Edge AI & Physical AI : architectures d'inférence pour l'industrie lourde

L'industrie manufacturière mondiale — pesant plusieurs milliers de milliards d'euros — traverse une mutation profonde. Selon une analyse publiée par Xpert.Digital, le secteur de la construction mécanique représente à lui seul un terrain d'application gigantesque pour l'IA embarquée, avec des cas d'usage allant du contrôle qualité temps réel à la maintenance prédictive sur des machines fonctionnant 24h/24 en environnement sévère. Pour les architectes ML, la question n'est plus "peut-on déployer des modèles en edge ?" mais "comment optimiser l'inférence à contrainte énergétique et latence sub-milliseconde ?".

---

1. Fondements techniques : la contrainte triple de l'Edge industriel

Le déploiement en Physical AI — terme popularisé par NVIDIA pour désigner les systèmes d'IA capables d'interagir physiquement avec le monde réel — impose trois contraintes orthogonales qu'un déploiement cloud n'a pas à gérer :

Latence déterministe : un bras robotique exécutant une soudure laser tolère des fenêtres de décision de 1 à 5 ms. Un pipeline d'inférence classique PyTorch avec overhead CUDA ne peut structurellement pas répondre à cette exigence sans optimisations agressives.

Enveloppe thermique et énergétique : les SoC industriels typiques (NVIDIA Jetson Orin NX, Hailo-8, Qualcomm RB6) opèrent dans des TDP entre 10 et 40W. À titre de comparaison, une inférence ResNet-50 non optimisée consomme ~3 GFLOPs ; sur un Cortex-A78 à 2W alloués au compute, le budget est serré.

Robustesse aux distributions shifts : les capteurs industriels — caméras hyperspetrales, lidars ToF, capteurs vibratoires MEMS — produisent des données très différentes des datasets d'entraînement académiques. La drift de distribution est permanente (usure outil, variations d'éclairage, température ambiante).

Le passage du ML cloud vers l'IA embarquée illustre bien ce changement de paradigme pour les équipes produit, mais côté ingénierie, les implications architecturales sont profondes.

---

2. Stack technique : du modèle au silicium

2.1 Quantification : INT8, INT4 et formats mixtes

La quantification post-entraînement (PTQ) reste le levier le plus accessible. La chaîne type :

import torch
from torch.quantization import quantize_dynamic

# Quantification dynamique INT8 - baseline rapide
model_int8 = quantize_dynamic(
    model,
    {torch.nn.Linear, torch.nn.Conv2d},
    dtype=torch.qint8
)

# Mesure de la dégradation
baseline_acc = evaluate(model, val_loader)
quant_acc    = evaluate(model_int8, val_loader)
print(f"Delta accuracy: {baseline_acc - quant_acc:.3f}")
``````python
import torch
from torch.quantization import quantize_dynamic

# Quantification dynamique INT8 - baseline rapide
model_int8 = quantize_dynamic(
    model,
    {torch.nn.Linear, torch.nn.Conv2d},
    dtype=torch.qint8
)

# Mesure de la dégradation
baseline_acc = evaluate(model, val_loader)
quant_acc    = evaluate(model_int8, val_loader)
print(f"Delta accuracy: {baseline_acc - quant_acc:.3f}")

La quantification dynamique introduit typiquement une dégradation de 0.5 à 2 points sur ImageNet pour les architectures convolutionnelles, et jusqu'à 4 points sur des tâches de détection d'anomalies industrielles où la distribution est longue queue.

Pour aller plus loin, la quantification aware training (QAT) avec fake quantization réduit ce delta à moins de 0.3 point en général, au prix de 20 à 40% de temps d'entraînement supplémentaire. Sur hardware Hailo-8 (26 TOPS @ 2.5W), le gain en throughput d'un modèle INT4 vs FP16 dépasse 3×.

2.2 Compilation et optimisation graphe : TensorRT vs ONNX Runtime vs TVM

Le choix du runtime d'inférence est critique et dépend du hardware cible :

Runtime	Hardware cible	Latence typique ResNet-50	Optimisations clés
TensorRT 10.x	NVIDIA (Jetson, Xavier)	1.2 ms (INT8, batch=1)	Layer fusion, kernel auto-tuning
ONNX Runtime + EP	Multi-vendor	2.8 ms (FP16)	Graph optimization passes
Apache TVM	Générique + RISC-V	3.5 ms (tuned)	AutoScheduler, BYOC
Hailo SDK	Hailo-8/15	0.7 ms (INT8)	Dataflow architecture native

