Gennemløb (throughput)

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.

Fysikken 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.

Gennemlø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.

Typiske 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.