AMD R9700 實測：ROCm 10，27B 模型、128K context 和 MTP (Windows 11 Pro)
分享一下我這段時間折騰 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 的等待時間還是很明顯。
我的配置
| 項目 | 配置 |
|---|---|
| GPU | GIGABYTE Radeon AI PRO R9700 32GB，gfx1201 |
| CPU / RAM | Ryzen 7 9800X3D / G.SKILL Trident Z5 Neo 64GB DDR5-6000 |
| 系統 / Driver | Windows 11 / 32.0.31019.2002 |
| Backend | ROCm 10.0.0 clean stack，官方 llama.cpp b10814 |
| 模型 | unsloth/Qwen3.8-27B-GGUF，UD-Q6_K |
| 圖片 projector | BF16 mmproj |
| Context / KV | 131072 / K、V 都用 q8_0 |
| MTP | draft-mtp，n=2；draft KV 也是 q8_0 |
| 其他 | Flash Attention on、parallel 1、batch4096 / ubatch1024、threads 8 |
主機板、SSD 等完整零件和價格我放在後面。圖片端到端流程在部署時已通過，下面的跑分則全部是文字測試。
實際跑分
這次我直接傳入固定長度的 token array，沒有再用字數估算。每組都核對 cache_n=0，MTP 也確認有啟用。
| 實際輸入 tokens | Prefill tok/s | 首字等待（TTFT） | MTP acceptance |
|---|---|---|---|
| 2,048 | 785.5 | 2.68 秒 | 94.1% |
| 32,768 | 555.6 | 59.1 秒 | 100% |
| 65,536 | 410.1 | 160.0 秒 | 100% |
| 102,400 | 316.1 | 324.4 秒 | 74.5% |
| 122,880 | 282.5 | 435.7 秒 | 未保存詳細計數 |
這裡的 120K 是 122,880 個輸入 tokens；128K 則是 server 配置容量 131,072，兩個數字不要混在一起。隨著輸入變長，prefill 下降，首字等待明顯增加。
生成速度我另外測，不把它和 prefill 混成一個 tok/s：
| 輸出長度 | Wall-clock | Server-reported | MTP acceptance |
|---|---|---|---|
| 256 tokens，清除殘留 server 後 | 38.07 tok/s | 39.23 tok/s | 60.17% |
| 512 tokens，正式 baseline | 35.4 tok/s | 36.6 tok/s | 53.0% |
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 輸入試過另一組：
| 120K A/B | 4096 / 1024 | 16384 / 2048 |
|---|---|---|
| Prefill | 282.5 tok/s | 280.4 tok/s |
| TTFT | 435.7 秒 | 438.2 秒 |
| Dedicated memory | 28.2 GiB | 29.1 GiB |
| Shared memory | 0.82 GiB | 1.87 GiB |
| 錯誤 | 0 | 0 |
速度差很小，一次測試不足以說大 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 輸入為例：
| 舊 Vulkan 模式 | Prefill tok/s | Decode tok/s | TTFT 秒 |
|---|---|---|---|
| MTP off | 496.304 | 22.168 | 132.281 |
| MTP n=2 | 477.646 | 44.426 | 137.529 |
| MTP n=3，補齊 draft q8 KV 後 | 469.014 | 46.524 | 139.986 |
這張表能看舊環境內部的 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系統。
| 零件 | 9月市場價 - 加幣 | 6月購入價 - 加幣 | 6月購入價 - 換算人民幣 |
|---|---|---|---|
| AMD Ryzen 7 9800X3D | 569.99 | 609.99 | 2,958 |
| ASUS TUF X870E-PLUS WIFI7 | 379.99 | 379.99 | 1,843 |
| G.SKILL Trident Z5 Neo 64GB DDR5-6000 | 1,729.99 | 1,419.99 | 6,886 |
| GIGABYTE R9700 32GB | 2,499.99 | 2,049.99 | 9,942 |
| Phanteks XT Pro Ultra | 109.99 | 104.99 | 509 |
| ASUS TUF Gaming 1000W Gold | 269.99 | 219.99 | 1,067 |
| WD_BLACK SN7100 2TB（6月第1顆） | 499.99 | 409.99 | 1,988 |
| be quiet! Pure Rock Pro 3 | 79.99 | 79.99 | 388 |
| WD_BLACK SN7100 2TB（8月第2顆） | 499.99 | 424.99 | — |
R9700 的9月 CAD 2,499.99 是缺貨牌價，不代表當天買得到。兩顆 SSD 也不是同時買：6月第一顆 409.99，8月第二顆 424.99，所以我把它們分開列。
RMB 只換算6月已知購入金額，使用 2026/9/4 的 1 CAD ≈ 4.8497 CNY
| 整套配置成本對照（CAD） | 9/6 報價／估算 | 原購入價格 |
|---|---|---|
| 商品小計，未折扣 | 6,639.91 | 5,699.91 |
| Combo 折扣 | -300.00 | -845.00 |
| 折後稅前小計 | 6,339.91 | 4,854.91 |
| 稅金 | 760.79 | 584.90 |
| 運費 | 19.24 | 19.24 |
| 含稅及運費總額 | 7,119.94 | 5,459.05 |
所以我目前整套配置的累計支出是 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
| 檔案 | Bytes | SHA256 |
|---|---|---|
| Qwen3.8-27B-UD-Q6_K.gguf | 21983677344 | c9c206812fbe4ac7b76a729e25928b63f2ae89d37f69da7a71c20aec763cd436 |
| mmproj-BF16.gguf | 931146432 | 83ee4f4f205fa514161778c41df1ea14144faa0f713510893b63c2395f5c2d53 |
| llama-b10814-bin-win-rocm-10.0-x64.zip | — | 5e088b105d480836751c4ae4826523acd0053caf6688fcca4a94763ab171bee2 |
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幫我整理，我再檢閱. 多多指教。