Skip to main content
Intermediate8 min read41 of 59

LLM Inference Latency: TTFT, Inter-Token Time, and Throughput

How to measure perceived LLM latency, interpret TTFT and inter-token time, and use hardware numbers as directional baselines rather than promises.

LLM Inference Latency: TTFT, Inter-Token Time, and Throughput

[Definition] LLM latency is not one number. Time to first token (TTFT) measures how long a user waits before streaming begins; inter-token latency (ITL) measures how smooth generation feels; throughput measures how much work the serving system completes over time.

Split the request into prefill and decode

text
request accepted → queue → prefill prompt → first token → decode token 2…N → final token
MetricWhat it measuresUser consequence
queue timewaiting for capacitythe app feels unavailable
TTFTqueue + prefill + first decodehow responsive chat feels
ITL / TPOTtime per generated tokenhow smooth streaming feels
E2E latencyfirst byte to final tokentotal task completion time
tokens/secoutput tokens divided by decode timesystem generation rate

A fast total response can still feel slow when TTFT is high. Conversely, a low TTFT with 100ms ITL produces a visibly sluggish stream.

Directional hardware baselines

The LLM-inference guide reports this directional, third-party benchmark example for a 7B-class model with a 350-token prompt and 150-token output. It is not an SLA and should not be copied into a production contract.

HardwarePrefillPer-token decodeApprox. request total
NVIDIA T4~75ms~46ms~7s
NVIDIA A10~39ms~23ms~3.5s
NVIDIA A100~16ms~6ms~1s

A 70B-class model can require 50–100ms or more per generated token depending on precision, parallelism, prompt length, and batch pressure.

[Key Insight] Use TTFT under 500ms and ITL under 30ms as useful interactive-chat targets, not universal values. Measure on your model, GPU, tokenizer, prompt mix, and concurrency profile.

What moves each part of the curve

TTFT

TTFT rises with queueing, prompt length, cold model loads, prefix-cache misses, and large prefill batches. Chunked prefill can prevent one long prompt from blocking short interactive requests.

ITL

Decode is commonly bandwidth-bound. ITL rises when the KV cache consumes headroom, too many sequences decode together, preemption occurs, or tensor-parallel communication dominates.

E2E

A useful approximation is:

text
E2E ≈ queue + TTFT + (output_tokens - 1) × ITL

For a 300-token answer, an extra 10ms of ITL adds about three seconds after the first token.

Build a latency baseline before tuning

Record at least these dimensions with every benchmark:

  • model and precision;
  • GPU/accelerator and parallelism setting;
  • prompt-token and output-token distributions, not one fixed prompt;
  • concurrent requests and queue policy;
  • prefix-cache hit rate and cache occupancy;
  • TTFT P50/P95/P99, ITL P50/P95/P99, E2E P50/P95/P99;
  • errors, cancellations, and preemption count.

Use separate tests for a single request, steady concurrency, burst traffic, long prompts, and long outputs. A system that passes the single-request demo may fail the burst test through queue growth.

Practical interventions

ProblemFirst investigation
high TTFTqueueing, prefill size, prefix-cache hit rate, cold starts
high ITLKV occupancy, max concurrent sequences, precision, bandwidth
high P99 onlyadmission control, long-prompt convoy, preemption, uneven routing
low tokens/secbatching, model parallelism, eager-mode configuration, kernel choice
rising cost with no quality gainoverlong context, repeated prefixes, output cap, wrong precision tier

Continue the inference path

Read KV Cache before increasing concurrency, then Continuous Batching and Admission Control to protect the tail. The LLM Inference area contains the KV sizing worksheet and the Pro serving path.