Inférence locale vs. cloud : le cas des systèmes à faible latence.Local inference vs. cloud: the case for low-latency systems.
Certaines décisions ne peuvent pas attendre 200 ms. Retour d'expérience sur trois déploiements terrain, avec les chiffres.Some decisions can't wait 200 ms. Lessons from three field deployments, with the numbers.
La question « edge ou cloud » est mal posée. La vraie question est : quel est mon budget de latence, et qui paye si je le dépasse ? Quand on reformule ainsi, la réponse devient évidente dans neuf cas sur dix — et surprenante dans le dixième.
Nous avons déployé trois systèmes ces dix-huit derniers mois où la latence était le facteur dominant. Chacun a poussé vers une architecture différente. Les voici, sans identification client, avec les chiffres qui comptent.
Cas 1 — Contrôle qualité sur ligne
Une ligne de production à 400 unités par minute. Budget de décision : 150 ms par pièce, depuis le déclenchement caméra jusqu'au signal d'éjection. Un modèle de classification binaire tourne sur un capteur 2 Mpx.
Nous avons évalué trois options : cloud avec lien 5G privé (45 ms RTT mesurés, p95 à 180 ms), serveur local en edge computing (12 ms), et inférence directe sur un SoC embarqué dans la tête de caméra (4 ms). Le cloud a été éliminé non pas à cause de la moyenne, mais de la queue : un p99 à 320 ms aurait produit 12 rejets par heure. L'edge local tenait le budget moyen mais imposait un câblage réseau qui ne passait pas l'audit terrain. Le SoC embarqué a gagné — non pas parce qu'il était le plus rapide, mais parce qu'il était le plus prévisible.
Ce qu'on a appris
La variance compte plus que la moyenne. Un système qui tient 50 ms en moyenne mais pique à 400 ms cinq fois par heure est inutilisable sur une ligne. Dans ce monde, le tail latency est le produit.
Cas 2 — Surimpression AR mobile
Un HUD porté qui affiche des annotations contextuelles sur le monde réel. Pour que la surimpression reste ancrée sans nausée, il faut une latence motion-to-photon inférieure à 20 ms. Dans ce budget, l'inférence ne peut pas consommer plus de 8 ms.
On exclut le cloud d'office. L'edge local est exclu aussi : le lien radio lui-même consomme 15 ms en conditions favorables. Tout doit tenir dans le casque. Nous avons donc bâti un pipeline avec quantization INT8, une architecture de détection sur mesure (pas YOLO, pas MobileNet — un modèle à 2,4 Mparamètres spécifique à la tâche), et une exécution sur NPU à 3 ms.
La contrainte de latence a dicté l'architecture du modèle, pas l'inverse. C'est une inversion culturelle : on ne part plus du modèle qui donne la meilleure accuracy, on part de celui qui rentre dans le budget, puis on pousse l'accuracy jusqu'à la limite du budget.
CHIFFRE
En dessous de 20 ms motion-to-photon, moins de 5 % des utilisateurs signalent un inconfort vestibulaire. À 35 ms, c'est 40 %. La courbe n'est pas linéaire.
Cas 3 — Robot mobile d'inspection
Un robot qui patrouille un site industriel, identifie des anomalies thermiques et visuelles, et remonte les alertes. Budget de détection : 2 secondes. Contexte réseau : 4G parfois, pas de 4G souvent, liaison radio longue portée en fallback.
Ici, le cloud devient envisageable pour la partie classification fine — mais avec une dégradation gracieuse obligatoire. L'architecture finale : détection de base en local (YOLO nano quantisé, 180 ms sur Jetson Orin Nano), et second passage en cloud uniquement si le lien est disponible pour enrichissement sémantique. Si le lien tombe, le robot fonctionne à 85 % de sa capacité au lieu de 100 %. C'est acceptable.
La règle qui ressort
On ne choisit pas edge ou cloud. On répartit. Le cloud gère ce qui tolère la latence et les pannes. L'edge gère ce qui ne les tolère pas. La frontière est définie par le budget de latence et le coût d'une panne réseau, pas par une préférence architecturale.
Une grille de décision
Budget < 20 ms : embarqué obligatoire, modèle sur mesure, quantization agressive.
20–200 ms : embarqué préféré, edge local acceptable si le réseau est contrôlé.
200 ms – 2 s : hybride. Cloud pour l'enrichissement, local pour la détection primaire.
> 2 s : cloud, avec cache local pour la résilience.
Cette grille est empirique. Elle ne remplace pas une analyse projet. Mais elle économise en général deux semaines d'atermoiements architecturaux.
The "edge or cloud" question is badly framed. The real question is: what's my latency budget, and who pays if I blow it? Reframe it that way, and the answer is obvious in nine cases out of ten — and surprising in the tenth.
We've deployed three systems over the last eighteen months where latency was the dominant factor. Each pushed toward a different architecture. Here they are, without client identification, with the numbers that matter.
Case 1 — In-line quality control
A production line at 400 units per minute. Decision budget: 150 ms per part, from camera trigger to eject signal. A binary classification model runs on a 2 Mpx sensor.
We evaluated three options: cloud over a private 5G link (45 ms RTT measured, p95 at 180 ms), a local edge server (12 ms), and direct inference on a SoC embedded in the camera head (4 ms). Cloud was eliminated not on the mean, but on the tail: a p99 at 320 ms would have produced 12 false rejects per hour. Local edge held the average budget but required cabling that didn't pass the site audit. The embedded SoC won — not because it was fastest, but because it was most predictable.
What we learned
Variance matters more than the mean. A system that averages 50 ms but spikes to 400 ms five times an hour is unusable on a line. In this world, tail latency is the product.
Case 2 — Mobile AR overlay
A worn HUD displaying contextual annotations on the real world. For the overlay to stay anchored without inducing nausea, motion-to-photon latency must sit under 20 ms. Within that budget, inference can't eat more than 8 ms.
Cloud is ruled out by default. Local edge is ruled out too: the radio link itself consumes 15 ms in good conditions. Everything has to fit in the headset. So we built a pipeline with INT8 quantization, a custom detection architecture (not YOLO, not MobileNet — a 2.4 M-parameter model specific to the task), and NPU execution at 3 ms.
The latency constraint dictated the model architecture, not the other way around. That's a cultural inversion: you no longer start from the model with the best accuracy, you start from the one that fits the budget, then push accuracy to the edge of that budget.
DATAPOINT
Below 20 ms motion-to-photon, fewer than 5% of users report vestibular discomfort. At 35 ms, it's 40%. The curve is not linear.
Case 3 — Mobile inspection robot
A robot patrolling an industrial site, flagging thermal and visual anomalies, surfacing alerts. Detection budget: 2 seconds. Network context: 4G sometimes, no 4G often, long-range radio as fallback.
Here, cloud becomes viable for the fine-classification stage — but with mandatory graceful degradation. Final architecture: baseline detection local (quantized YOLO nano, 180 ms on Jetson Orin Nano), and a second cloud pass only if the link is up for semantic enrichment. If the link drops, the robot operates at 85% of its capability instead of 100%. That's acceptable.
The rule that emerges
You don't choose edge or cloud. You split. Cloud handles what tolerates latency and outages. Edge handles what doesn't. The boundary is defined by the latency budget and the cost of a network failure, not by architectural preference.