Amazon Bedrock führt Batch Inference zu 50 Prozent des On-Demand-Token-Preises aus, und das Einzige, worauf man verzichtet, ist Unmittelbarkeit. Man reicht eine Datei mit Anfragen ein, der Job läuft asynchron, wenn Kapazität verfügbar ist, und man holt die Ergebnisse später ab. Für jeden Workload, bei dem kein Mensch dasitzt und auf die Antwort wartet, den vollen Preis für Echtzeit-Inferenz zu zahlen, lässt die Hälfte des Geldes für eine Geschwindigkeit liegen, die niemand gebraucht hat.

Der Fehler ist, jeden Modellaufruf standardmäßig über den synchronen Echtzeitpfad laufen zu lassen, nur weil der erste Prototyp so geschrieben wurde. Interaktiver Chat muss in Echtzeit sein. Ein nächtlicher Job, der die Support-Tickets von gestern klassifiziert, muss das nicht. Das sind unterschiedliche Latenzanforderungen, und Bedrock bepreist sie unterschiedlich. Die technische Frage ist schlicht, welche der eigenen Workloads wirklich jetzt eine Antwort brauchen und welche irgendwann.

Wie Batch auf Bedrock funktioniert

Batch Inference ist ein Job, kein Aufruf. Der Ablauf ist bewusst unspektakulär:

1. write requests as JSONL to S3   (one record per line)
2. create a batch inference job     (input S3 -> output S3)
3. job runs asynchronously          (minutes to hours)
4. read results from the output S3 prefix

Jeder Input-Record trägt eine Record-ID und denselben Modell-Input, den man in Echtzeit senden würde. Der Output wird zurück nach S3 geschrieben, ein Ergebnis pro Input, verschlüsselt über diese Record-ID, sodass man Ergebnisse mit Inputs verknüpfen kann. Es gibt keinen Endpoint, der warmgehalten werden muss, keine Concurrency, die abgestimmt werden muss, kein Throttling, das man auffangen müsste. Man tauscht die Request-Response-Schleife gegen eine Submit-and-Collect-Schleife und bekommt den vergünstigten Satz dafür, dass man akzeptiert, dass der Job nach dem Zeitplan des Services fertig wird, nicht nach dem eigenen.

Wo Latenz wirklich egal ist

Die passenden Workloads sind die, bei denen das Ergebnis einen Prozess speist, nicht einen Menschen, der vor dem Bildschirm wartet:

  • Klassifikation und Tagging in großem Umfang. Ein Rückstand an Dokumenten, Tickets oder Produkten kategorisieren. Die Antwort landet in einer Datenbank, nicht vor einem Nutzer.
  • Enrichment-Pipelines. Zusammenfassungen, Extraktionen oder Embeddings, die im Voraus erzeugt und gespeichert werden, sodass der Echtzeitpfad nur einen vorberechneten Wert liest.
  • Offline-Evaluation. Ein Modell oder eine Prompt-Änderung über Tausende Testfälle hinweg bewerten. Das ist ein Report, und Reports können eine Stunde warten.
  • Periodisches Reporting. Alles, was nach Zeitplan läuft und Output erzeugt, den ein Mensch später liest, nicht sofort.

Der gemeinsame Nenner: Die Deadline wird in Stunden gemessen, und das Volumen ist groß genug, dass die Halbierung des Token-Preises echtes Geld ist statt Rundungsfehler.

Die Kostenrechnung

Der Tausch ist eindeutig, wenn man ihn zu Papier bringt. Man nehme einen Job mit einer Million Records, jeder mit durchschnittlich fixen Token-Kosten:

Real-time path:
  1,000,000 requests x on-demand token price
  + endpoint kept responsive
  + throttling handling under load

Batch path:
  1,000,000 records x (0.5 x on-demand token price)
  + S3 storage (negligible)
  + the willingness to wait

Die Batch-Spalte ist die halbe Token-Rechnung und weniger operative Fläche, weil es keinen Live-Endpoint gibt, den man vor einem Burst schützen muss. Der Break-even hängt nicht am Volumen, sondern an der Deadline. Kann die Antwort warten, gewinnt Batch sowohl bei Kosten als auch bei Einfachheit. Kann sie das nicht, macht kein Rabatt einen asynchronen Job akzeptabel.

Wann Batch das falsche Werkzeug ist

Man sollte es nicht dort erzwingen, wo die Form nicht passt. Batch ist falsch, wenn ein Nutzer auf den Output wartet, wenn eine Anfrage vom Ergebnis der vorherigen abhängt, oder wenn der Job klein genug ist, dass der Rabatt trivial ist und die asynchrone Verkabelung sich nicht lohnt. Es ist auch falsch als Umgehung von Throttling: Wenn der eigene Echtzeit-Traffic gedrosselt wird, liegt die Lösung in Kapazitätsplanung und Prompt Caching, nicht darin, interaktive Anfragen durch einen Job zu schieben, der Stunden später antwortet. Batch ist für Arbeit, die ohnehin verschoben werden sollte, nicht dafür, ein Latenzproblem zu verstecken.

Das Fazit

Die Hälfte einer großen Token-Rechnung ist eine Architektur wert, die die meisten Teams ohnehin schon herumliegen haben: nach S3 schreiben, einen Job einreichen, die Ergebnisse später lesen. Der Rabatt ist nicht clever, er ist einfach das Bezahlen für verzögerte Kapazität statt On-Demand-Kapazität. Man prüft die eigenen Modellaufrufe und sortiert sie danach, wer wartet. Alles mit einem Menschen am anderen Ende bleibt Echtzeit. Alles andere, die Klassifikation, das Enrichment, die Evaluation und das Reporting, das eine Pipeline statt einen Menschen speist, gehört in einen Batch-Job zu 50 Prozent Rabatt. Die Ersparnis steckt in den Workloads, die man nie hinterfragt hat.

Weiterlesen

Für das breitere Kostenoptimierungs- und Pipeline-Playbook über AWS hinweg gibt es die Cloud-Notizen auf ercan.cloud, und der Hub ist unter ercanermis.com.