編輯 | 云昭

出品 | 51CTO技術棧（微信號：blog51cto）

一秒鐘輸出高達 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 兼容接口，方便接入現有系統；
• 可選動態參數，允許用戶在響應速度和生成質量之間權衡。

省流版，直接看下表。

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 勢必將成為下一個火熱賽道。

對此，大家如何看待這樣一款超高速編程產品呢？

參考鏈接：

??https://arxiv.org/pdf/2506.17298??

??https://news.ycombinator.com/item?id=44489690??

本文轉載自??51CTO技術棧??，作者：云昭