Lompat ke alat
JoeLucky

Klik ★ pada alat untuk menyimpannya

Kategori Alat

Enkoder/Dekoder Base64Penampil Pohon JSONPOPULERDekoder JWTPembuat UUIDEnkoder/Dekoder URLJSON ke CSVCSV ke JSONJSON ke YAMLYAML ke JSONJSON ke XMLXML ke JSONCSV ke YAMLYAML ke CSVPemformat JSONPemformat YAMLPemformat XMLPemformat HTMLPemformat CSSPenguji RegexPembuat HashPengurai CronEnkoder/Dekoder Entitas HTMLPengubah Basis BilanganPengurai URLPenampil dan Validator CSVPratinjau MarkdownPemformat SQLEditor Mermaid LangsungKalkulator Biaya API LLMBARUKalkulator VRAM LLMBARUVisualisasi Chunk RAGBARUBiaya Penyimpanan Cloud (S3, R2, B2)BARUKalkulator Uptime SLABARU
JoeLucky

Alat online praktis, semua di satu tempat

Kebijakan PrivasiKetentuan Layanan

© 2026 JoeLucky®. Hak cipta dilindungi.

  1. JoeLucky
  2. /Developer
  3. /Kalkulator VRAM LLM

Kalkulator VRAM LLM

Perkirakan VRAM yang dibutuhkan LLM dan periksa apakah muat di GPU Anda.

Laporkan

DEVELOPER SERUPA

Lihat semua
Kalkulator Biaya API LLM

Bandingkan biaya API per permintaan dan bulanan di OpenAI, Anthropic, dan Gemini, dengan tanggal verifikasi harga.

Buka →
Visualisasi Chunk RAG

Tempel dokumen untuk melihat pemecahan RAG dan perkiraan biaya embedding langsung. Teks tidak diunggah.

Buka →
Pengubah Satuan

Konversi antarsatuan di 12 kategori, termasuk panjang, berat, suhu, luas, dan volume.

Buka →

💬 Komentar

?

Belum ada komentar. Jadilah yang pertama!

APA ITU Kalkulator VRAM LLM?

Kalkulator VRAM LLM memperkirakan memori yang Anda perlukan untuk MENJALANKAN model bahasa besar secara lokal atau self-hosted. Total ≈ bobot + KV cache + overhead runtime, dengan bobot = parameter × bit per bobot ÷ 8 dan KV cache = 2 × lapisan × kepala KV × dimensi kepala × byte per elemen × konteks × sekuens bersamaan. Pilih model, kuantisasi, dan perangkat, lalu alat memberi tahu apakah muat, sisa ruang, konteks terpanjang yang muat, dan batas atas kecepatan generasi.

Cara memakai

  1. Pilih model (atau masukkan parameter, lapisan, kepala KV, dan dimensi kustom) dan kuantisasi bobot.
  2. Atur presisi KV cache, panjang konteks, dan jumlah sekuens bersamaan.
  3. Pilih kapasitas dan jenis perangkat (GPU diskrit, memori terpadu Apple) dan, jika perlu, jumlah perangkat dan bandwidth memori.
  4. Baca apakah muat, rincian memori, konteks terpanjang, dan tabel perbandingan per kuantisasi.

Catatan

  • Contoh: Llama 3.1 8B dalam Q4_K_M dengan konteks 8.192 token dan satu sekuens membutuhkan sekitar 4,6 GiB bobot dan sekitar 1 GiB KV cache, sekitar 7 GiB dengan overhead default.
  • Spesifikasi model berasal dari file config.json Hugging Face dan metadata safetensors; lebar bit kuantisasi adalah pengukuran llama.cpp pada Llama-3.1-8B dan sedikit berbeda untuk model lain.
  • Alat ini memperkirakan memori hanya untuk inferensi, bukan pelatihan atau fine-tuning; penggunaan nyata bervariasi menurut mesin, batching, dan versi CUDA, jadi sisakan margin.
  • Semuanya dihitung di browser Anda.

Pertanyaan yang sering diajukan

Berapa VRAM yang saya butuhkan untuk menjalankan LLM?

Total ≈ bobot + cache KV + overhead runtime. Bobot = parameter × bit per bobot ÷ 8; misalnya model 8 miliar parameter membutuhkan sekitar 15 GiB dalam FP16 (16 bit) dan sekitar 4,6 GiB dalam Q4_K_M (sekitar 4,9 bit). Cache KV tumbuh seiring panjang konteks dan jumlah sekuens bersamaan, jadi atur keduanya.

Apa itu cache KV dan mengapa konteks lebih panjang memakai lebih banyak memori?

Untuk setiap token yang diproses, model menyimpan Key dan Value tiap lapisan agar tidak perlu menghitungnya ulang saat menghasilkan. Ukuran = 2 × lapisan × kepala KV × dimensi kepala × byte per elemen × panjang konteks × sekuens, sehingga sebanding dengan panjang konteks. Model dengan grouped-query attention (kepala KV lebih sedikit) atau jendela geser membutuhkan jauh lebih sedikit.

Kuantisasi mana yang harus saya pilih? Apa pembeda Q4, Q5, dan Q8?

Bit lebih sedikit membuat bobot lebih kecil dan biasanya lebih cepat, dengan mengorbankan kualitas. Q8_0 mendekati aslinya, Q5_K_M dan Q6_K adalah kompromi umum, Q4_K_M adalah titik awal biasa saat memori terbatas, dan penurunan kualitas mulai terasa di bawah Q3. Tabel menunjukkan apakah tiap tingkat muat dengan pengaturan Anda saat ini.

