当主流大模型还在自回归的框架里比拼参数与算力时，Inception选择从生成范式本身下手。
发生了什么
Inception 发布了 Mercury 3，一款基于扩散（diffusion）架构的语言模型。官方给出的核心指标有两个：推理速度达到每秒 1068 个 token，上下文窗口为 100 万 token。在 Inception 自己公布的对比表中，Mercury 3 在 12 项基准测试中有 8 项领先于 GPT-6 Luna 和 Claude Haiku 5.5。需要说明的是，这些对比数据来自厂商自测，第三方复现尚未出现，速度与基准成绩的具体测试条件也未在摘要中披露。
为什么重要
当前几乎所有主流大语言模型都采用自回归方式生成文本——逐 token 从左到右预测下一个词。这一范式的代价是串行：输出长度直接决定延迟，长文本生成天然受限。扩散模型在图像、视频生成领域已是主流，其思路是先构造噪声再逐步去噪，理论上具备并行生成整段文本的潜力。Mercury 3 的意义不在于又一次刷新榜单，而在于把"非自回归语言模型"从论文推向了可用的产品形态。每秒 1068 token 的速度如果能在真实负载下成立，意味着交互式应用、长文档生成、实时 Agent 循环的延迟结构会被重新定义。100 万 token 上下文与高吞吐叠加，也让"一次性处理整个代码库或文档集"从概念走向工程可行。
影响与看点
对开发者而言，最直接的变化是延迟预算的重新分配。当生成速度不再是瓶颈，系统设计的重心会转向检索质量、上下文组织与结果校验。对 Agent 类产品，高吞吐意味着单次任务内可以承担更多轮的自我检查与工具调用，而不必为每轮推理付出高昂等待成本。对用户，长上下文加高速度的组合可能让"边生成边修改"的协作式体验更接近本地编辑器。
值得关注的疑点同样明确：扩散语言模型在长程一致性、指令遵循和复杂推理上的表现，历来是短板；厂商自测的 8/12 领先需要独立评测验证；每秒 1068 token 是峰值还是稳定吞吐、对应何种硬件与批量配置，都还是空白。
一个克制的判断是：Mercury 3 更像一次范式层面的试探，而非对现有模型的全面替代。它真正的价值，是让"速度"重新成为语言模型竞争的独立维度——过去两年这个维度被参数规模掩盖了。如果扩散路线能在质量上追平自回归，推理成本与延迟的曲线会被整体改写；如果追不平，它至少会在高吞吐、短延迟的特定场景里占住一块地盘。接下来要看的是第三方基准与真实生产环境的反馈，而不是发布当天的对比表。
