Waarom kan promptverwerking het lokaal genereren van AI-tokens overtreffen?

Promptverwerking kan het genereren van tokens overtreffen, omdat een accelerator veel invoertokens parallel verwerkt, maar uitvoertokens sequentieel moet decoderen.

Een AI-dashboard voor thuis kan honderden of duizenden prompttokens per seconde rapporteren, terwijl gestreamde uitvoer met een veel lagere snelheid binnenkomt. Die cijfers beschrijven verschillende uitvoeringsfasen en zijn dus niet tegenstrijdig. Prefill verwerkt de aangeleverde context als één blok en bouwt de aandachtstoestand op, terwijl decode het model herhaaldelijk uitvoert om telkens één nieuw token te accepteren. Het verschil hangt af van de promptlengte, modelgrootte, geheugenbandbreedte, batching, cache-indeling en de vraag of achtergrondverzoeken dezelfde accelerator gebruiken.

Prefill en decode lossen verschillende rekenproblemen op

Promptverwerking, vaak prefill genoemd, evalueert de invoerreeks en maakt de KV-toestand aan die nodig is voor latere generatie. Decode begint pas nadat die initiële toestand bestaat en breidt de reeks token voor token uit.

Onderzoek naar LLM-serving beschrijft rekenintensieve prefill en geheugenbandbreedtegebonden decode als afzonderlijke fasen met verschillend hardwaregedrag.

Hetzelfde model kan dus een hoge prefill-doorvoer en een veel lager aantal uitvoertokens produceren zonder dat er iets defect is. Elke metriek telt tokens die een ander uitvoeringspad doorlopen.

Prompttokens kunnen in grote parallelle matrices worden geëvalueerd

Tijdens prefill zijn veel queryposities tegelijk beschikbaar. Matrixvermenigvuldigingen kunnen werk over de reeks, batch, attention-heads en verborgen dimensies combineren, waardoor de accelerator genoeg parallelle bewerkingen heeft om actief te blijven.

FlashAttention vermindert de overhead van attention door middel van getegelde attentionberekening, waarbij wordt voorkomen dat de volledige attentionmatrix herhaaldelijk in traag apparaatgeheugen wordt aangemaakt.

Langere prompts verhogen het totale prefill-werk, maar kunnen ook de benutting van rekenkracht verbeteren totdat geheugencapaciteit, kernelbeperkingen of de complexiteit van attention dominant wordt.

Dit is de doorvoer over het invoerblok, niet een aanwijzing dat de server elke seconde hetzelfde aantal onafhankelijke uitvoertokens zou kunnen produceren.

Decode kan het volgende token niet voltooien voordat het huidige is verwerkt

Autoregressieve generatie selecteert of samplet één token, voegt het aan de reeks toe en voert vervolgens opnieuw een modelstap uit op basis van dat geaccepteerde resultaat. Het volgende geaccepteerde token is niet vooraf bekend.

DistServe behandelt de twee fasen afzonderlijk, omdat decode-iteraties herhaaldelijk modelgewichten en de actieve KV-toestand benaderen, terwijl ze per reeks slechts een kleine hoeveelheid nieuwe uitvoer produceren.

Batching van meerdere gebruikers kan verschillende decodereeksen paralleliseren, maar één gesprek doorloopt nog steeds een keten van onderling afhankelijke tokenbeslissingen.

Speculatieve decoding kan meerdere voorgestelde kandidaten tegelijk verifiëren, maar gewone decode blijft serieel wanneer er vooraf geen kandidaten worden geaccepteerd.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Een hoge promptdoorvoer kan nog steeds leiden tot een lange vertraging tot het eerste token

Tokens per seconde deelt het voltooide promptwerk door de promptgrootte. Een zeer lange context kan een indrukwekkende doorvoer hebben en toch enkele seconden nodig hebben voordat het eerste gegenereerde token verschijnt.

ZimaSpace onderscheidt laden, prompt-evaluatie en generatie in zijn bespreking van AI-latentiefasen. Een warm model verwijdert de vertraging door opnieuw laden, maar niet de kosten van het evalueren van een grote prompt.

De tijd tot het eerste token is daarom de betere interactieve maatstaf voor prefill. Prompttokens per seconde zijn nuttig om te vergelijken hoe efficiënt de runtime verschillende invoerlengtes verwerkt.

Lange prefills kunnen gebruikers die al aan het decoderen zijn vertragen

Een rekenintensieve documentprompt kan dezelfde accelerator gebruiken terwijl een andere gebruiker gestreamde tokens ontvangt. Als de runtime beide workloads zonder controle combineert, kan de grote prefill de decode-iteraties langer maken.

DistServe rapporteert sterke prefill-decode-interferentie wanneer de twee fasen op dezelfde plek worden uitgevoerd en samen worden ingepland.

De server kan nog steeds een hoge totale benutting tonen, terwijl de actieve chat grotere tussenpozen tussen tokens ervaart. Doorvoer en de door de gebruiker ervaren soepelheid kunnen tegengestelde ontwikkelingen laten zien.

Afzonderlijke workers, fasebewuste planning of gereserveerde decode-mogelijkheden kunnen interactieve uitvoer beschermen wanneer de hardware en runtime dit ondersteunen.

Chunking ruilt een deel van de prefill-efficiëntie in voor betere responsiviteit

Een runtime kan één lange prompt opsplitsen in kleinere stukken en deze stukken afwisselen met decodewerk. De prompt vereist dan meer planningsrondes, maar geen enkele prefill monopoliseert één zeer lange iteratie.

Sarathi-Serve gebruikt opgedeelde prefills om interferentie te verminderen en tegelijk nuttige batchingmogelijkheden te behouden.

De optimale chunkgrootte hangt af van promptlengtes, modelarchitectuur, de capaciteit van de accelerator en het latentiedoel voor actieve gesprekken.

Meet promptverwerkingstijd, tijd tot het eerste token, tijd tussen tokens en uitvoertokens per seconde afzonderlijk. De fase met de laagste headline-doorvoer veroorzaakt niet automatisch de langste wachttijd voor de gebruiker.