這件事發生在 2026 年 10 月 21 日。Inception Labs 推出 Mercury 3，主打擴散式語言模型架構，宣稱在 NVIDIA GPU 上推論速度可達每秒 1,068 個 token，並稱可處理一百萬 token 的上下文、提供 OpenAI API 相容介面。文章更新於 10 月 22 日，如果你的社羣這幾天又開始討論它，多半是有人真的跑起了測試。

先說結論：這個數字是廠商發布的，不是你的應用程式一定會有的體感。在急著把 API 接上去、連夜跑基準測試之前，我們把「速度」拆開看，也順便看看螢幕前的你可以怎麼照顧自己。

每秒 token 數，量的是哪一段？

每秒生成 token 數（tokens per second）是吞吐量指標，描述一段時間內產出多少文字。但你作為使用者真正感受到的等待，其實由幾段時間組成。

第一段是首字延遲（time to first token），從你送出請求到第一個字出現。第二段是完整回覆時間，等到答案全部生成完畢。如果你的應用會先搜尋資料、呼叫外部工具再組答案，那還要加上工具呼叫與網路往返的時間，這叫端到端時間。

所以短問答的應用更在意首字延遲，批次摘要看重整批處理量，多輪代理則要留意每一步的等待怎麼累積。Inception 的文章提到合作方 Octen 在特定搜尋 API 測試中，模型生成中位數時間為 0.9 秒、端到端回覆中位數 2.2 秒。這是特定合作方在特定環境的描述，換了資料、網路或負載，結果不會一樣。

擴散式生成，跟一般模型差在哪

常見的自回歸（autoregressive，也就是依序生成）模型像接龍：先生出一個 token，用它預測下一個，一路接到底。好處是能逐字串流給你看，代價是後面的字必須等前面的結果。

擴散式語言模型（diffusion language model）借用影像生成的去噪概念：先看到一堆被遮住的位置，一輪推論裡同時為多個位置猜候選 token，保留比較可信的，剩下的繼續下一輪修正，直到補完整段文字。這種做法有機會把原本逐步進行的計算平行化，這是速度宣稱的理論基礎。

但要注意限制。文字位置之間會互相牽動，後半句可能依賴前半句的主詞或推理結果。2026 年一篇探討擴散式大型語言模型平行解碼的研究指出，一次解開太多互相依賴的位置，可能降低生成品質與穩定度，實務上得在平行程度和逐步修正之間取捨。該研究討論的是其他擴散模型與解碼方法，不能直接推論 Mercury 3 的表現，這層證據強度你要先分清楚。

想自己驗證，可以怎麼做

來源文章建議的做法很實在：拿你自己的工作負載去測，不要只看單一速度數字。測的時候記幾件事。

同時記錄首字延遲、完整輸出時間和任務總時間，別只挑好看的一項。看第 50 和第 95 百分位數（也就是中位數和最慢的那批請求），平均值會遮住少數很慢的個案。固定測試提示、輸出長度判定方式與硬體條件，否則前後比較沒有意義。廠商公布的多項基準測試可以用來找出值得試跑的情境，例如他們描述早期合作夥伴把模型用在搜尋代理、客服與互動教學，但這些不能取代你自己跑出來的數字。

這種「先看數字來源、再自己驗證」的習慣，跟我們在把健康問題交給 AI 之前該做的識讀功課是同一套邏輯：宣稱、情境、可重現性，三件事分開看。

等測試跑完之前，也照顧一下自己

追新模型、跑評測的節奏，常常是熬夜開測、盯著終端機等到半夜。如果你正準備把 Mercury 3 接上自己的專案，有幾件小事可以順手做。

測試腳本寫好之後就離開螢幕，讓自己起身倒杯水、動動肩頸，批次跑完再看結果，這跟我們在追模型發布時的作息與用眼照顧裡聊過的做法一樣。如果你已經連續盯著輸出捲動好幾個小時，記得用 20-20-20 的原則休息眼睛：每 20 分鐘看 20 英尺（約 6 公尺）外的東西 20 秒。API 呼叫失敗或數字不如預期時，先停下來深呼吸再 debug，深夜的挫敗感往往會被放大。

速度數字會一直更新，你的眼睛和睡眠卻只有一份。看懂 Mercury 3 的宣稱怎麼來，用自己的負載驗證，然後在等結果的空檔照顧自己，這樣追新技術才追得久。