Panduan Kuantisasi LLM: 7 Metode Dibandingkan (Lengkap dengan Angka Benchmark)

Panduan Kuantisasi LLM: 7 Metode Dibandingkan (Lengkap dengan Angka Benchmark)

Llama 3.3 70B di FP16 butuh 140 GB hanya untuk bobot. Dua H100. Di Q4_K_M, model yang sama muat di sekitar 42 GB, alias satu RTX A6000 bekas dari marketplace. Jarak inilah alasan kuantisasi LLM ada, dan salah pilih metode berarti mengorbankan kualitas yang kelihatan atau VRAM yang tidak kamu punya.

Panduan kuantisasi LLM ini membandingkan 7 metode yang relevan di 2026, dengan setiap angka ditelusuri ke sumber publiknya.

Poin Penting

• Kuantisasi menukar memori dan bandwidth dengan penurunan kualitas yang terukur, dan biasanya kecil.
• GPTQ dan AWQ mengutamakan GPU; GGUF adalah format yang juga bisa jalan di CPU.
• Q4_K_M mendarat di sekitar 4,8 bit per bobot, bukan 4. Penamaannya menyembunyikan overhead itu.
• Kuantisasi 6-bit berada dalam ~0,1% dari perplexity FP16 menurut PR k-quants llama.cpp.

Apa yang Sebenarnya Dilakukan Kuantisasi LLM pada Model Kamu?

Kuantisasi LLM menyimpan bobot model pada presisi numerik yang lebih rendah, memperkecil memori dan bandwidth dengan mengorbankan galat pembulatan. Model 70B parameter turun dari 140 GB di FP16 menjadi sekitar 42 GB di 4-bit. Kecerdasannya tetap; angka di belakang koma yang hilang. Setiap metode di panduan ini adalah varian dari pertukaran itu.

Tangga presisi berjalan dari FP32 (32 bit) turun melalui FP16 dan BF16 (masing-masing 16 bit), lalu INT8, lalu INT4. Setiap langkah memangkas separuh byte per parameter. Standar IEEE 754 mendefinisikan format float; paper Mark Horowitz tahun 2014 "Computing's Energy Problem" menunjukkan mengapa memindahkan byte tersebut, bukan aritmetika di atasnya, mendominasi biaya energi. Itulah alasan fisik mengapa kuantisasi mempercepat inferensi.

Dua parameter membuat kuantisasi bekerja: faktor skala (pengali yang memetakan rentang integer kembali ke nilai riil) dan zero-point (integer yang mewakili 0,0). Kuantisasi simetris memusatkan rentang pada nol dan melewatkan zero-point; kuantisasi asimetris menggesernya agar memakai seluruh rentang integer ketika bobot mengumpul jauh dari nol.

Bobot terkuantisasi dengan rapi karena statis dan terdistribusi normal. Aktivasi tidak. Aktivasi outlier, kadang 100x median, meledakkan galat pembulatan jika kamu mengkuantisasinya secara naif. Asimetri itulah alasan kebanyakan metode di sini hanya mengkuantisasi bobot (W4A16) dan membiarkan aktivasi di FP16.

Kuantisasi pasca-pelatihan (post-training quantization, PTQ) mengonversi model yang sudah selesai dilatih. Quantization-aware training (QAT) mensimulasikan pembulatan selama pelatihan agar model beradaptasi. Semua yang ada di artikel ini adalah PTQ. QAT butuh komputasi lebih dan satu sesi pelatihan; itu keputusan terpisah.

Baris INT4 dan NF4 adalah 4-bit murni teoretis: 4 bit per bobot dan tidak ada yang lain. Format 4-bit riil membawa skala blok dan nilai minimum di atasnya, jadi hasilnya lebih tinggi. Model 70B di Q4_K_M sekitar 42 GB, bukan 35. Tabel VRAM di bagian bawah memakai laju efektif.

