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

选型对照
持续输出速度前列模型
按每秒输出 token 数排列,并同时列出首字延迟、总响应时间、综合智力和任务成本,避免把单一速度指标当成完整体验。
输出速度
1591.9 t/s
首字延迟
0.56 秒
总响应时间
0.87 秒
综合智力
6.3
任务成本
$0.050
输出速度
878.7 t/s
首字延迟
2.08 秒
总响应时间
4.93 秒
综合智力
30.5
任务成本
$0.000
输出速度
728.4 t/s
首字延迟
3.63 秒
总响应时间
4.32 秒
综合智力
12.3
任务成本
$0.12
输出速度
453.8 t/s
首字延迟
0.78 秒
总响应时间
6.28 秒
综合智力
26.5
任务成本
$0.19
输出速度
413.8 t/s
首字延迟
7.30 秒
总响应时间
8.50 秒
综合智力
22.2
任务成本
$0.19
输出速度
362.0 t/s
首字延迟
0.67 秒
总响应时间
7.58 秒
综合智力
30.3
任务成本
$0.23
数据更新于 2026年10月25日 17:05;输出速度、首字延迟和总响应时间分别排序。三项指标含义不同,不能合并成一个未经说明的“最快”结论。
大模型哪个响应最快
如果你关心模型开始输出后生成得多快,当前输出速度前三是 Celeris-1、K2 Horizon 375B A23B、Mercury 2.5。如果你关心点击发送后多久看到第一个字,应看首 token 延迟;如果你关心完整任务多久结束,则要看端到端响应时间。
同一个型号可能在其中一项很快、另一项一般。聊天产品、代码助手和后台批处理对“快”的定义也不相同。
持续输出速度排行榜
- Celeris-1 — 1591.9 token/秒
- K2 Horizon 375B A23B — 878.7 token/秒
- Mercury 2.5 — 728.4 token/秒
- Nemotron 3.5 Super VL — 453.8 token/秒
- Gemini 3.5 Flash-Lite — 413.8 token/秒
- Beam 1.0 — 362.0 token/秒
- Trinity Large Thinking — 357.1 token/秒
- Nemotron 3.5 Lightning — 294.1 token/秒
- Nova Micro — 287.0 token/秒
- Nemotron 3 Nano (non-reasoning) — 275.3 token/秒
持续输出速度表示模型已经开始生成后,每秒输出多少 token。它直接影响长回答、代码生成和流式输出的阅读节奏,但不包含请求发出后的首次等待。
首字延迟排行榜
- North Mini Code — 0.45 秒
- Command A+ — 0.52 秒
- Celeris-1 — 0.56 秒
- Nemotron 3.5 Lightning — 0.59 秒
- NVIDIA Nemotron Nano 9B V2 — 0.64 秒
- Nemotron 3 Nano (non-reasoning) — 0.65 秒
- Ministral 3 3B — 0.67 秒
- Beam 1.0 — 0.67 秒
- Granite 4.2 8B — 0.72 秒
- Granite 4.2 3B — 0.74 秒
首 token 延迟是从发送请求到收到第一个 token 的时间。搜索框、客服、聊天和实时助手通常对这项指标更敏感,因为用户会把“迟迟没有反应”理解为卡住。
总响应时间排行榜
- Celeris-1 — 0.87 秒
- Nemotron 3 Nano (non-reasoning) — 2.47 秒
- Nova Micro — 2.55 秒
- Ministral 3 3B — 3.07 秒
- NVIDIA Nemotron Nano 12B v2 VL (non-reasoning) — 3.52 秒
- Mistral Small 4 (non-reasoning) — 3.75 秒
- Nova 2.0 Lite (non-reasoning) — 3.79 秒
- Qwen3.5 Omni Flash — 3.89 秒
- NVIDIA Nemotron Nano 9B V2 (non-reasoning) — 4.00 秒
- Mercury 2.5 — 4.32 秒
端到端响应时间从请求开始算到完整回答结束。它同时受到首字延迟、推理过程、输出长度和持续输出速度影响,更接近“这次任务多久完成”。
为什么最快不一定最好用
模型速度只能说明等待体验,不能说明答案是否正确、任务是否完成或输出是否值得保留。当前综合智力靠前的候选为:
- Claude Opus 5.5 (max with fallback) — 57.6
- Claude Sonnet 5.5 (max with fallback) — 56.0
- Claude Opus 5.5 (xhigh with fallback) — 56.0
- Muse Wonder Full (max) — 55.8
- Kimi K3.1 Pro — 55.1
真实产品通常需要设置能力底线,再在合格模型中比较速度。如果速度更快但错误率更高、需要频繁重试,最终完成时间和总成本反而可能更差。
按产品场景选择速度指标
- 聊天与客服: 首字延迟决定是否“立即有回应”,输出速度决定后续是否流畅,两项都要看。
- 代码助手: 短补全更重视首字延迟;生成完整文件或长解释时,持续输出速度影响更大。
- 智能体工作流: 端到端时间、工具调用等待和重试次数共同决定任务完成速度。
- 后台批处理: 用户不直接等待时,可以降低首字延迟权重,更重视总完成时间、吞吐与成本。
- 长推理任务: 较长等待可能来自更复杂的推理过程,不能只按速度删除高能力候选。
一套可复用的速度验收方法
- 使用与你线上请求相同的输入长度、输出上限和推理设置。
- 分开记录首 token、持续输出、完整响应和失败重试,不只记录平均值。
- 对每个候选重复测试,观察高峰时段和较慢请求,而不是只看最快一次。
- 同时记录答案是否合格;不合格的快速回答不算有效完成。
- 把最终可用结果的时间与成本作为业务指标,再决定主模型和回退模型。
页面中的榜单用于快速筛选。接入前还需确认具体 API 供应方式、地区、并发、速率限制和流式返回行为,因为这些产品条件会影响真实延迟。