Kvantisering och snabb inferens på din egen hårdvara

Den första reaktionen många ingenjörer har när de tittar på hårdvarukraven för en toppmodern stor språkmodell är prischock. En modell med 70 miljarder parametrar i sitt ursprungliga FP32-format skulle behöva ungefär 280 GB GPU-minne – mer än de flesta organisationer har i en enda server och långt mer än de vill tilldela bara för att besvara anställdas frågor. Kvantisering är den teknik som gör dessa siffror hanterbara, och att förstå den är avgörande för alla som utformar en lokal AI-stack.

Vad kvantisering faktiskt gör

Ett neuralt nätverk är i slutändan en mycket stor samling tal – vikterna som lärdes in under träning. Som standard lagras dessa vikter som 32-bitars flyttalsvärden (FP32), där varje förbrukar 4 byte minne. Kvantisering ersätter höga precisionssiffror med lägre precisionsrepresentationer: 16-bitars flyttal (FP16 eller BF16), 8-bitars heltal (INT8) eller till och med 4-bitars heltal (INT4). Minnesfotavtrycket minskar proportionellt, och på hårdvara med inbyggt stöd för lägre precisionsaritmetik blir inferens också snabbare.

• FP16 / BF16 – halvprecisions­flyttal. Nästan förlustfritt för de flesta uppgifter; förstahandsval för produktionsdriftsättningar där noggrannhet är kritisk. Minnesbesparingar: 2x jämfört med FP32.
• INT8 – 8-bitars heltal, vanligtvis producerade av post-träningskvantiserings (PTQ)-metoder som GPTQ eller llm.int8(). Modest kvalitetsförsämring vid komplex slutledning; signifikant för de flesta praktiska uppgifter. Minnesbesparingar: 4x jämfört med FP32.
• INT4 – 4-bitars heltal, frontlinjen för aggressiv kvantisering. Verktyg som GGUF Q4_K_M och AWQ levererar förvånansvärt god kvalitet för sin storlek. Minnesbesparingar: 8x jämfört med FP32, med acceptabel försämring för chatt- och sammanfattningsarbets­belastningar.

Avvägningen mellan kvalitet och storlek

Kvantisering är inte gratis. Varje bit du tar bort är information som kastas bort, och vid en viss punkt syns det som försämrat resultat – hallucinationer, slutledningsfel eller förlust av nyanser. Den praktiska slutsatsen från Privonis-driftsättningar är att avvägningen är förvånansvärt gynnsam för de flesta företagsuppgifter. En 70B-modell kvantiserad till INT4 överträffar vanligtvis en 13B-modell vid FP16, även om båda ryms i liknande GPU-minne. När du är osäker, använd den största modellen som ryms vid den högsta precisionen din hårdvara stöder.

Att välja rätt kvantisering handlar mindre om antalet bitar och mer om att matcha modellkapaciteten till uppgiften: en välvald INT4 70B slår en slarvigt FP16 13B varje gång.

Inferensservrar: varifrån genomströmningen kommer

Att köra en kvantiserad modell är bara halva historien. Att serva den effektivt under samtidig belastning kräver en inferensserver som förstår strukturen hos transformeruppmärksamhet. Det dominerande öppen källkodsalternativet idag är vLLM, som introducerade PagedAttention – en minneshanteringsteknik lånad från operativsystemets virtuella minne som gör att servern kan sammanfläta många förfrågningar samtidigt utan att slösa GPU-minne på förallocerade KV-cache-block. Den praktiska effekten är en 10–30x förbättring av genomströmning jämfört med en naiv enstaka-förfrågnings-loop.

Andra anmärkningsvärda alternativ inkluderar llama.cpp (CPU-vänlig, utmärkt för mindre modeller på standard­hårdvara), Ollama (utvecklarvänlig omslutning runt llama.cpp), TGI från Hugging Face (starkt stöd för Hugging Face-modellformat) och TensorRT-LLM från NVIDIA (högst genomströmning på NVIDIA-hårdvara, till priset av en mer komplex kompileringspipeline). Privonis utvärderar och riktmärker alla dessa för varje kundkonfiguration.

Batching och genomströmning

GPU:er uppnår toppeffektivitet när de bearbetar många operationer samtidigt – det är vad de är designade för. Kontinuerlig batching (även kallad dynamisk batching eller iterations­nivåschemaläggning) gör att en inferensserver kan gruppera tokens från flera simultana förfrågningar i ett enda GPU-kärnanrop, vilket dramatiskt förbättrar utnyttjandet. Utan batching kan en enda användarfråga använda 5 % av din GPU-kapacitet; med kontinuerlig batching kan du trycka utnyttjandet till 70–80 % under verkliga trafikmönster. För ett företag med dussintals simultana användare kan skillnaden mellan en batching-medveten server och en naiv innebära skillnaden mellan att behöva en GPU-server eller fyra.

Välja rätt kvantisering för din GPU

Beslutsträdet är enklare än det ser ut. Börja med din GPU-minnesbudget, subtrahera utrymme för OS och inferensservern (vanligtvis 4–8 GB), och hitta sedan den största modellen som ryms vid den högsta precisionen. Några praktiska referenspunkter:

• 24 GB VRAM (t.ex. RTX 4090, A5000) – kör bekvämt en 13B-modell vid FP16, eller en 34B-modell vid INT4.
• 48 GB VRAM (t.ex. RTX 6000 Ada, A6000) – kör en 34B-modell vid FP16, eller en 70B-modell vid INT4.
• 2 × 80 GB (t.ex. A100-par via NVLink) – kör en 70B-modell vid FP16, eller en 140B-modell vid INT4 med tensorparallellism.
• Endast CPU (ingen GPU) – llama.cpp med en Q4_K_M 7B- eller 13B-modell är möjlig för låg-concurrens-utvecklarverktyg; förvänta dig 5–15 tokens/s.

Sätta ihop det med Privonis

Att välja ett kvantiseringsformat och en inferensserver är ingenjörsarbete som kräver profilering på din specifika hårdvara med din specifika arbetsbelastning. Privonis hanterar den riktmärkningen som en del av varje driftsättning: vi kör genomströmnings­tester, mäter outputkvalitet på ett representativt urval av dina verkliga prompts och levererar en konfiguration som maximerar prestanda inom din hårdvarubudget. Resultatet är en produktionsinferensstack som ditt team kan driva utan en specialist ML-ingenjör i jour. Om du är redo att utforska vad som passar din miljö är vårt team gärna med och beräknar siffrorna med dig.