Kuantisasi tidak memperkecil kecerdasan model. Ia memperkecil jumlah angka di belakang koma tempat kecerdasan itu disimpan. Dan kalau kamu bayar per token untuk inferensi API, memangkas tagihan API LLM sering dimulai dari menjalankan model terkuantisasi sendiri.

7 Metode Kuantisasi, Berdampingan

Ketujuh metode di bawah mencakup setiap jalur produksi untuk mengkuantisasi LLM di 2026. Dua khusus GPU (GPTQ, AWQ), satu jalan di mana saja (GGUF), satu mengkuantisasi saat load (BitsandBytes), dua menarget serving throughput tinggi (SmoothQuant, FP8), dan satu native PyTorch (TorchAO). Pilihan yang tepat tergantung hardware kamu, bukan metode mana yang skornya tertinggi di leaderboard.

GPTQ mengkuantisasi lapis demi lapis menggunakan Hessian invers untuk mendistribusikan ulang galat pembulatan ke bobot yang tersisa. Ia butuh set kalibrasi dan GPU. Paper GPTQ melaporkan kuantisasi model 175B ke 3-4 bit dalam sekitar 4 GPU-jam.

AWQ mengidentifikasi ~1% bobot yang paling penting (bobot salien, ditemukan dari magnitudo aktivasi) dan menskalakannya untuk melindunginya dari pembulatan. Paper AWQ (best paper MLSys 2024) melaporkan speedup lebih dari 3x dibanding implementasi FP16 HuggingFace di GPU desktop maupun mobile.

GGUF adalah format file, bukan algoritma. Algoritma di dalamnya adalah skema blok k-quant dari llama.cpp PR #1684. Ini satu-satunya metode di sini yang jalan di CPU, yang membuatnya jadi default untuk inferensi lokal. Lihat model open-weight yang layak dikuantisasi untuk tahu apa yang cocok dimasukkan ke dalamnya.

BitsandBytes mengkuantisasi saat load, bukan di awal. NF4 (4-bit NormalFloat) adalah format andalannya, dan ia tulang punggung fine-tuning QLoRA. Tidak perlu set kalibrasi.

SmoothQuant memindahkan outlier aktivasi ke dalam bobot sehingga keduanya bisa jalan di INT8. Paper ini melaporkan speedup hingga 1,56x dan pengurangan memori 2x, dan menarget throughput pada serving batch besar, skenario di mana metode W4A16 menyia-nyiakan performa.

FP8 (W8A8) adalah jalur native di GPU H100 dan B200. Hampir lossless di 8-bit, tanpa pusing kalibrasi, dan vLLM mendukungnya langsung.

TorchAO adalah library kuantisasi milik PyTorch sendiri, dibangun untuk bekerja dengan torch.compile. Kalau pipeline kamu sudah PyTorch, ini jalur paling minim gesekan.

Hanya ada dua pertanyaan nyata: apakah hardware kamu bisa menjalankannya, dan apakah kamu bisa hidup dengan biaya kualitasnya?

Apa yang Sebenarnya Ditunjukkan Benchmark Publik?

Benchmark publik bilang kuantisasi 4-bit memakan 1-2% perplexity pada model 7B, dan 6-bit di bawah 0,1%. Angka-angka itu berasal dari llama.cpp PR #1684 (2023), diukur oleh para maintainer llama.cpp pada satu model 7B di RTX 4080. Mereka angka yang paling banyak dikutip di ruang kuantisasi, dan mereka nyata. Mereka juga n = 1.

Sumber: llama.cpp PR #1684 (2023). Model 7B, RTX 4080, diukur oleh maintainer llama.cpp. n = 1 model.

Catatan soal kolom bit/bobot: itu laju nominal untuk tipe k-quant dasar, dan campuran _K menaikkan laju efektifnya. Q2_K contohnya. Jalankan rumus artikel ini pada angka nominal 2,5625 dan model 6,74B parameter dan kamu dapat ~2,0 GB, tapi barisnya melaporkan file 2,67 GB, yang dihitung balik menjadi ~3,4 bit per bobot. Sisa artikel ini memakai laju efektif, diturunkan dari ukuran file ini.

