Aekor

Aekor
专注于用户阅读体验的响应式博客主题
  1. 首页
  2. Blog
  3. 正文

首 Token 延迟实测:六个模型在三种提示词长度下的真实表现

2026-10-13 99451点热度 0人点赞 0条评论

一个语音助手 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
原始数据:每个模型每种长度的中位数与 P90
原始数据:每个模型每种长度的中位数与 P90

短提示词:五个模型挤在一秒内

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 秒。

对大模型处理长而密集的提示词来说,这不算不可接受。但如果你的应用要求这类输入下也稳定亚秒响应,就得提前知道这件事。

短提示词下的 TTFT 分布
短提示词下的 TTFT 分布
长提示词下的 TTFT 分布
长提示词下的 TTFT 分布

两次异常: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 的数据说明,短提示词下的表现预测不了长上下文下的表现。选型必须用真实业务的提示词长度去测。

如果你正在用无服务器推理搭需要实时反馈的应用,最可靠的做法不是看宣传指标,而是在上线前用真实请求模式跑一遍候选模型。这组测试的脚本和原始数据都可以直接拿来改。

本作品采用 知识共享署名 4.0 国际许可协议 进行许可
标签: 大模型评测 延迟
最后更新:2026-10-18

Aekor

这个人很懒,什么都没留下

点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

使用AI教程

  • API报错解决方案
  • API 基础知识
  • API Key 获取
  • 最新接入教程

分类

  • Blog
  • Oracle 数据库
  • TradingAgents-CN
  • 使用教程
  • 数据库

COPYRIGHT © 2026 Aekor. ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang