Bumalik sa blog

GGUF Quantization: Aling Level ang Gagamitin Mo?

Setyembre 13, 2026

Default sa Q4_K_M; pumunta sa Q6_K o Q8_0 kapag may sobra kang VRAM at kailangan mo ang huling ilang porsyento ng quality. Ang GGUF quantization ay pumipintig sa mga weight ng model mula 16 bits pababa — nagsi-store ang Q4_K_M ng mga 4.85 bits kada weight, kaya bumababa ang 7B model mula ~14 GB tungong ~4.1 GB na may perplexity na karaniwang wala pang 1% na masama kaysa orihinal. Ang tanong na “alin ang gguf quantization na gagamitin” ay may nakakaboring na matatag na sagot na tinatabunan ng karamihan ng drama sa online. Sa ibaba: ang aktwal na ginagawa ng quantization sa mga weight, magkano ang halaga ng bawat level sa quality, kung paano gawin ang size math mismo, at isang command para sukatin ang pinsala sa sarili mong hardware sa halip na maniwala sa benchmark ng iba.

Ano talaga ang ginagawa ng GGUF quantization?

Sanay ang model sa 16-bit floating point (FP16 o BF16): ang bawat isa sa bilyun-bilyong weight nito ay 2-byte na numero. Kinukumpress ng quantization ang bawat weight sa mas kaunting bits. Ang naive na paraan — i-round ang bawat weight sa 4-bit na integer — sumisira ng maliliit pero mahahalagang values, kaya gumagamit ang GGUF ng dalawang trick:

  1. Block scaling. Grinogrupo ang mga weight sa mga block (karaniwang 32), at may sariling scale factor ang bawat block. Mga offset sa loob ng block na iyon ang mga 4-bit na values, kaya nakaliligtas ang malawak na saklaw ng magnitudes.
  2. Importance-aware k-quants. Ang “K” sa Q4_K_M ay nangangahulugang mga super-block ng scales, kasama ang pagtrato sa mga attention at feed-forward layer nang magkaiba, dahil magkakaiba ang pagtitiis nila sa compression.

Ang pamilyang “I” (IQ4_XS at mga kaibigan nito) ay lumalalim pa sa mga information-theoretic codebook na hiram mula sa image compression. Parehong idea, mas pino na encoding: mas kaunting bits kada weight sa katulad na quality, sa halaga ng bahagyang mas mabagal na inference sa ilang backend.

Isang paglilinaw na pumipigil sa karamihan ng kalituhan: binabago ng quantization ang mga stored weight lang. Architecture, tokenizer, at paghawak ng context — walang galaw. Ang Q4 file at Q8 file ng parehong model ay iisang model, nakaiba lang ng Amerikana.

Q4 vs Q8: mas mainam ba ang mas mataas na quantization?

Oo, technically; hindi, sa pakiramdam. Gamitin bilang sanggunian ang sariling mga perplexity run ng llama.cpp sa mga Llama model: umaabot ang Q8_0 sa loob ng ~0.02% ng FP16 — para sa anumang praktikal na layunin, lossless. Halos hindi makilala ang Q6_K. Humahatak ng mga 1–2% perplexity ang Q4_K_M, kaunti pa ang Q4_0, at sa Q2_K nagsisimulang gumuho ang mga masasagot sa maliliit na model.

Dalawang tuntuning ipinahihiwatig ng mga numero:

  • Bumibili ang laki ng model ng quantization headroom. Nabubuhay ang 70B model sa Q2/Q3 nang mas maganda kaysa 7B model, dahil mas marami ang redundancy ng mas malalaking model. Ang pag-quantize ng 7B sa Q2 ay pagputol ng binti; ang pag-quantize ng 70B sa Q3 ay pananahi.
  • Sumusunod sa gawain ang quality floor. Kayang tiisin ng chat ang Q4. Ang eksaktong code generation, math, at RAG sa presisong mga dokumento ay mas maagang nagbubunyag ng quantization noise. Kapag tuloy-tuloy ang pagsusulat ng subtiliyong maling code ng Q4 model, subukan ang parehong model sa Q6_K bago mo sisihin ang model.
LevelBits/weightLaki vs FP16Pagkalugmok sa qualityGamitin kailan
Q2_K~3.4~21%Matindi sa sub-13BWalang ibang kasya, malalaking model lang
Q3_K_M~3.9~25%NapapansinSikip ang VRAM, ≥14B models
Q4_K_S~4.6~29%MaliitHindi kasya ang Q4_K_M at malapit na
Q4_K_M~4.85~30%~1% perplexityAng default. Pinakamainam na quality/size trade
Q5_K_M~5.7~35%~0.5%May VRAM, mga quality-critical na gawain
Q6_K~6.6~41%Halos walaCode/math, kumportable pa ring kumakasya
Q8_0~8.5~53%Epektibong walaMga reference run, mga base para sa fine-tune
IQ4_XS~4.3~27%≈Q4_K_MBahagyang masyadong malaki ang Q4_K_M, sumusuporta ang backend sa i-quants

Magkano ang VRAM na kailangan ng bawat level?

Gawin mo mismo ang size math sa halip na kabisaduhin ang mga table — isang linya lang:

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

Tapos idagdag ang mga bahaging hindi sinasama ng formula: ang KV cache (lumalaki kasama ang haba ng context — ilang daang MB hanggang ilang GB), mga activation, at compute buffers. Praktikal na margin: ang “4.9 GB” model ay nangangailangan ng 6 GB card sa 4k context, at flash-attention kasama ang KV-cache quantization para manatili doon sa 16k. Ang mga weight ang headline, hindi ang buong bill.

