分享一下我這段時間折騰 R9700 的結果。
我想用一張 32GB 卡在 Windows 跑本地 AI，平常透過 Hermes 使用，也希望保留128K長上下文和看圖功能。

目前我定下來的組合是 ROCm 10 + llama.cpp b10814 + Qwen3.8-27B UD-Q6_K，搭配 128K context、q8 KV、MTP n=2 和 BF16 mmproj。

先說結果：**獨立 512-token 輸出測試約 **35.4 tok/s（wall-clock）／36.6 tok/s（server-reported）****；精確 120K 輸入可以完成，但首字要等 435.7 秒，約 7 分 16 秒。所以對我來說，長 context 是能用，但一次塞進十幾萬 tokens 的等待時間還是很明顯。

我的配置

主機板、SSD 等完整零件和價格我放在後面。圖片端到端流程在部署時已通過，下面的跑分則全部是文字測試。

實際跑分

這次我直接傳入固定長度的 token array，沒有再用字數估算。每組都核對 cache_n=0，MTP 也確認有啟用。

這裡的 120K 是 122,880 個輸入 tokens；128K 則是 server 配置容量 131,072，兩個數字不要混在一起。隨著輸入變長，prefill 下降，首字等待明顯增加。

生成速度我另外測，不把它和 prefill 混成一個 tok/s：

256-token 那次 wall time 為 6.72 秒，server evaluation time 為 6499.66 ms，所以兩個速度稍有不同。512-token 的完整計時起止沒有留下，我保留原本的指標名稱。

這是 synthetic 測試，不是自然中文或 coding 的保證速度。 長輸入使用重複 token，MTP 比較容易接受 draft；我不會把表裡的 100% 當成日常對話也能達到。這些是部署時保存的單次結果，尚未做多次平均、長文品質或長時間壓力測試。

我為什麼選這套版本和參數

ROCm 10：先把環境整理乾淨。 我之前曾混用新 runtime 和舊 hipBLAS／rocBLAS，後來改成獨立的 ROCm 10 SDK 和官方 package，核對實際載入的 DLL。官方更新也包含 Windows memory-pool allocation stall 修正，值得測試，但不能只憑版本號就說速度提升多少。ROCm 10 更新說明

b10814：因為我實際驗證過這個官方包。 我試過自己編譯 b10819 和另一個 upstream 版本，在 Windows 的 ROCm Clang／MSVC 工具鏈遇到 host/device 編譯衝突，最後沒有編成。官方 b10814 則通過模型載入、長 context、MTP、看圖和 Hermes 使用流程，所以我先固定用它。b10814 官方下載

MTP n=2：已經可用，先不繼續追 n=3。 最終 ROCm 的 512-token baseline 有 53% acceptance。舊 Vulkan 測試中，n=3 在 64K 相對 n=2 只多約 4.7% decode，卻多約 1 GiB dedicated memory；我因此沒有繼續往上調。這不是 ROCm n=2／n=3 的正式對照，也不能說 n=2 一定最優。

batch4096 / ubatch1024：加大之後沒有看到收益。 我用同樣 122,880-token 輸入試過另一組：

速度差很小，一次測試不足以說大 batch 必然更慢，但我沒得到好處，記憶體用量又增加，就保留 4096/1024。這次同時改了兩個參數，也沒法單獨判斷是哪個造成差異。

幾個真的影響結果的坑

最值得提醒的是 prompt 長度和重複 server，它們都曾讓我的數字失真。

• 早期「64K」其實只有 45,372 tokens。 當時用字元數估算，整批輸入約短了 30.8%。那些 32K／64K／100K 成績已撤回，正式表是改用精確 token array 後重測的。我當時懷疑長 context 會讓 MTP 關閉，後續測到 120K 仍啟用，也撤回了這個推論。
• 舊 server 沒退乾淨。 新 server 跑分時，舊 ROCm 7.1 server 還在佔 GPU／shared memory，曾量到只有 12.79 tok/s。清除後的 256-token 測試回到 38.07／39.23 tok/s。這是排除資源互搶，不能說成升級 ROCm 後三倍加速。
• Hermes 曾啟動沒有模型的 router。 它佔著服務 port，旁邊又有真正的模型 server；另一次 launcher 漏了 auth 參數。後來我固定從同一個 launcher 啟動，並核對實際模型和 Hermes 請求，不只看 health 正常。
• 必要時完整重啟後端。 只殺掉其中一個 server 後，記憶體分佈仍不理想。我最後停掉全部 server、確認 port 釋放，等約 15 秒，再只啟動 production 一次。這裡的 cold restart 是重啟後端，不是重開 Windows。
• Smart App Control 曾擋住 DLL。 b10814 最初的 0xC0E90002 後來查到是 Code Integrity 阻擋 ggml.dll，不是單純缺 DLL。後續已成功載入，但我沒有保存具體 UI 修復步驟，因此不把它寫成一條通用解法。

