Inférence IA sous contraintes d'alimentation à la périphérie tactique

Tout système d'inférence IA qui quitte un centre de données pour entrer dans un environnement tactique se heurte au même obstacle : le matériel qui offre la meilleure précision de modèle consomme une puissance que la plateforme ne peut pas fournir et génère une chaleur que le boîtier ne peut pas dissiper. SWaP-C — Taille, Poids, Puissance et Coût (Size, Weight, Power, and Cost) — n'est pas une préoccupation d'ingénierie secondaire à la périphérie tactique ; c'est la contrainte de conception principale dont toutes les autres décisions découlent. Cet article couvre l'ensemble de la chaîne d'ingénierie, depuis la définition du budget SWaP-C jusqu'à la sélection matérielle, la stratégie de quantification, la méthodologie de profilage énergétique, la sélection du runtime, la gestion thermique et la conception du budget d'alimentation spécifique à la mission pour les déploiements militaires d'IA.

SWaP-C défini : pourquoi le poids et la puissance comptent plus que les TOPS bruts à la périphérie

La hiérarchie des contraintes à la périphérie tactique place les TOPS en dernier, et non en premier. Avant qu'un concepteur de système puisse s'intéresser au nombre de téra-opérations par seconde qu'une puce peut exécuter, trois questions préalables doivent trouver une réponse : la puce tient-elle dans le volume disponible, sa masse pousse-t-elle la plateforme au-delà de sa limite de charge utile, et sa consommation d'énergie dépasse-t-elle ce que la batterie ou l'alternateur de la plateforme peut fournir ? Ce n'est qu'après avoir répondu non à ces trois questions que le débit devient pertinent.

La taille contraint l'intégration physique. Un module Jetson AGX Orin mesure 100 mm × 87 mm et nécessite une carte porteuse qui ajoute encore 15 à 20 mm dans l'axe z. La trousse informatique démontée d'un soldat, le contrôleur d'une tourelle de petit calibre ou la baie de guidage d'une munition rôdeuse peuvent n'offrir qu'un volume de 60 × 60 × 25 mm pour du calcul supplémentaire. Dans ce cas, un accélérateur Hailo-8 M.2 de 34 mm × 26 mm tient là où l'AGX Orin ne rentre pas.

Le poids s'accumule à travers un système. Un module d'inférence de 300 g ajouté à la trousse d'un soldat démontable s'ajoute à une charge qui peut déjà peser 35 à 45 kg. Les programmes d'ergonomie militaire utilisent 30 % du poids corporel comme seuil de charge soutenue maximale ; chaque gramme de matériel d'inférence est en concurrence avec les munitions, l'eau et les équipements de communication pour l'allocation sous ce seuil. Sur un UAV, le poids supplémentaire réduit le temps de vol en augmentant la puissance nécessaire pour maintenir l'altitude, créant une double pénalité : plus de poids consomme plus d'énergie de batterie pour la propulsion, et il reste moins d'énergie de batterie pour la charge utile.

La puissance est la contrainte la plus impitoyable car la dépasser n'est pas seulement un problème de performance — elle peut mettre fin à la mission. L'alternateur d'un véhicule terrestre a une puissance de sortie fixe ; la batterie d'un UAV a une capacité fixe. Lorsque le sous-système d'inférence IA, la radio de communication, la suite de capteurs et les systèmes du véhicule dépassent collectivement la puissance disponible, l'unité de distribution d'énergie déleste les charges par ordre de priorité. L'inférence IA est rarement la charge la plus prioritaire. Le système conçu pour fonctionner en continu fonctionne de manière intermittente ou pas du tout.

Le coût détermine la doctrine d'expendabilité, qui à son tour contraint la sélection matérielle. Un kit de développement Jetson AGX Orin à 3 000 $ ne peut pas être installé sur une munition rôdeuse à usage unique prévue pour être consomptible. La contrainte de coût n'est pas purement économique — elle affecte également la logistique, car les modules de calcul coûteux nécessitent des chaînes d'approvisionnement sécurisées, un stockage contrôlé et des procédures de comptabilisation qui ralentissent les cycles de réapprovisionnement sur le terrain.

