On-device LLMs an der taktischen Einsatzkante: Quantisierung und Deployment

Ein großes Sprachmodell, das einen Cloud-Endpunkt benötigt, ist an der taktischen Einsatzkante nutzlos, denn das Netzwerk ist die unzuverlässigste Komponente im operativen Umfeld. Eine verweigerte, degradierte, intermittierende oder bandbreitenbeschränkte Verbindung kann keine Anfrage an ein entferntes Modell übertragen und innerhalb des für eine Entscheidung zur Verfügung stehenden Zeitrahmens eine Antwort zurückliefern – und das Senden operativer Texte außerhalb der Plattform erzeugt sowohl eine Emissionssignatur als auch ein Datenleckrisiko. Die Alternative ist, das Modell dort zu betreiben, wo die Daten sind: auf dem Gerät, mit ausgeschaltetem Funk, jedes Token lokal generierend. Dieser Artikel behandelt, wie das in der Praxis umgesetzt wird – Modellauswahl, Quantisierung, Hardware-Budgets, den Key-Value-Cache und die Runtime-Details, die darüber entscheiden, ob On-Device-Inferenz reaktionsfähig oder unbrauchbar langsam ist.

Warum on-device – und was es kostet

Das Argument für On-Device-Inferenz ist eindeutig: Das Netzwerk wird aus dem kritischen Pfad entfernt. Nachdem das Modell in den Arbeitsspeicher geladen ist, gibt es keinen Remote-Aufruf, keine Abhängigkeit von einer Satelliten- oder Mesh-Funkverbindung und keine Telemetrie, die die Plattform verlässt. Die Latenz wird deterministisch – eine Funktion der Hardware und des Modells, nicht einer umkämpften Verbindung. Prompts und Ausgaben, die möglicherweise Standorte, Truppenbezeichnungen oder Absichten enthalten, verlassen das Gerät nie.

Der Preis ist die Leistungsfähigkeit. Ein Modell, das auf ein einzelnes Edge-Gerät passt, ist weit kleiner als ein frontier Cloud-Modell, und ein 7B–8B-Parametermodell ist bei offenem Reasoning deutlich weniger leistungsfähig als ein zwei Größenordnungen größeres Modell. Die ingenieurtechnische Disziplin der On-Device-LLM-Arbeit ist daher die Aufgabenabgrenzung: eine enge, klar definierte Aufgabe dem kleinsten Modell zuzuordnen, das sie zuverlässig ausführen kann, anstatt von einem kleinen Modell einen allgemeinen Assistenten zu erwarten. Die Zusammenfassung eines Kontaktberichts, die Priorisierungsklassifizierung eingehender Nachrichten, die Extraktion strukturierter Felder aus Freitext oder die Beantwortung von Fragen über einen lokalen Dokumentenbestand sind alles Aufgaben, die ein kleines Modell gut bewältigt. Mehrschrittige Schlussfolgerungen über einen großen, mehrdeutigen Kontext sind der Bereich, in dem kleine Modelle versagen.

Modellauswahl: kleiner als gedacht

Der Instinkt, das größte Modell zu laden, das die Hardware physisch aufnehmen kann, ist der häufigste Fehler beim Edge-LLM-Deployment. Das größte Modell lässt keinen Speicherspielraum für das Kontextfenster, den Key-Value-Cache oder parallele Workloads, die sich das Gerät teilen – und bei autoregressiver Generierung bedeutet ein größeres Modell weniger Token pro Sekunde. Der richtige Ausgangspunkt ist die kleinste Modellfamilie, die die Aufgabe plausibel bewältigen kann, validiert an einem zurückgehaltenen Datensatz realer Beispiele, bevor irgendetwas anderes optimiert wird.

Als grobe Zuordnung: 1B–3B-Parametermodelle eignen sich für vorlagenbasierte Extraktion, Klassifizierung und Kurzformtransformation; sie laufen auf bescheidener Hardware und generieren schnell. 7B–8B-Modelle sind die Arbeitstierklasse für Zusammenfassung, retrieval-gestütztes Question Answering und eingeschränktes Reasoning, und sie passen einmal quantisiert komfortabel auf Mid-Tier-Edge-Beschleuniger. Jenseits von etwa 13B Parametern übersteigen die Speicher- und Bandbreitenanforderungen im Allgemeinen das, was ein einzelnes robustes Edge-Gerät bei einer interaktiven Token-Rate aufrechterhalten kann, und die marginale Mehrleistung rechtfertigt selten die Kosten am Edge.

Quantisierung: der zentrale Kompromiss

