Wie hoch sind die von MLPerf gemessenen Token pro Sekunde und wie werden sie in LLM verwendet?

Hardwarehandbuch » Benchmarks » Wie hoch sind die von MLPerf gemessenen Token pro Sekunde und wie werden sie in LLM verwendet?

Wenn Sie mit Sprachmodellen arbeiten, haben Sie den Begriff „Token pro Sekunde“ schon tausendmal gehört. Doch selten wird detailliert erklärt, was er in realen Umgebungen bedeutet und vor allem, wie MLPerf ihn misst. In diesem Artikel erklären wir anschaulich, was Token sind, warum die Metrik „Token pro Sekunde“ für die Inferenz so wichtig ist und wie Plattformen wie Databricks und der MLPerf-Benchmark sie zum Bemessen, Vergleichen und Skalieren verwenden. Darüber hinaus beziehen wir spezifische Zahlen von Herstellern und Leistungserwartungen von Cloud zu Boden ein..

Das Problem ist nicht unerheblich: Die Branche hat Token pro Sekunde standardisiert, um die LLM-Leistung in Rechenzentren und am Rand zu bewerten. MLPerf, die von Experten geprüfte MLCommons-Suite, ist zum Maßstab für den Vergleich von Hardware und Software geworden.Parallel dazu stellen Betreiber wie Databricks ihre Modellendpunkte bereits direkt basierend auf einer Reihe von Token pro Sekunde bereit. Lassen Sie uns das Ganze anhand von Zahlen und Anwendungsfällen aufschlüsseln.

Was ist ein Token und warum ist es im LLM wichtig?

Sprachmodelle verarbeiten einzelne Buchstaben oder Wörter nicht unverändert, sondern arbeiten mit Einheiten, die als Token bezeichnet werden. Ein Token ist normalerweise etwa 4 Zeichen lang oder durchschnittlich 0,75 Wörter.Dieses Verhältnis variiert je nach Sprache und Tokenizer des Modells, dient aber als schnelle Referenz: Ein 10-Wörter-Text bewegt sich um etwa 13–14 Token.

Die genaue Segmentierung hängt vom Modell ab: Jedes LLM verwendet seinen eigenen Tokenizer und unterteilt Wörter in vollständige Token oder TeilwörterMithilfe von Online-Tools können Sie beispielsweise sehen, wie Llama eine bestimmte Phrase tokenisiert. Diese scheinbar kleine Variabilität beeinflusst die Latenz und die Rechenkosten.

Wenn von der Generierungsrate die Rede ist, wird sie normalerweise in Token pro Sekunde und nicht in Wörtern pro Sekunde ausgedrückt. Dadurch wird die Metrik über Sprachen, Kontextlängen und Ausgabestile hinweg homogenisiert.und ermöglicht die genaue Berechnung der Inferenzkosten und der erforderlichen Kapazität.

Warum wird die Leistung in Token pro Sekunde und nicht in RPS gemessen?

Traditionelle API-Dienste konzentrieren sich auf RPS (Anfragen pro Sekunde). Bei LLM greift dieser Ansatz zu kurz: Zwei Anfragen können je nach Eingabe- und Ausgabetoken sehr unterschiedlich lange dauernDas heißt, die tatsächliche Nutzlast wird in Tokens und nicht in der „Anzahl der Anrufe“ angegeben.

Es gibt zwei Hauptquellen der Variabilität. Erstens die Länge des Eingabekontexts: Eine kurze Eingabeaufforderung kann nur wenige Token umfassen, ein zusammenfassendes Dokument kann jedoch Hunderte oder Tausende umfassen.Andererseits ist die Länge der Ausgabe wichtig: Beim Zusammenfassen werden normalerweise weniger Token erzeugt; das Generieren eines langen Artikels oder einer langen Beschreibung erhöht den Zeitaufwand, da die Dekodierung der Ausgabe der teuerste Teil ist.

