重點摘錄

Inception Labs 的 Mercury 2 聲稱約每秒 1,000 個 token，在關鍵基準測試上優於 Google 的 DiffusionGemma。兩者均採用並行擴散式生成，而非逐字逐 token 的序列解碼，能讓大段文字在多次迭代中被精煉。 Mercury 2 在 AIME 2026 得分 90%，而 DiffusionGemma 得分 69.1%，且 Mercury 2 在其他學術測試中也有競爭性結果。Mercury 2 以付費 API 提供且權重為封閉；DiffusionGemma 則以免費開放權重在 Hugging Face 上提供。實際案例顯示，在使用 Mercury 2 的生產子代理中可大幅降低延遲與成本。

情感分析

• 文章整體情感為偏正向：強調 Mercury 2 的明顯技術進展與亮眼基準成績，同時指出實務注意事項，例如權重封閉與仍有適用最佳情境。語氣對擴散生成的潛力表示熱忱，但對於序列模型仍佔優勢的領域則持謹慎態度。
• 技術樂觀可見：開發者與供應商對高吞吐量、較低延遲與大量任務的成本節省感到興奮。但文章同時強調，在某些情境下，絕對前沿的推理能力仍可能由其他模型家族領先。
• 對產業影響的呈現偏建設性：擴散式 LLM 將架構設計導向許多快速子代理，但生態系統（本地執行環境、代理協調）仍需追趕。

文章內容

Inception Labs 發表 Mercury 2，並將其定位為其中一款最快的推理型語言模型，報告的生成速度約為每秒 1,000 個 token。公司將這些速率與其他廣為人知的模型比較：例如 Anthropic 的 Claude Haiku 4.5 Reasoning 與 OpenAI 的 GPT-5 Mini 的每秒 token 速率明顯較低。大約在同一時間，Google 發布了 DiffusionGemma，這是另一款宣稱可比吞吐量的擴散式模型。這兩類模型都放棄了逐 token 的序列方式，轉而採用並行精煉：它們從一個帶有噪音的 token 區塊開始，經過數次迭代減少不確定性，直到整個區塊穩定為連貫的輸出。

這種並行擴散方法類似於影像生成中使用的技術，連續的去噪步驟將隨機噪音轉變為最終圖像。應用於文字時，該方法能在許多任務上實現更高的吞吐量與更低的延遲。兩者在效能與取捨上有所分歧。在 AIME 2026 基準測試（一個以正確解題百分比計分的具有挑戰性的數學考題套件）上，Inception 報告 Mercury 2 達到 90% 正確率。Google 在相同資料集上評估 DiffusionGemma 並記錄到 69.1% 的結果。相較之下，Google 的非擴散標準 Gemma 4 在該測試中得分 88.3%，這顯示擴散變體可能因設計選擇而在某些解題精確度上有所犧牲。

Mercury 2 與 DiffusionGemma 在其他科學基準上也相近。在 GPQA（博士級別的科學評估）上，Mercury 2 得到 77%，DiffusionGemma 得到 73.2%，顯示在某些任務上差距縮小。Google 的開發者指引亦建議，當追求最高品質時，非擴散的 Gemma 4 仍然較為可取。實務上的含意是：在吞吐量與低延遲至關重要的情境下，擴散模型表現優異，而在最艱難的推理任務上，一些序列大型模型可能仍佔優勢。

實際整合案例說明了操作上的好處。一個與程式碼代理公司的案例研究指出，用 Mercury 2 替換序列模型後，一個上下文壓縮子代理的延遲約減少 82%，成本約降低 90%，同時維持輸出品質。這些節省來自於能夠執行大量短且快速的工具呼叫，而不會累積序列管線中的延遲罰款。再加上通用 GPU 的支援，更高的吞吐量在大規模下能顯著降低基礎設施成本。

Inception 的技術血統可追溯到基於分數的擴散方法研究；創辦人的學術工作促成了現代影像與現在文字擴散模型背後的去噪技術。公司獲得來自知名投資者與機器學習硬體及研究社群的策略性資金。Mercury 2 以商業 API 並封閉權重提供，而 DiffusionGemma 則以免費、開放權重的檢查點在 Hugging Face 上發布，為研究人員與產品團隊創造不同的可及性輪廓。

在架構上，擴散模型鼓勵為複雜系統採用不同的協調模式。生產堆疊不再由單一龐大模型處理所有任務，而是成為一組專門化的子代理——有些為推理調校，有些為摘要、路由或快速檢查。 啟用擴散的子代理使頻繁的工具呼叫變得足夠便宜，可以廣泛使用，這改變了設計者如何劃分功能並優化對延遲敏感的體驗，例如即時編碼、語音互動與實時自動完成。

限制仍然存在。擴散式 LLM 目前最適合速度敏感且高流量的工作流程部分，而非推理能力的絕對前沿。可及性各異：封閉權重的 API 限制本地實驗，而開放權重的釋出則允許更廣泛的社群開發。此外，周邊生態系統——本地執行環境、代理框架與工具——仍在發展中，以便在各種環境中無縫利用並行生成。

即時使用情境包括能追上快速編輯的反應式程式輔助、依賴大量快速呼叫的多代理系統，以及需要最小延遲的語音介面。在大規模部署時，提升的吞吐量可轉化為標準硬體上的顯著能源與成本減少，使擴散式 LLM 成為對延遲敏感應用的有吸引力選擇。

關鍵見解表