Vilken kvantisering ska du välja? Vad Q4, Q5 och Q8 kostar i minne och kvalitet

Modellsidan visar en rad namn — Q4_K_M, Q5_K_M, Q6_K, Q8_0 — och en filstorlek per rad. Vad raden inte visar är hur många bitar per vikt namnet motsvarar, hur många gigabyte du köper eller säljer när du byter rad, och vad bytet gör med svaren. Alla tre går att ta reda på innan du laddar ner något. Den här texten fördjupar kvantiseringsstycket i modellguiden och stannar vid viktposten; hela minnesbudgeten med KV-cache, runtime och marginal står i hårdvaruguiden.

Räknesättet: parametrar × bitar per vikt ÷ 8

Vikterna är den post du kan räkna på i förväg. Multiplicera antalet parametrar med antalet bitar per vikt och dela med åtta, så får du antalet byte. Det svåra är inte formeln utan den andra faktorn: bitdjupet är sällan det heltal som namnet antyder.

llama.cpp publicerar bitdjupet i sin egen dokumentation för kvantiseringsverktyget, mätt på Llama-3.1-8B. Där står Q4_K_M som 4,8944 bitar per vikt, Q5_K_M som 5,7036 och Q8_0 som 8,5008. Sätter du in 8,03 miljarder parametrar i formeln får du 4,58, 5,33 och 7,95 GiB — exakt de storlekar samma tabell anger. Räknesättet stämmer alltså, så länge du använder det verkliga bitdjupet och inte siffran i namnet.

”Q4” är inte fyra bitar

Skillnaden mellan namnet och bitdjupet har två orsaker, och båda står i formatdokumentationen. Den första är blockstrukturen: Hugging Faces GGUF-dokumentation beskriver Q4_K som superblock med åtta block om 32 vikter, där varje block bär en egen skala och ett eget minvärde i sex bitar. Det landar på 4,5 bitar per vikt i stället för 4,0. Q5_K blir 5,5 och Q6_K 6,5625 av samma skäl. Även Q8_0, som lagrar en skalfaktor per block om 32 vikter, hamnar över sitt namn — llama.cpp mäter 8,5008 bitar per vikt.

Den andra orsaken är suffixet. _S och _M är inte två storlekar av samma sak utan två blandningar: k-kvantiseringen låter olika tensorer få olika precision. Det syns i tabellen — Q4_K_S ligger på 4,6672 bitar per vikt och Q4_K_M på 4,8944, alltså 0,23 bitar isär inom samma ”fyrbitars” familj. Vill du kringgå blandningen finns flaggan --pure i llama-quantize, som kvantiserar alla tensorer till samma typ. Det är sällan vad du vill, men det förklarar varför namnet inte räcker som beskrivning.

Hugging Faces tabell markerar dessutom Q4_0, Q5_0 och Q8_0 som äldre format med enkel avrundning per block, till skillnad från k-kvantiseringarna. Det är ett skäl att jämföra Q4_K_M mot Q5_K_M snarare än mot Q4_0 när du väljer nivå.

Vad ett steg kostar i minne

Ollamas egen modellsida för Llama 3.1 listar storleken per tagg, och siffrorna följer räkningen ovan. För 8B-varianten: q4_K_M 4,9 GB, q5_K_M 5,7 GB, q6_K 6,6 GB, q8_0 8,5 GB och fp16 16 GB. Steget från Q4 till Q5 kostar alltså cirka 0,8 GB på en 8B-modell — ofta ingenting på en maskin som redan klarar Q4.

Samma steg på en större modell är en helt annan sak. Ollamas 70B-taggar för samma modellfamilj visar q4_K_M 43 GB, q5_K_M 50 GB och q8_0 75 GB. Här kostar ett steg upp omkring 7 GB och två steg drygt 30 GB. Kostnaden för ett steg skalar med modellen, inte med din vana från 8B-modeller, och det är den vanligaste anledningen till att en tumregel som fungerade på en liten modell plötsligt gör en stor modell omöjlig att ladda.

Bitdjupen är llama.cpp:s mätning på Llama-3.1-8B. Storlekarna är de tal Ollama visar på sina egna taggsidor för Llama 3.1, kontrollerade 19 augusti 2026. Andra modellfamiljer har andra tal: Ollamas sida för Qwen 3 anger 5,2 GB för 8b-q4_K_M och 8,9 GB för 8b-q8_0, eftersom parameterantalet inte är exakt detsamma.

GiB eller GB — samma fil, två tal

llama.cpp skriver 4,58 GiB där Ollama skriver 4,9 GB. Det är inte en motsägelse utan två enheter: en gibibyte är 2³⁰ byte, en gigabyte 10⁹. Skillnaden är drygt sju procent och växer med filen — på en 70B-modell är den flera gigabyte. Blandar du enheterna när du jämför modellfilen mot ledigt minne kan du tro att du har marginal där du inte har det. Skriv därför alltid ut enheten i din egen kalkyl, precis som i minneskontrollen före nedladdning.

Vad ett steg kostar i kvalitet

Minnessidan är den lätta halvan. För kvalitetssidan publicerar llama.cpp en egen resultattavla för LLaMA 3 8B, framtagen på en angiven revision med CUDA-backend, en AMD Epyc 7742 och ett RTX 4090, med perplexitet mätt mot Wikitext-2 och Kullback–Leibler-divergens mot samma modell i f16. Tavlan är projektets egen mätning under de villkoren — inte ett allmängiltigt kvalitetsbetyg och inte något du ska räkna om till procent bättre eller sämre svar.

