Wat veroorzaakt storingen bij LLM-serving en hoe los je ze op?
Automatische vertaling
Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
Storingen bij LLM-serving ontstaan vaak door onvoldoende geheugen, meer gelijktijdig werk dan de dienst aankan of herhaalde pogingen die dure verzoeken opnieuw uitvoeren. Bepaal welke resource of fase faalt voordat je de runtime wijzigt. Dat een model succesvol wordt geladen, bewijst niet dat het het beoogde verkeer aankan.
Koppel het symptoom aan de meetgegevens
| Symptoom | Eerste gegevens om te bekijken | Te testen wijziging |
|---|---|---|
| GPU-geheugentekort | Weights, KV-toewijzing, activations, verzoeklengtes | Kleinere actieve batch, kortere limieten of ondersteunde quantization |
| Latency stijgt zonder fouten | KV-gebruik, preemptions, wachtende verzoeken | Minder gelijktijdig toegelaten verzoeken of meer capaciteit die door metingen is bevestigd |
| Trage eerste token | Wachtrij, tokenization, prefill, netwerktijden | Verhelp de trage fase; test prefill in chunks als de fasen elkaar hinderen |
| Belasting stijgt na time-outs | Aantal herhaalde pogingen en werk dat nog loopt | Begrensde herhaalde pogingen en annulering van verlaten werk |
Opslag voor weights en KV-opslag staan los van elkaar. Een 70B-model in FP16 heeft ongeveer 140 GB nodig voor alleen de waarden van de weights. Bij een conventionele cache-indeling met volledige attention voegt één Llama 3.1 70B-sequentie van 128K tokens 40 GiB aan FP16-KV-data toe, nog zonder runtime-overhead. Geen van beide getallen beschrijft op zichzelf de totale geheugenbehoefte.
Controleer preemption voordat je de wachtrij vergroot
Als er onvoldoende KV-ruimte is, kan een serving-engine verzoeken onderbreken. vLLM V1 berekent onderbroken werk normaal opnieuw, wat latency toevoegt, zelfs als de API uiteindelijk succesvol antwoordt. Vergelijk het aantal preemptions met promptlengtes, actieve sequenties en KV-gebruik.
Laat minder werk toe of wijzig de geteste geheugentoewijzing. Voordat je het GPU-geheugengebruik verhoogt, moet je bevestigen dat andere toewijzingen nog steeds passen. Herbruikbare KV-data naar CPU of schijf verplaatsen voegt ook overdrachten toe; het garandeert niet dat een te groot actief verzoek in het geheugen past.
Begrens herhaalde pogingen
Probeer tijdelijke fouten opnieuw binnen een deadline en een vast aantal toegestane pogingen. Gebruik oplopende wachttijden met willekeurige variatie en laat één laag de herhaalde pogingen uitvoeren, zodat pogingen van de gateway en de client elkaar niet vermenigvuldigen. De SRE-richtlijnen van Google leggen uit hoe herhaalde pogingen overbelasting kunnen verergeren.
Geef de annulering door wanneer de aanroeper afhaakt, controleer dat de generatie stopt en test dit gedrag onder belasting. Meer wachtrijcapaciteit stelt afwijzing uit, maar creëert geen verwerkingscapaciteit.
Lees de faalwijzen bij LLM-serving in de gids voor de bijbehorende concepten rond geheugen en planning.