Gestion des coûts du codage IA à l'échelle

Les outils de codage AI offrent une valeur immense : chez Databricks, le codage agentique a amélioré de manière mesurable chaque métrique de vélocité que nous suivons et, dans certaines équipes, a généré des gains de productivité d'un ordre de grandeur. Mais presque toutes les entreprises qui déploient des outils AI à grande échelle se sont heurtées au même mur : des coûts en croissance exponentielle. Cette courbe n'est pas viable : si rien n'est fait, elle finira par dépasser les revenus. L'explosion des dépenses place les entreprises dans une situation paradoxale : d'une part, le désir de pousser au maximum la transformation AI et de mettre des outils puissants entre les mains des employés, et d'autre part, la nécessité de composer avec un profil de coût global qui menace de compromettre, voire d'annuler, les gains d'efficacité mêmes apportés par l'AI.

Heureusement, plusieurs des premiers adoptants à grande échelle ont convergé vers un ensemble d'approches que résolvent ce casse-tête, réalisant un « double mandat » : (a) fournir un large accès aux outils AI, avec un minimum de friction, et (b) maintenir les coûts globaux dans une enveloppe à peu près fixe par utilisateur. Cet article présente des techniques éprouvées de gestion des coûts, basées sur notre expérience chez Databricks et sur des discussions avec plusieurs autres entreprises nées à l'ère du numérique, notamment Stripe, Coinbase, Uber et Ramp. Le tableau ci-dessous résume les techniques actuelles et les économies associées ; les chiffres sont indicatifs, basés sur une enquête informelle auprès d'équipes de développement :

Certaines de ces techniques peuvent être facilement mises en œuvre avec des logiciels que de nombreuses entreprises utilisent déjà. D'autres nécessitent une nouvelle infrastructure, en particulier les techniques qui modifient les clients finaux ou transfèrent le trafic entre les modèles. Chez Databricks, nous avons publié en open source ou mis à disposition gratuitement nos composants d'infrastructure clés : un méta-harnais pour l'utilisateur final (Omnigent) et notre AI Gateway (Unity AI Gateway). Pour être complet, cet article couvre également les logiciels utilisés par d'autres entreprises avec lesquelles nous avons échangé.

La « frontière d'efficacité » pour les modèles de codage

Le principal levier de réduction des coûts consiste à transférer les dépenses de codage vers des modèles plus efficaces au fur et à mesure de leur sortie. Ce point mérite que l'on s'y attarde, car la simple explication de « modèles moins chers » cache en réalité une relation nuancée entre le coût et la qualité du modèle.

Dans le langage courant, le terme modèle de pointe désigne « le modèle doté de l'intelligence la plus élevée », et les laboratoires de pointe se concentrent principalement sur l'amélioration de cette intelligence maximale. Les modèles de pointe peuvent désormais résoudre de nouveaux problèmes en mathématiques ou en cybersécurité. Mais lorsque l'AI est déployée à grande échelle, un autre type de frontière importe davantage : la frontière d'efficacité. La frontière d'efficacité est définie par l'ensemble des modèles qui offrent le meilleur rapport qualité-prix pour un niveau d'intelligence donné. La plupart des tâches de codage quotidiennes ne nécessitent pas de démonstrations mathématiques ni de nouvelles analyses de sécurité ; ce qui importe globalement, c'est donc le coût des modèles qui atteignent le niveau de qualité requis pour le travail d'ingénierie logicielle classique. Cette « frontière d'efficacité » progresse beaucoup plus rapidement que la frontière de l'intelligence, de nouveaux modèles sortant presque chaque semaine et offrant un meilleur rapport intelligence-prix que les modèles précédents.

Levier de coût n° 1 : Passer à l'open source et à des modèles moins coûteux

L'adoption rapide de modèles plus récents et plus efficaces offre les gains de coûts les plus importants de toutes les techniques. Mais pour réaliser ces gains, une entreprise doit d'abord savoir quels modèles surpassent réellement ses modèles actuels. Cela peut s'avérer difficile car les benchmarks publics reflètent mal les performances réelles sur les tâches de codage. Pour évaluer les nouveaux modèles, de nombreuses entreprises ont mis au point des évaluations automatisées qu'elles estiment plus représentatives de leur propre flux de développement interne. Databricks a récemment publié un exemple d'un tel benchmark, dans lequel nous avons constaté un rapport qualité/prix très compétitif pour les modèles GLM. Ce benchmark nous a conduits à déployer GLM auprès de nos développeurs en interne. Souvent, les nouveaux modèles ne font pas progresser la frontière d'efficacité, et les évaluations produisent fréquemment des résultats négatifs : Stripe a constaté qu'Opus 4.7 n'améliorait pas de manière significative la qualité par rapport à Opus 4.6, tout en augmentant les coûts. Ils ont donc refusé de rendre Opus 4.7 disponible en interne. Databricks a constaté des régressions de coûts similaires en comparant Opus 5.0 à 4.8.

