Throughput (LLM-serving)

Output-throughput vs. system-throughput

Når et benchmark rapporterer output-throughput, menes de tokens, der streamer til én forespørgsel efter det første token. Et eksempel er de 713 tok/s, vi måler på gpt-oss-120b. Dette tal afgør, hvor hurtigt en bruger får et komplet svar. System-throughput er noget andet. Den tekniske litteratur definerer det som antallet af output-tokens per sekund, som en inferens-server genererer på tværs af alle brugere og forespørgsler. Benchmark-dokumentation kalder det "TPS per system" i modsætning til "TPS per bruger". Under belastning bevæger de to tal sig i hver sin retning. Når samtidigheden stiger, nærmer system-throughput sig hardwarens mætningspunkt, mens hver enkelt brugers output-throughput falder.

Hvorfor batching skaber afvejningen

Inferensens decode-fase er begrænset af hukommelsesbåndbredden: For hvert genereret token skal hardwaren hente modellens vægte fra hukommelsen. Batching fordeler den omkostning. Vægtene indlæses én gang, og mange brugeres forespørgsler rykker frem i samme omgang. Anyscales benchmarks af continuous batching viste op til 23x højere throughput end naiv behandling af én forespørgsel ad gangen.

Ulempen er, at alle i batchen deler den samme hukommelsesbåndbredde. En større batch betyder derfor langsommere tokens for hver bruger. Databricks målte afvejningen konkret: Ved en batch-størrelse på 64 på en A100 steg throughput 14x, mens latensen for hver forespørgsel steg 4x. System-throughput er i sidste ende udbyderens anliggende. Det bestemmer udbyderens omkostning per token og kapacitetsplanlægning. Som bruger oplever du kun output-throughput for din egen forespørgsel. Udbyderens batching-politik afgør, hvor den lander.

Det skal du kigge efter i praksis

Når du vurderer udbydere, så tag udgangspunkt i tallene per forespørgsel: output-throughput og inter-token latency under realistisk belastning. Et flot tal for system-throughput siger intet om den oplevelse, dine forespørgsler får. Arkitekturen betyder også noget. Hardware, der holder en høj udnyttelse ved små batch-størrelser, kan levere høj hastighed per forespørgsel uden at være afhængig af aggressiv batching. Det er netop grundtanken bag den dataflow-arkitektur, som vores platform kører på.