KI-Codierungskosten im großen Maßstab verwalten

AI-Coding-Tools bieten einen immensen Mehrwert: Bei Databricks hat agentisches Coding jede von uns erfasste Velocity-Metrik messbar verbessert und in einigen Teams zu einer Steigerung des Outputs um eine Größenordnung geführt. Aber fast jedes Unternehmen, das AI-Tools in großem Stil einsetzt, ist an dieselbe Grenze gestoßen: exponentiell steigende Kosten. Diese Kurve ist nicht tragbar – wenn man sie nicht kontrolliert, wird sie irgendwann den Umsatz übersteigen. Die Explosion der Ausgaben hat Unternehmen in eine paradoxe Situation gebracht: Einerseits wollen sie die AI-Transformation maximal vorantreiben und ihren Mitarbeitenden leistungsstarke Tools an die Hand geben, andererseits müssen sie sich mit einem Gesamtkostenprofil abfinden, das die Effizienzgewinne, die AI bietet, zu untergraben oder sogar ins Gegenteil zu verkehren droht.

Glücklicherweise haben sich einige der ersten Großanwender auf eine Reihe von Ansätzen geeinigt, die dieses Rätsel lösen und ein „doppeltes Mandat“ erfüllen: (a) breiten Zugang zu AI-Tools mit minimalem Aufwand zu bieten und (b) die Gesamtkosten pro Nutzer in einem in etwa festen Rahmen zu halten. Dieser Beitrag beschreibt bewährte Methoden für das Kostenmanagement, basierend auf unseren Erfahrungen bei Databricks und Gesprächen mit mehreren anderen Digital-Native-Unternehmen, darunter Stripe, Coinbase, Uber und Ramp. Die folgende Tabelle fasst die aktuellen Techniken und die damit verbundenen Einsparungen zusammen. Die Zahlen sind Richtwerte, die auf einer informellen Umfrage unter Entwicklungsteams basieren:

Einige dieser Techniken lassen sich problemlos mit Software implementieren, die viele Unternehmen bereits nutzen. Andere erfordern eine neue Infrastruktur, insbesondere Techniken, die Endbenutzer-Clients modifizieren oder den Traffic über verschiedene Modelle hinweg verlagern. Bei Databricks haben wir unsere wichtigsten Infrastrukturkomponenten als Open Source bereitgestellt oder frei zugänglich gemacht: ein Meta-Harness für Endbenutzer (Omnigent) und unser AI Gateway (Unity AI Gateway). Der Vollständigkeit halber deckt dieser Beitrag auch Software ab, die von anderen Unternehmen verwendet wird, mit denen wir gesprochen haben.

Die „Effizienzgrenze“ für Coding-Modelle

Der größte einzelne Kostenhebel besteht darin, die Ausgaben für das Coding auf effizientere Modelle zu verlagern, sobald diese veröffentlicht werden. Dieser Punkt bedarf einer gewissen Diskussion, da die einfache Erklärung von „günstigeren Modellen“ in Wirklichkeit eine nuancierte Beziehung zwischen Modellkosten und -qualität verbirgt.

Umgangssprachlich bedeutet der Begriff Frontier-Modell „das Modell mit der höchsten Intelligenz“, und Frontier-Labs konzentrieren sich weitgehend darauf, diese Spitzenintelligenz weiterzuentwickeln. Frontier-Modelle können mittlerweile neuartige Probleme in der Mathematik oder Cybersicherheit lösen. Doch wenn AI in großem Stil eingesetzt wird, kommt es auf eine andere Grenze an: die Effizienzgrenze. Die Effizienzgrenze ist definiert durch die Gruppe von Modellen, die das beste Preis-Leistungs-Verhältnis für ein bestimmtes Intelligenzniveau bieten. Die meiste alltägliche Coding-Arbeit erfordert keine mathematischen Beweise oder neuartigen Sicherheitserkenntnisse. Was also in der Gesamtheit zählt, sind die Kosten für Modelle, die die Qualitätsanforderungen für typische Software-Engineering-Aufgaben erfüllen. Diese „Effizienzgrenze“ verschiebt sich weitaus schneller als die Intelligenzgrenze, da fast wöchentlich neue Modelle auf den Markt kommen, die ein besseres Verhältnis von Intelligenz zu Preis bieten als frühere Modelle.

Kostenhebel Nr. 1: Wechsel zu Open-Source- und kostengünstigeren Modellen

