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

Vilka funktioner möjliggör en AI-förtroendegräns i hemmet runt känsliga filer?
En förtroendegräns för AI i hemmet kombinerar kryptering i vila, behörigheter enligt principen om minsta privilegium, sandlådeförsörjning vid körning och avgränsad informationshämtning – ingen...

Vad gör att privata sökresultat prioriterar filer som redigeras ofta?
Filer som redigeras ofta får rankingfördelar när varje uppdatering lägger till färskhet, delar, versioner eller interaktionssignaler utan att normalisera efter källa.

Vad får modeller för närvaro i smarta hem att förväxla gäster med boende?
Gäster kan se ut som boende när systemet observerar aktivitetsmönster i hushållet men saknar en stabil identitetssignal för personen som ger upphov till dem.

