von Rohit Agrawal, Shuyu Cao, Darming Zhao, Zack Siegel und Aaron Davidson
• Bei Databricks steuern wir KI-Ausgaben in großem Stil, indem wir jeden Coding-Agenten über das Unity AI Gateway leiten. So haben unsere Teams einen zentralen Ort, um Budgets, Transparenz und Richtlinien für jedes Modell und Tool durchzusetzen.
• Wir bringen Innovation und Kostenkontrolle in Einklang, indem wir separate tägliche und monatliche Budgets nutzen. Diese verhindern ausufernde KI-Ausgaben, während unsere Engineers durch Self-Service-Budgeterhöhungen anstelle von Freigabeengpässen produktiv bleiben.
• Dieses bewährte Governance-Modell kombiniert zentralisierte Ausgabenkontrollen, einheitliche Observability und datengestützte Richtliniendurchsetzung, um die KI-Einführung zu skalieren, ohne unsere Entwickler auszubremsen.
Bei Databricks ändert sich die Art und Weise, wie wir Software entwickeln, rasant, da wir AI im Engineering-Bereich offensiv einsetzen. Tausende unserer Engineers nutzen täglich Coding-Agents und wechseln dabei zwischen Claude Code, Codex, Cursor und anderen – oft sogar mehreren gleichzeitig. Diese hohe Akzeptanz ist großartig, bringt aber ein neues Problem mit sich: Die Ausgaben für Coding-Agents gehören mittlerweile zu den am schnellsten wachsenden Posten in der R&D, und eine einzige außer Kontrolle geratene Automatisierungsschleife kann an einem einzigen Nachmittag das Budget eines ganzen Monats verschlingen.
In diesem Beitrag zeigen wir, wie wir dieses Problem intern gelöst haben – und zwar mit genau den Unity AI Gateway Budgets, die wir auch unseren Kunden anbieten. Da jeder Coding-Agent bei Databricks, unabhängig von Tool oder Modell, seinen Traffic über unser Gateway leitet, können wir eine einheitliche Ausgabenrichtlinie für die gesamte Flotte durchsetzen, ohne die Admin-Konsolen der einzelnen Coding-Agents anfassen zu müssen.
Die wichtigsten Erkenntnisse aus dieser Einführung waren:
Schauen wir uns genauer an, wie wir dorthin gelangt sind.
Hinweis: Die Dollarbeträge in diesem Beitrag dienen nur zur Veranschaulichung und entsprechen nicht unseren tatsächlichen internen Zahlen.
Als wir mit dem Kostenmanagement begannen, haben wir genau ein Limit festgelegt: Jeder Engineer erhielt ein standardmäßiges monatliches Ausgabenlimit (sagen wir 500 $). Wenn dieses erreicht war, wurde ein Antrag auf Erhöhung gestellt. Auf dem Papier klingt das vernünftig, aber in der Praxis hat diese Strategie überall zu Reibungsverlusten geführt.
Da dieses Limit gleichzeitig unser einziger Schutz vor unkontrollierten Ausgaben war, erfolgte jede Limiterhöhung ebenfalls in Schritten von 500 $. Power-User mussten jedes Mal, wenn sie ihr neues Limit erreichten, einen neuen Antrag stellen – manchmal mehrmals im Monat. Alles über 2.500 $ erforderte eine manuelle Überprüfung. Schlimmer noch: Jede Erhöhung war dauerhaft. Ein Engineer, der einen einzigen teuren Fehler machte oder an einem kostenintensiven Projekt arbeitete, behielt das hohe Limit unbegrenzt. Dadurch stieg unbemerkt der Anteil im Unternehmen, der für teure Fehler anfällig war. Zudem gab es kein Notfallverfahren („Break-Glass-Verfahren“), mit dem sich Engineers bei kritischen, zeitkritischen Aufgaben – wie der Nutzung von AI zur Behebung von Kundenproblemen – selbst freischalten konnten.
Bei unserer Unternehmensgröße erreichten jeden Monat zwischen 500 und 1.000 Engineers ihr Limit. Das bedeutete Hunderte von Tickets, Hunderte von unterbrochenen Arbeitssitzungen und einen sehr frustrierten #ai-devtools-Slack-Kanal.
Bevor wir mit dem Entwurf begannen, haben wir aufgeschrieben, was uns beim Thema AI-Ausgaben wirklich wichtig ist. Das ließ sich in zwei Prinzipien zusammenfassen:
Als wir das aufschrieben, wurde der Konflikt deutlich: Um unkontrollierte Ausgaben abzufangen, muss ein Limit so niedrig sein, dass es schon bei einem versehentlichen Fehler von wenigen Stunden anschlägt. Ein so niedriges Limit unterbricht jedoch ständig die normale monatliche Nutzung. Keine einzelne Zahl kann beide Aufgaben erfüllen.
Wir haben unsere Struktur nach einem einfachen Prinzip umgestellt: Wir lassen Engineers ungehindert arbeiten und greifen nur bei den beiden Arten von Verschwendung ein, auf die es wirklich ankommt – kurzfristige und langfristige Verschwendung.
Die Lösung für diese beiden Fehlerszenarien lässt sich auf zwei Budgets im Unity AI Gateway übertragen:
Ein Tageslimit, um unkontrollierte Ausgaben abzufangen. Dieses Limit ist im Verhältnis zu den monatlichen Ausgaben bewusst niedrig angesetzt. Wenn ein Engineer dieses Limit erreicht, gehen wir nicht davon aus, dass etwas nicht stimmt. Er erhält eine Slack-Benachrichtigung, bestätigt, dass die Ausgaben beabsichtigt waren, und das Limit erhöht sich automatisch um einen weiteren Schritt. Keine Freigabe, kein Ticket, keine Wartezeit. Waren die Ausgaben ein Versehen, ist die Benachrichtigung genau die Warnung, die er brauchte. Das Tagesbudget wird jeden Abend zu unserer nutzungsärmsten Stunde zurückgesetzt und zu Beginn jedes Monats vollständig gelöscht.
Ein Monatslimit zur Regelung außergewöhnlicher Ausgaben. Dieses Limit ist so hoch angesetzt, dass ein typischer Engineer es nie erreicht. Eine Überschreitung bedeutet, dass jemand deutlich mehr ausgeben möchte als seine Kollegen. Das ist völlig in Ordnung, sollte aber auf eine bestimmte geschäftliche Priorität zurückzuführen sein. Diese Erhöhungen werden vom jeweiligen Manager genehmigt (statt von einem zentralen Freigabeausschuss) und erfolgen in wenigen, klar definierten Stufen statt in unzähligen kleinen Schritten. Und was besonders wichtig ist: Sie sind zeitlich auf die Dauer des Projekts begrenzt. Nach Projektende wird das Limit wieder zurückgesetzt.
Die beiden Limits bleiben über ein festes Verhältnis miteinander gekoppelt. In unserer Implementierung wird ein Engineer, der seine Ausgaben gleichmäßig über den Monat verteilt, das Tageslimit nie erreichen, da das auf die Arbeitstage aufgeteilte Monatsbudget deutlich unter der täglichen Schwelle liegt. Wenn ein Manager das Monatslimit eines Mitarbeiters für ein großes Projekt erhöht, steigen dessen Tageslimit und die Erhöhungsschritte proportional an. So bleibt der Schutz vor unkontrollierten Ausgaben effektiv, ohne lästig zu werden.
Hinter den Kulissen lässt sich das jeweils effektive Limit ganz einfach beschreiben. Die Ausgaben eines Nutzers werden durch beide Budgets geregelt und sind somit auf das Minimum von zwei Limits begrenzt: die bisherige Nutzung in diesem Monat plus ein Erhöhungsschritt für unkontrollierte Ausgaben sowie das monatliche Maximum. Wenn ein Nutzer blockiert wird, zeigt uns diese Formel auch genau, welcher Fall vorliegt. Wird das Limit für unkontrollierte Ausgaben erreicht, kann die Nutzung nach einer Self-Service-Bestätigung fortgesetzt werden. Wird das monatliche Maximum erreicht, muss Rücksprache mit dem Manager gehalten werden.
Das Tageslimit funktioniert nur dann, wenn die Freischaltung wirklich reibungslos verläuft. Daher haben wir den Großteil unserer Entwicklungsarbeit in diesen Prozess gesteckt. Und so sieht das für einen Engineer in der Praxis aus:
Sobald ein Nutzer etwa 90 % seines Tageslimits erreicht hat, kann er eine Erhöhung beantragen, noch bevor er blockiert wird. Es wird eine Slack-Benachrichtigung mit dem entsprechenden Kontext gesendet (bisherige Tagesausgaben, verbleibender Spielraum) und einer einzigen Schaltfläche zur Bestätigung, dass die Ausgaben beabsichtigt sind. Ein Klick darauf erhöht das Tageslimit sofort um einen Schritt. Dieselbe selbstständige Erhöhung ist auch über unser internes Budgetportal und über das CLI möglich, das das verbleibende tägliche und monatliche Kontingent zusammen mit den Links zur Erhöhung anzeigt.
Es gibt keine Begrenzung für die Anzahl der selbstständigen Bestätigungen pro Tag. Ein Engineer mit einer wirklich hohen Arbeitslast kann zwei- oder dreimal am Tag eine Erhöhung bestätigen, und das ist völlig in Ordnung. Jede Bestätigung ist ein bewusstes menschliches Signal: „Ja, ich bin das, und das ist so gewollt.“ Ein unbeaufsichtigter Cron-Job kann schließlich nicht auf eine Slack-Schaltfläche klicken. Die Schrittgröße ist hierbei entscheidend: Ist sie zu klein, werden die Benachrichtigungen zu störendem Rauschen, das die Leute dazu verleitet, sie einfach wegzuklicken. Ist sie zu groß, verliert die Schutzfunktion ihre Wirkung. Wir haben unsere Schritte so dimensioniert, dass ein Engineer, der sein Monatsbudget gleichmäßig nutzt, überhaupt keine Benachrichtigung erhält.
Anstatt die Limits auf beliebige, benutzerspezifische Werte ansteigen zu lassen, bewegen sich beide Budgets in einer kleinen Anzahl fester Stufen (Tiers), die als Gruppenmitgliedschaften im Gateway implementiert sind. Jeder beginnt auf der Basisstufe, und jede höhere Stufe hebt den Schwellenwert um einen festen Betrag an. Dadurch bleibt das System übersichtlich: Eine Gruppenliste zeigt sofort, wer über dem Standardwert liegt und um wie viel.
Die beiden Budgets durchlaufen ihre Stufen auf unterschiedliche Weise, passend zu ihren jeweiligen Aufgaben.
Tägliche Stufen ändern sich automatisch. Jeder beginnt den Monat auf der Basisstufe. Jede Selbstbestätigung stuft den Benutzer um eine Stufe herauf, und ein geplanter Job stuft Benutzer auch proaktiv herauf, wenn ihre Ausgaben sich ihrer aktuellen Obergrenze nähern – höchstens einmal pro Tag, sodass die normale Nutzung nie unterbrochen wird. Am Ende des Monats setzt ein weiterer Job alle wieder auf die Basisstufe zurück. Der große Schub des letzten Monats wird nicht als Spielraum für diesen Monat übernommen.
Monatliche Stufen ändern sich bewusst. Es gibt nur wenige, etwa 2x, 5x, bis hin zu praktisch unbegrenzt, und jede Heraufstufung erfordert die Genehmigung eines Managers oder der nächsthöheren Führungsebene. Heraufstufungen sind auf das Projekt beschränkt, das sie rechtfertigt, in der Regel für einen, drei oder sechs Monate, und werden danach wieder rückgängig gemacht. Die groben Schritte erzwingen ein echtes Gespräch über die Ausgaben, anstatt kleiner Erhöhungen, die niemand überprüft. Das Erhöhen der monatlichen Stufe skaliert auch den täglichen Zuwachs proportional, sodass der Schutz vor unkontrollierten Kosten kalibriert bleibt.
Der Grund, warum dies fast ohne eigene Infrastruktur funktioniert, ist, dass das Unity AI Gateway bereits alles sieht. Jede Anfrage von jedem Coding-Agenten, egal ob sie Claude, GPT, Gemini oder Open-Source-Modelle betrifft, wird einer Benutzeridentität zugeordnet und an einem zentralen Ort erfasst. Die für das Gateway konfigurierten Budgets gelten für alle Tools, die ein Entwickler verwendet, und die Ausgaben können keines der geltenden Budgets überschreiten. Diese letzte Eigenschaft setzt das Verhalten "das Minimum der beiden Limits" quasi umsonst um: Wir definieren beide Budgets, und beide sind zu jedem Zeitpunkt wirksam.
Die täglichen und monatlichen Stufen werden implementiert, indem die budgetabhängigen Schwellenwert-Überschreibungen pro Benutzer verschiedenen Gruppen zugewiesen werden. Und die Heraufstufung erfolgt, indem der Benutzer durch tägliche Automatisierung, Selbstbestätigungen und Genehmigungen von Managern Mitglied der Gruppe der höheren Stufe wird.
Da das Gateway all diese Nutzungsdaten in Unity Catalog speichert, erhalten wir auch die Observability-Seite kostenlos dazu. Manager sehen die Ausgaben auf Teamebene in denselben Lakehouse-Tabellen, in denen wir unseren internen Coding-Agent-Benchmark erstellt haben, und die Finanzabteilung sieht eine einzige Rechnung statt fünf.
Die unterbrechungsgesteuerte Genehmigungswarteschlange gehört der Vergangenheit an. Unter dem neuen Modell erwarten wir, dass nur eine kleine Handvoll unserer aktivsten Benutzer jemals das tägliche Limit in einem bestimmten Monat erreicht, und jeder dieser Fälle lässt sich mit einem einzigen Klick zur Bestätigung lösen. Monatliche Limiterhöhungen haben sich von einer wiederkehrenden lästigen Pflicht pro Entwickler zu einer seltenen, projektbezogenen Entscheidung gewandelt, die ein Manager nur einmal treffen muss.
Ebenso wichtig ist, dass die Entwickler aufgehört haben, zu rationieren. Der Zweck dieser Leitplanken war nie, die KI-Nutzung zu reduzieren. Es ging darum, die Angst vor unbegrenzten Kosten zu nehmen, damit wir die Akzeptanz weiter steigern können. Ausgaben sind jetzt etwas, das wir mit Daten gestalten, anstatt sie aus Vorsicht zu deckeln.
Wir passen die Zahlen kontinuierlich an, während sich die Nutzungsmuster weiterentwickeln. Die Muster, die sich intern bewährt haben, fließen direkt in das Budgets-Produkt ein: native tägliche Budgetzyklen, temporäre Überschreibungen, die mit dem Budgetzyklus ablaufen, und ein Berechtigungsmodell, mit dem Endbenutzer ihren eigenen täglichen Schwellenwert direkt über die Budget-API selbst anheben können – mit mehr Flexibilität als bei den vordefinierten Überschreibungsgruppen.
Wir arbeiten auch daran, den teuren Pfad durch intelligenteres Modell-Routing von vornherein weniger notwendig zu machen, sodass alltägliche Aufgaben auf effizienten Modellen landen und Spitzenmodelle für die Arbeit reserviert bleiben, die sie wirklich benötigt. Mehr dazu in einem folgenden Beitrag.
Wenn Ihr Unternehmen Coding-Agenten skaliert und jedes Tool seine eigene Budgetkonsole hat, ist die Lösung dieselbe, die wir selbst verwendet haben. Die Unterstützung von Coding-Agenten im Unity AI Gateway ist ab heute für alle Databricks-Kunden verfügbar. Werfen Sie einen Blick in die Dokumentation, um loszulegen.
(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag
Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.