La figure de mérite correcte pour le matériel IA à la périphérie tactique est donc le débit d'inférence utile par watt par centimètre cube par dollar — une efficacité multidimensionnelle qu'aucun chiffre TOPS unique ne peut capturer. Pour une comparaison détaillée des performances des principales plateformes sur cette métrique composite, notre article sur la sélection de matériel IA edge pour la défense examine l'espace des compromis de manière systématique.

Panorama des accélérateurs IA : Jetson, Hailo, Coral, Qualcomm — TOPS de pointe vs débit soutenu vs enveloppe de puissance

Quatre familles de silicon couvrent la gamme pratique des déploiements à la périphérie tactique. Comprendre où chacune se situe sur la courbe TOPS/W et quels compromis architecturaux chacune représente est un prérequis à toute décision de sélection de plateforme.

La force de la famille Jetson réside dans son écosystème logiciel : Linux complet, CUDA, TensorRT et une large collection d'outils d'inférence open source. La force du Hailo-8 est son efficacité énergétique brute au niveau de l'accélérateur — son architecture dataflow distribue le graphe du réseau neuronal sur des clusters de processeurs et l'exécute de manière pipelinée, ce qui minimise les accès à la DRAM, qui est le coût d'alimentation dominant dans l'inférence GPU classique. Le Coral Edge TPU est le chemin d'intégration le plus simple pour les équipes qui utilisent déjà TFLite, mais son plafond de 4 TOPS et ses exigences strictes de compilation de graphe le limitent aux modèles plus petits. Le SoC QCS8550 de Qualcomm combine CPU, GPU et un NPU Hexagon sur une seule puce, offrant d'excellents TOPS/W dans un boîtier dérivé du smartphone qui apparaît de plus en plus dans les appareils militaires portables. Une évaluation comparative approfondie de ces plateformes figure dans notre article de comparaison des matériels IA edge.

Le débit soutenu diverge significativement des TOPS de pointe dans des conditions d'exploitation réelles. Les chiffres de TOPS de pointe sont mesurés à une utilisation de 100 % du chemin de données avec des schémas d'accès mémoire idéaux. Les charges de travail d'inférence réelles sur des architectures YOLOv8 ou RT-DETR soutiennent souvent 50 à 70 % des TOPS de pointe car le mix d'opérateurs du modèle — couches convolutives, normalisation par lots, fonctions d'activation et traitement de sortie multi-échelle de la tête de détection — ne maintient pas toutes les unités d'exécution occupées simultanément. Étalonnez toute plateforme candidate avec votre modèle réel avant de vous y engager dans une conception de plateforme.

Stratégies de quantification : INT8, INT4, FP16 — compromis précision vs puissance, PTQ vs QAT, par canal vs par tenseur

La quantification est la technique logicielle ayant le plus grand impact pour réduire la puissance d'inférence à la périphérie tactique. Réduire la précision numérique de FP32 à INT8 réduit l'empreinte mémoire du modèle de 4x et diminue proportionnellement la demande de bande passante DRAM — et puisque l'accès à la DRAM est souvent la consommation d'énergie dominante dans les charges de travail d'inférence, cela se traduit directement par une consommation d'énergie plus faible indépendamment des économies de calcul.

FP16 (virgule flottante 16 bits) est l'option la moins agressive. Elle réduit de moitié l'empreinte mémoire par rapport à FP32 et est nativement prise en charge par tous les accélérateurs IA modernes, y compris les tensor cores GPU Jetson. La perte de précision est négligeable — généralement moins de 0,2 mAP sur les benchmarks de détection standard — car la plage dynamique réduite de FP16 écrête rarement des valeurs de poids significatives dans un modèle bien entraîné. FP16 est la bonne valeur par défaut pour le premier déploiement d'un nouveau modèle lorsque la tolérance au risque de précision est faible et que l'économie d'énergie d'INT8 n'est pas nécessaire pour respecter le budget SWaP-C.

