Flexibilité des modèles TAKpilot : IA cloud, isolée et en périphérie pour les environnements tactiques

Chaque environnement tactique est différent. Certaines unités opèrent avec une connectivité persistante à haut débit vers une enclave cloud classifiée ; d'autres avancent dans des zones où le seul réseau disponible est la radio maillée dans le sac du soldat. Les copilotes d'IA qui ne fonctionnent que lorsque tout est parfait — connectivité complète, accès au cloud commercial, aucune restriction de classification — ne sont pas des outils utiles pour les opérations militaires. TAKpilot, le copilote de chat IA de Corvus Intelligence pour CloudTAK, est construit autour d'une architecture agnostique au modèle qui offre aux commandants et aux intégrateurs système un véritable choix : exécuter Claude Opus 4.7 contre l'API Anthropic pour des performances analytiques maximales, ou déployer Llama 3.3 70B sur un serveur GPU renforcé sans aucune dépendance à internet. Cet article explique comment cette architecture fonctionne, comment sélectionner le bon modèle selon le contexte de mission, et comment configurer TAKpilot pour des déploiements isolés en périphérie, étape par étape.

Pourquoi l'agnosticisme au modèle est essentiel pour les déploiements de défense

Les produits d'IA commerciaux codent généralement en dur un seul fournisseur. Cette approche crée une dépendance forte à la connectivité internet, à la disponibilité de l'API commerciale et aux conditions de traitement des données du fournisseur — des contraintes souvent incompatibles avec les environnements classifiés ou opérationnellement sensibles. L'architecture de TAKpilot résout ce problème en abstrayant l'accès aux modèles derrière une interface unique : la spécification API compatible OpenAI. Tout modèle qui parle ce protocole — qu'il soit hébergé par Anthropic, AWS, Google, ou un serveur d'inférence local tournant sur le même rack que le nœud CloudTAK — est un backend TAKpilot valide.

Il ne s'agit pas d'une flexibilité théorique. TAKpilot est déployé opérationnellement avec les forces de défense ukrainiennes, où les conditions réseau, les contraintes de connectivité et les exigences de classification varient considérablement à travers la force. Un élément de quartier général avec une connectivité fiable utilise Claude Sonnet 4.6 via l'API Anthropic. Une unité avancée déployée avec uniquement une connectivité radio tactique exécute Llama 3.3 8B sur un nœud d'inférence local. Les deux unités interagissent avec la même interface TAKpilot ; seul le backend diffère.

Guide de sélection de modèle : adapter la capacité au contexte de mission

TAKpilot prend en charge trois niveaux de modèles Claude via l'API Anthropic, ainsi que toute la gamme de modèles ouverts via l'interface compatible OpenAI. Le choix entre eux implique des compromis entre la profondeur de raisonnement, la latence, le coût opérationnel et les exigences de connectivité.

Claude Opus 4.7 : analyse multi-étapes complexe

Opus 4.7 est le modèle Claude à la plus haute capacité et le choix approprié pour les tâches nécessitant un raisonnement multi-étapes soutenu : synthèse de rapports ISR provenant de sources multiples, génération d'ordres de mission détaillés à partir d'instructions fragmentaires, ou analyse de données de capteurs ambiguës où les faux positifs ont de graves conséquences opérationnelles. Le compromis est la latence — Opus 4.7 produit des tokens plus lentement que Sonnet ou Haiku, et le coût par token est plus élevé. Pour les travaux d'analyse S2 et S3 au niveau du quartier général où le temps de réponse se mesure en minutes plutôt qu'en secondes, Opus 4.7 est la sélection appropriée. Il nécessite une connectivité à l'API Anthropic ou à AWS Bedrock / Google Vertex avec le modèle Opus activé.

Claude Sonnet 4.6 : performances équilibrées pour la gestion quotidienne du COP

Sonnet 4.6 est le modèle recommandé par défaut pour les opérations actives où les opérateurs émettent des commandes COP conversationnelles — placement de marqueurs, interrogation des positions d'unités, création de packages de données, abonnement à des canaux. Il offre une précision élevée de suivi d'instructions et d'utilisation d'outils à une latence plus faible qu'Opus, ce qui le rend suffisamment réactif pour une utilisation interactive sans le surcoût lié à l'exécution d'Opus pour chaque placement de marqueur sur la carte. Sonnet 4.6 est le modèle utilisé dans le déploiement opérationnel de TAKpilot avec les forces ukrainiennes comme configuration de base pour les éléments connectés.

