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

Ein Pilot ist eine Messung, keine Demo

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 Angebot für private KI/ML gehört diese Liste zum kostenpflichtigen technischen Assessment durch unseren Engineering-Partner Vixen.UNO, zusammen mit der Lösungsarchitektur und der Auswahl von Modell und GPU.

Nicht jede Zahl lässt sich übertragen. Der Bedarf schon: wie oft Anfragen eintreffen, wie lang Prompts und Antworten sind und wie viel Kontext sie brauchen, gezählt in den eigenen Token des Modells. Die Qualität auch, sofern in der Produktion dasselbe Modell in derselben Präzision läuft. Latenz und Durchsatz nicht: Sie gehören zu der GPU, der Engine-Version und den Serving-Einstellungen, mit denen sie gemessen wurden.

Die Zahlen, die zu erfassen sind

Zählen Sie Anfragen, nicht Menschen. 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. 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 rutschen also durch, während der Anstieg von vllm:e2e_request_latency_seconds_sum über die Spitzenstunde, geteilt durch 3.600, nach unserer Rechnung die mittlere Zahl der Anfragen in Bearbeitung in dieser Stunde ergibt, wartende eingeschlossen und abgebrochene nicht. Und eine anhaltende Warteschlange oder jede Verdrängung bedeutet, dass der Pilot an seine eigene Grenze gestoßen ist: Der Bedarf war höher, als die Karte durchließ.

Latenz, genau definiert

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 lässt TTFT heraus: 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; der Mittelwert verdeckt Stockungen, die Abstände zeigen sie. 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.0 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.

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 ist ein Suchproblem, das keine GPU behebt. 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. 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: NVIDIA nannte AIPerf im September 2026 „den designierten Nachfolger von GenAI-Perf“, und GenAI-Perf wird laut seiner eigenen Dokumentation „schrittweise eingestellt“. AIPerf wird mit pip install aiperf installiert (Stand September 2026 Release 0.12.0) 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, und --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 Auswahl; für die Messung setzt die Physik 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.

DGX Spark eignet sich für Funktions- und Qualitätspiloten: Seine 128 GB Unified Memory fassen Llama 3.3 70B in FP8 mit Platz für den Cache, aber bei 273 GB/s liegt seine Decode-Obergrenze für dieses Modell 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.

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 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.

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: mehr als die 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 scheitern also schon vor jeder Last an der Geschwindigkeit, es sei denn, spekulatives Dekodieren, das vLLM anbietet, um die Inter-Token-Latenz bei speichergebundenen Arbeitslasten unter niedriger bis mittlerer Last zu senken, ändert das Bild. 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

Eurokommerz liefert DGX Spark, 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 einzeln oder in individuellen, auf Bestellung gebauten KI-Servern; dort ist eine Starterkonfiguration mit zwei Karten der RTX PRO 6000 Server Edition für Piloten und RAG-Assistenten aufgeführt. Der Pilot selbst ist KI/ML-Integration, erbracht vom Team unseres Engineering-Partners Vixen.UNO im Rahmen eines Vertrags mit Eurokommerz. Wie die Seite zu privater KI/ML beschreibt, endet ein kostenloses erstes Gespräch 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