Ein privater KI-Pilot: was zu messen ist, wie man es misst und wie die Zahlen die Hardware für die Produktion dimensionieren

Zwei Aufgaben eines Piloten: Qualität und Daten zur Dimensionierung

Ein privater LLM-Pilot hat zwei Aufgaben: zu zeigen, ob das Modell echte Fragen gut genug beantwortet, und die Zahlen zu liefern, nach denen die Hardware für die Produktion dimensioniert wird. Für beides braucht es die Metriken und für jede eine Bestehensgrenze, schriftlich festgelegt, bevor sich der erste Nutzer anmeldet. In unserem Service Private AI/ML gehört diese Liste zum kostenpflichtigen technischen Assessment, zusammen mit der Lösungsarchitektur und der Auswahl von Modell und GPU. Schreiben Sie uns, welchen Prozess Sie in einem Pilotprojekt erproben wollen, und unser Team hilft Ihnen weiter.

Nicht jede Zahl lässt sich auf die Produktion übertragen. Übertragbar ist der Bedarf, also wie oft Anfragen eintreffen, wie lang Prompts und Antworten sind und wie viel Kontext sie brauchen, gezählt in den eigenen Token des Modells. Übertragbar ist auch die Qualität, sofern in der Produktion dasselbe Modell in derselben Präzision läuft. Latenz und Durchsatz sind es nicht, weil sie von der GPU, der Engine-Version und den Serving-Einstellungen abhängen, mit denen gemessen wurde.

Welche Zahlen im Piloten zu erfassen sind

Zählen Sie Anfragen statt Nutzer. Die Größe, nach der sich der Speicher bemisst, ist die Parallelität: Anfragen, die im selben Augenblick bearbeitet werden, jede mit ihrem eigenen KV-Cache auf der GPU. Erfassen Sie daneben die Ankunftsrate in der Spitzenstunde, die Prompt- und Antwortlänge jeder Anfrage als Verteilung (Median und 95. Perzentil, kein Mittelwert) und den Kontext, den jede Anfrage braucht, Prompt plus Antwort. RAG-Prompts enthalten gefundene Abschnitte, Chat-Prompts das bisherige Gespräch. vLLM veröffentlicht das Rohmaterial im Prometheus-Format unter /metrics auf seinem API-Port.

vLLM 0.30.0, veröffentlicht am 22. September 2026; Definitionen aus seinem Quellcode und seiner Design-Dokumentation zu den Metriken. In 0.31.0 vom 5. Oktober 2026 tragen die Metriken dieselben Namen; prüfen Sie /metrics nach einem Upgrade erneut (0.32.0 erschien am 18. Oktober 2026). Verwenden Sie 0.31.0 oder neuer, das den Sicherheitshinweis GHSA-h3rc-6mm3-gc2m behebt, besser das aktuelle Release, Stand November 2026 die Version 0.33.0 vom 2. November 2026, deren CUDA-13.0-Builds einen Treiber ab R580 brauchen. Zähler erscheinen mit dem Suffix _total; Histogramme ergänzen _bucket, _sum und _count.

Die Histogramme sind grob: Token-Zahlen landen in Buckets nach einer Reihe 1, 2, 5 (1.000, 2.000, 5.000 Token und so weiter) und die Inter-Token-Latenz in Buckets ab 10, 25, 50, 75 und 100 ms aufwärts, und Prometheus merkt an, dass der Fehler eines Perzentils „durch die Breite des Buckets begrenzt ist“; halten Sie exakte Zählungen je Anfrage im Gateway-Log fest. Gauges werden nur zum Zeitpunkt des jeweiligen Scrapes erfasst, kurze Spitzen entgehen ihnen also. Der Anstieg von vllm:e2e_request_latency_seconds_sum über die Spitzenstunde, geteilt durch 3.600, hat diese Lücke nicht: Nach unserer Rechnung ergibt er die mittlere Zahl der Anfragen in Bearbeitung in dieser Stunde, wartende eingeschlossen und abgebrochene nicht. Eine anhaltende Warteschlange oder jede Verdrängung bedeutet, dass der Pilot an die Grenze seiner Hardware gestoßen ist: Der Bedarf war höher, als die Karte bedienen konnte.

Latenzmetriken: TTFT, ITL, TPOT und Ende-zu-Ende-Latenz

Werkzeuge definieren Latenz unterschiedlich; notieren Sie zu jedem Wert die Definition.

Zeit bis zum ersten Token (TTFT) ist in NVIDIAs Benchmarking-Leitfaden für NIM die Zeit „von der Übermittlung der Anfrage bis zum ersten empfangenen Token“, einschließlich Wartezeit in der Warteschlange, Prefill-Phase und Netzwerklatenz; längere Prompts erhöhen sie. Das Histogramm von vLLM setzt später ein, wenn in seinem Frontend die Tokenisierung beginnt, und lässt deshalb das Netzwerk und jedes vorgeschaltete Gateway weg.

