免费！快Claude十倍！一秒1000个token！硅谷创业公司新推编程神器炸翻了！技术细节公开，网友：变天了，测试CI压力如山

一秒钟输出高达 1100 tokens！

昨天，一款专为编码场景设计的“相当另类”的模型成功出圈了。

等等党，这次终于不用再苦等了~

令人万万没想到的是，一直在图像/视频领域炙手可热的 Diffusion 模型也可以用到编程模型上来。这可以说是对以 Transformer 模型架构为主的 LLM 圈的一次“地基式”的革命。

关键是，速度提升了 5-10 倍的同时，编码的性能测试分数并没有牺牲掉，反而取得了让开发者眼前一亮的成绩。

图片

这款神器名为 Mercury Coder，是由大洋彼岸硅谷的一家 AI 初创公司 Inception Labs 研发的。它不仅准确率与 GPT‑4o Mini、Claude 3.5 Haiku 等自回归模型相当。

而且在 Copilot Arena 测评中，Mercury 速度第一，质量名列第二，仅次于 GPT‑4o 等模型。

多说一嘴，这么好的产品不再只是学术成果，已经成功实现商用了。

可以说非常的惊艳！

图片

1.LLM底层范式变天：扩散机制进入语言领域

众所周知，过去扩散模型专注图像生成，现在终于有团队成功将其移植到 LLM 世界（而且实现了商用）。

这就意味大语言模型取得了两种突破：

• 不再受限于“一次就生成一个token”的方式，而是能并行预测token（速度提升 5–10 倍，简直是一种颠覆）
• 允许模型“整体优化”“多token感知”，有助于提升上下文一致性与逻辑连贯性

而这两点，可以说对于业界来说一直都是很大的挑战。这尤其在代码生成、数学推理、结构化填空等场景中尤其重要。

尝鲜入口为大家找到了：

• API 地址：platform.inceptionlabs.ai
• 试玩地址：chat.inceptionlabs.ai

2.怎么做到的？技术细节公开了

至于具体的技术细节？由 Inception Labs 的多位核心研究者联合署名发表的论文《Mercury：基于扩散机制的超高速大语言模型》也给出了解释。

与以往的扩散方法不同，这种新框架有两个特点——（1）在Transformer 架构内部运行；（2）能够在多个位置同时进行语言建模。

下面就训练、推理、优化方面简单介绍一下，对于这块细节不太“感冒”的朋友可以直接看下一部分。

在训练方面，其实思路依旧是基于传统扩散模型的思路（噪声注入 + 重建），即：

使用一个前向扩散过程将原始数据扰乱（加噪），再通过反向去噪模型逐步恢复原始数据。

不过不同之处在于，该方法在所有位置的 denoising 是并行进行的，这意味着：

模型可以一次性预测多个 token，而不是像传统 LLM 那样一个一个地生成。

这种方法被称为多时间步扩散语言建模，同时团队成员还在在语言域上做了定制。

推理方面——

尽管训练是并行进行的，推理过程仍然是序列化的，但不同于标准的自回归 LLM：

• 在推理时，采用一种被称为“批次采样（batchwise sampling）”的策略；
• 每一步可以预测多个 token，然后用这些 token 更新序列；
• 然后下一步继续生成后续 token；
• 这个过程实际上是一个自回归的扩散采样机制。

这种方式允许兼顾：上下文感知的序列生成能力和批量生成的速度优势

简言之：训练时是并行的，推理时是快步自回归的。

第三，在输出token的质量方面，团队还设计了一种从粗到细（Coarse-to-Fine）的采样机制，以提升推理质量和效率：。

• 在初始阶段，快速生成多个 token 的初步版本；
• 然后模型根据已有上下文和这些 token 的质量打分，挑出需要进一步“细化”的 token；
• 在随后的步骤中，模型只对这些 token 进行再生成或修复。

这样做的好处就是，既避免了对所有 token 反复采样的成本，同时保证了整体输出的连贯性和准确性。

这种策略类似于图像生成中的“refinement step”，事实证明，这种方法现在也可以应用到了 token 级别的语言生成上。

此外，工程优化方面也做了很多工作。比如对 Transformer 这个骨干架构，同样在多个方面做了优化以支持扩散机制和高性能推理。

首先是，建模增强——

• 引入了时间嵌入（time embeddings）：将每个 token 的“扩散时间步”编码输入模型；
• 修改了 attention mask 和位置编码，使其支持同时多个 token 的解码推理。

其次，是推理系统层优化。

• 构建了专用的高吞吐推理引擎（用于部署）；
• 支持高效的 GPU 批处理、内存分页和流式解码；
• 推理引擎支持OpenAI API 兼容接口，方便接入现有系统；
• 可选动态参数，允许用户在响应速度和生成质量之间权衡。

省流版，直接看下表。

环节	描述
训练	多 token 并行去噪；非自回归的语言建模训练
推理	自回归式扩散采样；每步生成多个 token，快速推进
质量控制	coarse-to-fine 策略，提升效率与输出一致性
架构优化	改进 Transformer 支持扩散；系统层优化支持高吞吐

3.快到飞起，专为编程场景设计

