Time to First Token (TTFT): What We Measured

Time to first token (TTFT) is the delay between sending a prompt and receiving the first streamed token, and in our 2026-07-26 streaming test it ranged from 0.71s on native DeepSeek to 3.16s on routed Qwen3-235B. TTFT decides whether a chat reply feels instant or sluggish, so it matters more than raw speed for interactive apps.

Total time tells you how long the whole answer takes. TTFT tells you how long the user stares at a blank box before anything happens. For a chatbot, a translation widget, or an autocomplete field, that first moment is what people perceive as speed, even when the full generation runs several seconds longer.

Time to first token (verified 2026-07)

Time to first token is the latency metric that measures the gap between sending a request and receiving the first streamed token of any kind. In a chat interface it governs perceived responsiveness, because a reply that starts flowing in under a second feels instant even when the full answer takes several seconds to finish streaming.

We streamed seven endpoints three times each on 2026-07-26 with one fixed prompt, temperature 0, and reported the median of the three runs. DeepSeek V4-Flash was measured natively on api.deepseek.com; every other figure below is OpenRouter-routed and carries a needs_native_reverify flag. This is a single-prompt, single-region snapshot, not a load test.

In our 2026-07-26 streaming benchmark, DeepSeek V4-Flash on api.deepseek.com posted the fastest median TTFT at 0.71 seconds, while the same prompt sent through an OpenRouter-routed path returned its first token at 2.54 seconds. Qwen3-235B was slowest at 3.16 seconds. These are three-run medians from one region.

Kimi K2 was the fastest routed Chinese endpoint to a usable first token at 2.27 seconds (MiniMax's 1.50s TTFT was hidden reasoning, unreadable until 10.68s). Note that cheap and fast are different axes: Qwen3-235B was the slowest to first token in this set despite being the cheapest model in our earlier task benchmark. A low price does not buy a low latency, and buyers who conflate the two get surprised.

Why TTFT dominates chat responsiveness

Streaming APIs push tokens over a server-sent-event connection as the model generates them, so the interface can render text the instant the first token lands. That is why TTFT, not total wall time, sets the felt experience. A model that streams its first token in 0.7 seconds and finishes in 4 seconds feels faster than one that stays silent for 3 seconds and finishes in 4.

According to DeepSeek's API documentation, the chat completions endpoint streams responses incrementally when the stream parameter is enabled, delivering deltas as they are produced rather than buffering the full reply. DeepSeek V4-Flash serves these requests directly from api.deepseek.com, which is the native path we measured.

Routing changes the picture. OpenRouter and similar aggregators add a hop between your client and the model host, and that hop showed up clearly in our data. The same DeepSeek family answered at 0.71s native versus 2.54s routed, and decode throughput roughly halved. Treat that gap as a routing-overhead signal rather than a perfect A/B, because the routed alias may land on a different physical host or build than the native endpoint.

According to OpenAI's API reference, streaming works the same way across compatible endpoints: set the stream flag and consume delta events. That shared contract is why a single benchmark harness can time DeepSeek, Qwen, GLM, Kimi, MiniMax, and GPT-4o the same way and compare their first-token latency fairly.

The reasoning twist: when TTFT lies

TTFT can mislead on reasoning models that stream thinking tokens first. GLM-5 recorded a 2.5-second TTFT in our runs, yet its first user-visible content token did not arrive until 13.9 seconds. MiniMax-M2.5 showed the same pattern, thinking for 10.7 seconds before any answer text appeared. The stopwatch said fast; the user waited long.

This happens because reasoning models emit hidden thinking tokens before the answer. GLM-5 streamed 807 reasoning tokens on the median run before its first content token, so a naive TTFT reading of 2.5s badly overstates responsiveness. The metric that matches what a person sees is time to first content token.

Time to first content token (TTFCT) is the user-felt variant of TTFT that measures when the first token a person actually reads arrives. On non-reasoning models TTFT and TTFCT are identical, but on reasoning models TTFCT can lag TTFT by ten seconds or more while the model thinks through its answer before writing it.

This is a fit question, not a quality knock. GLM-5 emits reasoning tokens before content tokens by design, and that overhead can be worth it on hard multi-step problems. On a simple list-generation prompt like ours it is pure latency tax. If your workload is interactive chat, watch TTFCT; if it is a hard offline reasoning job, the thinking delay may pay for itself.

According to Alibaba Cloud's Model Studio documentation, Qwen models expose streaming through the same incremental-output mechanism, and Qwen3-235B behaved as a plain instruct model in our runs with TTFT equal to TTFCT at 3.16s. No thinking delay, but the slowest first token in the set.

First-hand: what we measured

We streamed each of the seven endpoints three times on 2026-07-26 using one fixed prompt, temperature 0, and max_tokens 4000, then reported medians. The measured TTFT spread ran from 0.71s (DeepSeek native) to 3.16s (routed Qwen3-235B). GLM-5 and MiniMax-M2.5 split TTFT from first-content-token sharply: GLM-5 at 2.5s versus 13.9s, MiniMax at 1.5s versus 10.7s. All 21 runs succeeded. DeepSeek native was measured on api.deepseek.com; every routed figure carries needs_native_reverify, and none of this is a load test.

FAQ

What is a good TTFT for a chatbot? Under roughly one second feels instant. In our snapshot only native DeepSeek V4-Flash (0.71s) cleared that bar; routed Chinese endpoints landed between 1.5s and 3.2s, and reasoning models felt far slower because their visible content lagged behind their first token.

Is TTFT the same as tokens per second? No. TTFT measures the wait before the first token; tokens per second measures how fast text flows after that. A model can win one and lose the other. Compare both on the fastest Chinese LLM API hub.

Why was routed DeepSeek so much slower than native? Routing adds an aggregator hop. The same DeepSeek family answered at 0.71s native versus 2.54s routed in our runs, and decode throughput roughly halved. Read it as a routing-overhead signal, since the routed alias may hit a different host or build.

Why does GLM-5 show a fast TTFT but feel slow? GLM-5 streams thinking tokens first. Its 2.5s TTFT counts the first reasoning token, but the first content token a user reads did not arrive until 13.9s on the median run. Watch TTFCT, not TTFT, for reasoning models.

Do these numbers apply to my region and workload? Treat them as a dated, single-region, single-prompt snapshot from 2026-07-26, not a guarantee. TTFT shifts with network distance, output length, provider load, and cold starts. See how region and network affect latency in Chinese vs Western LLM latency.

This article is part of the fastest Chinese LLM API speed cluster. For how thinking overhead trades against responsiveness, see Chinese LLM reasoning vs instruct.

Author: Kevin Fan, Customer Success Manager. Last verified: 2026-07-26.