Guide til LLM-kvantisering: 7 metoder sammenlignet (med benchmark-tal)

Guide til LLM-kvantisering: 7 metoder sammenlignet (med benchmark-tal)

Llama 3.3 70B i FP16 kræver 140 GB bare til vægtene. To H100ere. Med Q4_K_M fylder den samme model cirka 42 GB, hvilket svarer til én brugt RTX A6000 fra eBay. Det gab er hele grunden til, at LLM-kvantisering findes, og vælger du den forkerte metode, koster det dig enten kvalitet, du kan se, eller VRAM, du ikke har.

Denne guide til LLM-kvantisering sammenligner de 7 metoder, der betyder noget i 2026, hvor hvert tal er ført tilbage til en publiceret kilde.

Vigtigste pointer

• Kvantisering bytter hukommelse og båndbredde for et målbart, som regel lille, kvalitetstab.
• GPTQ og AWQ er GPU-først; GGUF er formatet, der også kører på CPU.
• Q4_K_M lander på cirka 4,8 bit pr. vægt, ikke 4. Navngivningen skjuler overheaden.
• 6-bit-kvantisering holder sig inden for ~0,1 % af FP16-perplexiteten ifølge llama.cpp k-quants-PR'en.

Hvad gør LLM-kvantisering egentlig ved din model?

LLM-kvantisering gemmer modelvægte med lavere numerisk præcision og skærer hukommelse og båndbredde ned mod en afrundingsfejl som pris. En 70B-parameter-model falder fra 140 GB i FP16 til cirka 42 GB ved 4-bit. Intelligensen bliver; decimalerne forsvinder. Hver metode i denne guide er en variant af det bytte.

Præcisionsstigen løber fra FP32 (32 bit) ned gennem FP16 og BF16 (16 bit hver), så INT8, så INT4. Hvert trin halverer antallet af bytes pr. parameter. IEEE 754-standarden definerer flydetalsformaterne; Mark Horowitz' paper fra 2014, "Computing's Energy Problem", viste, hvorfor det er flytningen af de bytes, ikke beregningerne på dem, der dominerer energiforbruget. Det er den fysiske grund til, at kvantisering gør inferens hurtigere.

To parametre får kvantisering til at virke: en skaleringsfaktor (en multiplikator, der mapper heltalsintervallet tilbage til reelle værdier) og et nulpunkt (det heltal, der repræsenterer 0,0). Symmetrisk kvantisering centrerer intervallet om nul og dropper nulpunktet; asymmetrisk kvantisering forskubber det for at bruge hele heltalsintervallet, når vægtene ligger forskudt fra nul.

Vægte kvantiserer rent, fordi de er statiske og normalfordelte. Det er aktiveringer ikke. Outlier-aktiveringer, nogle gange 100x medianen, sprænger afrundingsfejlen, hvis du kvantiserer dem naivt. Den asymmetri er grunden til, at de fleste metoder her kun kvantiserer vægte (W4A16) og lader aktiveringerne blive i FP16.

Kvantisering efter træning (PTQ) konverterer en færdig model efter træningen. Kvantiseringsbevidst træning (QAT) simulerer afrunding under træningen, så modellen tilpasser sig. Alt i dette indlæg er PTQ. QAT koster flere beregninger og en træningskørsel; det er en separat beslutning.

INT4- og NF4-rækkerne er teoretisk ren 4-bit: 4 bit pr. vægt og intet andet. Reelle 4-bit-formater bærer blokskaleringer og minima oveni, så de lander højere. En 70B-model med Q4_K_M er cirka 42 GB, ikke 35. VRAM-tabellen længere nede bruger de effektive rater i stedet.

Kvantisering skrumper ikke modellens intelligens. Den skrumper antallet af decimaler, som intelligensen gemmes i. Og hvis du betaler pr. token for API-inferens, begynder sænkningen af din LLM-API-regning ofte med selv at køre en kvantiseret model.

De 7 kvantiseringsmetoder side om side

De syv metoder nedenfor dækker alle produktionsveje for kvantisering af en LLM i 2026. To er kun til GPU (GPTQ, AWQ), én kører overalt (GGUF), én kvantiserer ved indlæsning (BitsandBytes), to sigter mod serving med høj throughput (SmoothQuant, FP8), og én er PyTorch-native (TorchAO). Det rigtige valg afhænger af din hardware, ikke af hvilken metode der scorer højest på en rangliste.

