Kuantisasi GGUF: Level Mana yang Harus Anda Pakai?

Pilih Q4_K_M sebagai default; naik ke Q6_K atau Q8_0 saat VRAM Anda longgar dan Anda membutuhkan beberapa persen kualitas terakhir. Kuantisasi GGUF mengecilkan bobot model dari 16 bit ke lebih sedikit — Q4_K_M menyimpan sekitar 4.85 bit per bobot, sehingga model 7B menyusut dari ~14 GB menjadi ~4.1 GB dengan perplexity yang biasanya kurang dari 1% lebih buruk daripada aslinya. Pertanyaan “gguf quantization mana yang dipakai” punya jawaban yang stabil hingga membosankan, dan sebagian besar drama di internet justru menutupinya. Di bawah: apa yang sebenarnya dilakukan kuantisasi pada bobot, berapa biaya kualitas di tiap level, cara menghitung ukurannya sendiri, dan satu perintah untuk mengukur kerusakannya di perangkat keras Anda sendiri alih-alih memercayai benchmark orang tak dikenal.

Apa yang sebenarnya dilakukan kuantisasi GGUF?

Model dilatih dalam floating point 16-bit (FP16 atau BF16): setiap satu dari miliaran bobotnya adalah angka 2 byte. Kuantisasi memampatkan tiap bobot menjadi lebih sedikit bit. Cara naifnya — membulatkan setiap bobot ke integer 4-bit — menghancurkan nilai yang kecil tapi penting, maka GGUF memakai dua trik:

1. Block scaling. Bobot dikelompokkan ke dalam block (biasanya 32), dan tiap block mendapat faktor skala sendiri. Nilai 4-bit adalah offset di dalam block itu, sehingga rentang magnitudo yang lebar tetap bertahan.
2. K-quant yang sadar kepentingan. Huruf “K” pada Q4_K_M berarti super-block berisi skala-skala, ditambah perlakuan berbeda untuk layer attention dan feed-forward, karena keduanya tidak sama-sama toleran terhadap kompresi.

Keluarga “I” (IQ4_XS dan kawan-kawannya) melangkah lebih jauh dengan codebook information-theoretic yang dipinjam dari kompresi gambar. Ide yang sama, pengodean yang lebih canggih: lebih sedikit bit per bobot pada kualitas serupa, dengan biaya inferensi sedikit lebih lambat di beberapa backend.

Satu klarifikasi yang mencegah sebagian besar kebingungan: kuantisasi hanya mengubah bobot yang tersimpan. Arsitektur, tokenizer, dan penanganan konteks tidak tersentuh. File Q4 dan file Q8 dari model yang sama adalah model yang sama, mengenakan mantel yang berbeda.

Q4 vs Q8: apakah kuantisasi yang lebih tinggi lebih baik?

Secara teknis ya; secara persepsi tidak. Memakai hasil pengukuran perplexity milik llama.cpp sendiri pada model Llama sebagai referensi: Q8_0 berada dalam ~0.02% dari FP16 — untuk keperluan praktis apa pun, lossless. Q6_K nyaris tak terbedakan. Q4_K_M menambah sekitar 1–2% perplexity, Q4_0 sedikit lebih lagi, dan Q2_K adalah titik tempat jawaban yang koheren mulai berantakan pada model kecil.

Dua aturan yang tersirat dari angka-angka itu:

• Ukuran model membeli ruang gerak kuantisasi. Model 70B selamat dari Q2/Q3 jauh lebih baik daripada model 7B, karena model yang lebih besar lebih redundan. Mengkuantisasi model 7B ke Q2 adalah amputasi; mengkuantisasi model 70B ke Q3 adalah penjahitan.
• Batas kualitas bergerak mengikuti tugas. Chat menoleransi Q4. Generasi kode yang presisi, matematika, dan RAG atas dokumen yang teliti memperlihatkan noise kuantisasi lebih cepat. Jika model Q4 terus menulis kode yang salah secara halus, uji model yang sama di Q6_K sebelum Anda menyalahkan modelnya.

Level	Bit/bobot	Ukuran vs FP16	Kehilangan kualitas	Pakai saat
Q2_K	~3.4	~21%	Berat di bawah 13B	Tak ada pilihan lain, hanya model besar
Q3_K_M	~3.9	~25%	Terlihat jelas	VRAM ketat, model ≥14B
Q4_K_S	~4.6	~29%	Kecil	Q4_K_M tak muat dan selisihnya tipis
Q4_K_M	~4.85	~30%	~1% perplexity	Default. Pertukaran kualitas/ukuran terbaik
Q5_K_M	~5.7	~35%	~0.5%	VRAM tersedia, tugas yang kritis soal kualitas
Q6_K	~6.6	~41%	Nyaris nol	Kode/matematika, masih muat nyaman
Q8_0	~8.5	~53%	Praktis nihil	Run referensi, basis fine-tune
IQ4_XS	~4.3	~27%	≈Q4_K_M	Q4_K_M sedikit kebesaran, backend mendukung i-quant

