Er 4-bit-kvantisering nok til LLM'er på edge-enheder?

Når en stor sprogmodel (LLM) trænes i skyen, gemmes vægtene som 32-bit flydetal. På en edge-enhed er det alt for tungt: 7 mia. parametre svarer til ~28 GB kun til vægte. Kvantisering erstatter de mange flydende tal med færre, faste trin - fx 4-bit heltal - uden at gen-træne hele modellen. Resultatet er en dramatisk reduktion i hukommelse og båndbredde, så modellen kan køre lokalt på mobil, mini-PC eller indlejret NPU.

Hvorfor lige 4-bit?

1. Hukommelse: 4-bit komprimerer vægtene 8× (og sommetider 16×) sammenlignet med FP32, så en 7B-model kan ligge i 3,5 GB i stedet for 28 GB.
2. Båndbredde: Halverede eller fjerdedel bus-overførsler giver lavere latenstid, især på mobil-SoC’er hvor RAM-til-NPU båndbredde er flaskehalsen.
3. Energiforbrug: Færre bit betyder færre switching-operationer. Ved lav strøm (batteri) kan det betyde ~30 % længere køretid i praksis.
4. Kvalitets-sweet spot: 4-bit bevarer overraskende meget af original nøjagtighed - ofte <1 % point tab på klassiske benchmarks - mens 3- og 2-bit typisk kræver mere avancerede tricks.

Metoderne: Fra simple tabeller til lærende skalaer

Vægte vs. Aktiveringer og kv-cache

Det er let at stirre sig blind på vægtene (model-lageret), men ved inferens fylder aktiveringer og især KV-cachen (key/value for transformer-hoveder) også:

• Vægte: Ofte 4-bit fint nok - statisk, kan pakkes i GGUF, ONNX m.m.
• Aktiveringer: Strømmer gennem chippen. 8-bit er i dag minimum pga. akkumuleringer; 4-bit her kan give numerisk ustabilitet.
• KV-cache: Skalerer lineært med prompt-længde og batch. Mange kører 8-bit (eller 16-bit i “long-context” modeller) som kompromis mellem RAM-pres og nøjagtighed.

Lad os antage en 7B-model og batch = 1:

• Vægte 4-bit: 3,5 GB
• KV-cache 8-bit, 4k tokens: ~1,2 GB
• Total RAM: ~4,7 GB + overhead → passer i en Raspberry Pi 5 med 8 GB eller en Android-telefon med 12 GB.
• Latenstid: 30-50 % lavere sammenlignet med 8-bit vægte pga. færre DRAM-læst.
• Energiforbrug: 20-40 % lavere under kontinuerlig generation ift. 16-bit.

Kommer du under rammegrænsen? Det er nu CPU-/NPU-gennemløb og cache-hit-rate der dominerer. 4-bit hjælper på hukommelsen, men ikke nødvendigvis på compute-perspektivet; nogle SoC’er mangler instruktioner til at multiplicere 4-bit tal direkte. Her kan en moderne mobil-NPU, en Apple M-series GPU eller NVIDIA Jetson med TensorRT-LLM udnytte int4-matrix multiply og hente ekstra hastighed.

Opsummering

4-bit-kvantisering er den nuværende “guldhårsløsning” på edge: markant lavere hukommelse og strømforbrug, men kun minimale kvalitetstab - hvis du vælger den rette metode og forstår forskellen på vægte og KV-cache. I resten af artiklen dykker vi ned i, hvordan hardware-begrænsninger, use-cases og nye komprimeringsteknikker afgør, om 4-bit også er nok til din deployment.

Edge-enheder spænder fra en Raspberry Pi i et el-skab til en MacBook Pro i tasken og en Samsung Galaxy i lommen. Ydelsen - og dermed loftet for, hvor store LLM’er vi kan afvikle i 4-bit - afhænger primært af tre faktorer: rå matrix-gennemløb, tilgængelig DRAM og termisk budget.

*TOPS = tera operations per second i INT4. Værdierne er datasheet-tal og falder ved længere sekvenser pga. hukommelses-båndbredde.

Ram, båndbredde og termik