Angka metode GPU datang langsung dari paper. GPTQ melaporkan speedup inferensi end-to-end dibanding FP16 sekitar 3,25x di A100 dan ~4,5x di A6000, dengan model 175B dikuantisasi ke 3-4 bit dalam sekitar 4 GPU-jam. AWQ melaporkan "speedup lebih dari 3x dibanding implementasi FP16 Huggingface di GPU desktop maupun mobile," plus deployment Llama-2 70B pertama di GPU mobile lewat TinyChat. Kami mengutip frasa paper-nya alih-alih memparafrasekan angka menjadi presisi palsu.

Kontribusi orisinal di sini adalah aritmetika. Memori untuk bobot mengikuti: weights (GB) ≈ params (B) × bits per weight ÷ 8. Jebakannya ada di angka bit-per-bobot mana yang kamu masukkan. PR #1684 mempublikasikan laju untuk tipe k-quant dasar (Q4_K = 4,5), dan campuran _S/_M/_L duduk di atas laju dasar itu karena mereka memberikan bit ekstra ke tensor attention dan feed-forward. Jadi kami menurunkan laju efektif dari ukuran file yang dipublikasikan PR itu sendiri, pada model 7B yang sebenarnya 6,74B parameter: Q2_K di 2,67 GB dihitung balik menjadi ~3,4 bpw, Q4_K_S di 3,56 GB menjadi ~4,5, Q6_K di 5,15 GB menjadi ~6,6. Q4_K_M mendarat di sekitar 4,8.

Itu mengubah angka utamanya. Model 70B di Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. Kebanyakan artikel bilang 35 GB. Mereka memakai 4,0 bpw dan melewatkan overhead skala blok sepenuhnya. Cek silangnya cuma satu klik: Llama-3.3-70B-Instruct-Q4_K_M.gguf dikirim di 42,5 GB di HuggingFace, di repo bartowski, lmstudio-community, dan second-state sama saja. Kami menghitung ulang setiap sel di tabel VRAM di bawah dengan basis itu.

Bacaan kami atas angka-angka ini: jarak perplexity antara Q6_K (5,9110) dan F16 (5,9066) adalah 0,0044, yang lebih kecil dari jarak antara dua fine-tune berbeda dari model dasar yang sama. Itulah mengapa "pakai saja Q4_K_M atau Q5_K_M" adalah saran yang bertahan saat bertemu hardware nyata. Kolom ms/token juga menunjukkan Q2_K tidak memberi tambahan kecepatan dibanding Q4_K_S (keduanya 15,5 ms/token) sambil memakan 0,75 perplexity. Q2_K adalah pertukaran terburuk di tabel.

Yang tidak diceritakan angka-angka ini: perplexity wikitext tidak sama dengan kualitas pada prompt kamu. Satu model di satu GPU itu n = 1. Angka kecepatan bergantung pada ukuran batch. Perlakukan ini sebagai penunjuk arah, bukan patokan universal.

Kuantisasi 6-bit mendarat di sekitar 0,1% dari perplexity model presisi penuh. Kompresinya hampir gratis di level itu.

GPTQ vs AWQ: Memilih di Antara Dua Metode GPU

GPTQ dan AWQ sama-sama menghasilkan checkpoint 4-bit GPU dari set kalibrasi, dan keduanya didukung baik di vLLM. Perbedaannya ada di cara mereka menangani galat pembulatan. GPTQ mendistribusikannya ulang ke bobot tersisa memakai Hessian invers. AWQ melindungi 1% bobot yang ditandai penting oleh aktivasi. Keduanya bekerja. Pilihannya soal pola serving kamu.

GPTQ bekerja lapis demi lapis. Untuk setiap layer, ia mengkuantisasi satu bobot pada satu waktu, lalu menyesuaikan bobot tersisa di layer itu untuk mengompensasi pembulatan yang baru saja dilakukan. Penyesuaiannya memakai informasi orde dua dari matriks Hessian, itulah mengapa ia butuh set kalibrasi untuk dihitung. Hasilnya kuat untuk inferensi batch di mana throughput lebih penting dari latensi per token.

