Kwantisatie en snelle inferentie op uw eigen hardware

De eerste reactie die veel engineers hebben wanneer ze naar de hardwarevereisten kijken voor een state-of-the-art groot taalmodel is prijsschrik. Een model met 70 miljard parameters in zijn native FP32-formaat zou ruwweg 280 GB GPU-geheugen nodig hebben — meer dan de meeste organisaties in één server hebben en ver meer dan ze willen inrichten om medewerkersvragen te beantwoorden. Kwantisatie is de techniek die deze getallen beheersbaar maakt, en het begrijpen ervan is essentieel voor iedereen die een on-premise AI-stack ontwerpt.

Wat kwantisatie eigenlijk doet

Een neuraal netwerk is uiteindelijk een zeer grote verzameling getallen — de gewichten geleerd tijdens training. Standaard worden die gewichten opgeslagen als 32-bit drijvende-kommawaarden (FP32), elk verbruikt 4 bytes geheugen. Kwantisatie vervangt hoge-precisie getallen door lagere-precisie representaties: 16-bit floats (FP16 of BF16), 8-bit integers (INT8) of zelfs 4-bit integers (INT4). De geheugenomvang krimpt proportioneel en op hardware met native ondersteuning voor lagere-precisie rekenkunde wordt inferentie ook sneller.

• FP16 / BF16 — half-precisie floats. Vrijwel verliesvrij voor de meeste taken; de standaardkeuze voor productie-implementaties waarbij nauwkeurigheid kritisch is. Geheugenbesparingen: 2x versus FP32.
• INT8 — 8-bit integers, doorgaans geproduceerd door post-training kwantisatiemethoden zoals GPTQ of llm.int8(). Bescheiden kwaliteitsdegradatie bij complexe redenering; significant bij de meeste praktische taken. Geheugenbesparingen: 4x versus FP32.
• INT4 — 4-bit integers, de frontier van agressieve kwantisatie. Tools zoals GGUF Q4_K_M en AWQ leveren verrassend goede kwaliteit voor hun omvang. Geheugenbesparingen: 8x versus FP32, met acceptabele degradatie voor chat- en samenvattingsworkloads.

De kwaliteit-versus-omvang afweging

Kwantisatie is niet gratis. Elke bit die u verwijdert is weggegooid informatie, en op een gegeven moment toont dat zich als gedegradeerde output — hallucinaties, redeneeerfouten of verlies van nuance. De praktische bevinding van Privonis-implementaties is dat de afweging verrassend gunstig is voor de meeste zakelijke taken. Een 70B model gekwantiseerd naar INT4 overtreft doorgaans een 13B model in FP16, ook al passen beiden in vergelijkbaar GPU-geheugen. Gebruik bij twijfel het grootste model dat past op de hoogste precisie die uw hardware ondersteunt.

De juiste kwantisatie kiezen gaat minder over het aantal bits en meer over het afstemmen van modelcapaciteit op de taak: een goed gekozen INT4 70B verslaat elke keer een onzorgvuldig FP16 13B.

Inferentieservers: waar de doorvoer vandaan komt

Een gekwantiseerd model draaien is slechts de helft van het verhaal. Het efficiënt serveren onder gelijktijdige belasting vereist een inferentieserver die de structuur van transformer-aandacht begrijpt. De dominante open-source optie vandaag is vLLM, dat PagedAttention introduceerde — een geheugenbeheer techniek geleend van het virtueel geheugen van besturingssystemen die de server in staat stelt vele verzoeken gelijktijdig te verweven zonder GPU-geheugen te verspillen aan vooraf toegewezen KV-cache-blokken. Het praktische effect is een 10 tot 30-voudige verbetering in doorvoer ten opzichte van een naïeve enkelvoudig-verzoek lus.

Andere opvallende opties zijn llama.cpp (CPU-vriendelijk, uitstekend voor kleinere modellen op commodity-hardware), Ollama (ontwikkelaarsvriendelijke wrapper rond llama.cpp), TGI van Hugging Face (sterke ondersteuning voor Hugging Face-modelformaten) en TensorRT-LLM van NVIDIA (hoogste doorvoer op NVIDIA-hardware, ten koste van een complexere compilatiepipeline). Privonis evalueert en benchmarkt al deze opties voor elke klantconfiguratie.

Batching en doorvoer

GPU's bereiken piekefficiëntie wanneer ze veel bewerkingen gelijktijdig verwerken — dat is waarvoor ze zijn ontworpen. Continue batching (ook wel dynamische batching of iteratieniveau-planning genoemd) stelt een inferentieserver in staat tokens van meerdere gelijktijdige verzoeken te groeperen in één GPU-kernelaanroep, waardoor benutting drastisch wordt verbeterd. Zonder batching kan een enkele gebruikersquery 5% van uw GPU-capaciteit gebruiken; met continue batching kunt u benutting tot 70 tot 80% pushen onder realistisch verkeerspatronen. Voor een onderneming met tientallen gelijktijdige gebruikers kan het verschil tussen een batching-bewuste server en een naïeve de behoefte aan één GPU-server of vier betekenen.

De juiste kwantisatie kiezen voor uw GPU

De beslissingsboom is eenvoudiger dan het lijkt. Begin met uw GPU-geheugenbudget, trek ruimte af voor het OS en de inferentieserver (doorgaans 4 tot 8 GB) en zoek dan het grootste model dat past op het hoogste precisieniveau. Een paar praktische referentiepunten:

• 24 GB VRAM (bijv. RTX 4090, A5000) — draait comfortabel een 13B model in FP16, of een 34B model in INT4.
• 48 GB VRAM (bijv. RTX 6000 Ada, A6000) — draait een 34B model in FP16, of een 70B model in INT4.
• 2 × 80 GB (bijv. A100-paar via NVLink) — draait een 70B model in FP16, of een 140B model in INT4 met tensorparallellisme.
• Alleen CPU (geen GPU) — llama.cpp met een Q4_K_M 7B of 13B model is haalbaar voor lage-concurrentie ontwikkelaarstooling; verwacht 5 tot 15 tokens/s.

Het samenbrengen met Privonis

Een kwantisatieformaat en een inferentieserver selecteren is engineering-werk dat profilering vereist op uw specifieke hardware met uw specifieke workload. Privonis verzorgt die benchmarking als onderdeel van elke implementatie: we voeren doorvoertests uit, meten outputkwaliteit op een representatief monster van uw echte prompts en leveren een configuratie die de prestaties maximaliseert binnen uw hardwarebudget. Het resultaat is een productie-inferentiestack die uw team kan beheren zonder een specialist ML-engineer on-call. Als u klaar bent om te verkennen wat bij uw omgeving past, voert ons team graag de berekeningen met u uit.