Wat veroorzaakt hiaten in GPU-benutting tijdens continue batching van LLM's?

Hiaten in GPU-benutting ontstaan meestal wanneer de scheduler voor continuous batching geen uitvoerbaar werk kan samenstellen of de accelerator niet kan voeden zonder een afhankelijkheidsblokkade.

Een thuisserver voor LLM's kan een hoge doorvoer rapporteren en toch periodieke GPU-dalen tussen decode-iteraties laten zien. Continuous batching verwijdert voltooide reeksen en laat nieuwe toe, maar kan geen werk creëren wanneer aanvragen schaars binnenkomen, KV-blokken niet beschikbaar zijn, lange prefills decode blokkeren of de CPU-runtime batches te langzaam voorbereidt. Synchronisatie en geheugenverplaatsingen kunnen hiaten veroorzaken, zelfs wanneer de aanvraagwachtrij vol is.

Aanvoerstroom van aanvragen en het wisselen van reeksen kunnen een batch leegmaken

Continuous batching vervangt voltooide reeksen aan de grenzen van iteraties. Als aanvragen in pieken binnenkomen, uitvoer gelijktijdig wordt voltooid of toelatingslimieten aanvragen buiten de uitvoerbare wachtrij houden, kan het aantal actieve tokens onder het efficiënte werkingsbereik van de GPU dalen.

Benchmarks van lidmaatschap van continuous batches vergelijken statisch en continu lidmaatschap van aanvragen bij uiteenlopende invoerlengtes, uitvoerlengtes en aankomsttijden. Het kenmerk is een laag aantal uitvoerbare tokens tijdens hiaten in het gebruik, ondanks een gezonde accelerator en zonder geheugenfout.

Een wachtrij die echt leeg is, is geen fout in de scheduler. Vergelijk de aankomstsnelheid, toegelaten reeksen en per iteratie geplande tokens voordat je elk interval van inactiviteit interpreteert als verloren capaciteit. Dit onderscheid blijft zichtbaar tijdens latere tests in de thuisomgeving.

Prefill, decode en KV-toewijzing veroorzaken luchtbellen in de scheduler

Prefill verwerkt veel prompttokens met rekenintensieve kernels, terwijl decode elke reeks met één token vooruitbrengt en vaak geheugenbeperkt is. Het mengen van deze fasen kan decode vertragen, en het reserveren of vrijgeven van KV-blokken kan de toelating tussen iteraties pauzeren.

Het ontwerp voor chunked-prefillplanning gebruikt chunked prefill om te voorkomen dat lange prompts serveeriteraties monopoliseren. Het mechanisme identificeert hiaten die correleren met prefillgrenzen, KV-toewijzing of het onderbreken van aanvragen, in plaats van met een zwakke vraag. Het tussenresultaat moet inspecteerbaar blijven voordat automatisering het opvolgt.

Als GPU-hiaten toenemen met de promptlengte maar niet met de uitvoerlengte, is prefillplanning de waarschijnlijkere oorzaak. Als ze de cachebelasting of verwijderingen volgen, is geheugentoelating verantwoordelijk, zelfs wanneer de wachtrij vol blijft. Die grens moet afzonderlijk worden gemeten onder realistische gebruiksomstandigheden.

CPU-aanvoer en synchronisatie tussen apparaten kunnen kernels uithongeren

Tokenisatie, sampling, schedulerbeslissingen, tensormetadata, kopieën van host naar apparaat, gedistribueerde collectives en logging vinden buiten de hoofdkernels plaats. Een verzadigde CPU-thread of blokkerende synchronisatie kan ervoor zorgen dat de GPU tussen verder geldige batches blijft wachten. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen om beperkte context concurreren.

Onderzoek naar interferentie tussen prefill en decode scheidt prefill- en decoderesources om interferentie te verminderen en latentiedoelen te halen. Het resultaat benadrukt dat één gebruiksgrafiek het gedrag van scheduler, host, communicatie en accelerator combineert. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.

De foutgrens is een korte bemonsteringsinterval waarin normale kernelgrenzen als nulgebruik worden gerapporteerd. Bevestig hiaten met een trace of hardwaretellers; dashboardmiddeling kan schijnbare dalen creëren die de tokens per seconde niet verminderen.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Stem tijdlijnen van wachtrij, scheduler en kernels op elkaar af

Speel gecontroleerde gelijkmatige en piekgewijze aankomsten opnieuw af terwijl je wachtende, toegelaten en actieve aanvragen, prompt- en decodetokens per iteratie, vrije KV-blokken, onderbrekingen, CPU-schedulertijd, tokenisatie, sampling, kopieën, collectives, hiaten tussen kernelstarts, GPU-kloksnelheden en uitvoerdoorvoer registreert.

Vergelijk het patroon met gedrag van continuous batching en varieer vervolgens één voor één de aankomstsnelheid, promptlengte, chunked-prefillgrootte, cachebudget en CPU-affiniteit. Behoud het model, de kwantisatie en het latentiedoel. Het resultaat moet daarom worden gecontroleerd aan de hand van het oorspronkelijke bewijsmateriaal.

Classificeer elk dal als geen vraag, een toelatingsblokkade, prefillinterferentie, cachebelasting, hostuithongering of synchronisatie voordat je gaat tunen. Optimaliseer de verantwoordelijke grens; een grotere batch forceren kan een lege wachtrij of geblokkeerde hostthread niet verhelpen.