Claude Haiku 4.5 : priorité à la vitesse pour les tâches à haute fréquence

Haiku 4.5 est optimisé pour la latence et le débit. C'est le choix approprié pour les commandes à haute fréquence et bien structurées — interrogation des pistes actuelles, listage des missions, récupération des données de position pour des indicatifs spécifiques — où la tâche est suffisamment routinière pour ne pas nécessiter une capacité de raisonnement maximale. Haiku répond plus rapidement que Sonnet et à un coût par token nettement inférieur, ce qui compte dans les environnements où TAKpilot gère un volume élevé de requêtes d'opérateurs sur plusieurs sessions simultanées. Il constitue également un modèle de repli approprié pendant les périodes de pression sur le taux de l'API.

Modèles ouverts pour les environnements isolés

Lorsque la connectivité cloud est indisponible ou que les exigences de classification interdisent les appels API externes, TAKpilot route l'inférence vers un modèle hébergé localement via l'endpoint compatible OpenAI. Trois modèles ont été validés pour les schémas d'utilisation d'outils de TAKpilot :

• Llama 3.3 70B — Le modèle à 70B paramètres affiné par instructions de Meta offre la meilleure précision d'utilisation d'outils parmi les modèles ouverts validés avec TAKpilot. En quantification 4 bits (Q4_K_M), il tient sur un serveur à deux GPU ou un A100 unique et délivre 25 à 40 tokens par seconde — suffisant pour les interactions COP conversationnelles. Il s'agit du modèle isolé recommandé par défaut pour les déploiements en périphérie bien équipés.
• Qwen 2.5 72B — Le modèle Qwen 2.5 d'Alibaba à 72B paramètres offre des performances comparables à Llama 3.3 70B sur les appels d'outils structurés et présente de meilleures performances multilingues, ce qui peut être précieux pour les opérations de coalition ou les unités non anglophones. Les exigences matérielles sont similaires.
• Mistral Large — Le modèle affiné par instructions de Mistral est disponible comme option de déploiement local et performe bien sur les tâches de classification et de routage. C'est un choix raisonnable lorsqu'une empreinte plus petite est requise et que la charge de travail de commandement est relativement structurée.
• Llama 3.3 8B — Pour les environnements très contraints en matériel (GPU grand public unique, 8 à 12 Go de VRAM), la variante 8B en quantification 4 bits offre des performances acceptables pour les requêtes COP simples. Les séquences d'outils multi-étapes complexes se dégraderont par rapport au modèle 70B, les opérateurs devront donc employer des formulations d'instructions plus explicites.

Backends cloud pour les environnements classifiés : AWS Bedrock et Google Vertex

Tous les déploiements cloud ne sont pas équivalents du point de vue de la classification et de la résidence des données. L'API Anthropic envoie le trafic d'inférence vers l'infrastructure d'Anthropic. Pour les environnements qui exigent que les données restent dans une enclave cloud spécifique — AWS GovCloud, Azure Government, ou une instance Google Workspace for Government — TAKpilot prend en charge le routage des modèles Claude via AWS Bedrock et Google Vertex AI, qui gèrent l'hébergement des modèles dans la frontière cloud du client.

AWS Bedrock expose Claude Opus 4.7, Sonnet 4.6 et Haiku 4.5 via le SDK AWS standard. Du point de vue de TAKpilot, le changement de configuration consiste à remplacer l'URL de base de l'API et la méthode d'authentification : remplacer la clé API Anthropic par des identifiants AWS IAM (via des variables d'environnement ou un rôle d'instance) et définir TAKPILOT_PROVIDER=bedrock avec la région AWS appropriée. Les mêmes modèles Claude sont disponibles ; le trafic d'inférence reste dans la frontière réseau AWS et est soumis aux accords de traitement des données AWS du client plutôt qu'aux conditions commerciales d'Anthropic.

Google Vertex AI offre le même accès aux modèles Claude via le jardin de modèles de Google. La configuration suit le même schéma : définir TAKPILOT_PROVIDER=vertex avec un ID de projet GCP et des identifiants de compte de service. Pour les organisations opérant déjà dans les offres cloud de défense de Google, cela maintient tout le trafic d'inférence dans le périmètre de sécurité existant.

Prise en charge des endpoints compatibles OpenAI

Le chemin isolé de TAKpilot utilise la même spécification API Chat Completions d'OpenAI qui est devenue le standard de facto pour les serveurs d'inférence de modèles locaux. Cela signifie que TAKpilot est compatible avec tout environnement d'exécution d'inférence qui implémente cette interface — Ollama, vLLM, serveur llama.cpp, LM Studio, Hugging Face TGI, et tout conteneur personnalisé qui encapsule un modèle avec une couche REST compatible OpenAI.

