LLM-kwantisatiegids: 7 methoden vergeleken (met benchmarkcijfers)

LLM-kwantisatiegids: 7 methoden vergeleken (met benchmarkcijfers)

Llama 3.3 70B in FP16 heeft 140 GB nodig, alleen al voor de gewichten. Twee H100's. Op Q4_K_M past hetzelfde model in ruwweg 42 GB, wat neerkomt op één tweedehands RTX A6000 van Marktplaats. Dat verschil is de hele reden dat LLM-kwantisatie bestaat, en de verkeerde methode kiezen kost je óf zichtbare kwaliteit óf VRAM dat je niet hebt.

Deze LLM-kwantisatiegids vergelijkt de 7 methoden die er in 2026 toe doen, met elk cijfer herleid tot een gepubliceerde bron.

Belangrijkste punten

• Kwantisatie ruilt geheugen en bandbreedte in voor een meetbaar, meestal klein, kwaliteitsverlies.
• GPTQ en AWQ zijn GPU-first; GGUF is het formaat dat ook op CPU draait.
• Q4_K_M komt uit op bijna 4,8 bits per gewicht, niet 4. De naamgeving verbergt de overhead.
• 6-bits kwantisatie zit binnen ~0,1% van de FP16-perplexity volgens de llama.cpp k-quants PR.

Wat doet LLM-kwantisatie eigenlijk met je model?

LLM-kwantisatie slaat modelgewichten op met lagere numerieke precisie, waardoor geheugen en bandbreedte krimpen ten koste van afrondingsfouten. Een 70B-parametermodel zakt van 140 GB op FP16 naar circa 42 GB op 4-bit. De intelligentie blijft; de decimalen verdwijnen. Elke methode in deze gids is een variant op die ruil.

De precisieladder loopt van FP32 (32 bits) via FP16 en BF16 (elk 16 bits) naar INT8 en dan INT4. Elke stap halveert de bytes per parameter. De IEEE 754-standaard definieert de floatformaten; Mark Horowitz' paper uit 2014 "Computing's Energy Problem" liet zien waarom het verplaatsen van die bytes, niet de rekenkundige bewerkingen erop, de energiekosten domineert. Dat is de fysische reden dat kwantisatie inference versnelt.

Twee parameters maken kwantisatie mogelijk: een schaalfactor (vermenigvuldiger die het integerbereik terugkoppelt aan reële waarden) en een nulpunt (het integer dat 0,0 vertegenwoordigt). Symmetrische kwantisatie centreert het bereik op nul en slaat het nulpunt over; asymmetrische kwantisatie verschuift het om het volledige integerbereik te benutten wanneer gewichten zich weg van nul clusteren.

Gewichten kwantiseren schoon omdat ze statisch en normaal verdeeld zijn. Activaties niet. Uitbijteractivaties, soms 100x de mediaan, blazen de afrondingsfout op als je ze naïef kwantiseert. Die asymmetrie is waarom de meeste methoden hier alleen gewichten kwantiseren (W4A16) en activaties in FP16 laten.

Post-training kwantisatie (PTQ) converteert een afgemaakt model na training. Quantization-aware training (QAT) simuleert afronding tijdens training zodat het model zich aanpast. Alles in dit artikel is PTQ. QAT kost meer rekenkracht en een trainingrun; dat is een aparte beslissing.

De INT4- en NF4-rijen zijn theoretisch puur 4-bit: 4 bits per gewicht en niets anders. Echte 4-bitformaten dragen blokschalen en mins bovenop, dus komen ze hoger uit. Een 70B-model op Q4_K_M is circa 42 GB, niet 35. De VRAM-tabel verderop gebruikt de effectieve ratios.

Kwantisatie krimpt niet de intelligentie van het model. Het krimpt het aantal decimalen waarin die intelligentie wordt opgeslagen. En als je per token betaalt voor API-inference, begint je LLM-API-rekening verlagen vaak met het zelf draaien van een gekwantiseerd model.

De 7 kwantisatiemethoden naast elkaar

De zeven methoden hieronder dekken elk productpad voor het kwantiseren van een LLM in 2026. Twee zijn GPU-only (GPTQ, AWQ), één draait overal (GGUF), één kwantiseert bij het laden (BitsandBytes), twee richten zich op high-throughput serving (SmoothQuant, FP8), en één is PyTorch-native (TorchAO). De juiste keuze hangt af van je hardware, niet van welke methode het hoogst scoort op een leaderboard.

