LLM Inference-hastighed forklaret: TTFT, gennemstrømning og hvad der virkelig betyder noget

To ting gør det svært at sammenligne. For det første måler udbyderne vidt forskellige ting: Når én reklamerer med 400 tokens per sekund og en anden med en latens under 200ms, er det to forskellige målinger. Begge kan være sande, og alligevel er ingen af dem måske afgørende for dit use case.

For det andet er "hurtig" altid relativt. Spørgsmålet er: i forhold til hvad? Når en GPU-baseret udbyder kalder sig hurtig, mener den som regel hurtig sammenlignet med andre GPU-udbydere. Inden for den kategori er det en rimelig baseline, men det siger intet om den absolutte ydeevne. En udbyder med specialiseret inferens-hardware kan være 5-10x hurtigere, og så er sammenligningen mellem GPU'er ligegyldig. Denne artikel gennemgår de tre metrikker, der bestemmer hastigheden af LLM-inferens, forklarer hvornår hver af dem betyder mest, og giver dig reelle måletal at sammenligne med. Hvis du også vurderer prisen, så læs den ledsagende artikel Hvad 'Pris per Token' ikke fortæller dig.

De tre metrikker, der bestemmer hastigheden

Når du sender en forespørgsel til en LLM-API, kommer svaret ikke tilbage i ét stykke. Det gennemløber flere faser, og hver fase har sin egen ydeevneprofil.

Latensen trin for trin:

For en udvikler i Europa, der kalder en udbyder i USA, ser det sådan ud:

• Netværks-roundtrip: 80-150ms (lysets hastighed i fiberkablet, som ingen software kan ændre på)
• TLS-handshake: 1-3 ekstra roundtrips ved hver ny forbindelse (med connection pooling slipper du for dem ved de efterfølgende forespørgsler)
• Gateway-overhead: 10-50ms (autentificering, rate limiting, routing)
• Køtid: fra 0ms til flere sekunder (afhænger af belastning og kapacitet)
• Prefill: afhænger af promptens længde
• Decode: afhænger af outputtets længde og af throughput

Derfor skal prefill og decode ses hver for sig:

I prefill behandler modellen hele din prompt parallelt. Den læser alle tokens på én gang og bygger en intern repræsentation, KV-cachen. Fasen er compute-bound: Her er det den rå regnekraft, der tæller.

I decode genererer modellen outputtet ét token ad gangen. Hvert nyt token afhænger af alle de foregående, så fasen er sekventiel. Den er memory-bound: Chippen bruger det meste af tiden på at læse modelvægte og cache fra hukommelsen og venter på data, før den kan beregne næste token.

Forskellige hardwarearkitekturer klarer de to faser forskelligt:

GPU'er er stærke til prefill, fordi de er bygget til parallelle beregninger. Til gengæld har de svært ved decode: Udnyttelsen falder til 20-40%, fordi regneenhederne står stille og venter på hukommelsen.

Specialiserede inferenschips som SambaNovas RDU, Groqs LPU og Cerebras' WSE er designet til den memory-bound decode-fase. De holder data på chippen, sparer roundtrips til hukommelsen og bevarer en høj udnyttelse, også når tokens genereres sekventielt. Resultatet er 3-10x hurtigere decode på store modeller.

Netværkslatensen rammer dig to gange, både på vej ud og på vej tilbage. En udbyder, der reklamerer med 300ms TTFT fra Virginia, leverer 400ms eller mere til München. Før inferensen overhovedet går i gang, er der allerede gået 100ms på ledningen.

Gateway-overhead er som regel lille, men den er der altid. Den store ubekendte er køtiden: På delt infrastruktur venter din forespørgsel bag andre kunders forespørgsler. Den samme API kan svare med det samme kl. 3 om natten og føles træg kl. 15. Med dedikeret kapacitet konkurrerer du ikke med andre kunder, og ydeevnen bliver forudsigelig.

Time to First Token (TTFT)

TTFT måler tiden, fra du sender en forespørgsel, til det første token begynder at streame tilbage. Den afgør, hvor hurtigt en applikation føles. Ved 200ms TTFT virker svaret øjeblikkeligt. En tom skærm i 2 sekunder får derimod applikationen til at virke i stykker, selv om den samlede svartid ender med at være den samme.