Um einen Inferenzendpunkt realistisch zu skalieren, ist es daher hilfreich, in Tokens zu denken. Databricks beispielsweise stellt seinen Serving-Endpunkten eine Reihe von Token pro Sekunde zur Verfügung und stellt die Rechnung stündlich basierend auf der Skalierung ab.Auf diese Weise können Sie die Kapazität an die tatsächliche Last anpassen, ohne von einem RPS getäuscht zu werden, das nicht die ganze Geschichte erzählt.

So messen Databricks und MLPerf Token pro Sekunde

Databricks nimmt eine repräsentative Anzahl von RAGs als Referenz und fasst zusammen: 2048 Eingabetoken und 256 AusgabetokenEs kombiniert beide Phasen (Vorfüllen und Dekodieren) und optimiert standardmäßig das Gleichgewicht zwischen Durchsatz und Latenz für Batchgrößen von 1 pro Anfrage, indem es mehrere gleichzeitige Anfragen simuliert.

Mit dieser Regel lauten die Zahlen wie folgt: Wenn Sie einen Endpunkt mit 2304 Token pro Sekunde (2048 + 256) konfigurieren, Eine Anfrage mit diesen Größen dauert etwa eine SekundeWenn Sie es auf 5600 Token pro Sekunde einstellen, sinkt die Bearbeitungszeit für dieselbe Anfrage auf etwa 0,5 s und Sie können zwei ähnliche Anfragen pro Sekunde verarbeiten.

Wenn sich Ihre Arbeitslast ändert, ändert sich auch die Latenz. Das Generieren von mehr Ausgabetoken führt zu stärkeren Strafen als das Erhöhen der Eingabetoken.Wenn Sie Batch-Inferenz durchführen, berechnen Sie die durchschnittliche Anzahl der Eingabe- und Ausgabetoken für Ihren Datensatz und vergleichen Sie sie mit dem vorherigen Benchmark, um die Zeiten zu schätzen.

Praktische Beispiele: Mit 1000 Zeilen, durchschnittlich 3000 Eingabe- und 500 Ausgabetoken und einem bereitgestellten Durchsatz von 3500 Token pro Sekunde, es dauert mehr als 1000 Sekunden weil Ihre Durchschnittswerte die Referenz überschreiten. Wenn Sie stattdessen durchschnittlich 1500 Eingaben und 100 Ausgaben mit 1600 Token pro Sekunde bereitstellen, Sie werden unter 1000 Sekunden fallen insgesamt für diese 1000 Zeilen.

Automatische Skalierung nach Bedarf und Berechnung der tatsächlichen Skalierung

Databricks Model Serving umfasst schnelle Autoskalierung, die Erhöhen oder verringern Sie die Ressourcen basierend auf der Nachfrage nach Token pro SekundeDas System skaliert in Kapazitätsblöcken, und zusätzliche Kapazität wird nur bei Nutzung in Rechnung gestellt. Bei Tests mit mehreren parallelen Anfragen steigt der bereitgestellte Durchsatz, bis er sich bei Ressourcensättigung bei etwa 8000 Token pro Sekunde stabilisiert, was die Warteschlangenlatenz erhöht.

Wenn Sie weniger Token pro Sekunde feststellen, als Sie markiert haben, überprüfen Sie zwei Dinge: Bereitgestellte Parallelität, die Endpunktmetriken und minimale Bandbreitengröße widerspiegelt konfiguriert. Mit diesen Daten wird die tatsächliche Skalierung mithilfe der Formel „bereitgestellte Parallelität × minimale Bandbreitengröße / 4“ geschätzt.

Ein konkretes Beispiel: Bei einer maximalen Gleichzeitigkeit von 8 und einer minimalen Streifengröße von 850 Token pro Sekunde, Das effektive Limit wäre 1700 Token pro Sekunde (8 × 850 / 4). Wenn Sie diese Berechnung verstehen, vermeiden Sie Überraschungen und können Ihre Einstellungen besser an Ihre Latenz-SLOs anpassen.

MLPerf-Inferenz: Was es ist und was es heute misst

MLPerf, entwickelt von MLCommons, ist die offene und standardisierte Suite zur Messung der KI-Leistung im Rechenzentrum und am Edge, von der Vision bis zum LLM. Ziel ist es, Plattformen auf faire und reproduzierbare Weise zu vergleichen, um die Effizienz des Ökosystems zu steigern.In den letzten Jahren hat sich der Fokus deutlich in Richtung GenAI und große LLMs verlagert.