GPTQ kwantiseert laag voor laag met de inverse Hessian om afrondingsfouten te herverdelen over de resterende gewichten. Het heeft een kalibratieset en een GPU nodig. De GPTQ-paper rapporteert het kwantiseren van een 175B-model naar 3-4 bits in circa 4 GPU-uren.

AWQ identificeert de ~1% van gewichten die er het meest toe doen (saliente gewichten, gevonden uit activatiegroottes) en schaalt ze om ze tegen afronding te beschermen. De AWQ-paper (MLSys 2024 beste paper) rapporteert meer dan 3x snelheidswinst ten opzichte van de HuggingFace FP16-implementatie op zowel desktop- als mobiele GPU's.

GGUF is een bestandsformaat, geen algoritme. Het algoritme erin is het k-quant blokschema uit llama.cpp PR #1684. Het is de enige methode hier die op CPU draait, wat het de standaard maakt voor lokale inference. Zie open-weight modellen om te kwantiseren voor wat je ermee kunt draaien.

BitsandBytes kwantiseert bij het laden in plaats van vooraf. NF4 (4-bit NormalFloat) is het kenmerkende formaat, en het is de ruggengraat van QLoRA fine-tuning. Geen kalibratieset nodig.

SmoothQuant migreert activatie-uitbijters naar de gewichten zodat beide op INT8 kunnen draaien. De paper rapporteert tot 1,56x snelheidswinst en 2x geheugenreductie, en richt zich op throughput bij large-batch serving waar W4A16-methoden prestaties laten liggen.

FP8 (W8A8) is het native pad op H100- en B200-GPU's. Bijna verliesvrij op 8-bit, geen kalibratiehoofdpijn, en vLLM ondersteunt het direct.

TorchAO is PyTorch's eigen kwantisatiebibliotheek, gebouwd om te werken met torch.compile. Als je pipeline al PyTorch is, is het het pad van de minste weerstand.

Er zijn maar twee echte vragen: draait je hardware het, en kun je leven met de kwaliteit die het kost?

Wat laten de gepubliceerde benchmarks echt zien?

Gepubliceerde benchmarks zeggen dat 4-bit kwantisatie 1-2% perplexity kost op een 7B-model, en 6-bit minder dan 0,1%. Die cijfers komen uit llama.cpp PR #1684 (2023), gemeten door de llama.cpp-beheerders op één enkel 7B-model op een RTX 4080. Het zijn de meest geciteerde cijfers in de kwantisatieruimte, en ze zijn echt. Het zijn ook n = 1.

Bron: llama.cpp PR #1684 (2023). 7B-model, RTX 4080, gemeten door de llama.cpp-beheerders. n = 1 model.

Een opmerking over die bits/gewicht-kolom: dat zijn de nominale ratios voor het basis k-quant type, en de _K-mixen verhogen het effectieve ratio. Q2_K is een goed voorbeeld. Pas de formule uit dit artikel toe op de nominale 2,5625 en een 6,74B-parametermodel en je krijgt ~2,0 GB, maar de rij rapporteert een bestand van 2,67 GB, wat terugrekent naar ~3,4 bits per gewicht. De rest van dit artikel gebruikt de effectieve ratios, afgeleid uit deze bestandsgroottes.

De GPU-methodecijfers komen direct uit de papers. GPTQ rapporteert end-to-end inference-snelheidswinst ten opzichte van FP16 van ruwweg 3,25x op een A100 en ~4,5x op een A6000, met een 175B-model gekwantiseerd naar 3-4 bits in circa 4 GPU-uren. AWQ rapporteert "meer dan 3x snelheidswinst ten opzichte van de Huggingface FP16-implementatie op zowel desktop- als mobiele GPU's", plus de eerste 70B Llama-2-deployment op een mobiele GPU via TinyChat. We citeren de bewoordingen van de paper in plaats van een cijfer tot valse precisie te parafraseren.

De originele bijdrage hier is rekenwerk. Geheugen voor gewichten volgt: gewichten (GB) ≈ params (B) × bits per gewicht ÷ 8. De valkuil is welk bits-per-gewicht-cijfer je erin stopt. PR #1684 publiceert het ratio voor het basis k-quant type (Q4_K = 4,5), en de _S/_M/_L-mixen zitten boven dat basisratio omdat ze extra bits geven aan de attention- en feed-forward-tensors. Dus leidden we de effectieve ratios af uit de bestandsgroottes die de PR zelf publiceert, op een 7B-model dat eigenlijk 6,74B parameters is: Q2_K op 2,67 GB rekent terug naar ~3,4 bpw, Q4_K_S op 3,56 GB naar ~4,5, Q6_K op 5,15 GB naar ~6,6. Q4_K_M komt uit op bijna 4,8.

