Batch-Inferenz mit LLMs on-premise: Dokumentenarchive über Nacht mit vLLM verarbeiten

Batch-Inferenz mit LLMs: Durchsatz statt Latenz

Batch-Inferenz mit einem LLM, also LLM-Stapelverarbeitung, wendet ein Modell auf eine feste Menge von Eingaben an, etwa ein Dokumentenarchiv, ohne dass ein Nutzer auf jede Antwort wartet. Sie wird nach Durchsatz ausgelegt, also nach den Token oder Dokumenten, die pro Stunde verarbeitet werden, und nach der Uhrzeit, zu der der Job fertig sein muss, nicht nach der Zeit bis zum ersten Token. Die Engine erhält deshalb alle Anfragen auf einmal, fährt die größten Batches, die der GPU-Speicher zulässt, und hält die Karten ausgelastet, bis die Warteschlange leer ist. On-premise passen solche Jobs in die Nachtstunden von GPUs, die tagsüber einen Assistenten bedienen.

Veröffentlichte Ergebnisse zeigen, was Latenzgrenzen an Durchsatz kosten. In MLPerf® Inference v6.0, Eintrag 6.0-0005, erzeugte ein Server mit acht RTX PRO 6000 Server Edition mit Llama 2 70B im Offline-Szenario, in dem alle Anfragen auf einmal gesendet werden, 27.730,1 Token pro Sekunde. Unter den Latenzgrenzen des interaktiven Szenarios erzeugte derselbe Server 6.262,6, weniger als ein Viertel. Unser Leitfaden zu Latenzzielen für LLMs setzt Ziele für Chat, RAG und Agenten; das Ziel eines Batch-Jobs ist die Zahl der Dokumente, die am Morgen fertig sind.

Batch- und interaktive Einstellungen in vLLM

vLLM-Dokumentation (latest): Quickstart und Beispiel zu run-batch, beide vom 10. Oktober 2026; Optimierungsleitfaden, 20. August 2026; Engine-Argumente; Structured Outputs, 19. Mai 2026. NVIDIA NIM for LLMs 1.14.0, Modellprofile, aktualisiert am 23. Juli 2026. Die interaktiven Ziele sind die Beispiele aus unserem Latenzleitfaden.

Der Optimierungsleitfaden von vLLM hält fest, dass kleinere Werte von max_num_batched_tokens „eine bessere ITL erreichen, weil weniger Prefills die Decodes verlangsamen“, und empfiehlt Werte über 8.192 „für optimalen Durchsatz … insbesondere bei kleineren Modellen auf großen GPUs“. Der Leitfaden erklärt außerdem, dass vLLM Anfragen verdrängt, wenn der Platz für den KV-Cache knapp wird, und dass vLLM V1 sie standardmäßig neu berechnet. Die Neuberechnung kostet Durchsatz, und als Abhilfe nennt der Leitfaden einen höheren Wert für gpu_memory_utilization oder einen niedrigeren für max_num_seqs.

Setzen Sie --max-model-len auf das längste Dokument plus die Antwort. Ist der Wert nicht gesetzt, leitet vLLM ihn „aus der Modellkonfiguration“ ab, und das kann weit mehr sein, als ein Dokument braucht. Bleibt --kv-cache-dtype auf „auto“, nutzt der Cache den Datentyp des Modells; ein FP8-Cache belegt halb so viele Byte wie ein 16-Bit-Cache und hält etwa doppelt so viele Dokumente gleichzeitig in Bearbeitung.

Stellen Sie die Anweisungen, die alle Anfragen gemeinsam haben, an den Anfang des Prompts und das Dokument ans Ende. Das automatische Prefix-Caching von vLLM „speichert den KV-Cache vorhandener Anfragen zwischen“, sodass eine neue Anfrage mit demselben Präfix „die Berechnung des gemeinsamen Teils überspringen“ kann. Die Dokumentation ergänzt, dass es nur das Prefill verkürzt und „die Zeit für die Erzeugung neuer Token nicht verringert“; es hilft also bei langen gemeinsamen Anweisungen, nicht bei langen Antworten. Einige vLLM-Rezepte schalten es für Benchmarks mit no-enable-prefix-caching ab; prüfen Sie daher, ob eine aus einem Rezept kopierte Konfiguration es eingeschaltet lässt.

