Warum ist LLM-Decode durch Speicherbandbreite und Prefill durch Rechenleistung begrenzt?
Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
LLM-Decode ist häufig durch die Speicherbandbreite begrenzt, weil ein kleiner Batch jeden Model Weight nur wenige Male wiederverwendet, bevor die nächsten Weights geladen werden. Prefill mit langen Prompts oder ausreichend großen Batches verwendet Weights für viele Prompt-Tokens wieder, sodass die Matrixberechnung zur begrenzenden Ressource werden kann. Das sind Bedingungen der jeweiligen Arbeitslast und keine dauerhaften Eigenschaften der beiden Phasen.
Die arithmetische Intensität hilft zu entscheiden, ob du Datenbewegungen reduzieren oder die Ausführung von Matrixoperationen verbessern solltest.
Berechnungen mit übertragenen Bytes vergleichen
Die arithmetische Intensität ist die Anzahl der Gleitkommaoperationen pro Byte, das aus dem Speicher übertragen wird. Das Roofline-Modell vergleicht sie mit der maximalen Rechenleistung geteilt durch die Speicherbandbreite.
Die technischen Daten der NVIDIA H100 SXM nennen ungefähr 989 TFLOPS für dichte FP16/BF16-Berechnungen auf Tensor Cores und 3.35 TB/s Speicherbandbreite. Der angegebene Wert von 1,979 TFLOPS setzt strukturierte Sparsität voraus. Das Verhältnis beträgt etwa 295 FLOPs pro Byte. Das ist eine theoretische Grenze auf Basis zueinander passender Hardwareangaben.
Eine vereinfachte dichte Matrix-Vektor-Multiplikation führt etwa zwei Operationen pro Weight mit zwei Bytes aus: ungefähr ein FLOP pro Byte. Ein Decoder mit Batchgröße eins kann unter diesen Bedingungen den maximalen Matrix-Throughput der GPU nicht nutzen. Größere Batches ermöglichen es, einen geladenen Weight für mehrere Tokenberechnungen zu verwenden. Prefill verwendet Weights ebenso für mehrere Prompt-Tokens wieder. Splitwise beschreibt diese unterschiedlichen Eigenschaften der Phasen.
Änderungen anhand der gemessenen Begrenzung auswählen
| Beobachtung | Zu untersuchende Änderung | Was einen Gewinn verhindern kann |
|---|---|---|
| Decode mit kleinen Batches benötigt Zeit für die Übertragung von Weights | Unterstützte Weight-Quantization; größere Decode-Batches | Quantization-Kernels, Qualitätsverlust, Latency-Grenzen |
| Decode mit langem Kontext benötigt Zeit zum Lesen des bisherigen Attention-Kontexts | Weniger KV-Heads; unterstützte KV-Quantization; effiziente Attention | Model-Architektur und Unterstützung der Cache-Präzision |
| Großes Prefill nutzt Matrixeinheiten intensiv | Effiziente Matrix-Kernels; unterstützte Berechnungen mit geringerer Präzision | Kurze Prompts, kleine Batches, andere Operationen |
| Viele kurze Kernels verursachen Lücken in der GPU-Ausführung | Fusion oder geringerer Aufruf-Overhead | Zusätzliche Nutzung von Registern und gemeinsamem Speicher |
Miss nach jeder Änderung sowohl die Latency bis zum ersten Token als auch die Intervalle zwischen späteren Tokens. Ein größerer Batch kann die Gesamtzahl der Tokens pro Sekunde erhöhen und gleichzeitig einzelne Anfragen verlangsamen. Das Hardwareverhältnis zeigt eine mögliche Begrenzung; ein Trace zeigt, auf welche Ressource deine Arbeitslast tatsächlich wartet.
Engineering Guide: durch Speicherbandbreite oder Rechenleistung begrenzte Inference enthält das Roofline-Diagramm und phasenspezifische Optimierungen.