Hur påverkar kontinuerlig batchning rättvisan på en AI-server för hemmet?
Kontinuerlig batchning förbättrar resursutnyttjandet genom att fylla på aktiva batcher, men rättvisa beror på hur användarna får tillgång till resurser, tokenbearbetning och minne över tid.
En AI-server i hemmet kan hantera flera konversationer utan att vänta på att alla sekvenser ska slutföras samtidigt. Slutförda begäranden lämnar kön, nya begäranden tillkommer och aktiva användare delar på upprepade inferensiterationer. Det ökar genomströmningen, men begärandena är inte likvärdiga: en användare kanske skickar ett kort kommando, en annan ett långt dokument och en tredje en agent som genererar hundratals token. En rättvis schemaläggare måste avgöra vilken arbetsenhet som ska räknas, hur nya begäranden tas in och hur prioriteringar ska samverka med oförutsägbara utdatalängder.
Kontinuerlig batchning ändrar schemaläggningsenheten från en fast batch till iterationer
Statisk batchning håller ihop en grupp tills hela gruppen är klar, vilket slösar kapacitet när korta begäranden blir färdiga tidigt. Kontinuerlig batchning kan fylla på lediga platser mellan genereringsiterationerna.
Orca introducerade schemaläggning på iterationsnivå så att begäranden kan ansluta och lämna när deras sekvenstillstånd förändras.
Det förbättrar resursutnyttjandet, men innebär också att användarna upprepade gånger konkurrerar om en plats i nästa iteration i stället för att få en enda odelbar plats för begäran.
Intagningsordningen avgör vem som börjar samla på sig tilldelad bearbetningstid
En begäran utanför den aktiva batchen får ingen modellbearbetning. Schemaläggaren kan ta in begäranden efter ankomsttid, uppskattad längd, prioritet, tillgängliga KV-block eller en rättviseräknare.
vLLM kombinerar kontinuerligt intag med hantering av sidindelad KV-cache så att minne kan tilldelas när sekvenserna växer.
Först till kvarn är enkelt, men en kö med långa begäranden kan försena senare korta kommandon i hemmet, även när dessa skulle bli färdiga snabbt.
Att räkna begäranden lika kan ge ojämlik acceleratorbearbetning
Ett svar på fem token och ett svar på femhundra token är båda en begäran, men de upptar mycket olika antal avkodningsiterationer. Även promptlängder medför olika mängder förbearbetning.
Virtual Token Counter definierar tokenbaserad rättvisa, eftersom antalet begäranden inte ensamt representerar den bearbetning som förbrukas av heterogena LLM-arbetsbelastningar.
En hushållspolicy bör avgöra om rättvisa innebär lika mycket tokenarbete, lika lång väntetid, lika möjlighet att slutföras eller prioritet för fördröjningskänsliga uppgifter.
Inget enskilt mått passar alla arbetsbelastningar. Ett röstkommando och en sammanfattning i bakgrunden bör inte nödvändigtvis behandlas identiskt.
Okänd utdatalängd gör framtida bearbetning svår att förutsäga
Schemaläggaren känner till promptens storlek när begäran tas in, men vet vanligtvis inte exakt hur många utgående token modellen kommer att generera. En begäran kan förbli aktiv betydligt längre än väntat.
Forskning om rättvisa lyfter fram oförutsägbara begärandelängder som en särskild utmaning vid LLM-serverdrift.
Att debitera bearbetning allt eftersom token faktiskt behandlas undviker att helt förlita sig på en dålig längduppskattning, men kan ändå låta en lång begäran uppta minne under många iterationer.
Omfattande förbearbetning kan störa användare som redan får token
En ny dokumentprompt kan tas in medan flera användare avkodar. Den beräkningsintensiva förbearbetningen kan förlänga den iteration som aktiva konversationer måste vänta igenom.
Sarathi-Serve använder schemaläggning utan stopp för att dela upp omfattande förbearbetning och minska dess påverkan på den pågående avkodningsfördröjningen.
En schemaläggare som bara räknar avkodningstoken kan ändå vara orättvis om en användare upprepade gånger introducerar omfattande förbearbetning som fördröjer allas strömmade utdata.
En rättvis redovisning bör därför omfatta både inmatningsbearbetning och genererade token.
Minnebrist kan skapa rättviseproblem innan beräkningskapaciteten är fullt utnyttjad
Varje aktiv konversation behöver KV-cache, och längre kontexter förbrukar fler block. En användare med en enda stor kontext kan minska antalet andra begäranden som får plats i den aktiva batchen.
ZimaSpaces analys av användning av flera användare kopplar användning av flera användare i hemmet till delat modellminne och schemaläggarens beslut.
Att tillfälligt avbryta eller flytta en begäran kan återställa kapacitet, men den avbrutna användaren kan senare behöva betala med omberäkning, omladdning av cache eller längre slutförandetid.
Minneintagning och beräkningsschemaläggning måste därför följa samma rättvisepolicy i stället för att fungera som oberoende begränsningar.
Prioriteringar behöver åldrande, kvoter och mätvärden som användarna kan se
Röststyrning, hjälpmedel och korta interaktiva chattar kan förtjäna högre prioritet än embedding-bearbetning eller sammanfattningar över natten. Ren prioritetsschemaläggning kan ändå svälta ut arbete med låg prioritet.
Llumnix använder dynamisk schemaläggning för att anpassa placeringen av begäranden och resursbesluten när serverförhållandena förändras.
Lägg till åldrande, kvoter per användare, gränser för maximal kontext eller maximal utdatalängd samt en reserverad andel för bakgrundsarbete, så att prioriterat arbete svarar snabbt utan att blockera allt annat på obestämd tid.
Mät kötid, tid till första token, fördröjning mellan token, slutförandetid, antal levererade token och avbrott per användare eller arbetsbelastningsklass. Kontinuerlig batchning är bara rättvis när den observerade fördelningen motsvarar hushållets policy, inte enbart när det totala antalet token per sekund är högt.
Rekommenderade produkter
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.
