Was ist die Disaggregation von Prefill und Decode, und warum verändert sie die Bereitstellung von LLMs?
Die Disaggregation von Prefill und Decoding trennt die Prompt-Verarbeitung von der Token-Generierung, sodass jede LLM-Phase unterschiedliche Worker, Zeitpläne und Kapazitätspläne verwenden kann.
Ein langer RAG-Prompt erfordert vor seinem ersten Token einen großen Rechenstoß, während das Decoding anschließend viele kleinere, speicherbandbreitensensitive Iterationen ausführt. Beide Phasen auf einer GPU auszuführen ist einfach, ermöglicht es langen Prefills jedoch, aktive Gespräche zu unterbrechen. Die Disaggregation verschiebt die Anfrage und ihren KV-Zustand zwischen Pools und tauscht zusätzliche Koordinations- und Transferkosten gegen eine unabhängige Steuerung der Latenz bis zum ersten Token und der Latenz pro Token ein.
Prefill und Decoding haben unterschiedliche Ressourcenprofile
Beim Prefill werden alle Prompt-Tokens parallel verarbeitet und der KV-Cache aufgebaut. Dadurch entsteht ein rechenintensiver Burst, dessen Dauer mit der Prompt-Länge wächst. Beim Decoding werden wiederholt Modellgewichte und der angesammelte KV-Zustand gelesen, um jeweils ein oder wenige neue Tokens zu generieren.
DistServe beschreibt Interferenzen zwischen Prefill und Decoding, wenn beide Phasen GPUs gemeinsam nutzen, und verknüpft Prefill mit der Zeit bis zum ersten Token, während Decoding die Zeit pro Ausgabetoken bestimmt. Durch die Trennung kann der Scheduler jedes Ziel unabhängig schützen. Dieser Unterschied bleibt auch bei späteren Tests im Haushalt sichtbar.
Disaggregation ist nicht dasselbe wie gewöhnlicher Modellparallelismus. Dasselbe Modell kann in beiden Pools vorhanden sein, während Anfragen zwischen funktionalen Phasen und nicht zwischen Schichten eines einzelnen Forward-Passes verschoben werden. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung fortgesetzt wird.
Der KV-Transfer verbindet die beiden Worker-Pools
Nach dem Prefill muss das System den KV-Cache der Anfrage einem Decode-Worker verfügbar machen. Es kann Tensoren über PCIe oder ein Netzwerkfabric übertragen, Shared Memory verwenden oder Worker so platzieren, dass die Transferkosten minimiert werden.
Splitwise untersucht phasenbezogenes Serving mit phasenspezifischen Maschinen und Scheduling und zeigt, warum die Hardwarezuweisung an die unterschiedlichen Recheneigenschaften von Prompt- und Token-Verarbeitung angepasst werden kann. Warteschlangen und Zustandsübertragung werden damit zu einem Teil des Serving-Pfads. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.
Der Decode-Pool kann erst starten, wenn er über einen konsistenten KV-Zustand und die Metadaten der Anfrage verfügt. Große Kontexte erhöhen die Anzahl der zu übertragenden Bytes, sodass eine nominell schnellere Phasentrennung in einem kleinen Heimnetzwerk gegenüber einer lokal ausgeführten Verarbeitung verlieren kann.
Unabhängige Skalierung verändert die Kapazitätsplanung
Getrennte Pools können zusätzliche Prefill-Kapazität für Bursts mit langen Dokumenten bereitstellen, ohne die Decode-Kapazität proportional zu erweitern, oder das Decoding von Sprache schützen, während die Hintergrundzusammenfassung Prompt-Worker beansprucht. Die Zulassungssteuerung kann zwei Warteschlangen und zwei Latenzbudgets berücksichtigen. Die praktische Folge zeigt sich, wenn mehrere Quellen um begrenzten Kontext konkurrieren.
Mooncake beschreibt eine Koordination des KV-Caches, die die Übertragung und Speicherung des KV-Caches als zentrale Aspekte des Servings behandelt. Die Architektur verdeutlicht, dass Disaggregation den Engpass von der reinen GPU-Planung hin zur Zustandsübertragung und Cache-Koordination verschiebt.
Die Fehlergrenze liegt bei unzureichender Skalierung oder Bandbreite. Ein oder zwei GPUs zu Hause bieten möglicherweise kein freies Gerät für eine Spezialisierung, und doppelte Modellgewichte sowie KV-Transfers können mehr Speicher und Latenz verbrauchen als die dadurch beseitigte Interferenz.
Vergleiche die Phasenbudgets bei lokaler und disaggregierter Ausführung
Miss Prompt-Tokens pro Sekunde, die Zeit bis zum ersten Token, die Zeit pro Ausgabetoken, übertragene KV-Bytes, Transferzeit, Wartezeit in der Warteschlange, doppelte Modellbelegung im Speicher, Energieverbrauch und Fehlerwiederherstellung für kurze, lange und gemischte Prompts. Diese Abhängigkeit sollte in der finalen Benutzeroberfläche ausdrücklich erhalten bleiben.
Verwende Chunked Prefill als lokal ausgeführte Alternative. Teste Chunked Prefill, bevor du einen zweiten Pool hinzufügst, und vergleiche anschließend identische Ankunftsverläufe unter beiden Architekturen. Das Ergebnis muss daher anhand der ursprünglichen Belege überprüft werden.
Führe Disaggregation nur ein, wenn Interferenzen zwischen den Phasen gemessen wurden und der Transferpfad beide Latenzziele erfüllt. Auf einem kleinen Server kann lokales Scheduling mit begrenzten Prefill-Blöcken dasselbe Nutzerergebnis mit weniger Zustandsübertragungen liefern.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Was ist Embedding-Drift, und wann muss ein privater Suchindex neu erstellt werden?
Entschlüsseln Sie Modell-, Vorverarbeitungs-, Korpus- und Abfragedrift, unterscheiden Sie zwischen Überwachung und Inkompatibilität und entscheiden Sie, wann ein privater Index neu erstellt werden muss.
Was ist Tokenizer-Kompatibilität, und warum kann sie den Modellwechsel beeinträchtigen?
Entschlüsseln Sie Vokabularidentität, die Semantik spezieller Token, Chatvorlagen, zwischengespeicherte Token, Adapter und Kompatibilitätsprüfungen für den Wechsel lokaler Modelle.
Was ist Modellresidenz, und wann sollte ein lokaler KI-Dienst die Gewichte geladen lassen?
Entschlüsseln Sie Gewichtsspeicherort, Cache-Ebenen, Kaltstarts, Verdrängung, Multiplexing, Speicherdruck und wann ein KI-Dienst zu Hause warm bleiben sollte.