GPTQ kvantiserer lag for lag med den inverse Hessian-matrix til at omfordele afrundingsfejl på tværs af de resterende vægte. Den kræver et kalibreringssæt og en GPU. GPTQ-artiklen rapporterer kvantisering af en 175B-model til 3-4 bit på cirka 4 GPU-timer.

AWQ identificerer de cirka 1 % af vægtene, der betyder mest (fremtrædende vægte, fundet ud fra aktiveringsstørrelser) og skalerer dem for at beskytte dem mod afrunding. AWQ-artiklen (bedste paper på MLSys 2024) rapporterer mere end 3x hastighedsforbedring over HuggingFaces FP16-implementering på både desktop- og mobil-GPU'er.

GGUF er et filformat, ikke en algoritme. Algoritmen indeni er k-quant-blokskemaet fra llama.cpp PR #1684. Det er den eneste metode her, der kører på CPU, hvilket gør den til standardvalget for lokal inferens. Se open-source-modeller, der er værd at kvantisere for, hvad du skal fodre den med.

BitsandBytes kvantiserer ved indlæsning i stedet for på forhånd. NF4 (4-bit NormalFloat) er dens signaturformat, og det er rygraden i QLoRA-finjustering. Intet kalibreringssæt krævet.

SmoothQuant flytter aktiverings-outliers over i vægtene, så begge kan køre i INT8. Artiklen rapporterer op til 1,56x hastighedsforbedring og 2x hukommelsesreduktion og sigter mod throughput ved serving med store batches, hvor W4A16-metoder efterlader ydelse på bordet.

FP8 (W8A8) er den native vej på H100- og B200-GPU'er. Næsten tabsfri ved 8-bit, ingen kalibreringshovedpine, og vLLM understøtter det direkte.

TorchAO er PyTorchs eget kvantiseringsbibliotek, bygget til at virke med torch.compile. Hvis din pipeline allerede er PyTorch, er det vejen med mindst modstand.

Der er reelt kun to spørgsmål: kan din hardware køre den, og kan du leve med den kvalitet, det koster?

Hvad viser de publicerede benchmarks reelt?

Publicerede benchmarks siger, at 4-bit-kvantisering koster 1-2 % perplexitet på en 7B-model, og at 6-bit koster under 0,1 %. De tal stammer fra llama.cpp PR #1684 (2023), målt af llama.cpp-vedligeholderne på én enkelt 7B-model på en RTX 4080. De er de mest citerede tal i kvantiseringsverdenen, og de er reelle. De er også n = 1.

Kilde: llama.cpp PR #1684 (2023). 7B-model, RTX 4080, målt af llama.cpp-vedligeholderne. n = 1 model.

En note om bit/vægt-kolonnen: det er de nominelle rater for basiskvant-typen, og _K-blandingerne hæver den effektive rate. Q2_K er et eksempel. Kører du indlæggets egen formel på de nominelle 2,5625 og en 6,74B-parameter-model, får du ~2,0 GB, men rækken rapporterer en 2,67 GB-fil, hvilket baglæns giver ~3,4 bit pr. vægt. Resten af dette indlæg bruger de effektive rater, udledt af disse filstørrelser.

GPU-metodernes tal kommer direkte fra artiklerne. GPTQ rapporterer ende-til-ende-inferensforbedringer over FP16 på cirka 3,25x på en A100 og ~4,5x på en A6000, med en 175B-model kvantiseret til 3-4 bit på cirka 4 GPU-timer. AWQ rapporterer "mere end 3x hastighedsforbedring over Huggingfaces FP16-implementering på både desktop- og mobil-GPU'er" plus den første 70B-Llama-2-udrulning på en mobil-GPU via TinyChat. Vi citerer artiklens ordlyd i stedet for at omskrive et tal til falsk præcision.

Det originale bidrag her er et regnestykke. Hukommelse til vægte følger: vægte (GB) ≈ parametre (mia.) × bit pr. vægt ÷ 8. Hagen er, hvilket bit-pr.-vægt-tal du fodrer den med. PR #1684 publicerer raten for basiskvant-typen (Q4_K = 4,5), og _S/_M/_L-blandingerne ligger over den basisrate, fordi de giver ekstra bit til attention- og feed-forward-tensorerne. Så vi udledte de effektive rater fra de filstørrelser, PR'en selv publicerer, på en 7B-model, der reelt er 6,74B parametre: Q2_K på 2,67 GB giver baglæns ~3,4 bpw, Q4_K_S på 3,56 GB ~4,5, Q6_K på 5,15 GB ~6,6. Q4_K_M lander på cirka 4,8.

