Inférence LLM sur matériel militaire de bord : exécuter des modèles de langage en environnements déconnectés

Les grands modèles de langage fonctionnant entièrement sur un nœud de bord local — sans internet, sans API cloud, sans données quittant la plateforme — ne sont plus une curiosité de recherche. Ils constituent une réalité opérationnelle pour les programmes de défense qui ont besoin d'un commandement et contrôle assisté par IA, d'une synthèse de renseignement ou d'un soutien à la décision autonome dans des environnements où la connectivité est un risque plutôt qu'un atout. Cet article couvre la pile complète : pourquoi les LLM cloud échouent tactiquement, quel matériel et quels modèles choisir, comment les quantifier et les servir efficacement, et comment sécuriser le service d'inférence sur un nœud de bord classifié.

1. le problème de connectivité

Les LLM cloud supposent une connexion haut débit stable et à faible latence. Dans les environnements tactiques, cette hypothèse échoue : l'EMCON interdit les transmissions pour éviter la détection ; la bande passante MANET sature rapidement sous les appels LLM simultanés ; les communications interdites signifient qu'une position avancée a besoin d'assistance IA précisément quand l'accès cloud est indisponible. Le routage de données sensibles via des API cloud commerciales crée également des risques OPSEC impermissibles pour les charges de travail classifiées.

2. niveaux matériels pour l'inférence LLM en périphérie

NVIDIA Jetson Orin NX 16 Go : 12–18 tok/s sur Llama 3.1 8B Q4_K_M, 15–20 W, température industrielle, chaîne d'approvisionnement défense — recommandation principale. Hailo-10 : 40 TOPS à moins de 5 W pour les nœuds à énergie contrainte. Intel Arc A770 16 Go : 20–30 tok/s pour les serveurs embarqués en véhicule. ARM sans GPU : 3–6 tok/s pour les tâches par lots hors ligne.

3. sélection de modèles : Llama, Qwen, Mistral

Llama 3.1 8B (~73 % MMLU, contexte 128K) — référence. Qwen2.5 7B (~74,2 % MMLU) — multilingue plus robuste. Mistral 7B v0.3 (~63 % MMLU) — plus petit cache KV, idéal sans GPU. Tous disponibles en GGUF pour transfert en réseau isolé.

4. pipeline de quantification

Q4_K_M GGUF : ~4,9 Go, perte de qualité de 1–3 % — choix tactique standard. Q8_0 : quasi sans perte quand la mémoire le permet. Éviter Q2/Q3 pour les sorties structurées. AWQ pour l'inférence GPU NVIDIA avec meilleure qualité INT4.

5. environnements d'exécution d'inférence

Serveur HTTP llama.cpp — par défaut pour les nœuds mono-utilisateur. Ollama — API REST, désactiver le téléchargement automatique sur les nœuds en réseau isolé. vLLM — serveurs NVIDIA multi-utilisateurs. ExLlamaV2 — 30–40 tok/s sur Orin AGX.

6. mode bord TAKpilot

TAKpilot bascule automatiquement entre Claude Sonnet (cloud) et Llama 8B local sous EMCON ou perte de connectivité — en moins de 200 ms, sans redémarrage, même interface REST.

7. ingénierie des prompts pour modèles contraints

Garder les prompts système sous 200 tokens. Utiliser des contraintes de grammaire GBNF pour la sortie JSON avec 2–3 tentatives de réessai avec retour d'erreur. Placer les exemples few-shot dans le tour utilisateur.

8. sécurité pour le déploiement LLM en périphérie

Intégrité du modèle SHA-256 à chaque chargement ; utilisateur OS dédié à faibles privilèges avec AppArmor/SELinux ; journalisation d'audit infalsifiable ; sortie réseau désactivée sur les nœuds en réseau isolé. Correspondance avec NIST SP 800-53.