La configuration est intentionnellement minimale. Deux variables d'environnement suffisent pour rediriger TAKpilot de l'API Anthropic vers n'importe quel endpoint local :

# Diriger TAKpilot vers un serveur d'inférence Ollama local
TAKPILOT_API_BASE=http://192.168.1.50:11434/v1
TAKPILOT_MODEL=llama3.3:70b-instruct-q4_K_M
TAKPILOT_API_KEY=ollama

# Ou vers un serveur vLLM exécutant Qwen 2.5
TAKPILOT_API_BASE=http://10.0.1.20:8000/v1
TAKPILOT_MODEL=Qwen/Qwen2.5-72B-Instruct
TAKPILOT_API_KEY=vllm-token

Lorsque TAKPILOT_API_BASE est défini, TAKpilot ne tente en aucun cas de joindre l'API Anthropic. Il n'y a pas de repli vers les modèles cloud si l'endpoint local est inaccessible — TAKpilot retournera une erreur à l'opérateur plutôt que de router silencieusement le trafic vers un endpoint non prévu. Il s'agit d'un comportement de sécurité délibéré pour les environnements classifiés.

Isolation des données par session

Quel que soit le backend de modèle utilisé, TAKpilot applique le même modèle d'isolation de session. Chaque connexion d'opérateur crée un contexte de session en mémoire qui contient l'historique de conversation, les appels d'outils en attente et toutes les données COP récupérées depuis CloudTAK pendant la session. Ce contexte n'est jamais écrit sur disque, jamais partagé avec d'autres sessions, et jamais envoyé à un endpoint autre que le backend de modèle configuré.

Lorsque l'opérateur se déconnecte — soit en fermant le panneau de chat CloudTAK, soit après un délai d'expiration de session configurable — le contexte de session est supprimé de la mémoire. Il n'y a pas de persistance de session entre les connexions. Un opérateur qui se reconnecte commence avec un contexte vierge sans connaissance des commandes ou des données récupérées de la session précédente.

Pour les déploiements isolés, la garantie d'isolation est absolue : le contexte de session ne franchit jamais une frontière réseau, car le backend du modèle est sur le même segment réseau. Les opérateurs traitant des données COP classifiées doivent utiliser le mode isolé contre un modèle local — le bac à sable par session garantit que les données classifiées sont traitées uniquement par le nœud d'inférence local et supprimées à la fin de la session.

Comment déployer TAKpilot avec Llama 3.3 sur du matériel tactique isolé

La procédure suivante suppose qu'une instance Node.js TAKpilot est déjà déployée et connectée à un serveur CloudTAK. Pour le déploiement initial de CloudTAK, consultez le guide de déploiement du serveur CloudTAK. Le serveur d'inférence doit être sur le même réseau LAN tactique que CloudTAK et TAKpilot.

Étape 1 : Provisionner un serveur d'inférence GPU sur le réseau LAN tactique

Installez Ollama sur un serveur Linux (Ubuntu 22.04 LTS recommandé) avec au moins un GPU NVIDIA. Vérifiez la reconnaissance du GPU :

curl -fsSL https://ollama.com/install.sh | sh
nvidia-smi   # doit lister le(s) GPU(s)
ollama --version

Attribuez au serveur une IP statique sur le réseau LAN tactique (par exemple, 192.168.1.50). Assurez-vous que le port 11434 est accessible depuis l'hôte TAKpilot. Par défaut, Ollama se lie uniquement à 127.0.0.1 — pour accepter les connexions LAN, définissez OLLAMA_HOST=0.0.0.0 dans l'environnement du service Ollama.

Étape 2 : Télécharger le modèle Llama 3.3

# Modèle 70B — nécessite ~40 Go de VRAM (double GPU ou A100)
ollama pull llama3.3:70b-instruct-q4_K_M

# Modèle 8B — tient sur un seul GPU de 8 Go
ollama pull llama3.3:8b-instruct-q4_K_M

La commande pull télécharge les poids du modèle via internet. Pour les environnements totalement isolés où même ce téléchargement initial est interdit, transférez le fichier modèle manuellement : téléchargez le fichier GGUF sur une machine connectée, copiez-le sur le serveur via un support amovible, et importez-le avec ollama create. La documentation d'Ollama couvre la procédure d'importation hors ligne.

Étape 3 : Vérifier l'endpoint compatible OpenAI

