大模型速度排行榜:输出速度、首字延迟与总响应时间
大模型哪个响应最快?分别比较持续输出速度、首字延迟和端到端响应时间,解释三项指标的区别,并结合能力与成本为聊天、实时应用和批处理任务筛选候选。
快速结论
30 秒先看结论
先看关键结论,再结合任务、预算和等待时间做选择。

选型对照
持续输出速度前列模型
按每秒输出 token 数排列,并同时列出首字延迟、总响应时间、综合智力和任务成本,避免把单一速度指标当成完整体验。
输出速度
2157.9 t/s
首字延迟
0.65 秒
总响应时间
0.88 秒
综合智力
11.8
任务成本
暂无数据
输出速度
749.4 t/s
首字延迟
3.41 秒
总响应时间
4.08 秒
综合智力
21.4
任务成本
$0.079
输出速度
427.5 t/s
首字延迟
1.67 秒
总响应时间
2.84 秒
综合智力
1.0
任务成本
暂无数据
输出速度
389.4 t/s
首字延迟
0.98 秒
总响应时间
7.40 秒
综合智力
30.3
任务成本
$0.091
输出速度
384.8 t/s
首字延迟
0.76 秒
总响应时间
7.25 秒
综合智力
17.8
任务成本
$0.024
输出速度
374.7 t/s
首字延迟
7.62 秒
总响应时间
8.96 秒
综合智力
36.5
任务成本
$0.096
数据更新于 2026年8月3日 20:42;输出速度、首字延迟和总响应时间分别排序。三项指标含义不同,不能合并成一个未经说明的“最快”结论。
大模型哪个响应最快
如果你关心模型开始输出后生成得多快,当前输出速度前三是 Celeris-1、Mercury 2、LFM2.5-VL-1.6B。如果你关心点击发送后多久看到第一个字,应看首 token 延迟;如果你关心完整任务多久结束,则要看端到端响应时间。
同一个型号可能在其中一项很快、另一项一般。聊天产品、代码助手和后台批处理对“快”的定义也不相同。
持续输出速度排行榜
- Celeris-1 — 2157.9 token/秒
- Mercury 2 — 749.4 token/秒
- LFM2.5-VL-1.6B — 427.5 token/秒
- Step 3.7 Flash — 389.4 token/秒
- HyperNova 60B 2605 — 384.8 token/秒
- Gemini 3.5 Flash-Lite — 374.7 token/秒
- LFM2.5-8B-A1B — 337.3 token/秒
- Nemotron 3 Nano Omni 30B A3B Reasoning — 316.9 token/秒
- Gemini 3.1 Flash-Lite — 309.9 token/秒
- Nova Micro — 286.5 token/秒
持续输出速度表示模型已经开始生成后,每秒输出多少 token。它直接影响长回答、代码生成和流式输出的阅读节奏,但不包含请求发出后的首次等待。
首字延迟排行榜
- Command A+ — 0.40 秒
- Ministral 3 3B — 0.64 秒
- Celeris-1 — 0.65 秒
- Qwen3.5 4B — 0.65 秒
- North Mini Code — 0.66 秒
- Gemma 4 E4B — 0.72 秒
- GPT-5.6 Terra (Non-reasoning) — 0.75 秒
- Ministral 3 8B — 0.76 秒
- HyperNova 60B 2605 — 0.76 秒
- Qwen3.5 4B — 0.77 秒
首 token 延迟是从发送请求到收到第一个 token 的时间。搜索框、客服、聊天和实时助手通常对这项指标更敏感,因为用户会把“迟迟没有反应”理解为卡住。
总响应时间排行榜
- Celeris-1 — 0.88 秒
- Nova Micro — 2.64 秒
- Ministral 3 3B — 2.82 秒
- LFM2.5-VL-1.6B — 2.84 秒
- NVIDIA Nemotron 3 Nano — 3.08 秒
- GPT-5.6 Luna (Non-reasoning) — 3.87 秒
- Gemini 3.5 Flash (minimal) — 3.95 秒
- Qwen3.5 Omni Flash — 4.03 秒
- Mercury 2 — 4.08 秒
- Mistral Small 4 — 4.11 秒
端到端响应时间从请求开始算到完整回答结束。它同时受到首字延迟、推理过程、输出长度和持续输出速度影响,更接近“这次任务多久完成”。
为什么最快不一定最好用
模型速度只能说明等待体验,不能说明答案是否正确、任务是否完成或输出是否值得保留。当前综合智力靠前的候选为:
- Claude Opus 5 (max) — 60.7
- Claude Opus 5 (xhigh) — 60.1
- Claude Fable 5 (with fallback) — 59.9
- GPT-5.6 Sol (max) — 58.9
- Claude Opus 5 (high) — 58.9
真实产品通常需要设置能力底线,再在合格模型中比较速度。如果速度更快但错误率更高、需要频繁重试,最终完成时间和总成本反而可能更差。
按产品场景选择速度指标
- 聊天与客服: 首字延迟决定是否“立即有回应”,输出速度决定后续是否流畅,两项都要看。
- 代码助手: 短补全更重视首字延迟;生成完整文件或长解释时,持续输出速度影响更大。
- 智能体工作流: 端到端时间、工具调用等待和重试次数共同决定任务完成速度。
- 后台批处理: 用户不直接等待时,可以降低首字延迟权重,更重视总完成时间、吞吐与成本。
- 长推理任务: 较长等待可能来自更复杂的推理过程,不能只按速度删除高能力候选。
一套可复用的速度验收方法
- 使用与你线上请求相同的输入长度、输出上限和推理设置。
- 分开记录首 token、持续输出、完整响应和失败重试,不只记录平均值。
- 对每个候选重复测试,观察高峰时段和较慢请求,而不是只看最快一次。
- 同时记录答案是否合格;不合格的快速回答不算有效完成。
- 把最终可用结果的时间与成本作为业务指标,再决定主模型和回退模型。
页面中的榜单用于快速筛选。接入前还需确认具体 API 供应方式、地区、并发、速率限制和流式返回行为,因为这些产品条件会影响真实延迟。