On-device LLM's aan de tactische rand: kwantisering en implementatie

Een groot taalmodel dat een cloud-eindpunt nodig heeft, is nutteloos aan de tactische rand, omdat het netwerk het minst betrouwbare element in de operationele omgeving is. Een geweigerde, gedegradeerde, intermitterende of beperkte bandbreedte-verbinding kan een verzoek naar een extern model niet verzenden en een antwoord retourneren binnen de tijdlijn die een beslissing toelaat — en het versturen van operationele tekst buiten het platform creëert zowel een uitstralingshandtekening als een risico op gegevensblootstelling. Het alternatief is het model te draaien waar de data zich bevindt: op het apparaat, met de radio uit, waarbij elk token lokaal wordt gegenereerd. Dit artikel beschrijft hoe dat in de praktijk wordt gedaan — modelselectie, kwantisering, hardwarebudgetten, de sleutel-waardecache en de runtime-details die bepalen of on-device inferentie responsief of onbruikbaar traag is.

Waarom on-device, en wat het u kost

De argumentatie voor on-device inferentie is eenvoudig: het verwijdert het netwerk uit het kritieke pad. Nadat het model in het geheugen is geladen, is er geen externe oproep, geen afhankelijkheid van een satelliet- of mesh-radioverbinding en geen telemetrie die het platform verlaat. De latentie wordt deterministisch — een functie van de hardware en het model, niet van een omstreden verbinding. Prompts en uitvoer die mogelijk locaties, eenheidsaanduidingen of intenties bevatten, verlaten het apparaat nooit.

De kosten zijn capaciteit. Een model dat op één edge-apparaat past, is veel kleiner dan een frontier-cloudmodel, en een 7B–8B parametermodel is aanzienlijk minder capabel bij open redeneren dan een model twee ordes van grootte groter. De engineering-discipline van on-device LLM-werk is daarom taakafbakening: een smalle, goed gedefinieerde taak koppelen aan het kleinste model dat het betrouwbaar kan uitvoeren, in plaats van te verwachten dat een klein model een algemene assistent is. Het samenvatten van een contactrapport, het classificeren van binnenkomende berichten op prioriteit, het extraheren van gestructureerde velden uit vrije tekst, of het beantwoorden van vragen over een lokale documentenset zijn allemaal taken die een klein model goed aankan. Redeneren in meerdere stappen over een grote, ambigue context is waar kleine modellen tekortschieten.

Modelselectie: kleiner dan u denkt

De neiging om het grootste model te laden dat de hardware fysiek aankan, is de meest voorkomende fout bij edge LLM-implementatie. Het grootste model laat geen geheugenruimte over voor het contextvenster, de sleutel-waardecache of enige gelijktijdige workload die het apparaat deelt — en bij autoregressieve generatie betekent een groter model minder tokens per seconde. Het juiste startpunt is de kleinste modelfamilie die plausibel capabel is voor de taak, gevalideerd aan de hand van een afgehouden set echte voorbeelden voordat iets anders wordt geoptimaliseerd.

Als globale mapping: 1B–3B parametermodellen zijn geschikt voor getemplatiëerde extractie, classificatie en korte transformatie; ze draaien op bescheiden hardware en genereren snel. 7B–8B modellen zijn de werkpaardsklasse voor samenvatting, retrieval-augmented vraagbeantwoording en beperkt redeneren, en ze passen comfortabel op mid-tier edge-versnellers na kwantisering. Boven ongeveer 13B parameters overschrijden de geheugen- en bandbreedtevereisten doorgaans wat één geharde edge-apparaat bij een interactieve tokensnelheid kan handhaven, en de marginale capaciteit rechtvaardigt zelden de kosten aan de rand.

Kwantisering: de centrale afweging

Kwantisering is de techniek die on-device LLM's praktisch maakt. Een model wordt getraind en gedistribueerd bij 16-bit drijvende-komma-precisie, maar het merendeel van die precisie is niet nodig voor inferentie. Kwantisering herschrijft de gewichten bij lagere bitbreedtes — 8, 5 of 4 bits, en lager — wat de geheugenvoetafdruk proportioneel verkleint en de doorvoer verhoogt, omdat de bindende beperking op generatie geheugenbandbreedte is en minder bytes per gewicht betekent minder bytes te verplaatsen per token.

De nauwkeurigheidskosten zijn niet-lineair, en het begrijpen van de vorm ervan is wat een gedegen implementatie onderscheidt van een brosse. Acht-bit kwantisering is voor vrijwel elke taak bijna verliesvrij. Vier-bit kwantisering met een modern K-quant-schema (gewoonlijk aangeduid als Q4_K_M) kost doorgaans 1–3 procent op redeneer-benchmarks terwijl de voetafdruk gehalveerd wordt ten opzichte van 8-bit — dit is de standaard sweet spot voor edge-implementatie. Onder 4 bits versnelt de degradatie: 3-bit en 2-bit builds kunnen instorten bij redenerende taken, zelfs als ze nog steeds vloeiende tekst produceren, wat ze gevaarlijk maakt juist omdat het falen niet duidelijk is bij een vluchtige lezing.

Het beslissende punt is dat deze afweging taakg­afhankelijk is en gemeten moet worden, niet verondersteld. Voor extractieve en getemplatiëerde taken — haal de gridreferentie uit dit bericht, classificeer dit rapport — presteert een 4-bit model dicht bij de volledige precisiebasislijn omdat de taak de kwetsbare delen van het model niet aanspreekt. Voor meerstappenredeneren kan dezelfde 4-bit build genoeg verliezen om ertoe te doen. De enige manier om dit te weten is de afgehouden evaluatieset door de volledige precisiebasislijn, de 8-bit build en de 4-bit build te laten lopen, taakrelevante maatstaven te vergelijken en de kleinste build te accepteren waarvan het verlies binnen de operationele tolerantie valt. Het kiezen van de juiste edge-versneller voor dat model is een eigen discipline — zie onze analyse van edge AI-hardwareselectie voor defensie.

Kwantiseringsgerichte training versus post-training kwantisering

De meeste edge-implementaties gebruiken post-training kwantisering: neem een bestaand model en kwantiseer de gewichten direct, met optionele kalibratie op een kleine representatieve dataset. Het is snel, vereist geen trainingsinfrastructuur en is goed genoeg bij 4 bits voor de meeste taken. Kwantiseringsgerichte training — het model fijn afstemmen met kwantisering gesimuleerd in de voorwaartse doorvoer — herstelt meer nauwkeurigheid bij zeer lage bitbreedtes maar vereist de trainingspijplijn en de oorspronkelijke data. Voor de meeste ingezette systemen is post-training 4-bit kwantisering met kalibratie de pragmatische keuze; reserveer kwantiseringsgerichte training voor gevallen waar sub-4-bit werking wordt afgedwongen door hardwarelimieten.

Hardwarebudgetten en de geheugen-bandbreedtemuur

De hardwarevraag voor on-device LLM's wordt gedomineerd door geheugen, niet rekenkracht. Autoregressieve generatie produceert één token tegelijk, en het produceren van elk token vereist het lezen van de volledige set modelgewichten uit het geheugen. De doorvoer in tokens per seconde wordt daarom veel vaker begrensd door geheugenbandbreedte gedeeld door modelgrootte in bytes dan door ruwe rekenkundige doorvoer. Een apparaat met ruime FLOPS maar bescheiden geheugenbandbreedte zal traag zijn bij generatie, ongeacht zijn rekenwaardering.

