Prefill versus decode: waarom LLM-inference twee fasen heeft
Automatische vertaling
Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
Prefill verwerkt een prompt en maakt de attention-cache ervan aan. Decode gebruikt die cache om volgende tokens te genereren. Lange prefill of prefill in batches kan grote matrixbewerkingen efficiënt benutten; decode met kleine batches besteedt vaak meer tijd aan het lezen van weights en gecachte sleutels en waarden.
Dit onderscheid helpt engineers om een traag eerste token los te onderzoeken van de trage generatie daarna.
Bepaal welke fase traag is
Gewone autoregressieve prefill produceert de logits waaruit het eerste uitvoertoken wordt gesampled. Latere decode-stappen voegen telkens één token toe. De tijd tot het eerste token omvat ook wachttijd, tokenization, planning en levering via het netwerk. Een hoge TTFT bewijst dus niet dat prefill zelf traag is.
| Symptoom | Meet dit voordat je de server wijzigt |
|---|---|
| Het eerste token verschijnt later bij langere prompts | Wachttijd en prefill-duur per invoerlengte |
| Latere tokens vertragen bij langere geschiedenissen | Decode-tijd en Verkeer van de KV cache |
| Een lange nieuwe prompt onderbreekt andere streams | Iteraties van de scheduler en intervallen tussen tokens |
| Aparte servers besteden tijd aan het overdragen van toestand | Overgedragen KV-bytes, bandbreedte en wachttijd |
Prefill hergebruikt weights voor meerdere prompt-tokens. De implementatie kan matrixblokken nog steeds meerdere keren laden; ze garandeert niet dat elke weight letterlijk maar één keer uit HBM wordt gelezen. Splitwise beschrijft hoe deze fasen verschillende hardwarebronnen gebruiken.
Wat prefill in chunks verandert
Prefill in chunks verwerkt een lange prompt over meerdere iteraties van de scheduler. De gedocumenteerde scheduler van vLLM laat eerst lopende decode-verzoeken toe en gebruikt het resterende tokenbudget van de iteratie voor prefill. De werkelijke grootte van de chunk volgt uit het beschikbare budget.
Dit kan onderbrekingen van bestaande streams verminderen en tegelijk de TTFT van het nieuwe verzoek verhogen. Kleinere chunks voegen ook planningswerk toe en lezen eerdere cachetoestand opnieuw. Sarathi-Serve onderzoekt deze afweging; de ongeveer 25% extra prefill-tijd bij chunks van 512 tokens werd gemeten voor Yi-34B met tensorparallellisme van twee.
Disaggregated serving plaatst prefill en decode daarentegen op aparte GPU-pools. Het kan elke fase onafhankelijk afstemmen, maar moet de KV cache van het verzoek overdragen. Controleer de overdrachtskosten en het gebruik van de pools voordat je dit ontwerp toepast. Chunking wijzigt de scheduler; disaggregatie verandert ook deployment en communicatie.
Engineeringgids: prefill versus decode bevat tijdlijnen voor beide benaderingen.