Mercury 3 每秒上千 Token，为什么做完一件事还得等？

屏幕吐字变快，是厂商在选定榜单上的表现

盯着屏幕看AI打字，确实容易让人心生烦躁。字是一个个蹦出来的，像早年接触不良的针式打印机，哪怕心里知道它在思考，眼睛也总觉得被慢动作耽误了。

Inception在10月19日正式发布的Mercury 3，摆出来的最大卖点就是治这种烦躁。厂商宣称在NVIDIA GPU上，Mercury 3的生成速度达到了1068 Token/s。在厂商自己选定的多项基准榜单对比里，这个数字比Luna和Haiku快上4到8倍。技术上的简要解释是它采用了扩散语言模型，能一次完善一段文字，而不必严格地依次生成Token；当然，这项内部具体算法并没有宣称完全公开。

与此同时，厂商公布的上下文容量达到了100万Token，比前代Mercury 2.5的26万Token有了扩容。但容量只是模型一次性可以吞吐的规格上限，并不等于它对这100万Token全都能准确读懂。目前Inception API、OpenRouter、Baseten与Vercel已经可以使用该模型，官方也提供了聊天体验入口。虽然接口兼容OpenAI的标准规范，但兼容格式并不代表任何现成系统不需要验证就能直接替换。

速度提升是白纸黑字写在公告里的，只是它代表的仅仅是模型在特定硬件上倾泻字符的物理速度。

模型吐字之外，还有别的环节在耗费时间

把每秒上千Token当成“不用等待”的保证，往往忽略了系统在吐字之外还干了什么。人向模型提问，到拿到完整可用的一页内容，中间经过的管道远不止模型生成本身。

Curiosity的开发者Rafael在10月19日记录了开发环境中的实际测试情况。在一台开发容器里，一轮包含一两次工具调用的聊天，整体耗时在1到2秒，首段内容流出用时0.4到1秒。Rafael特意说明这只是一天、一个容器内的记录，并不是标准评测。但这1到2秒的体感已经说明，即便每次调用都很快，工具交互本身依然占用时间。

Inception公告里引用的合作方数据，更能说明这种时间拆分。Octen创始人Kuan Zou测试显示，在特定的Sense API工作负载下，模型生成的耗时中位数是0.9秒，而完整响应的耗时中位数是2.2秒。

这两组数字不能拿来做简单的减法运算，去武断分摊具体某一步耗费了多少秒，更不意味着所有人用起来都要等上2.2秒。但它清楚表明了一件事：用户感知到的等待，是完整响应的总时间。在这段过程里，除了模型自身的计算，还可能涉及网络传输、输入内容的读取、工具的调度以及外部信息的检索。即使模型在0.9秒内完成了生成，其余环节该走的路一步也省不掉。

生成快省下的秒数，可能被改错重新耗尽

如果一个任务只需要模型给出一句现成的回答，或者在自动化工作流里进行多次短回合交互，更快的生成速度确实能带来立竿见影的流转收益。但对日常需要依靠AI产出具体内容的人来说，快与省时常常不是同义词。

在Reddit的r/singularity讨论区里，用户LyAkolon分享了尝试让Mercury 3生成贪吃蛇游戏的经历。LyAkolon认为初版代码还可以，但在要求模型继续添加功能后开始出现问题，最终表示这可能是运行工具的问题，但改起错误来非常痛苦。

同帖的另一位用户Ok_Knowledge_8259则提到，模型的常规输出表现接近Luna，但也坦承自己的测试并不充分。

两位用户的遭遇无法作为评判模型能力优劣的定论，我们更无从替LyAkolon确诊到底是模型逻辑出了偏差还是外部运行工具存在缺陷。然而这种体验折射出一个极常见的现实矛盾：当生成的代码或文本存在疏漏时，模型生成快了，人在排查问题、修改逻辑、重新提问上所花的时间却未必跟着缩短。生成速度省下的往往是几秒钟的视觉等待，而一次返工耗费的则是成倍的人工精力。

等待的本质，是从提问到拿到可用结果的全过程

回到最开始的问题：Mercury 3让生成速度突破每秒上千Token，我们是不是终于能摆脱等待了？

答案取决于你究竟在等什么。如果你等的是更快生成完整回复，是在多次调用外部工具的流程中减少积攒的响应延迟，那么扩散模型带来的生成加速确实缩短了纯粹的机械等待时间。

但对大多数人而言，等待AI从来不是单纯看光标跳跃的过程。从回车键按下的那一秒开始，读取提示词需要时间，可能涉及的数据检索需要时间，调用工具需要时间；拿到结果之后，核对事实、调试代码、修正逻辑更是需要时间。

吐字变快是生成环节的单点突破，它既不代表整个系统流程的其他开销跟着消失，也不保证产出结果能让人少返工。要想知道它到底能不能帮自己省下时间，最稳妥的办法依然是用手头那些能直接核对结果的日常任务去跑一跑，看看从敲下问题到真正交差，总共耗掉了多少工夫。