这款编码神器，速度实在一绝，用快到“飞起”都不能形容，小编认为这是火箭的速度！

小编试着输入了一个动画模拟的 prompt，结果还没眨眼，就出了效果了。

图片

目前 Mercury Coder，专门针对 编程场景做出了优化，目前分为两个版本：Mini 和 Small。

图片

在测试中，两款版本的速度优势显著：

在 NVIDIA H100 GPU 上的测试中（由第三方 Artificial Analysis 评估）：

• Mercury Coder Mini：1109 token/s，比所有开源模型表现更好，且速度快 8 倍以上
• Mercury Coder Small：737 token/s，性能接近 Claude 3.5 Haiku 与 Gemini 2.0 Flash，但推理速度更快。

正如开头所介绍的，这两个模型：在速度上不仅比当前最强的“快模型”平均快 10 倍，同时还保持了与主流模型相当的输出质量。

可以说，Mercury 模型显著推动了“延迟-准确率”的帕累托边界。

图片

比如，在 LLM 代码助手竞技场Copilot Arena 中：

• Mercury Coder 是目前最快的模型；
• 在质量排名中位居第二，说明性能并非以牺牲质量为代价。

4.多编程语言、多任务实测表现强劲

团队还展示了 Mercury Coder 在多种编程语言和实际应用场景下的 benchmark 表现。

图片

团队还测试了 6 种语言的代码生成能力（C++、Java、JS、PHP、Bash、TS），Mercury 模型整体优于大多数开源模型，并在 Java、JavaScript 上有极强竞争力。

值得一提的是，测试模型在以下任务的补全能力时，也都取得第一的水平：

• 单行缺失（FIM Single-Line）：考察补全代码中间缺失片段的能力
• 随机范围轻缺失（Random-Span-Light）

说明 Mercury 已经在 代码补全任务中为 SOTA 水准，优于所有参评模型，包含GPT-4o-mini、Codestral。

图片

至于，模型可扩展性方面，团队表示：虽然目前只有 Mini 和 Small 两个版本，但他们观察到——Small 在所有基准上都优于 Mini，这说明：diffusion 架构可扩展性良好，未来值得进一步扩大模型规模。

5.网友惊到了：太快了，革命性压力给到CI系统

这么快的编写速度，着实惊人。以至于网友惊呼：压力不再是编码，而是测试端！

Hacker News 上底下的大佬们看到这样的神器，纷纷表示：太快了，但测试和CI 跟不上这样的速度！

AI 写得再快，测试通不过还是白搭。Mercury 的快，不仅对「推理延迟」提出挑战，对整个 CI 流程提出了革命性压力。

网友 mike_hearn 表示：

LLM 代理越来越强了，但问题是：测试仍然慢得惊人，这会让速度优势毫无意义。即使 AI 代码写得比人快 100 倍，但如果每次提交（PR）都要等一小时测试，就毫无用处。

图片

他还指出：

• 大多数团队早就被 CI 速度卡住了；
• Mercury 生成的代码质量不错，但更重要的问题是：「我们如何让测试执行速度匹配生成速度？」

关于这一点，网友 refulgentis 提出：

测试延迟不是只靠加机器解决。我的 Android Wear 构建最短也要 52 分钟，有时超过 3 小时。

xemdetia也表达了类似的观点——

CI 测试失败很多时候不是代码问题，而是：

• GitHub rate limit；
• 第三方 SAST 工具超时；
• Artifactory 挂了；
• 本地测过但 CI 环境 flaky。

这一点非常现实：LLM 编码速度的“外部瓶颈”不在模型，而在落地流程：

• Mercury 的每秒千 tokens 意味着它能每分钟写好几个 PR；
• 但现实世界的 CI/CD，仍然像堵车的十字路口。

当然，也有网友思考如何尝试解决这个问题：是否可以用“云 + Spot 实例”优化 CI？

可以用云的 spot 实例来快速弹性扩展测试节点，CI 成本会降低不少。

但这种方案很快就引发了另一个问题：企业隐私安全问题。

很多公司因为 IP（知识产权）敏感，不敢把 CI 放到云上。

对于此，小编不得不说，Vibe Coding 气候已成，下一步无疑就是 Vibe testing！

6.写在最后：开胃菜已上，大餐还在后头

下面提一些小编的思考。

首先，是不得不佩服这家 Inception Labs 创业公司。

其一是他们团队把Diffusion 模型进入 LLM 核心战场：将扩散模型进入语言建模，且直接对标主流 Transformer 的 token-by-token 推理方式，这非常具有颠覆性。

其二，通过推理速度的突破和工程优化，能快速把基础研究实现产业落地着实。在保质的前提下提升 10 倍速度，就意味着运行成本和响应延迟都大幅降低，非常契合“落地场景”（如 Copilot 这类编码助手、实时对话系统）。

第二点，这种基于扩散模型的编程模型，只是开胃菜。虽然目前只是在编程垂类上做实验，但若这种架构能扩展到通用语言模型领域，可能将挑战 GPT 系列的主导地位。

第三点，通过评论区网友的反馈，可以预判：Vibe Testing 势必将成为下一个火热赛道。

对此，大家如何看待这样一款超高速编程产品呢？