vLLM-Offline-Inferenz, der Batch-Runner und NIM

vLLM bietet zwei Wege, einen Batch ohne Client auszuführen. Für seine Python-Klasse LLM beschreibt der Quickstart „Offline-Batch-Inferenz“ über eine Liste von Prompts, bei der llm.generate „die Eingabe-Prompts der Warteschlange der vLLM-Engine hinzufügt“ und die Ausgaben „mit hohem Durchsatz“ erzeugt. Für einen Ray-Cluster aus mehreren Servern verweist die vLLM-Seite zur Offline-Inferenz auf Ray Data LLM, das festhält: „Continuous Batching hält die vLLM-Replikate ausgelastet und maximiert die GPU-Auslastung.“

Der zweite Weg kommt ohne Code aus. vllm run-batch liest eine JSONL-Datei im Batch-Format von OpenAI, und das vLLM-Beispiel nennt das „Batch-Inferenz mit dem Batch-Dateiformat von OpenAI, nicht die vollständige Batch-(REST-)API“. „Jede Zeile stellt eine eigene Anfrage dar“, mit einer custom_id, der Methode, dem Endpunkt als url und dem body der Anfrage. Unterstützt werden die Endpunkte /v1/chat/completions, /v1/embeddings und /v1/score. Ein- und Ausgabe können lokale Dateien oder HTTP(S)-URLs sein, wobei die Ausgabe per HTTP PUT geschrieben wird. Ein Lauf lautet vllm run-batch -i in.jsonl -o out.jsonl, ergänzt um --model und die Engine-Einstellungen von oben.

NVIDIA NIM for LLMs wählt eine Engine-Konfiguration über ein Profil. Die Profilseite zu Release 1.14.0 sagt, dass Durchsatzprofile darauf ausgelegt sind, den Gesamtdurchsatz pro GPU zu maximieren, und dass „Latenzvarianten zusätzliche GPUs verwenden, um die Anfragelatenz zu senken, auf Kosten eines geringeren Gesamtdurchsatzes pro GPU im Vergleich zur Durchsatzvariante“. Ein Profil wird mit NIM_MODEL_PROFILE gewählt. Batch-Dateien erwähnt die Seite nicht; ein Batch-Job schickt seine Anfragen daher von einem Client an die NIM-API, der eine feste Zahl von Anfragen gleichzeitig offen hält.

Klassifizierung, Extraktion, Zusammenfassungen und Metadaten für RAG

Die Aufgabe bestimmt, wie viele Token jedes Dokument erzeugt, und damit, wie lange der Job läuft. Die Structured Outputs von vLLM schränken die Antwort ein: Mit choice „ist die Ausgabe genau eine der Auswahlmöglichkeiten“, und ein JSON-Schema lässt sich über die API als response_format oder offline als StructuredOutputsParams übergeben. Eine Klassifizierung liefert dann ein Label aus wenigen Token, sodass die Kosten je Dokument vor allem im Lesen liegen. Eine Extraktion liefert ein JSON-Objekt mit Datumsangaben, Parteien, Beträgen oder Ticketfeldern, einige zehn bis einige hundert Token. Eine Zusammenfassung ist die längste Ausgabe, mehrere hundert Token je Dokument.

Die Anreicherung mit Metadaten für RAG kombiniert diese Aufgaben. Das Modell weist jedem Dokument oder Chunk einen Dokumenttyp, einen Titel, ein Datum und Schlagwörter zu, und der Retrieval-Index speichert sie als Filter. Wo die Anreicherung dem Text des Chunks einen Titel oder eine Zusammenfassung hinzufügt, werden die Chunks neu eingebettet; das deckt vllm run-batch über seinen Embeddings-Endpunkt ab, während die Auslegung des Embedding-Servers Thema unseres Leitfadens zu Embedding- und Reranker-Servern ist. Gescannte Seiten brauchen zuerst Text, und die GPU-Kosten für das Lesen von Seiten mit einem Vision-Language-Modell behandelt unser Artikel zu Dokumenten-KI mit Vision-Language-Modellen.