Det ændrer overskriftstallet. En 70B-model med Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. De fleste indlæg siger 35 GB. De bruger 4,0 bpw og springer blokskalerings-overheaden helt over. Tjekket tager ét klik: Llama-3.3-70B-Instruct-Q4_K_M.gguf fylder 42,5 GB på HuggingFace, i både bartowski-, lmstudio-community- og second-state-repoerne. Vi genberegnede hver celle i VRAM-tabellen nedenfor på det grundlag.

Vores læsning af tallene: perplexitetsgabet mellem Q6_K (5.9110) og F16 (5.9066) er 0,0044, hvilket er mindre end gabet mellem to forskellige finjusteringer af den samme basismodel. Derfor er "brug bare Q4_K_M eller Q5_K_M" det råd, der overlever mødet med rigtig hardware. ms/token-kolonnen viser også, at Q2_K ikke køber hastighed over Q4_K_S (begge 15,5 ms/token), mens den koster 0,75 perplexitet. Q2_K er det dårligste bytte i tabellen.

Hvad tallene ikke fortæller dig: wikitext-perplexitet er ikke det samme som kvalitet på dine prompts. Én model på én GPU er n = 1. Hastighedstal afhænger af batchstørrelsen. Behandl dem som retningsgivende, ikke universelle.

6-bit-kvantisering lander inden for cirka 0,1 % af fuldpræcisionsmodellens perplexitet. Komprimeringen er næsten gratis på det niveau.

GPTQ vs. AWQ: Valget mellem de to GPU-metoder

GPTQ og AWQ producerer begge 4-bit-GPU-checkpoints ud fra et kalibreringssæt, og begge er velunderstøttede i vLLM. Forskellen er, hvordan de håndterer afrundingsfejl. GPTQ omfordeler dem på tværs af de resterende vægte med den inverse Hessian-matrix. AWQ beskytter de 1 % af vægtene, som aktiveringerne markerer som vigtige. Begge virker. Valget handler om dit serving-mønster.

GPTQ arbejder lag for lag. For hvert lag kvantiserer den én vægt ad gangen og justerer derefter de resterende vægte i laget for at kompensere for den afrunding, den netop har lavet. Justeringen bruger andenordensinformation fra Hessian-matricen, og derfor kræver den et kalibreringssæt at beregne. Resultatet er stærkt til batchinferens, hvor throughput betyder mere end latenstid pr. token.

AWQ tager en anden vinkel. Den identificerer fremtrædende vægte ved at kigge på aktiveringsstørrelser på tværs af kalibreringssættet, cirka den øverste 1 % af kanalerne. De vægte får en skaleringsfaktor pr. kanal, der holder dem i et højere præcisionsinterval under afrundingen. Kalibreringssættet kan være mindre end GPTQ's, og AWQ overfitter mindre til det, fordi den beskytter strukturelle træk i stedet for at fitte til specifikke inputs. Artiklen rapporterer stærke resultater ved latensfølsom serving.

Vælg GPTQ, hvis: du kører batchinferens på en GPU, har et godt kalibreringssæt, der matcher dit domæne, og throughput er målet.

Vælg AWQ, hvis: du servicerer enkeltbrugerforespørgsler med lav latenstid, vil have et mindre kalibreringssæt eller udruller på edge-/mobil-GPU'er.

# 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

Hvis du også vælger mellem serving-motorer, dækker vLLM mod SGLang den beslutning separat.

GGUF og K-Quants: Hvad Q4_K_M faktisk betyder

GGUF er et filformat, ikke en kvantiseringsalgoritme. GGUF-specifikationen definerer en container til modelvægte, metadata og tokenizer-data. Kvantiseringsalgoritmen inde i en GGUF-fil er k-quant- (eller i-quant-) blokskemaet fra llama.cpp PR #1684. At forveksle containeren med algoritmen er den mest almindelige fejl i denne verden, og den fører til spørgsmål som "hvad er bedst, GGUF eller GPTQ?", der ikke helt giver mening.

