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

Alle inference-udbydere taler om hastighed. Marketing-sider viser imponerende tal. Men hvad betyder "hurtigt" egentlig?

To problemer gør dette svært at fortolke. For det første: Når én udbyder reklamerer med 400 tokens i sekundet og en anden med under 200ms latenstid, måler de helt forskellige ting. Begge påstande kan være sande - og ingen af dem er måske relevante for dit use case.

For det andet: "Hurtigt" er altid relativt - men relativt til hvad? Når en GPU-baseret udbyder hævder at være hurtig, mener de normalt hurtig sammenlignet med andre GPU-udbydere. Det er en rimelig baseline inden for deres kategori, men det fortæller dig intet om absolut ydeevne. En udbyder med specialiseret inference-hardware kan levere 5-10x hastigheden, hvilket gør GPU-sammenligningen irrelevant. Denne artikel nedbryder de tre metrikker, der definerer inference-hastighed, forklarer hvornår hver enkelt er vigtig, og giver dig reelle tal at benchmarke imod. Hvis du også evaluerer på pris, se følgeartiklen: Hvad 'Pris per Token' ikke fortæller dig.

De tre metrikker der definerer hastighed

Når du sender en forespørgsel til en LLM API, ankommer svaret ikke på én gang. Det flyder i faser, og hver fase har sin egen ydeevnekarakteristik.

Den fulde latensfordeling:

For en europæisk udvikler der kalder en US-baseret udbyder:

• Netværks-roundtrip: 80-150ms (lysets hastighed gennem fiber - ingen software kan fikse dette)
• TLS handshake: 1-3 ekstra roundtrips på nye forbindelser (brug connection pooling for at undgå dette på efterfølgende forespørgsler)
• Gateway overhead: 10-50ms (autentificering, rate limiting, routing)
• Køtid: 0ms til sekunder (afhænger af belastning og kapacitet)
• Prefill: varierer efter prompt-længde
• Decode: varierer efter output-længde og gennemstrømning

Prefill vs Decode - hvorfor de betyder noget separat:

Prefill behandler hele din input-prompt parallelt. Modellen læser alle dine tokens på én gang og bygger en intern repræsentation (KV-cachen). Denne fase er compute-bound - rå beregningshastighed betyder mest.

Decode genererer output-tokens én ad gangen. Hvert nyt token afhænger af alle tidligere tokens, så det er sekventielt. Denne fase er memory-bound - chippen bruger det meste af sin tid på at læse modelvægte og cache fra hukommelsen og vente på data, før den kan beregne det næste token.

Forskellige hardwarearkitekturer håndterer disse faser forskelligt:

GPU'er er fremragende til prefill - parallel beregning er det, de er designet til - men kæmper med decode. Under decode falder GPU-udnyttelsen til 20-40%, da beregningsenhederne sidder inaktive og venter på hukommelse.

Specialiserede inference-chips som SambaNova's RDU, Groq's LPU og Cerebras WSE er arkitekteret til den memory-bound decode-fase. De holder data on-chip, reducerer hukommelses-roundtrips og opretholder høj udnyttelse selv under sekventiel token-generering. Resultatet: 3-10x hurtigere decode på store modeller.

Netværkslatensen rammer dig to gange - forespørgsel og svar. En udbyder der reklamerer med 300ms TTFT fra Virginia leverer 400ms+ til München. Før nogen inference sker, har du allerede brugt 100ms på ledningen.

Gateway overhead er normalt lille men altid til stede. Køtid er den skjulte variabel - på delt infrastruktur venter du bag andre kunders forespørgsler. Samme API kan føles øjeblikkelig kl. 3 om natten og træg kl. 15. Dedikeret kapacitet eliminerer konkurrence fra andre kunder og gør ydeevnen forudsigelig.

Time to First Token (TTFT)

TTFT måler latensen fra du sender en forespørgsel til det første token begynder at streame tilbage. Det bestemmer oplevet responsivitet. En 200ms TTFT føles øjeblikkelig. En 2-sekunders tom skærm føles ødelagt, selvom den samlede svartid ender med at være den samme.

