Warum kann die Prompt-Verarbeitung die lokale KI-Token-Generierung übertreffen?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Die Verarbeitung von Prompts kann der Token-Generierung davoreilen, weil ein Beschleuniger viele Eingabetokens parallel auswertet, Ausgabetokens jedoch nacheinander dekodieren muss.

Ein KI-Dashboard für den Heimgebrauch kann Hunderte oder Tausende Prompt-Tokens pro Sekunde anzeigen, während die gestreamte Ausgabe mit einer deutlich niedrigeren Rate eintrifft. Diese Zahlen beschreiben unterschiedliche Ausführungsphasen und widersprechen sich nicht. Beim Prefill wird der bereitgestellte Kontext als Block verarbeitet und der Aufmerksamkeitszustand aufgebaut, während beim Decode das Modell wiederholt ausgeführt wird, um jeweils ein neues Token zu verarbeiten. Der Unterschied hängt von der Prompt-Länge, der Modellgröße, der Speicherbandbreite, dem Batching, dem Cache-Layout und davon ab, ob Hintergrundanfragen denselben Beschleuniger nutzen.

Prefill und Decode lösen unterschiedliche Rechenprobleme

Die Prompt-Verarbeitung, oft Prefill genannt, wertet die Eingabesequenz aus und erstellt den KV-Zustand, der für die spätere Generierung benötigt wird. Decode beginnt erst, wenn dieser initiale Zustand vorhanden ist, und erweitert die Sequenz Token für Token.

Die Forschung zum LLM-Serving beschreibt rechengebundenes Prefill und speicherbandbreitengebundenes Decode als unterschiedliche Phasen mit jeweils anderem Hardwareverhalten.

Dasselbe Modell kann daher eine hohe Prefill-Durchsatzrate und eine deutlich niedrigere Ausgabetoken-Rate erzielen, ohne dass eine Fehlfunktion vorliegt. Jede Kennzahl zählt Tokens, die einen anderen Ausführungspfad durchlaufen.

Prompt-Tokens können in großen parallelen Matrizen ausgewertet werden

Während des Prefills sind viele Abfragepositionen gleichzeitig verfügbar. Matrixmultiplikationen können die Arbeit über Sequenz, Batch, Köpfe und verborgene Dimensionen hinweg bündeln, sodass der Beschleuniger über genügend parallele Operationen verfügt, um ausgelastet zu bleiben.

FlashAttention reduziert den Overhead der Aufmerksamkeit durch eine gekachelte Aufmerksamkeitsberechnung, bei der die vollständige Aufmerksamkeitsmatrix nicht wiederholt im langsamen Gerätespeicher materialisiert werden muss.

Längere Prompts erhöhen den gesamten Prefill-Aufwand, können aber auch die arithmetische Auslastung verbessern, bis Speicherkapazität, Kernel-Limits oder die Komplexität der Aufmerksamkeit zum dominierenden Faktor werden.

Dies ist der Durchsatz über den Eingabeblock hinweg und bedeutet nicht, dass der Server dieselbe Anzahl unabhängiger Ausgabetokens pro Sekunde erzeugen könnte.

Decode kann das nächste Token nicht vor dem aktuellen abschließen

Bei der autoregressiven Generierung wird ein Token ausgewählt oder gesampelt, an die Sequenz angehängt und anschließend ein weiterer, von diesem akzeptierten Ergebnis abhängiger Modellschritt ausgeführt. Das nächste akzeptierte Token ist nicht im Voraus bekannt.

DistServe trennt die beiden Phasen, weil Decode-Iterationen wiederholt auf Modellgewichte und den aktiven KV-Zustand zugreifen, während sie pro Sequenz nur eine kleine Menge neuer Ausgabe erzeugen.

Das Batching mehrerer Benutzer kann mehrere Decode-Sequenzen parallelisieren, doch eine einzelne Unterhaltung bewegt sich weiterhin durch eine Kette voneinander abhängiger Token-Entscheidungen.

Speculative Decoding kann mehrere entworfene Kandidaten gemeinsam verifizieren, doch das gewöhnliche Decode bleibt seriell, wenn keine Kandidaten im Voraus akzeptiert werden.

Ein hoher Prompt-Durchsatz kann dennoch zu einer langen Verzögerung bis zum ersten Token führen

Tokens pro Sekunde teilen die abgeschlossene Prompt-Verarbeitung durch die Prompt-Größe. Ein sehr langer Kontext kann einen beeindruckenden Durchsatz aufweisen und dennoch mehrere Sekunden benötigen, bevor das erste generierte Token erscheint.

ZimaSpace trennt in seiner Erläuterung der KI-Latenzphasen das Laden, die Prompt-Auswertung und die Generierung. Ein bereits geladenes Modell beseitigt die Verzögerung durch das erneute Laden, nicht jedoch die Kosten für die Auswertung eines großen Prompts.

Die Zeit bis zum ersten Token ist daher das bessere interaktive Maß für das Prefill. Prompt-Tokens pro Sekunde eignen sich zum Vergleich, wie effizient die Laufzeitumgebung Eingaben unterschiedlicher Länge verarbeitet.

Lange Prefills können Benutzer verlangsamen, die bereits Tokens dekodieren

Ein rechenintensiver Dokumenten-Prompt kann denselben Beschleuniger nutzen, während ein anderer Benutzer gestreamte Tokens empfängt. Kombiniert die Laufzeitumgebung beide Workloads ohne Steuerung, kann das große Prefill die Decode-Iterationen verlängern.

DistServe berichtet von starken Prefill-Decode-Interferenzen, wenn beide Phasen gemeinsam auf demselben System platziert und eingeplant werden.

Der Server kann weiterhin eine hohe Gesamtauslastung anzeigen, während der aktive Chat größere Abstände zwischen den Tokens erlebt. Durchsatz und die für Benutzer wahrnehmbare Gleichmäßigkeit können sich in entgegengesetzte Richtungen entwickeln.

Separate Worker, phasenbewusste Planung oder reservierte Decode-Zeitfenster können die interaktive Ausgabe schützen, sofern Hardware und Laufzeitumgebung dies unterstützen.

Chunking tauscht einen Teil der Prefill-Effizienz gegen bessere Reaktionsfähigkeit

Eine Laufzeitumgebung kann einen langen Prompt in kleinere Blöcke aufteilen und diese Blöcke mit Decode-Arbeit verschachteln. Der Prompt benötigt dadurch mehr Planungsschritte, aber kein einzelnes Prefill monopolisiert eine sehr lange Iteration.

Sarathi-Serve nutzt segmentierte Prefills, um Interferenzen zu reduzieren und gleichzeitig sinnvolle Batching-Möglichkeiten aufrechtzuerhalten.

Die optimale Blockgröße hängt von den Prompt-Längen, der Modellarchitektur, der Kapazität des Beschleunigers und dem Latenzziel für aktive Unterhaltungen ab.

Messen Sie die Prompt-Verarbeitungszeit, die Zeit bis zum ersten Token, die Zeit zwischen den Tokens und die Ausgabetokens pro Sekunde separat. Die Phase mit dem niedrigeren angezeigten Durchsatz verursacht nicht automatisch die längste Wartezeit des Benutzers.

Tech- & KI-Zentrum

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.