【2026 最新】Mercury 2.5 完整解析：1,107 tok/s 何時有用？（速度 × 品質 A/B Test 教學）

看到「每秒 1,107 個 Token」，直覺會以為 Mercury 2.5 適合所有即時 AI。問題是，使用者等待的是答案，不是速度計上的數字：模型可能很晚才送出第一塊文字，卻在開始後瞬間吐完；也可能很早開始串流，最後反而較晚完成。

所以這篇只記一條路由口訣：有效產能 ＝ 成功任務數 ÷ 全部嘗試總時間。它不是統計估計式，品質、尾端延遲與成本仍要分開報。AlphaLab 本次沒有自行呼叫 Mercury 2.5 的 API trace，因此不把外部結果包裝成本站測量；以下會交叉核對 Inception 官方資料與 Puter Developer 的原始第三方測量，再給你一套可用自己帳號重跑的四任務 A/B Test。

先看結論：1,107 tok/s 只回答了半個問題

Inception 在 2026 年 9 月 8 日的發布文表示 Mercury 2.5 可達 1,107 tok/s，並稱測試使用「廣泛可得的 NVIDIA GPU」。截至 2026 年 9 月 12 日，該頁沒有列出 GPU 型號與數量、batch、併發、prompt／output 長度、reasoning 等級、region、樣本數或 TTFT 是否算入；因此這是廠商的 generation throughput 宣稱，不是公共 API 的延遲保證。

第三方資料補上了最重要的反差。Puter Developer用四個公開 prompt、每個模型各跑 5 次，再完整重跑一輪；在要求 600 個英文單字的 HTTPS 題目中，Mercury 2.5 以本地 tokenizer 計算的 10 次 generation-window 速率中位數是 1,241 tok/s，範圍 727～1,756。但同題兩輪各 5 次的首段可見文字時間中位數分別為 5,338 與 5,017 ms；Puter 計算的全請求可見輸出率為 106 tok/s。該題 10 次的完成時間中位數為 5.7 秒，該測量中的 Claude Haiku 4.5 則為 9.4 秒；報告沒有比較兩者回答品質或等長性。

這份外部測量也有邊界：它是一個 Puter 服務路徑、一天的快照；呼叫端只明示 model 與 streaming，上游實際參數未公開，報告頁也沒有公開逐次 raw trace、tokenizer 名稱或完整任務品質 rubric。其 generation rate 把所有回傳 Token 除以第一塊到最後一塊的時間，計入第一塊 Token，卻沒有計入生成第一塊的等待，因此不能當成精確的內部 decode rate，也無法確認是否對應本文建議的 instant profile。它說明 generation-window tok/s 無法單獨決定首內容或總延遲，卻不能替你的客服、搜尋或工具流程宣布贏家。

Mercury 2.5 為什麼能快？先懂文字 Diffusion

典型自回歸（autoregressive，AR）模型先決定第 1 個 Token，再根據前文決定第 2 個。KV cache 會重用前文運算，但「下一個要等上一個」的因果相依仍然存在。以公開的 masked diffusion 研究為例（不代表 Mercury 2.5 內部），模型可先放入一段遮罩位置，在同一輪替多個位置預測 Token，再經多輪去噪逐步收斂。平行發生在一輪中的多個位置；去噪輪次本身仍是依序的，所以 diffusion 不等於一次完成。

Masked Diffusion Language Models 論文能說明一般機制，Mercury 技術報告則研究 2025 年的 Mercury Coder，而不是 Mercury 2.5。2.5 發布文只足以支持「diffusion language model」這個產品層級；舊報告明示的 Transformer／coarse-to-fine 設計不能直接套用，而本文查核的 2.5 公開資料也沒有指定 masking、block size、remasking 或 sampler。想補完整脈絡，可先讀 DiffusionGemma 256-token Canvas，再看 Uno Ψ-Spec 與多 Token 驗證，兩者也不能直接當成 Mercury 2.5 的內部實作。

別只量 tok/s：先定義四個時間與一個成本