Bagaimana memori dihitung untuk model MoE (mixture-of-experts)?

Semua expert harus dimuat, jadi bobot memakai TOTAL parameter, bukan parameter yang aktif untuk tiap token. Kecepatan generasi, sebaliknya, bergantung pada parameter AKTIF, itulah sebabnya model MoE sering memakai banyak memori tetapi tidak terlalu lambat.

Bisakah model memakai seluruh memori terpadu Mac Apple Silicon?

Biasanya tidak. Secara default sistem hanya membiarkan GPU memakai sebagian memori terpadu (kira-kira dua pertiga hingga tiga perempat), jadi memilih “Memori terpadu Apple” menganggap 75% dapat dipakai. Pilih “Porsi yang dapat dipakai kustom” untuk menyesuaikan dengan pengaturan Anda yang sebenarnya.

Bagaimana beberapa GPU ditangani?

Bobot dan cache KV diasumsikan terbagi rata ke semua kartu dan tiap kartu menanggung overhead runtime tetapnya sendiri, sehingga totalnya sedikit lebih tinggi daripada satu kartu. Pembagian sebenarnya (paralelisme tensor atau pipeline) dan overhead komunikasi bergantung pada engine, jadi sisakan margin tambahan.

Seberapa akurat ini? Apakah mencakup pelatihan atau fine-tuning?

Ini estimasi perencanaan hanya untuk INFERENSI: bobot, cache KV, dan overhead yang dapat disesuaikan. Penggunaan nyata bervariasi menurut engine (vLLM, llama.cpp, dan lainnya), batching, versi CUDA, dan pengaturan paged-KV. Pelatihan dan fine-tuning membutuhkan memori jauh lebih besar (gradien, status optimizer, aktivasi) dan berada di luar alat ini.

Bagaimana batas kecepatan generasi diperkirakan?

Menghasilkan tiap token membaca bobot aktif sekali, jadi pada ukuran batch 1 batasnya kira-kira “bandwidth memori ÷ byte bobot yang dibaca per token”. Ini batas teoretis yang mengabaikan batas komputasi, pembacaan cache KV, dan overhead perangkat lunak, sehingga kecepatan nyata biasanya lebih rendah. Ini hanya muncul setelah Anda memasukkan bandwidth perangkat Anda.

Perangkat

Ukuran umum
Jenis perangkat
Lanjutan: overhead runtime
%
Muat — Konfigurasi ini dapat dimuat di perangkat ini.
Bobot4,58 GiB
Cache KV1,00 GiB
Overhead runtime1,46 GiB
Total7,03 GiB
Dibutuhkan per perangkat7,03 GiB
Dapat dipakai per perangkat22,08 GiB
Sisa ruang15,05 GiB
Konteks terpanjang yang muat di perangkat ini131.456
Sekuens bersamaan terbanyak pada konteks ini16
Batas atas kecepatan generasi (perkiraan, token/dtk)—

Semua tingkat kuantisasi (pengaturan saat ini)

Semua tingkat kuantisasi (pengaturan saat ini)
KuantisasibpwBobotTotalMuat?
FP323229,92 GiB34,91 GiBTidak
FP161614,96 GiB18,45 GiBYa
Q8_08.50087,95 GiB10,74 GiBYa
FP887,48 GiB10,23 GiBYa
Q6_K6.56336,14 GiB8,75 GiBYa
Q5_K_M5.70365,33 GiB7,87 GiBYa
Q5_K_S5.57045,21 GiB7,73 GiBYa
Q4_K_M4.89444,58 GiB7,03 GiBYa
Q4_K_S4.66724,36 GiB6,80 GiBYa
Q3_K_L4.29794,02 GiB6,42 GiBYa
Q3_K_M3.9963,74 GiB6,11 GiBYa
Q3_K_S3.64293,41 GiB5,75 GiBYa
Q2_K3.15932,95 GiB5,25 GiBYa

Spesifikasi model berasal dari file config.json Hugging Face dan metadata safetensors (diverifikasi 2026-10-20); nilai bpw kuantisasi adalah hasil ukur llama.cpp pada Llama-3.1-8B dan sedikit berbeda untuk model lain.

Ini perkiraan perencanaan memori yang dibutuhkan untuk MENJALANKAN (inferensi) model, bukan untuk melatih atau fine-tuning. Penggunaan nyata bervariasi menurut engine (vLLM, llama.cpp, TensorRT-LLM…), batching, dan versi CUDA, jadi sisakan margin.

Rumus dan asumsi
  • Bobot = parameter × bit per bobot ÷ 8.
  • Cache KV = 2 × lapisan × head KV × dimensi head × byte per elemen × konteks × sekuens; lapisan sliding-window (mis. Gemma 2) dihitung paling banyak sepanjang jendela.
  • Overhead runtime = jumlah tetap per perangkat + sebagian dari bobot; ini aturan praktis yang dapat Anda sesuaikan.
  • Dengan beberapa perangkat, bobot dan cache diasumsikan terbagi rata dan setiap perangkat membayar overhead tetap.
  • Batas atas kecepatan = bandwidth memori ÷ byte bobot yang dibaca per token (batch 1, komputasi diabaikan).