par Rohit Agrawal, Shuyu Cao, Darming Zhao, Zack Siegel et Aaron Davidson
• Chez Databricks, nous encadrons les dépenses d'IA à l'échelle en acheminant chaque agent de codage via Unity AI Gateway, offrant ainsi à nos équipes un point unique pour appliquer les budgets, la visibilité et les politiques sur l'ensemble des modèles et des outils.
• Nous concilions innovation et contrôle des coûts grâce à des budgets quotidiens et mensuels distincts qui évitent les dérives de dépenses d'IA, tout en préservant la productivité de nos ingénieurs grâce à des augmentations de budget en libre-service plutôt que des goulets d'étranglement liés aux approbations.
• Ce modèle de gouvernance éprouvé associe des contrôles centralisés des dépenses, une observabilité unifiée et l'application de politiques basées sur les données pour déployer l'adoption de l'IA à l'échelle sans ralentir nos développeurs.
Chez Databricks, notre façon de concevoir des logiciels évolue rapidement à mesure que nous adoptons massivement l'AI pour l'ingénierie. Des milliers de nos ingénieurs utilisent chaque jour des agents de codage, alternant entre Claude Code, Codex, Cursor et d'autres, souvent plusieurs à la fois. Cette adoption est une excellente chose, mais elle crée un nouveau problème : les dépenses liées aux agents de codage représentent désormais l'un des postes budgétaires qui augmentent le plus rapidement en R&D, et une seule boucle d'automatisation hors de contrôle peut engloutir un mois de budget en une après-midi.
Cet article explique comment nous avons résolu ce problème en interne, en utilisant les mêmes Unity AI Gateway Budgets que nous proposons à nos clients. Comme chaque agent de codage chez Databricks, quel que soit l'outil ou le modèle, achemine son trafic via notre passerelle, nous pouvons appliquer une politique de dépenses unique à l'ensemble du parc sans avoir à toucher aux consoles d'administration individuelles des agents de codage.
Les principales leçons tirées de ce déploiement sont les suivantes :
Voyons en détail comment nous en sommes arrivés là.
Note : Les montants en dollars figurant dans cet article sont donnés à titre indicatif et ne correspondent pas à nos chiffres internes réels.
Lorsque nous avons commencé à gérer nos coûts, nous n'avions fixé qu'une seule limite : chaque ingénieur disposait d'une limite de dépenses mensuelle par défaut (disons 500 $), et lorsqu'il l'atteignait, il soumettait une demande d'augmentation. Cela semble raisonnable sur le papier, mais nous avons constaté que cette stratégie crée des frictions à tous les niveaux dans la pratique.
Comme cette limite était également notre seule protection contre les dépenses excessives, chaque augmentation de limite se faisait par paliers identiques de 500 $. Les gros utilisateurs devaient soumettre une nouvelle demande à chaque fois qu'ils atteignaient leur nouvelle limite, parfois plusieurs fois par mois, et tout montant supérieur à 2 500 $ nécessitait un examen manuel. Pire encore, chaque augmentation était permanente. Un ingénieur qui commettait une erreur coûteuse ou travaillait sur un projet à budget élevé conservait indéfiniment une limite élevée, augmentant ainsi discrètement la part de l'entreprise exposée à des erreurs coûteuses. De plus, il n'existait pas de procédure d'urgence (« break glass ») permettant aux ingénieurs de se débloquer eux-mêmes pour des tâches critiques et urgentes, comme l'utilisation de l'AI pour déboguer des incidents clients.
À notre échelle, entre 500 et 1 000 ingénieurs atteignaient la limite chaque mois. Cela représentait des centaines de tickets, des centaines de sessions de travail interrompues et un canal Slack #ai-devtools particulièrement mécontent.
Avant de concevoir quoi que ce soit, nous avons mis par écrit nos convictions concernant les dépenses liées à l'AI, qui se résument à deux principes :
Mettre cela par écrit a mis en évidence le conflit. Pour détecter les dépenses excessives, une limite doit être suffisamment basse pour être déclenchée par quelques heures d'accidents. Mais une limite aussi basse interrompt constamment l'utilisation mensuelle normale. Aucun chiffre unique ne peut remplir ces deux rôles.
Nous avons restructuré notre approche autour d'un principe simple : laisser les ingénieurs dépenser sans entrave et n'intervenir que pour les deux types de gaspillage qui comptent réellement, à savoir le gaspillage à court terme et le gaspillage à long terme.
La solution pour ces deux modes de défaillance correspond à deux budgets dans Unity AI Gateway :
Une limite quotidienne pour intercepter les dépenses excessives. Cette limite est volontairement basse par rapport aux dépenses mensuelles. Lorsqu'un ingénieur l'atteint, nous ne partons pas du principe que quelque chose ne va pas. Il reçoit une notification Slack, confirme que la dépense était intentionnelle, et la limite s'élève automatiquement d'un palier supplémentaire. Pas d'approbation, pas de ticket, pas d'attente. Si la dépense était accidentelle, la notification est exactement l'alerte dont il avait besoin. Le budget quotidien est réinitialisé chaque soir à l'heure où l'utilisation est la plus faible, et est entièrement remis à zéro au début de chaque mois.
Une limite mensuelle pour encadrer les dépenses extraordinaires. Cette limite est fixée à un niveau suffisamment élevé pour que l'ingénieur type ne la rencontre jamais. La franchir signifie que quelqu'un demande à dépenser nettement plus que ses pairs, ce qui est acceptable, mais doit être justifié par une priorité commerciale spécifique. Ces augmentations sont soumises à l'approbation du responsable plutôt qu'à celle d'un comité d'approbation centralisé, et se font selon quelques paliers généraux plutôt que par d'infinies petites hausses. De plus, elles sont limitées à la durée du projet. Une fois le projet terminé, la limite revient à son niveau initial.
Les deux limites restent couplées selon un ratio fixe. Dans notre déploiement, un ingénieur dont les dépenses sont régulières tout au long du mois ne déclenchera jamais la limite quotidienne, car le budget mensuel réparti sur les jours ouvrés reste largement inférieur au seuil quotidien. Si un responsable augmente la limite mensuelle d'un collaborateur pour un projet important, sa limite quotidienne et son palier d'augmentation augmentent proportionnellement, de sorte que la protection contre les dépenses excessives reste efficace sans devenir une nuisance.
Sous le capot, la limite effective à tout moment est simple à définir. Les dépenses d'un utilisateur sont régies par les deux budgets et seront donc plafonnées au minimum de deux limites : sa consommation depuis le début du mois plus un palier d'augmentation pour dépenses excessives, et son maximum mensuel. Lorsqu'un utilisateur est bloqué, cette formule nous indique également avec précision dans quel cas nous nous trouvons. S'il a atteint la limite de dépenses excessives, l'utilisation peut reprendre après une confirmation en libre-service. S'il a atteint le maximum mensuel, il doit en discuter avec son responsable.
La limite quotidienne ne fonctionne que si le déblocage se fait sans aucune friction. Nous avons donc concentré l'essentiel de nos efforts de conception sur ce parcours. Voici ce qu'un ingénieur vit concrètement.
Dès qu'un utilisateur franchit environ 90 % de sa limite quotidienne, il devient éligible à une augmentation avant même d'être bloqué. Une notification Slack lui parvient avec le contexte (ce qu'il a dépensé aujourd'hui, sa marge restante) et un bouton unique pour confirmer que la dépense est intentionnelle. Un clic sur ce bouton augmente immédiatement la limite quotidienne d'un palier. Cette même auto-augmentation est disponible depuis notre portail budgétaire interne et depuis la CLI, qui affiche les quotas quotidiens et mensuels restants ainsi que les liens pour augmenter l'un ou l'autre.
Il n'y a pas de limite au nombre d'auto-confirmations par jour. Un ingénieur gérant une charge de travail réellement lourde peut confirmer deux ou trois paliers d'augmentation en une seule journée, et c'est tout à fait acceptable. Chaque confirmation est un signal humain délibéré qui dit "oui, c'est bien moi, et c'est ce que je veux faire". Une tâche cron sans surveillance ne peut pas cliquer sur un bouton Slack. La taille du palier d'augmentation est importante ici : trop petite, et les notifications deviennent un bruit de fond qui incite les gens à cliquer sans réfléchir ; trop grande, et le garde-fou cesse de protéger. Nous avons dimensionné le nôtre de manière à ce qu'un ingénieur dont les dépenses sont régulières par rapport à son budget mensuel ne voie jamais de notification.
Au lieu de laisser les limites fluctuer vers des valeurs arbitraires par utilisateur, les deux budgets évoluent à travers un ensemble restreint de paliers fixes, implémentés sous forme d'appartenance à un groupe dans la passerelle. Tout le monde commence au palier de base, et chaque niveau supérieur augmente le seuil d'un pas fixe. Cela permet de garder le système lisible : la liste des membres d'un groupe permet de savoir qui dépasse la valeur par défaut et de combien.
Les deux budgets évoluent différemment à travers leurs paliers respectifs, conformément à leurs rôles distincts.
Les paliers quotidiens évoluent automatiquement. Tout le monde commence le mois au palier de base. Chaque auto-validation fait passer l'utilisateur au palier supérieur, et une tâche planifiée promeut également les utilisateurs de manière proactive lorsque leurs dépenses approchent de leur plafond actuel, au maximum une fois par jour, afin que l'utilisation normale ne soit jamais interrompue. À la fin du mois, une autre tâche réinitialise tout le monde au palier de base. L'effort important du mois dernier ne se reporte pas sur la marge de manœuvre de ce mois-ci.
Les paliers mensuels évoluent de manière délibérée. Il n'y en a que quelques-uns, environ 2x, 5x, jusqu'à un niveau pratiquement illimité, et chaque promotion nécessite l'approbation d'un responsable ou d'un supérieur hiérarchique direct. Les promotions sont limitées au projet qui les justifie, généralement pour un, trois ou six mois, puis annulées. Ces étapes franches imposent une véritable discussion sur les dépenses au lieu de petites augmentations que personne n'examine. L'augmentation du palier mensuel adapte également l'incrément quotidien de mani ère proportionnelle, de sorte que le garde-fou contre les dérives reste calibré.
La raison pour laquelle cela fonctionne sans presque aucune infrastructure personnalisée est que Unity AI Gateway voit déjà tout. Chaque requête de chaque agent de codage, qu'elle s'adresse à Claude, GPT, Gemini ou à des modèles open source, est attribuée à une identité d'utilisateur et mesurée en un seul endroit. Les budgets configurés pour la passerelle s'appliquent à tous les outils utilisés par un ingénieur, et les dépenses ne peuvent dépasser aucun des budgets applicables. Cette dernière propriété permet d'implémenter gratuitement le comportement du « minimum des deux limites » : nous définissons les deux budgets, et les deux sont effectifs à tout moment.
Les paliers quotidiens et mensuels sont implémentés en attribuant les dépassements de seuils par utilisateur du budget à différents groupes. Et la promotion de palier est obtenue en intégrant l'utilisateur au groupe du palier supérieur, grâce à l'automatisation quotidienne, aux auto-validations et aux approbations des responsables.
Puisque la passerelle envoie toutes ces données d'utilisation dans Unity Catalog, nous bénéficions également de l'observabilité gratuitement. Les responsables voient les dépenses au niveau de l'équipe dans les mêmes tables Lakehouse où nous avons développé notre benchmark interne d'agents de codage, et le service financier ne voit qu'une seule facture au lieu de cinq.
La file d'attente d'approbation basée sur les interruptions a disparu. Avec ce nouveau modèle, nous prévoyons que seule une poignée de nos utilisateurs les plus actifs atteindra la limite quotidienne au cours d'un mois donné, et chacun de ces cas se résout d'un simple clic de validation. Les augmentations de limites mensuelles sont passées d'une corvée récurrente pour chaque ingénieur à une décision rare, limitée au projet, qu'un responsable prend une seule fois.
Tout aussi important, les ingénieurs ont cessé de se rationner. Le but de ces garde-fous n'a jamais été de réduire l'utilisation de l'AI. Il s'agissait d'éliminer la peur de coûts illimités afin de continuer à encourager l'adoption. Les dépenses sont désormais un élément que nous façonnons grâce aux données, plutôt qu'une limite que nous imposons par prudence.
Nous continuons à ajuster les chiffres à mesure que les modèles d'utilisation évoluent, et les modèles qui ont fait leurs preuves en interne inspirent le produit Budgets lui-même : des cycles budgétaires quotidiens natifs, des dépassements temporaires qui expirent avec le cycle budgétaire, et un modèle de permissions qui permet aux utilisateurs finaux d'augmenter eux-mêmes leur propre seuil quotidien directement via l'API budgétaire avec plus de flexibilité que les groupes de dépassement prédéfinis.
Nous travaillons également à rendre les options coûteuses moins nécessaires dès le départ grâce à un routage plus intelligent des modèles, de sorte que les tâches quotidiennes soient orientées vers des modèles efficaces et que les modèles les plus avancés soient réservés aux travaux qui le nécessitent. Nous en reparlerons dans un prochain article.
Si votre organisation déploie des agents de codage à grande échelle et que chaque outil dispose de sa propre console budgétaire, la solution est la même que celle que nous avons utilisée nous-mêmes. La prise en charge des agents de codage dans Unity AI Gateway est disponible dès aujourd'hui pour tous les clients Databricks. Consultez la documentation pour commencer.
(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.