GPU-Stunden für ein Dokumentenarchiv: Methode und Beispiel

Die GPU-Stunden eines Batch-Jobs ergeben sich aus der Zahl der Dokumente, den Ausgabe-Token je Dokument und einem Durchsatzwert für Modell und Karten.

1. Zählen Sie die Dokumente und ziehen Sie eine Stichprobe von etwa tausend, die das Archiv repräsentiert.
2. Legen Sie Aufgabe und Ausgabelänge je Dokument mit max_tokens fest und, wo es passt, mit einem Schema.
3. Nehmen Sie einen veröffentlichten Durchsatz für ein vergleichbares Modell und einen vergleichbaren Server, oder messen Sie die Laufzeit der Stichprobe als Batch-Job; vllm bench throughput mit --input-len und --output-len auf den Mittelwerten der Stichprobe liefert eine erste Schätzung.
4. Teilen Sie Dokumente × Ausgabe-Token durch Token pro Sekunde, dann durch 3.600 für Stunden, und multiplizieren Sie mit der Zahl der Karten für GPU-Stunden.
5. Vergleichen Sie die Stunden mit dem Nachtfenster und planen Sie eine Reserve ein, bevor Sie über die Zahl der Server entscheiden.

MLPerf Inference v6.0 veröffentlicht Offline-Durchsatz für zwei Modelle, die zu dieser Methode passen. Der Benchmark mit Llama 3.1 8B fasst Nachrichtenartikel aus dem Datensatz CNN/DailyMail zusammen, 13.368 davon im Datacenter-Set, laut MLCommons im Mittel mit 778 Token Eingabe und 73 Token Ausgabe, und die Referenzimplementierung begrenzt jede Zusammenfassung auf 128 Token. Zusammenfassungen von Geschäftsdokumenten sind länger, daher nimmt das Beispiel unten 600 Ausgabe-Token je Zusammenfassung an. Der Benchmark mit Llama 2 70B beantwortet Fragen, im selben Eintrag mit etwa 274 Token je Antwort. Das Beispiel unten ist ein Archiv mit 2 Millionen Dokumenten.

MLPerf Inference v6.0, Datacenter-Suite, Closed Division, Kategorie Available, Offline-Szenario, Llama 3.1 8B und Llama 2 70B (Variante mit 99 Prozent Genauigkeit). Eintrag 6.0-0005, acht RTX PRO 6000 Server Edition, FP4-Gewichte, TensorRT 10.14, abgerufen aus dem v6.0-Ergebnis-Repository von MLCommons am 10. Oktober 2026; Eintrag 6.0-0021, Dell PowerEdge XE7740 mit acht H200 NVL, FP8-Gewichte, abgerufen von mlcommons.org am 24. September 2026 für unseren Benchmark-Review der H200 NVL; Ergebnisse von der MLCommons Association verifiziert. Die 274 Token je Antwort stammen aus Eintrag 6.0-0005 und sind auf beide Karten angewendet; die 600 Token je Zusammenfassung sind unsere Annahme. Stunden und GPU-Stunden sind unsere Rechnung, keine MLPerf-Metriken; die letzte Zeile nimmt an, dass die 70B-Rate auch für längere Antworten gilt, was der Benchmark nicht zeigt. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

Diese Raten stammen aus optimierten TensorRT-Läufen mit den eigenen Eingaben des Benchmarks. Ein Vertrag mit 30 Seiten ist um ein Vielfaches länger als ein Nachrichtenartikel, sodass das Prefill einen größeren Anteil der Zeit einnimmt, und vLLM mit Ihren Dokumenten ergibt einen anderen Wert. Dieses Beispiel plant mit der Hälfte der veröffentlichten Rate, bis ein Testlauf mit der Stichprobe einen gemessenen Wert liefert; das ist eine Planungsreserve, kein Herstellerwert. Mit dieser Reserve brauchen 2 Millionen Zusammenfassungen mit einem 8B-Modell etwa 14 Stunden auf einem Server mit acht RTX PRO 6000, also zwei Nächte oder eine Nacht auf zwei Servern. Die Werte der H200 NVL und das System dahinter stehen in unserem Benchmark-Review der H200 NVL.

