Benchmarking der LLM-Inferenz im großen Maßstab mit AIPerf

Benchmarking der LLM-Inferenz im großen Maßstab mit AIPerf

Eine Demo kann eine Handvoll Anfragen pro Sekunde bedienen und sich sofort anfühlen. Derselbe Dienst kann unter Hunderten gleichzeitigen Nutzern Sekunden mit Warten in der Warteschlange verbringen, bevor er ein einziges Token ausgibt. Am Modell hat sich nichts geändert. Geändert hat sich, dass die erste Messung an einem im Leerlauf befindlichen System vorgenommen wurde und die zweite an einem ausgelasteten.

Diese Lücke ist der ganze Grund, warum es ein dediziertes Benchmarking-Tool für die Inferenz großer Sprachmodelle gibt. NVIDIAs AI-Blogbeitrag Benchmarking LLM Inference at Scale with AIPerf (https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf) behandelt AIPerf, ein Tool, das genau für dieses Problem gebaut wurde. Dieser Artikel nimmt diesen Beitrag als faktischen Anker und erklärt dann die Methodik darum herum: wie man einen Inferenz-Benchmark rahmt, welchen Zahlen man vertrauen sollte und wo die Messung still schiefgeht.

Ein Hinweis zur Quellenlage, klar gesagt. Die verifizierte Tatsache, die diesem Artikel zugrunde liegt, ist, dass NVIDIA den obigen Beitrag über AIPerf veröffentlicht hat. Spezifika des Tools – seine Schnittstelle, unterstützte Endpunkte, Workload-Typen und sein Funktionsumfang – gehören in diesen Beitrag und in seine Dokumentation, und sie ändern sich mit der Zeit. Alles Folgende zur Methodik ist Orientierung und Interpretation, keine Aussage über die Interna von AIPerf. Wo dieser Artikel etwas nicht verifizieren kann, sagt er das, statt zu raten.

Warum LLM-Inferenz konventionelle Lasttests sprengt

Konventionelle Web-Lasttests gehen davon aus, dass Anfragen kurz, billig und austauschbar sind. LLM-Inferenz verletzt alle drei Annahmen gleichzeitig.

Eine Anfrage erzeugt nicht eine Antwort; sie erzeugt einen Strom von Token über die Zeit. Latenz ist daher kein Skalar, sondern eine Kurve mit mindestens zwei verschiedenen Regionen: die Wartezeit vor dem ersten Token und der Rhythmus zwischen den nachfolgenden Token. Die Wahrnehmung der Geschwindigkeit durch einen Nutzer hängt überwiegend von der ersten Region ab. Die Wahrnehmung der Flüssigkeit hängt von der zweiten ab. Eine einzelne „durchschnittliche Antwortzeit“ kollabiert beides zu einer Zahl, die keines von beidem beschreibt.

Die Kosten sind zudem variabel, und zwar auf eine Weise, wie Web-Anfragen es nicht sind. Ein kurzer Prompt, der zwanzig Token erzeugt, und ein langer Prompt, der zweitausend Token erzeugt, sind aus Sicht des Netzwerks dieselbe HTTP-Anfrage und aus Sicht des Servers völlig unterschiedliche Workloads. Benchmarks, die sie als gleichwertig behandeln, erzeugen Durchsatzwerte, die mit nichts vergleichbar sind.

Schließlich sind Inferenzserver in einer Weise zustandsbehaftet, die zählt. Batch-Entscheidungen, KV-Cache-Belegung und Speicherdruck hängen alle davon ab, was sonst noch in Bearbeitung ist. Eine Anfrage, die in einen leeren Cache eintrifft, verhält sich anders als eine, die hinter tausend ähnlichen Prompts eintrifft. Jeder Benchmark, der diesen Zustand nicht kontrolliert, misst genauso viel Historie wie Kapazität.

Was AIPerf ist und wohin es passt

Allgemeine Lastgeneratoren können HTTP-Verkehr erzeugen. Einen realistischen Token-Streaming-Workload zu erzeugen, das Timing pro Token aufzuzeichnen, genug Nebenläufigkeit aufrechtzuerhalten, um einen modernen Beschleuniger zu sättigen, und die Ergebnisse zu etwas Entscheidungstauglichem zu aggregieren, ist ein anderes Ingenieursproblem – eines, das ein speziell gebautes Tool rechtfertigt.

Das ist die Kategorie, die AIPerf laut NVIDIAs Beitrag besetzt. Die praktische Implikation für ein Team, das Inferenzinfrastruktur evaluiert, ist unkompliziert: Die Wahl des Tools ist weniger wichtig als die Disziplin, mit der es angewendet wird. Ein gut konzipierter Benchmark, der mit einem bescheidenen Tool ausgeführt wird, schlägt einen sorglosen Lauf mit einem hochentwickelten Tool jedes Mal.

