Der Stapellauf, der den Assistenten auffraß
Um neun Uhr morgens brauchte der Assistent neun Sekunden statt zwei. Es war nichts ausgerollt worden, das Modell war in Ordnung, und die Ursache war ein Stapellauf, der zu spät gestartet war und noch lief, als die Leute kamen.
Der Morgen
Antworten, die normalerweise zwei Sekunden brauchen, brauchten neun. Das Modell antwortete im Direkttest normal, der Index war gesund, und die Anwendungsprotokolle zeigten Anfragen in der Warteschlange statt Fehlschlägen.
Die Ursache war ein Aufnahmelauf, der neu eingetroffene Dokumente neu einbettet. Er läuft üblicherweise von zwei bis fünf Uhr morgens. In jener Nacht hatte ein Lieferant ein großes Archiv geliefert, der Lauf lief um neun noch — und er und der Assistent teilen sich einen GPU-Pool.
Warum der Autoscaler uns nicht gerettet hat
Er hat korrekt gegen die Kennzahl skaliert, die er bekommen hatte: durchschnittliche Auslastung über fünf Minuten. Unter einer Stapellast, die die Auslastung hoch und gleichmäßig hält, sagt diese Kennzahl, der Cluster arbeite kräftig — und unterscheidet nicht zwischen Arbeit, auf die jemand wartet, und Arbeit, auf die niemand wartet.
Park veröffentlichte Anfang 2026 eine Untersuchung dazu, wie Infrastrukturfehler Autoscaler zu Fehlzuteilungen führen. Unserer hatte keinen Fehler; er hatte eine Konfiguration, die eine Art von Last unterstellte — die häufigere Variante desselben Ergebnisses und schwerer zu bemerken, weil nichts kaputt ist.
Zwei Lasten mit gegensätzlichen Anforderungen
Der Assistent braucht niedrige Latenz und hat stoßweise, geringe Nachfrage. Der Aufnahmelauf braucht Durchsatz und schert sich überhaupt nicht um Latenz. Beide auf einem Pool heißt, der Pool ist auf eines von beiden abgestimmt — und er war auf keines von beidem besonders abgestimmt.
Das ist der Entwurfsfehler, und er stammt von uns und nicht von einer Komponente. Kapazität zwischen beiden zu teilen war eine Kostenentscheidung aus einer Zeit mit kleinem Aufnahmevolumen, und niemand hat sie überprüft, als das Volumen wuchs.
| Last | Was sie braucht |
|---|---|
| Interaktiver Assistent | Niedrige Latenz, reservierte Kapazität |
| Nächtliche Aufnahme | Durchsatz, verdrängbare Kapazität |
| Bewertungsläufe | Weder noch. Laufen irgendwann |
| Gemeinsamer Pool für alle drei | Die Konfiguration, die das ausgelöst hat |
Was wir geändert haben
Getrennte Pools, der interaktive klein und reserviert, der Stapel-Pool verdrängbar. Der Aufnahmelauf weicht heute zurück, wenn die interaktive Nachfrage steigt — eine große Aufnahme dauert damit länger und taucht nie wieder als Latenz für einen Menschen auf.
Wir haben dem Aufnahmelauf außerdem eine Frist gegeben statt eines Zeitplans. Er muss bis sieben fertig sein, und schafft er das nicht, teilt er sich und setzt in der Folgenacht fort — eine Eigenschaft, die dem Kunden lieber ist als ein unbegrenzter Lauf, der den Vormittag frisst.
Der Alarm, den wir nicht hatten
Zeit bis zum ersten Token nach Tagesstunde, mit Alarm auf eine Verschiebung statt auf eine Schwelle. Wir hatten Latenzüberwachung, und sie war über den Tag gemittelt — eine schlechte Stunde alle paar Wochen verschwand also in einer guten Tageszahl.
Dieser Alarm hätte es einen Monat früher gefangen, denn die Überlappung war zuvor zweimal in kleinerem Maßstab aufgetreten und niemandem aufgefallen. Der Vorfall war das erste Mal, dass die Überlappung für Nutzer sichtbar wurde — nicht das erste Mal, dass sie auftrat.
Warum wir nicht einfach Kapazität ergänzt haben
Weil es funktioniert und das Problem verdeckt hätte. Mehr Kapazität verschiebt die Schwelle, an der beide Lasten kollidieren, und die Kollision passiert dann bei einer größeren Lieferung, zu einem schlechteren Zeitpunkt und mit einer höheren Rechnung in der Zwischenzeit.
Die Trennung kostete rund fünfzehn Prozent mehr reservierte Kapazität und beseitigte den Fehlermodus vollständig. Das ist ein erklärbarer Handel, während eine Verdopplung des Pools Kosten ohne Begründung gewesen wäre, außer der, ein Symptom zum Verschwinden zu bringen.
Die allgemeine Regel, die wir mitgenommen haben
Teile keine Kapazität zwischen Arbeit, auf die jemand wartet, und Arbeit, auf die niemand wartet. Aufgeschrieben klingt das selbstverständlich, und es wurde in unserer eigenen Infrastruktur zwei Jahre lang von Leuten verletzt, die ihm im Abstrakten zugestimmt hätten.
Es überlebt, weil Teilen auf einer Auslastungsgrafik effizient aussieht. Hohe Auslastung ist ein gutes Zeichen für einen Stapel-Cluster und eine Warnung für einen interaktiven — und eine einzige Grafik über beide sagt weder das eine noch das andere.
Was wir nicht behaupten
Wir behaupten nicht, Trennung sei immer richtig. Bei einem kleinen System mit überschaubarem Volumen ist ein Pool einfacher und die Kollision tritt vielleicht nie auf — mehrere davon betreiben wir bewusst so.
Wir behaupten auch nicht, unser Alarm fange jede Variante. Er fängt eine Verschiebung der Latenz nach Stunde, und eine gleichmäßig über den Tag verteilte Verschlechterung ginge unbemerkt durch. Diese Grenze kennen wir und haben sie nicht geschlossen.