LLM-kvantisering: 7 metoder sammenlignet (med benchmark-tallene)

LLM-kvantisering: 7 metoder sammenlignet (med benchmark-tallene)

Llama 3.3 70B i FP16 trenger 140 GB bare til vekter. To H100-er. Med Q4_K_M får den samme modellen plass på rundt 42 GB, altså ett brukt RTX A6000 fra eBay. Det gapet er hele grunnen til at LLM-kvantisering finnes, og velger du feil metode, betaler du enten med kvalitet du kan se eller VRAM du ikke har.

Denne guiden til LLM-kvantisering sammenligner de 7 metodene som betyr noe i 2026, med hvert tall sporet tilbake til en publisert kilde.

Nøkkelpunkter

• Kvantisering bytter minne og båndbredde mot et målbart, vanligvis lite, kvalitetstap.
• GPTQ og AWQ er GPU-først; GGUF er formatet som også kjører på CPU.
• Q4_K_M lander nær 4,8 bits per vekt, ikke 4. Navnet skjuler ekstrautgiftene.
• 6-biters kvantisering ligger innenfor ~0,1 % av FP16-perplexity ifølge llama.cpp k-quants-PR-en.

Hva gjør egentlig LLM-kvantisering med modellen din?

LLM-kvantisering lagrer modellvekter med lavere numerisk presisjon, og krymper minne og båndbredde mot avrundingsfeil. En modell på 70B parametre går fra 140 GB i FP16 ned til rundt 42 GB med 4-bit. Intelligensen blir værende; desimalene forsvinner. Hver metode i denne guiden er en variant av det byttet.

Presisjonsstigen går fra FP32 (32 bits) ned gjennom FP16 og BF16 (16 bits hver), så INT8, så INT4. Hvert trinn halverer antall bytes per parameter. IEEE 754-standarden definerer flyttallsformatene; Mark Horowitz' artikkel fra 2014, "Computing's Energy Problem", viste hvorfor det er flyttingen av disse bytene, ikke regneoperasjonene på dem, som dominerer energikostnaden. Det er den fysiske grunnen til at kvantisering gjør inferens raskere.

To parametre får kvantisering til å virke: en skaleringsfaktor (en multiplikator som mapper heltallsområdet tilbake til reelle verdier) og et nullpunkt (heltallet som representerer 0,0). Symmetrisk kvantisering sentrerer området rundt null og hopper over nullpunktet; asymmetrisk kvantisering forskyver det for å bruke hele heltallsområdet når vektene hoper seg opp borte fra null.

Vekter lar seg kvantisere rent fordi de er statiske og normalfordelte. Det gjør ikke aktiveringer. Aktiveringer som er uteliggere, av og til 100x medianen, blåser opp avrundingsfeilen hvis du kvantiserer dem naivt. Den asymmetrien er grunnen til at de fleste metodene her bare kvantiserer vekter (W4A16) og lar aktiveringene bli stående i FP16.

Etter-trening-kvantisering (PTQ) konverterer en ferdig modell etter trening. Kvantiseringsbevisst trening (QAT) simulerer avrunding under treningen slik at modellen tilpasser seg. Alt i denne artikkelen er PTQ. QAT krever mer regnekraft og en treningskjøring; det er en egen beslutning.

INT4- og NF4-radene er teoretisk ren 4-bit: 4 bits per vekt og ingenting annet. Ekte 4-biters formater bærer blokkskalaer og minimumsverdier på toppen, så de lander høyere. En 70B-modell med Q4_K_M er rundt 42 GB, ikke 35. VRAM-tabellen lenger ned bruker de effektive ratene i stedet.

Kvantisering krymper ikke intelligensen til modellen. Den krymper antall desimaler modellen lagrer den intelligensen i. Og hvis du betaler per token for API-inferens, starter det å kutte LLM-API-regningen ofte med å kjøre en kvantisert modell selv.

De 7 kvantiseringsmetodene, side om side

De sju metodene nedenfor dekker alle produksjonsveier for å kvantisere en LLM i 2026. To er kun GPU (GPTQ, AWQ), én kjører overalt (GGUF), én kvantiserer ved lasting (BitsandBytes), to sikter mot høy gjennomstrømming (SmoothQuant, FP8), og én er PyTorch-native (TorchAO). Det riktige valget avhenger av maskinvaren din, ikke av hvilken metode som scorer høyest på en ledertavle.