AWQ mengambil sudut berbeda. Ia mengidentifikasi bobot salien dengan melihat magnitudo aktivasi di seluruh set kalibrasi, kira-kira 1% channel teratas. Bobot-bobot itu mendapat faktor skala per channel yang menjaga mereka di rentang presisi lebih tinggi selama pembulatan. Set kalibrasinya bisa lebih kecil dari milik GPTQ, dan AWQ lebih tidak overfit kepadanya karena ia melindungi fitur struktural, bukan mencocokkan diri ke input spesifik. Paper ini melaporkan hasil kuat pada serving sensitif latensi.

Pilih GPTQ jika: kamu melakukan inferensi batch di GPU, punya set kalibrasi bagus yang cocok dengan domain kamu, dan throughput adalah metriknya.

Pilih AWQ jika: kamu melayani request pengguna tunggal dengan latensi rendah, ingin set kalibrasi lebih kecil, atau deploy di GPU edge/mobile.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Kalau kamu juga sedang memilih antar serving engine, vLLM vs SGLang membahas keputusan itu secara terpisah.

GGUF dan K-Quant: Apa Arti Q4_K_M Sebenarnya

GGUF adalah format file, bukan algoritma kuantisasi. Spek GGUF mendefinisikan kontainer untuk bobot model, metadata, dan data tokenizer. Algoritma kuantisasi di dalam file GGUF adalah skema blok k-quant (atau i-quant) dari llama.cpp PR #1684. Mencampuradukkan kontainer dengan algoritma adalah kesalahan paling umum di ruang ini, dan ia memicu pertanyaan seperti "mana yang lebih baik, GGUF atau GPTQ?" yang tidak benar-benar masuk akal.

Skema penamaannya didekode sebagai berikut. Q berarti skema blok k-quant; IQ berarti i-quant matriks kepentingan (varian lebih baru yang memakai matriks kepentingan untuk kualitas lebih baik pada kedalaman bit yang sama). Angkanya adalah kedalaman bit nominal. _K menandai keluarga k-quant versus format lawas seperti Q4_0. _S, _M, _L mengontrol grup tensor mana yang mendapat bit ekstra: small, medium, large. Sufiks lebih tinggi berarti lebih banyak bit dialokasikan ke tensor attention dan feed-forward yang paling penting.

Laju efektif, dihitung balik dari ukuran file 7B (6,74B parameter) yang dipublikasikan di PR #1684, bukan angka tipe dasar. Baris lawas eksak menurut konstruksi: blok Q4_0 adalah 32 bobot pada 4 bit plus satu skala FP16, yaitu 4,5 bit per bobot, dan Q8_0 adalah 32 bobot pada 8 bit plus skala FP16, yaitu 8,5. PR itu mengonfirmasinya, mendaftar file Q4_0 dan Q4_K_S 7B di 3,56 GB yang sama.

Q4_K_M bukan 4 bit per bobot. Sekitar 4,8. Skala blok dan nilai minimum harus tinggal di suatu tempat, dan campuran _M kemudian membelanjakan bit ekstra pada tensor attention dan feed-forward, yang persis mengapa Q4_K_M duduk di atas Q4_K_S dan Q3_K_M duduk di atas Q3_K_S alih-alih menyamainya.

Mengapa GGUF jalan di tempat GPTQ tidak bisa: ia mendukung inferensi CPU dan offload layer antara VRAM GPU dan RAM sistem. Model 32B yang tidak muat seluruhnya di GPU kamu bisa jalan dengan separuh layer di-offload, pelan tapi fungsional. GPTQ tidak punya jalur CPU.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Baru di model lokal? Mulai dengan menjalankan model lokal pertama kamu sebelum mengkuantisasi apa pun. Dan kalau kamu mau UI browser, Open WebUI di atas Ollama butuh sekitar sepuluh menit. Dokumentasi GGUF HuggingFace menjelaskan bagaimana Hub mengekspos penamaan tipe quant.