In der fünften Ausgabe wurde Llama 2 70B als Star-Benchmark konsolidiert und verdrängte ResNet50, und Die Metrik „Token pro Sekunde“ verbesserte sich im besten Fall innerhalb eines Jahres um das 3,3-fache, mit einer durchschnittlichen Leistung, die dank Hardware- und Softwareoptimierungen fünfmal höher ist. Die Präsenz von CPUs wie Intel Xeon 5 in den offiziellen Ergebnissen zeigte auch, dass In bestimmten Szenarien gibt es Raum für effiziente Generallösungen.

Version 5.1 von MLPerf Inference hat einen weiteren Sprung nach vorne gemacht: Es wurden drei neue wichtige Benchmarks integriert, Schlussfolgerung mit DeepSeek-R1, Sprache-zu-Text mit Whisper Large v3 und einem kleinen LLM basierend auf Llama 3.1 8BInsgesamt meldete das Konsortium 27 Teilnehmer, erreichte den Meilenstein von 90.000 Ergebnissen und grenzte die Latenzmetriken in interaktiven Szenarien ein.

Kennzahlen und Ziele in den neuen Benchmarks

Der Reasoning-Benchmark mit DeepSeek‑R1, einem MoE mit 671B Parametern, zeigt, dass Diese Modelle produzieren lange Argumentationsketten, bevor die Antwort. Unterstützt Ausgaben von bis zu 20.000 Token, mit durchschnittlich 3880 Token pro Ausgabe im Datensatz, dem bisher größten Wert in der Inferenz.

Die Regeln messen den Durchsatz im Offline-Modus und im Server-Modus mit strengen Grenzwerten: Zeit bis zum ersten Token von 2 Sekunden und Latenz pro Token von 80 ms bei p99Dadurch soll ein Gleichgewicht zwischen dem „Denkbudget“ und der für dessen Einsatz erforderlichen Reaktionsfähigkeit hergestellt werden.

Der kleine LLM-Benchmark mit Llama 3.1‑8B ersetzt GPT‑J 6B als Gateway. Unterstützt Kontexte mit bis zu 128.000 Token und bewertet die Zusammenfassung auf CNN‑DailyMail mit 778 Eingabetoken und 73 Ausgabetoken. Die Genauigkeit wird mit ROUGE validiert und muss bei geschlossener Division 99 Prozent eines hochgenauen Benchmarks entsprechen.

Bei Latenzmetriken werden zwei Indikatoren verwendet: TTFT (Zeit bis zum ersten Token) und TPOT (Zeit pro Token-Ausgang). Auf dem Server werden 2 s TTFT und 100 ms TPOT notiert. (ca. 480 ppm), und im neuen interaktiven Szenario wird es für Fälle wie Chat, Codierung oder kreative Tools auf 0,5 s bzw. 30 ms (ca. 1600 ppm) reduziert.

Leistungshighlights nach Hersteller und Betreiber