# Depuis l'hôte TAKpilot
curl http://192.168.1.50:11434/v1/models
# Attendu : {"object":"list","data":[{"id":"llama3.3:70b-instruct-q4_K_M",...}]}

Si la requête expire, vérifiez qu'Ollama est lié à 0.0.0.0 et qu'aucun pare-feu hôte ne bloque le port 11434.

Étape 4 : Configurer les variables d'environnement de TAKpilot

# .env ou environnement du service systemd
TAKPILOT_API_BASE=http://192.168.1.50:11434/v1
TAKPILOT_MODEL=llama3.3:70b-instruct-q4_K_M
TAKPILOT_API_KEY=ollama

# Non défini ou vide — TAKpilot ne se repliera pas sur Anthropic
# ANTHROPIC_API_KEY=

Étape 5 : Démarrer TAKpilot et confirmer le routage du modèle

Démarrez le processus Node.js TAKpilot et inspectez le journal de démarrage pour la ligne du backend de modèle. Envoyez ensuite une commande de test via l'interface de chat CloudTAK et confirmez qu'une réponse est retournée. Surveillez l'utilisation GPU du serveur d'inférence avec nvidia-smi dmon pour vérifier que l'inférence s'exécute localement.

Étape 6 : Tester l'utilisation d'outils avec une commande COP

Envoyez une commande COP structurée : « Listez toutes les unités actives dans la Compagnie Alpha. » TAKpilot doit invoquer l'outil list_units de CloudTAK et retourner une réponse formatée. Si le modèle retourne une réponse en texte brut sans invoquer d'outils, cela indique que la capacité de suivi d'instructions du modèle est insuffisante pour les schémas d'appel d'outils de TAKpilot — passez à la variante 70B ou à Qwen 2.5 72B.

Étape 7 : Valider qu'aucun trafic ne sort de la frontière réseau

# Sur l'hôte TAKpilot — capturer tout trafic non destiné au réseau LAN
tcpdump -i eth0 -n 'not net 192.168.1.0/24 and not net 10.0.0.0/8'

Envoyez plusieurs commandes TAKpilot et confirmez qu'aucun paquet n'apparaît dans la sortie tcpdump. Tout le trafic d'inférence de modèle doit rester dans le réseau LAN tactique. Si des paquets vers des IP externes sont observés, auditez la configuration d'environnement de TAKpilot — assurez-vous que TAKPILOT_API_BASE est correctement défini et que ANTHROPIC_API_KEY est absent de l'environnement.

Compromis de performance pour les tâches COP courantes

Les différences de performance pratiques entre les modèles cloud et en périphérie deviennent rapidement apparentes sur la gamme des tâches que TAKpilot gère. Les caractérisations suivantes sont basées sur le comportement observé dans les déploiements TAKpilot, et non sur des benchmarks publiés.

Le placement de marqueurs et les requêtes d'unités sont les interactions COP les plus courantes. Claude Haiku 4.5 et Llama 3.3 8B gèrent ces tâches avec précision et à faible latence. La tâche est bien structurée — l'opérateur indique où placer un marqueur, TAKpilot appelle l'API CloudTAK — et nécessite un raisonnement minimal. L'un ou l'autre modèle convient. Pour la variante 8B, les formats de coordonnées explicites (degrés décimaux ou MGRS) améliorent la précision ; le modèle peut avoir du mal avec les références de localisation ambiguës.

La gestion de missions multi-étapes — créer une mission, assigner des groupes, joindre un package de données et confirmer le résultat — exige que le modèle maintienne le contexte à travers plusieurs invocations d'outils. Claude Sonnet 4.6 gère cela de manière fiable. Llama 3.3 70B le gère avec une précision acceptable. Llama 3.3 8B a du mal avec les séquences de plus de trois appels d'outils et ne devrait pas être utilisé pour des flux de travail de gestion de missions complexes.

L'intelligence documentaire et image — traitement de PDF, d'images et de rapports de renseignement téléchargés dans la session TAKpilot — bénéficie considérablement des modèles plus grands. Claude Opus 4.7 et Sonnet 4.6 offrent la synthèse la plus cohérente de documents multipages. Les tâches basées sur la vision (analyse de pièces jointes PNG/JPG) nécessitent un modèle avec capacité de vision ; Llama 3.3 est uniquement textuel. Pour les tâches de vision dans les environnements isolés, LLaVA ou une variante Qwen-VL serait nécessaire.

Questions fréquemment posées

+Quels modèles d'IA TAKpilot prend-il en charge par défaut ?