Inter-Token-Latenz (ITL) ist für NVIDIA die mittlere Zeit zwischen aufeinanderfolgenden Token, „auch bekannt als Zeit pro Ausgabe-Token (TPOT)“, und „Werkzeuge unterscheiden sich darin, ob TTFT in den Mittelwert einbezogen wird“. AIPerf schließt TTFT aus und rechnet Ende-zu-Ende-Latenz minus TTFT, geteilt durch die Ausgabe-Token minus eins. vllm bench serve meldet diesen Mittelwert je Anfrage als TPOT und jeden Abstand zwischen Ausgaben als ITL, so wie es auch das Server-Histogramm von vLLM tut; die einzelnen Abstände zeigen Stockungen, die der Mittelwert verdeckt. Die Geschwindigkeit je Nutzer nähert sich bei langen Antworten 1 ÷ ITL, und AIPerf meldet sie so: 50 ms sind 20 Token pro Sekunde.

Ende-zu-Ende-Latenz reicht von der Übermittlung bis zum letzten Token. Fehler brauchen eine eigene Zählung: Fehlschläge, Timeouts und Abbrüche am Gateway sowie das Label finished_reason am Anfragezähler von vLLM, bei dem length eine Antwort markiert, die an ihrer Token- oder Kontextgrenze abgeschnitten wurde. Eine Anfrage, die der Client abbricht, erreicht diesen Zähler in vLLM 0.30.0 nicht.

Die Zielwerte ergeben sich aus dem Anwendungsfall: Schreiben Sie sie in den Pilotplan, und beide Lasttest-Werkzeuge weiter unten melden Goodput, also die Anfragen pro Sekunde, die jedes Ziel einhalten. Zum Vergleich: MLPerf® Inference v6.1 setzt Llama 2 70B im Szenario Server Grenzen von 2 s bis zum ersten Token und 200 ms pro Ausgabe-Token und im Szenario Interactive von 450 ms und 40 ms, jeweils beim 99. Perzentil. Beispielziele für Chat, RAG und Agenten nennt unser Artikel zu Latenzzielen für LLMs, Dashboards für diese Metriken unser Artikel zum LLM-Monitoring mit vLLM-Metriken.

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.

Die Qualität entscheidet über Modell und Präzision

Gemessen wird die Qualität mit einem Evaluationssatz: echte Fragen der künftigen Nutzer, jede mit einer akzeptierten Antwort und bei RAG mit dem Abschnitt, aus dem sie stammen soll; unser RAG-Leitfaden empfiehlt fünfzig bis hundert. Bewerten Sie die Trefferquote der Suche, also wie oft der richtige Abschnitt unter den gefundenen ist, getrennt von den Antworten: Eine niedrige Trefferquote ist ein Suchproblem, das sich mit mehr GPU-Kapazität nicht beheben lässt. Zählen Sie auch die Antworten, die mit length endeten, denn abgeschnittene Antworten wirken wie falsche.

Derselbe Evaluationssatz entscheidet über die Präzision, die sich am stärksten auf die Hardware auswirkt. NVIDIAs NVFP4-Checkpoint von Llama 3.3 70B belegt 39,8 GiB gegenüber 67,7 GiB in FP8, und seine Model Card nennt für MMLU 81,1 gegenüber 83,3 bei BF16; ob das ins Gewicht fällt, zeigt nur der Evaluationssatz, ausgeführt in der Präzision, mit der Gewichte und KV-Cache in der Produktion laufen. Seit vLLM 0.32.0 lässt sich der KV-Cache auf Karten der RTX PRO 6000 auch in NVFP4 ablegen, mit etwa 4,5 Bit je Wert statt 8 bei FP8, und diese Präzision braucht denselben Test. Führen Sie ihn auf dem Produktions-Stack erneut aus: Die Dokumentation von vLLM warnt, dass es standardmäßig Reproduzierbarkeit gegen Leistung eintauscht und dass sich Ergebnisse selbst mit den richtigen Einstellungen nur auf derselben Hardware und mit derselben vLLM-Version reproduzieren lassen.

Lasttests: vllm bench serve und AIPerf

Metriken zeigen, was die Nutzer getan haben; ein Lasttest zeigt, was eine bestimmte GPU bei einer gewählten Last leistet.