編譯失敗的細節、事件編號和登錄檔處理，我留在私人技術筆記。對這篇跑分而言，重點是最後用哪個成功的 binary，以及測試時有沒有其他程序干擾。

跟我以前的 Vulkan 比起來呢？

我有舊 Vulkan b10819 的數據，但當時用的是 non-UD 模型、128-token synthetic 輸出，不能直接跟現在的 UD-Q6_K、512-token baseline 排名。

以舊環境的 65,536-token 輸入為例：

這張表能看舊環境內部的 MTP 差別，但不能證明 ROCm 或 Vulkan 全面勝出。特別是舊測試輸出高度重複，n=2 曾全數接受 draft，生成速度會很好看。要回答 backend 誰更快，我還需要用同一模型 hash、相同輸入和輸出長度重做對照。

我的硬件花了多少錢？(加拿大溫哥華)

以下來自我補充的 Excel 價格表：2026/9/6 Newegg.ca PC Builder 參考價在前，六月購入金額在後。購入欄是折扣前的零件金額，Combo 另計，不能直接當成每件折扣後淨成本。截止2026年9月6日, 這個主機組合2個月時間漲了約23%左右，後續加買了一樣的SSD 2TB給LINUX系統。

R9700 的9月 CAD 2,499.99 是缺貨牌價，不代表當天買得到。兩顆 SSD 也不是同時買：6月第一顆 409.99，8月第二顆 424.99，所以我把它們分開列。

RMB 只換算6月已知購入金額，使用 2026/9/4 的 1 CAD ≈ 4.8497 CNY

所以我目前整套配置的累計支出是 CAD 5,459.05，包含八月加買的 SSD。九月同配置參考總額約 7,119.94，差 1,660.89（30.42%）；其中不只零件牌價變動，也包含 Combo 優惠減少。9月稅金和運費是表內估算，不是完成結帳的報價。

海外加拿大沒有魔改卡, 否則我當初是想買京東保養的魔改卡

目前的價格也不想買第2張R9700, 所以想搭建UBUNTU那邊主要想玩Minimax H3

我目前的使用結論

折騰完之後，我留下了一套固定的 ROCm 10 環境、一個 production server，以及 UD-Q6_K／BF16 模型組合。舊 runtime、模型和 ROCm 7.1 殘留清掉後，約釋放 31 GiB；顯示驅動保留，最後 health、MTP、看圖和 Hermes 都確認正常。

我現在比較傾向保存版本、hash 和設定，以後需要時乾淨重建，不再留一堆舊 runtime 備份。35 tok/s 級別的這筆輸出測試對我的目標已經可用；真正要接受的限制，是 100K 以上新 prompt 的等待時間。

目前還缺自然中文／coding 的重複測試、長時間穩定性和功耗數據，所以這篇先當作我的部署與跑分分享。

附錄：重現所需的版本與參數

主模型與 BF16 projector 都固定在 repo revision：

4ca720788d1e01f1bff70c033e0d0028fd02e502

llama.cpp 完整 commit：1548a240e36079f07856c95c53de1ec2770840ab。上述 hash 是我的部署紀錄，不是本次重新下載後計算。官方 commit

以下是我的啟動狀態和參數摘要，檔案位置用佔位符取代；分行僅為方便閱讀，實際執行需按 shell 處理換行。

llama-server.exe
  --model MODEL_GGUF --mmproj MMPROJ_GGUF
  --alias Qwen38-27B-UD-Q6_K
  --host 127.0.0.1 --port 1234 --api-key-file KEY_FILE
  --ctx-size 131072 --cache-type-k q8_0 --cache-type-v q8_0
  --n-gpu-layers 99 --parallel 1 --flash-attn on
  --batch-size 4096 --ubatch-size 1024
  --threads 8 --threads-batch 8
  --spec-type draft-mtp --spec-draft-n-max 2
  --spec-draft-type-k q8_0 --spec-draft-type-v q8_0
  --metrics

我的 launcher 使用 process-local SDK PATH，沒有實作 singleton lock；維護時仍需確認沒有舊 server。長 prompt 也要同步檢查 client timeout，不能只改 server context。

第一次發長文, 我另一個SSD的LINUX那邊也裝好了HERMES QWEN 3.8 27B Q6 一樣的ROCM10 模型 上下文，如果感興趣我會再發LINUX那邊的測試結果。文章主要由AI幫我整理，我再檢閱. 多多指教。