LLM-Inferenz auf militärischer Edge-Hardware: Sprachmodelle in verbindungslosen Umgebungen betreiben

Große Sprachmodelle, die vollständig auf einem lokalen Edge-Knoten laufen — ohne Internet, ohne Cloud-API, ohne Datenverlust aus der Plattform — sind keine Forschungskuriosität mehr. Sie sind operative Realität für Verteidigungsprogramme, die KI-gestützte Führung und Kontrolle, Geheimdienstzusammenfassungen oder autonome Entscheidungsunterstützung in Umgebungen benötigen, wo Konnektivität eher eine Schwachstelle als ein Vorteil ist. Dieser Artikel behandelt den vollständigen Stack: warum Cloud-LLMs taktisch versagen, welche Hardware und Modelle zu wählen sind, wie man sie effizient quantisiert und betreibt und wie man den Inferenzdienst auf einem eingestuften Edge-Knoten absichert.

1. Das Konnektivitätsproblem

Cloud-LLMs wie GPT-4o oder Claude Sonnet setzen eine stabile Breitbandverbindung mit geringer Latenz voraus. In taktischen Umgebungen scheitert diese Annahme auf mindestens drei strukturell unterschiedliche Arten. EMCON (Emissionskontrolle) verbietet alle Funkübertragungen zur Vermeidung elektronischer Ortung. MANET-Bandbreite beläuft sich auf 1–10 Mbps aggregiert mit hoher Latenz, die durch gleichzeitige LLM-API-Aufrufe leicht gesättigt wird. Unterbrochene Kommunikation — Jamming, Geländemaskierung oder absichtliche Netzwerkisolierung — bedeutet, dass eine GPS- und kommunikationsunterdrückte Position genau dann KI-Unterstützung benötigt, wenn Cloud-Konnektivität am wenigsten verfügbar ist. Zudem erzeugt das Routing sensibler operativer Daten über kommerzielle Cloud-APIs OPSEC- und Klassifizierungsrisiken, die für eingestufte oder sensible Workloads oft unzulässig sind.

2. Hardware-Stufen für Edge-LLM-Inferenz

NVIDIA Jetson Orin NX 16GB ist die primäre Empfehlung: 16 GB LPDDR5 bei 102 GB/s, 1024 CUDA-Kerne, llama.cpp CUDA-Backend, 12–18 Tok/s auf Llama 3.1 8B Q4_K_M, 15–20 W. Industrietemperaturbereich, robuste Trägerplatinen, Verteidigungslieferkette. Hailo-10 bietet 40 TOPS bei unter 5 W — außergewöhnlich für leistungsbeschränkte Knoten, obwohl die LLM-Toolchain-Reife noch in der Entwicklung ist. Intel Arc A770 16GB liefert 20–30 Tok/s bei 30–35 W für fahrzeug- oder unterstandsbasierte Edge-Server. CPU-only ARM erreicht 3–6 Tok/s auf Llama 3.1 8B — langsam, aber vollständig offline und brauchbar für Batch- oder asynchrone Aufgaben.

3. Modellauswahl: Llama, Qwen, Mistral

Llama 3.1 8B (Apache 2.0): ~73 % MMLU, 128K-Kontext, zuverlässige Instruktionsbefolgung, 12–18 Tok/s auf Orin NX. Die Basisempfehlung. Qwen2.5 7B (Apache 2.0): ~74,2 % MMLU, stärkere mehrsprachige Leistung für Koalitionseinsatz — chinesischen Ursprung bei Beschaffungsprüfungen für eingestufte Programme beachten. Mistral 7B v0.3 (Apache 2.0): ~63 % MMLU, kleinster KV-Cache, am besten für CPU-only-Knoten, wo Durchsatz kritisch ist. Alle drei sind als GGUF auf Hugging Face für Air-Gap-Transfer verfügbar.

4. Quantisierungs-Pipeline

GGUF (llama.cpp) ist der Standard für den Edge — portabel über CPU-, gemischte und GPU-Inferenz. Q4_K_M: ~4,9 GB für 8B-Modelle, 1–3 % Qualitätsverlust gegenüber FP16, standardmäßige taktische Wahl. Q8_0: ~8,5 GB, nahezu verlustfrei, bevorzugt wenn Speicher vorhanden. Q2/Q3 für strukturierte Ausgaben oder mehrstufige Schlussfolgerungsaufgaben vermeiden. AWQ zielt auf NVIDIA-GPU-Inferenz mit besserer INT4-Qualität als naive Quantisierung — mit vLLM auf leistungsstärkeren Edge-Servern verwenden. GPTQ ist der ältere Standard mit breiter Tooling-Unterstützung; AWQ wird für neue GPU-Deployments bevorzugt.

5. Inferenz-Laufzeitumgebungen

llama.cpp mit HTTP-Server ist der richtige Standard für Einzelbenutzer-Edge-Knoten. Ollama kapselt llama.cpp mit REST API und CLI — Auto-Download auf Air-Gap-Knoten deaktivieren, als dedizierter Benutzer mit eingeschränkten Rechten ausführen. vLLM (nur NVIDIA) fügt PagedAttention und kontinuierliches Batching für Mehrbenutzer-Edge-Server hinzu (10+ gleichzeitige Benutzer). ExLlamaV2 erreicht 30–40 Tok/s auf Orin AGX mit EXL2-Quantisierung — maximaler Einzelgrafikkarten-Durchsatz, aber komplexere Toolchain.

6. TAKpilot Edge-Modus

TAKpilot überwacht die Konnektivität kontinuierlich und leitet bei verfügbarem Uplink an Claude Sonnet (Cloud) weiter, schaltet bei EMCON oder Konnektivitätsverlust automatisch auf lokales Llama 8B um — unter 200 ms Umschaltlatenz, kein Neustart, dieselbe REST-Schnittstelle. Der Edge-Modus kürzt Systemprompts automatisch, aktiviert grammatikbeschränkte JSON-Ausgabe und begrenzt die Antwortlänge.

7. Prompt Engineering für eingeschränkte Modelle

Systemprompts unter 200 Token halten. Strukturierte Ausgabe mit GBNF-Grammatikbeschränkungen (llama.cpp) oder Ollamas Format-Parameter erzwingen, plus anwendungsschichtige JSON-Validierung mit 2–3 Wiederholungsversuchen, die Fehler als Korrekturprompts zurückleiten. Few-Shot-Beispiele in den Benutzer-Turn statt in den Systemprompt legen für bessere Token-Effizienz und Formatkonformität bei kleineren Modellen.

8. Sicherheit für Edge-LLM-Deployment

Vier erforderliche Kontrollen: (1) SHA-256-Integritätsprüfung der Modelldateien bei jedem Laden; (2) dedizierter Betriebssystem-Benutzer mit eingeschränkten Rechten und AppArmor/SELinux-Policy, die den Inferenzdienst isoliert; (3) manipulationssichere Audit-Protokollierung jeder Anfrage und Antwort; (4) ausgehender Netzwerkverkehr auf Air-Gap-Knoten über iptables deaktiviert, auf die Service-UID beschränkt. Diese Kontrollen entsprechen NIST SP 800-53 und unterstützen die ATO-Dokumentation.