如何讀 DeepInfer Benchmark：V4.1-Flash 效能

DeepInfer 的 V4.1-Flash benchmark 很容易引用，卻很難解讀。每秒 token 數不是引擎的固有屬性；它是引擎、模型、批次、上下文長度、硬件配置與工作負載共同決定的屬性。圖表是某一趟旅程的地圖，不是對你這一趟的保證。

單位陷阱

服務討論中會出現三種不同的速率，它們不能互換：

一個系統可以同時有高 tokens/s/GPU 與低 tokens/s/user。decode 圖顯示的正是如此：併發上升時，總吞吐量上升，但每個使用者的輸出流變慢。這兩個數字都不是引擎的「速度」。

端到端延遲還包括網絡、排隊、分詞、排程與 API 開銷，這些都不在兩張圖裡。decode 的 100 ms/step 不代表 100 ms 的 time-to-first-token；325 tokens/s/user 也不代表 325 ms 的回應時間。

Prefill：批次換來吞吐量，延遲是代價

Prefill 處理 prompt 並建立 KV cache。批次越大，權重讀取的分攤效果越好，GPU 利用率越高，吞吐量也就上升。但每一步也更久，延遲因此上升。

DeepInfer 的 prefill 圖使用 4 張 SM100 GPU、131,072 token 上下文。標籤是 4,096 到 65,536 的批次大小。曲線先陡升，然後趨平：

• 每批 4,096 個 token 時，吞吐量約 60k tokens/s/GPU，每步約 68 ms。
• 16,384 時，吞吐量約 81k，每步約 200 ms。
• 65,536 時，吞吐量約 89k，每步約 730 ms。

轉折點比峰值更重要。若你的 SLO 很緊，你會待在曲線左側，並以吞吐量付出代價。若你跑的是離線批次評測，可以待在右側，接受更長的步驟。圖表不會告訴你哪一側才對——你的工作負載才會。

也要注意 prefill 圖量的是什麼：非快取輸入吞吐量。若你的 prompt 大部分都是快取命中，prefill 的工作量小得多，這條曲線就不是你的瓶頸。快取命中率是另一個變數，而缺席的 KV cache 系統正是為了把這個變數最大化。

Decode：併發換來吞吐量，互動性是代價

Decode 每個請求每步生成一個 token。併發請求越多，GPU 每步做的有用工作越多，總吞吐量上升。但每個請求在 token 之間等得更久，單一使用者速度下降。

DeepInfer 的 decode 圖使用 64 張 SM100 GPU、131,072 token 上下文，採 nextn=3 fixed 與 75% 單 token 草稿接受率。標籤是每個 DP rank 的請求數：

• 每個 rank 8 個請求時，總吞吐量約 2.6k tokens/s/GPU，每個使用者約 325 tokens/s。
• 64 個請求時，吞吐量約 15.5k，每個使用者約 248 tokens/s。
• 256 個請求時，吞吐量約 26k，每個使用者約 103 tokens/s。

這個形狀就是經典的服務取捨。聊天產品可能選左側；批次摘要或離線 agent 工作負載可能選右側。這張圖有用，因為它顯示整條前緣，而不是單一點。

examples README 給了 decode 吞吐量背後的計算公式：

decode throughput = avg_SPS × decode_num_requests × (1 + nextn) / cp

這是「全接受計算」：假設每個草稿 token 都被接受，不論真實接受率。圖表再把結果乘上 0.75 的接受率假設。若你的文字較難預測，真實數字會更低；若較易預測，則可能更高。

75% 的假設

推測解碼會提出草稿 token，再一次批次驗證。增益取決於有多少草稿被接受。decode 圖假設單 token 接受率為 75%，換算下來每步平均接受長度約 3.25 個 token。

這個假設對可預測的文字合理，對開放式推理、含罕見識別碼的程式碼或高度技術性的寫作就沒那麼合理。DeepSeek 自家的生產數據顯示，其 DSpark 配置的接受長度約在 3.2–3.3，所以圖表的假設並非憑空而來——但它仍是假設，不是你工作負載的屬性。

相關的 DSpark 優化——可變長度驗證——同樣取決於負載。DeepSeek 回報在其生產運行點可提升 4–7% 吞吐量，但在低併發時是小幅損失。這正好說明「推測解碼是免費的」為何是錯誤的心智模型：增益取決於接受率，也取決於你有多餘的驗證算力。

評測數字衡量什麼

評測腳本不是服務 benchmark。它們衡量模型在三個離線任務上的品質：

• AIME 2026：30 題，每題 32 個樣本，Pass@1 99.9%。
• GPQA Diamond：198 題，每題 8 個樣本，Pass@1 93.4%。
• HLE-Full：2,500 題（2,158 文字、342 圖片），每題 1 個樣本，Pass@1 42.6%。

Pass@1 是單一樣本答對的機率。AIME 每題 32 個樣本，99.9% 是 960 次取樣的平均；HLE 只有單一樣本，雜訊大得多。eval README 提醒，重複執行結果可能不同，且 Pass@1 只有在 coverage_complete 為 true 時才有效。

這些數字告訴你，模型在預設配置下於這些 benchmark 有相應能力。它們沒有告訴你這個引擎比另一個引擎更快、更便宜或更可靠。要知道那件事，你需要在相同硬件、上下文與工作負載下的服務 benchmark——最好由第三方來跑。

閱讀清單

看到推理 benchmark 時，請先問：

1. 單位是什麼？ tokens/s/GPU、tokens/s/user，還是 ms/step？
2. 工作負載是什麼？ 上下文長度、輸入輸出比例、快取命中率、請求到達模式。
3. 硬件是什麼？ GPU/NPU 型號、數量、互連、記憶體，以及是單節點還是叢集。
4. 批次／併發是多少？ 高併發下的吞吐量峰值，對延遲敏感的產品可能毫無意義。
5. 包含了什麼？ 只有引擎，還是含 KV cache、路由與 API 開銷的完整服務堆疊？
6. 假設了什麼？ 草稿接受率、快取命中率、量化、張量／管線平行。
7. 是誰跑的？ 廠商自測、獨立實驗室，還是附 commit hash 的重現？
8. 比較基準是什麼？ 相同模型、相同硬件、相同工作負載、相同 SLO？

若一項說法在其中三項以上站不住腳，就把它當方向性訊號，而不是採購數字。

回到圖表讀值，或繼續讀缺席的服務層。