Dat verandert het kopcijfer. Een 70B-model op Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. De meeste artikelen zeggen 35 GB. Die gebruiken 4,0 bpw en slaan de blokschaal-overhead volledig over. De kruiscontrole kost één klik: Llama-3.3-70B-Instruct-Q4_K_M.gguf scheept op 42,5 GB op HuggingFace, in de bartowski-, lmstudio-community- en second-state-repo's alike. We herberekenden elke cel in de VRAM-tabel hieronder op die basis.

Onze lezing van deze cijfers: het perplexityverschil tussen Q6_K (5.9110) en F16 (5.9066) is 0,0044, wat kleiner is dan het verschil tussen twee verschillende fine-tunes van hetzelfde basismodel. Daarom is "pak gewoon Q4_K_M of Q5_K_M" het advies dat overeind blijft bij echte hardware. De ms/token-kolom laat ook zien dat Q2_K geen snelheidswinst koopt ten opzichte van Q4_K_S (beide 15,5 ms/token) terwijl het 0,75 perplexity kost. Q2_K is de slechtste ruil in de tabel.

Wat de cijfers je niet vertellen: wikitext-perplexity is niet hetzelfde als kwaliteit op jouw prompts. Eén model op één GPU is n = 1. Snelheidscijfers zijn batchgrootte-afhankelijk. Beschouw ze als directioneel, niet universeel.

6-bits kwantisatie komt uit binnen circa 0,1% van de perplexity van het full-precision model. De compressie is op dat niveau bijna gratis.

GPTQ vs AWQ: kiezen tussen de twee GPU-methoden

GPTQ en AWQ produceren allebei 4-bit GPU-checkpoints uit een kalibratieset, en beide worden goed ondersteund in vLLM. Het verschil zit in hoe ze afrondingsfouten behandelen. GPTQ herverdeelt ze over de resterende gewichten met de inverse Hessian. AWQ beschermt de 1% van gewichten die activaties als belangrijk markeren. Beide werken. De keuze gaat over je servingpatroon.

GPTQ werkt laag voor laag. Voor elke laag kwantiseert het één gewicht tegelijk, en past dan de resterende gewichten in die laag aan om de afronding die het net deed te compenseren. De aanpassing gebruikt tweedeorde-informatie uit de Hessian-matrix, waardoor het een kalibratieset nodig heeft om te berekenen. Het resultaat is sterk voor batch-inference waar throughput belangrijker is dan per-token latency.

AWQ pakt het anders aan. Het identificeert saliente gewichten door naar activatiegroottes over de kalibratieset te kijken, ruwweg de bovenste 1% van kanalen. Die gewichten krijgen een per-kanaal schaalfactor die ze in een hogere-precisiebereik houdt tijdens afronding. De kalibratieset kan kleiner zijn dan die van GPTQ, en AWQ overfit er minder op omdat het structurele kenmerken beschermt in plaats van zich aan specifieke inputs te fitten. De paper rapporteert sterke resultaten op latency-gevoelige serving.

Kies GPTQ als: je batch-inference op een GPU doet, je een goede kalibratieset hebt die bij je domein past, en throughput de metriek is.

Kies AWQ als: je single-user verzoeken met lage latency serveert, je een kleinere kalibratieset wilt, of je op edge/mobiele GPU's deployt.

# 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

Als je ook tussen serving-engines kiest, vLLM versus SGLang dekt die beslissing apart.

GGUF en K-Quants: wat Q4_K_M eigenlijk betekent

GGUF is een bestandsformaat, geen kwantisatiealgoritme. De GGUF-specificatie definieert een container voor modelgewichten, metadata en tokenizerdata. Het kwantisatiealgoritme in een GGUF-bestand is het k-quant (of i-quant) blokschema uit llama.cpp PR #1684. De container met het algoritme verwarren is de meest gemaakte fout in deze ruimte, en het leidt tot vragen als "wat is beter, GGUF of GPTQ?" die niet helemaal kloppen.

