Batchningsstrategier för LLM-inferens i lokala miljöer

Varför batchning spelar större roll lokalt

När du serverar stora språkmodeller via ett moln-API sker batchningen bakom kulisserna. Leverantören absorberar kostnaden för inaktiva GPU-cykler mellan förfrågningar. Lokalt drabbar varje inaktiv millisekund din budget direkt. En enskild H100-GPU som drar 700 watt medan den väntar på nästa förfrågan är rent slöseri.

Inferensbatchning grupperar flera inkommande förfrågningar så att GPU:n bearbetar dem i ett enda framåtpass. Aritmetiken är övertygande: en modell som serverar 15 tokens per sekund för en enskild förfrågan kan ofta hantera 8 samtidiga förfrågningar med 12 tokens per sekund vardera, vilket ökar den aggregerade genomströmningen med ungefär 6 gånger med minimal inverkan på latens per förfrågan.

Statisk batchning: enkel men begränsande

Statisk batchning samlar ett fast antal förfrågningar och bearbetar dem tillsammans. Servern väntar tills N förfrågningar anlänt eller en timeout löper ut. Detta är det enklaste tillvägagångssättet och fungerar väl när förfrågningslängder är enhetliga och ankomstfrekvenser förutsägbara.

Problemet uppstår med variabel längd på indata och utdata. I en statisk batch måste varje förfrågan vänta tills den längsta sekvensen är klar innan några resultat returneras. En kort sammanfattningsuppgift hålls gisslan av en lång kodgenereringsförfrågan i samma batch. För interaktiva tillämpningar där användare förväntar sig strömmande svar skapar detta oacceptabel svanslatens.

Statisk batchning förblir lämplig för offline-batchbearbetning, som nattlig dokumentklassificering eller inbäddningsgenerering, där latens är irrelevant och maximering av genomströmning är det enda målet.

Kontinuerlig batchning: produktionsstandarden

Kontinuerlig batchning, även kallad iterationsnivåbatchning eller in-flight-batchning, löser problemet med variabel längd. Istället för att vänta på att en hel batch ska bli klar, infogar schemaläggaren nya förfrågningar i batchen vid varje avkodningssteg. När en förfrågan i batchen slutförs frigörs dess plats omedelbart för en väntande förfrågan.

Serveringsramverk som vLLM, TensorRT-LLM och text-generation-inference implementerar alla kontinuerlig batchning. I praktiken innebär detta att din GPU förblir mättad även när förfrågningslängder varierar kraftigt.

För att konfigurera kontinuerlig batchning effektivt lokalt, fokusera på tre parametrar:

Max batchstorlek — Den övre gränsen för samtidiga sekvenser i en batch. Ställ in detta baserat på ditt GPU-minne efter att ha tagit hänsyn till modellvikter och KV-cache.

Max väntetid — Hur länge en förfrågan kan sitta i kön innan den läggs till i nästa batchiteration. För realtidstillämpningar, håll detta under 100ms.

Preemption-policy — När batchen är full och en förfrågan med högre prioritet anländer, ska du avbryta en pågående förfrågan? Ramverk som vLLM stöder att flytta avbrutna förfrågningar till CPU-minne, vilket möjliggör prioritetsbaserad schemaläggning utan att förlora arbete.

PagedAttention och minneseffektiv KV-cachning

Den största begränsningen för batchstorlek är KV-cacheminnet. Varje aktiv sekvens underhåller en nyckel-värde-cache som växer med sekvenslängden. Traditionella implementationer förallokerar maximal möjlig cache för varje sekvens, vilket slösar minne på sekvenser som kommer att vara korta.

PagedAttention, introducerat av vLLM-projektet, tillämpar operativsystemets koncept med virtuellt minnessidhantering på KV-cacher. Istället för sammanhängande förallokerade block delas cachen in i sidor med fast storlek som allokeras vid behov. Detta eliminerar intern fragmentering och kan öka den effektiva batchstorleken med 2-4 gånger på samma hårdvara.

För lokala driftsättningar innebär detta direkt att fler samtidiga användare kan betjänas per GPU. Om din nuvarande uppsättning hanterar 16 samtidiga sekvenser med traditionell KV-cachning kan PagedAttention öka det till 40-50 sekvenser, beroende på din genomsnittliga sekvenslängdsfördelning.

Prioritetskö och flernivåservering

Alla inferensförfrågningar är inte lika. En chefspanel som genererar realtidssammanfattningar behöver svarstider under en sekund. Ett nattligt batchjobb som bearbetar tusentals supportärenden kan tolerera minuters köande. Lokalt, där GPU-kapaciteten är fast, är ett väldesignat prioritetssystem avgörande.

Implementera minst två nivåer: en realtidsnivå med strikta latens-SLO:er och reserverad GPU-kapacitet, och en batchnivå som absorberar återstående kapacitet. Batchnivån fungerar som en naturlig buffert som expanderar när realtidsbelastningen är låg och kontraherar under rusningstid.

Använd metadata om förfrågningar — källapplikation, användarnivå, uppgiftstyp — för att dirigera inkommande förfrågningar. En reverse proxy som Envoy eller en dedikerad inferensgateway kan hantera denna dirigering.

Mätning och finjustering av batchprestanda

De mätvärden som spelar roll för batchning är tid till första token (TTFT), latens mellan tokens (ITL), genomströmning (tokens per sekund över alla förfrågningar) och GPU-utnyttjande. Dessa mätvärden konkurrerar ofta: att maximera genomströmningen ökar TTFT då förfrågningar väntar på batchformering.

Börja med att profilera din faktiska arbetsbelastning. Fånga en veckas produktionsförfrågningsloggar inklusive inmatningslängder, utmatningslängder, ankomsttidsstämplar och källapplikationer. Spela upp denna trafik mot din serveringsinfrastruktur med olika batchningskonfigurationer.

Var uppmärksam på två vanliga felmönster. Först, batchsvält: under perioder med låg trafik väntar förfrågningar på en batch som aldrig fylls. Åtgärda detta med aggressiva timeout-inställningar. Sedan, minnestryckskaskad: under hög belastning förbrukar stora batcher allt KV-cacheminne, vilket tvingar fram preemptions som saktar ner allt.

Batchningskonfiguration är inte något man ställer in och glömmer. Allt eftersom din modellmix förändras, nya applikationer tas i drift och trafikmönster skiftar, bör du se över inställningarna kvartalsvis. Skillnaden mellan en vältrimmad och dåligt trimmad batchningskonfiguration på samma hårdvara kan enkelt vara 3-5 gånger i effektiv genomströmning.

Utvald bild av CoolIT Systems på Unsplash.