TAKpilot est fourni avec la prise en charge de toute la famille de modèles Claude — Opus 4.7, Sonnet 4.6 et Haiku 4.5 — via l'API Anthropic ou AWS Bedrock et Google Vertex AI. Il prend également en charge tout modèle accessible via un endpoint compatible OpenAI, ce qui couvre Llama 3.3, Qwen 2.5, Mistral Large, et tout autre modèle ouvert servi par Ollama, vLLM, llama.cpp ou un conteneur d'inférence personnalisé. Le modèle actif est sélectionné via les variables d'environnement TAKPILOT_MODEL et TAKPILOT_API_BASE — sans modification du code.

+TAKpilot peut-il fonctionner sans connexion internet ?

Oui. Le chemin de déploiement isolé de TAKpilot route toute l'inférence de modèle vers un serveur d'inférence local compatible OpenAI fonctionnant sur le même réseau LAN tactique ou sur le même hôte physique. Aucun trafic ne quitte le réseau. Les opérateurs provisionnent un modèle tel que Llama 3.3 70B ou Qwen 2.5 72B sur un serveur GPU renforcé, l'exposent sur un endpoint privé (par exemple, http://192.168.1.50:11434/v1), et définissent TAKPILOT_API_BASE sur cette adresse. TAKpilot s'y connecte de manière identique à un fournisseur cloud — la couche de transport est la seule différence.

+Comment TAKpilot garantit-il que les données des opérateurs ne quittent pas le réseau ?

TAKpilot applique un bac à sable par session pour toutes les données des opérateurs. Chaque session d'opérateur reçoit un contexte isolé qui n'est jamais écrit sur disque ni partagé entre sessions. Lorsque l'opérateur se déconnecte, le contexte de session — incluant tous les messages, les résultats des appels d'outils et les références COP — est supprimé de la mémoire. Pour les modèles hébergés dans le cloud (Claude via l'API Anthropic), les politiques de données d'entreprise d'Anthropic s'appliquent ; pour les déploiements isolés avec des modèles locaux, les données ne quittent jamais le réseau LAN tactique car l'endpoint d'inférence est local. Les opérateurs traitant des charges de travail classifiées doivent toujours déployer TAKpilot en mode isolé contre un modèle hébergé localement.

+Quelles sont les exigences matérielles pour exécuter Llama 3.3 70B sur un serveur de périphérie tactique ?

Llama 3.3 70B en quantification 4 bits (GGUF Q4_K_M) nécessite environ 40 Go de VRAM. Un seul NVIDIA RTX 4090 (24 Go) est insuffisant en pleine précision ; une configuration à deux GPU ou un serveur de niveau A100/H100 est recommandé pour l'inférence complète à 70B paramètres. Pour le matériel tactique plus contraint, Llama 3.3 8B (Q4_K_M, ~5 Go de VRAM) ou Qwen 2.5 7B offrent des performances acceptables sur un seul GPU grand public. La vitesse d'inférence à 70B sur un A100 est d'environ 25 à 40 tokens par seconde, ce qui est suffisant pour les interactions COP conversationnelles avec une latence acceptable.

+TAKpilot peut-il changer de modèle en cours d'opération sans redémarrer le serveur ?

La sélection du modèle dans la version actuelle de TAKpilot est définie au démarrage via des variables d'environnement et s'applique à toutes les sessions. Le changement à chaud de modèle sans redémarrage du serveur n'est pas pris en charge dans la configuration de base. Cependant, comme TAKpilot est open source sous AGPL-3.0, les déployeurs qui ont besoin d'une sélection de modèle par session peuvent étendre l'API de configuration. Un schéma courant pour les environnements multi-classification consiste à exécuter deux instances TAKpilot sur des ports séparés — l'une connectée à un endpoint Claude cloud pour le travail non classifié, l'autre connectée à un endpoint Llama local pour les opérations classifiées — et à router les opérateurs vers l'instance appropriée via un proxy inverse.

Lecture associée : Pour une introduction à l'ensemble des capacités de TAKpilot incluant les commandes COP en langage naturel, l'intelligence visuelle et les cartes d'outils en streaming, voir Copilotes IA pour les applications tactiques et le traitement du langage naturel. Pour l'API CloudTAK utilisée par TAKpilot pour exécuter les commandes des opérateurs, voir Intégration de l'API REST CloudTAK. Pour la mise en place de l'infrastructure de serveur CloudTAK sous-jacente, voir Guide de déploiement du serveur CloudTAK.