vllm bench serve gehört zu vLLM. Sein Standard-Datensatz besteht aus zufälligen Prompts mit 1.024 Token Eingabe und 128 Token Ausgabe; --dataset-name custom spielt Ihre eigenen Prompts ab, eine JSON-Zeile je Anfrage mit einem Feld prompt, und --custom-output-len setzt das Token-Limit jeder Antwort, standardmäßig 256; --ignore-eos lässt jede Antwort bis zu diesem Limit laufen. --max-concurrency begrenzt die Anfragen in Bearbeitung; ohne diese Option schickt die voreingestellte Anfragerate inf alles auf einmal. Der Bericht nennt TTFT, TPOT und ITL (Mittelwert, Median, 99. Perzentil), den Durchsatz und die Spitzenparallelität, gezählt je Sekunde; --goodput zählt die Anfragen, die Zielwerte in Millisekunden für TTFT, TPOT oder Ende-zu-Ende-Latenz eingehalten haben.

AIPerf ist NVIDIAs aktuelles Werkzeug: GenAI-Perf wird laut seiner eigenen Dokumentation „schrittweise eingestellt“, und die Dokumentation rät: „Für neuen Bedarf an Performance-Benchmarks verwenden Sie bitte stattdessen AIPerf“. AIPerf wird mit pip install aiperf installiert (Release 0.13.0, Stand Oktober 2026) und läuft als aiperf profile gegen OpenAI-kompatible Endpunkte, mit --streaming für TTFT und ITL. --concurrency hält eine feste Zahl von Anfragen in Bearbeitung. --custom-dataset-type single_turn mit --input-file spielt JSONL-Zeilen mit text und einem optionalen output_length ab, dem Token-Limit dieser Anfrage, sodass jeder Prompt des Piloten auf seine gemessene Antwortlänge begrenzt wird. --goodput nimmt Zielwerte etwa für TTFT und ITL entgegen.

NVIDIAs Benchmarking-Leitfaden zieht „für die meisten Benchmarks“ die Parallelität der Anfragerate vor, weil bei einer Rate „ausstehende Anfragen unbegrenzt anwachsen können“, sobald die Ankünfte dem System davonlaufen. Fahren Sie die Last von einer Anfrage bis zur gemessenen Spitze und darüber hinaus durch, und notieren Sie zu jedem Ergebnis die Engine-Version und die Einstellungen: In vLLM ergibt ein kleineres max_num_batched_tokens eine bessere ITL, ein größeres eine bessere TTFT.

Welche Hardware für den Piloten

Unser Vergleich für ein erstes KI-Projekt behandelt die Wahl der GPU. Für die Messung folgt aus der Hardware eine Regel: Die Erzeugung von Token ist bei kleiner Batchgröße durch die Speicherbandbreite begrenzt und die Verarbeitung von Prompts durch die Rechenleistung; Latenz, die auf einem GPU-Typ gemessen wurde, lässt sich also nicht auf einen anderen übertragen.

Ein DGX Spark mit 128 GB eignet sich für Funktions- und Qualitätspiloten: Sein Unified Memory fasst Llama 3.3 70B in FP8 mit Platz für den Cache. Bei 273 GB/s liegt seine Decode-Obergrenze für dieses Modell jedoch bei 3,9 Token pro Sekunde, gegenüber 22,6 auf einer RTX PRO 6000 Server Edition und 68,0 auf einer H200 NVL (Bandbreite geteilt durch die 70,6 GB, die je Token gelesen werden, nach unserer Rechnung). Eine RTX PRO 6000 hat die GB202-GPU eines Produktionsknotens mit RTX PRO 6000, aber die Workstation- und die Max-Q-Edition laufen mit 1.792 GB/s und die Server Edition mit 1.597 GB/s; ein Pilot auf einer Workstation überschätzt die Decode-Geschwindigkeit eines Rack-Knotens also um etwa 12 Prozent. Nehmen Sie für den Piloten die H200 NVL, wenn die Produktion auf H200 NVL laufen wird: Sie rechnet in FP8, hat aber keine FP4-Arithmetik, und NVIDIA führt seinen NVFP4-Checkpoint von Llama 3.3 70B für Blackwell.

Im Mittel entspricht die Zahl der Anfragen in Bearbeitung der Ankunftsrate mal der Zeit, die jede Anfrage dauert; ein langsamerer Pilot zeigt bei gleichem Verkehr also mehr davon. Übertragen Sie die Ankunftsrate und die Token-Längen, nicht die Parallelität, und führen Sie den Lasttest auf dem GPU-Typ der Produktion aus, bevor Sie skalieren.

Wir liefern alle drei hier besprochenen GPU-Typen, sodass Pilot und Produktion auf demselben Typ laufen können. Nennen Sie uns die Ankunftsrate und die Token-Längen, die Ihr Pilot gemessen hat, und wir legen die Hardware für die Produktion danach aus.

Von den Zahlen des Piloten zur Hardware für die Produktion

