AI
TTFT — Time to First Token
Den vigtigste måling for opfattet AI-reaktionsevne
Overblik
Time to First Token (TTFT) måler forsinkelsen fra det øjeblik din applikation sender en forespørgsel til en LLM, til det første token i svaret modtages. I streaming-applikationer svarer det til "tid til første ord" — det øjeblik applikationen holder op med at få brugeren til at vente og begynder at bevise, at den virker.
En forskel på 500 ms i TTFT kan være det, der afgør, om en bruger oplever din AI-funktion som "øjeblikkelig" eller "langsom". Mens den samlede svartid har betydning, er TTFT den absolut vigtigste måling for brugerens opfattelse i streaming-applikationer, fordi den styrer, hvornår brugeren ser det første tegn på fremskridt.
Nøglebegreber
- TTFTs tre komponenter: TTFT er ikke én enkelt operation — det er en sekvens. (1) Netværkslatens: transporttid fra din klient til API'et og tilbage. (2) Kø-ventetid: tid brugt på at vente på ledige beregningsressourcer under belastning. (3) Prefill-fasen: modellen behandler hele prompten og bygger sin interne key-value-cache, inden det første output-token kan genereres. Prefill-fasen er typisk den dominerende faktor, særligt ved lange prompts.
- TTFT vs. samlet latens: Samlet latens = TTFT + (antal output-tokens × tid-per-token). For streaming-applikationer er TTFT vigtigere end den samlede latens, fordi den bestemmer, hvornår brugeren ser den første respons og dermed sætter den indledende opfattelse af reaktionsevnen.
- Streaming er ikke valgfrit: TTFT er usynlig i ikke-streaming-kald — det fulde svar bufferlagres inden levering. Brug altid streaming for nøjagtig TTFT-måling og for at levere responsive brugeroplevelser. Streaming reducerer ikke den underliggende TTFT, men eksponerer den direkte over for brugeren frem for at skjule den.
- Promptlængdens betydning: Hvert token i din prompt skal behandles under prefill-fasen, inden ét eneste output-token kan genereres. En prompt med 10.000 tokens kan tilføje 500 ms eller mere til TTFT, uanset model eller hardware. I RAG-applikationer er beskæring af hentet kontekst ofte den mest effektive TTFT-optimering.
- Modelvalg og infrastruktur: Mindre, hurtigere modeller (fx GPT-4o mini, Claude 3.5 Haiku) tilbyder væsentlig lavere TTFT end større modeller til en brøkdel af prisen. Dedikeret kapacitet (Provisioned Throughput Units / PTU'er) eliminerer kø-forsinkelser under belastning. Adskillelse af interaktive workloads fra batch-jobs forhindrer kø-tid i at akkumulere.
Nøglefakta
- Applikationer med TTFT under 500 ms har 23% højere sessionsafslutningsrater sammenlignet med langsommere alternativer, ifølge Azure OpenAI-forskning.
- Branchestandard SLO-mål: interaktiv chat ved 500 ms p95, copilot- og autocompletefunktioner ved 300 ms p95. Batchbehandling har intet strikt TTFT-SLO, men bør overvåges for anomalier.
- Optimering af TTFT involverer ofte infrastrukturændringer, der også reducerer de samlede token-behandlingsomkostninger med 15–30%, hvilket gør det til en gevinst for både UX og økonomi.
- Et gennemsnitligt TTFT på 300 ms kan skjule p99-spikes på 2 sekunder. Overvåg altid p95 og p99-percentiler, og spor goodput — andelen af forespørgsler der opfylder dit SLO — frem for gennemsnitlig TTFT alene.
- Azure OpenAIs indholdssikkerhedsfiltre tilføjer overhead til hver forespørgsel. For applikationer med lav risiko kan modificerede indholdsfilteringspolitikker reducere TTFT mærkbart.
- TTFT bør altid måles sammen med Inter-Token Latency (ITL) og Tokens Per Second (TPS) — TTFT fortæller dig, hvornår det første token ankommer, men ikke hvor hurtigt modellen genererer de efterfølgende tokens.