Die schnelle Einführung neuerer, effizienterer Modelle bringt von allen Techniken die größten Kostenvorteile. Um diese Vorteile nutzen zu können, muss ein Unternehmen jedoch erst einmal wissen, welche Modelle seine bestehenden tatsächlich übertreffen. Dies kann schwierig sein, da öffentliche Benchmarks die tatsächliche Leistung bei Coding-Aufgaben nur unzureichend widerspiegeln. Um neue Modelle zu bewerten, haben viele Unternehmen automatisierte Evaluierungen entwickelt, von denen sie glauben, dass sie ihren internen Entwicklungsmix besser repräsentieren. Databricks hat kürzlich ein Beispiel für einen solchen Benchmark veröffentlicht, bei dem wir ein äußerst wettbewerbsfähiges Preis-Leistungs-Verhältnis für GLM-Modelle beobachtet haben. Dieser Benchmark hat uns dazu veranlasst, GLM intern für Entwickler bereitzustellen. Oft verschieben neue Modelle die Effizienzgrenze nicht, und Evaluierungen führen häufig zu negativen Ergebnissen: Stripe stellte fest, dass Opus 4.7 die Qualität im Vergleich zu Opus 4.6 nicht wesentlich verbesserte, während die Kosten stiegen. Sie sahen daher davon ab, Opus 4.7 intern zur Verfügung zu stellen. Databricks verzeichnete ähnliche Kostenrückschritte beim Vergleich von Opus 5.0 mit 4.8.

Harness- und Modellflexibilität

Da die größten Einsparungen durch den Wechsel zu neuen Modellen erzielt werden, wird die Einführung von Endbenutzer-Tools, die Modellflexibilität ermöglichen, zu einer entscheidenden Komponente zur Kostensenkung. Das Tool, das am häufigsten in Verbindung mit einem bestimmten Modell verwendet wird, wird als Harness bezeichnet. Proprietäre Frontier-Modelle werden zunehmend so konzipiert, dass sie gut mit bestimmten Harnesses zusammenarbeiten, was bedeutet, dass bestimmte Harnesses mit bestimmten Modellen „besser funktionieren“. Wenn ein Unternehmen die Modellunabhängigkeit wahren möchte, gibt es im Wesentlichen zwei Ansätze:

Benutzer zum Wechseln des Harness auffordern. Ein Ansatz besteht darin, Entwicklern eine Reihe von Harnesses (Claude Code, Codex oder Cursor) zur Verfügung zu stellen und sie dann zu bitten, zwischen den Harnesses zu wechseln, wenn ein Unternehmen die Ausgaben auf kostengünstigere Modelle verlagern möchte. Dadurch können Benutzer nach Möglichkeit in ihrem bevorzugten Harness arbeiten. Der Nachteil dieses Ansatzes besteht jedoch darin, dass die Umstellungskosten für einen einzelnen Entwickler hoch sein können. Wenn die Umstellungskosten zu hoch werden, führt das Harness selbst de facto zu einem Lock-in-Effekt für eine Modellfamilie, was die Möglichkeit einschränkt, Ausgaben auf wettbewerbsfähigere Modelle zu verlagern.

Einen Meta-Harness verwenden. Ein neuer und immer beliebterer Ansatz ist die Verwendung eines Meta-Harness, das Entwicklern eine einheitliche Benutzeroberfläche bietet, während Anfragen an die zugrunde liegenden Harnesses (sowohl proprietäre als auch Open-Source-Harnesses) weitergeleitet werden. Dieser Ansatz ermöglicht sowohl die Unabhängigkeit von Modellen und Harnesses als auch eine Reduzierung der Umstellungskosten für Entwickler. Bei Databricks ist dies der Standardmodus für Entwickler, die Omnigent nutzen. Einige Unternehmen, mit denen wir gesprochen haben, haben eigene interne Meta-Harnesses entwickelt, die in ihre Entwicklungs-Toolchain integriert sind.

Kostenhebel Nr. 2: Dynamisches Request- und Task-Routing

Anstatt die Benutzer aufzufordern, selbst die für die jeweilige Aufgabe geeigneten Modelle auszuwählen, legt eine wachsende Zahl von Forschungsarbeiten nahe, dass eine automatische Modell- und Tool-Auswahl die Effizienz von agentischen Coding-Workflows weiter steigern kann. Routing-Ansätze lassen sich grob in drei Kategorien einteilen:

• Routing auf Request-Ebene: Ein zustandsbehafteter Proxy befindet sich zwischen einem Client (z. B. einem Coding-Harness) und den zugrunde liegenden Foundation-Modellen. Der Proxy versucht, Anfragen an das kostengünstigste Modell weiterzuleiten, das in der Lage ist, die jeweilige Inference-Anfrage zu beantworten. Das Routing für agentische Anwendungsfälle muss auch das serverseitige Caching berücksichtigen, da ein Cold-Cache-Treffer bei Workloads mit großem Kontext sehr hohe Kosten verursacht. Eine neue Welle von Produkten zeigt erste, vielversprechende Ergebnisse für das Routing. Beispiele hierfür sind: Cursor Router, der AutoRouter von OpenRouter, das Router-Feature von Ramp und das Databricks-eigene Smart-Routing-Feature im Unity AI Gateway.
• Routing auf Task-Ebene (Meta-Harness): Ein clientseitiger Prozess verteilt Benutzeraufgaben basierend auf der Komplexität der Aufgabe an verschiedene Harnesses. Eine Benutzeraufgabe könnte „Benenne diese Komponente von X in Y um“ (eine einfache Aufgabe) oder eine offene Aufgabe wie „Untersuche Designüberlegungen, die die Latenz verringern würden“ (eine komplexe Aufgabe) sein. Der Dispatcher, oft als Meta-Harness bezeichnet, prüft, welche Stufe des zugrunde liegenden Modells für eine Aufgabe erforderlich ist, und delegiert dann diese gesamte End-to-End-Aufgabe an das Modell. Omnigent ist ein Beispiel für einen Meta-Harness, der dieses Muster unterstützt.
• Eskalations-/Delegationsmuster: Ein einzelnes Harness kombiniert zwei Modelle (ein teures Modell mit hoher Intelligenz und ein günstiges Worker-Modell). Bei einigen Ansätzen, wie dem Advisor-Tool von Claude, übernimmt das günstigere Modell die Führung und eskaliert, wenn es der Meinung ist, dass eine Aufgabe mehr Leistung erfordert. Es gibt auch das umgekehrte Muster: Bei Devin Fusion von Cognition bildet das teurere Modell die Hauptschleife und lagert Arbeit selektiv an ein günstigeres Modell aus.
  Interne Ergebnisse bei Databricks deuten darauf hin, dass unser AI Gateway Smart Router in der Lage ist, die durchschnittlichen Task-Kosten konsistent um mehr als 30 % zu senken und gleichzeitig in etwa die Qualität des teuersten Modells im Working Set zu erreichen. Andere Unternehmen, mit denen wir gesprochen haben, haben ähnliche Ergebnisse erzielt.

Kostenhebel Nr. 3: Entwicklern Transparenz, Warnschwellen und Budgets bieten

Es mag überraschen, dass dieser gesamte Artikel nicht mit dem Satz „Geben Sie den Nutzern ein monatliches Budget und fertig“ beginnt und endet. Strikte Budgets, bei denen die Nutzung ab einer bestimmten Ausgabengrenze komplett gesperrt wird, werden in fast allen Unternehmen, mit denen wir gesprochen haben, nur als letztes Mittel eingesetzt. Es gibt zwei Gründe, warum strikte Token-Budgets für das Ausgabenmanagement im Bereich AI nicht besonders effektiv sind: Erstens: Wenn Entwickler ihr Budgetlimit erreichen, würde die Sperrung des Zugangs zu AI-Tools ihre Produktivität massiv beeinträchtigen. Weder das Unternehmen noch die Mitarbeitenden wollen dieses Ergebnis. Zweitens sind zumindest einige der Nutzer mit hohen Ausgaben genau diejenigen, die mit AI enorme Effizienzsteigerungen erzielt haben und eine immense Leistung erbringen. Diese Nutzer zu demotivieren, wäre kontraproduktiv.

Anstelle einer strikten Obergrenze für die Ausgaben der Nutzer setzen die meisten Unternehmen auf einen differenzierteren und schrittweisen Ansatz. Dieser konzentriert sich auf Transparenz für die Endnutzer und führt mit steigenden Ausgaben zu mehr Hürden.

