Ein vLLM-Benchmark ist nur dann nützlich, wenn er dem Traffic ähnelt, den Ihre Anwendung tatsächlich senden wird. Eine prominente Tokens-pro-Sekunde-Zahl kann ein langsames erstes Token, eine überlastete Warteschlange oder eine Prompt-Verteilung verbergen, die in der Produktion nie vorkommt. Dieser Leitfaden bietet Ihnen einen wiederholbaren Serving-Benchmark: Wählen Sie eine Arbeitslast, variieren Sie die angebotene Last, erfassen Sie Latenzverteilung und Durchsatz gemeinsam und vergleichen Sie GPU-Konfigurationen bei demselben Qualitätsziel.
Kurzantwort: Verwenden Sie vllm bench serve
mit einer festgelegten vLLM-Version und einem festgelegten Modell auf einem dedizierten GPU-Server. Halten
Sie Modell, Präzision, Prompt- und Ausgabelängen, Sampling-Einstellungen,
Cache-Zustand und Client-Standort konstant. Führen Sie mehrere Anfrageraten aus,
erfassen Sie TTFT, TPOT, End-to-End-Latenz, erfolgreiche Anfragerate und
Ausgabe-Tokens pro Sekunde und wählen Sie dann die kostengünstigste Konfiguration,
die Ihr Serviceziel bei Spitzenlast erfüllt. Ein einzelner
Maximaldurchsatzlauf ist kein Kapazitätsplan.
Was in einem vLLM- Benchmark gemessen werden sollte
| Messgröße | Was sie Ihnen sagt | Häufiger Fehler |
|---|---|---|
| Zeit bis zum ersten Token (TTFT) | Verzögerung, bevor die erste gestreamte Ausgabe den Benchmark- Client erreicht | Nur die durchschnittliche Latenz anzugeben, während Nutzer im p95 oder p99 in einer Warteschlange warten |
| Zeit pro Ausgabe-Token (TPOT) | Decode-Zeit pro Anfrage nach dem ersten Token, über Anfragen gemittelt | Sie unter spekulativem Decoding als identisch mit jeder Inter-Token-Lücke zu behandeln |
| End-to-End-Latenz | Zeit von der Anfrageübermittlung bis zur finalen Ausgabe | Läufe mit unterschiedlichen Ausgabelängen zu vergleichen |
| Erfolgreiche Anfragen pro Sekunde | Abgeschlossene Arbeit bei einer angebotenen Last | Anfragen, bei denen ein Timeout auftrat oder die fehlschlugen, als Kapazität zu zählen |
| Ausgabe-Tokens pro Sekunde | Aggregierter Durchsatz generierter Tokens | Durch den GPU-Preis zu teilen, ohne das Latenzziel zu prüfen |
| GPU-Speicher und -Auslastung | Ob der gewählte Batch, KV-Cache und das Modell mit Reserven hineinpassen | Eine hohe Auslastung als gut zu bezeichnen, wenn Warteschlange und Tail-Latenz bereits die Anforderungen verfehlen |
Die vLLM- Benchmark-Dokumentation definiert TTFT, Inter-Token-Latenz und TPOT über ihre Messpunkte. Verwenden Sie diese Definitionen beim Vergleich von Tools. Insbesondere umfasst Client-TTFT Transport- und Frontend-Arbeit; optionale serverseitige Metriken können Scheduler-Wartezeit von der Modell- ausführung trennen, ihre Aktivierung verursacht jedoch zusätzlichen Overhead. Halten Sie Diagnoseläufe von den Hauptergebnissen getrennt.
Legen Sie vor dem Ausführen einen fairen Vergleich fest
Dokumentieren Sie Modellrevision und Tokenizer, vLLM-Version, GPU-Typ und -Anzahl, Tensor-Parallel-Größe, Serving-Flags, Quantisierungsformat, Kontextlänge und Softwareumgebung. Verwenden Sie für jeden Kandidaten dieselben Prompts und Ausgabeziele. Wenn Sie Modell, Präzision und GPU gleichzeitig ändern, kann das Ergebnis nicht zeigen, welche Änderung geholfen hat.
Wählen Sie mindestens zwei Arbeitslasten. Eine synthetische Arbeitslast mit fester Länge ist für kontrollierte Sweeps nützlich; ein bereinigter Trace realer Anfragelängen ist besser für eine Produktionsentscheidung. Bewahren Sie die Verteilung langer Prompts, kurzer Antworten und Bursts. Messen Sie für ein Chat- Produkt den Chat-Endpunkt mit dem entsprechenden Benchmark-Backend. Verwenden Sie für eine Completions- Arbeitslast das Completions-Backend. Vergleichen Sie deren Werte nicht, als wäre die Anfrageformatierung identisch.
Legen Sie die Bestehenskriterien vor dem Lauf fest. Geben Sie beispielsweise eine erforderliche erfolgreiche Anfragerate sowie die maximale p95-TTFT und p95- End-to-End-Latenz für Ihre eigene Arbeitslast an. Wir veröffentlichen keinen universellen Schwellenwert: Er hängt von der Benutzererfahrung und der Ausgabegröße ab. Eine Abnahmetabelle mit den Schwellenwerten, gemessenen Ergebnissen und dem Grund für Bestehen/Nichtbestehen ist nützlicher als ein einzelner Leistungswert.
Führen Sie einen kontrollierten Serving- Test durch
Der aktuelle vLLM-CLI-
Leitfaden führt vllm bench serve für Online-Serving-
Messungen auf und empfiehlt das Bench-Extra für dessen Abhängigkeiten. Die
folgende Übersicht verwendet das dokumentierte Completions-Beispiel von vLLM. Ersetzen
Sie Modell und Datensatz durch Assets, für deren Ausführung Sie lizenziert sind und die
auf Ihre Hardware passen. Diese Befehle sind eine reproduzierbare Vorlage, keine gemessenen
Flatkey-Ergebnisse.
In einer zweiten Shell, nachdem der Server bereit ist:
vllm bench serve \
--backend vllm \
--model YOUR_MODEL_ID \
--endpoint /v1/completions \
--dataset-name sharegpt \
--dataset-path /path/to/ShareGPT_V3_unfiltered_cleaned_split.json \
--num-prompts 1000 \
--request-rate 1 \
--save-result \
--save-detailedWiederholen Sie den Vorgang anschließend mit einer kurzen Reihe höherer Werte für --request-rate, während Sie die übrigen Eingaben unverändert lassen. Verwenden Sie genügend Prompts, damit Sie nicht eine Handvoll Anfragen als Tail-Latenzverteilung interpretieren. Speichern Sie für jeden Durchlauf die Rohdaten und den exakten Befehl. Das offizielle Online-Benchmark-Beispiel zeigt die Ausgabefelder und erläutert, wie --save-result und --save-detailed Nachweise bewahren. Verwenden Sie für Chat-Anfragen das dokumentierte Backend openai-chat und den Endpunkt /v1/chat/completions mit einem Datensatz und Modell, die Chat-Formatierung unterstützen.
Führen Sie diesen Benchmark nicht ohne Verkehrsplan gegen einen gemeinsam genutzten Produktionsendpunkt aus. Er erzeugt absichtlich Last. Verwenden Sie ein isoliertes Test-Deployment oder ein kontrolliertes Wartungsfenster und dokumentieren Sie Hintergrundprozesse, die das Ergebnis beeinflussen können.
Führen Sie einen Sweep durch, bis Sie den Latenz-Knick finden
Tragen Sie die angebotene Anfragerate auf der horizontalen Achse auf. Stellen Sie abgeschlossene Anfragen pro Sekunde, p95-TTFT, p95-End-to-End-Latenz und Ausgabetokens pro Sekunde als separate Reihen dar. Zunächst kann der Durchsatz ungefähr mit der angebotenen Last steigen. Jenseits des nachhaltigen Bereichs wächst die Warteschlange, die Tail-Latenz steigt und der erfolgreiche Durchsatz kann abflachen. Dieser Wendepunkt ist wichtiger als die größte Zahl, die in einem einzelnen Durchlauf ausgegeben wird.
Halten Sie einen Warm-up-Durchlauf getrennt. vLLM weist darauf hin, dass die Wiederholung eines Benchmarks gegen denselben Server gecachte Präfixe wiederverwenden und den Durchsatz erhöhen kann. Wenn die Cache-Wiederverwendung nicht Teil der Produktlast ist, variieren Sie den Seed oder setzen Sie den Server bzw. Cache gemäß den offiziellen Benchmark-Hinweisen zurück. Wenn Cache-Wiederverwendung doch realistisch ist, berichten Sie die Cache-Trefferquote und fügen Sie einen Vergleich mit kaltem Cache hinzu. Ein Benchmark ohne festgelegte Cache-Richtlinie ist schwer zu reproduzieren.
Wenn ein Durchlauf sein Ziel verfehlt, untersuchen Sie die Abfolge. Ein TTFT-Anstieg bei wachsender Warteschlange kann auf Sättigung oder Zulassungssteuerung hindeuten. Ein schlechter TPOT bei stabiler Wartezeit in der Warteschlange kann auf Decoding, Speicherbandbreite, Parallelität oder eine ineffiziente Präzisionswahl hindeuten. Wenn Fehler zunehmen, prüfen Sie Timeouts, OOMs und Serverprotokolle, bevor Sie Modelleinstellungen anpassen. Das gleichzeitige Ändern mehrerer Variablen verschleiert die Ursache.
Vergleichen Sie GPU-Optionen anhand akzeptierter Arbeit, nicht anhand der Rohgeschwindigkeit
Eine größere GPU kann mehr Ausgabetokens pro Sekunde erzeugen und dennoch pro akzeptierter Anfrage mehr kosten. Berechnen Sie für jede Konfiguration ungefähre Kosten:
GPU-Kosten pro 1.000 erfolgreiche Anfragen = stündliche GPU-Kosten ÷ erfolgreiche Anfragen pro Stunde × 1.000
Verwenden Sie ein aktuelles Angebot für die exakte Region und Laufzeitbindung und berücksichtigen Sie Nicht-GPU-Infrastruktur oder Mindestabrechnungsintervalle, falls sie relevant sind. Vergleichen Sie nur Durchläufe, die Ihre Latenz- und Fehlerziele erfüllen. Eine günstigere Konfiguration, die p95 TTFT nicht erfüllt, ist keine günstigere Möglichkeit, denselben Dienst bereitzustellen.
Halten Sie für einen ersten Cloud-Vergleich Modell und Serving-Konfiguration fest und ändern Sie nur den GPU-Typ. Testen Sie anschließend eine kleine Anzahl von Tuning-Änderungen, etwa Batch- und Speichereinstellungen, jeweils einzeln. Erfassen Sie Auslastung, VRAM-Reserven, Warteschlangentiefe, Erfolgsrate der Anfragen und das Benchmark-Artefakt. Flatkey Compute kann eine zu bewertende Kapazitätsoption sein; prüfen Sie die angebotene GPU, Region und das aktuelle Angebot, bevor Sie sie in einem Kostenvergleich verwenden. Dieser Leitfaden behauptet nicht, dass eine bestimmte GPU immer schneller oder günstiger ist.
Ein vLLM-Benchmark-Ergebnis, das Sie einem Reviewer vorlegen können
Dokumentieren Sie für jeden Durchlauf: Modell und Revision; vLLM- und Treiberversionen; GPU und Topologie; Befehl und Datensatz-Prüfsumme; Verteilung der Eingabe-/Ausgabelängen; Client-Standort; Cache-Richtlinie; Anfragerate; abgeschlossene und fehlgeschlagene Anfragen; p50/p95/p99 TTFT; p50/p95/p99 End-to-End-Latenz; Ausgabetoken-Durchsatz; GPU-Auslastung und VRAM; stündliches Angebot; Kosten pro akzeptierter Anfrage; sowie Bestanden/Nicht bestanden gegenüber dem vorab festgelegten Ziel.
Dies ist auch der Punkt, an dem Sicherheit und Qualität sichtbar bleiben sollten. Benchmark-Prompts sollten von Kundendaten bereinigt werden, und die Ausgabequalität sollte beim Vergleich quantisierter Modelle oder unterschiedlicher Modellrevisionen geprüft werden. Ein scheinbarer Geschwindigkeitsgewinn, der die Aufgabenqualität verändert, ist kein Vergleich auf Augenhöhe.
Häufige Fragen
Ist vllm bench throughput dasselbe wie vllm bench serve?
Nein. Der erste Befehl zielt auf den Durchsatz bei Offline-Inferenz ab; der zweite sendet Online-Anfragen an einen laufenden Server und misst das clientseitig wahrgenommene Serving-Verhalten. Verwenden Sie bench serve für die Latenz- und Kapazitätsplanung eines API-Deployments. Die vLLM-CLI-Referenz führt beide Befehle auf.
Welche Kennzahl sollte ich zuerst optimieren?
Beginnen Sie mit dem Serviceziel: Erfolgsrate und Tail-Latenz beim erwarteten Spitzenverkehr. Minimieren Sie dann die Kosten unter den Konfigurationen, die bestehen. Der aggregierte Token-Durchsatz ist für die Diagnose der Kapazität nützlich, kann jedoch ein nutzerorientiertes Latenzziel nicht ersetzen.
Kann ich veröffentlichte Benchmark-Zahlen verschiedener Anbieter vergleichen?
Nur wenn Modell, Präzision, Workload, Ausgabelänge, Endpunkt, Cache-Richtlinie, Anfrageratenregime und Messdefinitionen übereinstimmen. In den meisten Fällen liefert das erneute Ausführen desselben Workloads in beiden Umgebungen einen besser belastbaren Vergleich.
Nächster Schritt: Nehmen Sie einen repräsentativen Trace, legen Sie die Bestehenskriterien fest, führen Sie einen kurzen Raten-Sweep auf zwei GPU-Konfigurationen durch und bewahren Sie die vollständigen Ergebnisse zusammen mit der Entscheidung auf. Wenn Sie auch die Präzision ändern, verwenden Sie den separaten vLLM-Quantisierungsleitfaden, um Speicher und Qualität zu bewerten, bevor Sie Geschwindigkeitsunterschiede der GPU zuschreiben.