BitsandBytes, Marlin, SmoothQuant, dan TorchAO

Empat ini mencakup jalur produksi yang tersisa. Tidak ada yang "GPTQ yang lebih baik". Mereka memecahkan masalah yang berbeda.

BitsandBytes mengkuantisasi saat load, bukan di awal. Kamu mengarahkannya ke checkpoint FP16 dan ia mengonversi langsung ke NF4 atau FP4. Tanpa set kalibrasi, tanpa langkah offline. Klaim terbesarnya adalah QLoRA: model dasar 4-bit yang dibekukan dengan adaptor LoRA dilatih di atasnya, yang membuat fine-tuning model 65B di satu GPU mungkin pada 48 GB VRAM. QLoRA adalah teknik pelatihan, bukan teknik inferensi, tapi ia alasan kebanyakan orang bertemu BitsandBytes pertama kali.

Marlin bukan metode kuantisasi. Ia kernel GEMM presisi campuran INT4xFP16 yang membuat checkpoint 4-bit yang sudah ada lebih cepat pada ukuran batch sedang. Paper Marlin melaporkan speedup di A100 dan H100. Kalau stack serving kamu mendukungnya, kamu mengaktifkannya pada model yang sudah terkuantisasi. Kamu tidak "mengkuantisasi dengan Marlin".

SmoothQuant menggeser outlier aktivasi ke dalam bobot lewat faktor skala per channel, membuat W8A8 (bobot dan aktivasi sama-sama di INT8) layak. Paper ini menarget serving batch besar, kasus di mana metode W4A16 menyia-nyiakan throughput. Kalau kamu melayani ratusan request bersamaan, ini langkahnya.

TorchAO adalah kuantisasi native PyTorch yang bekerja dengan torch.compile. Tanpa dependensi eksternal, tanpa konversi format. Kalau pipeline inferensi kamu sudah PyTorch, ini opsi dengan gesekan paling rendah. Untuk menjalankan model embedding secara lokal, jalur Ollama biasanya lebih sederhana, tapi TorchAO cocok untuk stack PyTorch kustom.

Berapa VRAM yang Dibutuhkan Model Terkuantisasi?

Rumusnya weights (GB) ≈ params (B) × bits per weight ÷ 8. Model 70B di Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. Laju di bawah adalah laju efektif, dihitung balik dari ukuran file yang dipublikasikan llama.cpp PR #1684, bukan dari angka tipe dasar, karena campuran _M selalu berjalan di atas laju k-quant dasarnya. Kami menghitung ulang, bukan menyalin jalan pintas 4,0 bpw yang biasa dipakai.

Dihitung dari bit-per-bobot efektif: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Diturunkan dari ukuran file 7B (6,74B parameter) di PR #1684, lalu dicek silang dengan build 70B publik: Llama-3.3-70B-Instruct-Q4_K_M.gguf berukuran 42,5 GB di HuggingFace, versus 42,0 GB yang diprediksi di sini.

Peringatan jujurnya: ini hanya bobot. KV cache, panjang konteks, dan overhead framework menambah di atasnya. KV cache berskala dengan panjang konteks dan ukuran batch. Sesi konteks 32k pada model 70B bisa menambah beberapa GB. Tabel bobot adalah lantai, bukan anggaran. Jendela konteks kamu juga menyewa VRAM. Untuk gambaran penuh, lihat kebutuhan VRAM per model secara rinci.

Metode Kuantisasi Mana yang Harus Kamu Pakai?

Hardware kamu memutuskan sebelum preferensi kamu. Metode yang tidak jalan di GPU kamu bukan pilihan, melainkan harapan. Tabel di bawah memetakan setup umum ke metode yang benar-benar bekerja untuknya, berdasarkan kendala hardware dan pertukaran kualitas yang sudah dibahas di atas.