Wir bauen GPU-Server auf Bestellung rund um den Workload und prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Schicken Sie uns Dokumentenzahl, Aufgabe und Nachtfenster über das Formular unten, und Sie erhalten innerhalb eines Werktages eine Konfiguration.

Nachtfenster auf den Chat-GPUs mit Kubernetes und Kueue

Kueue beschreibt sich selbst als „ein Kubernetes-natives System, das Quoten verwaltet und regelt, wie Jobs sie verbrauchen“, und entscheidet, wann ein Job wartet, wann er startet und wann er verdrängt wird. Zu seinen stabilen Integrationen gehören der Batch-Job und das Deployment, sodass der Chat-Dienst und der Nachtjob eine ClusterQueue teilen können, deren Quote die GPUs abdeckt. Ein CronJob startet den Batch-Job jeden Abend; die Kueue-Dokumentation verlangt das Label kueue.x-k8s.io/queue-name im Job-Template und sagt, dass Kueue „die Suspendierung des Jobs automatisch verwaltet“ und entscheidet, wann er startet. Dieselbe Seite weist darauf hin, dass concurrencyPolicy standardmäßig auf Allow steht und startingDeadlineSeconds standardmäßig keine Frist setzt; stellen Sie beide passend zum Fenster ein.

Prioritäten entscheiden, welcher der beiden nachgibt. Eine WorkloadPriorityClass, an einem Job mit dem Label kueue.x-k8s.io/priority-class gesetzt, ist „unabhängig von der Priorität des Pods“ und dient der Reihenfolge und der Entscheidung, ob ein Workload andere verdrängen darf. Geben Sie dem Chat-Dienst die höhere Klasse und dem Batch-Job die niedrigere, und setzen Sie withinClusterQueue in der ClusterQueue auf LowerPriority, denn der Standardwert Never verdrängt nichts. Wenn das Chat-Deployment am Morgen hochskaliert und seine GPUs zurückbraucht, wird der Batch-Workload mit dem Grund Preempted verdrängt. Kueue verdrängt den gesamten Workload, alle Pods des Jobs auf einmal.

Teilen Sie das Archiv in Shard-Dateien auf und halten Sie fest, welche Shards fertig sind, damit ein verdrängter oder fehlgeschlagener Job mit dem nächsten Shard neu startet und höchstens einen verliert. Mit der Annotation kueue.x-k8s.io/job-min-parallelism kann Kueue einen Job mit weniger parallelen Pods als angefordert zulassen, wenn GPUs knapp sind, ohne die Zahl der Completions zu ändern. Zum Beispiel betreiben zwei Server mit je acht RTX PRO 6000 tagsüber ein Assistenzmodell als mehrere Kopien auf je einer Karte; nachts lässt ein geplantes Herunterskalieren, das Kueue nicht selbst ausführt, eine Kopie je Server übrig, und der Batch-Job nimmt die anderen vierzehn Karten. Quoten je Abteilung und Showback von GPU-Stunden sind Thema unseres Leitfadens zu einer gemeinsamen GPU-Plattform für Abteilungen.

Unsere Inferenz-Server tragen 2 bis 8 GPUs pro Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Beschreiben Sie Ihre Chat-Last am Tag und den Batch-Job in der Nacht im Formular unten, und wir legen eine Plattform für beides aus.

Was wir liefern

Wir bauen KI-Server auf Bestellung für private LLMs und RAG in Produktion, mit 2 bis 8 GPUs pro Knoten, montiert und im Burn-in getestet, mit Herstellergarantie auf jede Komponente und Lieferung in die ganze EU, unter einem EU-Vertrag und auf einer Rechnung. Zu den Karten gehören die RTX PRO 6000 Server Edition, die H200 NVL mit NVLink-Brücken, die L40S und die L4, aufgeführt auf unserer Seite zu professionellen NVIDIA-GPUs, und Lizenzen für NVIDIA AI Enterprise und vGPU kommen auf dieselbe Rechnung. Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch. Die Batch-Pipeline, die Modelle und RAG darauf sind unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