La compilation TVM mérite une attention particulière pour les déploiements sur hardware custom ou RISC-V (croissant dans l'edge industriel européen). Son MetaScheduler permet un tuning automatique qui surpasse les kernels hand-coded sur des targets exotiques.

La quantification dynamique introduit typiquement une dégradation de **0.5 à 2 points** sur ImageNet pour les architectures convolutionnelles, et jusqu'à **4 points** sur des tâches de détection d'anomalies industrielles où la distribution est longue queue.

Pour aller plus loin, la **quantification aware training (QAT)** avec fake quantization réduit ce delta à moins de 0.3 point en général, au prix de 20 à 40% de temps d'entraînement supplémentaire. Sur hardware Hailo-8 (26 TOPS @ 2.5W), le gain en throughput d'un modèle INT4 vs FP16 dépasse 3×.

### 2.2 Compilation et optimisation graphe : TensorRT vs ONNX Runtime vs TVM

Le choix du runtime d'inférence est critique et dépend du hardware cible :

| Runtime | Hardware cible | Latence typique ResNet-50 | Optimisations clés |
|---|---|---|---|
| TensorRT 10.x | NVIDIA (Jetson, Xavier) | 1.2 ms (INT8, batch=1) | Layer fusion, kernel auto-tuning |
| ONNX Runtime + EP | Multi-vendor | 2.8 ms (FP16) | Graph optimization passes |
| Apache TVM | Générique + RISC-V | 3.5 ms (tuned) | AutoScheduler, BYOC |
| Hailo SDK | Hailo-8/15 | 0.7 ms (INT8) | Dataflow architecture native |

La compilation TVM mérite une attention particulière pour les déploiements sur hardware custom ou RISC-V (croissant dans l'edge industriel européen). Son `MetaScheduler` permet un tuning automatique qui surpasse les kernels hand-coded sur des targets exotiques.

```bash
# Pipeline TVM pour target ARM Cortex-A78
import tvm
from tvm import relay, auto_scheduler

target = tvm.target.Target("llvm -mcpu=cortex-a78")
mod, params = relay.frontend.from_pytorch(scripted_model, input_shapes)

# Auto-tuning avec XGBoost cost model
tasks, task_weights = auto_scheduler.extract_tasks(mod, params, target)
tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
tuner.tune(auto_scheduler.TuningOptions(num_measure_trials=2000))
``````bash
# Pipeline TVM pour target ARM Cortex-A78
import tvm
from tvm import relay, auto_scheduler

target = tvm.target.Target("llvm -mcpu=cortex-a78")
mod, params = relay.frontend.from_pytorch(scripted_model, input_shapes)

# Auto-tuning avec XGBoost cost model
tasks, task_weights = auto_scheduler.extract_tasks(mod, params, target)
tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
tuner.tune(auto_scheduler.TuningOptions(num_measure_trials=2000))
```

### 2.3 Architectures adaptées à l'edge industriel

Les architectures **MobileNetV3**, **EfficientNet-Lite** et surtout les variantes **NAS-optimisées** (MNASNet, FBNet) dominent pour la vision. Mais l'industrie manufacturière a des spécificités :

- **Détection d'anomalies** : PatchCore, EfficientAD, et les approches flow-based (FastFlow) offrent d'excellents compromis accuracy/FLOPS avec zéro exemple d'anomalie en entraînement
- **Segmentation temps réel** : BiSeNetV2 et DDRNet sont préférables à SegFormer pour des latences < 5 ms
- **Time series industrielles** : TSMixer et PatchTST sur données vibratoires, avec des fenêtres contextuelles courtes (512 points @ 10 kHz)

---

## 3. Benchmarks représentatifs

### Détection d'anomalies visuelles (MVTec AD)

Modèle	AUROC	Latence (Jetson Orin NX, INT8)	Mémoire
PatchCore (WR50)	99.1%	45 ms	2.1 GB
EfficientAD-S	98.8%	3.2 ms	180 MB
FastFlow (WR18)	98.4%	8.7 ms	320 MB
SimpleNet	98.9%	2.1 ms	95 MB

EfficientAD-S représente le meilleur compromis pour un déploiement Jetson : moins de 4 ms de latence pour moins de 0.3 point de dégradation AUROC versus le SOTA lourd.

Throughput sur SoC edge (réseau MobileNetV3-Large, batch=1)

### 2.3 Architectures adaptées à l'edge industriel

Les architectures **MobileNetV3**, **EfficientNet-Lite** et surtout les variantes **NAS-optimisées** (MNASNet, FBNet) dominent pour la vision. Mais l'industrie manufacturière a des spécificités :

- **Détection d'anomalies** : PatchCore, EfficientAD, et les approches flow-based (FastFlow) offrent d'excellents compromis accuracy/FLOPS avec zéro exemple d'anomalie en entraînement
- **Segmentation temps réel** : BiSeNetV2 et DDRNet sont préférables à SegFormer pour des latences < 5 ms
- **Time series industrielles** : TSMixer et PatchTST sur données vibratoires, avec des fenêtres contextuelles courtes (512 points @ 10 kHz)

---

## 3. Benchmarks représentatifs

### Détection d'anomalies visuelles (MVTec AD)

| Modèle | AUROC | Latence (Jetson Orin NX, INT8) | Mémoire |
|---|---|---|---|
| PatchCore (WR50) | 99.1% | 45 ms | 2.1 GB |
| EfficientAD-S | 98.8% | 3.2 ms | 180 MB |
| FastFlow (WR18) | 98.4% | 8.7 ms | 320 MB |
| SimpleNet | 98.9% | 2.1 ms | 95 MB |

EfficientAD-S représente le meilleur compromis pour un déploiement Jetson : moins de 4 ms de latence pour moins de 0.3 point de dégradation AUROC versus le SOTA lourd.

### Throughput sur SoC edge (réseau MobileNetV3-Large, batch=1)

```
Jetson Orin NX (16GB) - TensorRT INT8  : 850 inf/s  @ 15W
Hailo-8                                 : 2100 inf/s @ 2.5W
Qualcomm RB6 (Hexagon DSP)             : 1200 inf/s @ 8W
Raspberry Pi 5 + AI HAT (RP1400)       : 380 inf/s  @ 5W

Jetson Orin NX (16GB) - TensorRT INT8 : 850 inf/s @ 15W Hailo-8 : 2100 inf/s @ 2.5W Qualcomm RB6 (Hexagon DSP) : 1200 inf/s @ 8W Raspberry Pi 5 + AI HAT (RP1400) : 380 inf/s @ 5W

L'efficacité énergétique du Hailo-8 (840 inf/s/W) dépasse d'un facteur 3× le Jetson Orin NX, ce qui en fait un choix pertinent pour des déploiements à grande échelle dans des armoires de contrôle industrielles.

---

## 4. Limitations et pièges à éviter

### 4.1 Le problème de la calibration PTQ sur données industrielles

La PTQ requiert un dataset de calibration représentatif (typiquement 100-500 échantillons). En environnement industriel, la distribution réelle inclut des conditions rares mais critiques (pièces défectueuses, conditions extrêmes) qui sont par définition sous-représentées. Une calibration sur données normales uniquement peut dégrader la précision de **8 à 15 points** sur les classes minoritaires.

**Mitigation** : utiliser des techniques de calibration robuste (entropie min/max vs percentile), et systématiquement évaluer sur un split déséquilibré reflétant la distribution réelle de production.

### 4.2 Overhead de la prétraitement et non-ML

Un piège classique : optimiser le modèle ML à 0.5 ms puis constater que le pipeline de prétraitement (décodage image, normalisation, resize sur CPU) prend 8 ms. L'utilisation de CUDA pour le prétraitement (torchvision CUDA ops, DALI) est souvent plus impactante que 10% de gain sur l'inférence modèle.

### 4.3 Dérive des modèles en production

Les modèles edge industriels ne bénéficient pas toujours d'une connexion fiable pour le retraining. Les stratégies de **continual learning** légères (EWC, ER-ACE) avec buffers de replay compact sont à considérer, mais leur implémentation sur contrainte mémoire reste un problème ouvert.

Notons que cette problématique de déploiement robuste n'est pas sans rappeler les défis d'orchestration abordés dans [MCP, le protocole qui connecte l'IA au monde réel](/articles/mcp-protocole-connecte-ia-monde-reel) — la standardisation des interfaces entre modèles et environnements physiques est un enjeu convergent.

---

## 5. Recherche & évolutions futures

### 5.1 Neural Architecture Search contraint hardware

La tendance lourde est au NAS "hardware-aware" avec contraintes LAT+MEM+FLOPS simultanées. ONAS, Once-for-All (MIT HAN Lab) et les approches supernet permettent de générer des modèles Pareto-optimaux pour un SoC donné sans retraining complet. L'intégration de ces pipelines dans les MLOps edge reste néanmoins immature industriellement.

### 5.2 Quantification sub-INT4 et formats émergents

Les formats **FP8** (E4M3, E5M2) arrivent sur les SoC edge de nouvelle génération. NVIDIA annonce le support FP8 sur les Jetson de prochaine génération. Les résultats préliminaires sur des réseaux de détection montrent une dégradation comparable à INT8 avec un gain mémoire supplémentaire de 2×.

Les **modèles binaires** (1-bit, BitNet b1.58) restent une piste de recherche active pour des modèles de langage légers sur microcontrôleurs, mais leur accuracy sur tâches visuelles industrielles n'est pas encore compétitive.

### 5.3 Physical AI : vers des boucles perception-action unifiées

La convergence entre vision industrielle et robotique vers des architectures **end-to-end differentiable** (type RT-2, OpenVLA) représente le front de recherche le plus avancé. Ces modèles vision-langage-action (VLA) nécessitent aujourd'hui des compute budgets encore incompatibles avec l'edge strict, mais la compression de ces architectures via distillation (OpenVLA-OFT réduit de 7B à moins d'1B avec dégradation < 5% sur manipulation tasks) ouvre des perspectives concrètes à horizon 2026-2027.

Les **state space models** (Mamba, S4) montrent également des promesses pour les séries temporelles industrielles longues, avec une complexité linéaire en séquence vs quadratique pour les transformers — un avantage décisif quand on traite 100 kHz de données capteur en continu.

---

## Conclusion

L'écart entre recherche ML et déploiement edge industriel se réduit, mais reste substantiel. Les ingénieurs ML travaillant sur ces sujets doivent maîtriser simultanément la compression de modèles (quantification, pruning, distillation), les runtimes d'inférence spécifiques aux SoC cibles, et les contraintes métier du domaine industriel. Le marché est réel, les outils existent — c'est l'expertise transversale qui reste la ressource rare.