Chinese LLM API Latency: 3-Run Streaming Benchmark

We streamed seven LLM endpoints three times each on 2026-07-26 and measured Chinese LLM API latency from 0.71s time-to-first-token (DeepSeek native) to 3.16s (Qwen3-235B routed), a single-prompt, single-region snapshot, not a load test.

This is the methodology and full-data page for our speed cluster. Other pages in the cluster cite the numbers here, so this article explains exactly how the run was set up, what each metric means, and where the honest limits are. It measures speed only. It makes no claim about answer quality or accuracy anywhere.

How we ran it

We sent one fixed prompt, "List 10 numbered one-sentence facts about the HTTP protocol. Output only the list.", at temperature 0 with max_tokens 4000. Each endpoint ran three times over server-sent-events streaming, and we report the median of the three. DeepSeek V4-Flash was measured both on native api.deepseek.com and through an OpenRouter route, giving a first-hand router-overhead pair. Every other model was OpenRouter-routed, which we disclose and flag for native reverification.

Three metrics do the work, and mixing them up is the most common mistake in speed writeups.

TTFT is a latency metric that measures the time from request to the first streamed token of any kind, reasoning tokens included. TTFCT is the first-content-token metric that captures when a user first sees usable output, so on a reasoning model TTFCT arrives well after TTFT. Decode throughput is tokens per second, computed as completion tokens divided by the decode window after the first token. Total is wall-clock time to the final token.

We streamed seven endpoints three times each on 2026-07-26 using one fixed prompt, temperature 0, and max_tokens 4000, then reported medians. DeepSeek V4-Flash ran on native api.deepseek.com; every other figure was OpenRouter-routed and needs native reverification. All 21 of 21 runs completed successfully.

Chinese LLM API latency (verified 2026-07)

DeepSeek V4-Flash native posted the fastest first token at 0.71s and the fastest Chinese decode at 95.8 tokens per second. GPT-4o, the Western baseline, won overall throughput at 174 tokens per second. Kimi K2 led routed Chinese endpoints to a usable first token at 2.27s; Qwen3-235B was slowest at 3.16s.

First-hand evidence: the router-overhead pair

Here is the finding we could not have read off any vendor page, because it required measuring the same model two ways at the same moment.

In the router-overhead pair, native DeepSeek V4-Flash reached its first token in 0.71s and decoded at 95.8 tokens per second, while the same family routed through an aggregator reached first token in 2.54s and decoded at 39.5 tokens per second. Routing added roughly 1.8s and about halved throughput.

We measured this as a 3-run median, not a single lucky call. The caveat matters: the routed deepseek/deepseek-chat alias may point at a different DeepSeek build than the native deepseek-chat (V4-Flash), and the routed path may land on a different physical host. Treat the pair as a routing-overhead signal, not a perfect A/B of identical builds. According to DeepSeek's API docs, the native API supports SSE streaming via the stream parameter, which is exactly what let us timestamp the first token.

Per-model notes

DeepSeek V4-Flash streamed its first token in 0.71s on native infrastructure, the fastest TTFT in the set and the fastest Chinese decode at 95.8 tokens per second. On simple generation like this prompt, that combination made it feel the most responsive of the Chinese endpoints.

GPT-4o decoded 174 tokens per second, the fastest throughput of any endpoint here and the reason it also posted the shortest total wall time at 3.57s. The Western baseline wins the throughput axis; we do not claim any Chinese model is fastest on tokens per second overall. According to OpenAI's model documentation, GPT-4o streams over the same SSE transport we used everywhere, so the comparison is apples to apples on transport.

Kimi K2 reached a usable first token fastest among routed Chinese endpoints at 2.27s but a modest 39.4 tokens per second decode, so its total ran to 8.79s. Qwen3-235B-A22B was the slowest to first token at 3.16s despite being the cheapest model in our earlier task benchmark. Cheap and fast are different axes, and this run shows they do not always move together.

GLM-5 and MiniMax-M2.5 behaved as reasoning models on this prompt. They streamed thinking tokens early, at 2.5s and 1.5s TTFT, but the first token a user would actually read arrived at 13.9s and 10.7s respectively, after 807 and 449 reasoning tokens. That is a fit trade-off, not a quality judgment.

Frame the reasoning tax as fit. Thinking first can be worth the wait on a hard multi-step problem, and it is pure latency overhead on a trivial listing task like this one. According to MiniMax's platform docs, the M-series can emit reasoning content ahead of the final answer, which matches the gap we saw between TTFT and first content token. In our earlier 2026-07-10 task benchmark, a different non-streaming prompt with shorter outputs, MiniMax-M2.5 posted a 3.64s median on short tasks, so trace depth clearly varies with prompt and configuration.

Honest limits

This is three runs, one prompt, one region, one moment. It is a snapshot, not a load test, so it says nothing about behavior under concurrency, at long output lengths, or from a different network location. Routed latency folds in an aggregator hop and possibly a different host than the vendor's own endpoint, and the alias caveat above applies to every routed row. Output length also shifts decode math, since reasoning models emitted many more tokens than the instruct models here. Read the table as a directional first-token-and-throughput picture from 2026-07-26, and reverify native endpoints before making a production call.

For the cross-cluster synthesis and the ranked recommendation, see our fastest Chinese LLM API benchmark hub. For how routing overhead compares against Western baselines, see Chinese vs Western LLM latency, and for the cost axis these speed numbers deliberately ignore, see DeepSeek API pricing.

FAQ

What is TTFT and why does it differ from first content token? TTFT is the time to the first streamed token of any kind, reasoning included. First content token is when usable output appears. On instruct models the two are identical; on reasoning models like GLM-5 the content token lagged TTFT by more than 11s in our run.

Which Chinese API had the lowest latency? DeepSeek V4-Flash on native api.deepseek.com, at 0.71s median TTFT and 95.8 tokens per second decode. Among routed endpoints, Kimi K2 reached a usable first token fastest at 2.27s. All routed figures need native reverification.

Did any Chinese model beat GPT-4o on throughput? No. GPT-4o decoded 174 tokens per second, the fastest in the set. DeepSeek native was the fastest Chinese decode at 95.8 tokens per second. Throughput and first-token latency are separate axes and did not rank the same way.

Why was Qwen3-235B slowest to first token if it is cheap? Price and latency are independent. Qwen3-235B-A22B posted the slowest median TTFT at 3.16s in this routed run even though it was cheapest in our earlier task benchmark. Cost tells you nothing reliable about speed.

Last verified: 2026-07-26. Author: Kevin Fan, Customer Success Manager, independent editorial team at China LLM Directory.