{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"ai/throughput","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/ai/throughput/","da":"https://cmaintz.github.io/tech-atlas/da/terms/ai/throughput/"},"term":{"en":"Throughput","da":"Gennemløb (throughput)"},"aka":{"en":[],"da":[]},"domain":["ai","cs"],"cluster":"ai-infrastructure","layer":"inference","status":"current","summary":{"en":"How much work a system gets through per second in total - for AI services, often counted as tokens or requests handled each second.","da":"Hvor meget arbejde et system i alt når igennem per sekund - for AI-tjenester ofte talt som tokens eller forespørgsler håndteret i sekundet."},"body":{"formal":{"en":"The rate at which a system completes work, measured as units finished per unit of time, such as requests per second; for a language model service it is usually the total number of tokens produced per second across all users at once.","da":"Den hastighed, hvormed et system fuldfører arbejde, målt som færdige enheder per tidsenhed, fx forespørgsler per sekund; for en sprogmodeltjeneste er det normalt det samlede antal tokens, der frembringes per sekund på tværs af alle brugere på én gang."},"plain":{"en":"Like counting how many cars cross a bridge each hour - a wider bridge lets more through, even if each car drives no faster.","da":"Som at tælle, hvor mange biler der krydser en bro i timen - en bredere bro lukker flere igennem, selv om hver bil ikke kører hurtigere."},"inPractice":{"en":"An operations engineer at a Danish software house that hosts a chat tool for 30 municipalities measures that its GPU server produces 2,500 tokens a second in total - enough for about 100 users at once - and orders a second server before the Monday-morning peak.","da":"En driftsingeniør i et dansk softwarehus, der driver et chatværktøj for 30 kommuner, måler, at GPU-serveren i alt producerer 2.500 tokens i sekundet - nok til omkring 100 samtidige brugere - og bestiller en server mere før spidsbelastningen mandag morgen."},"whyItMatters":{"en":"It decides how many machines a service needs and what each answer costs, so it drives the price users pay and how a service copes with sudden crowds.","da":"Det afgør, hvor mange maskiner en tjeneste har brug for, og hvad hvert svar koster, så det styrer den pris, brugerne betaler, og hvordan tjenesten klarer pludselige stormløb."}},"deepDive":{"en":"Throughput must always be stated with its unit and its conditions. For LLM services the common units are output tokens per second, total tokens per second (input plus output, which flatters prompt-heavy workloads because prefill processes many tokens in parallel), and requests per second; each can be reported per GPU, per server or per cluster. The figure depends heavily on the workload shape: prompt and output lengths, concurrency, the model and precision, and whether prefix caching hits. Two numbers measured with different input/output ratios are not comparable, which is why benchmark suites fix these parameters. MLPerf Inference, for instance, distinguishes an Offline scenario, which measures raw throughput with all queries available at once, from a Server scenario, which measures the highest query rate sustainable while meeting latency constraints.\n\nThe physics of LLM throughput follows from the decode phase being memory-bandwidth-bound. Generating one token for one sequence requires streaming all model weights from HBM; generating one token for 64 sequences in the same step requires reading the weights once and reusing them 64 times. Batching therefore raises aggregate tokens per second nearly linearly until the step becomes compute-bound or KV-cache memory runs out. This is why continuous batching, paged KV-cache management, grouped-query attention and quantization, all of which free memory for more concurrent sequences, are primarily throughput techniques.\n\nThroughput and latency are coupled, not independent. By Little's law, concurrency = throughput × time in system, so for a fixed number of concurrent users, higher throughput means lower latency; but pushing for maximum throughput by growing batches makes each step slower and lengthens queues, raising per-request latency. The usual way to report the trade-off is a curve of throughput against a latency percentile at increasing load, and the operationally relevant point is the maximum throughput at which the latency SLO still holds. The DistServe paper (Zhong et al., 2024) framed serving performance as \"goodput\": the maximum request rate at which a target share of requests complete within their TTFT and TPOT targets, as opposed to raw tokens per second, which can look excellent while users time out.\n\nCommon mistakes include quoting peak vendor numbers measured at unrealistically high batch sizes, confusing throughput with bandwidth (the capacity of a link rather than the useful work completed), measuring with a load generator that is itself the bottleneck, and ignoring the input side, where long prompts consume prefill capacity that never appears in output-token counts. For capacity planning, throughput at the SLO translates directly into cost per million tokens and the number of accelerators needed for peak load.","da":"Gennemløb skal altid angives med enhed og betingelser. For LLM-tjenester er de almindelige enheder output-tokens pr. sekund, samlede tokens pr. sekund (input plus output, hvilket får prompttunge arbejdsbelastninger til at se bedre ud, fordi prefill behandler mange tokens parallelt) og forespørgsler pr. sekund; hver af dem kan opgøres pr. GPU, pr. server eller pr. klynge. Tallet afhænger stærkt af belastningens form: prompt- og svarlængder, samtidighed, model og præcision, og om prefix caching rammer. To tal målt med forskellige forhold mellem input og output kan ikke sammenlignes, og derfor fastlåser benchmark-suiter disse parametre. MLPerf Inference skelner fx mellem et Offline-scenarie, der måler rå gennemløb med alle forespørgsler tilgængelige på én gang, og et Server-scenarie, der måler den højeste forespørgselsrate, der kan opretholdes, mens latenskravene overholdes.\n\nFysikken bag LLM-gennemløb følger af, at decode-fasen er begrænset af hukommelsesbåndbredden. At generere ét token for én sekvens kræver, at alle modelvægte læses fra HBM; at generere ét token for 64 sekvenser i samme trin kræver, at vægtene læses én gang og genbruges 64 gange. Batching hæver derfor det samlede antal tokens pr. sekund næsten lineært, indtil trinnet bliver compute-bound, eller KV-cache-hukommelsen slipper op. Det er grunden til, at continuous batching, sidebaseret styring af KV-cachen, grouped-query attention og kvantisering, som alle frigør hukommelse til flere samtidige sekvenser, først og fremmest er gennemløbsteknikker.\n\nGennemløb og latens hænger sammen og er ikke uafhængige. Ifølge Littles lov er samtidighed = gennemløb × tid i systemet, så ved et fast antal samtidige brugere betyder højere gennemløb lavere latens; men jagter man maksimalt gennemløb ved at gøre batchene større, bliver hvert trin langsommere og køerne længere, så latensen pr. forespørgsel stiger. Kompromiset rapporteres normalt som en kurve over gennemløb mod en latenspercentil ved stigende belastning, og det driftsmæssigt relevante punkt er det højeste gennemløb, hvor latens-SLO'et stadig holder. DistServe-artiklen (Zhong m.fl., 2024) opgjorde ydelsen som \"goodput\": den højeste forespørgselsrate, hvor en fastsat andel af forespørgslerne gennemføres inden for deres mål for TTFT og TPOT, i modsætning til rå tokens pr. sekund, som kan se fremragende ud, mens brugerne får timeout.\n\nTypiske fejl er at citere leverandørers maksimaltal målt ved urealistisk store batches, at forveksle gennemløb med båndbredde (en forbindelses kapacitet frem for det nyttige arbejde, der faktisk bliver udført), at måle med et belastningsværktøj, der selv er flaskehalsen, og at overse inputsiden, hvor lange prompter bruger prefill-kapacitet, som aldrig viser sig i optællingen af output-tokens. Ved kapacitetsplanlægning omsættes gennemløbet ved SLO'et direkte til pris pr. million tokens og antallet af acceleratorer, der skal til ved spidsbelastning."},"edges":[{"type":"used-with","to":"ai/time-to-first-token","why":{"en":"Speed tests of AI services report the two side by side - how soon one answer starts, and how many tokens flow out per second overall.","da":"Hastighedstest af AI-tjenester viser de to side om side - hvor hurtigt ét svar begynder, og hvor mange tokens der i alt strømmer ud per sekund."},"confidence":"high","strength":"normal"}],"depth":0,"sources":[{"title":"Hennessy & Patterson, Computer Architecture: A Quantitative Approach (ch. 1)","tier":"textbook","publisher":"Morgan Kaufmann"},{"title":"Kwon et al. (2023), Efficient Memory Management for Large Language Model Serving with PagedAttention","tier":"reference"}],"draft":true}