Untuk kebanyakan pembaca di hardware konsumen, GGUF Q4_K_M atau Q5_K_M prakuantisasi adalah jawaban yang tepat. Tarik dari HuggingFace, jalankan di Ollama atau llama.cpp, dan berhenti mengoptimasi. Perbedaan kualitas antara Q4_K_M dan Q5_K_M cukup kecil sehingga kamu harus memilih berdasarkan apakah file-nya muat, bukan berdasarkan tabel perplexity. Semua yang melampaui itu adalah optimasi demi optimasi itu sendiri, dan ia hanya layak dilakukan setelah kamu mengonfirmasi modelnya benar-benar memecahkan masalah kamu di Q4.

Panduan tools yang benar-benar menjalankan model ini secara lokal membahas sisi serving setelah kamu memilih level quant.

Lima Cara Kuantisasi Bisa Gagal

Kegagalan kuantisasi hampir selalu masalah konfigurasi, bukan masalah metode. Lima ini muncul terus-menerus.

1. Set kalibrasi tidak cocok dengan domain kamu. GPTQ dan AWQ keduanya mencocokkan diri ke data kalibrasi. Kalau kamu kalibrasi di Wikipedia dan deploy di transkrip medis, model terkuantisasi berkinerja buruk pada token yang tidak pernah ia lihat. Solusi: pakai set kalibrasi yang diambil dari distribusi input aktual kamu, bahkan 128 sampel saja membantu.

2. Ukuran grup disetel terlalu besar. Ukuran grup GPTQ mengontrol berapa banyak bobot berbagi satu faktor skala. 128 adalah standar. 256 atau 512 menghemat komputasi selama kuantisasi tapi menabrak tebing kualitas pada model lebih kecil. Solusi: tetap di 128 kecuali kamu sudah mengonfirmasi kualitasnya bertahan pada prompt kamu.

3. Mengharapkan Q2_K bisa dipakai. Menurut data PR #1684, Q2_K memakan ~0,87 perplexity versus F16 dan tidak memberi tambahan kecepatan dibanding Q4_K_S (keduanya 15,5 ms/token pada benchmark 7B). Kamu dapat file lebih kecil dan output lebih buruk tanpa keuntungan latensi. Solusi: Q4_K_S adalah lantai kecuali ukuran file adalah kendala keras.

4. Benchmark di perplexity wikitext, bukan di prompt kamu sendiri. Perplexity adalah metrik pemodelan bahasa. Ia tidak mengukur apakah model mengikuti system prompt kamu, memformat JSON dengan benar, atau menangani kosakata domain kamu. Solusi: jalankan 20-30 prompt riil kamu melewati model terkuantisasi dan yang tidak, lalu bandingkan outputnya.

5. Mencampuradukkan kontainer GGUF dengan algoritma kuantisasi di dalamnya. Ini memicu perbandingan "GGUF vs GPTQ" seolah mereka kategori yang sama. Mereka bukan. GGUF adalah format file. Skema k-quant di dalamnya adalah algoritmanya. Solusi: bandingkan level k-quant (Q4_K_M vs Q5_K_M), bukan format file.

Pertanyaan yang Sering Diajukan

Apa itu kuantisasi LLM?

Kuantisasi LLM mengurangi presisi numerik bobot model, biasanya dari floating point 16-bit ke integer 4-bit atau 8-bit. Ini memangkas penggunaan memori dan mempercepat inferensi dengan mengurangi bandwidth. Model 70B turun dari 140 GB menjadi sekitar 42 GB di 4-bit. Biaya kualitasnya biasanya 1-2% perplexity di 4-bit, lebih kecil di 6-bit.

Apakah kuantisasi mengurangi akurasi model?

Ya, tapi lebih sedikit dari yang kebanyakan orang kira. Menurut benchmark llama.cpp PR #1684, Q4_K_S pada model 7B memakan sekitar 2% perplexity versus F16, dan Q6_K di bawah 0,1%. Dampak praktis pada prompt riil sering lebih kecil dari yang ditunjukkan angka perplexity, terutama di Q4_K_M ke atas.

