Mercury 2.5 报出 770 tokens/s，速度榜单之外该看什么

770 tokens/s 是个什么量级

第三方评测站 Artificial Analysis 的模型页把 Mercury 2.5 的输出速度标在 770 tokens/s。这条消息今天在 Hacker News 上拿到 103 分、63 条评论。

拿日常经验对比一下：一个读得快的人，每秒大约看四到五个英文词。770 个 token 在一秒内吐完，等于你刚读完第一行，整段话已经写好了。这样的速度越过了“边打字边等”的区间，产品形态会跟着变。

但 tokens/s 从来不是孤立数字。任何榜单上的速度都测于特定条件——某批硬件、某个批大小、某段上下文长度、某种并发水平。你下午三点在真实产品里拿到的那份速度，是另一次测量，两者之间的差距可能不小。速度宣称更像“状态好时的上限”，而不是每一次请求的承诺。

背景也值得交代一句：Mercury 系列由 Inception Labs 推出，卖点是并行出词的扩散式生成路线，和主流的自回归逐词解码走的是两条道。速度本就是这条路线最想证明的东西。

输出速度为什么变成了硬指标

过去几年，评测讨论大多围着质量转：推理、代码、数学。速度排在后面。Agent 类工作流把顺序调了个个儿。

一次任务里，模型要连续输出几千个 token，中途调用工具、读返回结果、再决定下一步。输出速度在这里会被成倍放大成用户的实际等待时间——一次 20 秒的生成，在一个要跑十几轮的流程里就是几分钟。代码补全、长文撰写、实时语音转写，都吃这一口。

反方向也有：批量离线任务里，tokens/s 直接换算成一块卡一天能干多少活，进而换算成成本。速度在这里不是体验问题，是账目问题。

榜单能说明什么，不能说明什么

Artificial Analysis 的价值在于横向可比：同一套测法、同一把尺子，把不同模型的输出速度和质量指标摆在一起。想快速了解一个陌生模型，这类页面仍是效率最高的入口。

尺子之外还站着几件事。答案对不对，速度数字完全不涉及；高峰期会不会掉速，看的是服务稳定性；价格、上下文窗口、工具调用的可靠性，也都不在这条曲线里。Mercury 2.5 的 770 tokens/s 证明的是吞吐能力，不是综合能力。

Hacker News 上的 103 分和 63 条评论，说明这个话题有人盯得紧。讨论热度属于关注度指标，和模型好坏是两码事。

开发者该拿它做什么

在自家负载上重测一遍。用真实 prompt、真实并发、真实上下文长度，别用评测页的短样例。

把首 token 延迟和输出速度分开看。前者决定“什么时候开始出字”，后者决定“多久能出完”。对话式产品两个都敏感；长输出、批处理场景里，后者才是主导项。

Mercury 2.5 的 770 tokens/s 值得记一笔，它的意义更接近一记提醒：当输出速度跨过某个门槛，交互设计里的许多默认假设要重新算。至于这条技术路线能不能在质量上同样站住，还要看更长期的评测和真实使用反馈。