For korte til mellemlange prompts omkring 1K tokens føles alt under 300ms fremragende for interaktiv chat. Mellem 300-600ms er acceptabelt for de fleste applikationer. Når du krydser 600ms, begynder brugere at bemærke forsinkelsen. Over et sekund antager de, at noget er galt.

Men TTFT skalerer med input-længde, og det er her benchmarks bliver vildledende. En 100-token prompt kan returnere på 200ms. En 10K-token prompt tager længere tid at prefille - forvent 400-800ms selv på hurtig infrastruktur. En 100K-token prompt? Flere sekunder er normalt. TTFT-benchmarks uden input-længde er meningsløse. "300ms TTFT" på en kort prompt er ubemærkelsesværdigt. "300ms TTFT" på 10K tokens er imponerende.

Tre faktorer driver TTFT:

• Prefill compute - modellen skal behandle hele dit input før den genererer output, så længere prompts betyder længere TTFT.
• Køtid - hvis udbyderen er overbelastet, venter din forespørgsel før behandlingen overhovedet begynder.
• Netværkslatens - en EU-bruger der rammer en US-udbyder tilføjer 100-150ms før inference begynder. Fysik tilføjer latens du ikke kan optimere væk, hvilket er grunden til at dataresidency betyder noget for ydeevne, ikke kun compliance.

TTFT betyder mest for interaktive applikationer hvor et menneske ser på skærmen: chat-interfaces, coding-assistenter i IDE'er, voice AI, alt real-time.

Output-gennemstrømning (Tokens per sekund)

Gennemstrømning måler hvor hurtigt tokens streamer efter det første vises. Det bestemmer hvor hurtigt du modtager det komplette svar. For et 1.000-token svar er forskellen mellem 100 tok/s og 400 tok/s 10 sekunder versus 2,5 sekunder. Den forskel vokser med længere outputs.

Gennemstrømning afhænger stærkt af modelarkitektur, hvilket gør sammenligninger på tværs af modeller vildledende. En 70B dense model læser 70B parametre for hvert token. En 671B MoE model som DeepSeek aktiverer måske kun 37B parametre per token - færre aktive parametre betyder hurtigere decode trods større total størrelse. Hardware betyder også noget: GPU'er kæmper med memory-bound decode, mens specialiserede inference-chips som SambaNova's RDU, Groq's LPU og Cerebras WSE er designet specifikt til det. Og inden for samme arkitektur er større modeller altid langsommere - en 7B model vil overgå en 70B model på identisk hardware.

Den eneste retfærdige sammenligning er samme model på tværs af forskellige udbydere. DeepSeek R1 671B kører med 30-80 tok/s hos GPU-baserede udbydere, men SambaNova's RDU leverer 250+ tok/s - den hurtigste registreret af Artificial Analysis for den model. Llama 3.3 70B viser en endnu skarpere forskel: 50-150 tok/s på GPU'er versus 2.100 tok/s på Cerebras WSE og 1.200+ tok/s på Groq's LPU.

Gennemstrømning betyder mest når noget venter på det komplette svar før det handler. Agentic workflows er det klareste eksempel - se hvorfor gennemstrømning betyder noget for agentic coding. Batch-behandling, langform content-generering, enhver workflow hvor total fuldførelsestid driver produktivitet.

End-to-End latens

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

Matematikken er simpel. For et 1.000-token output ved 100 tok/s med 500ms TTFT venter du 0,5 sekunder på det første token, derefter 10 sekunder på resten - 10,5 sekunder i alt. Ved 400 tok/s med 600ms TTFT tager samme output 3,1 sekunder. Den langsommere TTFT opvejes mere end af 4x hurtigere gennemstrømning.

End-to-end latens betyder mest når intet menneske ser det mellemliggende output. Batch-processing pipelines, backend API-kald, SLA-bundne applikationer med krav til total svartid - disse bekymrer sig om hvornår jobbet er færdigt, ikke hvornår det starter.

Hvorfor disse metrikker konflikter

Optimering for én metrik skader ofte en anden.

TTFT vs. gennemstrømning tradeoff:

Prefill-fasen (behandling af dit input) og decode-fasen (generering af output) konkurrerer om de samme hardware-ressourcer. En udbyder kan konfigurere deres infrastruktur til at:

1. Optimere for TTFT: Dedikere flere ressourcer til prefill, starte generering hurtigt, men decode langsommere
2. Optimere for gennemstrømning: Batche flere forespørgsler sammen, højere gennemstrømning per forespørgsel, men længere køtider

Denne tradeoff er ved at ændre sig. Branchen bevæger sig mod disaggregeret inference - at køre prefill og decode på separat, specialiseret hardware. GPU'er håndterer compute-bound prefill effektivt; hukommelsesoptimerede chips håndterer decode. Ved GTC 2026 annoncerede NVIDIA denne retning, og SambaNova samarbejdede med Intel om en heterogen arkitektur: GPU'er til prefill, RDU'er til decode, Xeon til orkestrering. Tidlige resultater viser 50%+ gennemstrømningsgevinster uden TTFT-straf.

For nu kører de fleste udbydere dog stadig begge faser på samme hardware. Samme model fra forskellige udbydere performer forskelligt. Udbyder A koster mindre men har variabel hastighed. Udbyder B koster mere men leverer konsistent ydeevne. Den underliggende model er identisk; infrastrukturvalgene er forskellige.

Kontekstlængde forstærker alt:

De fleste udbydere opkræver samme pris per token uanset kontekstlængde. Men compute-omkostningerne er ikke flade.

Prefill skalerer nogenlunde kvadratisk med kontekstlængde. Modellen beregner attention mellem hvert tokenpar:

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

Reelle tal fra produktionssystemer viser påvirkningen. En 128K kontekst-prompt tager ~4 sekunder at prefille på optimeret infrastruktur. En 1M kontekst-prompt tager ~77 sekunder. Samme model, samme hardware - bare mere input.

Match metrikker til use cases

Interaktiv chat prioriterer TTFT over gennemstrømning. Brugere læser mens tokens streamer, så det første svar betyder mest - de tilgiver langsommere generering hvis svaret starter hurtigt. Agentic workflows vender dette om: agenter venter på komplette svar før de handler, intet menneske ser mellem trinene, så gennemstrømning dominerer. Voice AI har brug for begge - initial svartid påvirker samtaleflow, men taletempo betyder også noget. Batch-behandling bekymrer sig næsten udelukkende om gennemstrømning og total fuldførelsestid. RAG-pipelines falder et sted i midten og balancerer responsivitet med retrieval-latensen der normalt dominerer alligevel.

Det agentiske use case

Agentic coding tools som Cursor, Cline eller Codex CLI illustrerer hvorfor gennemstrømning dominerer nogle workloads. En enkelt coding-opgave kan kræve 50-200+ LLM-kald mens agenten læser filer, bygger kontekst, planlægger en tilgang, genererer kode, kører tests, debugger fejl og itererer indtil den er færdig.

Hvert kald genererer hundredvis af tokens. Ved 100 tok/s tager en 300K token session - almindelig for kompleks refaktorering - omkring 50 minutter inference-tid. Ved 400 tok/s tager samme session 12 minutter. Det er 38 minutter sparet, forskellen mellem at blive i flow og alt-tabbe til Slack mens du venter.

Den skjulte faktor: Konsistens under belastning

Benchmarks viser peak ydeevne. Produktionssystemer oplever variabel belastning.

Hvad du skal spørge udbydere om:

• P50 vs P99 latens: 99. percentil viser worst-case ydeevne. Hvis P99 er 5x højere end P50, vil du have frustrerede brugere.
• Rate limits: Kan du faktisk ramme de hastigheder de reklamerer med, eller throttler limits dig først?
• Ydeevneforringelse ved skalering: Holder gennemstrømningen når du sender 100 forespørgsler/sekund?

Artificial Analysis udgiver uafhængige benchmarks der fanger denne varians. Deres metodologi tester udbydere kontinuerligt og viser ikke kun peak ydeevne men konsistens over tid.

Sådan benchmarker du selv

Stol ikke på marketing-tal. Kør dine egne benchmarks med dine faktiske workloads.

