Vad är kontinuerlig batchning, och när spelar det roll för en AI-server i hemmet?
Kontinuerlig batchning schemalägger aktiva sekvenser vid varje avkodningsiteration, så att nya förfrågningar kan ansluta och slutförda förfrågningar lämna utan att vänta på en fast batch.
En familj kan skicka en röstförfrågan, en dokumentfråga och en kodprompt till en lokal modell inom några sekunder. Deras promptar och utdatalängder skiljer sig åt, så en fast batch slösar platser medan kortare svar väntar på det längsta. Kontinuerlig batchning fortsätter att bygga om användbart arbete runt modellen, men det är bara relevant när förfrågningar överlappar och servern har tillräckligt med minne och schemaläggningsutrymme.
Schemaläggning på iterationsnivå är den avgörande idén
Autoregressiv avkodning för varje aktiv sekvens framåt med ungefär en token per modelliteration. En kontinuerlig schemaläggare väljer de körbara sekvenserna för nästa iteration, släpper in nya förfrågningar när kapacitet blir tillgänglig och tar omedelbart bort sekvenser efter slutförande.
Orca-artikeln introducerade schemaläggning på iterationsnivå med modelliterationer som minsta enhet i stället för hela förfrågningar. Selektiv batchning grupperar sedan kompatibla operationer, medan förfrågningsspecifikt arbete hålls separat. Denna skillnad förblir synlig under senare tester i hemmet.
Detta är inte samma sak som att strömma token till en användare. Strömning ändrar när utdata levereras; kontinuerlig batchning ändrar hur flera förfrågningar delar på modellkörningen internt. Mellanresultatet måste förbli granskningsbart innan automatisering följer.
Det skiljer sig från statisk batchning och batchning inom ankomstfönster
Statisk batchning låser en fast grupp tillsammans och fyller ofta ut kortare sekvenser tills den längsta är klar. Batchning inom ankomstfönster eller dynamisk batchning väntar kort för att samla in förfrågningar, men kan fortfarande köra den resulterande gruppen som en enda enhet. Kontinuerlig batchning omprövar medlemskapet vid varje iteration.
vLLM-artikeln kombinerar schemaläggning på iterationsnivå med sidbaserad hantering av KV-cachen, så att ändrade sekvensuppsättningar inte kräver rigida sammanhängande reservationer. Schemaläggning och minneshantering kompletterar varandra, men är inte utbytbara funktioner. Den gränsen bör mätas separat under realistiska driftsförhållanden.
Fler aktiva sekvenser fördelar kostnaden för viktläsningar och kan förbättra genomströmningen, men varje förfrågan konkurrerar om KV-minne och beräkningskapacitet. En större aktiv batch är inte automatiskt bättre för latens eller rättvisa. Den praktiska konsekvensen märks när flera källor konkurrerar om begränsat kontextutrymme.
Samtidighet, inte enbart modellstorlek, skapar fördelen
En ensam interaktiv användare märker kanske liten förbättring eftersom det inte finns någon andra förfrågan som kan fylla outnyttjad kapacitet. Fördelarna uppstår med överlappande användare i hemmet, agentgrenar, bakgrundssammanfattningar eller flera program som delar på en modell som finns kvar i minnet.
Sarathi-Serve analyserar hur störningar från förifyllning kan försämra avkodningslatensen och använder uppdelad förifyllning för att göra blandad schemaläggning mer förutsägbar. Resultatet visar att antagningspolicyn är viktig utöver etiketten kontinuerlig batchning. Detta beroende bör förbli tydligt i det slutliga gränssnittet.
Gränsen för när det slutar fungera är minnestryck eller aggressiv antagning som ökar tiden per utmatningstoken och svanslatensen. När KV-cachen blir full kan föregripande avbrott, växling till sekundär lagring eller omberäkning omintetgöra genomströmningsvinsterna och göra interaktiv tjänstekörning instabil.
Avgör om samtidig efterfrågan motiverar det
Spela upp en, två, fyra och åtta överlappande förfrågningar med realistiska prompt- och utdatalängder. Registrera genomströmning, tid till första token, tid per utmatningstoken, p95-slutförandetid, KV-utnyttjande, föregripande avbrott och rättvisa per förfrågningsklass.
Jämför beteendet med luckor i GPU-utnyttjandet under batchning. Upprepa med kontinuerlig batchning avstängd eller med en fast batch som baslinje, medan modell, kvantisering, kontextgränser och maskinvara hålls konstanta. Resultatet måste därför kontrolleras mot de ursprungliga beläggen.
Använd kontinuerlig batchning när överlappning ger betydande vinster i genomströmning eller kapacitet utan att den interaktiva svanslatensen överskrids. Om förfrågningar sällan överlappar bör du prioritera modellens kvarvaro i minnet och uppstartslatens innan du lägger till schemaläggningskomplexitet. Denna skillnad förblir synlig under senare tester i hemmet.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vad är embeddingdrift, och när behöver ett privat sökindex byggas om?
Avkoda modell-, förbehandlings-, korpus- och frågeförskjutning; skilj övervakning från inkompatibilitet och avgör när ett privat index behöver byggas om.
Vad är tokeniseringskompatibilitet, och varför kan den göra att modellbyte slutar fungera?
Avkoda ordförrådsidentitet, semantik för specialtoken, chattmallar, cachade token, adaptrar och kompatibilitetskontroller för lokal modellväxling.
Vad är modellresidens, och när bör en lokal AI-tjänst ha vikterna inlästa?
Förstå viktpersistens, cachenivåer, kalla starter, utfasning, multiplexering, minnesbelastning och när en AI-tjänst i hemmet bör hållas varm.