INT8 est la norme de production pour les déploiements militaires à la périphérie sous contraintes d'alimentation. Le matériel avec des unités d'exécution INT8 — Jetson Orin, Hailo-8, Coral Edge TPU — offre une amélioration de débit de 2 à 4x par rapport à FP32 à capacité de modèle équivalente, avec une perte de précision typique de 0,5 à 2 mAP. L'impact sur la précision dépend fortement de la qualité de la calibration. La quantification post-entraînement (PTQ) calibre les facteurs d'échelle INT8 en exécutant le modèle FP32 sur un ensemble de données de calibration et en enregistrant la distribution des activations à chaque couche. Le choix de l'ensemble de données de calibration est critique : calibrez sur des images provenant du capteur et de l'altitude de déploiement, et non sur un ensemble de données aériennes publiques génériques, sinon les distributions d'activations seront inadaptées et la perte de précision sera supérieure à ce que les chiffres de référence suggèrent.

L'entraînement conscient de la quantification (QAT) insère du bruit de quantification simulé dans le graphe d'entraînement afin que l'optimiseur ajuste les poids pour être robustes aux arrondis INT8. Le QAT surpasse systématiquement le PTQ de 1 à 3 mAP, avec les gains les plus importants sur les petits modèles où la variance des poids par canal est plus élevée. Le coût est une passe de fine-tuning de 10 à 50 époques — généralement 6 à 24 heures sur un GPU d'entraînement — et l'accès à l'ensemble de données d'entraînement original. Pour les programmes où la précision a un plancher strict lié à une exigence de probabilité de détection, le QAT est l'approche correcte. Pour le prototypage rapide ou les situations post-transfert où l'ensemble de données d'entraînement est indisponible, le PTQ calibré avec des facteurs d'échelle par canal est l'alternative pratique.

La quantification par canal vs par tenseur est un choix de calibration qui affecte significativement la précision des modèles convolutifs. La quantification par tenseur attribue un seul facteur d'échelle à l'ensemble du tenseur de poids d'une couche ; la quantification par canal attribue un facteur d'échelle indépendant à chaque canal de sortie. La différence est importante car les filtres convolutifs dans les modèles de détection matures ont des normes L2 substantiellement différentes entre les canaux — le réseau a appris à concentrer l'information dans certains filtres et à la supprimer dans d'autres. Imposer un seul facteur d'échelle à tous les canaux crée de grandes erreurs d'arrondi dans les filtres à haute norme. La quantification par canal préserve la précision au prix d'une table de calibration marginalement plus grande. Tous les outils de quantification TensorRT et PyTorch en production prennent en charge la quantification des poids par canal ; il n'y a aucune raison technique de choisir la quantification par tenseur pour les poids en 2026.

La quantification INT4 emballe deux valeurs par octet et atteint jusqu'à 8x de compression par rapport à FP32, mais une perte de précision de 3 à 8 mAP sur les benchmarks de détection la rend inadaptée à la plupart des applications tactiques sans QAT. Son cas d'usage principal est l'inférence de très grands modèles de langage où la bande passante DRAM, et non le calcul, est la contrainte principale. Pour les applications de détection ISR et de cibles de défense utilisant des modèles de la classe YOLOv8, INT8 est le point d'opération pratique.

# Calibration TensorRT INT8 — extrait représentatif
import tensorrt as trt

class Int8Calibrator(trt.IInt8EntropyCalibrator2):
    def __init__(self, calibration_images, cache_file):
        super().__init__()
        self.cache_file = cache_file
        self.dataset = calibration_images   # 500+ images du domaine de déploiement
        self.index = 0

    def get_batch(self, names):
        if self.index >= len(self.dataset):
            return None
        batch = preprocess(self.dataset[self.index])
        self.index += 1
        return [cuda.memcpy_htod_async(d_input, batch, stream)]

    def get_calibration_cache(self):
        if os.path.exists(self.cache_file):
            with open(self.cache_file, 'rb') as f:
                return f.read()
        return None

# Construction du moteur INT8
config.set_flag(trt.BuilderFlag.INT8)
config.int8_calibrator = Int8Calibrator(calib_images, 'calib.cache')
# La quantification par canal est la valeur par défaut dans TRT 9+

Méthodologie de profilage énergétique — instrumentation de mesure, puissance dynamique vs statique, limitation thermique dans les environnements MILSPEC