GPTQ kvantiserer lag for lag ved å bruke den inverse hessiske matrisen til å omfordele avrundingsfeil over gjenværende vekter. Den trenger et kalibreringssett og en GPU. GPTQ-artikkelen rapporterer kvantisering av en 175B-modell til 3-4 bits på rundt 4 GPU-timer.

AWQ identifiserer de ~1 % av vektene som betyr mest (saliente vekter, funnet fra aktiveringsstyrker) og skalerer dem for å beskytte dem mot avrunding. AWQ-artikkelen (beste artikkel på MLSys 2024) rapporterer mer enn 3x hastighetsløft over HuggingFace sin FP16-implementasjon på både stasjonære og mobile GPU-er.

GGUF er et filformat, ikke en algoritme. Algoritmen inni er k-quant-blokkskjemaet fra llama.cpp PR #1684. Det er den eneste metoden her som kjører på CPU, noe som gjør den til standardvalget for lokal inferens. Se modeller med åpne vekter som er verdt å kvantisere for hva du skal mate den med.

BitsandBytes kvantiserer ved lasting i stedet for på forhånd. NF4 (4-bit NormalFloat) er signaturformatet, og det er ryggraden i QLoRA-finjustering. Ikke noe kalibreringssett nødvendig.

SmoothQuant flytter aktiveringsuteliggere over i vektene slik at begge kan kjøre med INT8. Artikkelen rapporterer opptil 1,56x hastighetsløft og 2x minnereduksjon, og sikter mot gjennomstrømming på servering med store batcher, der W4A16-metoder lar ytelse ligge igjen.

FP8 (W8A8) er den native veien på H100- og B200-GPU-er. Nær tapsfri ved 8-bit, ingen kalibreringshodepine, og vLLM støtter det direkte.

TorchAO er PyTorch sitt eget kvantiseringsbibliotek, bygget for å virke med torch.compile. Hvis pipelinen din allerede er PyTorch, er det veien med minst motstand.

Det finnes bare to reelle spørsmål: kan maskinvaren din kjøre den, og kan du leve med kvaliteten den koster?

Hva viser egentlig de publiserte benchmarkene?

Publiserte benchmarker sier at 4-biters kvantisering koster 1-2 % perplexity på en 7B-modell, og at 6-bit koster under 0,1 %. De tallene kommer fra llama.cpp PR #1684 (2023), målt av llama.cpp-vedlikeholderne på én enkelt 7B-modell på en RTX 4080. De er de mest siterte tallene i kvantiseringsverdenen, og de er reelle. De er også n = 1.

Kilde: llama.cpp PR #1684 (2023). 7B-modell, RTX 4080, målt av llama.cpp-vedlikeholderne. n = 1 modell.

En merknad om den bits/vekt-kolonnen: dette er de nominelle ratene for den grunnleggende k-quant-typen, og _K-miksene hever den effektive raten. Q2_K er et godt eksempel. Kjør artikkelens egen formel på den nominelle 2,5625 og en modell på 6,74B parametre, og du får ~2,0 GB, men raden rapporterer en fil på 2,67 GB, som regnet baklengs gir ~3,4 bits per vekt. Resten av denne artikkelen bruker de effektive ratene, utledet fra disse filstørrelsene.

Tallene for GPU-metodene kommer direkte fra artiklene. GPTQ rapporterer ende-til-ende hastighetsløft for inferens over FP16 på rundt 3,25x på en A100 og ~4,5x på en A6000, med en 175B-modell kvantisert til 3-4 bits på rundt 4 GPU-timer. AWQ rapporterer «mer enn 3x hastighetsløft over Huggingface sin FP16-implementasjon på både stasjonære og mobile GPU-er», pluss den første 70B Llama-2-utrullingen på en mobil GPU via TinyChat. Vi siterer artikkelens ordlyd i stedet for å parafrasere et tall til falsk presisjon.

Det originale bidraget her er aritmetikk. Minne for vekter følger: vekter (GB) ≈ parametre (B) × bits per vekt ÷ 8. Haken er hvilket bits-per-vekt-tall du mater den med. PR #1684 publiserer raten for den grunnleggende k-quant-typen (Q4_K = 4.5), og _S/_M/_L-miksene ligger over den grunnraten fordi de gir ekstra bits til oppmerksomhets- og feed-forward-tensorene. Så vi utledet de effektive ratene fra filstørrelsene PR-en selv publiserer, på en 7B-modell som egentlig er 6,74B parametre: Q2_K på 2,67 GB regnet baklengs gir ~3,4 bpw, Q4_K_S på 3,56 GB ~4,5, Q6_K på 5,15 GB ~6,6. Q4_K_M lander nær 4,8.

