Hur påverkar batchstorleken latensen för första token och per token?
Större batchar förbättrar ofta den totala token-genomströmningen, men de kan öka fördröjningen till den första token och fördröjningen per token genom köbildning, tyngre iterationer och minnesbelastning.
En lokal modell med batchstorlek ett kan utnyttja acceleratorn dåligt eftersom varje avkodningssteg flyttar modellvikter för mycket lite arbete. Genom att kombinera förfrågningar fördelas den förflyttningen över flera förfrågningar och genomströmningen ökar. Samtidigt kan förfrågningar behöva vänta på att släppas in, långa förinläsningar kan blockera avkodning, och varje aktiv sekvens ökar KV-cachen och tokenarbetet. Därför beror den bästa batchstorleken på om målet är genomströmning, responsivitet eller godput inom ett latensmål.
Batchning fördelar modellarbete över flera förfrågningar
En batchad matrisoperation bearbetar token från flera sekvenser tillsammans, vilket förbättrar hårdvaruutnyttjandet och fördelar fasta kostnader för start eller viktöverföring över mer nyttigt arbete. Vinsterna är störst innan beräkningskapacitet, minnesbandbredd, cachekapacitet eller schemaläggningskostnader blir mättade.
Orcas schemaläggning på iterationsnivå inför schemaläggning på iterationsnivå, så att slutförda sekvenser kan lämna och nytt arbete ansluta mellan avkodningsiterationer. Det gör att varje förfrågan inte behöver vänta på den längsta medlemmen i en statisk batch.
Batchstorlek kan avse konfigurerat maximum, insläppta sekvenser eller antal token som bearbetas i en iteration. Dessa värden skiljer sig åt vid kontinuerlig batchning, så prestandarapporter bör ange vilken kvantitet som styrdes och observerades. Denna skillnad förblir synlig under senare tester i hemmet.
Fördröjningen till den första token omfattar köbildning och förinläsning
Tiden till den första token börjar när en förfrågan anländer och omfattar väntan hos schemaläggaren, förinläsning av prompten och det första avkodningssteget. En policy som väntar med att bygga en batch kan öka kötiden, medan en stor prompt kan uppta en iteration och fördröja befintliga interaktiva förfrågningar.
En aktuell jämförelse av kontinuerlig batchning förklarar hur kontinuerlig batchning släpper in och tar bort förfrågningar dynamiskt och hur aggressiv schemaläggning innebär en avvägning mellan genomströmning och TTFT. Den tydliggör varför batchstorleken ensam inte kan förutsäga responsiviteten för den första token. Mellanresultatet måste förbli granskningsbart innan automatiseringen går vidare.
Segmenterad förinläsning kan varva långa promptar med avkodningsarbete, men segmentstorleken blir ytterligare en avvägning. Små segment skyddar interaktiva token men medför mer schemaläggningskostnader; stora segment förbättrar effektiviteten vid förinläsning men skapar längre blockeringsintervall. Den gränsen bör mätas separat under realistiska driftsförhållanden.
Fördröjningen per token beror på den aktiva iterationen
Under avkodning producerar varje steg vanligtvis en token per aktiv sekvens. Fler sekvenser gör batchen större och kan öka varaktigheten för varje iteration, även när den sammanlagda tokenhastigheten ökar. Olikformiga kontexter, cachebelastning, föregripande avbrott och synkronisering i distribuerade system skapar ytterligare variation.
DistServes separering av förinläsning och avkodning skiljer förinläsning från avkodning eftersom de har olika beräkningsegenskaper och servicemål. Designen visar varför optimering av den sammanlagda genomströmningen kan stå i konflikt med både TTFT och tiden per genererad token. Den praktiska konsekvensen märks när flera källor konkurrerar om begränsad kontext.
Felgränsen är att välja den största batchen från ett offline-diagram över genomströmning för en interaktiv hemassistent. Om köbildning eller tokengap bryter mot användarmålet är den nominella genomströmningen inte användbar godput, oavsett acceleratorutnyttjande.
Kartlägg fronten för batchgodput
Spela upp korta chattar, långa RAG-promptar och bakgrundsjobb vid kontrollerade ankomsthastigheter. Variera maximalt antal sekvenser och gränserna för batchade token medan du mäter percentiler för TTFT, latens mellan token, latens från början till slut, genomströmning för promptar och utdata, ködjup, cacheanvändning, föregripande avbrott och avvisade förfrågningar.
Använd beteendet vid kontinuerlig batchning i beteendet vid kontinuerlig batchning för att skilja konfigurerade gränser från den aktiva batch som varje iteration ser. Håll fördelningarna för promptar och utdata fasta och rapportera andelen förfrågningar som uppfyller både målen för den första token och tokengap.
Välj den inställning som maximerar slutfört arbete inom dessa mål i stället för rå tokenhastighet per sekund. Isolera eller ge bakgrundsbatcher lägre prioritet när de minskar den interaktiva godputen, och testa på nytt efter ändringar av modell, kvantisering, kontextblandning eller schemaläggare.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Kan en lokal LLM återuppta genereringen efter att dess process startats om?
En mekanismförst-förklaring av hur LLM-generering återupptas, avvägningarna kring delade resurser, tre vanliga frågor om frågeförgrening samt ett praktiskt verifieringsprotokoll.
Kan en hemserver köra embeddings och videotranskodning på samma integrerade GPU?
En mekanismfokuserad förklaring av delade iGPU-inbäddningar och omkodning, avvägningar kring delade resurser, tre vanliga frågor om frågefanout och en praktisk verifiering.
Hur påverkar åtkomsttokenets livslängd säkerheten och besvären i hushållet?
En mekanism-först-förklaring av åtkomsttokeners livslängd, avvägningarna kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
