Wenn ein KI-System im Unternehmen langsam wird, lautet die erste Vermutung fast immer: zu wenig Rechenleistung. In der Praxis ist die Ursache häufiger eine falsche Betriebsart. Aufgaben, die niemand in dieser Sekunde braucht, werden trotzdem in dieser Sekunde gerechnet — und verdrängen dabei genau die Aufgaben, auf die ein Mensch gerade wartet. Wer diese beiden Klassen sauber trennt, bekommt spürbar mehr Durchsatz, ohne einen Euro in Hardware zu stecken.
Interaktiv und rechenintensiv sind zwei verschiedene Betriebsarten
Eine Rückfrage im Chat, eine Klassifizierung im Posteingang, eine Zusammenfassung im Gespräch: Solche Aufgaben sind kurz, und ihr Wert verfällt in Sekunden. Eine Antwort nach zwei Minuten ist wertlos, auch wenn sie perfekt ist. Dem gegenüber steht die zweite Klasse: Belege des Vortags auslesen, hunderte Datensätze anreichern, Berichte bauen, Medien rendern, einen Wissensindex neu aufbauen. Diese Aufgaben sind lang, und ihr Wert verfällt nicht. Ob sie um drei Uhr nachts oder um sechs Uhr morgens fertig werden, ist gleichgültig — Hauptsache, sie sind fertig, bevor der Betrieb sie braucht.
Der Fehler beginnt dort, wo beide Klassen dieselbe Warteschlange benutzen. Dann bestimmt der Zufall, wer zuerst drankommt. Die lange Aufgabe blockiert die kurze, der Nutzer wartet, jemand startet die Anfrage neu, und die doppelte Last macht es schlimmer.
Der eigentliche Engpass ist der Speicher, nicht die Rechenzeit
Bei lokal betriebenen Modellen ist der knappe Posten selten die reine Rechenleistung, sondern der Grafikspeicher. Ein Sprachmodell belegt ihn vollständig, solange es geladen ist. Kommt ein zweites Modell dazu — ein Bildmodell, ein Einbettungsmodell für die Wissenssuche —, passt es nicht mehr daneben. Das System lädt aus und wieder ein. Genau dieses Ein- und Ausladen kostet die meiste Zeit, und es fällt bei jedem Wechsel erneut an.
Das Muster ist im Log gut zu erkennen: Nicht die Aufgabe selbst dauert lange, sondern die Zeit davor. Ein Auftrag, der allein in Sekunden durchläuft, braucht im Wechselbetrieb ein Vielfaches — und läuft irgendwann in einen Zeitablauf, der als „Modell antwortet nicht" protokolliert wird. Die Fehlermeldung zeigt auf das Modell. Schuld ist die Terminplanung.
Phasen trennen: erst alles denken, dann alles rechnen
Die wirksamste Gegenmaßnahme ist banal und wird trotzdem selten umgesetzt: Ein Batch-Lauf verarbeitet nicht Auftrag für Auftrag komplett, sondern Arbeitsschritt für Arbeitsschritt über alle Aufträge hinweg. Zuerst laufen sämtliche Textschritte durch — mit genau einem geladenen Modell. Dann wird dieses Modell bewusst entladen. Erst danach beginnt der Teil, der ein anderes Modell braucht.
Der Unterschied ist erheblich, weil das Ein- und Ausladen von vielen Malen auf ein einziges Mal fällt. Der Preis dafür ist, dass die erste Phase vollständig abgeschlossen sein muss, bevor die zweite beginnt — Zwischenergebnisse müssen also auf die Platte, nicht in den Arbeitsspeicher. Genau das ist die Voraussetzung für den nächsten Punkt.
Wiederaufnahme statt Neustart
Ein Nachtlauf, der bei einem Fehler von vorn beginnt, ist kein Nachtlauf, sondern ein Glücksspiel. Jeder abgeschlossene Teilschritt gehört sofort persistiert, mit einem Zustand, den der nächste Start lesen kann. Fällt der Lauf in der zweiten Phase aus, wird nur die zweite Phase wiederholt. Das klingt nach Kleinigkeit, entscheidet aber darüber, ob ein einzelner Aussetzer eine Nacht kostet oder zehn Minuten.
- Zustand nach jedem Teilschritt schreiben, nicht erst am Ende des Laufs.
- Fehler pro Auftrag abfangen, damit ein schlechter Datensatz nicht den ganzen Stapel mitreißt.
- Vorflug prüfen: Sind alle Dienste erreichbar? Ein sauberer Abbruch vor dem Start ist besser als vier Stunden Zeitüberschreitungen.
- Harte Obergrenze je Auftrag setzen, damit ein hängender Einzelfall nicht den Rest der Nacht auffrisst.
- Ausweichweg definieren: Was wird ausgeliefert, wenn der aufwendige Weg scheitert? Ein einfacheres Ergebnis ist besser als kein Ergebnis.
Doppelverarbeitung ist der teuerste Fehler im Batch
Sobald ein zweiter Prozess dieselbe Arbeitsliste anfasst, wird es gefährlich. Der klassische Ablauf: Der Nachtlauf liest die Liste zu Beginn in den Speicher, arbeitet stundenlang und schreibt seinen Stand am Ende zurück. In der Zwischenzeit hat ein anderer Prozess Einträge als erledigt markiert. Das Zurückschreiben setzt diese Markierung auf „offen" — und der nächste Durchlauf erledigt sie ein zweites Mal. Nach außen sichtbar wird das erst, wenn dieselbe Nachricht mehrfach herausgeht.
Jede geteilte Arbeitsliste braucht drei Dinge: eine Sperre beim Schreiben, eine Reservierung des einzelnen Eintrags vor der eigentlichen Aktion, und ein Zurückschreiben, das nur den eigenen Eintrag ändert statt der ganzen Datei. Fehlt eines davon, ist die Doppelverarbeitung keine Frage des Ob, sondern des Wann.
Der Morgen entscheidet, ob der Lauf etwas wert war
Ein Batch-Lauf arbeitet ohne Zuschauer. Deshalb braucht er am Ende eine maschinenlesbare Bilanz: Was war geplant, was ist entstanden, was ist gescheitert und woran. Diese Bilanz gehört nicht in eine Logdatei, die niemand öffnet, sondern in dieselbe Übersicht, in der die Zahlen des Tages stehen. Ohne sie bleibt der häufigste Fall unentdeckt — der Lauf meldet keinen Fehler, hat aber nur die Hälfte geschafft. Das ist derselbe blinde Fleck, der auch anderswo im Betrieb entsteht und den wir in Stille Ausfälle: warum Prozesskontrolle nicht reicht ausführlicher behandeln.
Der Weg dahin ist unspektakulär: Aufgaben nach Dringlichkeit sortieren statt nach Auftragseingang, alles Nicht-Dringende in ein festes Zeitfenster außerhalb der Arbeitszeit legen, die Phasen darin sauber trennen, jeden Schritt wiederaufnehmbar machen und den Zugriff auf gemeinsame Listen sperren. Danach ist die vorhandene Hardware in aller Regel deutlich weniger ausgelastet, als sie vorher wirkte — und die Frage nach dem größeren Rechner stellt sich für eine ganze Weile nicht mehr.