Det endrer hovedtallet. En 70B-modell med Q4_K_M: 70 × 4.8 ÷ 8 = 42 GB. De fleste artikler sier 35 GB. De bruker 4,0 bpw og hopper fullstendig over blokkskala-ekstrautgiftene. Kryssjekken tar ett klikk: Llama-3.3-70B-Instruct-Q4_K_M.gguf leveres på 42,5 GB på HuggingFace, likt i bartowski-, lmstudio-community- og second-state-repoene. Vi regnet om hver celle i VRAM-tabellen nedenfor på det grunnlaget.

Vår lesning av disse tallene: perplexity-gapet mellom Q6_K (5.9110) og F16 (5.9066) er 0.0044, som er mindre enn gapet mellom to ulike finjusteringer av den samme basismodellen. Derfor er «bare bruk Q4_K_M eller Q5_K_M» rådet som overlever møte med reell maskinvare. ms/token-kolonnen viser også at Q2_K ikke kjøper noen hastighet over Q4_K_S (begge 15.5 ms/token) mens det koster 0,75 perplexity. Q2_K er det dårligste byttet i tabellen.

Hva tallene ikke forteller deg: wikitext-perplexity er ikke det samme som kvalitet på dine egne prompter. Én modell på én GPU er n = 1. Hastighetstall er avhengig av batchstørrelse. Behandle disse som retningsgivende, ikke universelle.

Seks-biters kvantisering lander innenfor rundt 0,1 % av fullpresisjonsmodellens perplexity. Kompresjonen er nesten gratis på det nivået.

GPTQ mot AWQ: valg mellom de to GPU-metodene

GPTQ og AWQ produserer begge 4-biters GPU-sjekkpunkter fra et kalibreringssett, og begge er godt støttet i vLLM. Forskjellen er hvordan de håndterer avrundingsfeil. GPTQ omfordeler den over gjenværende vekter med den inverse hessiske matrisen. AWQ beskytter de 1 % av vektene som aktiveringer markerer som viktige. Begge virker. Valget handler om serveringsmønsteret ditt.

GPTQ jobber lag for lag. For hvert lag kvantiserer den én vekt om gangen, så justerer den de gjenværende vektene i det laget for å kompensere for avrundingen den nettopp gjorde. Justeringen bruker andreordens informasjon fra den hessiske matrisen, og det er grunnen til at den trenger et kalibreringssett for å beregnes. Resultatet er sterkt for batch-inferens der gjennomstrømming betyr mer enn latens per token.

AWQ tar en annen vinkel. Den identifiserer saliente vekter ved å se på aktiveringsstyrker på tvers av kalibreringssettet, omtrent den øverste 1 % av kanalene. De vektene får en per-kanal skaleringsfaktor som holder dem i et høyere presisjonsområde under avrunding. Kalibreringssettet kan være mindre enn GPTQ sitt, og AWQ overtilpasser seg det mindre fordi den beskytter strukturelle trekk heller enn å tilpasse seg spesifikke input. Artikkelen rapporterer sterke resultater på latenssensitiv servering.

Velg GPTQ hvis: du kjører batch-inferens på en GPU, du har et godt kalibreringssett som matcher domenet ditt, og gjennomstrømming er målet.

Velg AWQ hvis: du serverer enkeltbrukerforespørsler med lav latens, du vil ha et mindre kalibreringssett, eller du ruller ut på edge-/mobile 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å velger mellom serveringsmotorer, dekker vLLM mot SGLang den beslutningen separat.

GGUF og K-Quants: hva Q4_K_M egentlig betyr

GGUF er et filformat, ikke en kvantiseringsalgoritme. GGUF-spesifikasjonen definerer en container for modellvekter, metadata og tokenizer-data. Kvantiseringalgoritmen inni en GGUF-fil er k-quant- (eller i-quant-) blokskjemaet fra llama.cpp PR #1684. Å forveksle containeren med algoritmen er den vanligste feilen på dette feltet, og den fører til spørsmål som «hva er best, GGUF eller GPTQ?» som ikke helt gir mening.

