Angesichts steigender KI-Kosten ist die gängigste Reaktion, die Nutzung zu beschränken: Verbrauchsobergrenzen, Nutzerkontingente und Genehmigungen vor dem Start von Agents. Solche undifferenzierten Beschränkungen können jedoch sinnvolle Anwendungen behindern und messen die falsche Kennzahl, wie die Analyse zeigt.
- Obergrenzen messen nur den Verbrauch, nicht die gelieferte Arbeit.
- Relevanter ist die Kennzahl Kosten pro akzeptiertem Merge Request, die Qualität muss dabei im Blick bleiben.
- Ein Gateway leitet jede Anfrage an das passende Modell, und teure Modelle kommen nur bei Bedarf zum Einsatz.
- Open-Weight-Modelle übernehmen Routinearbeit, müssen aber zuvor am eigenen Code getestet werden.
Die Kosten pro Token (eine Texteinheit, die von einem Sprachmodell verarbeitet wird) messen den Verbrauch, nicht die Ergebnisse. Ein Teil der Ausgaben entspricht Verschwendung, wie wiederholte Anfragen oder unkontrollierte Schleifen, während ein anderer Teil die eigentliche Arbeit der Softwarelieferung darstellt. Ein Zähler kann dies ebenso wenig unterscheiden wie eine Ausgabengrenze.
Die gelieferte Software messen
Eine relevantere Kennzahl wären die Kosten pro akzeptiertem Merge Request, also die Gesamtkosten der KI-gestützten Entwicklung dividiert durch die Anzahl der Änderungen, die das Review passieren und in den Code integriert werden, im Jargon « Pull Requests » genannt. Parallel müssen Nachbesserungen und Fehler verfolgt werden, damit kostengünstigere Änderungen keine Qualitätsverschlechterung verschleiern.
Sinken diese Kosten bei steigender Nutzung ohne Qualitätseinbußen, wandeln Entwickler mehr Verbrauch in nützliche Software um. Es geht also nicht um die Anzahl der verwendeten Token, sondern um die Menge an erledigter Arbeit, die die Investition hervorbringt. Um dieses Verhältnis zu verbessern, werden zwei Hebel genannt: kostspielige Inferenz für Aufgaben reservieren, die sie benötigen, und die Kosten der Routinearbeit senken.
Das Modell an die Aufgabe anpassen
Agentische Entwicklung, bei der ein Agent autonom Code schreibt und ändert, erfordert nicht bei jedem Schritt das leistungsstärkste Modell. Ein Spitzenmodell oder ein vor Ort gehostetes Flaggschiffmodell bei entsprechender Unternehmenspolitik kann für komplexe Planung und neuartiges Reasoning reserviert werden. Einfachere Aufgaben wie Codegenerierung, Test-Erstellung oder wiederholte Refaktorierungen können an Open-Weight-Modelle delegiert werden, die das Unternehmen direkt betreibt.
Ein Gateway kann jede Anfrage nach Komplexität, Datensensibilität, Kosten und Latenz lenken. Das erste Modell kommt somit nur zum Einsatz, wenn die Situation es rechtfertigt. Wie der Autor zusammenfasst: « Meter the exception, not the workload », also: Miss die Ausnahme, nicht die Arbeitslast.
Open-Weight-Modelle machen diese Aufteilung immer praktikabler. Laut zitierten Software-Engineering-Benchmarks können die besten unter ihnen bei bestimmten Aufgaben an Spitzenleistungen heranreichen. Diese Feststellung garantiert keine Gleichwertigkeit über alle Code-Repositories oder Workflows hinweg. Daher wird empfohlen, Kandidaten am eigenen Code, eigenen Tests und eigenen Akzeptanzkriterien zu evaluieren, bevor man ihnen Produktionsarbeit anvertraut.
Die Ökonomie wiederholter Nutzung ändern
Es bleibt zu klären, wer die Rechenkapazität besitzt. Bei gemieteter Inferenz schlägt jeder Aufruf auf der Rechnung zu Buche. Bei eigener Kapazität sind die wesentlichen Kosten bereits im Voraus entstanden, sodass jeder zusätzliche Aufruf mit steigender Nutzung günstiger wird.