Ved korte til mellemlange prompts på omkring 1K tokens føles alt under 300ms fremragende i en interaktiv chat. 300-600ms er acceptabelt for de fleste applikationer. Over 600ms begynder brugerne at bemærke forsinkelsen, og efter mere end et sekund går de ud fra, at noget er galt.

TTFT vokser dog med inputtets længde, og det er her, benchmarks bliver misvisende. En prompt på 100 tokens kan komme tilbage på 200ms. En prompt på 10K tokens tager længere tid i prefill, og selv på hurtig infrastruktur skal du regne med 400-800ms. Ved 100K tokens er flere sekunder normalt. Et TTFT-benchmark uden inputlængde siger derfor ingenting: "300ms TTFT" på en kort prompt er ikke noget særligt, men på 10K tokens er det imponerende.

Tre faktorer bestemmer TTFT:

• Beregning i prefill - modellen skal behandle hele inputtet, før den begynder på outputtet. Jo længere prompt, desto højere TTFT.
• Køtid - hvis udbyderen er overbelastet, venter din forespørgsel, før behandlingen overhovedet begynder.
• Netværkslatens - når en bruger i EU kalder en udbyder i USA, kommer der 100-150ms oveni, før inferensen begynder. Den latens er fysik og kan ikke optimeres væk. Derfor handler dataresidency også om ydeevne, ikke kun om compliance.

TTFT betyder mest i interaktive applikationer, hvor et menneske kigger på skærmen: chat-interfaces, coding-assistenter i IDE'en, voice AI og alt, der kører i realtid.

Output-throughput (tokens per sekund)

Throughput måler, hvor hurtigt tokens strømmer ind efter det første. Det afgør, hvornår du har det komplette svar. Et svar på 1.000 tokens tager 10 sekunder ved 100 tok/s og 2,5 sekunder ved 400 tok/s. Ved længere output vokser forskellen tilsvarende.

Throughput afhænger meget af modellens arkitektur, og derfor er sammenligninger på tværs af modeller misvisende. En dense-model på 70B læser alle 70B parametre for hvert token. En MoE-model på 671B som DeepSeek aktiverer måske kun 37B parametre per token. Færre aktive parametre giver hurtigere decode, selv om modellen samlet set er større. Hardwaren betyder også noget: GPU'er har svært ved memory-bound decode, mens specialiserede inferenschips som SambaNovas RDU, Groqs LPU og Cerebras' WSE er designet netop til det. Inden for samme arkitektur er større modeller desuden altid langsommere. På identisk hardware er en 7B-model hurtigere end en 70B-model.

Den eneste fair sammenligning er den samme model hos forskellige udbydere. DeepSeek R1 671B kører med 30-80 tok/s hos GPU-baserede udbydere, mens SambaNovas RDU leverer 250+ tok/s. Det er den højeste værdi, Artificial Analysis har målt for den model. Ved Llama 3.3 70B er forskellen endnu større: 50-150 tok/s på GPU'er mod 2.100 tok/s på Cerebras' WSE og 1.200+ tok/s på Groqs LPU.

Throughput betyder mest, når et system først kan arbejde videre med det komplette svar. Agentiske workflows er det tydeligste eksempel, som vores artikel om throughput i agentic coding viser. Det samme gælder batchbehandling, generering af lange tekster og enhver workflow, hvor den samlede behandlingstid styrer produktiviteten.

End-to-end-latens

End-to-end-latens er den samlede tid fra forespørgsel til komplet svar, altså TTFT plus tiden til at generere alle output-tokens.

Regnestykket er hurtigt lavet. Ved 1.000 output-tokens, 100 tok/s og 500ms TTFT venter du 0,5 sekunder på det første token og derefter 10 sekunder på resten, i alt 10,5 sekunder. Ved 400 tok/s og 600ms TTFT tager det samme output 3,1 sekunder. Den 4x højere throughput opvejer mere end rigeligt den langsommere TTFT.

End-to-end-latens betyder mest, når intet menneske følger med i det løbende output. Batch-pipelines, backend-API-kald og applikationer med SLA-krav til den samlede svartid er ligeglade med, hvornår jobbet starter. For dem tæller kun, hvornår det er færdigt.

Hvorfor metrikkerne trækker i hver sin retning

Når du optimerer én metrik, går det ofte ud over en anden.