• NVIDIA führte erneut, diesmal mit Blackwell Ultra auf dem GB300 NVL72-System, und erzielte Ein Rekord im Reasoning mit 45 Prozent mehr Durchsatz DeepSeek‑R1 als GB200 NVL72, erreichte 5842 Token pro Sekunde pro GPU offline und 2907 auf dem Server, mit Verbesserungen von fast dem Fünffachen im Vergleich zum nicht verifizierten Hopper.
• Im neuen interaktiven Llama 3.1 405B Benchmark hat NVIDIA disaggregiertes Servieren mit Dynamo, Trennung von Kontext und Generierung auf verschiedenen GPUs und Übertragung des KV-Cache über NVLink, wodurch ein 1,5-mal höherer Durchsatz pro GPU erreicht wird als bei herkömmlicher Bereitstellung auf Blackwell und mehr als 5-mal mehr als bei Systemen mit Hopper.
• Für kleinere Modelle berichtete NVIDIA Über 18.000 Token pro Sekunde pro GPU auf Llama 3.1 8B offline und 5667 Token pro Sekunde pro GPU in Whisper, wodurch die GPU-Führung in allen Szenarien (offline, Server und interaktiv) beibehalten wird.
• AMD hat seine Präsenz mit der ersten Auslieferung der Instinct MI355X GPU erweitert, die jetzt im 2-70B-Bereich liegt. Es zeigte eine Multi-Node-Skalierung und eine 2,7-fache Steigerung der Token pro Sekunde gegenüber MI325X in FP8. Bei der offenen Teilung wurde strukturierter Schnitt bei Llama 3.1‑405B (FP4) angewendet, Steigerung des Durchsatzes um 82 Prozent mit einem um 21 Prozent verfeinerten Modell und um 90 Prozent mit einem um 33 Prozent verfeinerten Modell, wobei die Präzision erhalten bleibt.
• Außerdem wurden erstmals die Modelle Llama 2‑70B Interactive, Mixtral‑8×7B und Stable Diffusion XL ausgeliefert und gemischte Ergebnisse für MI300X/MI325X präsentiert: Bei der Skalierung auf 4 Knoten erreichte MI355X einen 3,4-mal höheren Durchsatz als MI300X, erweiterbar auf 8 Knoten mit guter Skalierbarkeit.
• HPE, bestehend aus ProLiant und Cray, meldete 14 Nummer-1-Ergebnisse. Der DL380a Gen12 stach in DLRM und Llama 3.1‑8B (Server) unter den 8-GPU-PCIe-Systemen hervor; der DL385 Gen11 deutlich bessere GPU-Leistung in Whisper mit H200 NVL; und der Cray XD670 (8× H200) erzielte sechs erste Plätze in RetinaNet, Llama 3.1‑8B, Mixtral und Whisper sowie erste Plätze mit RTX Pro 6000 Blackwell SE und GH200 NVL2-Ergebnissen in DLRM.
• CoreWeave war die erste Cloud, die Ergebnisse mit GB300 meldete und lieferte 6005 Token pro Sekunde pro GPU in DeepSeek‑R1 offline und demonstriert Orchestrierung und Skalierung mit Slurm auf Kubernetes und topologiebewusster Planung, um das Beste aus NVLink herauszuholen.
• Dell lieferte 12 Systeme mit AMD- und NVIDIA-Beschleunigern aus und glänzte in LLaMA 2 70B Interactive mit PowerEdge XE9680L und B200, LLaMA 3.1‑8B Server auf XE9685L+B200, SDXL auf XE9685L und Whisper auf XE9680L, die die Vielseitigkeit von Bild bis Sprache durch LLM demonstrieren.
• Intel betonte, dass es weiterhin der einzige, der Ergebnisse mit Server-CPUs sendet und zeigte, dass Xeon 6 mit P-Cores in fünf Benchmarks eine 1,9-fache Verbesserung gegenüber Xeon der 5. Generation aufweist, was seine Rolle in der allgemeinen Inferenz festigt. Außerdem wurden Workstations mit 8 Arc Pro B60-GPUs mit 192 GB VRAM eingeführt, um Llama2-70B für mehrere Benutzer bereitzustellen, sowie gebündelte Treiber und Frameworks, um die Bereitstellung mehrerer GPUs zu vereinfachen.
• Zu den Integratoren und Partnern zählen ASUSTeK Optimierte Latenz und Durchsatz mit Quantisierung, Kerneln und Stack; Broadcom demonstrierte VCF-Virtualisierung mit minimalem Overhead im Vergleich zu Bare Metal bei mehreren Workloads (Whisper, SDXL, Llama 3.1-405B, Llama2-70B, RGAT, RetinaNet); Cisco skalierte nahezu linear mit dem UCS C885A M8 (8× H200 SXM) und UCS C845A M8 (8× H200 NVL oder L40S), unterstützt von One G200-Netzwerken.
• KRAI hat mithilfe der OpenAI-API und realistischer Overheads SGLang und vLLM mit Llama3.1‑70B verglichen: 31.391 Token pro Sekunde offline mit SGLang 0.4.9 und 26.319 mit vLLM 0.9.2 auf einem einzelnen Server mit 8x H200; mit dynamischer Quantisierung erreichte es 27.697 mit SGLang und 30.893 mit vLLM, und auf mehreren Knoten skalierte es auf drei Servern auf 87.334 Token pro Sekunde.
• Lambda mit 8x B200 180 GB SXM zeigte Durchsatzverbesserungen bis zu 7 Prozent in SDXL und 15 Prozent in Llama 3.1‑405B im Vergleich zur vorherigen Runde und bietet Cluster von 16 bis 1536 GPUs mit verwaltetem Kubernetes oder Slurm.
• MiTAC glänzte mit seiner G8825Z5-Serie bei LLaMA 2 70B Interactive mit 18.846,1 Token pro Sekunde und gute Ergebnisse in Server und Mixtral; Nebius zertifizierte seine virtualisierte Leistung fast auf dem Niveau von Bare Metal in GB200 NVL72, HGX B200 und HGX H200, mit 596,11 Token pro Sekunde auf dem Server und 855,82 Token offline auf Llama 3.1‑405B mit 4 GB200-GPUs.
• Red Hat demonstrierte vLLM als unterstützte Laufzeitumgebung auf seinem AI Inference Server mit CUTLASS-Kernel für FP8 und FlashAttention‑3 plus eine verbesserte vLLM v1-Engine, treibt Llama-3.1-8B in H100 und L40S mit einem hervorragenden Preis-Leistungs-Verhältnis an.
• Supermicro erzielte mit dem HGX‑B200 8‑GPU (Luft und Flüssigkeit) sowohl mit Intel‑ als auch mit AMD‑CPUs führende Ergebnisse und betonte Llama 3.1‑8B und Llama 2‑70B auf Server/offline/interaktiv und Whisper; in Kooperationen zeigte es eine hervorragende Skalierung mit 32× H100‑SXM und Alternativen mit MI325X.
• Vultr debütierte mit Supermicro AS‑8126GS‑TNMR und 8x MI325X und zertifizierte wettbewerbsfähige Leistung als Cloud-GPU; GATEOverflow verbesserte Reproduzierbarkeit mit MLCFlow auf RTX 4090 und AMD/Intel-CPUs; Giga Computing lieferte luftgekühlte 8U-Systeme EPYC+MI325X und Xeon+HGX B200; QCT deckte Xeon 6-Konfigurationen mit H200 NVL (4 GPUs) und 8× H200 SXM5-Plattformen mit NVLink und GPUDirect Storage ab, zusätzlich zu 8× MI325X-Systemen.

