一个语音助手 Demo 跑得好好的,上线就被人说「反应太慢」。翻模型规格表,每家都写着自己低延迟,但真到用户盯着屏幕等回复的时候,谁快谁慢,其实没底。
更麻烦的是这种等待没法靠猜。你挑三四个模型,文档都说自己快,但没人告诉你:在你实际用的提示词长度下,谁真能一秒内开口?把文档从 500 字加到 10000 字之后谁会突然变慢?谁平时正常、却偶尔卡上十几秒?
Aekor 这次直接把这件事测了。六个模型,三种提示词长度,380 次调用,全部跑在无服务器推理上,Tier 1 定价档,也就是新账户的默认档位。
测试对象:Gemma 4、GLM-5.3、Kimi K2.6、DeepSeek V3.2、DeepSeek V4.1 Flash、Llama 4 Maverick。
为什么只看 TTFT
首 Token 延迟(Time to First Token,TTFT)不等于总响应时间。一个模型可能两秒才开始输出,但之后流式生成很快;另一个模型立刻开始,但每字都慢。前者对用户来说是「想了很久才说话」,后者是「边想边说」。
但对聊天、语音、Agent 这类交互式应用,用户感受到的等待就是第一段内容出现之前那段时间。所以 TTFT 决定了产品给人「反应灵敏」还是「卡住了」的印象。
这里有个容易忽略的细节:推理模型的思考过程也算输出。Kimi K2.6 和 DeepSeek V4.1 Flash 总是先吐推理内容,GLM-5.3 在长提示词下也会。如果只监听最终答案,就会把前面那段等待算漏。
测试方法
三种提示词长度:短提示词一个简单问题,约 20–50 token;中等约 500 token,一段摘录加一个摘要请求;长约 5000–10000 token,更长的摘录加一个问题。
每个模型和长度组合重复 20 次。另外对 DeepSeek V3.2 单独做了 20 次精确 10000 token 的测试,用模型自己的 tokenizer 计数,不用字符数估算。全部合计 380 次调用。
为了避免命中提示缓存,每条提示词开头都插了随机 UUID:
import uuid
session_marker = str(uuid.uuid4())
full_prompt = f"[session:{session_marker}]\n{prompt_text}"计时逻辑在请求发出前启动,逐块接收流式响应,在第一段真实内容出现时打时间戳:
import time
start_time = time.perf_counter()
first_token_time = None
stream = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": full_prompt}],
stream=True,
max_tokens=50,
)
for chunk in stream:
if chunk.choices:
delta = chunk.choices[0].delta
content_piece = getattr(delta, "content", None) or getattr(delta, "reasoning_content", None)
if content_piece and first_token_time is None:
first_token_time = time.perf_counter()
ttft = first_token_time - start_time那行 getattr(delta, "content", None) or getattr(delta, "reasoning_content", None) 是踩坑之后加的。第一版脚本只检查 content,390 条记录里有 127 条没记到 TTFT,因为有些模型把 50 token 的输出预算全用在推理上了,还没轮到最终答案,额度就耗尽了。
要让输入精确到 10000 token,用的是二分查找:
low, high = 1, len(sentences)
best_text, best_count, best_diff = None, None, float("inf")
while low <= high:
mid = (low + high) // 2
candidate_text = " ".join(sentences[:mid]) + question_suffix
tok_count = count_tokens(candidate_text, "deepseek-3.2")
diff = abs(tok_count - 10000)
if diff < best_diff:
best_text, best_count, best_diff = candidate_text, tok_count, diff
if tok_count < 10000:
low = mid + 1
elif tok_count > 10000:
high = mid - 1
else:
break
短提示词:五个模型挤在一秒内
GLM-5.3 中位 0.88 秒,Kimi K2.6 是 0.90,DeepSeek V4.1 Flash 是 0.90,Gemma 4 是 0.93,Llama 4 Maverick 是 0.98。对于一个简单问题,这些模型基本每次都能在一秒内开口。
DeepSeek V3.2 明显慢一档:短提示词中位 1.43 秒,输入涨到 10000 token 时升到 1.9 秒,P90 达到 4.1 秒。
对大模型处理长而密集的提示词来说,这不算不可接受。但如果你的应用要求这类输入下也稳定亚秒响应,就得提前知道这件事。


两次异常:186.9 秒和 78.3 秒
这是整组测试里最值得记下来的发现。DeepSeek V3.2 的 80 次调用中,有两次等待远超正常水平:一次 186.9 秒才收到第一个 token,另一次 78.3 秒。
注意,一旦开始输出,这两次都正常生成答案,50 token 的输出大约 4 秒完成。也就是说延迟全部发生在模型开口之前,不是生成慢。
另外五个模型的 300 次调用里,没有一次 TTFT 接近 10 秒。
80 次里两次,样本太小,不能据此断言它有固定故障率。但作为工程信号,它足够重要:如果你的产品用这个模型做实时对话,必须设超时和备用模型,否则用户会遇到「点了没反应,等三分钟」。

小模型不一定快
Gemma 4 被选作「体量小、理论上快」的基线。短提示词下 0.93 秒,符合预期。但长提示词下升到 3.35 秒,是所有模型里增幅最大的,其他模型长提示词下都低于 2.1 秒。
结论很直接:模型参数量不能单独决定它处理长提示词的速度。如果你的应用经常塞大量上下文,只看模型大小或短提示词跑分,会得出完全错误的判断。
这组测试看不出来的东西
只用一个账户,Tier 1 默认配置,在 2026 年 9 月某一天的约 10 分钟内跑完。推理服务的容量和请求路由都会变,同样的方法下周重测,结果可能不一样。
那两次异常等待是实际观察,不是故障率。严谨的说法只能是:这次测试里 DeepSeek V3.2 出现了两次长时间等待,其他模型没有。
数据、脚本和完整提示词都公开,任何人都能复现。这一点比结论本身更重要——延迟这种指标,别人的数字只能当参考,自己的业务提示词才是唯一可信的基准。
选型上的两条实际建议
第一,给偶发长尾留后路。 DeepSeek V3.2 这类模型偶尔会出现远超典型值的 TTFT。用在聊天、语音这类需要即时反馈的场景,超时机制和备用模型不是可选项。
第二,别假设小模型一定快。 Gemma 4 的数据说明,短提示词下的表现预测不了长上下文下的表现。选型必须用真实业务的提示词长度去测。
如果你正在用无服务器推理搭需要实时反馈的应用,最可靠的做法不是看宣传指标,而是在上线前用真实请求模式跑一遍候选模型。这组测试的脚本和原始数据都可以直接拿来改。
文章评论