2026-11-03/04，透過 AIHubMix 在五家供應商上測試了 DeepSeek V4.1 Flash 1017，並使用 APB Full 套件：每次的問題、參數和請求指令碼都相同。這份 APB Profile 僅涵蓋 Baidu 的測試結果，並逐節呈現。
以下數字僅為分數，不代表排名或供應商推薦。Q 38.00、F 88.39、P 37.77、K 68.85 和 R 100 先行列出；總分 56.48 是摘要指標，沒有信賴區間。評分規則依據 AIHubMix Provider Benchmark Standard v2.0。
五家供應商的分數
粗體標示本文所探討的供應商。供應商依固定順序列出，不代表排名。K 是 P 的子分數，占 20%。總分是摘要指標，沒有信賴區間。官方通道與 Alibaba Cloud 相差 0.37，這項差異無法區辨。
概覽
- Q：38.00。BFCL 86.40%、HLE 9.36%、AA-LCR 32.80%。綜合結果比官方通道低 4.46 個百分點，95% 區間為 −5.78 至 −3.16，不包含 0。HLE 記錄 864 次請求失敗，AA-LCR 則有 100 次，幾乎全部發生在第一個時段，並計為錯誤答案。
- F：88.39。174 項納入計算的檢查中，有 148 項通過。未回傳快取讀取欄位與思考 token 數量；超出上下文範圍和孤立工具結果案例則回傳 200。
- P：37.77。90 次十路並行探測中，有 50 次回傳
no_available_channel，因此超過半數無效，TTFA 和 TPOT 均按懲罰值計分。90 次單路並行探測中，有 78 次有效。 - K：68.85。8k 熱請求中有 5/9 次命中，另有 3 次請求失敗；32k 前綴則有 8/9 次命中。命中數以 1,024-token 區塊回報：8k 為 7,168 tokens，32k 為 31,744 tokens。
- R：100。專用的 300 次請求全部在第一次嘗試時成功。回答與速度探測期間的通道失敗計入 Q 和 P。
測試設定
請求使用 AIHubMix 的 快速入門路由和供應商專屬 ID，參數則遵循 DeepSeek 的 API 文件；其他供應商 ID 列於模型頁面。這不是直接連線至 Baidu 自有帳戶。
| 欄位 | 值 |
|---|---|
| 模型 | DeepSeek V4.1 Flash 1017 |
| 請求的模型 ID | baidu-deepseek-v4.1-flash-1017 |
| 回傳的模型名稱 | deepseek-v4.1-flash-1017 |
| 存取路由 | 透過 AIHubMix 使用供應商專屬模型 ID；並非直接連線至供應商自有帳戶 |
| 參數 | 非思考模式、temperature 1.0、max_tokens 16,384、逾時 300 s、不自動重試 |
| 關閉思考模式 | 每個請求皆使用 reasoning_effort=none |
| 時間 | 2026-11-03 18:07 – 11-04 16:33 UTC+8；五家供應商共用一台 Mac mini、同一網路與帳戶 |
| 樣本 | 4,250 次回答嘗試（BFCL 500 × 3、HLE 250 × 10、AA-LCR 25 × 10）；60 個 function 案例 × 3 個時段；90 次單路並行與 90 次十路並行速度探測；300 次穩定性請求；30 次快取探測（8k 和 32k 前綴各三組） |
Q — 回答品質：38.00
回答品質測試包含三種任務：500 個 BFCL 任務各回答三次、250 個 HLE 任務各回答十次，以及 25 個 AA-LCR 任務各回答十次。BFCL 依自動規則評分；HLE 和 AA-LCR 則由評審模型 deepseek-flash 判定正確或錯誤。五家供應商使用相同的任務集，並將三種類型合併為一個準確率。由於任務無法判定，移除了十筆回答，最終納入評分的嘗試共 4,240 次。
| 任務 | 題數 | 答對 | 準確率 | 失敗 |
|---|---|---|---|---|
| BFCL 工具呼叫 | 500 × 3 | 1,296/1,500 | 86.40% | 0 |
| HLE 高難度問題，由評審評分 | 250 × 10 | 233/2,490 | 9.36% | 875 |
| AA-LCR 長文件推理 | 25 × 10 | 82/250 | 32.80% | 100 |
| 綜合 · 95% 區間 36.23%–39.58% | — | 1,611/4,240 | 38.00% | 975 |
服務失敗，包括請求失敗或輸出遭截斷，仍計入分母並視為錯誤答案。HLE 有 864 次請求失敗（第一個時段 863 次，第二個時段 1 次），另有 11 個輸出在 max_tokens 上限處遭截斷。AA-LCR 有 100 次請求失敗，全部發生在第一個時段。
每個 BFCL 任務回答三次；表格呈現三輪合併結果。
| BFCL 類別 | 通過 | 通過率 |
|---|---|---|
| simple_python：單一函式，呼叫與參數正確 | 336/360 | 93.33% |
| multiple：從多個函式中選出正確函式 | 269/300 | 89.67% |
| parallel：平行呼叫同一個函式數次 | 268/300 | 89.33% |
| parallel_multiple：平行呼叫多個不同函式 | 206/240 | 85.83% |
| irrelevance：沒有適用的函式時，不進行呼叫 | 113/150 | 75.33% |
| ahm_multi_turn：三階段工具鏈 | 104/150 | 69.33% |
與其他四家的比較
差異以相較於官方通道的百分點表示，鬚線顯示 95% 區間。若區間跨過 0，則視為無法區辨。HLE 和 AA-LCR 的評審模型 deepseek-flash 與受測模型同屬 DeepSeek 系列，且未經校準，因此判斷結果可能偏寬鬆。
F — 函式支援：88.39
函式案例測試介面是否依照通訊協定規格運作，而非模型回答得好不好。六組共 60 個案例，在三個時段各執行一次，共 180 項檢查，並依據供應商文件所述格式判定。不適用、無效或未觀察到的檢查會從分母排除。Baidu 納入計算的檢查共 174 項，其中 148 項通過，加權分數為 88.39。
各組分數依該組所占權重計算，並非單純以 148/174 計算。
| 案例組別 | 權重 | 通過 | 排除 | 組別分數 |
|---|---|---|---|---|
| 串流與訊息通訊協定 | 20% | 27/27 | 3 | 100.00 |
| 工具介面 | 20% | 30/30 | — | 100.00 |
| 輸出限制與參數 | 20% | 29/30 | — | 96.67 |
| 上下文與狀態 | 15% | 26/30 | — | 86.67 |
| 錯誤與復原 | 15% | 21/30 | — | 70.00 |
| 用量計量與快取通訊協定 | 10% | 15/27 | 3 | 55.56 |
| 總計，加權後 | 100% | 148/174 | 6 | 88.39 |
| 失敗案例 | 失敗時段 | 原因 |
|---|---|---|
| 超出上下文範圍（上下文與狀態） | 3/3 | 應回傳參數錯誤；實際回傳 200 |
| 格式錯誤的訊息（錯誤與復原） | 3/3 | 回傳 400，但回應本文為空，沒有結構化錯誤 |
| 孤立工具結果（錯誤與復原） | 3/3 | 應回傳參數錯誤；實際回傳 200 |
| 格式錯誤的 stream_options（錯誤與復原） | 3/3 | 回傳 400，但回應本文為空，沒有結構化錯誤 |
| 快取讀取欄位（用量計量與快取通訊協定） | 3/3 | 未回傳快取讀取欄位；無法確認讀取結果 |
| 思考 token 計量（用量計量與快取通訊協定） | 3/3 | 未回傳思考 token 數量 |
| 輸入計入工具定義（用量計量與快取通訊協定） | 3/3 | 加入工具定義後，回報的輸入 token 數量沒有增加 |
| 快取前後的輸入計數一致（用量計量與快取通訊協定） | 3/3 | 未回傳快取讀取欄位；無法確認讀取結果 |
| 取樣多樣性（輸出限制與參數） | 1/3 | temperature 為 0 和 1 時的重複輸出差異過小，未達預先登錄的標準 |
| 請求間隔離（上下文與狀態） | 1/3 | 第一步未依要求只回覆 STORED，因此無法繼續進行隔離檢查 |
以下檢查不納入分母：既不算通過，也不算失敗。
| 狀態 | 案例 | 數量 | 原因 |
|---|---|---|---|
| 未觀察到 | 串流停止序列 | 3 | 前一步之後未送出此步驟的請求，因此無法判定 |
| 不適用 | 明確指定 cache_control | 3 | 預先登錄為此介面不支援 |
五家供應商的格式錯誤 messages 和格式錯誤 stream_options 檢查全都失敗：兩者皆回傳 400，但回應本文為空，客戶端無法取得結構化錯誤。五家都出現的失敗較可能發生在 AIHubMix 閘道層，需要另行調查。五家供應商的思考 token 計量也全都未通過，但原因各異：即使關閉思考模式，ByteDance 和 Fireworks 仍回報思考 token；另外三家則未回傳思考 token 數量。
與其他四家的比較
P — 回應速度：37.77
每個請求包含約 10,000 個輸入 token，並要求生成約 1,100 個輸出 token 的本文。三個時段中，每個時段都送出 30 次單路並行探測和 30 次十路並行探測，共 180 個請求。
| 指標 | 結果 |
|---|---|
| 首 token TTFA | 單路並行中位數 2.26 s（有效請求中位數 2.05 s）；十路並行超過半數無效，中位數按無限大計（有效請求中位數 1.86 s） |
| 生成速度 TPOT | 單路並行 3.48 ms/token；十路並行 50.00 ms/token（超過半數無效，採用懲罰值） |
| 有效吞吐量（有效吞吐） | 十路並行 1,329.2 token/s |
| 有效請求 | 單路並行 78/90（第一個時段 18/30）；十路並行 40/90（第一個時段 0/30，第三個時段 10/30） |
| 無效原因 | 62 次探測回傳 400 no_available_channel |
| 組成分數 | TTFA 0.00、TPOT 0.00、吞吐量 100.00；回應分數 30.00 |
| P 的組成 | 回應分數 30.00，占 80%；快取 K 68.85，占 20%；總分 37.77 |
TPOT 是根據串流區塊估算，並非在硬體上逐 token 測量。有效吞吐量是十路並行負載下的有效輸出 token 數除以批次的總耗時。
在十路並行層級中，90 次探測有 50 次回傳 no_available_channel。由於超過半數無效，首 token 時間中位數視為無限大，TTFA 和 TPOT 均採用懲罰值。單路並行層級則有 90 次探測中的 78 次有效。
五家供應商共用一台機器、同一網路與帳戶。三個時段依供應商逐一排程，因此資料收集期間並未完全重疊；不宜過度解讀細微差異。
K — 快取：68.85
每組送出五個請求。第一個請求包含約 8k 或 32k token 的固定前綴，並建立快取。第 2 至第 4 個請求保留前綴，只更改末尾的問題，間隔分別為 5 s、30 s 和 120 s。第五個請求使用新的前綴，作為冷快取對照。三個時段 × 兩種長度，共 30 個請求。K 是熱請求讀取的快取 token 數，除以依規則應可重用的 token 數，兩種長度各占一半權重。K 占 P 的 20%。
表格顯示伺服器回報的快取讀取 token 數；「未回傳」表示回應中缺少該欄位。
| 前綴 | 時段 | 種子請求 | +5 s | +30 s | +120 s | 冷快取對照 |
|---|---|---|---|---|---|---|
| 8k | 1 | 失敗 | 失敗 | 失敗 | 未回傳 | 未回傳 |
| 8k | 2 | 未回傳 | 7,168 | 7,168 | 失敗 | 失敗 |
| 8k | 3 | 未回傳 | 7,168 | 7,168 | 7,168 | 未回傳 |
| 32k | 1 | 未回傳 | 未回傳 | 31,744 | 31,744 | 未回傳 |
| 32k | 2 | 未回傳 | 31,744 | 31,744 | 31,744 | 未回傳 |
| 32k | 3 | 未回傳 | 31,744 | 31,744 | 31,744 | 未回傳 |
8k 前綴命中 9 個熱門請求中的 5 個，讀取了原本可重用的 72,252 個 token 中的 35,840 個，得分為 49.60。32k 前綴命中 9 個中的 8 個，讀取了 288,261 個中的 253,952 個，得分為 88.10。兩種長度各占相同權重，K 為 68.85。共有 5 個 8k 請求整體失敗：視窗 1 的種子請求、5 秒與 30 秒請求，以及視窗 2 的 120 秒與冷快取對照請求，錯誤皆為 no_available_channel。因此，8k 級別還有 3 個熱門請求失敗。
命中時，回報的讀取量以每 1,024 個 token 為一個區塊計算：8k 前綴為 7,168 個 token，32k 前綴為 31,744 個 token。未命中時，使用量區塊不包含 prompt_tokens_details；表格記錄為「未回傳」，該值以 0 計算。
與其他四家相比
R — 服務穩定性：100
這 300 個請求分為四種類型：短文字、長輸入、工具呼叫和多輪對話紀錄。這些請求在三個時段以單一併發數送出。僅檢查首次回應是否有效且完整，不評分答案，也不重試。回答期間與速度測試中的失敗會計入 Q 和 P，不會再次計入 R。
| 請求類型 | 首次嘗試成功率 |
|---|---|
| 短文字 | 120/120 |
| 10k 長輸入 | 90/90 |
| 工具呼叫 | 60/60 |
| 多輪對話紀錄 | 30/30 |
| 總計 | 300/300，95% 信賴區間 98.78%–100% |
300 個請求全都在首次嘗試時回傳有效且完整的回應。R 100 僅涵蓋這 300 個專用請求，並不代表整個服務路徑毫無失敗。300 個請求全數成功時，95% 區間的下限為 98.78%，因此失敗率很可能低於 1.22%。
與其他四家相比
R 僅涵蓋這 300 個專用請求；回答期間與速度測試中的失敗會記錄在 Q 和 P，不會再次計入 R。
| 供應商 | 首次嘗試成功率 | 95% 信賴區間 |
|---|---|---|
| ByteDance | 300/300 | 98.78%–100% |
| Baidu | 300/300 | 98.78%–100% |
| Alibaba Cloud | 300/300 | 98.78%–100% |
| DeepSeek 官方 | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
常見問題
整體分數代表什麼？
這是彙整指標，不含信賴區間，也不是認證。本文呈現 Q、F、P、K 和 R，不對任何供應商提出推薦。
為什麼 10 個併發探測中有一半失敗？
90 個回應中有 50 個回傳 no_available_channel。由於無效回應超過一半，首個 token 時間的中位數視為無限大，TTFA 和 TPOT 均按其懲罰值計分。
R 100 是否代表沒有通道失敗？
不是。R 涵蓋 300 個專用請求，這些請求都在首次嘗試時成功。速度測試中的 62 個 no_available_channel 回應，以及回答測試中的失敗，分別計入 P 和 Q。
為什麼 32k 前綴命中 9 個中的 8 個，K 卻是 68.85？
兩種長度各占相同權重。8k 前綴命中 9 個熱門請求中的 5 個，得分為 49.60；32k 命中 9 個中的 8 個，得分為 88.10；平均後為 68.85。
Baidu 的答案品質與官方通道有明顯差異嗎？
有。合併 Q 的差異為 −4.46 個百分點，95% 信賴區間為 −5.78 至 −3.16，不包含 0。這是唯一一個低於官方通道，且信賴區間不包含 0 的供應商結果。
哪些檢查未納入 F？
共 6 項：前一步驟的請求未送出，因此無法觀察到的 3 項串流停止序列檢查，以及 3 項事先登記為此介面不支援的明確 cache_control 檢查。
繼續閱讀：DeepSeek V4.1 Flash 系列
- Baidu 的 BFCL 準確度接近官方通道；接下來的 ByteDance 文章將以相同測試套件檢視工具呼叫與用量計量結果：DeepSeek V4.1 Flash on ByteDance：工具呼叫相符，用量計量不同
- Baidu 單一併發的 TTFA 為 2.26 秒，與一場達到 1.34 秒的測試形成對比：DeepSeek V4.1 Flash on Alibaba Cloud：首個 token 1.34s，快取命中率 99.37
- Baidu 的 F 為 88.39，對照組測試為 94.00，且有 15 次無效探測：DeepSeek V4.1 Flash on the official channel：F 為 94.00，15 次無效探測
- Baidu 的 8k 快取命中率為 5/9，對照組測試為 3/9，且停止回覆內容為空：DeepSeek V4.1 Flash on Fireworks：停止回覆內容為空，快取命中 3/9
