Alors que certaines organisations commencent encore à mettre en œuvre leurs stratégies d’IA, d’autres en sont au purgatoire pilote, avec peu d’expériences ou de preuves de concept (POC) atteignant la production. Selon The State of AI in the Enterprise, seulement 25 % des organisations ont mis en production 40 % ou plus de leurs expériences d’IA.
Nous avons discuté de la fourniture de preuves de concept d’IA importantes lors d’un récent Coffee With Digital Trailblazers sur LinkedIn Live. L’une des principales raisons pour lesquelles les POC échouent est lorsqu’ils ne s’alignent pas bien avec la stratégie commerciale de l’IA ou n’ont pas de résultats commerciaux définis. Deux autres problèmes : il n’y a pas de programme suffisant de gestion du changement en matière d’IA, ou les employés ne sont pas impliqués dans le processus de développement.
Mais il existe également un problème technologique important : l’architecture utilisée pour entraîner les modèles d’IA et développer des agents d’IA peut être très différente de celle utilisée pour l’inférence d’IA, exécutant un modèle entraîné pour générer des résultats en production. La formation et l’inférence ont des exigences de performances, d’évolutivité, de conformité et de sécurité très différentes, et il est faux de supposer que l’inférence de l’IA est une version agrandie ou réduite de l’architecture de formation.
« L’attention du secteur passe rapidement de la formation de modèles pionniers à l’optimisation de l’inférence de l’IA dans les environnements de production », déclare Pascal Jaillon, vice-président senior des produits chez OVHcloud US. « Les entreprises se rendent compte que le succès à long terme de l’IA dépend moins de la taille brute du modèle que de l’équilibre entre latence, évolutivité, sécurité et économie de l’infrastructure dans les environnements distribués. À mesure que les charges de travail d’inférence évoluent, les organisations évaluent de plus en plus d’alternatives aux stratégies traditionnelles basées uniquement sur les hyperscalers pour améliorer la rentabilité, la souveraineté des données et la flexibilité opérationnelle. »
L’optimisation de l’environnement d’inférence de l’IA doit également tenir compte des conditions d’exploitation, des exigences de conformité et des compromis en matière de coûts. Rick Ross, éminent technologue chez EY, déclare : « Pour les DSI, l’inférence localisée est un choix architectural délibéré réservé aux applications sensibles à la latence comme la robotique, ou lorsque la réglementation l’exige. »
Attendre une expérience d’IA ou un POC réussi avant d’envisager son architecture d’inférence peut être une erreur. Cela peut entraîner des retouches imprévues ou ajouter des complexités qui nécessitent de redémarrer le processus de développement. Voici cinq bonnes pratiques pour développer une architecture, une infrastructure et des opérations d’inférence d’IA efficaces.
1. Architecte d’intégration et de performance
Les architectures de formation sont conçues pour répondre à des exigences de débit et de données flexibles, tandis que l’inférence nécessite une faible latence, une fiabilité élevée et un fonctionnement autonome. Les environnements d’inférence pour les agents IA doivent également prendre en compte la manière dont les flux de travail seront orchestrés avec les serveurs MCP (Model Context Protocol) et les intégrations agent à agent (A2A).
« Les équipes informatiques doivent d’abord moderniser les couches d’intégration et d’orchestration, en s’assurant qu’elles peuvent prendre en charge des interfaces événementielles, à faible latence et haute fiabilité avant que les systèmes d’IA ne soient déployés à grande échelle », déclare Riki Efraim-Lederman, président de division d’Amdocs Studios chez Amdocs. « De nombreux environnements existants semblent fonctionnels parce que les humains compensent les lacunes en coulisses, mais une fois que les systèmes d’IA commencent à agir de manière autonome, ce filet de sécurité disparaît et ces faiblesses font rapidement surface. »
À mesure que les organisations déploient davantage d’agents d’IA et que leur utilisation augmente, les équipes de développement doivent prendre en compte les exigences de latence pour différents cas d’utilisation et les exigences de performances en charge de pointe.
« Les équipes informatiques sous-estiment la rapidité avec laquelle la complexité s’accroît en raison d’un trafic imprévisible, de pipelines de données sensibles et d’agents d’IA s’exécutant sur des API et des chaînes d’outils opaques », déclare Sridhar Iyer, directeur principal de l’IA/ML chez Versa. « L’inférence IA nécessite de plus en plus une architecture distribuée, déplaçant les charges de travail de manière dynamique entre les emplacements cloud, sur site et en périphérie en fonction de la latence, de la souveraineté et du coût.
Les environnements de formation nécessitent souvent de la flexibilité pour accéder à plusieurs sources de données à grande échelle afin de tester et d’optimiser les modèles d’IA. Cela contraste avec les environnements d’inférence, qui se connectent souvent à moins de sources de données d’exécution et où la disponibilité et la latence sont des considérations de conception clés.
« L’inférence en périphérie ou dans des environnements distribués ne fonctionne que lorsque la base de données correspond à cette architecture : locale, cohérente et hautement disponible », explique Phillip Merrick, PDG et cofondateur de pgEdge. « Les équipes informatiques ont tendance à traiter la décision relative à l’infrastructure et la décision relative aux données comme des flux de travail distincts, mais ce n’est pas le cas, et il s’agit de la même décision.
2. Sécurisez les données et les actions de l’IA
Dans les environnements de formation, le service informatique peut bloquer les accès extérieurs, masquer les données sensibles et limiter les actions aux environnements de test. Une stratégie sécurisée dès la conception est nécessaire pour les environnements d’inférence dans lesquels les agents d’IA accèdent aux données en temps réel, automatisent les actions sur les plates-formes SaaS de production et nécessitent des évaluations de sécurité dynamiques autour des autorités décisionnelles.
« L’inférence est le moment où un modèle passe de l’expérimentation aux opérations réelles, touchant des données réelles, de vrais services et de vrais flux de travail commerciaux », explique Gal Ordo, cofondateur et CPO chez Native. « À ce stade, les questions cruciales sont de savoir à quoi le modèle est autorisé à accéder, quelles actions il peut déclencher et quelles conditions doivent toujours être remplies pendant son exécution. Rendre les limites explicites dès le départ, afin que l’inférence fonctionne dans un environnement contrôlé et déterministe. «
Étant donné que les décisions de l’IA sont non déterministes, l’observabilité, l’audit et la surveillance sont essentiels pour éviter les agents malveillants, signaler les dérives du modèle et alerter rapidement en cas de modèles d’utilisation inattendus.
« Les services informatiques doivent traiter l’inférence de l’IA comme une autre charge de travail présentant des caractéristiques inhabituelles en matière d’identité, de données et de coûts », déclare Mike Toole, directeur de la sécurité et de l’informatique chez Blumira. « Il est essentiel de choisir où il s’exécute en fonction de la sensibilité de ce qui se passe dans l’invite et d’appliquer les mêmes contrôles d’accès, de journalisation et de révision que vous appliqueriez à tout SaaS touchant aux données de production. »
3. Exigences distinctes de formation et d’inférence
Les environnements de formation peuvent nécessiter des puces GPU et d’autres architectures hautes performances. Pour en déduire, l’infrastructure doit se concentrer sur la conformité, la latence, le coût et d’autres exigences non fonctionnelles. Les différentes exigences se traduisent souvent par des infrastructures distinctes.
« À mesure que le calcul devient de plus en plus distribué, le processeur devient un composant essentiel des charges de travail d’inférence, et avec l’explosion des agents, le calcul est leur lieu de résidence », déclare Michael Reid, PDG de Megaport. « Dans le même temps, l’inférence agit comme un multiplicateur de trafic nord-sud, augmentant considérablement les demandes de transfert de données et exerçant une plus grande pression sur la capacité du réseau. L’optimisation complète de l’inférence de l’IA nécessite donc un environnement unifié où le calcul, le réseau et le stockage fonctionnent en étroite collaboration. »
Les systèmes Web optimisent les performances en incluant une couche de mise en cache. Dans les architectures d’inférence d’IA, la mise en cache réduit également les calculs redondants et le coût GPU associé,
« Chaque requête qui retraite les mêmes entrées à partir de zéro brûle des cycles GPU à plein coût », déclare Junchen Jiang, cofondateur et PDG de Tensormesh. « La mise en cache des valeurs clés élimine cette redondance, réduisant ainsi considérablement la latence et les dépenses GPU. Les équipes informatiques qui intègrent dès le départ la mise en cache dans leur architecture d’inférence seront en mesure d’évoluer sans factures d’infrastructure incontrôlables. »
Les grandes entreprises devront envisager une infrastructure hybride basée sur des exigences de conformité et de performances. Par exemple, les agents d’IA et les applications impliquant la sécurité humaine devront évaluer l’infrastructure de périphérie et sur site, tandis que les opérations de back-office pourront s’exécuter entièrement sur des cloud publics.
« La plus grande erreur que commettent les entreprises avec l’inférence de l’IA est de la traiter comme une décision de modèle alors qu’il s’agit en réalité d’une décision de modèle opérationnel », déclare Andrea Malagodi, CIO chez Sonar. « L’endroit où l’inférence s’exécute, que ce soit dans le cloud, sur site ou en périphérie, affecte directement la latence, le coût, l’exposition des données et la résilience.
4. Concevoir pour des opérations flexibles et résilientes
Les architectures d’inférence ne sont pas construites une seule fois, puis mises à l’échelle, comme le sont les applications Web. Les architectes doivent planifier l’évolution des modèles, de l’infrastructure, de la sécurité et de la gestion des données à mesure que la technologie, la conformité et la tarification évoluent.
« L’inférence d’IA devient rapidement une charge de travail de production essentielle qui nécessite des opérations cohérentes et automatisées dans des environnements de cloud hybride et une chaîne de confiance claire du modèle au déploiement », déclare Tushar Katarki, responsable produit Gen AI Foundation Model Platforms chez Red Hat. « L’Open Source et les normes ouvertes sont ici essentielles ; ils donnent aux entreprises la transparence nécessaire pour sécuriser leur pile d’IA et la flexibilité nécessaire pour exécuter l’inférence partout où leur activité l’exige. »
L’une des sources de changement réside dans les capacités, les performances et les coûts du modèle d’IA. Ayaz Ahmed Khan, directeur principal de l’ingénierie chez Cloudways, déclare : « Les modèles s’améliorent à une vitesse vertigineuse, et dès que le modèle est modifié, les invites et les garde-fous doivent être soigneusement évalués, revus et modifiés. »
Une autre préoccupation concerne le suivi de l’utilisation et des interactions avec les plateformes SaaS, les sources de données et d’autres agents d’IA. Shannon Weyrick, CTO et cofondatrice de NetBox Labs, déclare : « Les équipes informatiques doivent acheminer le trafic de l’IA via un point de contrôle unique qui offre une visibilité sur les modèles utilisés, les données qui quittent l’organisation et la manière dont les coûts s’accumulent, car vous ne pouvez pas sécuriser ou gérer ce que vous ne pouvez pas voir.
Matt Waxman, directeur produit chez Precisely, affirme que le défi le plus sous-estimé dans l’inférence de l’IA d’entreprise n’est pas le modèle, mais les données qui le sous-tendent. « Les invites et les pipelines de récupération proviennent de dizaines de sources avec une sémantique incohérente, une lignée manquante et aucune couche de gouvernance, et le modèle n’a aucun moyen de le savoir. Dans un monde agentique, où les systèmes d’IA agissent de manière autonome et à grande échelle, cette base devient encore plus critique », explique Waxman.
David Mytton, PDG et fondateur d’Arcjet, partage un problème pratique rencontré par son entreprise avec l’inférence de production. « Chaque modèle veut devenir sa propre API avec différentes formes de requêtes, contrôles de santé, métadonnées, comportement de préparation, formats d’erreur et champs de réponse. Cela ne s’adapte pas une fois que vous avez plusieurs modèles ou back-ends », explique Mytton. Arcjet a construit une abstraction en utilisant le protocole d’inférence ouvert en plus de ses modèles de sécurité d’IA pour fournir des services d’inférence avec une forme standardisée pour l’activité, la préparation, les métadonnées, les itinéraires de modèle versionnés et les entrées et sorties de style tenseur.
5. Optimiser les coûts et l’évolution des modèles d’IA
Les organisations qui passent de dizaines à des milliers d’agents d’IA devront faire progresser leurs programmes finops pour tenir compte de l’impact de la sélection et de l’optimisation des modèles d’IA sur les coûts.
« À mesure que les équipes passent des prototypes mono-agent aux pipelines multi-agents, les coûts d’inférence n’augmentent pas de manière linéaire. Un système multi-agent peut brûler 15 fois plus de jetons qu’une seule interaction par chat », explique Andrew Marshall, vice-président du marketing produit chez Yugabyte. « Ce multiplicateur est un problème de données, pas un problème de modèle, basé sur la quantité de contexte transmis entre les agents, la quantité récupérée de manière redondante et la quantité d’état qui doit être reconstruite à partir de zéro à chaque appel. »
En plus de modifier les modèles d’IA, les architectes doivent considérer que les modèles frontières utilisés pendant la formation peuvent aider à développer des modèles plus petits et plus efficaces qui sont ensuite utilisés pour l’inférence.
Jason Rolles, PDG et directeur général de BlueOptima, déclare : « Les LLM évoluent rapidement vers deux grandes catégories : les modèles frontières à l’échelle du cloud qui resteront probablement l’apanage des hyperscalers, et les modèles spécialisés plus petits et hautement distillés déployés à la périphérie de l’entreprise. Cela donne aux entreprises la possibilité d’acheminer les tâches de bas niveau et peu ambiguës vers des modèles plus petits, tout en exploitant des modèles frontières pour les décisions qui nécessitent du raisonnement et de la précision, ce qui permet de réduire les coûts globaux.
Andrew Filev, PDG et fondateur de Zencoder, déclare : « Une fois que les agents sont devenus utiles, l’utilisation a été multipliée par 10, les contextes ont explosé et les entreprises ont commencé à payer des prix de modèle frontière pour chaque jeton. Beaucoup brûlent désormais leur budget annuel d’IA en quelques mois, et la plupart de ces dépenses proviennent de l’exécution d’un modèle phare à chaque étape, y compris des tâches simples. «
Pour augmenter le nombre de modèles et d’agents d’IA de production, les entreprises auront besoin d’un plan solide pour créer des architectures d’inférence résilientes et évolutives. Mais à mesure que l’utilisation, la conformité, la technologie et les prix changent, prévoyez de réévaluer et de faire évoluer l’architecture.
