LLM throughput versus goodput: welke meetwaarde moet je gebruiken?
Automatische vertaling
Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
LLM throughput meet hoeveel werk een server per seconde afrondt. Goodput meet de hoeveelheid werk per seconde die ook aan vastgelegde service-eisen voldoet. Gebruik voor serving-beslissingen de throughput van output-tokens samen met het aantal succesvolle verzoeken per seconde dat aan je latency-doelen voor het eerste token en de generatie voldoet.
Een server die meer tokens produceert terwijl verzoeken de tijdslimiet overschrijden, kan een hogere throughput en een lagere bruikbare capaciteit hebben.
Definieer een verzoek dat aan de eisen voldoet
Definieer vóór de test aan welke voorwaarden een verzoek moet voldoen. Bijvoorbeeld: succesvolle afronding, TTFT onder 500 ms en gemiddelde TPOT onder 50 ms. Tel vervolgens de afgeronde verzoeken die tijdens het meetinterval aan die voorwaarden voldoen:
request goodput = qualifying completed requests / measured seconds
output throughput = generated output tokens / measured secondsDit zijn een voorbeeld-SLO en twee expliciete definities van meetwaarden. Als 100 verzoeken in tien seconden worden afgerond, maar slechts 60 aan de eisen voldoen, is de throughput van afgeronde verzoeken tien verzoeken per seconde en de goodput zes. Rapporteer ook de throughput van output-tokens, omdat antwoorden in lengte kunnen verschillen.
DistServe gebruikt goodput om serving te beoordelen onder eisen voor TTFT en tokengeneratie. Geef altijd aan of je eenheid verzoeken of tokens zijn die aan de eisen voldoen: het woord alleen definieert de noemer of de telvoorwaarden niet.
Houd de werklast vergelijkbaar
| Leg vast | Waarom dit het resultaat beïnvloedt |
|---|---|
| Input- en outputlengtes | Prefill-werk, cachegrootte en decode-duur verschillen |
| Model, precisie, GPU en runtime-revisie | Ze veranderen de uitvoeringskosten |
| Aangeboden verzoeken per seconde | Bepaalt de druk op de wachtrij |
| Gelijktijdige verzoeken | Verandert batching en geheugengebruik |
| Cachebeleid | Herhaalde prefixes kunnen prefill-werk verminderen |
| Fouten en annuleringen | Succesvolle afronding is onderdeel van bruikbare capaciteit |
Bij kleine decode-batches kan het toevoegen van verzoeken het hergebruik van weights verbeteren. Grotere batches of een toenemende aangeboden belasting kunnen uiteindelijk de latency verhogen of de grenzen van geheugen, rekenkracht of communicatie overschrijden. De curve hangt af van de werklast; lineaire schaalbaarheid is niet gegarandeerd.
Verhoog de aangeboden belasting stapsgewijs en zet throughput, goodput, P99-latency, fouten en wachtrijlengte in grafieken. Kies een belasting die aan de eisen voldoet en ruimte laat voor verkeersvariatie. Het Anyscale-experiment met continuous batching laat zien waarom een vergelijking de verdeling van verzoeken moet vermelden.
De engineeringgids: throughput en de afweging met latency legt de afweging bij serving in context uit.