Med det förbehållet är mönstret tydligt. q8_0 ligger 0,0027 perplexitetsenheter över f16 med en KL-divergens på 0,0014. q5_K_M ligger 0,057 över, q4_K_M utan importansmatris 0,175 och q3_K_M 0,657. Kurvan är inte rak: steget från Q5 till Q4 ungefär tredubblar avvikelsen, och steget från Q4 till Q3 fyrdubblar den igen. Går du hela vägen till q2_K hamnar avvikelsen kring 2,4 enheter med importansmatris, och sannolikheten för rätt token faller enligt tavlan med ungefär 6,6 procent i genomsnitt. Utan matris är samma steg dyrare än så: tavlan anger 3,5 enheter.

Två detaljer i tavlan är värda att lägga märke till. Den första: q4_K_M med importansmatris ligger på 0,151 mot 0,175 utan — samma filstorlek, 4,58 GiB, men mindre avvikelse. Vilken kvantisering du har är alltså inte hela svaret; hur den togs fram spelar också roll. Den andra: q4_1 är på 4,78 GiB större än q4_K_M på 4,58 GiB men har enligt tavlan högre avvikelse. Större fil är inte automatiskt bättre kvalitet när formaten skiljer sig åt.

LM Studios egen dokumentation stannar vid en tumregel: välj ett fyrbitarsalternativ eller högre om maskinen klarar det. Den rekommendationen är rimlig som golv, men den avgör inte om du ska betala 0,8 GB för steget till Q5 eller 30 GB för steget till Q8. Det avgörs av din uppgift.

Provet du kan köra på din egen maskin

Ett steg i kvantisering är ett nytt testfall, inte samma modell med en gratis besparing. Så här kan ett litet, upprepningsbart prov se ut. Byt modellnamn mot din egen kandidat.

1. Hämta två grannar. Ta två varianter som ligger intill varandra, inte de två ytterligheterna: ollama pull llama3.1:8b-instruct-q4_K_M och ollama pull llama3.1:8b-instruct-q5_K_M. Ett steg åt gången gör resultatet tolkbart.
2. Läs av vad de tar. ollama list visar storleken på disk. Starta sedan en av dem och kör ollama ps, som enligt Ollamas dokumentation listar körande modeller — den raden, inte filstorleken, är vad som faktiskt är laddat.
3. Använd samma frågor på båda. Kör provpaketet från modellguiden — normalfall, svåra fall och sådant modellen ska avstå från. Sätt bedömningsreglerna innan du ser svaren, och frys prompt, temperatur, kontextlängd och runtimeversion mellan körningarna.
4. Kör flera gånger. En körning per variant är ingen mätning. Kör minst tre och notera resultatet som ett spann, inte som ett tal.
5. Vill du ha ett siffermått finns llama.cpp:s perplexity-verktyg med --kl-divergence-base och --kl-divergence. Räkna med utrymme: dokumentationen anger att logitfilen från f16-modellen blir mycket stor — 11 GiB för LLaMA 2 och 37 GiB för LLaMA 3 med Wikitext-2. Verktyget mäter dessutom likheten mot f16-modellen, inte om svaren duger för din uppgift.

Så redovisar du dina egna mätningar

Ett prov som inte går att upprepa är en åsikt. Skriv därför alltid ned exakt variantnamn eller digest, runtime och version, hårdvara, kontextlängd och antal körningar tillsammans med resultatet, och redovisa uppmätta värden som spann över körningarna. Blanda aldrig ihop tre olika saker: källans uppgift om filstorlek, en estimators planeringsvärde och din egen mätning. Håller du dem isär har du något konkret att undersöka när de avviker — annars har du bara en siffra utan känt ursprung. Behöver du bakgrund om vilket verktyg som visar vad står jämförelsen i Ollama eller LM Studio.

Beslutsregeln blir enkel när underlaget finns: välj den lägsta kvantisering som klarar dina bedömningsregler med marginal, och lägg de gigabyte du sparar på kontext, samtidighet eller en större modell i stället. Klarar Q4 uppgiften är steget till Q8 inte en kvalitetsförbättring du behöver betala för. Klarar den inte, är nästa steg upp oftast billigare än en helt annan modell.

Källor

• llama.cpp — llama-quantize, bitar per vikt och storlek per kvantiseringstyp samt varningen för omkvantisering
• llama.cpp — perplexity, KL-divergens och resultattavlan för LLaMA 3 8B
• Hugging Face — GGUF-formatet och kvantiseringstypernas blockstruktur och bitar per vikt
• Ollama — Llama 3.1, storlek per kvantiseringstagg för 8B och 70B
• Ollama — Qwen 3, storlek per kvantiseringstagg
• LM Studio — val av nedladdningsvariant och rekommendationen om fyra bitar eller högre
• Ollama — kommandoreferens för ollama list och ollama ps

Källorna kontrollerades 19 augusti 2026. Bitdjup, filstorlekar och resultattavlor är versionskänsliga och ändras när modellfilerna eller llama.cpp byggs om. Nästa kontroll sker när någon av källsidorna ändras eller senast 19 september 2026.