Vad är separering av prefill och avkodning, och varför förändrar det LLM-servering?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

What Is Prefill-Decode Disaggregation, and Why Does It Change LLM Serving?

Uppdelning av förifyllning och avkodning separerar promptbearbetning från token-generering så att varje LLM-fas kan använda olika arbetare, scheman och kapacitetsplaner.

En lång RAG-prompt kräver en stor beräkningsburst före sin första token, medan avkodningen därefter utför många mindre iterationer som är känsliga för minnesbandbredd. Att köra båda faserna på samma GPU är enkelt, men gör att långa förifyllningar kan avbryta aktiva konversationer. Uppdelning flyttar begäran och dess KV-tillstånd mellan pooler och byter extra samordning och överföringskostnad mot oberoende kontroll över latensen för första token och per token.

Förifyllning och avkodning har olika resursprofiler

Förifyllning bearbetar alla promptens token parallellt och bygger KV-cachen, vilket skapar en beräkningsintensiv burst vars varaktighet ökar med promptens längd. Avkodning läser upprepade gånger modellvikter och det ackumulerade KV-tillståndet för att generera en eller några nya token.

DistServe identifierar störningar mellan förifyllning och avkodning när båda faserna delar GPU:er och kopplar förifyllning till tiden till första token, medan avkodning styr tiden per utmatad token. Genom att separera dem kan schemaläggaren skydda varje mål oberoende. Denna skillnad förblir synlig under senare tester i hemmet.

Uppdelning är inte vanlig modellparallellism. Samma modell kan finnas i båda poolerna, medan begäranden flyttas mellan funktionella faser i stället för mellan lager i en enda framåtpassering. Mellanresultatet måste förbli inspekterbart innan automatisering följer efter.

KV-överföring kopplar samman de två arbetar-poolerna

Efter förifyllningen måste systemet göra begärans KV-cache tillgänglig för en avkodningsarbetare. Det kan överföra tensorer över PCIe eller ett nätverksfabric, använda delat minne eller placera arbetare för att minimera förflyttningskostnaden.

Splitwise studerar fasspecifik servering med fasspecifika maskiner och schemaläggning och visar varför hårdvarutilldelningen kan anpassas till de olika beräkningsmässiga egenskaperna hos prompt- och tokenarbete. Köbildning och tillståndsförflyttning blir en del av serveringsvägen. Den gränsen bör mätas separat under realistiska driftsförhållanden.

Avkodningspoolen kan inte starta förrän den har ett konsekvent KV-tillstånd och metadata för begäran. Stora kontexter ökar antalet överförda byte, så en nominellt snabbare fasesplit kan förlora mot samlokaliserad körning i ett litet hemnätverk.

Oberoende skalning förändrar kapacitetsplaneringen

Separata pooler kan lägga till förifyllningskapacitet för toppar med långa dokument utan att avkodningskapaciteten behöver utökas proportionellt, eller skydda röstavkodning medan bakgrundssummering använder promptarbetare. Antagningskontroll kan inriktas på två köer och två latensbudgetar. Den praktiska konsekvensen blir synlig när flera källor konkurrerar om begränsad kontext.

Mooncake beskriver en KV-cache-samordning som behandlar förflyttning och lagring av KV-cache som centrala frågor för servering. Arkitekturen visar att uppdelning flyttar flaskhalsen från ren GPU-schemaläggning mot tillståndsöverföring och cache-samordning.

Felgränsen är otillräcklig skala eller bandbredd. En eller två GPU:er i hemmet kanske inte har någon ledig enhet för specialisering, och duplicerade modellvikter plus KV-överföring kan förbruka mer minne och latens än de störningar som tas bort.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Jämför fasbudgetar för samlokaliserad och uppdelad körning

Mät prompttoken per sekund, tid till första token, tid per utmatad token, överförda KV-byte, överföringstid, väntetid i kö, duplicering av modellminne, energi och återställning efter fel för korta, långa och blandade promptar. Detta beroende bör förbli explicit i det slutliga gränssnittet.

Använd delad förifyllning som det samlokaliserade alternativet. Testa delad förifyllning innan en andra pool läggs till och jämför sedan identiska ankomstspår i båda arkitekturerna. Resultatet måste därför kontrolleras mot de ursprungliga bevisen.

Inför uppdelning endast när fasstörningar har uppmätts och överföringsvägen bevarar båda latensmålen. På en liten server kan samlokaliserad schemaläggning med begränsade förifyllningssegment ge samma användarresultat med mindre tillståndsförflyttning.