Batch-Inferenz

Batch-Inferenz bezeichnet die gebündelte Anwendung eines fertig trainierten KI-Modells auf eine große, abgeschlossene Menge an Daten (zum Beispiel alle Kundendatensätze einer Nacht) in einem geplanten Lauf. Die Ergebnisse werden gesammelt in ein Zielsystem geschrieben, statt einzeln an einen wartenden Nutzer zurückgegeben. Sie ist damit das Gegenstück zur Real-Time-Inferenz (Echtzeit-Vorhersage pro einzelner Anfrage) und steht für den planmäßigen, kostenoptimierten Massenlauf.

Was ist Batch-Inferenz?

Bei der Batch-Inferenz wendet ein bereits trainiertes Modell seine Vorhersage auf eine feste Menge an Eingaben an. Als Modell kommen ein klassisches Machine-Learning-Modell (ML), ein Deep-Learning-Modell oder ein Large Language Model (LLM, also ein großes Sprachmodell wie ChatGPT) in Frage. Typische Eingaben sind Tabellenzeilen, Dokumente, Bilder oder Nachrichten. Die Vorhersagen werden gesammelt in eine Zieltabelle, einen Objektspeicher (also einen Datei-Ablageort in der Cloud) oder ein nachgelagertes System geschrieben. Ausgeführt wird der Lauf als planmäßiger Job (nächtlich, stündlich oder bei Bedarf), nicht als Reaktion auf eine einzelne Anfrage.

Der Begriff existiert, weil viele produktive Anwendungsfälle keine Latenz im Sekundenbereich brauchen: Kundensegmentierung, Score-Aktualisierung, Kategorisierung von Dokumenten oder Vorbefüllung eines Feature-Stores. Wo die Vorhersagen nicht sofort benötigt werden, reduziert die Batch-Inferenz die Kosten pro Vorhersage deutlich. Die Hardware wird gleichmäßig ausgelastet, der Modell-Cold-Start amortisiert sich über viele Datensätze, und die Endpoint-Infrastruktur mit Autoscaling, Load Balancer und Hochverfügbarkeit entfällt. Cloud-Anbieter und Foundation-Model-APIs bieten Batch-Aufträge in der Regel zu reduzierten Preisen an; bei LLM-Batch-APIs (OpenAI Batch, Anthropic Message Batches, Together AI, Amazon Bedrock Batch) liegt der Rabatt gegenüber synchronen Aufrufen häufig in der Größenordnung von rund 50 %, anbieterspezifisch und an ein SLA von in der Regel bis zu 24 Stunden gekoppelt.

Ein Batch-Inferenz-Job stützt sich technisch auf vier Bausteine: eine Datenquelle als abgeschlossene Menge (Tabelle, Partition, Zeitraum); eine Ausführungs-Engine, die das Modell parallel über die Daten anwendet (etwa [Apache Spark](https://spark.apache.org/) mit UDFs, spezialisierte Batch-Jobs oder LLM-Batch-APIs); ein Zielsystem, in dem die Vorhersagen persistent landen (Delta-Tabelle, Feature-Store, Datenprodukt); und eine Orchestrierung, die den Lauf planmäßig auslöst und dessen Erfolg überwacht. Im LLM-Umfeld wird Batch-Inferenz als asynchrone API angeboten: Aufträge werden als .jsonl-Datei eingereicht, in einer Warteschlange des Anbieters mit anderer Priorität verarbeitet und die Ergebnisse binnen Stunden statt Millisekunden zurückgegeben. Der Preisvorteil gegenüber synchronen Aufrufen ist der Hauptantrieb für diesen Modus.

Abgrenzung: Real-Time-Inferenz, Streaming und Training

Batch-Inferenz wird häufig mit benachbarten Begriffen verwechselt. Die Abgrenzung zur Real-Time-Inferenz (auch: Online-Inferenz, Single Inference) ist die wichtigste: dort läuft ein Modell synchron hinter einem Endpoint, jede eingehende Anfrage bekommt eine einzelne Antwort mit Latenzanforderung im Millisekunden- bis Sekundenbereich. Batch-Inferenz kennt keinen wartenden Nutzer; die relevanten Metriken sind Durchsatz und Kosten pro Vorhersage, nicht Latenz pro Anfrage.

Beispiel: Nächtlicher Scoring-Lauf und LLM-Batch-Auftrag

Ein typischer klassischer Einsatz ist ein nächtlicher Job, der Kundendatensätze aus einer Delta-Tabelle liest, ein Klassifikationsmodell zur Ermittlung eines Abwanderungs-Scores anwendet und die Ergebnisse in eine Score-Tabelle schreibt, die morgens im CRM sichtbar wird. Der Lauf greift auf einen partitionierten Ausschnitt (etwa die vergangenen 24 Stunden), verteilt die Vorhersagen über mehrere Executor-Prozesse und persistiert die Ausgabe versioniert.

Im LLM-Umfeld verläuft ein vergleichbarer Ablauf über eine Batch-API: Zehntausende gescannte Dokumente werden als .jsonl-Auftrag hochgeladen, vom Anbieter asynchron zusammengefasst oder kategorisiert und das Ergebnis in einer Analyse-Tabelle abgelegt. Weitere verbreitete Einsatzfelder sind die Vorbefüllung von Feature-Stores mit Modellausgaben, Massen-Übersetzung und die Berechnung von Embeddings für Retrieval-Augmented-Generation-Indizes.