Afvejningen mellem TTFT og throughput:

Prefill-fasen (behandling af inputtet) og decode-fasen (generering af outputtet) konkurrerer om den samme hardware. En udbyder kan indrette sin infrastruktur efter et af to mål:

1. Optimering for TTFT: flere ressourcer til prefill, så genereringen starter hurtigt, men decode bliver langsommere
2. Optimering for throughput: flere forespørgsler per batch og dermed højere throughput per forespørgsel, men længere køtider

Det er ved at ændre sig. Branchen bevæger sig mod disaggregeret inferens, hvor prefill og decode kører på separat, specialiseret hardware. GPU'er klarer den compute-bound prefill effektivt, og hukommelsesoptimerede chips tager sig af decode. På GTC 2026 annoncerede NVIDIA denne retning, og SambaNova gik sammen med Intel om en heterogen arkitektur: GPU'er til prefill, RDU'er til decode og Xeon til orkestrering. De første resultater viser 50% eller mere i ekstra throughput, uden at det går ud over TTFT.

Indtil videre kører de fleste udbydere dog stadig begge faser på den samme hardware. Derfor opfører den samme model sig forskelligt fra udbyder til udbyder. Udbyder A er billigere, men hastigheden svinger. Udbyder B koster mere, men leverer en stabil ydeevne. Modellen er identisk, det er valgene i infrastrukturen, der er forskellige.

Kontekstlængden forstærker det hele:

De fleste udbydere tager den samme pris per token, uanset kontekstlængden. Men beregningsomkostningen er ikke konstant.

Prefill vokser nogenlunde kvadratisk med kontekstlængden, fordi modellen beregner attention mellem alle par af tokens:

• 1.000 tokens: 1 million attention-beregninger
• 10.000 tokens: 100 millioner attention-beregninger

Måletal fra produktionssystemer viser, hvad det betyder. En prompt med 128K kontekst tager omkring 4 sekunder i prefill på optimeret infrastruktur. En prompt med 1M kontekst tager omkring 77 sekunder. Modellen og hardwaren er den samme, kun inputtet er længere.

Hvilken metrik passer til hvilket use case

I en interaktiv chat går TTFT forud for throughput. Brugerne læser med, mens tokens strømmer ind, så det vigtigste er, at svaret kommer i gang. En langsommere generering tilgiver de, hvis svaret starter hurtigt. Agentiske workflows vender det om: Agenterne venter på det komplette svar, før de handler, og intet menneske følger med mellem trinene. Her er det throughput, der afgør det. Voice AI kræver begge dele, fordi den første svartid påvirker samtalens flow, og taletempoet også skal passe. Batchbehandling handler næsten kun om throughput og samlet behandlingstid. RAG-pipelines ligger et sted midt imellem: De skal reagere hurtigt, men som regel dominerer latensen i retrieval-trinnet alligevel.

Use case: agentiske workflows

Agentic coding-værktøjer som Cursor, Cline og Codex CLI viser, hvorfor throughput er afgørende for nogle workloads. En enkelt kodeopgave kan kræve fra 50 til over 200 LLM-kald: Agenten læser filer, opbygger kontekst, planlægger sin tilgang, genererer kode, kører tests, retter fejl og gentager det hele, indtil opgaven er løst.

Hvert kald genererer hundredvis af tokens. En session på 300K tokens, som er almindeligt ved kompleks refaktorering, tager omkring 50 minutters ren inferenstid ved 100 tok/s. Ved 400 tok/s tager den samme session 12 minutter. De 38 minutters forskel afgør, om du bliver i dit flow eller skifter over til Slack, mens du venter.

Den oversete faktor: konsistens under belastning

Benchmarks viser den højeste ydeevne, mens belastningen i produktion svinger.

Det bør du spørge udbyderne om:

• Latens ved P50 og P99: 99. percentil viser ydeevnen i det værste tilfælde. Hvis P99 er 5x højere end P50, får du frustrerede brugere.
• Rate limits: Kan du overhovedet nå de hastigheder, der reklameres med, eller bremser grænserne dig inden da?
• Ydeevne under høj belastning: Holder throughput, når du sender 100 forespørgsler i sekundet?