1. Transparenz: Jedes Unternehmen, mit dem wir gesprochen haben, verfügte über einen Mechanismus, um den Nutzern nahezu in Echtzeit Rückmeldung zu ihren laufenden Ausgaben zu geben. Viele boten zudem konkrete Tipps oder Einblicke, wie sich die Ausgaben durch die Nutzung kostengünstigerer Modelle senken lassen. Es ist wichtig, dass die Nutzer ihre Ausgaben über alle Tools hinweg einsehen können, da sie so die Wahl des Tools mit dem höchsten ROI gezielt steuern können.

   

   Ein Entwickler-Dashboard bei Databricks, das die aktiven Ausgaben anzeigt

2. Ausgabenschranken: Entwickler können aufgefordert werden, bei steigenden Ausgaben bestimmte Maßnahmen zu ergreifen oder Genehmigungen einzuholen. Die einfachste Form einer Ausgabenschranke ist eine, die selbst freigegeben werden kann und als Warnung dient, dass die Ausgabenrate einen bestimmten Schwellenwert überschreitet. Wir bei Databricks haben festgestellt, dass selbst freigebbare Schranken ein nützlicher Mechanismus sind, um versehentliche oder unbeabsichtigte Ausgaben zu verhindern. Es können weitere Schranken eingeführt werden, die eine ausdrückliche Budgetgenehmigung erfordern (häufig über die Managementebene).
3. Herabstufung: Wenn ein Entwickler eine Ausgabenschranke erreicht hat, kann er auf ein kostengünstigeres Modell herabgestuft werden, anstatt ihm den Token-Zugriff komplett zu entziehen. Da die günstigsten Modelle drastisch billiger sind als Frontier-Modelle, können Entwickler mit dieser Methode ihre Arbeit fortsetzen, ohne dass massive laufende Kosten entstehen.
4. Sperrung: Im Extremfall behalten die meisten Systeme die Möglichkeit bei, Nutzer vollständig vom Token-Zugriff zu sperren. Wie oben erwähnt, ist dies meist nur eine vorübergehende Maßnahme und der Ausgangspunkt für ein Gespräch darüber, wie AI effizient genutzt werden kann.

Kostenhebel Nr. 4: Reduzierung des Token-Overheads

Wenn ein Nutzer eine relativ einfache Anfrage in einen AI-Coding-Agenten eingibt (wie z. B. „Bitte untersuche und behebe diesen Fehler.“), sammelt dieser Agent anschließend riesige Mengen an relevantem Kontext, ruft eine Vielzahl von Tools auf, durchsucht die Codebasis und integriert vom Unternehmen bereitgestellte Fähigkeiten oder Systeminformationen. Bis die kostspielige LLM-Inferenz erfolgt, macht die ursprüngliche Eingabe des Nutzers nur einen verschwindend geringen Teil der in das AI-System eingespeisten Daten aus. Das bedeutet, dass die Kosten hauptsächlich durch den Kontext entstehen, den der Nutzer nicht explizit angegeben hat. Techniken zur Reduzierung dieses Kontext-Overheads (Context Bloat) sind noch neu, aber es werden bereits mehrere vielversprechende Ansätze untersucht, wie zum Beispiel:

• Erzwingen einer häufigeren Komprimierung (Kompaktierung) des aktiven Kontexts.
• Nutzung von Harnesses, die „weniger gesprächig“ (token-effizienter) sind, oder die Anpassung bestehender Harnesses, um weniger Token-Overhead zu erzeugen.
• Überprüfung beliebter Tools und Reduzierung ihrer Detailtiefe (Verbosity).
• Entwickler dazu anhalten, Aufgaben in kleinere, einzelne Arbeitsschritte zu unterteilen, um den Kontextumfang zu verringern.

Wenn der Kontext groß wird, spielt auch das Prompt-Caching eine wichtige Rolle für die Gesamtleistung. Sowohl proprietäre als auch Open-Source-LLMs verfügen über Einstellungen, mit denen Sie das Prompt-Caching aktivieren und die Speicherdauer des Cache anpassen können. Das Schreiben in den Cache kostet Geld, aber das Lesen aus dem Cache kann die Kosten pro Inferenz drastisch senken. Dieser Abwägungsprozess hängt von der spezifischen Arbeitslast eines Unternehmens ab. Daher kann eine manuelle Anpassung der Standard-Cache-Einstellungen zur Erhöhung der Cache-Trefferquote (Cache Hit Rate) die Gesamtkosten drastisch senken.