Het naamgevingsschema decodeert als volgt. Q betekent k-quant blokschema; IQ betekent importance-matrix i-quant (een nieuwere variant die een importance-matrix gebruikt voor betere kwaliteit bij dezelfde bitdiepte). Het getal is de nominale bitdiepte. _K markeert de k-quantfamilie versus legacy-formaten zoals Q4_0. _S, _M, _L sturen welke tensorgroepen extra bits krijgen: small, medium, large. Hoger achtervoegsel betekent meer bits toegewezen aan de attention- en feed-forward-tensors die er het meest toe doen.

Effectieve ratios, terugberekend uit de 7B (6,74B-parameter) bestandsgroottes gepubliceerd in PR #1684, niet de basis-type-cijfers. De legacy-rijen zijn exact per constructie: een Q4_0-blok is 32 gewichten op 4 bits plus één FP16-schaal, wat 4,5 bits per gewicht is, en Q8_0 is 32 gewichten op 8 bits plus een FP16-schaal, wat 8,5 is. De PR bevestigt het en vermeldt de 7B Q4_0- en Q4_K_S-bestanden op dezelfde 3,56 GB.

Q4_K_M is geen 4 bits per gewicht. Het is circa 4,8. De blokschalen en mins moeten ergens wonen, en de _M-mix besteedt dan extra bits aan de attention- en feed-forward-tensors, wat precies is waarom Q4_K_M boven Q4_K_S zit en Q3_K_M boven Q3_K_S in plaats van gelijk te zijn.

Waarom GGUF draait waar GPTQ niet kan: het ondersteunt CPU-inference en laag-offloading tussen GPU-VRAM en systeem-RAM. Een 32B-model dat niet volledig op je GPU past kan draaien met de helft van de lagen geoffload, langzaam maar functioneel. GPTQ heeft geen CPU-pad.

# 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

Nieuw bij lokale modellen? Begin met je eerste lokale model opstarten voordat je iets kwantiseert. En als je een browser-UI wilt, Open WebUI bovenop Ollama kost circa tien minuten. De HuggingFace GGUF-docs leggen uit hoe de Hub kwant-typenaming blootstelt.

BitsandBytes, Marlin, SmoothQuant en TorchAO

Deze vier dekken de resterende productpaden. Geen van alle is een "betere GPTQ." Ze lossen verschillende problemen op.

BitsandBytes kwantiseert bij laadtijd, niet vooraf. Je wijst het naar een FP16-checkpoint en het converteert on the fly naar NF4 of FP4. Geen kalibratieset, geen offline stap. De belangrijkste claim op roem is QLoRA: een 4-bit bevroren basismodel met LoRA-adapters die erop getraind worden, wat single-GPU fine-tuning van een 65B-model mogelijk maakt op 48 GB VRAM. QLoRA is een trainingtechniek, geen inference-techniek, maar het is de reden dat de meeste mensen BitsandBytes als eerste tegenkomen.

Marlin is geen kwantisatiemethode. Het is een INT4xFP16 mixed-precision GEMM-kernel die bestaande 4-bit checkpoints sneller maakt bij gematigde batchgroottes. De Marlin-paper rapporteert snelheidswinst op A100 en H100. Als je serving-stack het ondersteunt, schakel je het in op een al-gekwantiseerd model. Je "kwantiseert niet met Marlin."

SmoothQuant verschuift activatie-uitbijters naar de gewichten via een per-kanaal schaalfactor, waardoor W8A8 (zowel gewichten als activaties op INT8) levensvatbaar wordt. De paper richt zich op large-batch serving waar W4A16-methoden throughput laten liggen. Als je honderden gelijktijdige verzoeken serveert, is dit de zet.

TorchAO is PyTorch-native kwantisatie die werkt met torch.compile. Geen externe afhankelijkheden, geen formaatconversie. Als je inference-pipeline al PyTorch is, is het de optie met de minste wrijving. Voor embeddingmodellen lokaal draaien is het Ollama-pad meestal eenvoudiger, maar TorchAO past bij custom PyTorch-stacks.

Hoeveel VRAM heeft een gekwantiseerd model nodig?

De formule is gewichten (GB) ≈ params (B) × bits per gewicht ÷ 8. Een 70B-model op Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. De ratios hieronder zijn effectieve, terugberekend uit de bestandsgroottes die llama.cpp PR #1684 publiceert in plaats van uit de basis-type-cijfers, omdat de _M-mixen altijd boven hun basis k-quant ratio uitkomen. We herberekenden in plaats van de gebruikelijke 4,0-bpw-snelkoppeling te kopiëren.