Auch die akademische Welt hatte ihren großen Auftritt. Die University of Florida mit ihrem DGX B200 SuperPOD, integriert mit HiPerGator, war die erste Institution, die Inferenzergebnisse vorlegte Erreichen von Serverlatenzen bei geschlossener Partitionierung, Verwendung von Apptainer ohne Docker/Sudo und Einbindung in Multi-User-SLURM. Am anderen Ende der Skala: eine einzelne Übermittlung auf einem M1 MacBook Pro, mit ONNX Runtime und CoreML auf GPU und Neural Engine, übertraf die Zielgenauigkeit in der Edge-Kategorie und zeigte, dass Qualitätsinferenz auf Verbraucherhardware ausgewertet werden kann.

Von Benutzern wahrgenommene Geschwindigkeit und praktische Grenzen

Benutzererfahrung wird nicht nur in Benchmarks gemessen; im Alltag, Das Gefühl der Flüssigkeit kommt, wenn Sie eine bestimmte Schwelle von Token pro Sekunde überschreitenEin Benutzer kommentierte, dass das Limit für Gespräche 4 Token pro Sekunde und für das Schreiben von Geschichten etwa 10 Token pro Sekunde beträgt; darunter fühlt sich die Interaktion langsam an.

Wenn Sie versuchen, ein LLM lokal auszuführen, gibt es drei Realitäten. Auf einer Desktop-CPU Es ist normal, sich mit 1–2 Token pro Sekunde zu bewegen, undurchführbar für lange Antworten. Mit einer High-End-Gaming-GPU können Sie fast 5 Token pro Sekunde erreichen. Mit einer NVIDIA H100 sprechen wir bereits von 60 Token pro Sekunde, aber es handelt sich um Rechenzentrumshardware, nicht um Desktop-Hardware.

