Vad orsakar luckor i GPU-användningen vid kontinuerlig LLM-batchning?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

What Causes GPU Utilization Gaps During Continuous LLM Batching? - Zima Store Online

Luckor i GPU-utnyttjandet uppstår vanligtvis när schemaläggaren för kontinuerlig batchning inte kan sätta samman körbart arbete eller mata acceleratorn utan ett beroendestopp.

En LLM-server hemma kan rapportera hög genomströmning men ändå visa återkommande GPU-dalar mellan avkodningsiterationer. Kontinuerlig batchning tar bort färdiga sekvenser och släpper in nya, men kan inte skapa arbete när ankomsterna är glesa, KV-block saknas, långa förifyllningar blockerar avkodning eller CPU-körningen förbereder batchar för långsamt. Synkronisering och minnesförflyttningar kan skapa luckor även med en full begärandekö.

Begärandetillförsel och sekvensomsättning kan tömma en batch

Kontinuerlig batchning ersätter färdiga sekvenser vid iterationsgränser. Om ankomsterna sker i stötar, utdata blir färdiga samtidigt eller antagningsgränser håller begäranden utanför den körbara kön, kan antalet aktiva token sjunka under acceleratorns effektiva arbetsområde.

Benchmarktester av kontinuerligt batchmedlemskap jämför statiskt och kontinuerligt begärandemedlemskap med varierande indata- och utdatalängder samt ankomsttider. Signaturen är ett lågt antal körbara token under nyttjandeluckor trots en välfungerande accelerator och utan minnesfel.

En kö som faktiskt är tom är inget fel i schemaläggaren. Jämför ankomsttakt, antagna sekvenser och schemalagda token per iteration innan varje tomt intervall tolkas som förlorad kapacitet. Denna skillnad förblir synlig under senare tester i hemmiljö.

Förifyllning, avkodning och KV-allokering skapar schemaläggningsbubblor

Förifyllning bearbetar många prompttoken med beräkningstunga kärnor, medan avkodning avancerar varje sekvens med en token och ofta är minnesbegränsad. Om faserna blandas kan avkodningen fördröjas, och reservation eller återvinning av KV-block kan pausa antagningen mellan iterationer.

Utformningen för schemaläggning av uppdelad förifyllning använder uppdelad förifyllning för att förhindra att långa promptar monopoliserar serveringsiterationer. Mekanismen identifierar luckor som korrelerar med gränser för förifyllning, KV-allokering eller förhandsbortträngning av begäranden snarare än svag efterfrågan. Mellanresultatet måste förbli granskningsbart innan automatisering följer det.

Om GPU-luckorna växer med promptlängden men inte med utdatalängden är schemaläggning av förifyllningen den starkare orsaken. Om de följer cachetryck eller bortvräkningar är minnesantagningen ansvarig även när kön förblir full. Den gränsen bör mätas separat under realistiska driftförhållanden.

CPU-matning och synkronisering mellan enheter kan svälta kärnor

Tokenisering, sampling, schemaläggarbeslut, tensormetadata, kopieringar från värd till enhet, distribuerade kollektivoperationer och loggning sker utanför huvudkärnorna. En överbelastad CPU-tråd eller en blockerande synkronisering kan lämna GPU:n väntande mellan annars giltiga batchar. Den praktiska konsekvensen uppstår när flera källor konkurrerar om begränsat kontextutrymme.

Forskning om störningar mellan förifyllning och avkodning separerar resurser för förifyllning och avkodning för att minska störningar och uppfylla latensmål. Resultatet understryker att ett enda nyttjandediagram kombinerar schemaläggar-, värd-, kommunikations- och acceleratorbeteende. Detta beroende bör förbli explicit i det slutliga gränssnittet.

Felgränsen är ett kort samplingsintervall som rapporterar normala kärngränser som noll nyttjande. Bekräfta luckor med en spårning eller maskinvaruräknare; medelvärdesbildning i instrumentpanelen kan skapa synliga dalar som inte minskar token per sekund.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Samordna kö-, schemaläggar- och kärntidslinjer

Spela upp kontrollerade jämna ankomster och ankomster i stötar samtidigt som väntande, antagna och körande begäranden, prompt- och avkodningstoken per iteration, lediga KV-block, förhandsbortträngningar, CPU-tid för schemaläggaren, tokenisering, sampling, kopieringar, kollektivoperationer, luckor mellan kärnlanseringar, GPU-klockfrekvenser och utdata-genomströmning registreras.

Jämför mönstret med beteendet hos kontinuerlig batchning och variera sedan ankomsttakt, promptlängd, storlek på uppdelad förifyllning, cachebudget och CPU-affinitet en åt gången. Behåll modell, kvantisering och latensmål oförändrade. Resultatet måste därför kontrolleras mot de ursprungliga beläggen.

Klassificera varje dal som ingen efterfrågan, antagningsstopp, störning från förifyllning, cachetryck, svält på värdsidan eller synkronisering innan justeringar görs. Optimera den ansvariga gränsen; att tvinga fram en större batch kan inte åtgärda en tom kö eller en blockerad värdtråd.