Continuous batching en statische batching: hoe LLM-scheduling werkt
Automatische vertaling
Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
Statische batching groepeert verzoeken voor een inference-uitvoering. Continuous batching werkt de verzameling actieve verzoeken bij tussen generatie-iteraties: voltooide verzoeken verdwijnen en wachtende verzoeken die aan de voorwaarden voldoen, komen erbij. Zo kan een server capaciteit opnieuw gebruiken zonder te wachten tot alle oorspronkelijke verzoeken klaar zijn.
Voor serving-engineers hangt het voordeel af van wisselende antwoordlengtes, het schedulingbeleid, de geheugencapaciteit en de latency-eisen.
Vergelijk ongelijke uitvoerlengtes
Stel dat drie verzoeken 10, 40 en 100 uitvoertokens nodig hebben. In een eenvoudige generatielus met een vaste batch die voltooide verzoeken niet vervangt, komt de capaciteit van de eerste twee vrij voordat het derde klaar is. De server wacht toch op het langste antwoord van de batch voordat hij een volgende volledige batch start.
Een scheduler per iteratie kan elk voltooid verzoek verwijderen en een ander toelaten. Orca introduceerde een ontwerp voor LLM-serving dat deze schedulingaanpak gebruikt. Toelating vereist nog steeds vrije KV-cacheblokken en een passend iteratiebudget. Continuous batching betekent niet dat elk verzoek in de wachtrij direct start.
Nieuwe prompts hebben ook prefill nodig. Prefill in delen kan iteratiebudgetten delen met lopende decode-bewerkingen. De toelatings- en prioriteitsregels van de scheduler beïnvloeden daardoor zowel de tijd tot het eerste token als de intervallen tussen latere tokens.
Vergelijk de scheduler en de volledige runtime
Het experiment van Anyscale uit 2023 rapporteerde ongeveer 4x voor FasterTransformer, 8x voor zijn continuous-batchingconfiguraties en 23x voor vLLM ten opzichte van zijn eenvoudige referentie-implementatie. Het gebruikte OPT-13B, een A100-40GB, 1,000 verzoeken, invoer van 512 tokens en een exponentiële verdeling van uitvoerlengtes met een gemiddelde van 128 tokens. Dit zijn resultaten voor volledige implementaties in die opstelling, in plaats van het afzonderlijke effect van één schedulingwijziging.
Leg voor je vergelijking het volgende vast:
| Controlepunt | Waarom het van belang is |
|---|---|
| Verdelingen van aankomsttijden en uitvoerlengtes van verzoeken | Bepalen ongebruikte capaciteit en druk op de wachtrij |
| Maximaal aantal actieve sequenties en tokenbudget | Begrenzen het werk per iteratie |
| KV-toewijzing en preëmptie | Kunnen nieuwe toelatingen verhinderen |
| TTFT en generatie-latency per verzoek | Tonen de kosten voor afzonderlijke verzoeken |
| Succespercentage en goodput | Tonen of extra werk aan het servicedoel voldoet |
Onderzoek korte en lange verzoeken afzonderlijk. Een hogere totale throughput kan samengaan met slechtere latency voor één groep verzoeken. Kies schedulinginstellingen op basis van de gemeten service-eisen.
Engineeringgids: continuous batching legt de mechanismen voor toewijzing en scheduling samen uit.