Navngivningen afkodes sådan her. Q betyder k-quant-blokskema; IQ betyder importance-matrix-i-quant (en nyere variant, der bruger en importance-matrix til bedre kvalitet ved samme bitdybde). Tallet er den nominelle bitdybde. _K markerer k-quant-familien over for legacy-formater som Q4_0. _S, _M, _L styrer, hvilke tensorgrupper der får ekstra bit: small, medium, large. Højere suffiks betyder flere bit til attention- og feed-forward-tensorerne, der betyder mest.

Effektive rater, baglæns beregnet ud fra 7B- (6,74B-parameter-) filstørrelserne publiceret i PR #1684, ikke basistypens tal. Legacy-rækkerne er eksakte per konstruktion: en Q4_0-blok er 32 vægte à 4 bit plus én FP16-skalering, hvilket er 4,5 bit pr. vægt, og Q8_0 er 32 vægte à 8 bit plus en FP16-skalering, hvilket er 8,5. PR'en bekræfter det og lister 7B Q4_0- og Q4_K_S-filerne til de samme 3,56 GB.

Q4_K_M er ikke 4 bit pr. vægt. Det er cirka 4,8. Blokskaleringerne og minimaerne skal bo et sted, og _M-blandingen bruger så ekstra bit på attention- og feed-forward-tensorerne, hvilket præcis er grunden til, at Q4_K_M ligger over Q4_K_S, og Q3_K_M ligger over Q3_K_S i stedet for at matche den.

Hvorfor GGUF kører, hvor GPTQ ikke kan: den understøtter CPU-inferens og lag-offload mellem GPU-VRAM og system-RAM. En 32B-model, der ikke kan være helt på din GPU, kan køre med halvdelen af lagene offloadet, langsomt men funktionelt. GPTQ har ingen CPU-vej.

# 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

Ny med lokale modeller? Start med at få din første lokale model i gang, før du kvantiserer noget som helst. Og hvis du vil have en browsergrænseflade, tager Open WebUI oven på Ollama cirka ti minutter. HuggingFaces GGUF-dokumentation forklarer, hvordan Hubben eksponerer navngivningen af kvant-typer.

BitsandBytes, Marlin, SmoothQuant og TorchAO

Disse fire dækker de resterende produktionsveje. Ingen af dem er en "bedre GPTQ". De løser forskellige problemer.

BitsandBytes kvantiserer ved indlæsning, ikke på forhånd. Du peger den mod et FP16-checkpoint, og den konverterer undervejs til NF4 eller FP4. Intet kalibreringssæt, intet offline-trin. Dens primære berømmelse er QLoRA: en 4-bit frossen basismodel med LoRA-adaptere trænet ovenpå, hvilket gør finjustering af en 65B-model på én GPU mulig med 48 GB VRAM. QLoRA er en træningsteknik, ikke en inferensteknik, men det er grunden til, at de fleste møder BitsandBytes først.

Marlin er ikke en kvantiseringsmetode. Det er en INT4xFP16 mixed-precision GEMM-kernel, der gør eksisterende 4-bit-checkpoints hurtigere ved moderate batchstørrelser. Marlin-artiklen rapporterer hastighedsforbedringer på A100 og H100. Hvis din serving-stack understøtter den, aktiverer du den på en allerede kvantiseret model. Man "kvantiserer ikke med Marlin".

SmoothQuant flytter aktiverings-outliers over i vægtene via en skaleringsfaktor pr. kanal og gør W8A8 (både vægte og aktiveringer i INT8) levedygtig. Artiklen sigter mod serving med store batches, hvor W4A16-metoder efterlader throughput på bordet. Servicerer du hundredvis af samtidige forespørgsler, er det trækket.

TorchAO er PyTorch-native kvantisering, der virker med torch.compile. Ingen eksterne afhængigheder, ingen formatkonvertering. Hvis din inferenspipeline allerede er PyTorch, er det muligheden med mindst modstand. For kørsel af embedding-modeller lokalt er Ollama-vejen som regel simplere, men TorchAO passer til brugerdefinerede PyTorch-stacks.

Hvor meget VRAM kræver en kvantiseret model?

Formlen er vægte (GB) ≈ parametre (mia.) × bit pr. vægt ÷ 8. En 70B-model med Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. Raterne nedenfor er effektive, baglæns beregnet ud fra de filstørrelser, llama.cpp PR #1684 publicerer, i stedet for basistypens tal, fordi _M-blandingerne altid ligger over deres basis-k-quant-rate. Vi genberegnede i stedet for at kopiere den sædvanlige 4,0-bpw-genvej.