Flexibilité du harnais et du modèle

Puisque les gains les plus importants proviennent du passage à de nouveaux modèles, l'adoption d'outils pour l'utilisateur final permettant une flexibilité des modèles devient un élément essentiel pour limiter les coûts. L'outil le plus couramment utilisé de concert avec un modèle particulier est appelé un harnais. Les modèles de pointe propriétaires sont de plus en plus co-conçus pour fonctionner de manière optimale avec des harnais spécifiques, ce qui signifie que certains harnais « fonctionnent mieux » avec certains modèles. Si une entreprise souhaite préserver l'indépendance vis-à-vis des modèles, il existe en gros deux approches :

Demander aux utilisateurs de changer de harnais. Une approche consiste à fournir aux développeurs un ensemble de harnais (Claude Code, Codex ou Cursor), puis à leur demander de passer d'un harnais à l'autre lorsqu'une entreprise souhaite migrer ses dépenses vers des modèles moins coûteux. Cela permet aux utilisateurs de travailler dans leur harnais préféré lorsque c'est possible, mais l'inconvénient de cette approche est que le coût de transition pour un développeur individuel peut être élevé. Si ces coûts de transition deviennent trop élevés, le harnais lui-même devient un facteur de dépendance (lock-in) de facto à une famille de modèles, limitant la capacité à transférer les dépenses vers des modèles plus compétitifs.

Utiliser un méta-harnais. Une nouvelle approche de plus en plus populaire consiste à utiliser un méta-harnais qui offre une expérience utilisateur commune aux développeurs tout en répartissant les requêtes vers les harnais sous-jacents (qu'ils soient propriétaires ou open source). Cette approche permet à la fois l'indépendance vis-à-vis des modèles et des harnais tout en réduisant les coûts de transition pour les développeurs. Chez Databricks, c'est le mode par défaut pour les développeurs qui utilisent Omnigent. Certaines entreprises avec lesquelles nous avons discuté ont développé des méta-harnais internes personnalisés qui s'intègrent à leur chaîne d'outils de développement.

Levier de coût n° 2 : Routage dynamique des requêtes et des tâches

Plutôt que de demander aux utilisateurs de choisir eux-mêmes les modèles adaptés à leurs tâches, un nombre croissant de recherches suggère que la sélection automatique des modèles et des outils peut optimiser encore davantage l'efficacité des flux de travail de codage agentique. Les approches de routage se divisent globalement en trois catégories :

• Routage au niveau de la requête : Un proxy avec état s'interpose entre un client (comme un harnais de codage) et les modèles de fondation sous-jacents. Le proxy tente de router les requêtes vers le modèle le moins coûteux capable de répondre à chaque requête d'inférence. Le routage pour les cas d'usage agentiques doit également prendre en compte la mise en cache côté serveur, car un accès avec cache froid (cold cache hit) représente un coût très élevé pour les charges de travail à grand contexte. Une nouvelle vague de produits affiche des premiers résultats prometteurs en matière de routage. Par exemple : Cursor Router, l'AutoRouter d'OpenRouter, la fonctionnalité Router de Ramp et la propre fonctionnalité de Smart Routing de Databricks dans Unity AI Gateway.
• Routage au niveau de la tâche (méta-harnais) : Un processus côté client répartit les tâches utilisateur vers différents harnais en fonction de la complexité de la tâche. Une tâche utilisateur peut être « renommer ce composant de X à Y » (une tâche simple) ou une tâche ouverte comme « Explorer les considérations de conception qui réduiraient la latence » (une tâche complexe). Le répartiteur, souvent appelé méta-harnais, examine quel niveau de modèle sous-jacent est requis pour une tâche, puis délègue l'intégralité de cette tâche de bout en bout au modèle. Omnigent est un exemple de méta-harnais prenant en charge ce modèle.
• Modèles d'escalade/délégation : Un seul harnais associe deux modèles (un modèle coûteux à haute intelligence et un modèle d'exécution économique). Dans certaines approches, comme l'outil Advisor de Claude, le modèle le moins cher dirige les opérations et escalade la tâche lorsqu'il estime qu'elle nécessite plus de puissance. Le modèle inverse existe également : dans Devin Fusion de Cognition, le modèle le plus coûteux gère la boucle principale et sous-traite de manière sélective le travail à un modèle moins cher.
  Les résultats internes chez Databricks suggèrent que notre Smart Router d'AI Gateway est capable de réduire systématiquement le coût moyen des tâches de plus de 30 %, tout en égalant à peu près la qualité du modèle le plus coûteux de l'ensemble de travail. D'autres entreprises avec lesquelles nous avons échangé ont constaté des résultats similaires.

