KI-Agenten im Unternehmen: AI21 verkürzt Wartezeit von 72 auf 12 Stunden

Von zweiundsiebzig Stunden auf zwölf

Am 3. Oktober 2026 hat AI21 Labs das Vorher und Nachher seiner Trainingsumgebung öffentlich gemacht, mit Zahlen belegt.

Jobs mit hoher Priorität sind Trainingsläufe über viele Knoten: Sie fordern die halbe Cluster-Kapazität oder mehr und liegen auf dem kritischen Pfad eines Modellprojekts. Früher blieben sie bis zu 72 Stunden in der Warteschlange und warteten darauf, dass zusammenhängende Kapazität frei wurde.

Heute startet dieselbe Klasse von Jobs innerhalb von 12 Stunden. Die manuellen Scheduling-Eingriffe sind von zwanzig pro Woche auf null gesunken, wie das Labor im Google Cloud Blog berichtet^[1]. Die zusammenfassende Zahl, die das Team in die erste Zeile stellt, ist eine Reduzierung der Startzeit der Workloads um 83%.

Der Rahmen dieses Ergebnisses bleibt eine einzige Trainingsumgebung, und das gehört gleich zu Beginn erwähnt.

Die ursprüngliche Idee: eine einzige Flotte, null feste Anteile

AI21 baut Basismodelle, darunter die Jamba-Familie, und verkauft Technologie zur Optimierung von Agenten. Das Training läuft auf einem seiner gemeinsam genutzten Cluster auf Google Kubernetes Engine.

Dieser Cluster bündelt mehrere Tausend Google Cloud A3-Instanzen mit NVIDIA H100 GPUs und A3 Ultra-Instanzen mit H200 GPUs. Jedes Team greift auf die volle Kapazität der Flotte zu, anstatt in dem ihm zugewiesenen Anteil eingeschlossen zu bleiben. Auf derselben Infrastruktur laufen die Jamba-Modelle und die Workloads zur Optimierung der Agenten.

Die Entscheidung sieht nach einer Infrastrukturwahl aus.

Sie ist eine Wahl der Ressourcen-Governance.

Alles zu bündeln hält die Auslastung hoch, nahe 100%, und genau dort will ein Unternehmen eine reservierte und bereits bezahlte Rechenflotte sehen. Es macht das Scheduling zugleich schwierig, und das Labor schreibt es in aller Deutlichkeit.

Als Kapazität auf Slack verhandelt wurde

Bevor die Orchestrierung an GKE überging, wurde Kapazität von Hand verhandelt. Wer GPUs brauchte, schrieb in den Kanal #gpu-resources und hoffte auf eine nützliche Antwort.

Die Methode funktionierte, solange der Cluster freien Spielraum hatte.

Sie hörte auf zu funktionieren, als die Auslastung nahe am Maximum feststeckte.

Ab diesem Moment wurde jede Anfrage zu einer Verhandlung. Die Teamleiter verbrachten ihre Zeit als Schiedsrichter in Streitfällen um Rechenzeit, anstatt an den Modellen zu arbeiten. Die Kosten dieser Phase lassen sich in zwei Währungen messen: in den Wartestunden der Forschenden und in den Koordinationsstunden der technischen Leitung.

Zwanzig manuelle Eingriffe pro Woche zeigen die Größenordnung des Problems. Das waren vier pro Tag, jeden Tag, um eine Warteschlange am Leben zu halten, die die Software selbst verwalten konnte.

Zwei Probleme, für eines gehalten

Hier kommt der lehrreichste Teil der Geschichte, und er kommt als Korrektur.

Die Knappheit erzeugte zwei verschiedene Probleme, und das Labor räumt ein, sie erst nach einiger Zeit als getrennt erkannt zu haben. Das erste ist der Wettbewerb: wer den nächsten Zugang zur Rechenzeit erhält. Die menschliche Verhandlung löste dieses.

Das zweite ist die Fragmentierung: auf dem Papier freie Kapazität, verstreut in Stücken, die für einen großen Job zu klein sind. Acht freie GPUs, verteilt als 1+1+4+2 auf vier Knoten, lassen einen Workload liegen, der acht GPUs zusammenhängend anfordert. Das ist ein Packungsproblem, und die Diplomatie auf Slack lässt es unberührt.

