Exécuter un grand modèle de langage en production ne se limite plus à entraîner, tester, déployer le modèle et surveiller des tableaux de bord. Le système moderne peut relier des prompts, des bases de données vectorielles et des sources de connaissances, puis produire des textes ouverts évalués selon le ton, la sécurité et la confiance, en plus de la précision. C’est dans ce contexte que Daniel Bryant pose, dans un article publié sur le blog de la CNCF, une question pratique : qui devrait posséder le pipeline d’IA ?
Selon l’auteur, la réponse ne consiste pas à donner à LLMOps un royaume séparé, mais à l’intégrer dans une plateforme d’ingénierie bien organisée, qui expose les capacités requises par les mêmes interfaces que celles utilisées par les équipes de développement pour les autres charges de travail.
Que signifie LLMOps ?
LLMOps désigne l’ensemble des pratiques, outils et flux de travail nécessaires pour développer, déployer et gérer les grands modèles de langage tout au long de leur cycle de vie en production. Ce cycle comprend la gestion des données, l’ingénierie des prompts, le réglage fin, le déploiement et le service d’inférence, la surveillance et l’évaluation, ainsi que la sécurité et la gouvernance.
Selon l’analyse, LLMOps ne constitue pas simplement un nouveau nom pour MLOps. Les grands modèles de langage sont plus coûteux à régler finement et à servir, tandis que l’évaluation de leurs résultats est plus difficile que la réduction des performances à un chiffre de précision clairement défini. Il ne suffit pas que le modèle soit précis ; il doit également être sûr et digne de confiance, des propriétés plus complexes à mesurer.
De plus, l’exploitation du modèle ne s’arrête pas au déploiement initial. Les modèles peuvent s’écarter de leur comportement antérieur, les coûts peuvent augmenter, les prompts peuvent cesser de fonctionner comme auparavant, et les intégrations avec les systèmes de gestion de la relation client ou les bases de connaissances internes nécessitent un suivi continu.
Un cycle de vie qui recoupe l’ingénierie des plateformes
Le cycle de vie LLMOps va de la préparation des données et de l’ingénierie des prompts — en traitant les prompts comme des éléments versionnables plutôt que comme des textes temporaires — au réglage fin de modèles de base ouverts à l’aide de bibliothèques telles que Hugging Face Transformers. Il comprend également le versionnage des modèles et des prompts ainsi que le suivi de leur provenance, la mise à disposition de l’inférence via des points de terminaison pris en charge par des unités de traitement graphique, et la surveillance fondée sur les retours humains afin de détecter la dérive et les coûts.
Chaque partie de ce cycle nécessite une infrastructure, des contrôles d’accès et un environnement d’exécution, des domaines qui relèvent déjà de l’ingénierie des plateformes. Cependant, l’auteur distingue la nature des deux domaines : l’ingénierie des plateformes est centrée sur l’infrastructure, tandis que le MLOps est centré sur les modèles. Il estime donc que la question utile n’est pas « qui possède le pipeline ? », mais « qui possède chaque couche, et existe-t-il réellement une entité qui les coordonne ? ».
Le risque de créer une pile parallèle
L’analyse divise le paysage de la livraison logicielle entre les équipes DevOps, qui peuvent être submergées par les demandes de déploiement, les équipes d’ingénierie des plateformes, qui construisent des parcours standardisés en libre-service, et les équipes MLOps, qui ont créé des piles parallèles parce que les outils DevOps n’étaient pas conçus pour gérer le versionnage des données ou surveiller la dérive. Avec l’ajout de LLMOps, une troisième pile indépendante peut apparaître pour les prompts, les bases de données vectorielles et les pipelines RAG, à l’écart de l’entité responsable de la gouvernance.
L’auteur relie cette possibilité au problème des « opérations d’IA fantômes ». Une équipe peut créer son propre pipeline RAG, connecté à une base de données vectorielle qui n’a pas été auditée, sans que l’entité responsable sache clairement ce qui fonctionne réellement. Selon l’analyse, le plus grand risque opérationnel ne réside pas seulement dans un chatbot qui produit des hallucinations, mais dans la propagation de ces capacités en dehors de la plateforme, puis dans leur maintien hors de portée de la visibilité et du contrôle.
L’auteur ne propose pas de ralentir les équipes pour empêcher cela, mais de rendre la plateforme capable de répondre rapidement aux demandes tout en intégrant la gouvernance au parcours d’utilisation lui-même. L’absence d’un parcours prêt à l’emploi peut pousser les équipes à construire leurs capacités en dehors de la plateforme, tandis que la mise à disposition d’un parcours standard contribue à ramener ces capacités dans un environnement gérable.
LLMOps au sein des couches de la plateforme
Bryant s’appuie sur la conception des plateformes présentée dans le livre blanc sur les plateformes publié par le groupe TAG App Delivery de la CNCF, qui divise l’environnement en trois couches : les produits en haut, les plateformes au milieu, en tant que couche d’intégration la moins épaisse raisonnable, et les fournisseurs de capacités en bas.
Selon cette conception, des fonctions telles que les tâches de réglage fin, les bases de données vectorielles, les journaux de prompts et les points de terminaison d’inférence peuvent être traitées comme une capacité supplémentaire de la plateforme. Comme les autres, elles nécessitent des interfaces de programmation, un versionnage et une responsabilité clairement définie. L’auteur mentionne des outils de l’écosystème CNCF susceptibles de soutenir ce modèle : Backstage présente les parcours standardisés dans la couche produit, tandis que Crossplane assemble l’infrastructure dans la couche inférieure, et que des frameworks tels que Kratix, KusionStack et KubeVela opèrent au milieu pour exposer un pipeline LLM via une interface en libre-service similaire à celle des autres services.
Des contrôles pratiques pour gouverner le pipeline
L’analyse propose que les équipes de plateformes adoptent un ensemble de contrôles pratiques :
- Des interfaces de programmation gouvernées plutôt que des scripts informels : les tâches de réglage fin, le déploiement des prompts et les points de terminaison d’inférence devraient être demandés via la même interface en libre-service que celle utilisée pour les autres besoins des développeurs.
- L’application des politiques à la demande : les limites de coût, les règles de localisation des données et les contrôles d’accès aux modèles doivent être vérifiés avant le début de la tâche, et non après l’apparition de la facture des services cloud.
- Une approbation humaine proportionnelle à l’ampleur de l’impact : tous les prompts ne nécessitent pas une approbation préalable, mais un modèle qui traite des données personnelles de clients ou prend des décisions autonomes peut l’exiger.
- Un journal d’audit clair : le journal doit répondre à des questions telles que ce qui a changé et pourquoi, que le changement concerne le modèle, le prompt ou les données, ainsi que l’identité de la personne qui l’a approuvé ou l’objet de l’approbation.
L’auteur conclut qu’un pipeline LLM est un autre consommateur automatisé des capacités de la plateforme et qu’il a besoin des mêmes garanties que le développeur humain ou l’agent autonome. Les équipes qui réussissent dans ce modèle ne choisissent pas un camp dans le débat entre DevOps, plateforme et MLOps ; elles traitent plutôt l’ensemble du pipeline comme un produit versionnable, surveillable et attentif aux coûts, avec des boucles de rétroaction continues.
En ce sens, Bryant estime que LLMOps n’annule pas la question de la responsabilité et ne la réinvente pas non plus, mais soumet les plateformes existantes à une pression accrue en raison de la taille des modèles, de leur coût élevé et de la difficulté de les évaluer. Selon lui, la solution consiste à construire une fois le parcours standard, puis à le proposer comme une capacité gouvernée au développeur, au data scientist et à l’agent intelligent, via une interface de programmation ou une interface utilisateur commune. Il indique que cette discussion se poursuit au sein de la CNCF, notamment dans le Platforms Working Group de TAG App Delivery, qui est ouvert à toute personne souhaitant y contribuer.