Inception Labs 為 Mercury 2.5 給出的賣點不太尋常：它主打的不是更聰明的模型，而是一個足夠快、足夠便宜、可以在單次使用者互動中被呼叫幾十次的模型。這家初創公司稱它是迄今訓練過的最大擴散語言模型，在市面上容易買到的 NVIDIA GPU 上達到每秒 1,107 個詞元，標價為輸入每百萬詞元 0.20 美元、輸出 0.75 美元，上線期間打兩折，降至 0.04 美元和 0.15 美元。
核心要點
- Mercury 2.5 宣稱在保持同樣低延遲、低成本服務形態的前提下，智慧相較 Mercury 2 提升了 40%。
- Inception 把質量對標放在成本最佳化檔位上——GPT-5.6 Luna（Low）、Gemini 3.5 Flash-Lite 和 Claude Haiku 4.5，而非旗艦推理模型。
- Augment Code 表示，把上下文壓縮遷到 Mercury 後延遲下降 82%，從約 150 秒降到 27 秒，成本同時降低 90%。
擴散語言模型為何能在延遲上競爭
傳統大語言模型逐個吐出詞元，說得越多，牆上時間就越長。擴散模型則通過並行的多輪迭代同時打磨整塊文本，正是這一架構差異讓 Inception Labs 能在通用加速卡而非專用推理晶片上報出四位數吞吐量。
公司把 Mercury 2.5 描述為反饋閉環的首個產物，而不是一次衝榜。Mercury 2 釋出後，覆蓋數千名開發者和數十個企業部署的用量增長超過一個數量級；Inception 稱，在啟動訓練之前，他們圍繞這波增長暴露出的生產環境失敗案例重建了評測體系。
客戶把它用在哪裡
搜尋場景最能說明單次呼叫的延遲如何疊加。一條查詢可能扇出成幾十次模型呼叫——規劃、查詢改寫、重排序、事實結構化、摘要、答案校驗——而整條鏈路必須在使用者察覺到停頓之前跑完。這也是 Inception 表示多家頭部搜尋基礎設施公司已在生產環境中執行 Mercury 的原因。
語音智慧體的約束更硬，因為那裡的延遲會直接變成通話中可聽見的沉默。為真實客戶對話構建 AI 電話智慧體的 OpenCall 在生產負載上測得模型響應延遲中位數約為 170 毫秒。聯合創始人兼 CEO Oliver Silverstein 說，切換之後公司的 P99 從幾分鐘降到一秒，P50 從 0.4 秒降到 0.2 秒以內：
明顯快於我們見過的任何一家供應商，而且這還是把推理模型算進去之後的結果。
程式設計智慧體是第三類形態，釋出中最具體的數字也出自這裡。Augment Code 把上下文壓縮遷到 Mercury 上，耗時從約 150 秒降到 27 秒，降幅 82%，成本減少 90%，而該公司稱質量沒有變化，MCP 工具檢索摘要則在一秒內返回。
兩項瞄準延遲下限的預覽
與主版本一同預覽的 Mercury Voice 是一款針對語音互動中最緊時間預算調優的 dLLM，首個詞元的生成時間低於 170 毫秒。另一項預覽 Mercury Router 則用擴散模型讀取傳入的提示詞，按質量、速度與成本在開源或閉源的下游模型之間做出選擇。
NVIDIA 加速計算部門高階產品經理 Shruti Koparkar 把這次釋出看作一個標誌，說明新架構能以多快的速度在既有 AI 基礎設施上固化為可投產的系統。這其實才是本次釋出的真正主張：文本擴散做了多年的研究奇觀，而單靠速度數字此前並未打動買家——OpenAI 自家的超高速檔位就依靠 Cerebras 晶片才拿到相當的躍升，而 Inception 聲稱自己的收益來自架構而非硬體。
如何獲取與接下來的計劃
Mercury 2.5 通過 Inception API、Baseten 和 OpenRouter 提供服務，新 API 使用者可獲得 1 億免費詞元，企業方案則覆蓋專屬算力、自動擴縮容、合規控制與可配置的資料留存。可調推理、並行工具呼叫以及符合模式的 JSON 構成了其餘功能，最後一項對依賴結構化輸出的智慧體流水線尤為關鍵。
繼任模型已在訓練中。Inception 稱它是公司迄今最大的模型，計劃在數月內釋出，目標是在不犧牲擴散架構速度與詞元效率的前提下實現能力躍遷。
常見問題
Mercury 2.5 的價格是多少
標價為輸入每百萬詞元 0.20 美元，輸出每百萬詞元 0.75 美元。上線期間 Inception 打兩折，降至輸入 0.04 美元、輸出 0.15 美元。新 API 使用者還可獲得 1 億免費詞元。
Mercury 2.5 是開源的嗎
不是。Mercury 2.5 是通過 Inception API、Baseten 和 OpenRouter 提供的專有託管模型。企業客戶可以獲得專屬算力和可配置的資料留存策略，但權重並未公開。
什麼是擴散語言模型
擴散語言模型並非嚴格從左到右預測詞元，而是通過並行迭代不斷打磨一整塊詞元來生成文本。它用架構上的熟悉度換取吞吐量，因此主要瞄準語音智慧體、搜尋流水線和智慧體框架這類對延遲敏感的場景。
