Inferenz-Durchsatz-Rechner
Eingaben
| Parameter | 70 |
|---|---|
| Gewichtspräzision | 16-Bit (2 Bytes) |
| Speicherbandbreite | 3.350 |
Inferenz-Durchsatz-Rechner
Schätzt die durch die Speicherbandbreite begrenzte LLM-Decodiergeschwindigkeit aus Modellgröße, Gewichtspräzision und Speicherbandbreite des Beschleunigers — die Tokens-pro-Sekunde-Obergrenze für einen einzelnen Stream.
Eingaben
Modell
Hardware
Ergebnisse
Geben Sie einen Wert ein, um die Ergebnisse zu sehen.
Details
Inferenz-Durchsatz
Der Inferenz-Durchsatz gibt an, wie viele Tokens ein Sprachmodell pro Sekunde generieren kann. Für eine einzelne Anfrage wird die Obergrenze nicht durch die reine Rechenleistung des Beschleunigers gesetzt, sondern dadurch, wie schnell er die Gewichte des Modells aus dem Speicher lesen kann. Dieser Rechner überführt die Modellgröße, die Gewichtspräzision und die Speicherbandbreite der Hardware in diese Obergrenze — die Tokens-pro-Sekunde-Grenze für einen Decodier-Stream.
Warum das Decodieren speichergebunden ist
Autoregressiv Text zu erzeugen bedeutet, ein Token zu produzieren und es dann zurückzuführen, um das nächste zu produzieren. Jeder dieser Schritte muss jedes Gewicht im Modell lesen, um ein einziges neues Token zu berechnen. Bei einer Batchgröße von eins führt der Beschleuniger pro geladenem Byte sehr wenig Arithmetik aus, sodass er fast die gesamte Zeit damit verbringt, Gewichte zu verschieben, statt zu multiplizieren. Die Token-Rate wird daher von der Speicherbandbreite bestimmt. (Das Prefill des Prompts ist das Gegenteil: Es verarbeitet alle Prompt-Tokens gemeinsam und ist durch die Rechenleistung begrenzt.)
Die Formel
Zunächst wird ermittelt, wie viel Speicher die Gewichte belegen, dann wird die verfügbare Bandbreite dadurch geteilt:
Mv=N×b=MBWDabei ist die Parameteranzahl in Milliarden, die pro Parameter gespeicherten Bytes, die Modellgröße in Gigabyte, die Speicherbandbreite in Gigabyte pro Sekunde und die Durchsatzgrenze in Tokens pro Sekunde. Da eine Milliarde Bytes etwa einem Gigabyte entspricht, landet die Größe direkt in Gigabyte, wenn die Parameter in Milliarden eingegeben werden. Die Gewichtspräzision beträgt 2 Bytes für 16-Bit-Gewichte, 1 Byte für 8-Bit und ein halbes Byte für 4-Bit.
Rechenbeispiel
Man nehme ein Modell mit 70 Milliarden Parametern in 16-Bit-Präzision, das auf einem Beschleuniger mit 3.350 GB/s Speicherbandbreite betrieben wird:
Mv=70×2=140 GB=1403350≈23.9 tokens/sEin einzelner Stream erreicht somit höchstens etwa 24 Tokens pro Sekunde. Eine Quantisierung desselben Modells auf 4-Bit verkleinert es auf 35 GB und hebt die Obergrenze auf etwa 96 Tokens pro Sekunde — ein vierfacher Zuwachs, der die vierfache Verringerung der pro Token gelesenen Bytes widerspiegelt.
Das Ergebnis einordnen
Der Wert ist eine Obergrenze, kein Versprechen. Er zählt nur den Verkehr beim Streamen der Gewichte; der Key-Value-Cache, die Attention-Berechnung und der Kernel-Overhead zehren alle daran, sodass ein realer einzelner Stream üblicherweise zwischen der Hälfte und drei Vierteln der Obergrenze erreicht. Das Bedienen vieler Anfragen in einem Batch liest die Gewichte für die gesamte Gruppe nur einmal und treibt den Gesamtdurchsatz weit über den Single-Stream-Wert — siehe den Batch-Inferenz-Durchsatz-Rechner. Um eine Token-Rate in eine für den Nutzer sichtbare Wartezeit umzurechnen, kombinieren Sie sie mit dem Inferenz-Latenz-Rechner, und um zu beurteilen, wie gut die Rechenleistung der Hardware genutzt wird, siehe den Rechner für die Modell-FLOPs-Auslastung.
Häufig gestellte Fragen (FAQ)
Warum ist das Decodieren durch die Speicherbandbreite und nicht durch die Rechenleistung begrenzt?
Beim autoregressiven Decodieren generiert das Modell ein Token nach dem anderen, und jeder Schritt muss jedes Gewicht aus dem Speicher lesen, um das nächste Token zu berechnen. Bei einer Batchgröße von eins fällt sehr wenig Arithmetik pro geladenem Byte an, sodass der Beschleuniger die meiste Zeit damit verbringt, Gewichte zu verschieben, statt zu multiplizieren.
Die Token-Rate wird daher davon bestimmt, wie schnell der Speicher gelesen werden kann, nicht von der maximalen Gleitkomma-Rechenleistung. Das Prefill, das den gesamten Prompt auf einmal verarbeitet, ist das Gegenteil — es ist rechengebunden.
Erreicht ein Server diesen Wert tatsächlich?
Nein. Der Wert ist eine saubere Obergrenze, die annimmt, dass der einzige Speicherverkehr durch die Gewichte entsteht. In der Praxis ziehen der Key-Value-Cache, die Attention-Berechnung, der Overhead beim Kernel-Start und eine unvollständige Speicherauslastung alle davon ab, sodass ein einzelner Stream typischerweise zwischen der Hälfte und drei Vierteln der Obergrenze erreicht.
Das Zusammenfassen vieler Anfragen zu einem Batch hebt den Gesamtdurchsatz deutlich über die Single-Stream-Grenze, weil die Gewichte für den gesamten Batch nur einmal gelesen werden.
Wie stark erhöht die Quantisierung den Durchsatz?
Der Durchsatz skaliert umgekehrt zur Modellgröße, sodass eine Halbierung der Bytes pro Parameter die Grenze etwa verdoppelt. Der Wechsel von 16-Bit- zu 8-Bit-Gewichten halbiert die pro Token gelesenen Bytes, und 4-Bit halbiert sie erneut. Die Quantisierung kann die Ausgabequalität verringern, sodass der Geschwindigkeitsgewinn gegen eine mögliche Genauigkeitseinbuße für die jeweilige Aufgabe abgewogen wird.
Haftungsausschluss
Dies ist eine Obergrenze erster Ordnung, die nur den Speicherverkehr der Gewichte zählt und Single-Stream-Decodieren annimmt. Der tatsächliche Durchsatz hängt vom Serving-Stack, der Batchgröße, der Sequenzlänge und dem Key-Value-Cache ab und liegt üblicherweise bei einem Bruchteil der Grenze. Führen Sie vor einer Kapazitätsplanung Benchmarks auf der Zielhardware durch.