• TTFT／首塊內容時間：從送出 request 到第一個非空 content block。Mercury 是 block streaming，名稱比「第一個 Token」更精確。
• 可行動時間：到第一個完整句子、可 parse JSON，或完整 tool arguments 出現為止。這通常比 TTFT 更接近產品體感。
• 總延遲：從送出到收到 [DONE] 與最終 usage。機器接手下一步時，這個數字最重要。
• 可見輸出速率：可見 Token 或 Unicode 字數 ÷ 全請求時間。跨模型 tokenizer 不同，另報字元／秒比較誠實。
• Decode rate：只有收到至少兩個 content delta 時才計 (可見 Token−第一塊 Token) ÷ (最後內容時間−第一內容時間)；只有一塊就標 NA。
• 每成功任務成本：所有第一次嘗試與必要重試的總費用 ÷ 通過品質門檻的題數；失敗不能從分母偷偷消失。

截至 2026 年 9 月 12 日，官方模型頁列出的 Mercury 2.5 定價是每百萬 Token：input US$0.20、cached input US$0.02、output US$0.75；頁面同時顯示首發優惠 US$0.04／0.004／0.15，但沒有公布截止日。Reasoning Token 已包含在 completion Token，成本式應寫成 ((input-cached)×input_rate + cached×cache_rate + completion×output_rate) ÷ 1,000,000，不可把 reasoning 再加一次。

先凍結 A/B Test：同題、同路徑、同失敗規則

主決策的 A arm 可設為 Mercury 2.5 instant，B arm 則是你已部署、版本與價格快照都已凍結的 production model；這才回答「要不要換」。若帳戶仍可呼叫 Mercury 2，也可另做同供應商比較：兩者 output list price 都是 US$0.75／M，但 input 分別為 US$0.20／M 與 US$0.25／M，不能稱為完全同價；先比 instant 對 instant，再比 medium 對 medium。接著鎖定 client region、官方直連 endpoint、prompt、工具 schema、candidate order、temperature、輸出上限與 timeout。每題用 AB／BA 隨機交錯，分散到至少三個時段；主測試先以 concurrency 1 隔離單請求延遲，再另外做 8 或 32 併發的 load test。

Mercury 2.5 的 reasoning_effort 官方值是 instant、low、medium、high，預設為 medium；沒有名為 off 的設定。先比較 instant 與 medium，但只能把它解讀為同一模型的產品 profile 差異。一般串流使用 diffusing=false；diffusing=true 會送回每輪完整、會被覆寫的中間文字，適合展示，不適合拿來量一般 TTFT。想先理解評分器與回歸測試，可搭配 AI Evals 七步教學。

pip install inceptionai==0.1.4
export INCEPTION_API_KEY="your_api_key_here"

import time
from inceptionai import Inception

client = Inception(max_retries=0, timeout=60.0)  # 外部記錄重試
YOUR_FROZEN_PROMPT = "請用兩句話解釋向量資料庫，不要使用 Markdown。"
t0, first, usage, text = time.perf_counter(), None, None, ""

stream = client.chat.completions.create(
    model="mercury-2.5",
    messages=[{"role": "user", "content": YOUR_FROZEN_PROMPT}],
    reasoning_effort="instant",
    temperature=0.5,
    max_completion_tokens=800,
    stream=True,
    stream_options={"include_usage": True},
    diffusing=False,
)
for chunk in stream:
    if chunk.choices:
        delta = chunk.choices[0].delta.content or ""
        if delta and first is None:
            first = time.perf_counter()
        text += delta
    if getattr(chunk, "usage", None):
        usage = chunk.usage

done = time.perf_counter()
print({"first_content_s": None if first is None else first-t0, "total_s": done-t0,
       "chars": len(text), "usage": usage})

這段程式只完成一個 arm 的時間記錄；正式 ledger 還要存 model_requested、model_returned、UTC、client region、SDK／tokenizer 版本、request ID、prompt SHA-256、reasoning、realtime、每個 delta 的時間、finish reason、warning、token usage、HTTP status、output hash 與成功分數。溫身請求不計分，429、5xx、timeout 與 finish_reason=length 都保留為第一次嘗試失敗；主結果先限 cached_tokens=0，warm-cache 另成一層。若要觀察 production retry，可在預註冊中另定最多 2 次、1／2 秒 backoff，保存 retry index 與所有嘗試成本；load test 也要先寫清 open-loop 或 closed-loop、總請求數與 quota。

從零開始：先跑一個最小但誠實的版本

