Patrick Wendell, cofondateur de Databricks, explique pourquoi les coûts du codage par IA augmentent de manière exponentielle et comment les responsables de l'ingénierie peuvent inverser la courbe sans ralentir leurs équipes.
par Catherine Brown
Dans cette conversation, Catherine Brown évalue avec Patrick ce qui s'est passé lorsque Databricks s'est pleinement investi dans les agents de codage AI : comment les coûts ont d'abord grimpé en flèche avec l'augmentation de l'utilisation, ce qui a permis de réduire les coûts unitaires jusqu'à 90 %, et pourquoi chaque équipe d'ingénierie a besoin d'une couche de contrôle entre ses développeurs et ses modèles. Cette couche de contrôle a commencé comme un correctif interne pour la propre facture AI de Databricks, et c'est devenu l'inspiration derrière Unity Gateway.
Catherine : Vous dirigez les produits AI de Databricks et vous avez également été le champion interne de l'adoption de l'AI. Pourquoi est-ce devenu une priorité personnelle pour vous ?
Patrick : Parce que le rendement de l'ingénierie est le principal goulot d'étranglement dans notre activité. Chaque entreprise a besoin que son équipe d'ingénierie avance plus vite, et si vous pouvez lui donner quelque chose qui améliore significativement sa productivité, cela a énormément de valeur. Les premiers produits de chat étaient assez utiles. Mais le ROI a vraiment changé il y a environ un an, lorsque les premiers modèles de codage vraiment performants sont apparus.
Catherine : Comment savez-vous si vous obtenez des gains de productivité grâce aux outils d'AI ?
Patrick : Nous suivons plusieurs métriques de rendement : pull requests, fonctionnalités livrées et lignes de code. Aucune d'entre elles n'est parfaite en soi. Je vois la R&D comme une grande machine. Vous y mettez des ressources, vous en tirez des fonctionnalités et du code, et vous pouvez mesurer combien il en sort en plus. Au global, nous sommes près de doubler le rendement avec la même équipe. Les équipes qui ont reconstruit leurs processus autour de l'AI vont beaucoup plus vite que cela.
Catherine : Lorsque Databricks a déployé pour la première fois des outils de codage AI, quelles erreurs avez-vous commises ?
Patrick : C'est assez amusant parce qu'au début, nous avions le problème inverse. Personne ne voulait essayer les nouveautés. Je faisais le tour pour insister auprès des gens. Nous avons donc fait ce que tout le monde a fait, c'est-à-dire supprimer tous les obstacles : le modèle le plus cher, autant de tokens que vous voulez. Je pense que cela partait d'une bonne intention. Vous essayez d'aider les gens à franchir le cap.
Ensuite, les gens ont vraiment commencé à l'utiliser, et nous avons vu cette courbe de coûts exponentielle. Ces outils sont tous facturés à la consommation aujourd'hui, et non par utilisateur, donc un seul utilisateur peut, en principe, dépenser une quantité illimitée d'argent. Il peut lancer une petite boucle sur le modèle le plus cher et partir déjeuner. Peut-être que cette boucle fait quelque chose de très utile, mais peut-être qu'elle ne fait que brûler des tokens. Si vos coûts augmentent de manière exponentielle et pas vos revenus, à un moment donné, vous avez un problème. Nous en sommes arrivés au point où les coûts menaçaient d'annuler les gains d'efficacité, qui étaient la seule raison pour laquelle nous avions fait cela.
C'est là que je me suis très impliqué personnellement. J'ai échangé avec des dirigeants d'autres entreprises technologiques qui, je le savais, adoptaient l'AI à grande échelle (Coinbase, Uber, Stripe et d'autres). Collectivement, nous étions nombreux à utiliser des techniques similaires. Aujourd'hui, chez Databricks, nos dépenses en tokens par personne sont à peu près stables, même si l'utilisation totale et la valeur continuent d'augmenter.
Catherine : Le premier réflexe de la plupart des entreprises est d'imposer un plafond de dépenses strict. Vous avez essayé. Que s'est-il passé ?
Patrick : C'est la réaction évidente au début, et le mécanisme est utile. Mais une interruption brute est une mauvaise expérience. Vous coupez quelqu'un en pleine tâche, et il perd son élan, voire des heures de travail. Et les personnes qui atteignent le plafond sont souvent vos meilleurs utilisateurs. Si vous les coupez, certains vont simplement utiliser un compte personnel, et vous perdez toute visibilité.
Nous sommes donc passés à une friction progressive, et Unity Gateway gère tout cela. D'abord un avertissement, puis une approbation, puis nous vous faisons passer à un modèle moins cher pour que vous puissiez continuer à travailler. Couper l'accès à quelqu'un est vraiment le dernier recours. Nous envoyons également à tout le monde un détail régulier de leurs propres dépenses avec des suggestions pour économiser. Cela représente à lui seul environ 10 % d'économie. Une entreprise que je connais affiche le modèle et le coût directement dans chaque pull request. C'est donc de l'affichage public si vous utilisez un modèle coûteux pour une petite tâche. J'adore l'idée.
Catherine : Vous avez écrit un article sur quatre leviers pour réduire ces coûts. Lequel a eu le plus d'impact ?
Patrick : Notre levier préféré est plutôt banal : des modèles meilleurs et moins chers continuent de sortir, et on y réoriente le trafic. Il y a probablement cinq modèles publiés chaque semaine entre les fournisseurs propriétaires et le monde de l'open source. Tous ne constituent pas une avancée sur les coûts, mais peut-être un toutes les une ou deux semaines. C'est une tendance générale. Vous obtenez le même résultat pour moins d'argent, et personne n'a rien à changer. Pas de routage sophistiqué, rien.
Pour vous donner une idée de la vitesse à laquelle cela évolue : l'un des récents modèles économiques correspond à peu près à ce qu'un modèle de pointe pouvait faire il y a environ neuf mois, pour environ 1 % du coût par tâche. C'est une réduction d'un facteur 100 en moins d'un an. C'est encore préliminaire, mais c'est la tendance.
Le piège, c'est qu'il faut vraiment faire la transition. Si un nouveau modèle sort et que personne dans votre entreprise ne l'utilise, c'est comme un arbre qui tombe dans la forêt sans que personne ne l'entende. Nous sommes donc devenus performants pour évaluer rapidement les nouveaux modèles et basculer les charges de travail dès qu'un modèle est suffisamment bon. Comme tout passe par Unity Gateway, nous pouvons effectuer ce changement en un seul endroit, et les développeurs n'ont rien à modifier. C'est la mesure qui a eu le plus d'impact, 50 % ou plus à elle seule. Ajoutez le routage, la visibilité des dépenses et la réduction du surcoût en tokens, et dans certains cas, nos coûts unitaires ont baissé jusqu'à 90 %.
Catherine : Votre équipe évalue les agents de codage par rapport à la propre base de code de plusieurs millions de lignes de Databricks. Pourquoi ne pas simplement faire confiance aux benchmarks publics ?
Patrick : Les benchmarks publics ne vous apprennent pas grand-chose sur votre propre code. Les tâches fuient dans les données d'entraînement et ne ressemblent pas à une grande base de code d'entreprise. Nous avons donc créé le nôtre à partir de véritables pull requests dans notre dépôt, et nous évaluons en exécutant réellement les tests. Nous n'utilisons pas un LLM comme juge, car cela a tendance à récompenser ce qui semble juste plutôt que ce qui est juste.
Certains résultats en ont surpris plus d'un. Un modèle open source, GLM 5.2, a fait jeu égal avec Opus 4.8 en termes de qualité, pour environ un tiers de moins par tâche. Un modèle 1,7 fois moins cher par token coûtait plus cher par tâche, parce qu'il consommait plus de tokens. Et la structure applicative, l'outil de codage autour du modèle, comptait presque autant que le modèle lui-même. Même modèle, structure différente, plus de 2x de différence sur le coût. Le simple fait d'ajuster notre structure et nos paramètres de mise en cache nous a permis d'économiser près de 50 %.
Catherine : L'écart entre les modèles les moins chers et les plus chers peut être de 100x. Comment les responsables ingénierie devraient-ils aborder cet écart ?
Patrick : Voyez cela comme des voitures. Il y a la Lamborghini, la Honda et le vélo. Vous n'avez pas besoin de la Lamborghini pour tous les trajets, et la plupart des travaux de codage n'ont pas besoin du plus grand modèle.
Astra en était un bon exemple. Nous l'avons déployé auprès de tous les ingénieurs, soit environ 3 500 personnes, et autant que nous sachions, nous sommes la première entreprise à partager publiquement un tel déploiement. Il était nettement meilleur sur les tâches complexes, comme la conception de systèmes. Mais les dépenses ont augmenté d'environ 60 %, et il n'apportait pas d'aide évidente sur les tâches quotidiennes, que les modèles existants gèrent déjà très bien. Une grande partie de cela était du gaspillage, des gens utilisant Astra pour des choses pour lesquelles ils auraient dû utiliser un autre modèle. Nous lui avons donc attribué son propre budget dans Unity Gateway. Utilisez-le pour les problèmes complexes.
À long terme, je ne sais pas dans quelle direction cela va évoluer. Les modèles économiques continuent de prendre en charge une plus grande partie du travail de routine, mais les gens soumettent également des problèmes de plus en plus difficiles à l'AI. C'est un peu le but. Vous voulez être capable d'orienter les choses dans un sens comme dans l'autre.
Catherine : Vous avez soutenu que le coût de l'AI est un problème d'infrastructure, pas un problème d'achats. Pourquoi les budgets et les politiques ne peuvent-ils pas le résoudre ?
Patrick : Les budgets aident, mais un budget ne peut pas décider quel modèle doit traiter une requête donnée. C'est le rôle du routage. Le renommage d'un composant est confié à un modèle économique ; un problème difficile et ouvert est confié à un modèle performant. Notre Smart Router réduit le coût moyen par tâche de plus de 30 % avec approximativement la qualité du modèle le plus cher. Cela nous permet également de ne plus demander aux utilisateurs de décider quand utiliser les modèles les plus chers… cela se fait automatiquement.
Pour faire tout cela, vous avez besoin d'une couche entre vos développeurs et les modèles. Nous avons construit la nôtre parce que nous y étions contraints. Tout le trafic de nos outils de codage passe par une seule passerelle, qu'il s'agisse de Claude Code, Codex, Cursor ou Omnigent, notre meta-harness. C'est ce qui nous a permis de voir où allait vraiment l'argent. Puis nous avons réalisé que chaque client avait le même problème, nous l'avons donc transformé en produit sous le nom de Unity Gateway. Des milliers de clients l'utilisent aujourd'hui.
Catherine : Le routage finira-t-il par être aussi concurrentiel que les modèles eux-mêmes ?
Patrick : C'est notre point de vue. À mesure que les marges sur les modèles se réduisent, déterminer quel modèle utiliser pour quel usage est une position particulièrement intéressante. Les modèles de routage doivent être extrêmement petits et rapides. C'est également difficile à réussir. Il existe de nombreuses questions de recherche ouvertes sur l'aspect pratique de l'utilisation de ces modèles, et je pense qu'il y a une vraie valeur en matière de propriété intellectuelle à réussir dans ce domaine.
Catherine : Si vous deviez donner un seul conseil à un CTO confronté à une facture d'IA de plus en plus lourde, quel serait-il ?
Patrick : Cherchez à savoir où va cet argent. La plupart des entreprises ne peuvent pas vous dire ce qu'elles dépensent en IA par équipe ou par modèle, et encore moins si cela s'avère rentable. Placez une passerelle devant vos modèles afin que tout le trafic passe par un seul endroit et que vous puissiez le visualiser. Tout le reste devient plus simple par la suite. Et ne ralentissez pas. Les gains de productivité sont réels. Mais ces coûts s'accumulent et, si vous attendez, la facture sera bien plus élevée que vous ne le pensez.
Le message de Patrick aux responsables ingénierie est qu'il n'est pas nécessaire de choisir entre productivité IA et contrôle des coûts. Les entreprises qui réussissent sur ce plan conservent un accès large aux meilleurs modèles, testent les nouveaux modèles sur leur propre code, passent à des modèles plus économiques dès qu'ils sont suffisamment bons et offrent aux développeurs de la visibilité plutôt que des obstacles. À la base de tout cela se trouve une couche de contrôle, une passerelle, qui permet de visualiser et de piloter les dépenses en IA. Chez Databricks, cette couche est devenue Unity Gateway.
Pour en savoir plus sur la façon dont Databricks gère ses propres dépenses de codage lié à l'IA, lisez le billet de blog de Patrick « Managing AI Coding Costs at Scale » et essayez Databricks Unity Gateway.
(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original
Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.