De praktische ondergrens voor een responsief 7B-klasse model is ongeveer 8 GB geheugen toegankelijk voor de inferentieversneller en voldoende bandbreedte om 10–20 tokens per seconde te handhaven. Een Jetson Orin NX in zijn 8GB of 16GB configuratie valt precies in dit bereik, evenals een klein geharde x86-systeem met een geïntegreerde of discrete GPU. CPU-only inferentie is volledig haalbaar voor 1B–3B-modellen en produceert enkele tokens per seconde op 7B-modellen — acceptabel voor batchsamenvatting die zonder wachtende operator draait, onaanvaardbaar voor interactief gebruik. Prefill (de prompt verwerken) en decoderen (het antwoord genereren) hebben verschillende knelpunten: prefill is rekenkracht-gebonden en parallel, decoderen is bandbreedte-gebonden en sequentieel, dus ze moeten apart worden gemeten bij het bepalen van de hardwareomvang.

De sleutel-waardecache: de verborgen geheugenkosten

Gewichtsgrootte is de geheugenkosten waarvoor iedereen budget; de sleutel-waarde (KV) cache is degene die teams overrompelt. Tijdens generatie slaat het model de aandachtssleutels en -waarden op voor elk al verwerkt token zodat het ze niet opnieuw hoeft te berekenen, en die cache groeit lineair met de contextlengte. Voor een 7B-model bij 16-bit precisie kost de KV-cache ongeveer 0,5 MB per token, zodat een 8.000-token context ruwweg 4 GB bovenop de gewichten toevoegt — vaak groter dan de gekwantiseerde gewichten zelf. Op beperkte hardware is de KV-cache, niet de gewichten, wat de bruikbare contextlengte beperkt. De KV-cache kwantiseren naar 8 of 4 bits halveert of kwadrateert dit en is vaak het verschil tussen een werkbaar contextbudget en een out-of-memory-fout. De corollaire is de contextlengte in te stellen op de kleinste waarde die de taak nodig heeft, niet de grootste die het model ondersteunt.

Runtime, verpakking en geverifieerde offline werking

De on-device runtime is de laag die de gekwantiseerde gewichten laadt, de KV-cache beheert en een generatie-interface blootstelt aan de applicatie. Een llama.cpp-gebaseerde engine is de gangbare keuze omdat hij het GGUF-gekwantiseerde formaat direct uitvoert, CPU- en versneller-backends ondersteunt en een kleine afhankelijkheidsvoetafdruk heeft die past bij een geharde image. Welke runtime ook gebruikt wordt, het model moet na het eerste laden in het geheugen worden vastgezet zodat de seconden durende laadkosten eenmalig worden betaald in plaats van bij elk verzoek, en de applicatie moet generatielatentie behandelen als een eersteklas maatstaf die aan de operator wordt weergegeven.

Verpakking is waar on-device-claims worden gewonnen of verloren. Het modelbestand, de runtime, de tokenizer en de prompttemplates moeten allemaal aanwezig zijn op de apparaatimage — niets wordt tijdens runtime opgehaald. De enige eerlijke test van offline werking is de volledige workflow uit te voeren met de radio uit, in vliegtuigmodus of op een geïsoleerd netwerk, en te bevestigen dat het systeem start en antwoordt zonder bereikbaar eindpunt. Elke verborgen oproep — een tokenizerdownload, een telemetriebaken, een licentiecontrole — moet worden gevonden en verwijderd, want aan de rand zal het stil mislukken en de capaciteit meenemen. Modelupdates worden verzonden via fysieke media of via een geverifieerde lokale synchronisatie, nooit via een aanname van connectiviteit.

On-device LLM's verbreden ook het aanvalsoppervlak op manieren die een cloudmodel niet doet, omdat de gewichten, prompts en elk ophaalcorpus zich bevinden op een apparaat dat mogelijk kan worden veroverd. Promptinjectie via ingesloten documenten, data-exfiltratie via gecrafted uitvoer en manipulatie van het modelbestand vallen allemaal in het bereik en moeten worden ontworpen tegen — een onderwerp dat uitgebreid wordt behandeld in onze gids over LLM-beveiliging voor defensie AI-systemen.