Aling GGUF quantization ang dapat mong gamitin?

Ayos ng pagdedesisyon, walang eksepsiyon na worth kabisaduhin:

  1. Kalkulahin muna ang context + KV budget mo, tapos ang mga weight. Mas masama ang context na hindi kasya kaysa quality na hindi mo masukat.
  2. Default sa Q4_K_M. May dahilan kung bakit ito ang default ng komunidad — mga 1% perplexity sa 70% ng laki. Bawat registry, kasama ang Ollama, ito ang binibitbit bilang baseline.
  3. Umakyat sa Q6_K kapag pinaparusa ng gawain ang ingay: code, math, extraction, kahit anong ipapakain mo sa pipeline nang walang bantay.
  4. Gamitin ang Q8_0 para sa reference lang — mga A/B test, pagsukat ng pinsala ng quantization, o base para sa fine-tune. Bilang daily driver, init lang sa VRAM sensors mo ang binibili nito.
  5. Lumusot sa ilalim ng Q4 sa ilalim lang ng bigat ng sitwasyon, at sa malalaking model lang. Subukan gamit ang kilalang-mahirap na prompt bago mo ito pagkatiwalaan.

Kung pipiliin mo kung aling file ang i-download sa Hugging Face, piliin ang isang Q4_K_M.gguf kaysa mga sharded split maliban kung ang mga split lang ang binibitbit ng uploader — mas kaunti ang gumagalaw na bahagi. At kung pinipili mo kung saan ito tatakbo, hiwalay ang usapin ng engine: tingnan ang llama.cpp vs Ollama para sa axis na iyon.

Paano mo mismo susukatin ang pinsala ng quantization?

Nagkakaiba ang mga benchmark; hindi nagbabago ang prompt mo. I-build nang isang beses ang llama.cpp, i-download ang dalawang level ng parehong model, at sukatin ang parehong perplexity (mas mabuti ang mababa) at tokens/second:

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 on a wiki-text chunk (lower = closer to the original model)
./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

# and speed on the same hardware
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Ang numerong Q4_K_M ay ilang sankot-kot na masama kaysa Q8_0 at ang file ay mga ~40% na mas maliit. Kapag hindi namamalayan ng downstream task mo ang pagkakaiba — at sa karamihan, hindi — may sagot ka na nang hindi nagbabasa ng leaderboard ng iba.

Nasasaktan ba ng quantization ang privacy o mga local-only na claim?

Hindi — arithmetic lang ito sa mga weight, ganap na offline, at ang quantized file ay mas maliit lang na lalagyan ng parehong mga parameter. Ang pagpapatakbo ng Q4_K_M locally ay nagtutulo ng eksaktong kaparehong dami (o kaunti) tulad ng pagpapatakbo ng full-precision model locally: walang umaalis sa makina. Ang variable na may kinalaman sa privacy ay kung saan tumatakbo ang inference, hindi ang lapad ng bit. Parehong naaangkop ang karaniwang babala sa model provenance sa bawat quant level: ang nakawan-base na “uncensored” fine-tune sa Q8 ay hindi mas ligtas kaysa parehong weight sa Q4. Para sa file-format na bahagi nito, tingnan ang paano mag-run ng mga GGUF model locally.

Aling level ang pipiliin mo?

Q4_K_M, at tigilan na ang pagbabasa ng mga forum tungkol dito. Mag-upgrade sa Q6_K para sa mga gawaing gutom sa presisyon kung papayag ang VRAM, mag-ingat ng isang Q8_0 para sa mga A/B comparison, at ituring na emergency ration ang kahit anong nasa ilalim ng Q4 — para sa malalaking model lang. Ang tanging pagkakamaling worth iwasan ay symmetric: pag-aalala sa Q4-vs-Q5 habang binabalewala ang haba ng context, na sumisira ng mas maraming local setup kaysa anumang quant sa kasaysayan.

FAQ

Ano ang ibig sabihin ng Q4, Q5 at Q8 sa GGUF?

Bits kada weight: nasa mga 4.8 BPW ang Q4_K_M, mga 5.5 ang Q5, mga 8.5 ang Q8. Mas maliit at mas mabilis ang mababa, na may bahagyang kapalit sa quality.

Aling quantization ang gagamitin ko para sa 7B model?

Ang Q4_K_M ang default — mga 30 porsyentong mas maliit kaysa Q8 na hindi namamalayan ng karamihan ang quality. Kunin ang Q8 kapag may sobrang RAM at gusto mo ang kisame.

Nawawalan ba ng accuracy ang mga quantized model?

Kaunti, at hindi pantay: nauunang bumagsak ang reasoning bago ang fluency. Sa ilalim ng mga Q4 totoo ang cliff; sa itaas ng Q5_K_M ingay na lang ang karamihan.

— mrsaynothing

— mrsaynothing

Mga field note sa AI, Linux at self-hosting.

Pag-usapan ang post na ito sa dev.to dev.to ↗

Ang susunod na how-to sa email

Isang email kada post. Ayusin, tuloy sa susunod.

self-hosted · walang third parties · one-click unsubscribe

ano ito?

Git Cherry Pick: Maramihang Commits, Branches, Conflicts

Nag-e-enjoy ka ba sa mga sulat na ito? Ito ang tinatayo ko para sa trabaho. i-hire ako