Databricks-Mitgründer Patrick Wendell darüber, warum KI-Codierungskosten exponentiell steigen und wie Engineering-Leader die Kurve abflachen können, ohne ihre Teams zu bremsen
von Catherine Brown
In diesem Gespräch spricht Catherine Brown mit Patrick darüber, was passierte, als Databricks voll auf AI-Coding-Agenten setzte: wie die Kosten mit der zunehmenden Nutzung zunächst explodierten, was die Stückkosten tatsächlich um bis zu 90 % senkte und warum jede Engineering-Organisation eine Steuerungsebene zwischen ihren Entwicklern und ihren Modellen braucht. Diese Steuerungsebene begann als interne Lösung für die eigene AI-Rechnung von Databricks und wurde zur Inspiration für den Unity Gateway.
Catherine: Sie leiten die AI-Produkte von Databricks und sind auch der interne Verfechter der AI-Einführung. Warum ist das für Sie zu einer so persönlichen Priorität geworden?
Patrick: Weil der Engineering-Output der Hauptflaschenhals in unserem Geschäft ist. Jedes Unternehmen muss sein Engineering-Team schneller machen, und wenn man ihnen etwas geben kann, das ihre Produktivität spürbar verbessert, ist das sehr viel wert. Die ersten Chat-Produkte waren einigermaßen nützlich. Aber der ROI hat sich vor etwa einem Jahr wirklich grundlegend verändert, als die ersten richtig guten Coding-Modelle auftauchten.
Catherine: Woher wissen Sie, ob Sie durch AI-Tools Produktivitätsgewinne erzielen?
Patrick: Wir verfolgen eine Reihe von Output-Metriken: Pull Requests, ausgelieferte Features und Codezeilen. Keine davon ist für sich genommen perfekt. Ich stelle mir die R&D wie eine große Maschine vor. Man gibt Ressourcen hinein, bekommt Features und Code heraus und kann messen, wie viel mehr herauskommt. Insgesamt stehen wir kurz davor, den Output mit demselben Team zu verdoppeln. Die Teams, die ihre Prozesse rund um AI neu aufgebaut haben, sind sogar noch viel schneller.
Catherine: Als Databricks zum ersten Mal AI-Coding-Tools eingeführt hat, was haben Sie da falsch gemacht?
Patrick: Es ist irgendwie lustig, weil wir am Anfang das gegenteilige Problem hatten. Niemand wollte die neuen Sachen ausprobieren. Ich bin herumgelaufen und habe den Leuten auf die Nerven gegangen. Also haben wir das getan, was alle getan haben: wir haben jede Hürde abgebaut – das teuerste Modell, so viele Tokens, wie man möchte. Ich denke, das kam aus einer guten Absicht. Man versucht, die Leute über die Hürde zu bringen.
Dann fingen die Leute tatsächlich an, es zu nutzen, und wir sahen diese exponentielle Kostenkurve. Diese Tools werden heute alle nach Verbrauch abgerechnet, nicht pro Nutzer. Ein einzelner Nutzer kann also im Prinzip eine unbegrenzte Menge Geld ausgeben. Er kann eine kleine Schleife auf dem teuersten Modell ausführen und Mittagessen gehen. Vielleicht macht diese Schleife etwas wirklich Wertvolles, aber vielleicht verbrennt sie auch einfach nur Tokens. Wenn die Kosten exponentiell steigen und die Einnahmen nicht, hat man irgendwann ein Problem. Wir kamen an den Punkt, an dem die Kosten die Effizienzgewinne – die überhaupt der Grund für das Ganze waren – zunichtezumachen drohten.
An diesem Punkt habe ich mich persönlich sehr stark eingebracht. Ich habe mich mit Führungskräften anderer Technologieunternehmen ausgetauscht, von denen ich wusste, dass sie AI in großem Umfang einsetzen (Coinbase, Uber, Stripe und andere). Gemeinsam haben viele von uns ähnliche Techniken verfolgt. Heute sind unsere Token-Ausgaben pro Kopf bei Databricks nahezu unverändert, obwohl die Gesamtnutzung und der Mehrwert weiter steigen.
Catherine: Der erste Instinkt der meisten Unternehmen ist eine harte Ausgabenobergrenze. Das haben Sie ausprobiert. Was ist passiert?
Patrick: Es ist der naheliegende erste Schritt, und man möchte den Mechanismus natürlich haben. Aber ein harter Stopp ist eine schlechte Erfahrung. Man bricht die Arbeit von jemandem mitten in der Aufgabe ab, und er verliert seinen Flow, vielleicht sogar stundenlange Arbeit. Und die Leute, die an das Limit stoßen, sind oft die besten Nutzer. Wenn man sie blockiert, nutzen einige von ihnen einfach ein privates Konto, und man hat keinerlei Einblick mehr.
Also sind wir zu einer schrittweise ansteigenden Hürde übergegangen, und Unity Gateway regelt das alles. Zuerst eine Warnung, dann eine Genehmigung, dann stufen wir auf ein günstigeres Modell herunter, damit man weiterarbeiten kann. Jemanden tatsächlich zu blockieren, ist das letzte Mittel. Wir senden auch jedem regelmäßig eine Aufschlüsselung seiner eigenen Ausgaben mit Vorschlägen zum Sparen. Das allein macht schon etwa 10 % aus. Ein Unternehmen, das ich kenne, fügt das Modell und die Kosten direkt in jeden Pull Request ein. Es ist also im Grunde genommen Anprangern, wenn man ein teures Modell für eine Kleinigkeit nutzt. Ich liebe das.
Catherine: Sie haben über vier Hebel zur Senkung dieser Kosten geschrieben. Welcher davon hatte die größte Wirkung?
Patrick: Unser Favorit ist irgendwie langweilig: Es kommen ständig bessere, günstigere Modelle heraus, und man verlagert den Traffic auf diese. Sowohl von kommerziellen als auch von Open-Source-Anbietern werden wahrscheinlich jede Woche fünf Modelle veröffentlicht. Nicht jedes ist ein Fortschritt bei den Kosten, aber vielleicht alle ein bis zwei Wochen eines. Es ist wie eine steigende Flut. Man erhält denselben Output für weniger Geld, und niemand muss etwas ändern. Kein ausgeklügeltes Routing, gar nichts.
Um Ihnen ein Gefühl dafür zu geben, wie schnell das geht: Eines der jüngsten günstigen Modelle entspricht in etwa dem, was ein Frontier-Modell vor etwa neun Monaten leisten konnte – und das zu etwa 1 % der Kosten pro Aufgabe. Das ist ein Rückgang um das 100-Fache in weniger als einem Jahr. Das ist zwar noch vorläufig, aber das ist die Richtung.
Der Haken ist, dass man auch tatsächlich wechseln muss. Wenn ein neues Modell herauskommt und niemand im Unternehmen es nutzt, ist es wie der Baum, der im Wald umfällt. Also wurden wir gut darin, neue Modelle schnell zu evaluieren und Workloads zu verlagern, wenn eines gut genug ist. Weil alles über Unity Gateway läuft, können wir diese Umstellung an einer Stelle vornehmen, und die Entwickler müssen nichts ändern. Das war die wirkungsvollste Maßnahme, die wir ergriffen haben – für sich genommen schon 50 % oder mehr. Rechnet man noch Routing, Transparenz bei den Ausgaben und die Reduzierung des Token-Overheads hinzu, sind unsere Stückkosten in einigen Fällen um bis zu 90 % gesunken.
Catherine: Ihr Team führt Benchmarks für Coding-Agenten anhand der eigenen, mehrere Millionen Zeilen langen Codebasis von Databricks durch. Warum vertrauen Sie nicht einfach den öffentlichen Benchmarks?
Patrick: Öffentliche Benchmarks sagen nicht viel über den eigenen Code aus. Die Aufgaben fließen in die Trainingsdaten ein und sehen nicht wie eine große Unternehmens-Codebasis aus. Wir haben also unsere eigenen aus echten Pull Requests in unserem Repository erstellt und bewerten, indem wir die Tests tatsächlich ausführen. Wir nutzen kein LLM als Richter, weil das dazu neigt, richtig zu klingen anstatt richtig zu sein.
Einige der Ergebnisse haben überrascht. Ein Open-Source-Modell, GLM 5.2, lag in der Qualität gleichauf mit Opus 4.8 – bei etwa ein Drittel geringeren Kosten pro Aufgabe. Ein Modell, das pro Token 1,7-mal günstiger war, kostete pro Aufgabe mehr, weil es mehr Tokens verbrannt hat. Und das Harness, also das Coding-Tool rund um das Modell, spielte eine fast genauso große Rolle wie das Modell selbst. Dasselbe Modell, anderes Harness: mehr als 2-facher Unterschied bei den Kosten. Allein die Feinabstimmung unseres Harnesses und der Caching-Einstellungen hat uns fast 50 % eingespart.
Catherine: Die Spanne zwischen den günstigsten und den teuersten Modellen kann das 100-Fache betragen. Wie sollten Engineering-Verantwortliche über diese Bandbreite nachdenken?
Patrick: Stellen Sie sich das wie Autos vor. Es gibt den Lamborghini, den Honda und das Fahrrad. Man braucht nicht für jede Fahrt den Lamborghini, und die meiste Coding-Arbeit erfordert nicht das größte Modell.
Astra war ein gutes Beispiel. Wir haben es für jeden Entwickler eingeführt, etwa 3.500 Personen, und soweit wir wissen, sind wir das erste Unternehmen, das einen solchen Rollout öffentlich teilt. Bei den schwierigen Aufgaben wie dem Systemdesign war es eindeutig besser. Aber die Ausgaben stiegen um etwa 60 %, und bei den alltäglichen Aufgaben, die die bestehenden Modelle bereits gut bewältigen, gab es keinen offensichtlichen Nutzen. Vieles davon war Verschwendung – Leute nutzten Astra für Dinge, für die sie ein anderes Modell hätten verwenden sollen. Also haben wir ihm ein eigenes Budget in Unity Gateway gegeben: Nutzung nur für die schwierigen Probleme.
Langfristig weiß ich nicht, in welche Richtung sich das entwickelt. Günstige Modelle übernehmen immer mehr Routinearbeiten, aber die Leute konfrontieren die AI auch mit immer schwierigeren Problemen. Das ist gewissermaßen der Sinn der Sache. Man möchte in beide Richtungen steuern können.
Catherine: Sie haben argumentiert, dass AI-Kosten ein Infrastrukturproblem und kein Beschaffungsproblem sind. Warum können Budgets und Richtlinien das nicht lösen?
Patrick: Budgets helfen, aber ein Budget kann nicht entscheiden, welches Modell eine bestimmte Anfrage bearbeiten soll. Das übernimmt das Routing. Das Umbenennen einer Komponente geht an ein günstiges Modell; ein schwieriges, ergebnisoffenes Problem geht an ein leistungsfähiges. Unser Smart Router senkt die durchschnittlichen Aufgabenkosten um mehr als 30 % bei ungefähr der gleichen Qualität wie die teuersten Modelle. Zudem müssen wir die Nutzer nicht mehr bitten zu entscheiden, wann sie teurere Modelle verwenden… das passiert einfach automatisch.
Um all das zu tun, braucht man eine Ebene zwischen den Entwicklern und den Modellen. Wir haben unsere gebaut, weil wir es mussten. Der gesamte Traffic unserer Coding-Tools läuft über ein Gateway – egal ob Claude Code, Codex, Cursor oder Omnigent, unser Meta-Harness. Dadurch konnten wir überhaupt erst sehen, wohin das Geld floss. Dann erkannten wir, dass jeder Kunde dasselbe Problem hatte, und machten daraus ein Produkt: den Unity Gateway. Tausende von Kunden nutzen ihn heute.
Catherine: Wird das Routing am Ende genauso umkämpft sein wie die Modelle selbst?
Patrick: Das ist unsere Sicht der Dinge. Da die Margen für die Modelle immer geringer werden, ist es eine ziemlich interessante Aufgabe, herauszufinden, welches Modell wofür verwendet werden soll. Die Routing-Modelle müssen winzig und schnell sein. Außerdem ist es einfach schwer, das gut hinzubekommen. Es gibt viele offene Forschungsfragen bei der praktischen Anwendung dieser Modelle, und ich denke, es steckt echtes IP darin, es richtig zu machen.
Catherine: Wenn Sie einem CTO, der vor einer wachsenden KI-Rechnung steht, einen einzigen Rat geben könnten, welcher wäre das?
Patrick: Finden Sie heraus, wohin das Geld fließt. Die meisten Unternehmen können Ihnen nicht sagen, was sie nach Team oder Modell geordnet für KI ausgeben, geschweige denn, ob es sich auszahlt. Schalten Sie ein Gateway vor Ihre Modelle, damit der gesamte Datenverkehr über eine Stelle läuft und Sie ihn sehen können. Alles andere wird danach einfacher. Und werden Sie nicht langsamer. Die Produktivitätsgewinne sind real. Aber diese Dinge summieren sich, und wenn Sie warten, wird die Rechnung sehr viel höher ausfallen, als Sie denken.
Patricks Botschaft an Engineering-Führungskräfte lautet, dass Sie sich nicht zwischen KI-Produktivität und Kostenkontrolle entscheiden müssen. Die Unternehmen, die dies richtig machen, behalten einen breiten Zugang zu den besten Modellen bei, testen neue Modelle an ihrem eigenen Code, wechseln zu günstigeren, sobald diese gut genug sind, und bieten Entwicklern Transparenz statt Hindernissen. Unter all dem liegt eine Steuerungsebene, ein Gateway, die KI-Ausgaben sichtbar und steuerbar macht. Bei Databricks wurde diese Ebene zu Unity Gateway.
Um mehr darüber zu erfahren, wie Databricks seine eigenen KI-Codierungskosten verwaltet, lesen Sie Patricks Blog „Managing AI Coding Costs at Scale“ und testen Sie Databricks Unity Gateway.
(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.