• Hukommelse til vægte dominerer ved korte prompts. 4-bit kvantisering reducerer vægtene 8× i forhold til FP32 og 2× i forhold til INT8.
• KV-cachen vokser lineært med sekvenslængde og kan hurtigt overstige vægtene. Den bør ofte lægges i 8-bit for ikke at kvæle præcisionen, men INT4/K-bit eksperimenteres.
• Båndbredde: Selv store TOPS-tal hjælper ikke, hvis LPDDR-bussen ikke kan følge med. Under sustained load ser vi ofte 40-60 % af peak-ydelsen.
• Thermal throttling: Telefon-chippen rammer 42-45 °C på få sekunder ved fuld NPU-belastning; klokken falder hurtigt 20-30 % uden aktiv køling.
• Batteri: 7-10 W kontinuerligt dræner et 5000 mAh-batteri på ~1,5 time. Brug on-device kvantisering + kvikkere decodere (ex. flash-attention) for at afkorte inference-tiden.

Tommelfingerregler for modelstørrelse vs. Hukommelsesbudget

1. Vægte (4-bit):
   • 7 B ≈ 3,5-4 GB
   • 13 B ≈ 7-8 GB
   • 33 B ≈ 18-20 GB (kræver laptop/desktop)
2. KV-cache (8-bit) for dialog med 4 k tokens
   ≈ 2 × layers × hidden × seq × bytes
   F.eks. Llama-2-7B, 32 lag, 4096 tokens: ~2,1 GB.
3. Mål at holde total RAM < 70 % af fysisk hukommelse for at undgå swap/GC-stop.
4. Batteriforskrækkelse? Trim sekvenslængden eller opløsningen (vision) før du halverer bits endnu mere.

Platform- og runtime-valg

• Llama.cpp (GGUF): Letvægts C/C++-runtime, kører på alt fra Pi til RTX. INT4 = q4_0/q4_k_m. Understøtter GPU-offload (Metal, CUDA, Vulkan).
• ONNX Runtime:
  • Windows: DirectML (INT4 pilot).
  • Android: NNAPI / Qualcomm HTP.
  • Linux: CUDA, ROCm eller ARM Compute Library.
• Core ML: Apple-økosystemet. 4-bit er konverteret til «packed INT4» og afvikles på ANE/GPU uden speciel kode.
• TensorRT-LLM: Højeste gennemløb på NVIDIA-GPU’er; kræver dog fuld desktop/laptop-GPU.
• WebGPU (Bun/Node/Browser): Spændende til lette modeller <4 B parametre. Undgå lange dialoger pga. begrænset VRAM.

Praksisråd: Start altid med en 4-bit-model, benchmark i din tænkte sekvenslængde, og mål derefter KV-cache-footprintet. Overskrider du termik eller RAM, så skru først på sekvens, dernæst på bits, og til sidst på parametre.

4-bit-kvantisering er ikke en mirakelkur, men i mange edge-scenarier er den ”god nok” - især hvis man forstår, hvor grænserne går, og hvordan man kompenserer for dem. Her er det praktiske billede, som det ser ud i dag.

Hvorfor virker det?

1. LLM-fejlmarginen er høj - et par procent i perplexity giver sjældent mærkbare fejl i almindelig samtale eller søge-augmented generering.
2. 4-bit-vægt-fejl ≠ 4-bit-aktivations-fejl. Vi kvantiserer kun vægte; aktiveringer og KV-cache holder vi i 8-bit, så præcisionen i løbetiden bevares.
3. Nævnerens lov på edge-hardware: Halvering af hukommelsen betyder tit >50 % energieffektivitet pga. mindre DRAM-trafik og lavere termik.

Faldgruber du skal kende

• Reasoning-tunge opgaver: Chain-of-Thought, logikpuzzles og ”hvad-hvis”-scenarier taber 4--8 % på MMLU/GSM8K, særligt på 7B-modeller.
• Meget lange prompts (>8 k tokens): Kvantiseringen af positionelle vægte kan akkumulerer fejl, som øger hallucination og gentagelser.
• MoE-arkitekturer: 4-bit slår hårdere, fordi router-vægtens støj sender tokens til forkerte eksperter. Her er 8-bit eller mixed-precision sikrere.

4-bit-vægt + 8-bit kv-cache: Det gyldne kompromis

KV-cachen fylder lineært med kontekstlængden. På en 7B-model kan selve vægtene ofte være 3-4 GB (4-bit), mens KV-cachen hurtigt overhaler det ved lange dialoger. 8-bit på cachen bevarer præcisionen, og fordi cachen ligger i hurtigere on-chip-SRAM/L2 på mobile GPU’er/NPU’er, er den ekstra byte nemmere at sluge end permanent DRAM-fodring.

Anbefalet tommelfingerregel

Hvis din opgave kan accepterer ±5 % kvalitetsudsving, så er 4-bit værd at prøve først. Mål, før du opgraderer til 8-bit overalt - gevinsten i latens og batteri er ofte mere værd end den marginale kvalitetsoptimering.