Nehmen Sie unser 70B-Rechenbeispiel als Ergebnis des Piloten: Llama 3.3 70B in FP8 mit FP8-KV-Cache (--kv-cache-dtype fp8) und einen Bedarf, der, auf die Nutzerzahl der Produktion hochgerechnet, in der Spitze 30 Anfragen in Bearbeitung erreicht, jede innerhalb von 8.192 Token (Beispielwerte). Die Gewichte sind NVIDIAs Checkpoints, 67,7 GiB in FP8 und 39,8 GiB in NVFP4; der Cache beträgt 2 × 80 Schichten × 8 Key-Value-Köpfe × 128 Werte × 1 Byte, 160 KiB je Token oder 1,25 GiB je Sitzung, 2,5 GiB mit einem 16-Bit-Cache. Wir planen wie in unserem Leitfaden zu Nutzern pro RTX PRO 6000: 90 Prozent dessen, was der Treiber meldet (95,6 GiB auf einer 96-GB-Karte und 140,4 GiB auf einer H200 NVL), abzüglich etwa 3 GiB Overhead je Karte, abzüglich der Gewichte; die Voreinstellung von vLLM liegt seit Release 0.20.0 bei 0,92, CUDA-Graphen eingerechnet.

Unsere Rechnung auf der obigen Grundlage, aus NVIDIAs Bandbreitenangaben, den Größen der Checkpoints und der Konfiguration des Modells: RTX PRO 6000 Server Edition mit 1.597 GB/s, Zeilen mit zwei und vier Karten in FP8, Sitzungen mit vollen 8.192 Token und FP8-KV-Cache. Decode-Obergrenze für einen einzelnen Stream: Bandbreite ÷ 70,6 GB, gelesen je Token in FP8, 40,6 GB in NVFP4; ein aufgeteiltes Modell erreicht als Pipeline-Stufen 22,6, mit Tensor-Parallelismus bis zu 45,2, bevor der Verkehr zwischen den Karten eingerechnet ist. Die RTX PRO 6000 hat kein NVLink, eine aufgeteilte Kopie tauscht ihre Daten also über PCIe aus, und vLLM schaltet seinen Custom All-Reduce bei mehr als zwei GPUs ohne NVLink ab, was zwei Paare gegenüber einer Kopie auf vier Karten begünstigt.

Gemessen an 30 Sitzungen reicht eine Karte in FP8 mit 12 nicht aus, bei einem 16-Bit-Cache mit 6; zwei Kopien auf zwei Karten fassen 24, weil jede die Gewichte noch einmal speichert, während eine auf beide aufgeteilte Kopie 78 fasst. Eine Karte in NVFP4 fasst 34, sofern der Evaluationssatz in NVFP4 bestanden wurde, und die H200 NVL fasst 44. Reale Sitzungen füllen selten 8.192 Token, und die 3 GiB Overhead sind unsere Schätzung; vLLM gibt beim Start die genaue Größe des KV-Cache und die maximale Parallelität aus, wie dieser Leitfaden zeigt.

Ein Ziel von 40 ms pro Token, die Grenze von MLPerf® Inference im Szenario Interactive, entspricht 25 Token pro Sekunde. Das liegt über der Obergrenze von 22,6 einer Karte der Server Edition, die für jedes Token alle FP8-Gewichte liest; eine Karte, zwei Kopien und eine Aufteilung als Pipeline verfehlen das Ziel also alle schon, bevor überhaupt Last anliegt. Spekulatives Dekodieren, das vLLM anbietet, um die Inter-Token-Latenz bei speichergebundenen Arbeitslasten unter niedriger bis mittlerer Last zu senken, kann daran etwas ändern. Solche Obergrenzen erreicht kein System, deshalb ist der letzte Schritt der Lasttest: die Prompts des Piloten mit 30 gleichzeitigen Anfragen auf dem Kandidaten, mit den Zielwerten als Goodput.

Was wir liefern

Wir liefern die DGX Spark Founders Edition (128 GB), die RTX PRO 6000 Blackwell in allen drei Editionen und die H200 NVL EU-weit mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Es gibt sie separat oder in individuellen, auf Bestellung gebauten KI-Servern; dort sind die Starterkonfiguration mit zwei Karten der RTX PRO 6000 Server Edition für Piloten und RAG-Assistenten und der Inferenzknoten mit vier dieser Karten für die produktive Inferenz mehrerer Teams aufgeführt. Wenn Sie den Piloten für sich planen und durchführen lassen wollen, ist das unser Service Private AI/ML, erbracht von unserem Engineering-Partner Vixen.UNO im Rahmen eines Vertrags mit Eurokommerz: Das erste Gespräch ist kostenlos und endet mit zwei oder drei Szenarien, das kostenpflichtige technische Assessment liefert den Pilotplan und seine Metriken zu einem Preis, der vor Beginn der Arbeit feststeht, und die Ergebnisse des Piloten entscheiden über die Skalierung, mit Support unter einem vereinbarten SLA.

FAQ