Bei Databricks führte eine relativ einfache Anpassung unserer Harness- und Caching-Einstellungen zu einer Reduzierung der generierten Token und der damit verbundenen Kosten um fast 50 % – ohne spürbare Qualitätseinbußen für die Entwickler. Wir erforschen weiterhin Techniken in diesem Bereich und glauben, dass noch erhebliche zusätzliche Optimierungen möglich sind.

Eine drastische Reduzierung der Token pro Sitzung durch die Eliminierung überflüssiger Inferenzaufrufe und die Reduzierung von Cache-Schreibvorgängen.

Das AI-Gateway-Designmuster

Die oben genannten Techniken brachten viele implizite technische Anforderungen mit sich: Um neue Modelle schnell nutzen zu können, benötigen Unternehmen einen zentralen Ort, an dem das „Modellmenü“ verwaltet wird, und Endnutzer benötigen eine Toolchain, die die Kombination verschiedener Modelle (Model Mixing) unterstützt. Um Budgettransparenz über mehrere AI-Tools hinweg zu gewährleisten, ist eine einheitliche Funktion zur Kostenüberwachung (Cost Observability) erforderlich. Um den Kontext-Overhead zu verwalten, müssen Unternehmen in der Lage sein, typische Tool-Aufrufe (Toolcalls) zu überwachen und eine Komprimierung oder Kompaktierung zu erzwingen. Diese Anforderungen werden zusammenfassend durch eine neue Klasse von Infrastruktursoftware gelöst, die am besten als AI Gateway bezeichnet wird. Ein AI Gateway ist ein zentraler Ort, an dem all dies geschieht:

1. Kapazitätsmanagement und Proxy-Zugriff auf die zugrunde liegenden Modelle (sowohl proprietäre als auch OSS-Modelle).
2. Budgetüberwachung und -durchsetzung, einschließlich komplexer Budgetrichtlinien wie schrittweiser Hürden und Modellherabstufungen.
3. Konfigurationsmanagement für Endnutzer-Tools zur Durchsetzung von Modell-Allowlists, Kompaktierungseinstellungen und anderen lokal vermittelten Aspekten.
4. Protokollierung von Traces aus Coding-Sitzungen für nachgelagerte Effizienzanalysen und Benchmarks.

Bei Databricks verlassen wir uns für all diese Funktionen stark auf das Unity AI Gateway.

Fazit

Das exponentielle Wachstum der AI-Coding-Kosten ist kein unumgängliches Schicksal, sondern ein lösbares Engineering- und Governance-Problem. Unternehmen, die diese Kosten in den Griff bekommen haben, nutzen ein gemeinsames Konzept: Sie streben unermüdlich nach maximaler Effizienz statt nach maximaler Modellintelligenz, setzen Tools ein, die die Flexibilität der Modelle wahren, leiten Aufgaben intelligent an das günstigste geeignete Modell weiter, ersetzen strikte Budgets durch Transparenz und schrittweise Hürden und reduzieren den Token-Overhead, der die tatsächlichen Ausgaben dominiert. Keine dieser Techniken erfordert den Verzicht auf die Produktivitätsgewinne, die die Einführung von AI überhaupt erst lohnenswert gemacht haben. Zusammen ermöglichen sie es Unternehmen, die doppelte Anforderung eines breiten, unkomplizierten Zugangs in einem kalkulierbaren Kostenrahmen zu erfüllen.

Es entstehen neue Infrastruktur-Abstraktionen, die Unternehmen die Werkzeuge zur Kostenkontrolle an die Hand geben. Bei Databricks haben wir die Schlüsselkomponenten unseres Kostenmanagement-Stacks als Open-Source- oder kostenlose Softwareprodukte veröffentlicht: Unser Unity AI Gateway für die zentrale Verwaltung und Omnigent für Entwickler-Tools. Tausende von Unternehmen nutzen diese Komponenten täglich. Wir laden weitere Unternehmen dazu ein, ihre Erkenntnisse zu teilen und Methoden zu vergleichen, während sich diese Technologielandschaft rasant weiterentwickelt.

Danksagung: Vielen Dank an die Infrastruktur-Verantwortlichen bei Uber, Stripe, Coinbase und Ramp, die diesen Artikel kommentiert und geprüft haben. Vielen Dank an Thrive Capital für das Feedback zu einem frühen Entwurf dieses Artikels.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag