Varför kan promptbearbetning gå snabbare än lokal AI-token­generering?

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.

Promptbearbetning kan gå snabbare än tokengenerering eftersom en accelerator utvärderar många indatatoken parallellt, medan utdatatoken måste avkodas sekventiellt.

En AI-instrumentpanel för hemmet kan visa hundratals eller tusentals prompttoken per sekund, medan det strömmade resultatet kommer med betydligt lägre hastighet. Dessa siffror beskriver olika körningsfaser, inte motstridiga mätningar. Prefill bearbetar den angivna kontexten som ett block och bygger upp uppmärksamhetstillståndet, medan decode upprepade gånger kör modellen för att ta emot en ny token i taget. Skillnaden beror på promptens längd, modellens storlek, minnesbandbredd, batchning, cache-layout och om bakgrundsbegäranden delar samma accelerator.

Prefill och decode löser olika beräkningsproblem

Promptbearbetning, ofta kallad prefill, utvärderar indatasekvensen och skapar det KV-tillstånd som behövs för den fortsatta genereringen. Decode startar först när detta initiala tillstånd finns och utökar sekvensen token för token.

Forskning om LLM-serverdrift beskriver beräkningsbunden prefill och minnesbandbreddsbegränsad decode som separata faser med olika hårdvarubeteende.

Samma modell kan därför uppvisa hög genomströmning vid prefill och betydligt lägre hastighet för utdatatoken utan att något är fel. Varje mätvärde räknar token som passerar genom en annan körningsväg.

Prompttoken kan utvärderas i stora parallella matriser

Under prefill finns många frågepositioner tillgängliga samtidigt. Matrismultiplikationer kan kombinera arbete över sekvensen, batchen, huvudena och de dolda dimensionerna, vilket ger acceleratorn tillräckligt många parallella operationer för att hållas sysselsatt.

FlashAttention minskar uppmärksamhetsberäkningens omkostnader genom blockindelad uppmärksamhetsberäkning som undviker att upprepade gånger materialisera hela uppmärksamhetsmatrisen i enhetens långsamma minne.

Längre promptar ökar det totala prefill-arbetet, men kan också förbättra det aritmetiska utnyttjandet tills minneskapacitet, kärnbegränsningar eller uppmärksamhetsberäkningens komplexitet blir dominerande.

Detta är genomströmning över indatablocket och betyder inte att servern kan generera samma antal oberoende utdatatoken varje sekund.

Decode kan inte färdigställa nästa token innan den aktuella token är klar

Autoregressiv generering samplar eller väljer en token, lägger till den i sekvensen och kör sedan ytterligare ett modellsteg baserat på det accepterade resultatet. Nästa accepterade token är inte känd i förväg.

DistServe skiljer mellan de två faserna eftersom decode-iterationer upprepade gånger läser modellvikter och aktivt KV-tillstånd, samtidigt som de bara producerar en liten mängd nytt resultat per sekvens.

Batchning av flera användare kan parallellisera flera decode-sekvenser, men en enskild konversation går fortfarande framåt genom en kedja av beroende tokenbeslut.

Spekulativ avkodning kan verifiera flera föreslagna kandidater tillsammans, men vanlig decode förblir seriell när inga kandidater accepteras i förväg.

Hög promptgenomströmning kan ändå ge lång tid till första token

Token per sekund beräknas genom att det färdiga promptarbetet divideras med promptens storlek. En mycket lång kontext kan ha imponerande genomströmning och ändå ta flera sekunder innan den första genererade token visas.

ZimaSpace skiljer mellan inläsning, promptutvärdering och generering i sin genomgång av AI-fördröjningsfaser. En varm modell eliminerar omladdningsfördröjningen, men inte kostnaden för att utvärdera en stor prompt.

Tid till första token är därför det bättre interaktiva måttet för prefill. Prompttoken per sekund är användbart för att jämföra hur effektivt körmiljön bearbetar indatasekvenser av olika längd.

Långa prefill-faser kan göra användare som redan får resultat långsammare

En beräkningstung dokumentprompt kan använda samma accelerator samtidigt som en annan användare får strömmade token. Om körmiljön kombinerar båda arbetsbelastningarna utan styrning kan den stora prefill-fasen förlänga decode-iterationerna.

DistServe rapporterar omfattande störningar mellan prefill och decode när de två faserna placeras på samma accelerator och schemaläggs tillsammans.

Servern kan fortfarande visa hög total resursanvändning, men den aktiva chatten upplever längre mellanrum mellan token. Genomströmning och upplevd smidighet kan utvecklas åt motsatta håll.

Separata arbetare, fasmedveten schemaläggning eller reserverade decode-möjligheter kan skydda interaktiv output när hårdvaran och körmiljön stöder detta.

Blockindelning byter en del prefill-effektivitet mot bättre responsivitet

En körmiljö kan dela upp en lång prompt i mindre block och varva dessa block med decode-arbete. Prompten kräver fler schemaläggningsomgångar, men ingen enskild prefill-fas monopoliserar en mycket lång iteration.

Sarathi-Serve använder blockindelad prefill för att minska störningar och samtidigt behålla användbara batchningsmöjligheter.

Den bästa blockstorleken beror på promptlängder, modellarkitektur, acceleratorns kapacitet och vilket fördröjningsmål som gäller för aktiva konversationer.

Mät promptbearbetningstid, tid till första token, tid mellan token och utdatatoken per sekund separat. Fasen med den lägre genomströmningen är inte automatiskt den fas som orsakar användarens längsta väntan.

Teknik- och AI-hubb

Mer att läsa

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.