Beregnet ud fra effektive bit-pr.-vægt-værdier: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Udledt af 7B- (6,74B-parameter-) filstørrelserne i PR #1684 og derefter krydstjekket mod et publiceret 70B-build: Llama-3.3-70B-Instruct-Q4_K_M.gguf er 42,5 GB på HuggingFace mod 42,0 GB forudsagt her.

Det ærlige forbehold: det er kun vægte. KV-cache, kontekstlængde og framework-overhead lægges oveni. KV-cachen skalerer med kontekstlængde og batchstørrelse. En 32k-kontekstsession på en 70B-model kan lægge adskillige GB til. Vægttabellen er gulvet, ikke budgettet. Dit kontekstvindue lejer også VRAM. For det fulde billede, se VRAM-krav pr. model i detaljer.

Hvilken kvantiseringsmetode skal du vælge?

Din hardware bestemmer, før dine præferencer gør. En metode, der ikke kører på din GPU, er ikke et valg, det er et ønske. Tabellen nedenfor kobler almindelige setups til den metode, der faktisk virker for dem, baseret på hardwarebegrænsningerne og kvalitetsafvejningerne ovenfor.

For de fleste læsere på forbrugerhardware er en prækvantiseret Q4_K_M- eller Q5_K_M-GGUF det rigtige svar. Hent den fra HuggingFace, kør den i Ollama eller llama.cpp, og hold op med at optimere. Kvalitetsforskellen mellem Q4_K_M og Q5_K_M er lille nok til, at du bør vælge ud fra, om filen kan være der, ikke ud fra en perplexitetstabel. Alt ud over det er optimering for sin egen skyld, og det er kun værd at gøre, når du har bekræftet, at modellen faktisk løser dit problem med Q4.

Guiden værktøjer, der faktisk kører disse modeller lokalt dækker serving-siden, når du har valgt et kvant-niveau.

Fem måder, kvantisering går galt på

Kvantiseringsfejl er næsten altid konfigurationsproblemer, ikke metodeproblemer. Disse fem dukker op hele tiden.

1. Kalibreringssættet matcher ikke dit domæne. GPTQ og AWQ fitter begge til kalibreringsdataene. Hvis du kalibrerer på Wikipedia og udruller på medicinske transskriptioner, præsterer den kvantiserede model dårligere på de tokens, den aldrig har set. Løsning: brug et kalibreringssæt fra din faktiske inputfordeling, selv 128 samples hjælper.

2. Gruppestørrelsen er sat for højt. GPTQ's gruppestørrelse styrer, hvor mange vægte der deler en skaleringsfaktor. 128 er standarden. 256 eller 512 sparer beregninger under kvantiseringen, men rammer en kvalitetsmur på mindre modeller. Løsning: bliv på 128, medmindre du har bekræftet, at kvaliteten holder på dine prompts.

3. At forvente, at Q2_K er brugbar. Ifølge PR #1684-dataene koster Q2_K ~0,87 perplexitet mod F16 og køber ingen hastighed over Q4_K_S (begge 15,5 ms/token på 7B-benchmarken). Du får en mindre fil og dårligere output uden nogen latensgevinst. Løsning: Q4_K_S er gulvet, medmindre filstørrelse er en hård begrænsning.

4. At benchmarke på wikitext-perplexitet i stedet for dine egne prompts. Perplexitet er en sproglmodelmetrik. Den måler ikke, om modellen følger din systemprompt, formaterer JSON korrekt eller håndterer dit domænes ordforråd. Løsning: kør 20-30 af dine rigtige prompts gennem både den kvantiserede og den ukvantiserede model, og sammenlign output.

5. At forveksle GGUF-containeren med kvantiseringsalgoritmen indeni. Det fører til at sammenligne "GGUF vs. GPTQ", som om de var samme kategori. Det er de ikke. GGUF er et filformat. K-quant-skemaet indeni er algoritmen. Løsning: sammenlign k-quant-niveauer (Q4_K_M vs. Q5_K_M), ikke filformater.

Ofte stillede spørgsmål

Hvad er LLM-kvantisering?