Test med dine reelle prompt-længder - ydeevne varierer markant mellem 1K og 100K input-tokens, og de fleste marketing-benchmarks bruger korte prompts der smigrer resultaterne. Test også dine forventede output-længder, da korte completions og langform-generering har forskellige ydeevneprofiler. Hvis du kører samtidige forespørgsler, benchmark det mønster specifikt i stedet for at teste enkelte forespørgsler isoleret. Vigtigst af alt, test i peak-timer. Off-peak benchmarks viser best-case ydeevne som du sjældent vil se i produktion. Artificial Analysis udgiver uafhængige udbydersammenligninger hvis du vil have en neutral baseline, men intet erstatter timing-instrumentering i dit eget produktionsmiljø.

Hvilken metrik betyder mest?

Din workload bestemmer svaret. Hvis brugere ser på skærmen, prioriter TTFT - under et sekund svarstart føles øjeblikkeligt. Hvis agenter venter på svar, prioriter gennemstrømning - hurtigere tokens betyder hurtigere task completion. Hvis du behandler i skala, prioriter end-to-end latens og konsistens - total job completion tid og forudsigelige SLA'er betyder mere end peak hastighed.

De fleste produktionsapplikationer har brug for acceptabel ydeevne på tværs af alle tre. Lynhurtig gennemstrømning med 3-sekunders TTFT vil frustrere interaktive brugere. Øjeblikkelig TTFT med 50 tok/s gennemstrømning vil flaskehalse agentic workflows. Tradeoffs er reelle.

Test det selv: benchmark.infercom.ai lader dig køre dine faktiske prompts mod vores infrastruktur. Eller se vores publicerede benchmarks for standardiserede sammenligninger.

Hvorfor vi kalder det "Ultraspeed"

Dette er grunden til at vi brander vores MiniMax M2.7 som Ultraspeed:

1. SambaNova dataflow-arkitektur. Formålsbygget inference-hardware, ikke genbrugte GPU'er. RDU'en eliminerer hukommelsesflaskehalsen der begrænser GPU-gennemstrømning. Hvordan dataflow leverer hastighed
2. 428 tokens per sekund. Målt gennemstrømning der gør agentic workflows praktiske. Ved denne hastighed fuldfører en 50-trins coding-opgave der ville tage en time på standard GPU-infrastruktur på minutter.
3. 690ms TTFT på 10K input-tokens, under 150ms på korte prompts. Målt fra Tyskland til vores München-infrastruktur - EU-brugere får latensfordelen uden 100ms+ netværksstraf til US-datacentre.

Ultraspeed er delt infrastruktur - du drager fordel af arkitekturen og EU-hosting, men køtid varierer med platformbelastning som enhver delt service.

Prøv MiniMax M2.7 Ultraspeed

Bundlinjen

Hastighedspåstande uden kontekst er meningsløse. Spørg altid: hvilken metrik, hvilken input-længde, hvilken baseline? "Hurtigste LLM API" kunne betyde hurtigste TTFT på korte prompts, højeste gennemstrømning på en specifik model, eller laveste end-to-end latens under ideelle forhold. Uden den kontekst fortæller påstanden dig intet.

Din workload bestemmer hvilken metrik der betyder noget. Interaktive applikationer har brug for hurtig TTFT. Agentic workflows har brug for høj gennemstrømning. Batch-behandling har brug for konsistent end-to-end latens. De fleste produktionssystemer har brug for acceptabel ydeevne på tværs af alle tre.

Konsistens under belastning betyder lige så meget som peak ydeevne. En udbyder der leverer 400 tok/s kl. 3 om natten men 150 tok/s i arbejdstiden er ikke faktisk en 400 tok/s udbyder for din produktions-workload.

Netværkslatens er fysik, ikke software. For EU-brugere vil en inference-udbyder i München altid være hurtigere end én i Virginia - ingen optimering kan overvinde lysets hastighed. Dataresidency handler ikke kun om compliance; det er en ydeevnefordel.

Kilder

• LLM API Latency Benchmarks 2026 - Kunal Ganglani
• Time to First Token (TTFT) - IBM
• Tokens Per Second: LLM Speed Benchmark Guide - Morph
• SambaNova - Artificial Analysis
• Inference Speed or Throughput? With RDUs - SambaNova
• Key metrics for LLM inference - BentoML
• Cerebras Llama 3.1 405B at 969 tokens/second