Navneskjemaet dekodes slik. Q betyr k-quant-blokkskjema; IQ betyr importance-matrix i-quant (en nyere variant som bruker en importance-matrise for bedre kvalitet ved samme bitdybde). Tallet er den nominelle bitdybden. _K markerer k-quant-familien mot eldre formater som Q4_0. _S, _M, _L styrer hvilke tensorgrupper som får ekstra bits: small, medium, large. Høyere suffiks betyr flere bits tildelt oppmerksomhets- og feed-forward-tensorene som betyr mest.

Effektive rater, regnet baklengs fra 7B- (6,74B-parametre) filstørrelsene publisert i PR #1684, ikke grunn-typens tall. Legacy-radene er eksakte ved konstruksjon: en Q4_0-blokk er 32 vekter på 4 bits pluss én FP16-skala, som er 4,5 bits per vekt, og Q8_0 er 32 vekter på 8 bits pluss en FP16-skala, som er 8,5. PR-en bekrefter det, og lister 7B-filene Q4_0 og Q4_K_S til samme 3,56 GB.

Q4_K_M er ikke 4 bits per vekt. Det er rundt 4,8. Blokkskalaene og minimumsverdiene må bo et sted, og _M-miksen bruker så ekstra bits på oppmerksomhets- og feed-forward-tensorene, som er nøyaktig hvorfor Q4_K_M ligger over Q4_K_S og Q3_K_M ligger over Q3_K_S i stedet for å matche den.

Hvorfor GGUF kjører der GPTQ ikke kan: den støtter CPU-inferens og lag-offloading mellom GPU-VRAM og system-RAM. En 32B-modell som ikke får plass i sin helhet på GPU-en din, kan kjøre med halvparten av lagene offloadet, sakte men funksjonelt. GPTQ har ingen CPU-vei.

# 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 på lokale modeller? Start med å få din første lokale modell i gang før du kvantiserer noe. Og hvis du vil ha et nettleser-UI, tar Open WebUI oppå Ollama rundt ti minutter. HuggingFace sin GGUF-dokumentasjon forklarer hvordan Hub-en viser navngiving av quant-typer.

BitsandBytes, Marlin, SmoothQuant og TorchAO

Disse fire dekker de gjenværende produksjonsveiene. Ingen er en «bedre GPTQ». De løser ulike problemer.

BitsandBytes kvantiserer ved lasting, ikke på forhånd. Du peker den mot et FP16-sjekkpunkt, og den konverterer fortløpende til NF4 eller FP4. Ikke noe kalibreringssett, ikke noe offline-steg. Det den er mest kjent for, er QLoRA: en 4-biters frosset basismodell med LoRA-adaptere trent oppå, som gjør finjustering av en 65B-modell på én GPU mulig med 48 GB VRAM. QLoRA er en treningsteknikk, ikke en inferensteknikk, men det er grunnen til at de fleste møter BitsandBytes først.

Marlin er ikke en kvantiseringsmetode. Det er en INT4xFP16 mixed-precision GEMM-kjerne som gjør eksisterende 4-biters sjekkpunkter raskere ved moderate batchstørrelser. Marlin-artikkelen rapporterer hastighetsløft på A100 og H100. Hvis serveringsstakken din støtter den, slår du den på på en allerede kvantisert modell. Du «kvantiserer ikke med Marlin».

SmoothQuant flytter aktiveringsuteliggere over i vektene via en per-kanal skaleringsfaktor, og gjør W8A8 (både vekter og aktiveringer med INT8) levedyktig. Artikkelen sikter mot servering med store batcher der W4A16-metoder lar gjennomstrømming ligge igjen. Hvis du serverer hundrevis av samtidige forespørsler, er dette trekket.

TorchAO er PyTorch-native kvantisering som virker med torch.compile. Ingen eksterne avhengigheter, ingen formatkonvertering. Hvis inferenspipelinen din allerede er PyTorch, er det alternativet med minst friksjon. For å kjøre embedding-modeller lokalt er Ollama-veien vanligvis enklere, men TorchAO passer egendefinerte PyTorch-stakker.

Hvor mye VRAM trenger en kvantisert modell?

Formelen er vekter (GB) ≈ parametre (B) × bits per vekt ÷ 8. En 70B-modell med Q4_K_M: 70 × 4.8 ÷ 8 = 42.0 GB. Ratene nedenfor er effektive, regnet baklengs fra filstørrelsene llama.cpp PR #1684 publiserer, i stedet for fra grunn-typens tall, fordi _M-miksene alltid ligger over sin grunnleggende k-quant-rate. Vi regnet om i stedet for å kopiere den vanlige 4,0-bpw-snarveien.