1. 選一種真實任務：不要一開始混四類。從自己的紀錄挑 20 題，刪除個資，保留容易、普通、會失敗的邊界案例。
2. 先寫答案怎樣才算成功：把 JSON 是否可解析、必含欄位、事實清單、允許的語氣或工具參數寫成機器檢查；主觀品質才交給匿名盲評。
3. 固定兩個主 arm：A 用 Mercury 2.5 instant，B 用現有 production model；Mercury medium 是同模型敏感度分析，不可只留下最好看的組合。
4. 先做 5 次不計分 warm-up：確認 key、timeout、串流 parser 與 usage 都正常。Pilot 後才凍結 max_completion_tokens；上限太低造成的截斷仍是產品失敗。
5. 以 AB／BA 順序逐題跑：同一題前後緊鄰，順序隨機；把原始 SSE、完整輸出與 HTTP 錯誤保存到不可變檔案，再從 raw artifact 產生摘要表。
6. 先看失敗，再看中位數：依序檢查 first-attempt success、P95 可行動時間、P50 總時間與 cost per success。只有品質過預設門檻，速度差才有決策意義。

這個最小版不是統計結論，而是用來抓出評測管線的錯誤。確認 prompt 沒洩漏答案、評分器沒有偏向某種格式、兩邊都能完成任務後，再增加樣本與測試時段。若模型 alias 會滾動更新，報表務必記下回傳的 model 名稱、日期與 output hash，否則下次無法判斷是模型變了，還是網路變了。

四種任務怎麼出題與打分？

1. Voice response：人要等第一句，不是等全文

痛點：模型總時間很短，卻可能讓通話先沉默。解法：固定客服或預約對話，要求兩句內、不要 Markdown；歧義時只問一個澄清問題。把 t_actionable 定義為 parser 看見第一個句界標點後的時間，並事先凍結縮寫／小數例外與 timeout；分開記錄模型時間，不把 ASR、TTS 與電話網路混入。品質檢查 slot 是否正確、是否遵守長度、該轉人工時有沒有轉交。Voice 題另開一層測 realtime=true，不可和主測的 false 混算。完整語音端評估可接著看 Voice Agent Eval。

2. Search reranking：答案短，更看格式與排序

痛點：重排常只回傳一串 ID，tok/s 幾乎沒有解釋力。解法：可凍結 TREC 2019 Deep Learning passage qrels與對應 MS MARCO corpus，保存 query IDs、index／retriever 版本、BM25 參數、top-20 passages、截斷規則與同分排序；要求只輸出 strict JSON IDs，每題輪換三種候選順序。計分使用 nDCG@10、top-1 relevance（例如明訂 qrel ≥ 2）、schema validity 與順序敏感性，並固定 trec_eval 版本與 relevance level；速度則量到完整 JSON 可 parse 的時間。若格式錯誤，即使文字很快也算 task failure。

3. Tool subtask：快送出錯參數，仍然是慢

痛點：只計到第一個 tool delta，會忽略 JSON 尚未閉合與工具執行。解法：準備 single call、可平行的獨立 calls、相依 multi-turn 與 no-tool 題；凍結 case IDs、期望 call graph、argument canonicalizer、stub responses 與工具 timeout，兩個模型收到完全相同的 schema 和本機唯讀 stub。分開量第一組完整 arguments、模型總時間、工具時間與 task E2E，再檢查函式名稱、參數、相依順序，以及最後答案是否真的根據 tool result。官方 Tool Use 指南示範模型可在一次 response 回傳多個獨立 tool_calls，並建議對相依操作採序列呼叫；公開指引沒有要求讀者設定專用開關，但這不構成某個額外參數不受支援的證據。

4. 長文寫作：速度要扣掉重寫成本

痛點：長文最容易讓高吞吐量看起來驚人，也最容易因漏事實而整篇重來。解法：凍結 evidence packet、字數範圍、必含事實與禁止捏造項；輸出匿名、隨機排序，交給兩名不知道模型名稱的評審，分歧再由第三人仲裁。硬門檻可設為：所有格式限制通過、必含事實至少 8／10、沒有 critical unsupported claim，再評結構與可讀性。只有通過的文章才進成功分母，人工修訂時間另列。

怎麼判定速度值得換品質？