Edge-LLM’er er stadig vilde dyr at tæmme. Med den rigtige fremgangsmåde kan de dog komme i bur på få watt - uden at gå alt for meget på kompromis med kvaliteten.

Fra idé til inferens: En hurtig tjekliste

1. Definér use case
   • Skal modellen blot autoudfylde felter, køre en simpel chatbot eller generere kildekode?
   • Kræves on-device eller er delvist cloud-fallback acceptabelt?
2. Fastlæg kvalitetskrav
   • Målbare KPI’er: exact match, bleu/rouge, eller menneskelig vurdering.
   • Tolereret fejlniveau afgør om 4-bit er nok eller der skal skaleres op i præcision.
3. Vælg modelstørrelse
   • 7 - 13 B parametre: typisk mobil og Raspberry Pi 5 + NPU.
   • 30 - 34 B: kraftigere mini-PC’er med dGPU (RTX 30/40) eller Apple-silicon.
   • >34 B: kun realistisk på high-end GPU’er eller kraftige servere.
4. Check hukommelsesbudget
   Tommelregel: 4-bit vægte = ~0,5 GB pr. 1 B parametre + 8-bit KV-cache på 1,5 MB pr. token i samtalen.
5. Vælg runtime
   • CPU-first: llama.cpp (GGUF).
   • Metal/Apple NPU: Core ML + MLX.
   • NVIDIA GPU: TensorRT-LLM / vLLM.
   • Android: Qualcomm SNPE eller MediaTek NeuroPilot.
6. Implementér kvantisering
   • PTQ (post-training) for hurtige POCs.
   • QLoRA/AWQ for finetuningscenarier.
   • Husk altid exponentielle moving averages ved GPTQ-kalibrering.
7. Kalibrér & mål
   • Kør perplexity + task-metrics før og efter kvantisering.
   • Profilér latency (p99) og watt-forbrug med f.eks. tegrastats, powermetrics eller nvidia-smi.
8. Hærd mod privacy-risici
   • Krypter lokale model­filer hvis telefonen/boardet kan tabes.
   • Slå bagdørs-scanning til i distributions-pipelines (vægt-hashing, supply-chain-bill-of-materials).
9. Deploy & observér
   • Brug OTA-opdateringer (delta patches) for ikke at skylle gigabytes igennem nettet.
   • Log kun anonyme performance-telemetridata for at efterleve GDPR.

Anbefalede formater & konfigurationer

Kalibrering & måling

• Dataset-valg: Brug 128-256 repræsentative dialoger. For kode-LLM’er: short-snippets + repos.
• Gradient-halvering: Overvåg at vægte ikke klapper sammen ved QLoRA-finetuning.
• Golden set: Hav 10-20 manuelle edge-cases til sanity-check efter hver kompilering.

Privacy-overvejelser

Edge-deployment mindsker datalæk, men åbner nye fronter:

• Model inversion: Raadgiv brugere om ikke at fodre LLM’en med personnumre.
• Prompt-beskyttelse: Krypter kontekst (FHE / TEE) hvis output skal sendes til cloud-RAG.
• Zero-trust OTA: Signér og hash-valider hver model-shard.

Fremtidsblik

2-3-bit kvantisering er allerede på forskningslab-stadiet (bits-and-bytes NF3, FlexRQ) og lover yderligere 25-40 % RAM-besparelse, dog ofte med udtalt præcisionstab i ræsonnering. Kombineres det med sparsitet (60-70 %) kan vi se en teoretisk 7× throughput-gevinst. Samtidig presser chip-producenterne på:

• Apple M4 NPU: >38 TOPS INT4.
• Qualcomm Oryon: dedikeret micro-tile engine til KV-cache.
• NVIDIA Blackwell: decoder engine der streamer tokens direkte fra HBM til SM-clusters.

Det næste store spring kan komme fra speculative decoding og draft-&-verify metoder, der skærer latency i halv-til hel, uafhængigt af bit-bredden.

Konklusion

4-bit-kvantisering er i dag den sweet spot mellem hukommelsesforbrug, latency og modelkvalitet på edge. Den dækker de fleste lokale chat-assistenter, enklere RAG-workloads, tale-intents og let billed-captionering. Har du brug for lang kontekst > 64 k tokens, avanceret kodesyntese eller enterprise-grade compliance, må du stadig op i 8-bit eller hybrid FP16-løsninger - eller vente på næste generation af hardware og 2-3-bit-algoritmer.