Beregnet fra effektive bits-per-vekt: Q8_0 = 8.5, Q6_K = 6.56, Q5_K_M = 5.7, Q4_K_M = 4.8, Q3_K_M = 3.9. Utledet fra 7B- (6,74B-parametre) filstørrelsene i PR #1684, så kryssjekket mot et publisert 70B-bygg: Llama-3.3-70B-Instruct-Q4_K_M.gguf er 42,5 GB på HuggingFace, mot 42,0 GB beregnet her.

Det ærlige forbeholdet: dette er bare vekter. KV-cache, kontekstlengde og rammeverk-ekstrautgifter kommer på toppen. KV-cachen skalerer med kontekstlengde og batchstørrelse. En økt med 32k kontekst på en 70B-modell kan legge til flere GB. Vekt-tabellen er gulvet, ikke budsjettet. Kontekstvinduet ditt leier også VRAM. For det fulle bildet, se VRAM-krav per modell i detalj.

Hvilken kvantiseringsmetode bør du bruke?

Maskinvaren din avgjør før preferansene dine gjør det. En metode som ikke kjører på GPU-en din, er ikke et valg, det er et ønske. Tabellen nedenfor kobler vanlige oppsett til metoden som faktisk virker for dem, basert på maskinvarebegrensningene og kvalitetsavveiningene dekket over.

For de fleste lesere på forbrukermaskinvare er en ferdig kvantisert Q4_K_M- eller Q5_K_M-GGUF det riktige svaret. Hent den fra HuggingFace, kjør den i Ollama eller llama.cpp, og slutt å optimalisere. Kvalitetsforskjellen mellom Q4_K_M og Q5_K_M er liten nok til at du bør velge ut fra om filen får plass, ikke ut fra en perplexity-tabell. Alt utover det er optimalisering for sin egen skyld, og det er bare verdt å gjøre når du har bekreftet at modellen faktisk løser problemet ditt med Q4.

Guiden til verktøyene som faktisk kjører disse modellene lokalt dekker serveringssiden når du har valgt et quant-nivå.

Fem måter kvantisering går galt på

Kvantiseringsfeil er nesten alltid konfigurasjonsproblemer, ikke metodeproblemer. Disse fem dukker opp hele tiden.

1. Kalibreringssettet matcher ikke domenet ditt. GPTQ og AWQ tilpasser seg begge til kalibreringsdataene. Hvis du kalibrerer på Wikipedia og ruller ut på medisinske transkripsjoner, presterer den kvantiserte modellen dårligere på tokenene den aldri så. Løsning: bruk et kalibreringssett hentet fra din faktiske input-distribusjon, selv 128 prøver hjelper.

2. Gruppestørrelse satt for høy. GPTQ sin gruppestørrelse styrer hvor mange vekter som deler en skaleringsfaktor. 128 er standarden. 256 eller 512 sparer regnekraft under kvantisering, men treffer en kvalitetsvegg på mindre modeller. Løsning: bli på 128 med mindre du har bekreftet at kvaliteten holder på dine prompter.

3. Forvente at Q2_K er brukbar. Ifølge PR #1684-dataene koster Q2_K ~0,87 perplexity mot F16 og kjøper ingen hastighet over Q4_K_S (begge 15.5 ms/token på 7B-benchmarken). Du får en mindre fil og dårligere output uten noen latensgevinst. Løsning: Q4_K_S er gulvet med mindre filstørrelse er en hard begrensning.

4. Benchmarke på wikitext-perplexity i stedet for dine egne prompter. Perplexity er en språkmodelleringsmetrikk. Den måler ikke om modellen følger systemprompten din, formaterer JSON korrekt, eller håndterer domeneordforrådet ditt. Løsning: kjør 20-30 av dine reelle prompter gjennom både den kvantiserte og den ukvantiserte modellen og sammenlign output.

5. Forveksle GGUF-containeren med kvantiseringsalgoritmen inni den. Dette fører til å sammenligne «GGUF mot GPTQ» som om de er samme kategori. Det er de ikke. GGUF er et filformat. K-quant-skjemaet inni er algoritmen. Løsning: sammenlign k-quant-nivåer (Q4_K_M mot Q5_K_M), ikke filformater.

Ofte stilte spørsmål

Hva er LLM-kvantisering?

