免費！快Claude十倍！一秒1000個token！硅谷創(chuàng)業(yè)公司新推編程神器炸翻了！ 原創(chuàng)
編輯 | 云昭
出品 | 51CTO技術棧（微信號：blog51cto）
一秒鐘輸出高達 1100 tokens！
昨天，一款專為編碼場景設計的“相當另類”的模型成功出圈了。
等等黨，這次終于不用再苦等了~
令人萬萬沒想到的是，一直在圖像/視頻領域炙手可熱的 Diffusion 模型也可以用到編程模型上來。這可以說是對以 Transformer 模型架構為主的 LLM 圈的一次“地基式”的革命。
關鍵是，速度提升了 5-10 倍的同時，編碼的性能測試分數(shù)并沒有犧牲掉，反而取得了讓開發(fā)者眼前一亮的成績。
圖片
這款神器名為 Mercury Coder，是由大洋彼岸硅谷的一家 AI 初創(chuàng)公司 Inception Labs 研發(fā)的。它不僅準確率與 GPT?4o Mini、Claude 3.5 Haiku 等自回歸模型相當。
而且在 Copilot Arena 測評中，Mercury 速度第一，質量名列第二，僅次于 GPT?4o 等模型。
多說一嘴，這么好的產品不再只是學術成果，已經成功實現(xiàn)商用了。
可以說非常的驚艷！
圖片
1.LLM底層范式變天：擴散機制進入語言領域
眾所周知，過去擴散模型專注圖像生成，現(xiàn)在終于有團隊成功將其移植到 LLM 世界（而且實現(xiàn)了商用）。
這就意味大語言模型取得了兩種突破：
- 不再受限于“一次就生成一個token”的方式，而是能并行預測token（速度提升 5–10 倍，簡直是一種顛覆）
- 允許模型“整體優(yōu)化”“多token感知”，有助于提升上下文一致性與邏輯連貫性
而這兩點，可以說對于業(yè)界來說一直都是很大的挑戰(zhàn)。這尤其在代碼生成、數(shù)學推理、結構化填空等場景中尤其重要。
嘗鮮入口為大家找到了：
- API 地址：platform.inceptionlabs.ai
- 試玩地址：chat.inceptionlabs.ai
2.怎么做到的？技術細節(jié)公開了
至于具體的技術細節(jié)？由 Inception Labs 的多位核心研究者聯(lián)合署名發(fā)表的論文《Mercury：基于擴散機制的超高速大語言模型》也給出了解釋。
與以往的擴散方法不同，這種新框架有兩個特點——（1）在Transformer 架構內部運行；（2）能夠在多個位置同時進行語言建模。
下面就訓練、推理、優(yōu)化方面簡單介紹一下，對于這塊細節(jié)不太“感冒”的朋友可以直接看下一部分。
在訓練方面，其實思路依舊是基于傳統(tǒng)擴散模型的思路（噪聲注入 + 重建），即：
使用一個前向擴散過程將原始數(shù)據(jù)擾亂（加噪），再通過反向去噪模型逐步恢復原始數(shù)據(jù)。
不過不同之處在于，該方法在所有位置的 denoising 是并行進行的，這意味著：
模型可以一次性預測多個 token，而不是像傳統(tǒng) LLM 那樣一個一個地生成。
這種方法被稱為多時間步擴散語言建模，同時團隊成員還在在語言域上做了定制。
推理方面——
盡管訓練是并行進行的，推理過程仍然是序列化的，但不同于標準的自回歸 LLM：
- 在推理時，采用一種被稱為“批次采樣（batchwise sampling）”的策略；
- 每一步可以預測多個 token，然后用這些 token 更新序列；
- 然后下一步繼續(xù)生成后續(xù) token；
- 這個過程實際上是一個自回歸的擴散采樣機制。
這種方式允許兼顧：上下文感知的序列生成能力和批量生成的速度優(yōu)勢
簡言之：訓練時是并行的，推理時是快步自回歸的。
第三，在輸出token的質量方面，團隊還設計了一種從粗到細（Coarse-to-Fine）的采樣機制，以提升推理質量和效率：。
- 在初始階段，快速生成多個 token 的初步版本；
- 然后模型根據(jù)已有上下文和這些 token 的質量打分，挑出需要進一步“細化”的 token；
- 在隨后的步驟中，模型只對這些 token 進行再生成或修復。
這樣做的好處就是，既避免了對所有 token 反復采樣的成本，同時保證了整體輸出的連貫性和準確性。
這種策略類似于圖像生成中的“refinement step”，事實證明，這種方法現(xiàn)在也可以應用到了 token 級別的語言生成上。
此外，工程優(yōu)化方面也做了很多工作。比如對 Transformer 這個骨干架構，同樣在多個方面做了優(yōu)化以支持擴散機制和高性能推理。
首先是，建模增強——
- 引入了時間嵌入（time embeddings）：將每個 token 的“擴散時間步”編碼輸入模型；
- 修改了 attention mask 和位置編碼，使其支持同時多個 token 的解碼推理。
其次，是推理系統(tǒng)層優(yōu)化。
- 構建了專用的高吞吐推理引擎（用于部署）；
- 支持高效的 GPU 批處理、內存分頁和流式解碼；
- 推理引擎支持OpenAI API 兼容接口，方便接入現(xiàn)有系統(tǒng)；
- 可選動態(tài)參數(shù)，允許用戶在響應速度和生成質量之間權衡。
省流版，直接看下表。
環(huán)節(jié) | 描述 |
訓練 | 多 token 并行去噪；非自回歸的語言建模訓練 |
推理 | 自回歸式擴散采樣；每步生成多個 token，快速推進 |
質量控制 | coarse-to-fine 策略，提升效率與輸出一致性 |
架構優(yōu)化 | 改進 Transformer 支持擴散；系統(tǒng)層優(yōu)化支持高吞吐 |
3.快到飛起，專為編程場景設計
這款編碼神器，速度實在一絕，用快到“飛起”都不能形容，小編認為這是火箭的速度！
小編試著輸入了一個動畫模擬的 prompt，結果還沒眨眼，就出了效果了。
圖片
目前 Mercury Coder，專門針對 編程場景做出了優(yōu)化，目前分為兩個版本：Mini 和 Small。
圖片
在測試中，兩款版本的速度優(yōu)勢顯著：
在 NVIDIA H100 GPU 上的測試中（由第三方 Artificial Analysis 評估）：
- Mercury Coder Mini：1109 token/s，比所有開源模型表現(xiàn)更好，且速度快 8 倍以上
- Mercury Coder Small：737 token/s，性能接近 Claude 3.5 Haiku 與 Gemini 2.0 Flash，但推理速度更快。
正如開頭所介紹的，這兩個模型：在速度上不僅比當前最強的“快模型”平均快 10 倍，同時還保持了與主流模型相當?shù)妮敵鲑|量。
可以說，Mercury 模型顯著推動了“延遲-準確率”的帕累托邊界。
圖片
比如，在 LLM 代碼助手競技場Copilot Arena 中：
- Mercury Coder 是目前最快的模型；
- 在質量排名中位居第二，說明性能并非以犧牲質量為代價。
4.多編程語言、多任務實測表現(xiàn)強勁
團隊還展示了 Mercury Coder 在多種編程語言和實際應用場景下的 benchmark 表現(xiàn)。
圖片
團隊還測試了 6 種語言的代碼生成能力（C++、Java、JS、PHP、Bash、TS），Mercury 模型整體優(yōu)于大多數(shù)開源模型，并在 Java、JavaScript 上有極強競爭力。
值得一提的是，測試模型在以下任務的補全能力時，也都取得第一的水平：
- 單行缺失（FIM Single-Line）：考察補全代碼中間缺失片段的能力
- 隨機范圍輕缺失（Random-Span-Light）
說明 Mercury 已經在 代碼補全任務中為 SOTA 水準，優(yōu)于所有參評模型，包含GPT-4o-mini、Codestral。
圖片
至于，模型可擴展性方面，團隊表示：雖然目前只有 Mini 和 Small 兩個版本，但他們觀察到——Small 在所有基準上都優(yōu)于 Mini，這說明：diffusion 架構可擴展性良好，未來值得進一步擴大模型規(guī)模。
5.網(wǎng)友驚到了：太快了，革命性壓力給到CI系統(tǒng)
這么快的編寫速度，著實驚人。以至于網(wǎng)友驚呼：壓力不再是編碼，而是測試端！
Hacker News 上底下的大佬們看到這樣的神器，紛紛表示：太快了，但測試和CI 跟不上這樣的速度！
AI 寫得再快，測試通不過還是白搭。Mercury 的快，不僅對「推理延遲」提出挑戰(zhàn)，對整個 CI 流程提出了革命性壓力。
網(wǎng)友 mike_hearn 表示：
LLM 代理越來越強了，但問題是：測試仍然慢得驚人
，這會讓速度優(yōu)勢毫無意義。即使 AI 代碼寫得比人快 100 倍，但如果每次提交（PR）都要等一小時測試，就毫無用處。
圖片
他還指出：
- 大多數(shù)團隊早就被 CI 速度卡住了；
- Mercury 生成的代碼質量不錯，但更重要的問題是：「我們如何讓測試執(zhí)行速度匹配生成速度？」
關于這一點，網(wǎng)友 refulgentis 提出：
測試延遲不是只靠加機器解決。我的 Android Wear 構建最短也要 52 分鐘，有時超過 3 小時。
xemdetia也表達了類似的觀點——
CI 測試失敗很多時候不是代碼問題，而是：
- GitHub rate limit；
- 第三方 SAST 工具超時；
- Artifactory 掛了；
- 本地測過但 CI 環(huán)境 flaky。
這一點非?，F(xiàn)實：LLM 編碼速度的“外部瓶頸”不在模型，而在落地流程：
- Mercury 的每秒千 tokens 意味著它能每分鐘寫好幾個 PR；
- 但現(xiàn)實世界的 CI/CD，仍然像堵車的十字路口。
當然，也有網(wǎng)友思考如何嘗試解決這個問題：是否可以用“云 + Spot 實例”優(yōu)化 CI？
可以用云的 spot 實例來快速彈性擴展測試節(jié)點，CI 成本會降低不少。
但這種方案很快就引發(fā)了另一個問題：企業(yè)隱私安全問題。
很多公司因為 IP（知識產權）敏感，不敢把 CI 放到云上。
對于此，小編不得不說，Vibe Coding 氣候已成，下一步無疑就是 Vibe testing！
6.寫在最后：開胃菜已上，大餐還在后頭
下面提一些小編的思考。
首先，是不得不佩服這家 Inception?Labs 創(chuàng)業(yè)公司。
其一是他們團隊把Diffusion 模型進入 LLM 核心戰(zhàn)場：將擴散模型進入語言建模，且直接對標主流 Transformer 的 token-by-token 推理方式，這非常具有顛覆性。
其二，通過推理速度的突破和工程優(yōu)化，能快速把基礎研究實現(xiàn)產業(yè)落地著實。在保質的前提下提升 10 倍速度，就意味著運行成本和響應延遲都大幅降低，非常契合“落地場景”（如 Copilot 這類編碼助手、實時對話系統(tǒng)）。
第二點，這種基于擴散模型的編程模型，只是開胃菜。雖然目前只是在編程垂類上做實驗，但若這種架構能擴展到通用語言模型領域，可能將挑戰(zhàn) GPT 系列的主導地位。
第三點，通過評論區(qū)網(wǎng)友的反饋，可以預判：Vibe Testing 勢必將成為下一個火熱賽道。
對此，大家如何看待這樣一款超高速編程產品呢？
參考鏈接：
??https://arxiv.org/pdf/2506.17298??
??https://news.ycombinator.com/item?id=44489690??
本文轉載自??51CTO技術棧??，作者：云昭