Was passiert in der Cloud? Die leistungsstärksten Anbieter übertreffen diese Zahlen dank spezialisierter Hardware und optimierter Inferenz-Stacks. Bei ChatGPT‑119 wurden Durchschnittswerte von etwa 4 Token pro Sekunde und bei Gemini von 168 gemeldet., während beliebte Open-Source-Modelle wie DeepSeek bei etwa 21 Token pro Sekunde liegen. Wenn Sie das in Wörter umrechnen, sind 119 Token pro Sekunde etwa 90 Wörter pro Sekunde.

Fazit für die Praxis: Für die meisten Benutzer Das Ausführen einer KI auf dem Computer ist möglich, aber aufgrund der Langsamkeit unpraktischUm mit angenehmer Geschwindigkeit und geringen Latenzen zu arbeiten, bleiben Managed Services die sinnvolle Option.

So dimensionieren Sie Ihren Endpunkt nach TPS und was Sie hinsichtlich der Latenz erwarten können

Praktische Schritte zur Dimensionierung. Skizzieren Sie zunächst Ihren Anwendungsfall: Durchschnittliche Anzahl von Eingabe- und Ausgabetoken, Längenverteilung und erwartete Parallelität. Führen Sie zweitens einen Belastungstest mit einem repräsentativen Datensatz durch, der TTFT und Token pro Sekunde pro Anforderung umfasst.

Richten Sie anschließend die Konfiguration an Ihr Muster aus. Wenn Ihre Arbeitslast der Databricks-Referenz ähnelt (2048 Eingänge, 256 Ausgänge), Wählen Sie einen Bereich von Token pro Sekunde, sodass eine Anfrage innerhalb des gewünschten Latenzbudgets liegtBedenken Sie, dass das Duplizieren der Ausgabe normalerweise mehr kostet als das Duplizieren der Eingabe und dass eine effektive Parallelität von der tatsächlichen automatischen Skalierung abhängt.

Überwachen und anpassen. Behalten Sie die Kennzahlen im Auge bereitgestellte Parallelität, Warteschlangen, TTFT und TPOT, und vergleichen Sie es mit Ihren SLOs. Wenn die Kapazität knapp ist, erweitern Sie den Bereich. Wenn Sie über Ressourcen verfügen, reduzieren Sie ihn und passen Sie die Blöcke an, um zu sparen. Die Formel für die wahre Skalierung hilft Ihnen zu verstehen, warum der Endpunkt nicht wie konfiguriert funktioniert, wenn er nicht genügend Replikate erstellt hat.

Seien Sie sich schließlich des Szenarios bewusst. Im interaktiven Chatbot-Modus, streben Sie eine TTFT von 0,5 s und 30 ms pro Token an Dies bietet Ihnen ein erstklassiges Benutzererlebnis. Im Servermodus sind 2 s und 100 ms pro Token sinnvolle Richtlinien, und offline wird ein maximaler Durchsatz angestrebt, während die vom Benchmark geforderte Genauigkeit beibehalten wird.

Bei Betrachtung der MLPerf-Trends ist der Vektor klar: Mehr Kontext, mehr Token und bessere Effizienztechniken – disaggregiertes Serving, FP4/FP8, strukturiertes Pruning, benutzerdefinierte Kernel, KV-Cache-Scheduling – treiben die Token-Obergrenze von Jahr zu Jahr um das Zweite nach oben, sowohl pro Chip als auch pro System.

Das Gesamtbild, das Databricks und MLPerf zeichnen, ist konsistent: Um Kosten, Latenz und Skalierbarkeit in LLM zu beurteilen, ist es richtig, in Token pro Sekunde zu denken.Mit einem guten repräsentativen Benchmark, TTFT/TPOT-Metriken und gut kalibrierter automatischer Skalierung ist es möglich, schnelle und stabile Antworten zu liefern, ohne die Infrastruktur zu überdimensionieren.

Verwandte Artikel:

NVIDIA Blackwell Ultra GB300: Architektur, Speicher und NVLink 5