Levier de coût n°3 : Offrir aux développeurs de la visibilité, des garde-fous et des budgets

Il peut sembler surprenant que cet article ne commence et ne se termine pas simplement par : « Donnez un budget mensuel aux utilisateurs et le tour est joué. » Les budgets stricts, où l'utilisation est complètement interrompue dès qu'un certain seuil de dépenses est atteint, ne sont souvent utilisés qu'en dernier recours par toutes les entreprises avec lesquelles nous avons échangé. Il y a deux raisons pour lesquelles les budgets stricts de jetons ne sont pas particulièrement efficaces pour la gestion des dépenses liées à l'AI : Premièrement, si un développeur atteint son plafond budgétaire, lui couper l'accès aux outils d'AI nuirait gravement à sa productivité. Ni l'entreprise ni l'employé ne souhaitent réellement ce résultat. Deuxièmement, au moins certains des utilisateurs à « dépenses élevées » sont en réalité ceux qui ont réalisé d'immenses gains d'efficacité grâce à l'AI et qui génèrent une productivité exceptionnelle. Décourager ces utilisateurs serait contre-productif.

Plutôt que d'imposer un plafond de dépenses strict par utilisateur, la plupart des entreprises adoptent une approche plus nuancée et progressive, axée sur la visibilité pour les utilisateurs finaux et sur l'introduction de niveaux de friction croissants à mesure que les dépenses augmentent.

1. Visibilité : Toutes les entreprises avec lesquelles nous avons discuté disposaient d'un mécanisme permettant de fournir un retour quasi instantané aux utilisateurs sur leurs dépenses en cours, et beaucoup proposaient également des conseils ou des suggestions spécifiques pour réduire les coûts en utilisant des modèles moins onéreux. Il est important que les utilisateurs puissent visualiser leurs dépenses sur l'ensemble des outils, car ils peuvent vouloir orienter leur choix vers l'outil qui leur offre le meilleur ROI.

   

   Un tableau de bord développeur chez Databricks affichant les dépenses actives

2. Seuils de dépenses : On peut demander aux développeurs de prendre des mesures ou de solliciter des approbations à différents paliers de dépenses. La forme la plus simple de seuil de dépenses est celle qui peut être auto-validée et qui sert d'avertissement lorsque le rythme des dépenses dépasse un certain seuil. Chez Databricks, nous avons constaté que ces seuils auto-validés constituent un mécanisme utile pour éviter les dépenses accidentelles ou involontaires. D'autres seuils peuvent être mis en place, nécessitant une approbation budgétaire explicite (souvent via la chaîne managériale).
3. Rétrogradation : Si un développeur atteint un seuil de dépenses, il peut être redirigé vers un modèle moins coûteux plutôt que de voir son accès aux jetons totalement suspendu. Comme les modèles les moins chers sont considérablement moins onéreux que les modèles d'intelligence de pointe, cette technique permet aux développeurs de continuer à travailler sans engendrer de dépenses continues massives.
4. Suspension : En dernier recours, la plupart des systèmes conservent la capacité de suspendre totalement l'accès d'un utilisateur aux jetons. Comme indiqué plus haut, il s'agit souvent d'une mesure purement temporaire et du point de départ d'une discussion sur la manière d'exploiter efficacement l'AI.

Levier de coût n°4 : Réduire la surcharge de jetons

Lorsqu'un utilisateur saisit une requête relativement simple dans un agent de codage AI (comme « Veuillez analyser et corriger ce bug. »), cet agent rassemble ensuite une quantité massive de contexte pertinent, appelle de nombreux outils, effectue des recherches dans la base de code et intègre des compétences ou des informations système fournies par l'entreprise. Au moment où l'inférence coûteuse du LLM se produit, la requête initiale de l'utilisateur ne représente qu'une fraction négligeable des données injectées dans le système d'AI, ce qui signifie que les coûts sont dominés par un contexte que l'utilisateur n'a pas explicitement inclus. Les techniques de réduction de l'encombrement du contexte sont encore récentes, mais plusieurs approches prometteuses sont actuellement explorées, notamment :