不要用「平均分差不多」直接放行。先註冊 non-inferiority margin，例如定義「Mercury−baseline」後，二元成功率的 95% 區間下界要高於 −3 個百分點、搜尋 nDCG@10 要高於 −0.02；以 task ID 為重抽樣單位做 paired bootstrap，並另外確認主要延遲指標的區間有利，兩道門都過才放行。每種任務只指定一個主要品質與一個主要延遲 endpoint，避免事後挑數字。這些門檻是產品決策範例，不是 Mercury 的既有成績，應依錯誤成本調整。樣本先從每類 20 題做 pipeline sanity check，這不足以穩定估計 P95；有穩定流量再擴大，同時報 P50、P95、first-attempt error rate，別只挑最好的一次。

批次摘要、搜尋重排、結構化抽取與短工具子任務可列為 Mercury 2.5 的優先驗證假設，理由只是它們常由程式等待完整結果；這篇 Puter 報告沒有測這四類的 task success、工具正確率或併發產能，不能先宣布 generation burst 已轉成 pipeline 產能。語音與互動 UI 則要看首內容、第一個完整句子與 P95；如果畫面長時間空白，應測 instant，另加低延遲用途的 realtime=true 分層，並設計進度回饋。長文寫作必須讓 evidence fidelity 與重寫時間決定結果，不能只看吐字速度。想把這些規則落成多模型路由，可參考 AI 模型路由 Eval；想理解 serving 對速度的影響，可讀 LLM 推論引擎教學。

Mercury 2.5 常見問題 FAQ

1. Mercury 2.5 的 1,107 tok/s 是假的嗎？

不能這樣下結論。它是 Inception 在未完整公開測試設定下的 generation throughput 宣稱；Puter 的原始第三方測量中位數 1,241 tok/s 在數值上屬相同量級，但路徑不同，tokenizer、硬體與設定也無法對齊核對，因此不是對官方宣稱的獨立重跑。公共 API 的首內容、整體延遲與你的 workload 仍要另測。

2. tok/s、TTFT 和總延遲有什麼差別？

tok/s 描述開始輸出後或某個計時窗內的速度；TTFT 是等到第一塊內容；總延遲是整個 request 完成。互動產品通常先在意 TTFT，批次 pipeline 通常更在意總延遲。

3. Diffusion language model 是一次生成整篇嗎？

不是。多個位置可以在同一輪平行處理，但模型仍要經多輪精煉；實際產品還受 serving、kernel、batch 與輸出策略影響。

4. instant 就是關掉 reasoning 嗎？

官方把它定義為最低延遲的 reasoning effort，不叫 off。文章與報表都應保留原名；跨模型的 low／instant 也不代表相同運算量。

5. diffusing=true 適合正式速度測試嗎？

不適合當一般 streaming 主測。它會送回每個去噪階段的完整中間文字，前一版需要被覆寫；用來看視覺效果可以，正式比較應固定 false。

6. Reasoning Token 要另外算一次費用嗎？

不用重複相加。官方 usage 定義中 reasoning Token 已包含在 completion Token，按 output rate 計費。

7. Mercury 2.5 最適合哪種工作？

可先把由程式等待完整結果的批次摘要、重排、抽取與短工具流程列為待驗假設；互動或語音要以可行動時間與尾端延遲重新過門檻。這是輸出形狀推導出的測試順序，不是公開資料已驗證的適用性結論。

8. 新手今天應先做哪一步？

從一個真實任務挑 20 題，先寫成功條件，再跑 Mercury instant／medium 與現有模型。只要保留 prompt hash、時間、usage、output 與失敗原因，就比抄一張 tok/s 排行榜更接近可採購的答案。

重點整理

• 1,107 tok/s 是廠商的 generation throughput 宣稱，不等於首內容、P95 或公共 API SLA。
• Puter 的同 prompt 彙總同時報告 1,241 tok/s 與約 5 秒首段可見文字，示範「開始後快」和「開始得晚」兩個指標可以背離。
• 文字 diffusion 能在一輪處理多個位置，但不是 one-pass，也不能把一般論文細節直接套到 Mercury 2.5。
• Mercury 官方 reasoning 值是 instant／low／medium／high，不是 off／on。
• 四種任務要分開定義 task success、可行動時間、總延遲與每成功成本。
• 品質先過不劣門檻，速度才有資格變成路由依據。