Output throughput vs. system-throughput
Når et benchmark rapporterer output throughput - som de 713 tok/s vi måler på gpt-oss-120b - betyder det tokens, der streames til en enkelt forespørgsel efter den første token. Det er det tal, der afgør, hvor hurtigt en bruger modtager et komplet svar. System-throughput er noget andet: den tekniske litteratur definerer det som antallet af output-tokens per sekund, en inference-server genererer på tværs af alle brugere og forespørgsler; benchmarking-dokumentation kalder det "TPS per system" i modsætning til "TPS per user". De to bevæger sig i modsatte retninger under belastning: når samtidigheden stiger, klatrer system-throughput mod hardware-mætning, mens hver brugers output throughput falder.
Hvorfor batching skaber trade-offet
Inferencens decode-fase er bundet af hukommelsesbåndbredde: for hver genereret token skal hardwaren streame modelvægtene fra hukommelsen. Batching amortiserer den omkostning - indlæs vægtene én gang, og lad mange brugeres forespørgsler rykke frem i samme gennemløb. Anyscales continuous-batching-benchmarks viste op til 23x højere throughput sammenlignet med naiv forespørgsel-for-forespørgsel-serving.
Hagen: alle i batchen deler den samme hukommelsesbåndbredde, så en større batch betyder langsommere tokens for hver bruger. Databricks målte trade-offet konkret: ved batch-størrelse 64 på en A100 steg throughput 14x - mens hver forespørgsels latens steg 4x. System-throughput er i sidste ende udbyderens anliggende - den bestemmer deres omkostning per token og kapacitetsplanlægning. Som bruger oplever du kun din egen forespørgsels output throughput; udbyderens batching-politik afgør, hvor den lander.
Hvad man skal kigge efter i praksis
Når du evaluerer udbydere, så forankr dig i per-request-tallene: output throughput og inter-token latency under realistisk belastning - et system-throughput-tal i overskriften siger intet om den oplevelse, dine forespørgsler vil få. Arkitekturen betyder også noget: hardware, der fastholder høj udnyttelse ved lave batch-størrelser, kan levere høj per-request hastighed uden at være afhængig af aggressiv batching - hvilket er designpræmissen for den dataflow-arkitektur, vores platform kører på.
Kilder
Relaterede begreber
Tokens per sekund
Standardenheden for LLM-genereringshastighed - og hvorfor det samme tal kan betyde to forskellige ting.
Latency vs. Throughput
Det fundamentale serving-trade-off: samlet systemoutput vs. hver brugers hastighed.
Prefill vs. Decode
LLM-inferencens to faser - parallel prompt-behandling vs. token-for-token-generering.
Lær hvordan SambaNova's dataflow-arkitektur ændrer økonomien i inference - og hvorfor vi byggede på den.