延續上一篇的實測，我們來看看 DeepSeek-V4-Flash-0731 ，它是 V4-Flash 的正式版，模型結構與 V4-Flash-DSpark 相同，出廠就附帶投機解碼模組，284B 總參數、每 token 活躍 13B 的稀疏 MoE，原生 1M context，並支援可調整的推理深度。官方公布的代理向數字不錯，Terminal Bench 2.1 拿到 82.7，Toolathlon Verified 70.3，DeepSWE 54.4，和 Qwen3.8-27B 的 73.0 相比，差距是拉開一截的。由於這是，尚待第三方驗證，而本文主要討論是下面這兩件會影響選型的事。
DeepSeek-V4-Flash-0731 它適合的任務其實很明確，凡是前面推薦給 Qwen3.8-27B 的長時程代理工作，只要你公司或家裡的硬體放得下，都應該優先考慮它，包括長時程程式碼代理、整個 repo 的重構、跨多工具的自動化流程等等，都適合使用它來讓資料不離境，以及省雲端 AI API 的 token，關鍵任務輸出才給雲端，其他則在這個地端就可執行。
其次，它的混合注意力架構本來就是為了壓低超長 context 的推論成本而設計，1M context 加上 13B 活躍參數，prefill 與解碼速度都會比密集 27B 舒服，這對系統提示動輒上萬 token 的代理框架是實質優勢。
環境
| 項目 | 值 |
|---|---|
| 機器 | NVIDIA GB10（DGX Spark），128 GiB 統一記憶體，driver 580.173.02 / CUDA 13.0 |
| 模型檔 | /var/lib/ds4-models/DeepSeek-V4-Flash-0731-IQ2XXS-w2Q2K-AProjQ8-SExpQ8-OutQ8-imatrix.gguf |
| 檔案大小 | 86,720,111,520 B = 80.76 GiB |
| DSpark 支援檔 | DeepSeek-V4-Flash-DSpark-support-0731.gguf，5,989,114,272 B = 5.58 GiB，stages=3 block=5 markov_rank=256 |
| 伺服器 | ~/src/ds4/ds4-server，git 84cc882，2026-08-10 自建 |
| 常態旗標 | --ctx 100000 --batched-session 2 --kv-cache-continued-interval-tokens 2048 --cuda --warm-weights |
| 記憶體規劃 | 權重 80.76 + KV 1.64 + buffers 0.76 = 83.16 GiB（ctx=100000、兩個常駐 session 另需 4.81 GiB context buffer） |
四個伺服器生命週期：
| 代號 | 設定 | 日誌 |
|---|---|---|
| S1 | production 預設（batched 2、無 DSpark） | ~/ds4-server.log |
| S2 | 無 batched、無 DSpark（對照組） | raw/s2.log |
| S3 | 無 batched、DSpark 開、DS4_DSPARK_STATS=1 DS4_DSPARK_SPEC_LOG=1 | raw/s3.log |
| S4 | batched 2、DSpark 開、同上儀表 | raw/s4.log |
這次刊出前補測，其中看ds4-server --help thinking 到現在還寫著：In thinking mode, client sampling knobs are ignored like the official API.
那行說明是舊的，程式碼（ds4_server.c:11646-11656）只對客戶端沒送的旋鈕套用固定值，明送的 temperature / top_p / top_k / min_p 一律優先，README 也是這樣寫的。更進一步，request_init()（ds4_server.c:813-824）本來就對每一個請求先填上temperature 1.0、top_p 1.0、min_p 0.05，而思考模式那段填的是同樣這四個值，所以思考模式對取樣什麼都沒改。
因此實測（同一個 prompt、400 token、比對輸出的 sha256）：
| 送出的參數 | 思考 | 三個 seed 的輸出 |
|---|---|---|
temperature 1.0, top_p 0.95（官方代理評測設定） | 開 | 三份都不同 |
| 同上，但 seed 固定不變 | 開 | 兩次逐位元相同 |
temperature 0 | 開 | 三份逐位元相同 |
| 完全不送取樣參數 | 開 | 三份都不同 |
temperature 1.0, top_p 0.95 | 關 | 三份都不同（對照） |
temperature 0 | 關 | 三份逐位元相同（對照） |
固定 seed 重跑會拿到一模一樣的輸出，換 seed 才會分歧，分歧來自取樣器。而且思考模式在 temperature 1.0 下產出的東西，跟它自己在 temperature 0 下產出的東西根本不一樣。
全伺服器唯一真的強制貪婪的地方，是 DSML 工具呼叫的結構性 token（ds4_server.c:11657-11659），而且字串參數的內容還被排除在外。這一點也看得出來，同一個工具請求換三個 seed，函式名稱與參數骨架逐位元相同，body 欄位的內容每次都不一樣。
DSpark 在代理工作負載下保不住加速
把 DSpark 真的掛上去（--mtp 支援檔 5.58 GB --dspark），開伺服器自己的DS4_DSPARK_SPEC_LOG 逐輪計數。每組 1 暖機 + 2 量測，速率取伺服器自算的解碼速率（不含 prefill）：
| 條件 | 無投機 | DSpark | 倍率 | 走投機路徑的 token |
|---|---|---|---|---|
思考 + temperature 0 | 17.88 | 19.00 | 1.06× | 98.8% |
思考 + temperature 1.0 / top_p 0.95 | 17.69 | 17.71 | 1.00× | 0% |
| 思考 + 不送取樣參數（代理框架的實際行為） | 17.80 | 17.81 | 1.00× | 0% |
| 思考 + 官方取樣 + 工具 | 17.76 | 18.58 | 1.05× | 23.8% |
思考 + temperature 0 + 工具 | 17.84 | 20.56 | 1.15× | 100% |
這樣的測試結果顯示 :
第一，取樣一開，DSpark 一次都不提案。 中間兩列的 spec enter 是 0 行，不是「有提案但接受率低」。這兩件事在報告裡必須分開，因為它們的解法完全不同。對照組（不掛 DSpark）在貪婪 17.88 與官方取樣 17.69 之間幾乎沒有差別，所以差距全部來自投機失效，不是取樣本身的成本。
第二，就算全程貪婪，加速也只有 1.06×。 關機時的彙總統計是accept_rate=82.20% avg_accept=0.683，接受率看起來漂亮，但 no_draft=2135、scheduler_skips=1694，大部分輪次根本沒有草稿可用。 24.2 秒對上 628 秒的目標模型時間，約 3.8%。
第三，production 設定直接把投機關掉。s->batched_mode = (batched_sessions > 0)，而投機路徑要求 !batched_mode（ds4_server.c:11669）。我們常態跑 --batched-session 2 讓排程任務與互動代理不互相卡住；加上這個旗標之後，即使 temperature 0、即使 DSpark 已載入，spec enter 還是 0 行，速度回到 17.66。
代理框架要並行就得開 batched session，一開就沒有投機，這道門比取樣還要前面。
代理情境（帶工具、官方取樣）確實還撿得到 1.05×，來自工具呼叫骨架被強制貪婪的那一小段，佔了那一輪 23.8% 的 token。但那是單輪、單工具、214 token 的形狀撐出來的比例，真實代理回合的思考與散文段落應該多半遠長於此，所以這個比例只會更低。
結論因此就會改成，DeepSeek V4 Flash 0731 的處境跟 Muse-Glimmer 相同，不是相反。投機解碼的加速在真實取樣設定下留不下來，這條規律到目前為止沒有例外。
單台 GB10 跑得動 DeepSeek V4 Flash 0731，但只能 2-bit 量化
這台 GB10 跑的 0731，用的是 IQ2_XXS 混合量化，檔案 80.76 GiB，加上 KV 1.64 GiB 與 buffer 0.76 GiB，規劃 83.16 GiB，
而且它就是我們 dsh 代理框架的後端，已經穩定服務好幾天。這個版本的模型呢，末六層 experts 改用 Q4_K 的版本約 97.6 GB，對 128 GiB 的機器沒有餘裕。所以正確的說法是單台 128 GB 的 GB10 放不進 Q4 級別的量化，只能跑 2-bit 的混合量化，不是放不進主流量化版本，這也是它和上一篇文章我們提到前三款地端模型真正的差別，這三款是一台就跑得動，且不必在量化上讓步的東西。
那 2-bit 的品質到底會不會降低很多呢？有讀者寫信來關切這件事情，我們用專案自帶的評分題庫抽測 24 題（GPQA Diamond、SuperGPQA、AIME 2025 輪替），思考模式開啟，取樣用同一組官方設定（temperature 1.0、top_p 0.95），每題回覆上限 4096 token來測試，結果是 21/24 通過，AIME 7/8、GPQA Diamond 7/8、SuperGPQA 7/8，跑了 31 分鐘。三題失敗裡有兩題是撞到 4096 token 上限被截斷，只有一題是真的答錯，以下是實測結果。
IQ2_XXS 量化的品質抽測
ds4-eval 自帶題庫（GPQA Diamond / SuperGPQA / AIME 2025 / COMPSEC，三者輪替），取前 24 題（伺服器須停機，CLI 自己載 80.76 GiB 權重）：
./ds4-eval -m /var/lib/ds4-models/DeepSeek-V4-Flash-0731-IQ2XXS-...gguf --cuda \
--plain --questions 24 --tokens 4096 --think --temp 1.0 --top-p 0.95 --seed 1 \
--trace raw/eval-iq2xxs-q24.trace取樣設定是官方代理評測的 1.0 / 0.95，思考模式開啟。
結果：21/24 通過，3 題失敗，執行 31 分鐘。
| 題庫 | 通過 |
|---|---|
| AIME 2025 | 7 / 8 |
| GPQA Diamond（含 1 題 modified） | 7 / 8 |
| SuperGPQA | 7 / 8 |
三題失敗中有兩題是撞到 4096 token 上限被截斷（第 4 題 GPQA Diamond、第 9 題 AIME2025-02，gen 欄都是 4096），只有第 14 題 SuperGPQA 是在 81 個 token 內給出錯誤答案。也就是說 4096 的回覆預算讓分數偏低，不是偏高。24 題在 p≈0.875 下的 95% 信賴區間約 ±13 個百分點。
老實說，這個數字並不能拿來幹嘛，因為是絕對值，並非量化折損的數字。但因為本機沒有同一款模型高位元量化的對照組（Q4 那階 97.6 GB 塞不進來），確實無法說明 Q2 會掉多少品質。上游也明講這個題庫是回歸測試集，不該當成官方 GPQA／SuperGPQA／AIME 分數引用。我們只能說，24 題在這個通過率下的 95% 信賴區間約 ±13 個百分點，確實沒有崩掉，但不適合說掉了幾分，就實務上，這個版本之所以很多社群會採用，應該就是它能打能用吧，輸出品質掉的分數差異可能沒有太大，大家還能接受，畢竟它的智商比上一篇文章提到的這三款模型要強。
地端 AI 選型結論
搭配 Hermes Agent 與 OpenClaw，現階段的答案仍然是 GB10 肯定首選 DeepSeek V4 Flash 0731 的，但理由只剩一個而不是兩個。
能力面它是同價位帶的天花板，代理任務跑錯重來的成本邏輯在它身上同樣成立，2-bit 量化在我們的抽測裡沒有明顯崩壞。
但投機解碼在它身上占便宜這條理由要刪掉，實測下來它跟 Muse-Glimmer 一樣，投機的加速在真實取樣設定下留不住。
唯一的門檻仍然是記憶體，單台 GB10 跑得動 2-bit 的混合量化，跑不動 Q4 那一階。要吃到更好的量化，就是 CyberQ 接下來要做的雙 GB10 vLLM 部署。
這個測試我們重跑的目的，是驗證 DeepSeek-V4-Flash-0731 的思考模式使否會強制忽略取樣參數，讓貪婪路徑意外生效，等於官方附的 DSpark 投機模組在代理工作負載下能保住加速。
結論大致上這段架設與預期的前半段是錯的，後半段幾乎是錯的。 思考模式對取樣參數沒有任何特殊待遇，DSpark 在代理框架的實際請求形狀下一次都不提案，而如果開了 production 設定（--batched-session 2）更是不分溫度、直接把整條投機路徑關掉。
