在兩台 DGX Spark（GB10）上跑本地大模型一段時間之後，CyberQ 在公司 Lab 累積了不少解碼速度的數字，比方說某個 checkpoint 幾 tok/s、開了投機解碼變幾 tok/s、草稿接受率多少。這些數字都是真的，但它們回答不了許多讀者來信提問真正想知道的事，接上 agent harness 之後，到底好不好用。
為了解開這個疑問，CyberQ 設計了一套嚴謹的實證評測，涵蓋兩套 Agent Harness（Qwen Code 與 DeepSeek Harness）、5 種推論伺服器設定、7 個代表性任務與許多次的重複實驗。初期的 168 次執行在驗證逐題統計穩定性時發現不足，隨後擴充 120 次重複樣本，並進一步補上跨雙機張量平行（TP=2）的 102 次執行，最終累積了 390 次完整的 Agent 執行紀錄。每一次執行皆在乾淨獨立的工作目錄下展開，成敗完全由自動化驗證腳本判定，杜絕任何依賴模型自我陳述的主觀干擾。實測揭露的結果不僅打破了許多直覺假設，更在實驗過程中發現了幾個統計與架構陷阱。
評測環境與測試架構配置
為了確保所有資料的可重現性與公平性，評測環境釘住了核心軟體套件版本與模型設定。Harness 端採用 2026 年 8 月 19 日釋出的 Qwen Code 0.21.14（關閉自動更新）以及 DeepSeek Harness 0.1.0-rc.7。推論引擎統一使用 vLLM 0.26.1rc1（映像檔標籤為 vllm/vllm-openai:muse-glimmer）。受測模型包含透過雙機 TP=2 部署於節點 A 與 B 的 DeepSeek-V4-Flash-0731（搭配 DSpark n=5，服務於 8008 埠），以及部署於節點 A 的 Qwen3.8-27B NVFP4 量化版本。Qwen3.8-27B 涵蓋了 TP=1 的 MTP n=2 對照組、TP=1 的 DFlash2 n=7 投機解碼組，以及跨雙機 TP=2 的 DFlash2 n=7 加速組。
| 測試配置標籤 | 模型與量化格式 | 拓撲架構 | 投機解碼配置 | 服務埠號 |
| DS4-Flash | DeepSeek-V4-Flash-0731 | 雙機 TP=2（131+141） | DSpark n=5 | :8008 |
| Qwen3.8-27B (基準組) | unsloth NVFP4 | 單機 TP=1（131） | MTP n=2 | :8006 |
| Qwen3.8-27B (DFlash2組) | Inferact NVFP4 | 單機 TP=1（131） | DFlash2 n=7 | :8009 |
| Qwen3.8-27B (對照組) | Inferact NVFP4 | 單機 TP=1（131） | MTP n=2 | :8009 |
| Qwen3.8-27B (TP=2組) | Inferact NVFP4 | 雙機 TP=2（131+141） | DFlash2 n=7 | :8007 |
兩套 Harness 均直接與 vLLM 的 API 埠通訊，刻意繞過原本 CyberQ 放在本系統中的 LiteLLM Proxy。這是因為 Proxy 的全域回呼常式中註冊了 clamp_max_tokens.handler，會無差別將所有請求的 max_tokens 強制截斷至 8192，導致推理模型在長思考過程中耗盡預算並回傳空內容。此外，評測時雙方皆不傳送取樣參數，完全回歸各檢查點 generation_config.json 的預設值，DS4-Flash 為 temperature 1.0 與 top_p 1.0。Qwen3.8-27B 則為 temperature 1.0、top_p 0.95 與 top_k 20。雖然 DeepSeek 官方建議在 Agent 情境使用 top_p 0.95，但由於 DeepSeek Harness 的未提供 top_p 欄位，為了避免非對稱設定破壞比較基準，雙方維持原廠預設值，並將最大生成長度統一鎖定在 32000 token。
七項任務的試金石：常規開發無差別，分水嶺落在排錯場景
評測所設計的七個任務涵蓋了軟體工程師日常仰賴 Agent 處理的典型場景。任務 01 要求修復會靜默丟棄最後一段資料的 off-by-one 缺陷並通過既有測試。任務 02 負責將兩個模組中的重複函式重構抽取至共用模組且維持行為不變。任務 03 提供真實 vLLM 啟動崩潰紀錄，要求找出根本原因並給出完整環境變數修法。
任務 04 要求排查設定檔中的連接埠衝突，同時嚴格禁止修改已簽訂契約的保留埠。任務 05 要求依規格從零撰寫 CLI 工具並通過未公開的獨立測試資料。任務 06 在長達 90,208 token 的龐大文件中精準檢索三項分散事實。任務 07 則是要求執行讀檔、計算、寫檔、自我驗證的四步相依工具鏈。
| 任務編號 | 任務主體與驗證要求 | 核心考察能力 |
| 01 | 修復靜默丟棄最後資料段的 off-by-one 缺陷 | 單檔程式碼除錯與單元測試全綠驗證 |
| 02 | 跨模組重複函式重構與共用化 | 跨檔案結構理解與行為等價重構 |
| 03 | 分析 vLLM 當機記錄並輸出完整環境變數修正方案 | 深層日誌診斷與跨組件隱性相依排查 |
| 04 | 解決服務連接埠衝突且不得更動契約保留埠 | 設定解析、約束條件遵守與邊界處理 |
| 05 | 從零實作 CLI 工具並通過隔離測試集 | 完整功能實作與黑盒介面驗證 |
| 06 | 於 90,208 token 長文本中檢索三項散落事實 | 超長上下文檢索與精確字串匹配 |
| 07 | 執行「讀檔 → 計算 → 寫檔 → 驗證」四步工具鏈 | 外部工具呼叫、狀態傳遞與多步驟自我驗證 |
測試結果呈現出顯著的兩極化分布。在任務 01、02、04、05、06 與 07 這六個項目中，DeepSeek Harness 與 Qwen Code兩套 Harness 搭配不同模型與推論配置，在基本輪次中寫下了 264 次執行零失敗的完美紀錄，所有跨單元組合全部順利過關。這項資料證明，當面對程式碼重構、單元除錯、規格撰寫、超長文本檢索或多步相依呼叫時，現代開源本地模型搭配成熟 Harness 已經具備充足的實用能力，工具選型在此類常規任務上並無顯著優劣之分。
本系列測試中，所有的失敗案例均集中在任務 03。該任務給出的崩潰日誌結尾為 AssertionError: DeepGEMM layout transform requires sm_90a or sm_100a, got sm_121a。此處的深層陷阱在於，僅將全域開關設定為 VLLM_USE_DEEP_GEMM=0 並不足以解決問題，因為 MoE 路由有獨立的控制變數 VLLM_MOE_USE_DEEP_GEMM=0，必須同時關閉才能讓服務順利啟動。
CyberQ 發現，兩套 Harness 在任務 03 展現出截然相反且高度一致的失敗模式。DeepSeek Harness 展現了 deep dig 行為，在 DS4-Flash 上兩度耗盡 17 分鐘的執行時限而未能產出任何檔案。在尚未切斷外網連線的早期測試中，它甚至發出了 56 次 Shell 呼叫，一路從 GitHub 抓取原始碼、查詢 API、讀取 PyPI 元資料，最後還透過搜尋引擎檢索，只為了反覆驗證日誌中早已載明的答案，最終因過度嚴謹而超時停擺。
相反地，Qwen Code 表現得極為迅速且自信，每次都在兩分半鐘內給出產出，其對 sm_121a 架構不支援 DeepGEMM 的根因診斷完全正確，但產出的修復指令卻寫成拼字錯誤的 VLLM_USE_DEEPGEMM=0（遺漏了底線），且對 MoE 的專屬開關並沒有更多說明。這份回答表面上極具專業水準，但若直接套用至正式環境則毫無作用。這兩種傾向，一個是「追求周延以致做不完」與「迅速產出卻埋藏隱形錯誤」的行為分歧，成為選型時權衡品質風險的關鍵分水嶺。
Token 計算分歧與壁鐘時間的統計問題
在評估推論成本時，若直接拿兩套 Harness 回傳的原始資料相減，會得到 DeepSeek Harness 輸入 Token 量僅有 Qwen Code 十五分之一的高度差異結論。然而，這是一個嚴重的統計假象。深入追查追蹤日誌後發現，兩套 Harness 對快取讀取量（cacheReadTokens）的定義完全相反，DeepSeek Harness 將其視為與 inputTokens 並列相加的獨立數值，在某些紀錄中甚至出現快取量大於輸入量的反常現象。Qwen Code 則遵循 OpenAI 慣例，將快取量視為輸入 Token 的內部子集。若直接拿未標準化的欄位進行跨系統比較，確實就會產生倍率失真。
| 計算基準 | DeepSeek Harness 計數 | Qwen Code 計數 | 實質比例差距 |
| Harness 回報原始欄位（任務 01 未標準化） | 44,498 | 111,790 | 表面差距約 2.51×（部分指標曾失真至 15×） |
vLLM 伺服器端實體計數器 (prompt_tokens_total) | 44,638 | 111,578 | 真實差距為 2.50×（全套件落於 1.91×–2.21×） |
以伺服器端中立的計數器 vllm:prompt_tokens_total 作為客觀標準，兩者的實際差距約為兩倍左右（DS4-Flash 為 2.21×，Qwen3.8-27B 為 1.91×）。造成固定開銷差異的主因，在於 Qwen Code 在發送任務前會預先載入 28,409 字元的系統提示詞與 45,930 字元的工具 Schema，換算約為 1.8 萬個 Token 的基礎最低消費。在具備 Prefix Caching 的標準注意力模型上，這筆開銷能被快取吸收，但是在 64 層中有 48 層為 Gated DeltaNet（GDN）線性注意力結構的 Qwen3.8-27B 模型上，線性層會無法命中 Prefix Cache，導致 42 次執行的快取命中率全數歸零，使固定開銷最大的架構，在解碼最慢的模型上被迫承受了完整的 Prefill 代價。
另一個奇怪的數字是投機解碼的加速倍率。初次計算時，DFlash2 在任務 02 跑出了高達 4.98× 的加速比。然而檢視單次原始資料後發現，MTP 在該題的三次耗時分別為 389 秒、67 秒與 323 秒，其生成 Token 量高達 6111、1144 與 5170。而 DFlash2 的耗時為 72 秒、65 秒與 64 秒，生成 Token 量為 2487、2320 與 2123。MTP 的耗時暴增並非源於解碼緩慢，而是在 temperature 1.0 的取樣條件下，Agent 偶然選擇了路徑極長的生成策略。
當把重複實驗擴充到 8 次（新增 120 次執行）並透過 Bootstrap 重新計算 90% 信賴區間時，該題的中位數加速比直接從 4.98× 回落至 1.65×（信賴區間為 1.40–5.48）。壁鐘時間的組內離散度在樣本數增加後依然高達 6.0 倍與 9.6 倍，證明這種時間波動是 Agent 真實的行為路徑差異，無法單純藉由增加樣本數來收斂區間。相反地，以輸出 Token 數除以壁鐘時間定義的吞吐量指標，能精確剔除行為路徑的長度干擾，其信賴區間在所有任務上均收斂在正負 0.1 內，並穩定維持在 1.83×（DeepSeek Harness）與 1.77×（Qwen Code）的實質加速水準。
投機解碼實戰：DFlash2 在 GB10 上的部署與機制洞察
DFlash2 採用區塊擴散平行草稿模型搭配候選路徑選擇器架構。在 GB10（sm_121a）上的整合過程中，相關支援全數由 Python 模組構成，完全不涉及底層 CUDA、C++ 或 CMake 的重新編譯。由於既有映像檔已內建基礎架構，新映像檔在 12 秒內便建置完成。
在部署細節上，環境必須正確啟用 use_v2_model_runner 配置。若略過此項設定，系統將退回舊版草稿路徑，導致候選選擇器完全未被呼叫，使系統在無任何報錯的情況下靜默退化為前代效能。伺服器啟動時，日誌必須明確印出 Using V2 Model Runner 以及 Capturing model for DFlash2 speculator 才能確認完整生效。此外，DFlash2 候選選擇器要求未量化的 LM Head，這導致同時量化了 lm_head 的 unsloth NVFP4 權重遭到拒絕，必須採用將 lm_head 排除在量化範圍外的 Inferact NVFP4 權重方可正常載入。
在標準隔離測試與實際 Agent 負載之間，DFlash2 與張量平行展現了截然相反的失真現象。
| 測試架構改動 | 隔離散文測試加速比 (256 tokens) | Agent 任務實測吞吐加速比 | 效能表現趨勢 |
| DFlash2 ÷ MTP | 1.51× | 1.83× | 實戰環境中優勢放大 |
| TP=2 ÷ TP=1 | 1.76× | 1.54× | 實戰環境中優勢收斂 |
DFlash2 的效能優勢在 AI Agent 任務中被顯著放大。這是因為 AI 代理人Agent 的輸出多為程式碼、工具呼叫 JSON 與結構化編輯語法，其語意規律性與可預測性，遠遠高於自由散文，使得 7 個 Token 的草稿區塊擁有更高的驗證通過率。相對地，TP=2 的加速優勢在 Agent 任務中出現收斂，原因在於張量平行僅能加速 Prefill 與解碼階段，但 Agent 執行過程中的 Shell 指令執行與檔案讀寫耗時完全不變，固定開銷的存在拉低了整體倍率。而在任務 06（長文本檢索，1.69×）與任務 07（四步工具鏈，1.66×）中，由於大量時間花費在 90,208 token 的 Prefill 與外部工具呼叫上，投機解碼所能貢獻的整體加速比，當然就因此降低了。
GB10 跨雙機張量平行實測與雙節點 TP=2 效能表現
CyberQ 在完成單節點評測後，進一步去實驗把 Qwen3.8-27B 擴展至跨雙機張量平行（TP=2）環境，驗證分散式推論在 Agent 負載下的擴展能力與穩定性。模型權重與 Drafter 透過高速直連網路，以約 320 MB/s 的速率同步至第二節點，並逐位元組比對確認無誤，覆蓋層映像檔在第二台機器同樣僅花 12 秒即建置完成。
雙機環境上線後，完整的 102 次執行表現出優異的系統穩定性，兩台機器的日誌中未曾出現任何記憶體非法存取、核心當機、CUDA 或 NCCL 錯誤。在任務成功率方面，雙機 TP=2 取得了 49/51 的通過率，整體水準與單機環境相當，甚至在任務 03 出現了一次成功解答。
| 測試配置組別 | 任務通過次數 | 中位壁鐘時間 | 匯總吞吐量 (dsh) | 匯總吞吐量 (qwen-code) |
| MTP n=2, TP=1 | 48/51 | 119.7 秒 | 15.80 tok/s | 14.94 tok/s |
| DFlash2 n=7, TP=1 | 48/51 | 69.9 秒 | 28.84 tok/s | 26.46 tok/s |
| DFlash2 n=7, TP=2 | 49/51 | 38.2 秒 | 44.39 tok/s | 41.47 tok/s |
GB10 雙機 TP=2 的實際吞吐量達到 44.39 tok/s（DeepSeek Harness）與 41.47 tok/s（Qwen Code），相較單機 TP=1 實現了 1.54×–1.57× 的加速，而相較單機 MTP 基準，更達成了約 2.8×（2.81× 與 2.78×）的整體效能提升。
評測方法論防護與未涵蓋邊界
為了確保 390 次評測資料具備足夠的嚴謹度與可信度，測試框架落實了多項底層工程防護措施。所有任務的驗證腳本在正式執行前均完成雙向自我校驗，確認原始狀態必定判定失敗、正確解法必定通過，並防範任何作弊行為，例如任務 05 透過未公開測資重測以防硬編碼，任務 04 嚴禁修改契約保留埠。每次測試均配置全新工作目錄以阻絕殘留檔案，並採嚴格循序執行以避免共用 GPU 產生資源競爭。由於 CyberQ 的測試伺服器曾於滿載時發生無預警斷電，所有評測資料在寫入 JSONL 時均即時執行 fsync 處理。
在環境公平性與可重現性方面，評測框架封鎖了外部網路連線，僅保留內部 Loopback 供 Harness 連接本機 vLLM 服務，避免 Agent 透過 Shell 發出非受控的網路請求而破壞測試一致性。Qwen Code 設定為 yolo 模式以避免預設分類器攔截指令或產生額外的 Token 開銷，同時關閉 autoConfigureMemory 以維持對等結構。在前置健康檢查中，更排除了自訂測試提示詞所導致的吞吐量失真，確認提示詞形態對量測資料具有決定性影響。
這項評測也存在明確的邊界條件，測試僅針對功能通過與否去判斷，但是沒有對產出程式碼的架構美感與品質進行質化評分。任務 03 由於基準通過率過低而維持三次重複，測試未涵蓋超過 17 分鐘或足以觸發上下文壓縮的超長工作階段，子 Agent、Plan 模式、Skills、工作流程與 MCP 等進階功能也沒有納入本次測試路徑。至於多輪互動對話、雙機 TP=2 下的 MTP 拓撲對照組、長時間持續高壓穩定性，以及繁體中文與多模態場景，均屬於後續研究的領域。
實測的核心工程啟示
CyberQ 認為，在日常軟體開發情境下，兩套主流 Harness 的表現難分高下，且本地模型的能力已完全足以應付日常任務，真正的能力差距僅在極端除錯與邊界決策場景中才會顯現。
跨工具比對效能指標時，必須先校準底層計數標準，尋求中立的伺服器端實體監控作為裁判，避免落入定義差異造成的倍率陷阱。
在架構效能評估上，單一倍率數字往往會因工作負載特徵而往不同方向失真，投機解碼在高度結構化的程式碼生成任務中，能顯著取得超越基準測試的加速效益，而平行運算加速則會受到工具呼叫等固定開銷壓縮，但還是很快啦，比起單機來說。
面對高度隨機性的 Agent 行為，壁鐘時間容易受到生成路徑長度干擾，唯有回歸吞吐量指標並檢驗信賴區間的收斂特性，才能在有限的運算資源中，找出真實可靠的系統效能結論。