LLM-kvantisering reducerer den numeriske præcision af en models vægte, typisk fra 16-bit flydende tal til 4-bit eller 8-bit heltal. Det skærer hukommelsesforbruget ned og gør inferens hurtigere ved at reducere båndbredden. En 70B-model falder fra 140 GB til cirka 42 GB ved 4-bit. Kvalitetsprisen er som regel 1-2 % perplexitet ved 4-bit, mindre ved 6-bit.

Reducerer kvantisering en models nøjagtighed?

Ja, men mindre end de fleste forventer. Ifølge llama.cpp PR #1684-benchmarks koster Q4_K_S på en 7B-model cirka 2 % perplexitet mod F16, og Q6_K koster under 0,1 %. Den praktiske betydning på rigtige prompts er ofte mindre, end perplexitetstallet antyder, især ved Q4_K_M og opefter.

Er GPTQ eller AWQ bedst?

Ingen af dem er universelt bedst. GPTQ bruger invers-Hessian-fejlomfordeling og passer til batch-GPU-inferens. AWQ beskytter fremtrædende vægte via aktiveringsbevidst skalering og passer til latensfølsom serving. AWQ kræver et mindre kalibreringssæt og overfitter mindre til det. Servicerer du enkeltbrugerforespørgsler med lav latenstid, så start med AWQ.

Hvad betyder Q4_K_M?

Q4_K_M er et k-quant GGUF-kvantiseringsniveau. "Q4" betyder nominel 4-bit-dybde, "K" markerer k-quant-blokskemaet (modsat legacy Q4_0), og "M" betyder medium: attention- og feed-forward-tensorer får ekstra bit. Effektive bit pr. vægt er cirka 4,8, ikke 4,0, fordi blokskaleringer og minima tilføjer overhead, og medium-blandingen bruger mere oveni.

Kan jeg køre en kvantiseret model på en CPU?

Ja, men kun via GGUF. GPTQ og AWQ er kun til GPU. GGUF's k-quant-modeller kører på CPU gennem llama.cpp eller Ollama og understøtter lag-offload mellem GPU-VRAM og system-RAM. Q4_K_M er standardkvanten til CPU. Forvent langsommere tokengenerering end GPU, men funktionel inferens.

Hvad er forskellen mellem GGUF og GGML?

GGML er det ældre tensorbibliotek og filformat, som llama.cpp oprindeligt brugte. GGUF erstattede det i august 2023 som et mere fleksibelt containerformat med bedre metadataunderstøttelse. GGUF-filer er det, du downloader fra HuggingFace i dag. GGML-filer er legacy og distribueres næsten ikke længere.

Skal jeg kvantisere en model selv eller downloade en prækvantiseret?

Download en prækvantiseret først. llama.cpp- og HuggingFace-fællesskaberne har allerede kvantiseret de fleste populære modeller på alle niveauer. Selv at kvantisere giver kun mening, hvis du har brug for et specifikt kalibreringssæt til dit domæne, eller hvis der ikke findes en prækvantiseret version af din model.

Hvornår bør jeg bruge kvantisering i stedet for en mindre model?

Brug kvantisering, når du har brug for den større models evner, men ikke kan have den i hukommelsen. En kvantiseret 70B-model slår generelt en ukvantiseret 13B-model på komplekse ræsonnementsopgaver. Brug en mindre model i stedet, når latenstid er begrænsningen, da mindre modeller genererer tokens hurtigere uanset kvantisering.

Hvad er forskellen mellem kvantisering og distillation?

Kvantisering reducerer den numeriske præcision af en eksisterende models vægte. Distillation træner en mindre model til at efterligne en større og producerer en reelt anderledes (mindre) arkitektur. Kvantisering bevarer den originale models arkitektur og er principielt reversibel. Distillation skaber en ny model og kræver en træningskørsel.

Den korte version: kvantisering er måden, du får den model, du vil have, ind i den hardware, du har. For de fleste på forbruger-GPU'er eller Apple Silicon er en prækvantiseret Q4_K_M-GGUF hentet fra HuggingFace hele løsningen. GPTQ og AWQ er svarene til GPU-serving. FP8 og SmoothQuant er svarene til produktionsthroughput. Alt andet er optimering, efter at du har bekræftet, at modellen virker.

Hvis du beslutter, hvad du selv vil hoste, og vil have en anden vurdering af hardware-metode-kombinationen, tager vi gerne en snak.