Berekend uit effectieve bits-per-gewicht: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Afgeleid uit de 7B (6,74B-parameter) bestandsgroottes in PR #1684, daarna gekruistcontroleerd tegen een gepubliceerde 70B-build: Llama-3.3-70B-Instruct-Q4_K_M.gguf is 42,5 GB op HuggingFace, tegenover 42,0 GB hier voorspeld.

De eerlijke kanttekening: dit is alleen gewichten. KV-cache, contextlengte en framework-overhead komen er bovenop. De KV-cache schaalt met contextlengte en batchgrootte. Een 32k-contextsessie op een 70B-model kan meerdere GB's toevoegen. De gewichtentabel is de vloer, niet het budget. Je contextvenster huurt ook VRAM. Voor het volledige plaatje, zie per-model VRAM-vereisten in detail.

Welke kwantisatiemethode moet je gebruiken?

Je hardware beslist voordat je voorkeuren dat doen. Een methode die niet op je GPU draait is geen keuze, het is een wens. De tabel hieronder koppelt veelvoorkomende setups aan de methode die er daadwerkelijk voor werkt, gebaseerd op de hardwarebeperkingen en kwaliteitsafwegingen die hierboven behandeld zijn.

Voor de meeste lezers op consumentenhardware is een voorgekwantiseerde Q4_K_M of Q5_K_M GGUF het juiste antwoord. Haal het van HuggingFace, draai het in Ollama of llama.cpp, en stop met optimaliseren. Het kwaliteitsverschil tussen Q4_K_M en Q5_K_M is klein genoeg dat je moet kiezen op basis van of het bestand past, niet op basis van een perplexity-tabel. Alles daarbuiten is optimalisatie om de optimalisatie, en het is alleen de moeite waard zodra je bevestigd hebt dat het model je probleem daadwerkelijk oplost op Q4.

De tools die deze modellen echt lokaal draaien-gids dekt de serving-kant zodra je een kwantisatieniveau gekozen hebt.

Vijf manieren waarop kwantisatie misgaat

Kwantisatiefouten zijn bijna altijd configuratieproblemen, geen methodeproblemen. Deze vijf komen constant voor.

1. Kalibratieset past niet bij je domein. GPTQ en AWQ fitten allebei op de kalibratiedata. Als je kalibreert op Wikipedia en deployt op medische transcripties, presteert het gekwantiseerde model slechter op de tokens die het nooit gezien heeft. Oplossing: gebruik een kalibratieset uit je werkelijke inputdistributie, zelfs 128 samples helpen.

2. Group size te groot ingesteld. GPTQ's group size bepaalt hoeveel gewichten een schaalfactor delen. 128 is de standaard. 256 of 512 bespaart rekenkracht tijdens kwantisatie maar raakt een kwaliteitsklif op kleinere modellen. Oplossing: blijf op 128 tenzij je bevestigd hebt dat de kwaliteit overeind blijft op jouw prompts.

3. Verwachten dat Q2_K bruikbaar is. Volgens de PR #1684-data kost Q2_K ~0,87 perplexity versus F16 en koopt het geen snelheid ten opzichte van Q4_K_S (beide 15,5 ms/token op de 7B-benchmark). Je krijgt een kleiner bestand en slechtere output zonder latencywinst. Oplossing: Q4_K_S is de vloer tenzij bestandsgrootte een harde beperking is.

4. Benchmarken op wikitext-perplexity in plaats van je eigen prompts. Perplexity is een taalmodelmetriek. Het meet niet of het model je systeemprompt volgt, JSON correct formatteert, of je domeinwoordenschat hanteert. Oplossing: draai 20-30 van je echte prompts door zowel het gekwantiseerde als het ongekwantiseerde model en vergelijk de outputs.

5. GGUF de container verwarren met het kwantisatiealgoritme erin. Dit leidt tot het vergelijken van "GGUF vs GPTQ" alsof ze dezelfde categorie zijn. Dat zijn ze niet. GGUF is een bestandsformaat. Het k-quant schema erin is het algoritme. Oplossing: vergelijk k-quant-niveaus (Q4_K_M vs Q5_K_M), geen bestandsformaten.

Veelgestelde vragen

Wat is LLM-kwantisatie?