Quantisierung ist die Technik, die On-Device-LLMs praktikabel macht. Ein Modell wird mit 16-Bit-Gleitkommazahlpräzision trainiert und verteilt, aber der Großteil dieser Präzision wird für die Inferenz nicht benötigt. Quantisierung kodiert die Gewichte auf niedrigere Bitbreiten neu – 8, 5 oder 4 Bit und darunter – was den Speicherbedarf proportional verringert und den Durchsatz erhöht, da die bestimmende Einschränkung bei der Generierung die Speicherbandbreite ist und weniger Bytes pro Gewicht weniger Bytes bedeuten, die pro Token bewegt werden müssen.

Der Genauigkeitsverlust ist nichtlinear, und das Verständnis seiner Form trennt ein solides Deployment von einem brüchigen. 8-Bit-Quantisierung ist für fast jede Aufgabe nahezu verlustfrei. 4-Bit-Quantisierung mit einem modernen K-Quant-Schema (üblicherweise als Q4_K_M bezeichnet) kostet typischerweise 1–3 Prozent auf Reasoning-Benchmarks, halbiert aber den Speicherbedarf gegenüber 8-Bit – das ist der Standard-Sweet-Spot für Edge-Deployments. Unterhalb von 4 Bit beschleunigt sich die Degradierung: 3-Bit- und 2-Bit-Builds können bei Reasoning-Aufgaben zusammenbrechen, auch wenn sie noch flüssigen Text produzieren, was sie gerade deshalb gefährlich macht, weil das Versagen bei oberflächlicher Lektüre nicht offensichtlich ist.

Der entscheidende Punkt ist, dass dieser Kompromiss aufgabenabhängig ist und gemessen, nicht angenommen werden muss. Für extraktive und vorlagenbasierte Aufgaben – Gitterreferenz aus dieser Nachricht extrahieren, diesen Bericht klassifizieren – schneidet ein 4-Bit-Modell nahe am Vollpräzisions-Basismodell ab, weil die Aufgabe die fragilen Teile des Modells nicht beansprucht. Beim mehrschrittigem Reasoning kann derselbe 4-Bit-Build genug verlieren, um relevant zu werden. Der einzige Weg, dies zu wissen, ist, einen zurückgehaltenen Evaluierungsdatensatz durch das Vollpräzisions-Basismodell, den 8-Bit-Build und den 4-Bit-Build laufen zu lassen, aufgabenrelevante Metriken zu vergleichen und den kleinsten Build zu akzeptieren, dessen Verlust innerhalb der operativen Toleranz liegt. Die Wahl des richtigen Edge-Beschleunigers für dieses Modell ist eine eigene Disziplin – siehe unsere Analyse zur Edge-AI-Hardware-Auswahl für die Verteidigung.

Quantisierungsbewusstes Training vs. Post-Training-Quantisierung

Die meisten Edge-Deployments verwenden Post-Training-Quantisierung: ein bestehendes Modell nehmen und die Gewichte direkt quantisieren, mit optionaler Kalibrierung an einem kleinen repräsentativen Datensatz. Sie ist schnell, erfordert keine Trainingsinfrastruktur und ist bei 4 Bit für die Mehrheit der Aufgaben gut genug. Quantisierungsbewusstes Training – Fine-Tuning des Modells mit im Forward Pass simulierter Quantisierung – stellt bei sehr niedrigen Bitbreiten mehr Genauigkeit wieder her, erfordert aber die Trainingspipeline und die Originaldaten. Für die meisten eingesetzten Systeme ist Post-Training-4-Bit-Quantisierung mit Kalibrierung die pragmatische Wahl; quantisierungsbewusstes Training bleibt für Fälle reserviert, in denen Sub-4-Bit-Betrieb durch Hardware-Grenzen erzwungen wird.

Hardware-Budgets und die Speicherbandbreitenwand

Die Hardware-Frage für On-Device-LLMs wird von Speicher dominiert, nicht von Rechenleistung. Autoregressive Generierung produziert ein Token nach dem anderen, und die Produktion jedes Tokens erfordert das Lesen des gesamten Satzes von Modellgewichten aus dem Speicher. Der Durchsatz in Token pro Sekunde ist daher häufiger durch die Speicherbandbreite geteilt durch die Modellgröße in Bytes begrenzt als durch den rohen arithmetischen Durchsatz. Ein Gerät mit reichlich FLOPS aber bescheidener Speicherbandbreite wird bei der Generierung unabhängig von seiner Rechenbewertung langsam sein.

