LLM throughput und goodput: Welche Kennzahl sollten Sie verwenden?
Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Der Throughput eines LLM misst, wie viel Arbeit ein Server pro Sekunde erledigt. Goodput misst die Rate der Arbeit, die zusätzlich definierte Serviceanforderungen erfüllt. Verwenden Sie für Serving-Entscheidungen den Throughput der Ausgabetokens zusammen mit der Anzahl erfolgreicher Anfragen pro Sekunde, die Ihre Latency-Ziele für das erste Token und die Generierung erfüllen.
Ein Server, der mehr Tokens erzeugt, während Anfragen wegen Zeitüberschreitung scheitern, kann einen höheren Throughput und eine geringere nutzbare Kapazität haben.
Definieren Sie eine Anfrage, die die Anforderungen erfüllt
Definieren Sie vor dem Test die Bedingungen, die eine Anfrage erfüllen muss. Zum Beispiel: erfolgreicher Abschluss, TTFT unter 500 ms und durchschnittliche TPOT unter 50 ms. Zählen Sie dann im Messintervall die abgeschlossenen Anfragen, die diese Bedingungen erfüllen:
request goodput = qualifying completed requests / measured seconds
output throughput = generated output tokens / measured secondsDies sind ein beispielhaftes SLO und zwei explizite Kennzahlendefinitionen. Wenn 100 Anfragen in zehn Sekunden abgeschlossen werden, aber nur 60 die Anforderungen erfüllen, beträgt der Abschluss-Throughput zehn Anfragen pro Sekunde und der Goodput sechs. Geben Sie auch den Throughput der Ausgabetokens an, da die Antwortlängen unterschiedlich sein können.
DistServe verwendet Goodput, um Serving unter Anforderungen an TTFT und Tokengenerierung zu bewerten. Geben Sie immer an, ob Sie Anfragen oder Tokens zählen, die die Anforderungen erfüllen: Das Wort allein definiert weder den Nenner noch die Bedingungen für die Zählung.
Halten Sie den Workload vergleichbar
| Erfassen | Warum es das Ergebnis beeinflusst |
|---|---|
| Eingabe- und Ausgabelängen | Prefill-Aufwand, Cache-Größe und Decode-Dauer unterscheiden sich |
| Model, Präzision, GPU und Runtime-Revision | Sie verändern die Ausführungskosten |
| Angebotene Anfragen pro Sekunde | Bestimmt die Warteschlangenbelastung |
| Gleichzeitige Anfragen | Verändert Batching und Speichernutzung |
| Cache-Richtlinie | Wiederholte Präfixe können den Prefill-Aufwand senken |
| Fehler und Abbrüche | Erfolgreicher Abschluss ist Teil der nutzbaren Kapazität |
Bei kleinen Decode-Batches können zusätzliche Anfragen die Wiederverwendung der Weights verbessern. Größere Batches oder eine steigende angebotene Last können schließlich die Latency erhöhen oder Speicher-, Rechen- oder Kommunikationsgrenzen überschreiten. Die Kurve hängt vom Workload ab; eine lineare Skalierung ist nicht garantiert.
Erhöhen Sie die angebotene Last schrittweise und stellen Sie Throughput, Goodput, P99-Latency, Fehler und Warteschlangenlänge grafisch dar. Wählen Sie eine Last, die die Anforderungen erfüllt und Spielraum für Verkehrsschwankungen lässt. Das Anyscale-Experiment zu Continuous Batching zeigt, warum ein Vergleich die Verteilung der Anfragen angeben muss.
Der Engineering-Leitfaden: Throughput und der Zielkonflikt mit Latency erklärt den Zielkonflikt beim Serving im Kontext.