Monate an Verhandlungen hatten am falschen Symptom gearbeitet. Die Scheduling-Policy auf dem einzigen Cluster greift beide Probleme an: Sie entscheidet die Prioritäten und verdichtet die freien Stücke.

Der Unterschied zählt für jeden, der eine Warteschlange verwaltet. Der Wettbewerb wird mit einer Prioritätsregel gesteuert. Die Fragmentierung wird darüber gesteuert, wie die Jobs auf den Knoten platziert werden, und verlangt eine Maschine, die die gesamte Flotte auf einmal sieht.

Erklärtes Ergebnis und geprüftes Ergebnis

Die Unterscheidung zählt. Der Bericht trägt die Signatur von Barak Peleg, VP Technology and Architecture bei AI21, und von Asaf Ben-Tovim, DevOps Engineer. Der Text erscheint im Blog des Cloud-Anbieters, der die Infrastruktur verkauft hat.

Damit werden die Zahlen zu einer Erklärung aus erster Hand auf einem interessierten Kanal. Ein unabhängiges Audit fehlt, und wer liest, sollte die 83% als das behandeln, was sie sind: eine interne Messung, veröffentlicht von dem Unternehmen, das sie erzielt hat.

Der Wert dieses Falls liegt in der Form der Messung. Es gibt zwei Vorher-Nachher-Paare mit einem klaren Nenner. 72 Stunden gegen 12 Stunden bei derselben Klasse von Jobs, zwanzig Eingriffe gegen null in derselben Arbeitswoche.

Außen bleiben die Daten, die das Bild vervollständigen würden: der genaue Auslastungsgrad, die Kosten pro Trainingslauf, die gesamte Durchlaufzeit. Eine berechtigte Forderung für jeden, der diesen Schritt nachbauen will.

Was sich für alle ändert, die Agenten in Produktion bringen

Viele Unternehmen bringen heute KI-Agenten in die Enterprise-Produktion und entdecken den Engpass an derselben Stelle: in der Warteschlange für Rechenzeit.

Für die Gründerin oder den Gründer eines KMU kostet das übertragbare Playbook null an Lizenzen. Es genügt, die Kapazität in einen einzigen Pool zu legen und eine Prioritätsregel zu schreiben, anstatt Maschinen pro Team zuzuweisen. Der Vorteil kommt aus der Regel, noch vor der Hardware.

Für eine CTO oder einen CTO ist das technische Signal präzise: Der Orchestrator verwaltet Wettbewerb und Packung besser als ein Chat-Kanal. Die Bedingung lautet, die Prioritäten ausdrücklich zu erklären.

Für ein Board betrifft die Verschiebung der Messlatte die Rendite auf die bereits gekaufte Flotte. Dieselbe Menge GPUs erzeugt mehr nützliche Läufe, sobald die Warteschlange zu einer lesbaren Regel wird. Für eine Teamleitung reist die Idee auch über die GPUs hinaus: Jede knappe Ressource, die von Hand verteilt wird, erzeugt Schiedsrichter, und Schiedsrichter kosten Senior-Gehälter.

Was bleibt

Drei Lektionen bleiben auch weit entfernt von der Welt der Basismodelle bestehen.

Die erste: Die Jahre zuvor getroffene Architekturentscheidung wiegt schwerer als die Technologie des Augenblicks. Der einzige Pool ist der Schritt, der den Gewinn möglich gemacht hat, und die Orchestrierungsplattform hat den Rest geleistet.

Die zweite: Jede gemessene Erfolgsgeschichte enthält eine Korrektur. Hier ist die Korrektur eine im Kopf, und sie ist mehr wert als die Zahlen. Zwei Probleme sahen wie eines aus, und die richtige Lösung kam, nachdem sie getrennt worden waren.

Die dritte: Eine erklärte Verbesserung gewinnt an Gewicht, sobald sie mit einem Nenner kommt. «Wartezeit reduziert» sagt wenig. «Von 72 Stunden auf 12 Stunden bei Jobs, die den halben Cluster belegen» sagt viel.

Die offene Frage gilt für jede Organisation: Welche knappe Ressource wird in deinem Unternehmen heute von einer Person in einem Chat-Kanal zugewiesen? Und was kostet diese Person jede Woche für die Rolle als Schiedsrichter?