Was in jeder Phase passiert
Im Prefill liest das Modell den gesamten Prompt auf einmal. Das ist eine große, hochparallele Matrix-Matrix-Berechnung, die die Recheneinheiten der Hardware voll auslastet. Das Ergebnis ist der KV-Cache: die Attention-Keys und -Values für jedes Token des Prompts. Sie werden einmal berechnet und für den Rest des Requests wiederverwendet. Das Prefill endet mit dem ersten Ausgabe-Token. Deshalb bestimmt die Länge des Prompts die Zeit bis zum ersten Token.
Im Decode erzeugt das Modell ein Token, hängt es an den Kontext an und wiederholt das. Jeder Schritt ist eine schmale Matrix-Vektor-Operation, die den zwischengespeicherten Zustand wiederverwendet. Trotzdem muss die Hardware für jedes einzelne Token die Modellgewichte aus dem Speicher lesen. Diese Phase ist speichergebunden: Die Latenz hängt vor allem davon ab, wie schnell Gewichte und Cache-Daten aus dem Speicher kommen, nicht von der Rechenleistung.
Warum der Unterschied wichtig ist
Die beiden Phasen stellen unterschiedliche Anforderungen an die Hardware. Das Prefill profitiert von roher Rechenleistung, das Decode von Speicherbandbreite und effizienter Datenbewegung. Der Engineering-Leitfaden von Databricks formuliert die praktische Konsequenz: Die Speicherbandbreite sagt die Geschwindigkeit der Token-Generierung besser voraus als die Spitzenrechenleistung. Ein Chip mit spektakulären FLOPS kann trotzdem langsam Token erzeugen, wenn er auf den Speicher warten muss.
Deshalb setzt GPU-basiertes Serving so stark auf Batching. Jeder Ladevorgang der Gewichte wird auf viele gleichzeitige Requests verteilt, und so steigt die Auslastung im Decode wieder. Der Preis ist eine geringere Geschwindigkeit pro Nutzer. Architekturen, die rund um die Datenbewegung entworfen sind, gehen den Engpass im Decode dagegen direkt an. Ein Beispiel ist die Dataflow-Hardware, die wir betreiben. Sie bleibt auch bei kleinen Batch-Größen hoch ausgelastet.
Die Metriken aus diesem Blickwinkel lesen
Die Leistung im Prefill zeigt sich in der TTFT. Die Leistung im Decode zeigt sich in der Inter-Token-Latenz und in den Ausgabe-Token pro Sekunde. Die Forschungsliteratur macht eine Einschränkung: Die Aufteilung in rechengebunden und speichergebunden gilt für übliche Batch-Größen im Serving. Bei sehr großen Batches kann auch das Decode rechengebunden werden. Aus genau diesem Grund gibt es den Trend zum disaggregierten Serving: Prefill und Decode laufen dabei auf getrennten, spezialisierten Hardware-Pools, weil sich die beiden Phasen so stark unterscheiden.
Quellen
Erfahren Sie, wie die Dataflow-Architektur von SambaNova die Wirtschaftlichkeit der Inferenz verändert und warum wir auf ihr aufbauen.
Technologie entdecken