Artificial Analysis udgiver uafhængige benchmarks, der fanger disse udsving. Udbyderne testes løbende, så man ikke kun ser den højeste ydeevne, men også hvor stabil den er over tid.

Sådan benchmarker du selv

Stol ikke på marketingtal, men mål selv med dine egne workloads.

Test med de promptlængder, du bruger i praksis. Ydeevnen varierer markant mellem 1K og 100K input-tokens, og de fleste marketing-benchmarks bruger korte prompts, der får resultaterne til at se bedre ud. Test også de outputlængder, du forventer, for korte completions og lange tekster har forskellige ydeevneprofiler. Hvis du sender samtidige forespørgsler, så benchmark netop det mønster i stedet for enkelte forespørgsler isoleret. Test frem for alt i spidsbelastningstimerne. Uden for dem ser du det bedste tilfælde, som du sjældent oplever i produktion. Artificial Analysis udgiver uafhængige sammenligninger af udbydere, hvis du vil have en neutral baseline. Men intet erstatter tidsmålinger i dit eget produktionsmiljø.

Hvilken metrik betyder mest?

Det afhænger af din workload. Hvis brugerne kigger på skærmen, så prioritér TTFT: Starter svaret inden for et sekund, føles det øjeblikkeligt. Hvis agenter venter på svar, så prioritér throughput, for hurtigere tokens betyder hurtigere løste opgaver. Hvis du behandler store mængder, så prioritér end-to-end-latens og konsistens: Den samlede behandlingstid og forudsigelige SLA'er betyder mere end tophastigheden.

De fleste applikationer i produktion har brug for en acceptabel ydeevne på alle tre metrikker. Lynhurtig throughput med 3 sekunders TTFT frustrerer interaktive brugere. En øjeblikkelig TTFT med 50 tok/s throughput bliver en flaskehals for agentiske workflows. De afvejninger kommer man ikke uden om.

Prøv selv: På benchmark.infercom.ai kan du køre dine egne prompts mod vores infrastruktur. Standardiserede sammenligninger finder du i vores publicerede benchmarks.

Hvorfor vi kalder det "Ultraspeed"

Derfor kalder vi vores MiniMax M2.7 for Ultraspeed:

1. SambaNovas dataflow-arkitektur. Hardwaren er bygget specifikt til inferens og er ikke genbrugte GPU'er. RDU'en fjerner den flaskehals i hukommelsen, der begrænser GPU'ers throughput. Sådan skaber dataflow hastighed
2. 428 tokens per sekund. Med den målte throughput bliver agentiske workflows praktisk anvendelige. En kodeopgave med 50 trin, der ville tage en time på almindelig GPU-infrastruktur, er løst på få minutter.
3. 690ms TTFT på 10K input-tokens, under 150ms på korte prompts. Tallene er målt fra Tyskland til vores infrastruktur i München. Brugere i EU får latensfordelen uden de 100ms eller mere, som vejen til datacentre i USA koster.

Ultraspeed kører på delt infrastruktur. Du får fordelen af arkitekturen og hostingen i EU, men køtiden svinger med platformens belastning, som ved enhver delt tjeneste.

Prøv MiniMax M2.7 Ultraspeed

Konklusion

Hastighedstal uden kontekst siger ingenting. Spørg altid: Hvilken metrik, hvilken inputlængde, hvilken baseline? "Hurtigste LLM-API" kan betyde hurtigste TTFT på korte prompts, højeste throughput på en bestemt model eller laveste end-to-end-latens under ideelle forhold. Uden den kontekst fortæller påstanden dig intet.

Din workload afgør, hvilken metrik der betyder noget. Interaktive applikationer har brug for en lav TTFT, agentiske workflows for høj throughput og batchbehandling for en stabil end-to-end-latens. De fleste produktionssystemer har brug for en acceptabel ydeevne på alle tre.

Konsistens under belastning betyder lige så meget som den højeste ydeevne. En udbyder, der leverer 400 tok/s kl. 3 om natten, men kun 150 tok/s i arbejdstiden, er ikke en 400 tok/s-udbyder for din workload i produktion.

Netværkslatens er fysik, ikke software. For brugere i EU vil en inferensudbyder i München altid være hurtigere end en i Virginia, for ingen optimering kan overvinde lysets hastighed. Dataresidency handler derfor ikke kun om compliance. Det er også en fordel for ydeevnen.