LLM-kwantisatie verlaagt de numerieke precisie van de gewichten van een model, doorgaans van 16-bit floating point naar 4-bit of 8-bit integers. Dit vermindert geheugengebruik en versnelt inference door bandbreedte te verlagen. Een 70B-model zakt van 140 GB naar circa 42 GB op 4-bit. De kwaliteitskosten zijn meestal 1-2% perplexity op 4-bit, minder op 6-bit.

Verlaagt kwantisatie de nauwkeurigheid van een model?

Ja, maar minder dan de meeste mensen verwachten. Volgens de llama.cpp PR #1684-benchmarks kost Q4_K_S op een 7B-model circa 2% perplexity versus F16, en Q6_K minder dan 0,1%. De praktische impact op echte prompts is vaak kleiner dan het perplexitycijfer suggereert, vooral op Q4_K_M en hoger.

Is GPTQ of AWQ beter?

Geen van beide is universeel beter. GPTQ gebruikt inverse-Hessian-foutherverdeling en past bij batch GPU-inference. AWQ beschermt saliente gewichten via activatie-bewuste schaling en past bij latency-gevoelige serving. AWQ heeft een kleinere kalibratieset nodig en overfit er minder op. Als je single-user verzoeken met lage latency serveert, begin dan met AWQ.

Wat betekent Q4_K_M?

Q4_K_M is een k-quant GGUF-kwantisatieniveau. "Q4" betekent nominale 4-bit diepte, "K" markeert het k-quant blokschema (versus legacy Q4_0), en "M" betekent medium: attention- en feed-forward-tensors krijgen extra bits. Effectieve bits per gewicht is circa 4,8, niet 4,0, omdat blokschalen en mins overhead toevoegen en de medium-mix er bovenop meer besteedt.

Kan ik een gekwantiseerd model op een CPU draaien?

Ja, maar alleen via GGUF. GPTQ en AWQ zijn GPU-only formaten. GGUF's k-quant-modellen draaien op CPU via llama.cpp of Ollama, en ondersteunen laag-offloading tussen GPU-VRAM en systeem-RAM. Q4_K_M is de standaard CPU-kwant. Verwacht tragere tokengeneratie dan GPU, maar functionele inference.

Wat is het verschil tussen GGUF en GGML?

GGML is de oudere tensorbibliotheek en bestandsformaat dat llama.cpp oorspronkelijk gebruikte. GGUF verving het in augustus 2023 als een flexibeler containerformaat met betere metadata-ondersteuning. GGUF-bestanden zijn wat je vandaag van HuggingFace downloadt. GGML-bestanden zijn legacy en worden zelden meer gedistribueerd.

Moet ik zelf een model kwantiseren of een voorgekwantiseerde downloaden?

Download eerst een voorgekwantiseerde. De llama.cpp- en HuggingFace-gemeenschappen hebben de meeste populaire modellen al op elk niveau gekwantiseerd. Zelf kwantiseren is alleen zinvol als je een specifieke kalibratieset voor je domein nodig hebt, of als er geen voorgekwantiseerde versie bestaat voor je model.

Wanneer moet ik kwantisatie gebruiken in plaats van een kleiner model?

Gebruik kwantisatie wanneer je de capaciteit van het grotere model nodig hebt maar het niet in geheugen kunt passen. Een gekwantiseerd 70B-model presteert doorgaans beter dan een ongekwantiseerd 13B-model op complexe redeneertaken. Gebruik een kleiner model wanneer latency de beperking is, aangezien kleinere modellen sneller tokens genereren ongeacht kwantisatie.

Wat is het verschil tussen kwantisatie en distillatie?

Kwantisatie verlaagt de numerieke precisie van de gewichten van een bestaand model. Distillatie traint een kleiner model om een groter te imiteren, wat een daadwerkelijk andere (kleinere) architectuur oplevert. Kwantisatie behoudt de architectuur van het originele model en is in principe omkeerbaar. Distillatie creëert een nieuw model en vereist een trainingrun.

De korte versie: kwantisatie is hoe je een model dat je wilt in hardware past die je hebt. Voor de meeste mensen op consumenten-GPU's of Apple Silicon is een voorgekwantiseerde Q4_K_M GGUF van HuggingFace de volledige oplossing. GPTQ en AWQ zijn de GPU-serving-antwoorden. FP8 en SmoothQuant zijn de productie-throughput-antwoorden. Al het andere is optimalisatie nadat je bevestigd hebt dat het model werkt.

Als je beslist wat je zelf wilt hosten en een second opinion wilt over de hardware-methode-combinatie, we praten graag.