Der Rest dieses Artikels handelt von dieser Disziplin.

Die Metriken, auf die es tatsächlich ankommt

Fünf Messungen leisten die meiste Arbeit.

Time to first token (TTFT) erfasst Prefill, Queueing und Scheduling – alles, was passiert, bevor der Nutzer irgendetwas sieht. Es ist der dominierende Treiber der wahrgenommenen Reaktionsfähigkeit in interaktiven Anwendungen.

Inter-Token-Latenz (ITL), manchmal als Zeit pro Ausgabe-Token ausgedrückt, erfasst die Decode-Schleife. Sie bestimmt, ob sich die Ausgabe flüssig oder stockend anfühlt. Sie wird üblicherweise als Median angegeben, weil das erste Token ausgeschlossen wird und weil der Decode-Rhythmus vergleichsweise stabil ist, bis der Server sättigt.

Ende-zu-Ende-Latenz ist die Summe aus beidem plus der vollständigen Generierung. Sie zählt am meisten für Batch- und agentische Workloads, bei denen kein Mensch den Stream beobachtet.

Durchsatz muss präzise angegeben werden, weil zwei verschiedene Zahlen denselben Namen teilen. Anfragedurchsatz zählt abgeschlossene Anfragen pro Sekunde. Token-Durchsatz zählt erzeugte Token pro Sekunde. Ein System kann das eine verbessern, während es das andere verschlechtert, und Anbieter sagen selten, welches sie meinen.

Goodput ist die Metrik, die das auflöst. Sie zählt nur die Anfragen, die ein definiertes Service-Level-Ziel erfüllt haben. Eine Konfiguration, die 6.000 Token pro Sekunde erzeugt, während sie bei einem Drittel der Anfragen ihr Latenzziel verfehlt, hat ein Goodput-Problem, keinen Durchsatztriumph.

Berichten Sie Perzentile, keine Durchschnitte. Ein p50, das gesund aussieht, neben einem p99, das vierzigmal größer ist, beschreibt ein System, das die meiste Zeit in Ordnung und manchmal unbrauchbar ist – was für ein interaktives Produkt ein ausfallendes System ist.

Hängen Sie immer den Workload an die Zahl. „5.000 Token pro Sekunde“ bedeutet nichts ohne die Verteilungen von Prompt- und Ausgabelänge, das Nebenläufigkeitsniveau, die Hardware und die Softwareversionen. Ohne diese ist es eine Marketingzahl, keine Messung.

Den Workload definieren, bevor Sie irgendetwas messen

Die meisten schlechten Benchmarks sind schlecht, bevor die erste Anfrage gesendet wird, weil der Workload nie spezifiziert wurde.

Beginnen Sie mit der Eingabelänge. Reale Prompts sind nicht gleichförmig; ein Chat-Assistent mit Retrieval erzeugt eine Verteilung mit einem langen Schweif. Synthetische Tests, die eine einzelne feste Prompt-Länge verwenden, sind nützlich, um Variablen zu isolieren, und irreführend, wenn sie als repräsentativ präsentiert werden.

Dann die Ausgabelänge. Wenn der Server bei einer maximalen Token-Anzahl stoppt, verraten Anfragen, die das Limit erreichen, etwas über den Workload, nicht über den Server. Entscheiden Sie im Voraus, ob gekappte Antworten als Erfolge zählen.

Dann das Ankunftsmuster. Hier liegt die folgenreichste Designentscheidung. In einem Closed-Loop-Test sendet eine feste Anzahl virtueller Clients ihre nächste Anfrage erst, nachdem die vorherige abgeschlossen ist. Dieses Modell ist leicht zu durchdenken und unterschätzt systematisch Überlast: Wenn der Server stockt, warten die Clients höflich, und der Stillstand wird nie als Latenz erfasst. In einem Open-Loop-Test treffen Anfragen nach einem unabhängigen Zeitplan ein, unabhängig davon, ob frühere Anfragen abgeschlossen sind. Warteschlangenverzögerungen erscheinen dann dort, wo sie tatsächlich auftreten – in der Erfahrung des Nutzers.

Dieser Fehlermodus ist als koordinierte Auslassung (Coordinated Omission) bekannt, und er ist die mit Abstand häufigste Art, wie ein Inferenz-Benchmark ein System schönfärbt. Wenn Ihr Test immer nur fragt: „Wie schnell war diese Anfrage?“, und nie: „Wie lange hätte ein Nutzer auf seine Anfrage gewartet?“, dann haben Sie Servicezeit gemessen, nicht Latenz.

Entscheiden Sie schließlich den Nebenläufigkeits-Sweep im Voraus. Ein einzelner Nebenläufigkeitspunkt sagt Ihnen fast nichts; die Form der Kurve ist der Befund.

Ein praktisches Beispiel: einen Benchmark-Plan erstellen

Das folgende Szenario ist illustrativ. Die Zahlen sind Designentscheidungen, keine gemessenen Ergebnisse.

Angenommen, Sie qualifizieren einen Chat-Assistenten, der einen langen System-Prompt und abgerufenen Kontext voranstellt und dann kurze Antworten generiert. Die erwartete Eingabe beträgt ungefähr 2.000 Token, die erwartete Ausgabe ungefähr 150.

Schritt eins: Formulieren Sie das Ziel als Einschränkung, nicht als Wunsch. Zum Beispiel: p95 TTFT unter 800 ms und p95 Inter-Token-Latenz unter 50 ms, gehalten bei 40 Anfragen pro Sekunde. Das vorher aufzuschreiben verhindert das häufige Ergebnis, einen Benchmark laufen zu lassen und dann zu entscheiden, welche Zahl beeindruckend aussah.

Schritt zwei: Bauen Sie den Sweep. Führen Sie ihn bei Nebenläufigkeitsniveaus von 1, 8, 32, 128 und 512 aus. Halten Sie jedes Niveau für ein festes Zeitfenster, das lang genug ist, um einen Steady State zu erreichen. Halten Sie die Prompt-Längenverteilung über alle Niveaus identisch, damit Änderungen in der Kurve die Last widerspiegeln, nicht den Inhalt.

Schritt drei: Fixieren Sie alles. Modellrevision, Serving-Konfiguration, Parallelitätseinstellungen, Batch-Limits, Client-Hardware und Netzwerkpfad. Ein nicht fixierter Benchmark erzeugt eine Anekdote, kein Ergebnis.

Schritt vier: Aufwärmen, dann verwerfen. Die ersten Anfragen gegen einen kalten Cache sind nicht repräsentativ für den Steady-State-Betrieb. Führen Sie eine Aufwärmphase aus und schließen Sie sie von der Berichterstattung aus.

Schritt fünf: Wiederholen und Streuung berichten. Drei Läufe pro Nebenläufigkeitsniveau, mit angezeigter Varianz. Ein einzelner Lauf, der zufällig gut aussieht, ist kein Beleg.

Schritt sechs: Finden Sie den Knickpunkt, nicht den Spitzenwert. Der Durchsatz steigt ungefähr linear mit der Nebenläufigkeit, bis sich eine Warteschlange bildet. Danach flacht der Durchsatz ab oder sinkt, während die Latenz steil ansteigt. Das nützliche Ergebnis der Übung ist nicht die höchste Zahl, die das System je produziert hat; es ist die höchste Nebenläufigkeit, bei der das Service-Level-Ziel noch hält. Das ist Ihr Betriebspunkt.

Wo Inferenz-Benchmarks schiefgehen

Der Client wird zum Engpass. Tokenisierung, TLS-Handshakes und Sampling pro Token sind CPU-Arbeit. Bei hoher Nebenläufigkeit kann der Lastgenerator sättigen, bevor der Server es tut, und am Ende messen Sie Ihren Benchmarking-Rechner. Bestätigen Sie Client-Reserven, bevor Sie irgendeinem Ergebnis am oberen Ende der Kurve vertrauen.

Cache-Effekte blähen Ergebnisse auf. Das Wiederholen eines kleinen Satzes identischer Prompts erzeugt unrealistisch hohe Cache-Wiederverwendung. Verwenden Sie Prompt-Diversität, die der Produktion entspricht, oder sagen Sie ausdrücklich, dass Sie einen cache-warmen Best Case messen.

Tokenizer sind nicht abgestimmt. Token mit einem anderen Tokenizer zu zählen als dem, den der Server verwendet, erzeugt Durchsatzwerte, die um ein paar Prozent falsch sind und nie abgeglichen werden.

Die Konfiguration driftet zwischen Läufen. Einen achtfach parallelen Lauf mit einem vierfach parallelen zu vergleichen, oder einen Lauf mit anderen Sampling-Parametern, erzeugt einen Unterschied, der nichts mit der getesteten Änderung zu tun hat.

Der Tail wird weggemittelt. Das Berichten der mittleren Latenz verbirgt genau das Verhalten, das Nutzerbeschwerden und Incident-Tickets erzeugt.

Durchsatz wird auf Kosten der Reaktionsfähigkeit optimiert. Eine Konfiguration mit ausgezeichnetem Token-Durchsatz und schlechtem TTFT kann die richtige Wahl für Offline-Batchverarbeitung und die falsche Wahl für eine Chat-Oberfläche sein. Das Metrikset sollte dem Produkt folgen.

Überlastverhalten wird nie getestet. Gehen Sie absichtlich über den Knickpunkt hinaus. Verschlechtert sich das System allmählich, indem es Last abwirft und Latenz hält, oder fällt es von der Klippe? Dieses Verhalten ist wertvoller zu kennen als die Spitzenzahl.

Den Benchmark selbst skalieren

Oberhalb von ein paar hundert gleichzeitigen Streams wird der Benchmark zu einem verteilten System und erbt Probleme verteilter Systeme.

Perzentile lassen sich nicht mitteln. Den p99 von drei Lastgeneratoren durch ihren Mittelwert zusammenzuführen, ist arithmetisch bedeutungslos. Korrekte Aggregation erfordert zusammengeführte Latenzverteilungen oder Histogramme, die von jedem Worker gesammelt werden – ein Detail, das in ansonsten sorgfältigen Evaluierungen stillschweigend Ergebnisse verfälscht.

Uhrzeitabgleich zählt aus demselben Grund. Wenn sich Worker über die aktuelle Zeit uneinig sind, wird das Timing pro Anfrage genau in dem Maßstab verrauscht, in dem Präzision am wichtigsten ist.

Anhaltende Läufe mit hoher Nebenläufigkeit brauchen außerdem Verbindungswiederverwendung und sorgfältige Speicherverwaltung auf der Client-Seite. Ein Generator, der pro Token alloziert, verbringt seine Zeit mit Garbage Collection statt mit Messung.

Schließlich fügen Multi-Turn- und Long-Context-Workloads eine Dimension hinzu, die Single-Request-Tests völlig verpassen. Sitzungszustand, wachsender Kontext und wiederholte Präfixe verändern das Cache-Verhalten auf eine Weise, die nur sichtbar wird, wenn ein Benchmark eine Konversation statt einer Anfrage modelliert.

Ergebnisse interpretieren und berichten

Ein Benchmark-Bericht, der nicht reproduziert werden kann, ist kein Bericht. Er sollte mindestens die Workload-Definition, die Hardware- und Softwareversionen, die getesteten Nebenläufigkeitsniveaus, die Metrikwerte mit Perzentilen und ein ausdrückliches Urteil gegen das Service-Level-Ziel enthalten.

Eine kompakte Tabelle funktioniert gut, und die folgende ist eine Vorlage mit Platzhalterwerten, keine gemessenen Daten:

Das Ergebnis dieser Übung ist keine Zahl. Es ist eine dokumentierte Betriebshülle: der Lastbereich, innerhalb dessen sich der Dienst wie versprochen verhält, und eine Beschreibung dessen, was außerhalb passiert.

Offene Grenzen

Mehrere Dinge kann dieser Artikel nicht klären. Die Leistung eines bestimmten Modells auf bestimmter Hardware unter einem bestimmten Serving-Stack hängt von allen dreien ab, und keine allgemeine Anleitung ersetzt das Ausführen Ihres eigenen Workloads. Tool-Funktionen entwickeln sich weiter, daher ist die maßgebliche Beschreibung der Fähigkeiten von AIPerf der Quellbeitrag selbst, nicht eine sekundäre Zusammenfassung. Und ein Benchmark, so sorgfältig er auch ausgeführt wird, charakterisiert eine Konfiguration zu einem Zeitpunkt; er sagt nichts über das Verhalten nach einem Treiber-Update, einer Batch-Änderung oder einer Verschiebung des Verkehrsmixes voraus.

Behandeln Sie veröffentlichte Ergebnisse, auch günstige, als Hypothesen über Ihr Deployment, nicht als Schlussfolgerungen darüber.

Fazit

LLM-Inferenz im großen Maßstab verhält sich nicht wie Web-Verkehr, und Tools, die für Web-Verkehr entwickelt wurden, messen die falschen Dinge. Die Arbeit, sie zu benchmarken, läuft auf ein paar disziplinierte Entscheidungen hinaus: Definieren Sie den Workload, bevor Sie ihn ausführen; sweepen Sie die Nebenläufigkeit, statt einen einzelnen Punkt zu testen; bevorzugen Sie Open-Loop-Ankunftsmuster, damit Warteschlangenverzögerungen sichtbar werden; berichten Sie Perzentile statt Durchschnitte; und behandeln Sie Goodput – nicht Spitzendurchsatz – als die Zahl, die bestimmt, ob das System tatsächlich nutzbar ist.

AIPerf existiert, um diese Messung im großen Maßstab praktikabel zu machen. Das Tooling verkürzt die Distanz zwischen einer Frage und einer Antwort; es entscheidet nicht, welche Frage gestellt wird. Diese Entscheidung – das Ziel, der Workload und der Betriebspunkt, den Sie ausliefern wollen – bleibt Ihre.