当行业还在比拼参数规模时，速度这条战线正在被重新拉直。Mercury 2.5 宣称达到每秒 770 tokens 的生成速度，这个数字本身比它的模型细节更值得讨论。
发生了什么
据 Hacker News 上的讨论，Mercury 2.5 这款 LLM 的生成速度达到每秒 770 tokens。目前公开信息有限，讨论热度也处于早期阶段（帖子约 21 分），但「770 tokens/s」这个量级已经足够引发关注。作为参照，主流云端大模型的输出速度通常在每秒几十到一百多 tokens 区间，770 已经明显超出常规水位。需要说明的是，速度指标高度依赖硬件、批处理规模、上下文长度和评测口径，脱离这些条件的单一数字只能作为方向性参考。
为什么重要
过去两年，大模型竞赛的主轴是能力：更大的参数量、更长的上下文、更高的基准分数。但能力提升带来的边际体验改善正在放缓，而延迟——用户从提问到看到第一个字、再到读完答案的等待时间——始终是产品体验里最硬的约束之一。
速度之所以重新变得关键，有几层原因。其一，Agent 与工具调用场景天然是串行的：一次任务要经历多轮「思考—调用—观察」，每轮都叠加延迟，单次生成快一倍，端到端体验可能快好几倍。其二，语音对话、实时翻译、代码补全这类交互形态对首 token 延迟和吐字速率有硬性要求，慢一点就从「自然」掉到「卡顿」。其三，推理成本与吞吐直接挂钩，单位时间能服务更多请求，意味着同样的算力能支撑更多用户。
Mercury 这类主打速度的模型，本质上是在押注一个判断：对相当一部分任务而言，「够用且极快」比「最强但慢」更有产品价值。
影响与看点
对开发者来说，最直接的变化是架构选择变多了。过去为了压延迟，往往要在模型能力上做妥协，或者堆昂贵的推理优化工程；如果高速模型可用，一些原本被延迟劝退的场景——实时代码补全、低延迟语音助手、高频 Agent 循环——会重新变得可行。
对行业而言，速度成为卖点，意味着竞争维度在扩散：不只是「谁更聪明」，还有「谁更快、更便宜、更稳定」。这对推理基础设施、专用芯片和推理优化服务都是利好信号。
值得关注的几个点：一是 770 tokens/s 在真实负载和长上下文下能否保持，还是仅在理想条件下成立；二是速度是否以能力下降为代价，需要独立评测来验证；三是定价与可用性，速度优势只有转化为成本优势才真正有杀伤力。
一个独立判断：如果这类高速模型的能力落在「中上」而非「顶尖」，它依然可能吃掉大量真实场景——因为大多数生产任务要的不是最强模型，而是足够好且足够快的模型。速度，正在从工程指标变成产品战略。