Les estimations de puissance rapportées par logiciel via les API des fournisseurs sont utiles pour la surveillance des tendances mais insuffisantes pour la validation du budget d'alimentation au niveau système. La seule source fiable de vérité est la mesure de courant en ligne sur les rails d'alimentation matériels alimentant l'accélérateur IA. L'écart entre la puissance rapportée par logiciel et la puissance mesurée peut atteindre 15 à 25 % sur les plateformes Jetson lors d'une inférence soutenue, car le firmware de gestion thermique ajuste les fréquences d'horloge de manières qui ne sont pas toujours reflétées dans les lectures instantanées de l'API.

L'approche d'instrumentation standard pour les plateformes IA embarquées utilise des amplificateurs de mesure de courant INA3221 ou INA226 placés en série avec la ligne d'alimentation de chaque rail de puissance, lus via I2C à 100–200 Hz. Sur Jetson Orin, NVIDIA expose les capteurs INA3221 embarqués via sysfs :

# Lecture des rails d'alimentation Jetson Orin via sysfs (échantillon toutes les 100 ms)
RAILS=(
  "/sys/bus/i2c/drivers/ina3221/1-0040/hwmon/hwmon1"  # VDD_GPU_SOC
  "/sys/bus/i2c/drivers/ina3221/1-0040/hwmon/hwmon2"  # VDD_CPU_CV
  "/sys/bus/i2c/drivers/ina3221/1-0041/hwmon/hwmon3"  # VIN_SYS_5V0
)
while true; do
  ts=$(date +%s%N)
  for rail in "${RAILS[@]}"; do
    pwr=$(cat "$rail/power1_input" 2>/dev/null)  # microwatts
    echo "$ts,$rail,$pwr"
  done
  sleep 0.1
done >> /var/log/power_trace.csv

La puissance statique (au repos) est la consommation de base avec le modèle chargé en mémoire de l'accélérateur et le pipeline d'inférence actif mais sans traitement de trames. Pour le Jetson Orin Nano en mode 7 W, la puissance au repos est d'environ 1,5 à 2,0 W. C'est le plancher en dessous duquel le système ne descend jamais tant que le service d'inférence est actif. Dans un modèle de cycle de service, la puissance au repos multipliée par le temps de repos détermine le coût énergétique minimal pour maintenir la capacité d'inférence disponible.

La puissance dynamique (inférence active) est la consommation supplémentaire au-dessus du repos lors du traitement actif des trames. La différence entre la puissance au repos et la puissance active représente le coût énergétique de chaque cycle d'inférence. Pour un Jetson Orin Nano exécutant YOLOv8s INT8 à 15 fps, la puissance dynamique au-dessus du repos est d'environ 4 à 6 W, pour un total de 5,5 à 8 W lors des rafales d'inférence.

La limitation thermique est le scénario de profilage de puissance le plus dangereux à omettre d'un programme de test MILSPEC. Tous les accélérateurs IA modernes ont un firmware qui réduit les fréquences d'horloge lorsque la température de la puce approche le maximum de jonction nominal. Sur les plateformes Jetson, cela est géré par le framework de gestion thermique et la limitation commence 5 à 10°C en dessous de la limite de jonction. Dans un environnement MILSPEC où le boîtier peut atteindre +70°C ambiants, une puce nominale à 85°C de température de jonction n'a qu'un budget thermique de 15°C de l'ambiant à la jonction. Si la résistance thermique de la puce à l'ambiant dépasse 15°C/W et que la puce dissipe 10 W, la température de jonction ne peut pas se stabiliser sous la limite de jonction — la limitation commence immédiatement et persiste indéfiniment. La conséquence pratique est que le débit d'inférence spécifié à température ambiante n'est pas le débit disponible sur un véhicule chaud dans un environnement désertique. Le profilage de puissance doit être conduit à la température ambiante maximale attendue avec le matériel installé dans son boîtier de production.

Système d'exploitation et sélection du runtime pour l'efficacité énergétique — bare-metal vs RTOS vs Linux, TensorRT vs ONNX Runtime vs TFLite

Le choix de l'environnement d'exploitation affecte directement la puissance au repos. Une distribution Linux complète avec un environnement de bureau, des services en arrière-plan et une pile de journalisation consomme significativement plus d'énergie au repos qu'un Linux minimal avec uniquement le service d'inférence et ses dépendances. Les déploiements bare-metal ou RTOS peuvent réduire davantage la puissance au repos en éliminant complètement le planificateur OS et les sous-systèmes du noyau, mais ils sacrifient la compatibilité de la chaîne d'outils qui rend le déploiement et la mise à jour des modèles pratiques dans un programme opérationnel.

Pour les plateformes Jetson, le chemin recommandé est un Linux minimal (Ubuntu Server ou BSP dérivé de Yocto) configuré pour un démarrage spécifique à la cible. Désactivez les services systemd non nécessaires au fonctionnement de l'inférence : supprimez le gestionnaire d'affichage, le démon NetworkManager si la plateforme utilise une configuration réseau fixe, tous les agents de télémétrie cloud et Bluetooth si le matériel le prend en charge. Le service nvpmodel doit être conservé et réglé au mode d'alimentation le plus bas qui satisfait l'exigence de latence d'inférence au débit de trame de mission. Un Jetson Orin Nano correctement allégé exécutant uniquement le service d'inférence, un démon SSH et un processus de journalisation minimal a une puissance au repos d'environ 1,2 à 1,8 W contre 2,5 à 3,5 W pour l'image développeur par défaut.

La sélection du runtime détermine comment le graphe de modèle quantifié est compilé en instructions matérielles au moment du chargement ou à l'avance. TensorRT est le runtime le plus performant pour le matériel NVIDIA Jetson. Il fusionne les noyaux d'opérateurs adjacents, sélectionne la variante d'algorithme la plus rapide pour chaque couche en fonction de la précision et de la taille de lot cibles, et exploite pleinement les capacités des tensor cores GPU du Jetson. Un modèle YOLOv8s compilé dans un fichier moteur TensorRT INT8 s'exécute à 30–45 fps à 7–9 W sur Jetson Orin Nano ; le même modèle dans une session ONNX Runtime générique sans backend TensorRT s'exécute à 12–18 fps à 10–14 W. La différence de puissance n'est pas accidentelle — la fusion de noyaux de TensorRT réduit le nombre d'allers-retours d'accès DRAM par inférence, et l'accès DRAM est le coût d'alimentation dominant.

ONNX Runtime avec TensorRT Execution Provider est l'option recommandée pour les programmes qui doivent cibler à la fois le matériel Jetson et des accélérateurs non-NVIDIA à partir de la même base de code. L'API ONNX Runtime abstrait le backend matériel, et le TensorRT EP gère la compilation et l'exécution sur Jetson tandis qu'un EP différent (DirectML, CUDA générique, CPU) gère l'exécution sur d'autres plateformes. Le bénéfice de portabilité se fait au prix d'une réduction marginale des performances par rapport à l'utilisation directe de TensorRT, typiquement 5 à 10 % de réduction du débit.

TFLite avec le délégué Edge TPU est le runtime correct pour les plateformes Coral. Il compile le graphe du modèle vers la SRAM on-chip de l'Edge TPU au moment du chargement ; toutes les opérations qui ne peuvent pas être mappées à l'Edge TPU s'exécutent sur le CPU hôte. La fraction du modèle qui revient au CPU est le principal facteur de latence et d'efficacité énergétique — un modèle avec 10 % de retour au CPU peut consommer 2 à 3x la puissance d'un modèle entièrement on-chip car le CPU hôte consomme significativement plus d'énergie par opération que le matériel dédié de l'Edge TPU. Utilisez le journal de compilation de l'edgetpu_compiler pour identifier les opérations qui ne sont pas mappées au matériel et modifiez l'architecture du modèle pour les remplacer par des équivalents compatibles Edge TPU avant de déployer en production.

Gestion thermique dans les boîtiers MILSPEC — dissipateurs thermiques, refroidissement par conduction, plage opérationnelle -40°C à +85°C