Die praktische Untergrenze für ein reaktionsfähiges 7B-Klassemodell sind etwa 8 GB Arbeitsspeicher, der dem Inferenzbeschleuniger zugänglich ist, und ausreichend Bandbreite für 10–20 Token pro Sekunde. Ein Jetson Orin NX in seiner 8-GB- oder 16-GB-Konfiguration liegt genau in diesem Bereich, ebenso ein kleines robustes x86-System mit integrierter oder diskreter GPU. CPU-only-Inferenz ist für 1B–3B-Modelle vollständig praktikabel und produziert bei 7B-Modellen wenige Token pro Sekunde – akzeptabel für Batch-Zusammenfassungen ohne wartenden Bediener, nicht akzeptabel für interaktiven Einsatz. Prefill (Verarbeitung des Prompts) und Decode (Generierung der Antwort) haben unterschiedliche Engpässe: Prefill ist rechengebunden und parallel, Decode ist bandbreitengebunden und sequenziell, daher müssen sie bei der Hardware-Dimensionierung getrennt gemessen werden.

Der Key-Value-Cache: die versteckten Speicherkosten

Die Gewichtsgröße ist die Speicherkosten, für die jeder budgetiert; der Key-Value-Cache (KV-Cache) ist derjenige, der Teams überrascht. Während der Generierung speichert das Modell die Attention-Keys und -Values für jedes bereits verarbeitete Token, damit es sie nicht neu berechnen muss, und dieser Cache wächst linear mit der Kontextlänge. Bei einem 7B-Modell mit 16-Bit-Präzision kostet der KV-Cache etwa 0,5 MB pro Token; ein 8.000-Token-Kontext fügt daher rund 4 GB zu den Gewichten hinzu – häufig mehr als die quantisierten Gewichte selbst. Auf eingeschränkter Hardware ist der KV-Cache – nicht die Gewichte – das, was die nutzbare Kontextlänge begrenzt. Den KV-Cache auf 8 oder 4 Bit zu quantisieren halbiert oder viertelt dies und ist oft der Unterschied zwischen einem praktikablen Kontextbudget und einem Out-of-Memory-Fehler. Die Konsequenz ist, die Kontextlänge auf den kleinsten Wert zu setzen, den die Aufgabe benötigt, und nicht auf den größten, den das Modell unterstützt.

Runtime, Packaging und verifizierter Offline-Betrieb

Die On-Device-Runtime ist die Schicht, die die quantisierten Gewichte lädt, den KV-Cache verwaltet und der Anwendung eine Generierungsschnittstelle bereitstellt. Eine llama.cpp-basierte Engine ist die häufigste Wahl, weil sie das quantisierte GGUF-Format direkt ausführt, CPU- und Beschleuniger-Backends unterstützt und einen kleinen Abhängigkeits-Footprint hat, der einem robusten Image entgegenkommt. Unabhängig von der Runtime sollte das Modell nach dem ersten Load im Arbeitsspeicher fixiert werden, damit die sekundenlangen Ladekosten nur einmal anfallen und nicht bei jeder Anfrage, und die Anwendung sollte die Generierungslatenz als erstklassige, dem Bediener angezeigte Metrik behandeln.

Beim Packaging entscheidet sich, ob On-Device-Versprechen gehalten werden oder nicht. Die Modelldatei, die Runtime, der Tokenizer und die Prompt-Vorlagen müssen alle auf dem Geräte-Image vorhanden sein – nichts wird zur Laufzeit abgerufen. Der einzig ehrliche Test für den Offline-Betrieb ist, den gesamten Workflow mit ausgeschaltetem Funk, im Flugzeugmodus oder in einem isolierten Netzwerk zu betreiben und zu bestätigen, dass das System ohne erreichbaren Endpunkt startet und antwortet. Jeder verborgene Aufruf – ein Tokenizer-Download, ein Telemetrie-Beacon, eine Lizenzprüfung – muss gefunden und entfernt werden, denn am Edge wird er still scheitern und die Fähigkeit mit sich nehmen. Modell-Updates werden über physische Medien oder einen authentifizierten lokalen Sync geliefert, nie durch die Annahme von Konnektivität.

On-Device-LLMs erweitern auch die Angriffsfläche auf eine Weise, die ein Cloud-Modell nicht tut, da die Gewichte, Prompts und jedes Retrieval-Corpus auf einem Gerät liegen, das möglicherweise erbeutet wird. Prompt-Injection durch aufgenommene Dokumente, Datenexfiltration durch gestaltete Ausgaben und Manipulation der Modelldatei sind allesamt im Scope und müssen konzeptionell berücksichtigt werden – ein Thema, das in unserem Leitfaden zur LLM-Sicherheit für Verteidigungs-KI-Systeme eingehend behandelt wird.