GPTQ atau AWQ yang lebih baik?

Tidak ada yang universal lebih baik. GPTQ memakai redistribusi galat Hessian invers dan cocok untuk inferensi GPU batch. AWQ melindungi bobot salien lewat skala sadar-aktivasi dan cocok untuk serving sensitif latensi. AWQ butuh set kalibrasi lebih kecil dan lebih tidak overfit kepadanya. Kalau kamu melayani request pengguna tunggal dengan latensi rendah, mulai dengan AWQ.

Apa arti Q4_K_M?

Q4_K_M adalah level kuantisasi GGUF k-quant. "Q4" berarti kedalaman 4-bit nominal, "K" menandai skema blok k-quant (versus Q4_0 lawas), dan "M" berarti medium: tensor attention dan feed-forward mendapat bit ekstra. Bit efektif per bobot sekitar 4,8, bukan 4,0, karena skala blok dan nilai minimum menambah overhead dan campuran medium membelanjakan lebih banyak di atasnya.

Bisakah saya menjalankan model terkuantisasi di CPU?

Bisa, tapi hanya lewat GGUF. GPTQ dan AWQ adalah format khusus GPU. Model k-quant GGUF jalan di CPU lewat llama.cpp atau Ollama, dan mendukung offload layer antara VRAM GPU dan RAM sistem. Q4_K_M adalah quant CPU standar. Harapkan generasi token lebih lambat dari GPU, tapi inferensi yang fungsional.

Apa perbedaan GGUF dan GGML?

GGML adalah library tensor dan format file lebih lama yang awalnya dipakai llama.cpp. GGUF menggantikannya pada Agustus 2023 sebagai format kontainer yang lebih fleksibel dengan dukungan metadata lebih baik. File GGUF adalah yang kamu unduh dari HuggingFace hari ini. File GGML sudah lawas dan jarang didistribusikan lagi.

Harus kuantisasi sendiri atau unduh yang sudah jadi?

Unduh yang sudah jadi dulu. Komunitas llama.cpp dan HuggingFace sudah mengkuantisasi kebanyakan model populer di setiap level. Kuantisasi sendiri hanya masuk akal kalau kamu butuh set kalibrasi spesifik untuk domain kamu, atau kalau tidak ada versi prakuantisasi untuk model kamu.

Kapan pakai kuantisasi alih-alih model yang lebih kecil?

Pakai kuantisasi ketika kamu butuh kemampuan model yang lebih besar tapi tidak bisa memuatnya di memori. Model 70B terkuantisasi umumnya mengungguli model 13B tanpa kuantisasi pada tugas penalaran kompleks. Pakai model lebih kecil sebagai gantinya ketika latensi adalah kendalanya, karena model lebih kecil menghasilkan token lebih cepat terlepas dari kuantisasi.

Apa perbedaan kuantisasi dan distilasi?

Kuantisasi mengurangi presisi numerik bobot model yang sudah ada. Distilasi melatih model lebih kecil untuk meniru yang lebih besar, menghasilkan arsitektur yang benar-benar berbeda (lebih kecil). Kuantisasi mempertahankan arsitektur model asli dan pada prinsipnya reversibel. Distilasi membuat model baru dan membutuhkan satu sesi pelatihan.

Versi pendeknya: kuantisasi adalah cara kamu memuat model yang kamu mau ke hardware yang kamu punya. Untuk kebanyakan orang di GPU konsumen atau Apple Silicon, GGUF Q4_K_M prakuantisasi yang ditarik dari HuggingFace adalah seluruh solusinya. GPTQ dan AWQ adalah jawaban serving GPU. FP8 dan SmoothQuant adalah jawaban throughput produksi. Semua yang lain adalah optimasi setelah kamu mengonfirmasi modelnya bekerja.

Kalau kamu sedang memutuskan apa yang akan di-self-host dan ingin pendapat kedua soal pasangan hardware-metode, kami siap ngobrol.