Les boîtiers MILSPEC pour l'électronique tactique spécifient généralement une plage de température opérationnelle de -40°C à +85°C selon la méthode MIL-STD-810 501/502. La borne inférieure et la borne supérieure créent des défis d'ingénierie thermique opposés. À -40°C, les appareils à semi-conducteurs peuvent ne pas démarrer de manière fiable sans préconditionnement ; à +85°C ambiants, le rejet de chaleur passif est marginal pour tout accélérateur IA dissipant plus de 3 à 4 W.

Le refroidissement par conduction est le mécanisme de rejet de chaleur dominant dans les boîtiers MILSPEC étanches où le flux d'air convectif est exclu par l'indice de protection IP. Le chemin thermique va de la puce de l'accélérateur IA à travers le boîtier, à travers un matériau d'interface thermique (TIM), à travers une plaque de diffusion thermique, à travers la paroi du boîtier et enfin vers l'environnement extérieur via la convection naturelle et le rayonnement. Chaque interface de matériau ajoute une résistance thermique, et la somme de toutes les résistances détermine l'élévation de température de la jonction de la puce à l'air ambiant.

Budget de résistance thermique — Hailo-8 dans boîtier Al étanche
==========================================================
Jonction → boîtier (package Hailo-8):      2,0 °C/W
Boîtier → TIM (pad à changement de phase, 1 mm):    0,5 °C/W
TIM → diffuseur (Al 6061, 3 mm):     0,3 °C/W
Diffuseur → paroi boîtier:          1,0 °C/W
Paroi boîtier → ambiant (150 cm² Al):  4,5 °C/W
                                        ─────────
R_th totale (j→a):                       8,3 °C/W

À P_diss = 5 W, ΔT = 8,3 × 5 = 41,5 °C
À T_ambiant = 71°C (MIL):  T_jonction = 71 + 41,5 = 112,5 °C
Max jonction Hailo-8 nominale: 125 °C → marge 12,5 °C ✓

Le choix du matériau de diffuseur thermique est significativement important. L'aluminium 6061 a une conductivité thermique d'environ 167 W/m·K et est l'alliage structurel aérospatial standard. Le cuivre (385 W/m·K) offre une conductance thermique 2,3 fois meilleure et est utilisé lorsque le diffuseur thermique doit couvrir une plus grande zone entre le boîtier de la puce et la paroi du boîtier. Les feuilles de graphite pyrolytique (700–1500 W/m·K dans le plan) sont utilisées dans les applications les plus exigeantes où l'aluminium ne peut pas satisfaire le budget thermique, mais elles sont fragiles et nécessitent une protection contre les charges de vibration et de choc — une préoccupation importante dans les applications de véhicules blindés ou de largage aérien. Pour la plupart des boîtiers IA tactiques fonctionnant avec des accélérateurs de classe Hailo-8 ou Coral, une plaque d'aluminium de 3 à 5 mm entre le module et la paroi du boîtier est suffisante si le boîtier a au moins 100 à 150 cm² de surface extérieure pour la convection naturelle.

Le démarrage à froid à -40°C exige que la carte soit alimentée avec des éléments chauffants avant d'appliquer la charge de calcul. Les modules Jetson COTS sont nominaux à -25°C (variante industrielle) pour le stockage et le fonctionnement ; certaines variantes militaires s'étendent à -40°C. En dessous de la limite inférieure nominale, les condensateurs internes peuvent ne pas se charger correctement et le stockage flash peut ne pas s'initialiser. Un chauffage résistif à thermostat consommant 3 à 5 W de la batterie de la plateforme — s'activant automatiquement lorsque la température du boîtier descend en dessous de -20°C — est une solution plus simple et plus fiable que d'attendre que les fournisseurs de semi-conducteurs spécifient un fonctionnement à -40°C. Le chauffage doit être placé entre la paroi du boîtier et la carte de calcul pour s'assurer que la température de la carte atteint la température de fonctionnement minimale nominale avant que l'alimentation principale soit appliquée.

