Batch oder Realtime: Verarbeitungsmodelle für LLM-Workloads richtig wählen

Nicht hinter jeder LLM-Anfrage sitzt ein Mensch, der auf die Antwort wartet. Wer zehntausende Dokumente klassifizieren, einen CRM-Bestand anreichern oder ein Archiv zusammenfassen will, braucht keine Antwort in zwei Sekunden. Trotzdem laufen solche Aufgaben in vielen Systemen über denselben synchronen Pfad wie der Chat mit dem Nutzer: Request raus, auf Antwort warten, nächster Request.

Das ist die teuerste und fragilste Art, LLM-Workloads zu verarbeiten. Synchrone Schleifen über große Bestände kämpfen mit Rate Limits, brechen bei Fehlern in der Mitte ab und zahlen den vollen Preis pro Token, obwohl niemand die Geschwindigkeit braucht. Die meisten großen Anbieter bieten längst einen zweiten Weg an: Batch-Verarbeitung mit deutlich reduzierten Preisen, wenn man auf die sofortige Antwort verzichtet.

Die Entscheidung zwischen Batch und Realtime ist deshalb keine technische Randnotiz, sondern eine Architekturfrage mit direkter Wirkung auf Kosten, Stabilität und Betriebsaufwand.

Typische Batch-Kandidaten

Die Faustregel ist einfach: Batch eignet sich überall dort, wo das Ergebnis erst zu einem späteren Zeitpunkt gebraucht wird und niemand synchron wartet. In der Praxis sind das erstaunlich viele Aufgaben:

• Klassifikation und Tagging: Support-Tickets kategorisieren, Dokumente verschlagworten, Inhalte moderieren.
• Extraktion: strukturierte Daten aus Rechnungen, Verträgen oder Formularen ziehen.
• Datenanreicherung: CRM-Einträge vervollständigen, Produktdaten normalisieren, Firmenbeschreibungen generieren.
• Zusammenfassungen auf Vorrat: neue Dokumente beim Eingang zusammenfassen, damit die Ansicht später sofort da ist.
• Eval-Läufe: Qualitätsprüfungen über den Prüffall-Katalog, die ohnehin über Nacht laufen können.

Der Realtime-Pfad bleibt reserviert für alles, was direkt in einer Nutzerinteraktion steckt: Chat, Assistenzfunktionen, interaktive Analysen.

Was Batch-Verarbeitung günstiger macht

Batch-APIs funktionieren nach einem einfachen Vertrag: Man reicht eine große Menge von Anfragen als Auftrag ein und bekommt die Ergebnisse innerhalb eines Zeitfensters zurück, typischerweise im Bereich von Stunden. Im Gegenzug liegt der Tokenpreis spürbar unter dem des synchronen Endpunkts. Der Anbieter kann diese Aufträge auf freie Kapazität legen, und diesen Spielraum gibt er über den Preis weiter.

Der Preisvorteil ist aber nur die halbe Rechnung. Dazu kommen Betriebsvorteile: Batch-Aufträge kollidieren nicht mit den Rate Limits des interaktiven Verkehrs, Fehler einzelner Positionen werden pro Position gemeldet statt den ganzen Lauf zu reißen, und die eigene Anwendung muss keine langlaufende Schleife mit Backoff-Logik babysitten. Für regelmäßige Massenverarbeitung ist das oft der größere Gewinn als der Rabatt selbst.

Die Queue-Architektur dahinter

Batch-Verarbeitung braucht auf der eigenen Seite eine kleine, aber solide Infrastruktur. Kern ist eine Job-Verwaltung, meist eine Tabelle in der bestehenden Datenbank, die pro Auftrag und pro Einzelposition den Status führt: eingereicht, in Verarbeitung, erledigt, fehlgeschlagen. Daraus ergeben sich die Anforderungen fast von selbst:

• Idempotenz: Jede Position hat einen stabilen Schlüssel, damit ein wiederholter Lauf keine Duplikate erzeugt.
• Wiederaufnahme: Bricht ein Lauf ab, wird nur der offene Rest neu eingereicht, nicht alles.
• Fehlerpfad: Positionen, die mehrfach scheitern, landen in einer separaten Liste zur manuellen Sichtung statt in einer Endlosschleife.
• Validierung vor Übernahme: Ergebnisse werden geprüft, etwa auf Format und Pflichtfelder, bevor sie in Produktivdaten geschrieben werden.

Wer diese vier Punkte abdeckt, hat den Großteil der Betriebsprobleme vorweggenommen. Alles Weitere, etwa Priorisierung oder parallele Aufträge, lässt sich später ergänzen.

Nutzererwartungen und SLAs

Die größte Hürde für Batch ist selten technisch, sondern kommunikativ. Nutzer und Fachabteilungen haben durch Chat-Oberflächen gelernt, dass KI sofort antwortet, und übertragen diese Erwartung auf jede Aufgabe. Dabei ist die ehrliche Frage fast immer: Wann wird das Ergebnis wirklich gebraucht? Ein Import, der über Nacht läuft und morgens verlässlich fertig ist, ist für die meisten Abläufe besser als einer, der sofort startet und gelegentlich hängen bleibt.

Das SLA für Batch-Verarbeitung formuliert man deshalb als Termin, nicht als Latenz: Ergebnisse liegen bis zu einem definierten Zeitpunkt vor, mit einer bekannten Quote erfolgreich verarbeiteter Positionen. Die Oberfläche zeigt dazu einen Status mit Fortschritt und benachrichtigt bei Fertigstellung. Verlässlichkeit schlägt Geschwindigkeit, sobald niemand aktiv wartet.

Hybride Muster

In reifen Systemen stehen Batch und Realtime nicht gegeneinander, sondern kombiniert. Drei Muster tauchen immer wieder auf. Erstens die Rückfüllung: Neue oder gerade angezeigte Objekte werden in Realtime verarbeitet, der historische Bestand läuft parallel als Batch hinterher. Zweitens der Eilweg: Die Standardverarbeitung läuft als Batch, aber einzelne Positionen lassen sich auf Anforderung sofort über den synchronen Pfad ziehen, etwa wenn ein Sachbearbeiter genau dieses eine Dokument jetzt braucht. Drittens die Vorberechnung: Nachts rechnet ein Batch alles Absehbare vor, tagsüber behandelt der Realtime-Pfad nur noch die Abweichungen.

Gemeinsam ist allen Mustern, dass beide Pfade dieselben Prompts, dieselbe Validierung und dieselbe Ergebnisstruktur nutzen. Nur dann bleibt das Verhalten konsistent, egal über welchen Weg eine Position verarbeitet wurde.

Fazit

Die Frage ist nicht, ob Batch oder Realtime besser ist, sondern welcher Anteil der eigenen Workloads wirklich eine sofortige Antwort braucht. Ehrlich betrachtet ist es oft der kleinere Teil. Alles andere gehört auf einen Batch-Pfad: günstiger pro Token, robuster gegen Rate Limits und Teilausfälle, planbarer im Betrieb. Die Investition dafür ist überschaubar, eine Job-Verwaltung mit Idempotenz, Wiederaufnahme und Fehlerliste, dazu klar kommunizierte Termine statt Sofort-Versprechen. Wer beide Pfade sauber trennt und über hybride Muster verbindet, bekommt niedrigere Kosten und eine stabilere Anwendung zugleich.