LLM-kvantisering reduserer den numeriske presisjonen til en modells vekter, typisk fra 16-biters flyttall til 4-biters eller 8-biters heltall. Dette kutter minnebruken og gjør inferens raskere ved å redusere båndbredden. En 70B-modell går fra 140 GB ned til rundt 42 GB med 4-bit. Kvalitetskostnaden er vanligvis 1-2 % perplexity ved 4-bit, mindre ved 6-bit.

Reduserer kvantisering nøyaktigheten til en modell?

Ja, men mindre enn de fleste forventer. Ifølge llama.cpp PR #1684-benchmarkene koster Q4_K_S på en 7B-modell rundt 2 % perplexity mot F16, og Q6_K koster under 0,1 %. Den praktiske påvirkningen på reelle prompter er ofte mindre enn perplexity-tallet antyder, spesielt med Q4_K_M og over.

Er GPTQ eller AWQ best?

Ingen er universelt best. GPTQ bruker invers-hessisk feilomfordeling og passer batch-GPU-inferens. AWQ beskytter saliente vekter via aktiveringsbevisst skalering og passer latenssensitiv servering. AWQ trenger et mindre kalibreringssett og overtilpasser seg det mindre. Hvis du serverer enkeltbrukerforespørsler med lav latens, start med AWQ.

Hva betyr Q4_K_M?

Q4_K_M er et k-quant GGUF-kvantiseringsnivå. «Q4» betyr nominell 4-biters dybde, «K» markerer k-quant-blokkskjemaet (mot eldre Q4_0), og «M» betyr medium: oppmerksomhets- og feed-forward-tensorer får ekstra bits. Effektive bits per vekt er rundt 4,8, ikke 4,0, fordi blokkskalaer og minimumsverdier legger til ekstrautgifter og medium-miksen bruker mer på toppen.

Kan jeg kjøre en kvantisert modell på en CPU?

Ja, men bare via GGUF. GPTQ og AWQ er rene GPU-formater. GGUF sine k-quant-modeller kjører på CPU gjennom llama.cpp eller Ollama, og støtter lag-offloading mellom GPU-VRAM og system-RAM. Q4_K_M er standard CPU-quant. Forvent tregere tokengenerering enn GPU, men funksjonell inferens.

Hva er forskjellen mellom GGUF og GGML?

GGML er det eldre tensorbiblioteket og filformatet som llama.cpp opprinnelig brukte. GGUF erstattet det i august 2023 som et mer fleksibelt containerformat med bedre metadatastøtte. GGUF-filer er det du laster ned fra HuggingFace i dag. GGML-filer er legacy og distribueres sjelden lenger.

Bør jeg kvantisere en modell selv eller laste ned en ferdig kvantisert?

Last ned en ferdig kvantisert først. llama.cpp- og HuggingFace-fellesskapene har allerede kvantisert de fleste populære modeller på alle nivåer. Å kvantisere selv gir bare mening hvis du trenger et spesifikt kalibreringssett for domenet ditt, eller hvis det ikke finnes noen ferdig kvantisert versjon for modellen din.

Når bør jeg bruke kvantisering i stedet for en mindre modell?

Bruk kvantisering når du trenger kapasiteten til den større modellen men ikke får plass til den i minnet. En kvantisert 70B-modell presterer generelt bedre enn en ukvantisert 13B-modell på komplekse resonnementoppgaver. Bruk en mindre modell i stedet når latens er begrensningen, siden mindre modeller genererer tokener raskere uavhengig av kvantisering.

Hva er forskjellen mellom kvantisering og distillering?

Kvantisering reduserer den numeriske presisjonen til en eksisterende modells vekter. Distillering trener en mindre modell til å etterligne en større, og produserer en genuint annen (mindre) arkitektur. Kvantisering bevarer den originale modellens arkitektur og er reversibel i prinsippet. Distillering lager en ny modell og krever en treningskjøring.

Den korte versjonen: kvantisering er hvordan du får en modell du vil ha til å passe i maskinvaren du har. For de fleste på forbruker-GPU-er eller Apple Silicon er en ferdig kvantisert Q4_K_M-GGUF hentet fra HuggingFace hele løsningen. GPTQ og AWQ er svarene for GPU-servering. FP8 og SmoothQuant er svarene for produksjonsgjennomstrømming. Alt annet er optimalisering etter at du har bekreftet at modellen virker.

Hvis du bestemmer hva du skal selve-hoste og vil ha en andremening om maskinvare-metode-koblingen, snakker vi gjerne med deg.