Les tests thermiques doivent être conduits avec le boîtier de production et la configuration de montage de production. Les tests sur banc avec une carte porteuse ouverte dans une chambre thermique afficheront des températures de jonction inférieures à la configuration de production car la convection forcée du ventilateur de la chambre aide à refroidir la carte d'une manière que le boîtier étanche ne peut pas reproduire. Testez toujours dans la configuration du pire cas — boîtier étanche, cycle de service d'inférence maximal, température ambiante maximale — et documentez la température de jonction en régime permanent dans cette condition dans le dossier de qualification du système.

Conception du budget d'alimentation spécifique à la mission — modélisation du cycle de service, fréquence d'inférence vs autonomie de la batterie, modes d'alimentation liés à l'état de menace

Un système conçu pour des performances d'inférence de pointe tout au long d'une mission entière tombera en panne de batterie avant la fin de la mission ou transportera une batterie plus lourde qui ajoute du poids et du coût. Aucun des deux résultats n'est optimal. L'approche de conception correcte lie la fréquence d'inférence à l'état opérationnel, faisant fonctionner l'accélérateur IA à cycle de service élevé uniquement lorsque la situation tactique le justifie et réduisant le cycle de service — ou entrant dans un état de veille basse consommation — pendant les phases où l'inférence complète est inutile.

La modélisation du cycle de service commence par un profil de mission : une séquence ordonnée dans le temps de phases opérationnelles avec des durées estimées et des états de menace associés. Une mission de véhicule terrestre pourrait avoir une phase de transit (60 minutes, menace faible, déplacement sur un itinéraire connu sûr), une phase d'approche (20 minutes, menace élevée, entrée en territoire inconnu) et une phase de surveillance (40 minutes, menace haute, observation stationnaire). Chaque phase a une exigence d'inférence différente : 2 fps pendant le transit, 10 fps pendant l'approche, 15 fps pendant la surveillance. La consommation d'énergie dans chaque phase est la somme de la puissance au repos plus la puissance d'inférence active multipliée par la fraction du cycle de service d'inférence.

Le tableau illustre que la gestion du cycle de service réduit la consommation d'énergie d'inférence IA de 42 % par rapport au fonctionnement à la cadence de trames maximale en continu — de 20 Wh à 11,5 Wh pour une mission de 160 minutes sur une plateforme de classe Hailo-8. Sur un système avec une allocation de batterie de 40 Wh pour le sous-système IA, l'approche gérée étend l'autonomie de la batterie de 120 minutes à 210 minutes, ce qui peut faire la différence entre une plateforme qui termine la mission et une qui perd la capacité IA dans la phase finale.

Les transitions de mode d'alimentation doivent être pilotées par la machine d'état opérationnel de la plateforme plutôt que par une entrée manuelle de l'équipage, car la charge cognitive de l'équipage dans des environnements à haute menace rend la gestion manuelle peu fiable. Les entrées de la machine d'état comprennent la vitesse du véhicule (au-dessus de 15 km/h suggère le mode transit), l'état du système d'armes (armé suggère une menace élevée), le géorepérage GPS par rapport aux zones de menace connues et les commandes de remplacement explicites du commandant. Le gestionnaire d'inférence IA reçoit les transitions d'état comme des événements et ajuste la cadence de trames de la boucle d'inférence en conséquence, soit en changeant l'intervalle de veille entre les captures de trames, soit en configurant la fréquence de fonctionnement de l'accélérateur via l'API du mode d'alimentation. L'approche de conception complète pour déployer ces systèmes dans des conditions de terrain est couverte dans notre article sur l'inférence IA embarquée pour les UAV, qui applique les mêmes principes de cycle de service dans le contexte aéroporté.

Une marge de réserve doit être intégrée dans chaque budget d'alimentation. Une réserve de 20 % est un minimum — les missions tactiques dépassent routinièrement leur durée planifiée, les températures ambiantes dans les environnements désertiques estivaux dépassent les hypothèses de planification, et les mises à jour logicielles peuvent augmenter la taille du modèle ou la fréquence d'inférence entre la planification et l'exécution. Un budget d'alimentation alloué à 100 % au moment de la planification sera dépassé sur le terrain. Dimensionnez la batterie ou l'allocation d'alimentation pour couvrir 120 % de l'énergie modélisée par cycle de service, et documentez la politique de réserve dans la spécification de conception du système.