Welke invloed heeft de batchgrootte op de latentie van het eerste token en per token?
Grotere batches verbeteren vaak de totale tokensdoorvoer, maar kunnen de vertraging tot het eerste token en de latentie per token verhogen door wachtrijen, zwaardere iteraties en geheugendruk.
Een lokaal model met batchgrootte één benut zijn accelerator mogelijk onvoldoende, omdat elke decodeerstap modelgewichten verplaatst voor maar weinig werk. Door verzoeken te combineren, wordt die verplaatsing uitgesmeerd over meer werk en neemt de doorvoer toe. Toch kunnen verzoeken moeten wachten op toelating, kunnen lange prefill-bewerkingen decodeerbewerkingen blokkeren en voegen actieve reeksen elk KV-cache- en tokenwerk toe. De beste batch hangt daarom af van de vraag of het doel doorvoer, responsiviteit of goedeput binnen een latentiedoelstelling is.
Batching spreidt modelwerk over verzoeken
Een gebatchte matrixbewerking verwerkt tokens uit meerdere reeksen tegelijk, waardoor de hardwarebenutting verbetert en vaste kosten voor het starten van bewerkingen of het overzetten van gewichten over meer nuttig werk worden verdeeld. De grootste winst ontstaat voordat rekenkracht, geheugenbandbreedte, cachecapaciteit of plannings overhead verzadigd raakt.
De Orca-planning op iteratieniveau maakt planning op iteratieniveau mogelijk, zodat voltooide reeksen kunnen vertrekken en nieuw werk tussen decodeeriteraties kan instromen. Hierdoor hoeft niet elk verzoek te wachten op het langste lid van een statische batch.
Batchgrootte kan staan voor het geconfigureerde maximum, het aantal toegelaten reeksen of het aantal tokens dat in één iteratie wordt verwerkt. Bij continuous batching verschillen deze waarden, dus prestatierapporten moeten vermelden welke hoeveelheid is beheerst en waargenomen. Dit onderscheid blijft zichtbaar tijdens latere tests in de thuisomgeving.
De latentie tot het eerste token omvat wachtrijen en prefill
De tijd tot het eerste token begint wanneer een verzoek binnenkomt en omvat het wachten op de scheduler, prompt-prefill en de eerste decodeerstap. Een beleid dat wacht met het samenstellen van een batch kan de wachttijd verhogen, terwijl het toelaten van een grote prompt een iteratie kan bezetten en bestaande interactieve verzoeken kan vertragen.
Een actuele vergelijking van continuous batching legt uit hoe continuous batching verzoeken dynamisch toelaat en verwijdert en hoe agressieve planning doorvoer afweegt tegen TTFT. Dit verduidelijkt waarom de batchgrootte alleen de responsiviteit van het eerste token niet kan voorspellen. Het tussenresultaat moet controleerbaar blijven voordat automatisering het proces overneemt.
Gepartitioneerde prefill kan lange prompts afwisselen met decodeerwerk, maar de chunkgrootte vormt een extra afweging. Kleine chunks beschermen interactieve tokens, maar voegen plannings overhead toe; grote chunks verbeteren de efficiëntie van prefill, maar creëren langere blokkeringsintervallen. Die grens moet afzonderlijk worden gemeten onder realistische bedrijfsomstandigheden.
De latentie per token hangt af van de actieve iteratie
Tijdens het decoderen produceert één stap doorgaans één token per actieve reeks. Meer reeksen vergroten de batch en kunnen de duur van elke iteratie verlengen, zelfs als het totale aantal tokens per seconde stijgt. Ongelijke contexten, cache-druk, preëmptie en gedistribueerde synchronisatie voegen variatie toe.
DistServe scheidt prefill en decode, omdat deze verschillende rekenkarakteristieken en servicedoelen hebben. Het ontwerp laat zien waarom het optimaliseren van de totale doorvoer kan botsen met zowel TTFT als de tijd per uitvoertoken. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen concurreren om beperkte context.
De foutgrens ligt bij het kiezen van de grootste batch uit een offline-doorvoerdiagram voor een interactieve thuisassistent. Als wachtrijen of tokentussenpozen de gebruikersgerichte doelstelling schenden, is de nominale doorvoer geen bruikbare goedeput, ongeacht de benutting van de accelerator.
Breng de goedeputgrens van batches in kaart
Speel korte chats, lange RAG-prompts en achtergrondtaken af bij gecontroleerde aankomstsnelheden. Varieer het maximale aantal reeksen en de limieten voor gebatchte tokens, terwijl je percentielen voor TTFT, latentie tussen tokens, end-to-endlatentie, prompt- en uitvoerdoorvoer, wachtrijdiepte, cachegebruik, preëmptie en afgewezen verzoeken meet.
Gebruik het gedrag van continuous batching in continuous batching om geconfigureerde limieten te onderscheiden van de actieve batch die in elke iteratie wordt gezien. Houd de prompt- en uitvoerverdelingen vast en rapporteer het percentage verzoeken dat zowel aan de doelstelling voor het eerste token als aan die voor de tokentussenpoos voldoet.
Kies de instelling die de voltooide hoeveelheid werk binnen deze doelstellingen maximaliseert, in plaats van de ruwe tokens per seconde. Isoleer batches op de achtergrond of geef ze een lagere prioriteit wanneer ze de interactieve goedeput verlagen, en test opnieuw na wijzigingen aan het model, de kwantisatie, de contextmix of de scheduler.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Kan een lokale LLM de generatie hervatten nadat het proces opnieuw is gestart?
Een mechanismegerichte uitleg van het hervatten van LLM-generatie, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een homeserver embeddings genereren en video transcoderen op dezelfde geïntegreerde GPU?
Een uitleg waarin het mechanisme centraal staat van gedeelde iGPU-embeddings en transcodering, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een...
Welke invloed heeft de levensduur van toegangstokens op de beveiliging en het gedoe in het huishouden?
Een mechanismegerichte uitleg van de levensduur van toegangstokens, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