Berapa banyak VRAM yang dibutuhkan tiap level?

Hitung sendiri ukurannya alih-alih menghafal tabel — hanya satu baris:

size_GB ≈ (bits_per_weight × params) / 8
# 8B model @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# 8B model @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

Lalu tambahkan bagian-bagian yang dilewatkan rumus itu: KV cache (tumbuh mengikuti panjang konteks — beberapa ratus MB hingga ber-GB), aktivasi, dan compute buffer. Margin praktisnya: model “4.9 GB” menginginkan kartu 6 GB pada konteks 4k, dan flash-attention plus kuantisasi KV-cache agar tetap bertahan di sana pada 16k. Bobot adalah judul beritanya, bukan seluruh tagihannya.

Kuantisasi GGUF mana yang sebaiknya Anda pakai?

Urutan keputusan, tanpa pengecualian yang layak dihafal:

1. Hitung anggaran konteks + KV Anda lebih dulu, baru bobotnya. Konteks yang tak muat lebih buruk daripada kualitas yang tak terukur.
2. Jadikan Q4_K_M default. Ia menjadi default komunitas dengan alasan — sekitar 1% perplexity untuk 70% dari ukurannya. Setiap registry, termasuk milik Ollama, mengirimkannya sebagai baseline.
3. Naik ke Q6_K saat tugasnya menghukum noise: kode, matematika, ekstraksi, apa pun yang Anda suapkan ke pipeline tanpa pengawasan.
4. Q8_0 hanya untuk referensi — uji A/B, pengukuran kerusakan kuantisasi, atau basis fine-tune. Sebagai pemakaian harian, ia kebanyakan membeli kehangatan di sensor VRAM Anda.
5. Turun di bawah Q4 hanya terdesak, dan hanya pada model besar. Uji dengan satu prompt yang diketahui sulit sebelum memercayainya.

Jika yang Anda pilih adalah file mana yang diunduh di Hugging Face, utamakan satu Q4_K_M.gguf daripada split yang terpecah kecuali pengunggahnya hanya mengirim yang itu — lebih sedikit bagian yang bergerak. Dan jika yang Anda pilih adalah di mana menjalankannya, pilihan mesin itu sumbu terpisah: lihat llama.cpp vs Ollama untuk sumbu itu.

Bagaimana mengukur sendiri kerusakan kuantisasi?

Benchmark berbeda-beda; prompt Anda tetap. Build llama.cpp sekali, unduh dua level dari model yang sama, dan ukur keduanya — perplexity (semakin rendah semakin baik) dan token/detik:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# perplexity pada potongan wiki-text (semakin rendah = semakin dekat ke model asli)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# dan kecepatan di perangkat keras yang sama
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Angka Q4_K_M akan beberapa perseratus poin lebih buruk daripada Q8_0 dan filenya ~40% lebih kecil. Jika tugas hilir Anda tak bisa membedakannya — dan untuk kebanyakan tugas, tak bisa — Anda sudah punya jawabannya tanpa membaca leaderboard siapa pun.

Apakah kuantisasi merugikan klaim privasi atau local-only?

Tidak — itu aritmetika pada bobot, sepenuhnya offline, dan file terkuantisasi hanyalah wadah yang lebih kecil dari parameter yang sama. Menjalankan Q4_K_M secara lokal membocorkan persis sebanyak (atau sesedikit) menjalankan model presisi penuh secara lokal: tidak ada yang keluar dari mesin. Variabel yang relevan bagi privasi adalah di mana inferensi dijalankan, bukan lebar bitnya. Peringatan biasa soal asal-usul model berlaku sama untuk semua level quant: fine-tune “uncensored” dengan basis curian dalam Q8 tidak lebih aman daripada bobot yang sama dalam Q4. Untuk sisi format filenya, lihat cara menjalankan model GGUF secara lokal.

Level mana yang harus Anda pilih?

Q4_K_M, dan berhentilah membaca forum soal itu. Naik ke Q6_K untuk pekerjaan yang rakus presisi jika VRAM mengizinkan, simpan satu Q8_0 untuk perbandingan A/B, dan perlakukan apa pun di bawah Q4 sebagai jatah darurat khusus model besar. Satu-satunya kesalahan yang layak dihindari sifatnya simetris: khawatir soal Q4-vs-Q5 sambil mengabaikan panjang konteks, yang merusak lebih banyak setup lokal daripada quant mana pun sepanjang masa.