• Forcer un compactage (une compression) plus fréquent du contexte actif.
• Utiliser des harnesses « moins bavards » (plus économes en jetons), ou ajuster les harnesses existants pour générer moins de surcharge de jetons.
• Auditer les outils populaires et réduire leur niveau de verbosité.
• Encourager les développeurs à diviser les tâches en unités de travail individuelles plus petites, réduisant ainsi la portée du contexte.

Lorsque les contextes deviennent volumineux, la mise en cache des prompts joue également un rôle significatif dans les performances globales. Les LLM propriétaires et open source disposent tous deux de paramètres permettant d'activer la mise en cache des prompts et d'ajuster la durée de conservation du cache. L'écriture dans le cache a un coût, mais les lectures mises en cache peuvent réduire considérablement le coût par inférence. Ce compromis dépend de la charge de travail spécifique de l'entreprise. Ainsi, un ajustement manuel des paramètres de cache par défaut pour augmenter le taux de réussite du cache peut apporter des améliorations spectaculaires sur le coût global.

Chez Databricks, un ajustement relativement simple de nos paramètres de harness et de mise en cache a permis de réduire de près de 50 % le nombre de jetons générés et les coûts associés, sans aucune dégradation de qualité constatée pour les développeurs. Nous continuons d'explorer des techniques dans ce domaine et pensons qu'une optimisation supplémentaire significative reste possible.

Une réduction drastique des jetons par session en éliminant les appels d'inférence superflus et en réduisant les écritures en cache.

Le modèle de conception AI Gateway

Les techniques ci-dessus comportaient de nombreuses exigences techniques implicites : pour tirer rapidement parti des nouveaux modèles, les entreprises doivent disposer d'un emplacement centralisé où le « menu des modèles » est géré, et les utilisateurs finaux doivent disposer d'une chaîne d'outils prenant en charge la combinaison de modèles. Pour offrir une visibilité budgétaire sur plusieurs outils d'AI, une capacité unifiée d'observabilité des coûts doit exister. Pour gérer l'encombrement du contexte, les entreprises ont besoin d'un moyen d'observer les sorties d'appels d'outils typiques et d'imposer une compression ou un compactage. Ces besoins sont collectivement résolus par une nouvelle classe de logiciels d'infrastructure, que l'on peut qualifier d'AI Gateway. Une AI gateway est un emplacement centralisé où se déroulent les opérations suivantes :

1. Gestion de la capacité et proxying de l'accès aux modèles sous-jacents (modèles propriétaires et OSS).
2. Suivi et application des budgets, y compris des politiques budgétaires complexes telles que des niveaux de friction progressifs et la rétrogradation de modèles.
3. Gestion de la configuration des outils des utilisateurs finaux, afin d'appliquer les listes d'autorisation de modèles, les paramètres de compactage et d'autres aspects gérés localement.
4. Enregistrement des traces de session de codage pour l'analyse de l'efficacité en aval et l'évaluation comparative (benchmark).

Chez Databricks, nous nous appuyons fortement sur Unity AI Gateway pour l'ensemble de ces fonctionnalités.

En résumé

La croissance exponentielle des coûts de codage liés à l'AI n'est pas une fatalité, c'est un problème d'ingénierie et de gouvernance tout à fait soluble. Les entreprises qui y sont parvenues partagent une stratégie commune : rechercher sans relâche la frontière de l'efficacité plutôt que celle de l'intelligence, adopter des outils qui préservent la flexibilité des modèles, orienter intelligemment le travail vers le modèle le moins cher et le plus performant, remplacer les budgets stricts par de la visibilité et une friction progressive, et réduire la surcharge de jetons qui domine les dépenses réelles. Aucune de ces techniques ne nécessite de sacrifier les gains de productivité qui ont rendu l'adoption de l'AI intéressante à l'origine ; ensemble, elles permettent aux organisations de répondre au double impératif d'un accès large et fluide, tout en maintenant une enveloppe de coûts prévisible.

Un ensemble de nouvelles abstractions d'infrastructure émerge pour donner aux entreprises les outils nécessaires à la gestion de leurs coûts. Chez Databricks, nous avons publié les composants clés de notre pile de gestion des coûts sous forme de produits open source ou de logiciels gratuits : notre Unity AI Gateway pour une gestion centralisée et Omnigent pour les outils de développement. Des milliers d'entreprises utilisent ces composants chaque jour. Nous invitons d'autres entreprises à partager leurs conclusions et à comparer leurs techniques à mesure que ce paysage technologique évolue rapidement.

Remerciements : Merci aux responsables d'infrastructure chez Uber, Stripe, Coinbase et Ramp qui ont apporté leurs commentaires et révisé cet article. Merci à Thrive Capital pour ses retours sur une première version de cet article.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original