La plupart des conversations sur l’IA en entreprise commencent toujours au mauvais endroit. Ils commencent par les modèles, les plateformes et les services cloud. Quel modèle de fondation est le meilleur ? Quel fournisseur possède le plus de GPU ? Quel outil peut créer la démo la plus flashy ? Ces questions sont importantes, mais ce n’est pas là que l’IA de production réussit ou échoue habituellement. La meilleure question est : où l’inférence devrait-elle réellement se produire ?
Cela semble simple, mais cela devient l’une des décisions architecturales les plus importantes en matière d’IA. Toutes les inférences n’appartiennent pas au cloud central. Toutes les inférences n’appartiennent pas à l’appareil. Toutes les inférences n’appartiennent pas à la limite. La bonne réponse implique généralement que les trois travaillent ensemble comme un pipeline. J’appelle cela une architecture d’inférence d’IA Edge-Cloud. Il répartit les charges de travail d’IA entre les appareils, les emplacements périphériques et les plates-formes cloud centralisées afin que les décisions sensibles à la latence soient prises à proximité de l’utilisateur ou de la machine, tandis que le raisonnement, l’agrégation, la gouvernance et le recyclage plus complexes restent centralisés.
C’est là que se dirige la prochaine génération de systèmes d’IA d’entreprise utiles.
La latence change la conception
L’IA cloud-first fonctionne bien lorsque l’utilisateur peut attendre. Un chatbot peut tolérer quelques centaines de millisecondes, parfois plus. Un workflow d’analyse de documents peut attendre quelques secondes. Un processus d’analyse par lots peut attendre des minutes ou des heures. De nombreux systèmes d’IA opérationnels ne le peuvent pas. Un robot de fabrication ne peut pas attendre un aller-retour vers une région nuageuse lointaine avant d’arrêter un processus défectueux. Une caméra de caisse de vente au détail ne peut pas dépendre d’un appel de modèle à distance pour chaque image. Un véhicule, un dispositif médical, un scanner d’entrepôt ou un contrôleur de réseau énergétique ne peuvent pas traiter la latence du réseau après coup.
Dans ces cas, l’inférence doit avoir lieu localement ou très près de la source. Cela peut signifier sur l’appareil lui-même, sur un serveur périphérique sur site, dans une installation de télécommunications périphérique ou dans un micro-centre de données régional. Le problème n’est pas l’étiquette. Le point est la proximité.
La latence n’est pas seulement une question de vitesse. C’est une question de fiabilité. Un système qui ne fonctionne que lorsque le réseau est parfait n’est pas un système de production. Si le processus métier est urgent, sensible à la sécurité ou critique à la mission, l’architecture doit assumer une connectivité, une congestion et des pannes intermittentes.
C’est pourquoi l’inférence des bords est importante.
Toutes les déductions ne sont pas égales
Une erreur que je constate souvent est de traiter l’inférence comme une seule chose. Ce n’est pas. Certaines inférences sont une simple classification. Cette pièce est-elle défectueuse ? Cette transaction est-elle suspecte ? Ce modèle sonore est-il anormal ? Une certaine inférence est une détection ou une reconnaissance. Une personne est-elle présente ? Un véhicule est-il dans la mauvaise voie ? Un actif est-il en surchauffe ?
Une autre inférence est plus complexe. Cela peut nécessiter un raisonnement en plusieurs étapes, un accès aux données de l’entreprise, un contexte historique ou une coordination entre plusieurs systèmes. Un modèle local peut détecter une anomalie, mais un flux de travail cloud central peut déterminer si l’anomalie fait partie d’un modèle plus large entre les installations.
C’est là que le modèle de pipeline est important.
Vous pouvez exécuter un petit modèle sur un appareil pour filtrer les signaux bruts. Vous pouvez envoyer uniquement les événements intéressants à un nœud périphérique pour une analyse plus riche. Vous pouvez envoyer des résultats résumés, des métadonnées et des exceptions vers le cloud pour un raisonnement plus approfondi, un examen humain, un audit ou une reconversion. Il s’agit d’une meilleure conception que de tout diffuser sur le cloud en espérant que la bande passante, le coût et la latence restent gérables.
Edge fait gagner plus de temps
Les gens justifient généralement l’IA de pointe par la latence. C’est valable, mais incomplet. L’inférence Edge peut réduire les coûts de bande passante en filtrant les données avant qu’elles ne quittent l’environnement local. Une caméra vidéo générant des séquences haute résolution en continu ne devrait pas envoyer chaque image vers un cloud central si seule une petite fraction des images compte. Un réseau de capteurs ne devrait pas pousser chaque lecture en amont si l’agrégation locale peut identifier ce qui est important.
Edge AI peut également améliorer la confidentialité et la conformité. Si les données sensibles peuvent être traitées localement et que seules les conclusions ou les fonctionnalités anonymisées sont envoyées vers le cloud, l’entreprise peut réduire son exposition. Cela est important dans les domaines de la santé, de l’industrie manufacturière, des services financiers, du gouvernement et de la vente au détail.
Cela peut également améliorer la résilience. Les systèmes locaux peuvent continuer à fonctionner lorsque le réseau se dégrade. Ils n’ont peut-être pas accès à tous les services centraux, mais ils peuvent néanmoins prendre des décisions de base et se synchroniser ultérieurement.
C’est ce que négligent de nombreuses stratégies d’IA basées uniquement sur le cloud. La centralisation est efficace jusqu’à ce qu’elle ne le soit pas.
Le cloud compte toujours
Rien de tout cela ne signifie que le cloud central disparaît. En fait, le cloud devient plus important, pas moins. Le cloud est l’endroit où les entreprises doivent gérer le cycle de vie plus large de l’IA : formation des modèles, réglage fin, contrôle des versions, évaluation, observabilité, gestion des politiques et analyse globale. C’est souvent là que appartiennent les charges de travail de raisonnement les plus lourdes, en particulier lorsqu’elles nécessitent un accès au contexte d’entreprise plus large.
Le cloud est également l’endroit où les données provenant de nombreux emplacements périphériques peuvent être combinées. Un seul magasin peut voir un modèle localement. Un fabricant peut constater un problème de qualité dans une usine. Mais le cloud peut déterminer si le même schéma apparaît dans des centaines de magasins ou des dizaines d’installations. C’est là que la centralisation crée de la valeur en transformant des événements isolés en intelligence d’entreprise.
Une erreur architecturale consiste à utiliser le cloud pour tout. L’erreur inverse consiste à pousser trop loin. Les appareils Edge sont limités. Ils ont des capacités limitées de calcul, de mémoire, d’alimentation, de stockage et de gestion. Ils peuvent être difficiles à corriger. Ils peuvent fonctionner dans des environnements difficiles. Ils peuvent être physiquement accessibles aux attaquants.
Le cloud doit se coordonner. Le bord devrait agir. Les appareils doivent détecter et réagir.
Le placement du modèle est désormais une architecture
Les entreprises doivent faire du placement de modèles une décision architecturale de premier ordre. Cela signifie décider quels modèles s’exécutent à quel endroit, pourquoi ils s’y exécutent et comment ils sont mis à jour.
Un petit modèle de vision peut fonctionner sur une caméra ou une passerelle. Un modèle moyen peut fonctionner sur un serveur Edge à l’intérieur d’une usine. Un modèle plus grand ou un flux de travail agent peut s’exécuter dans le cloud. Chaque décision de placement doit être basée sur la latence, le coût, la confidentialité, la résilience, la précision et la complexité opérationnelle.
Il en va de même pour le placement des données. Les données brutes peuvent rester locales. Les entités peuvent se déplacer vers le bord. Les résumés peuvent être déplacés vers le cloud. Les exceptions peuvent déclencher des téléchargements plus détaillés. Les données de formation peuvent être échantillonnées, anonymisées ou transférées dans des conditions contrôlées.
Il s’agit d’une architecture de systèmes distribués avec l’IA à l’intérieur.
Les opérations seront la partie la plus difficile
Exécuter l’IA sur les appareils, en périphérie et dans le cloud semble élégant jusqu’à ce que quelqu’un doive l’exploiter. Les modèles doivent être déployés, surveillés, restaurés et actualisés. La dérive doit être détectée. Les nœuds Edge ont besoin de mises à jour sécurisées. Les appareils ont besoin d’identité. Les données doivent être synchronisées. Les journaux doivent être collectés sans surcharger le réseau. Les politiques de sécurité doivent être appliquées de manière cohérente dans tous les environnements.
C’est là que de nombreux projets échoueront. La démo fonctionne car le modèle s’exécute au même endroit dans des conditions contrôlées. La production échoue car il existe 5 000 emplacements, trois profils matériels, une connectivité peu fiable, différents modèles de données locales et aucun moyen propre de mettre à jour les modèles en toute sécurité.
Les entreprises doivent concevoir le modèle opérationnel avant de mettre à l’échelle le modèle d’inférence.
Les gagnants se partageront le travail
Les meilleurs systèmes d’IA ne seront pas uniquement basés sur le cloud, uniquement en périphérie ou uniquement sur les appareils. Ils répartiront le travail intelligemment. Les décisions sensibles à la latence se produiront à proximité de la source. Un filtrage utilisant beaucoup de bande passante aura lieu localement. Le raisonnement centralisé, l’amélioration des modèles, la gouvernance et l’optimisation globale se produiront dans le cloud. C’est l’architecture qui rend l’IA pratique. Il réduit les coûts, améliore la réactivité, protège les données sensibles et offre à l’entreprise une meilleure voie d’évolution.
L’IA ne deviendra pas opérationnelle car chaque charge de travail sera envoyée au plus gros modèle dans la plus grande région cloud. Il deviendra opérationnel lorsque les entreprises placeront le bon modèle au bon endroit pour la bonne raison.
