AMD R9700 實測：ROCm 10，Qwen38-27B-UD-Q6_K、128K context 和 MTP
-
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 c9c206812fbe4ac7b76a729e25928b63f2ae89d37f69da7a71c20aec763cd436mmproj-BF16.gguf 931146432 83ee4f4f205fa514161778c41df1ea14144faa0f713510893b63c2395f5c2d53llama-b10814-bin-win-rocm-10.0-x64.zip — 5e088b105d480836751c4ae4826523acd0053caf6688fcca4a94763ab171bee2llama.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幫我整理，我再檢閱. 多多指教。
-
-
我感觉R9700有点尴尬，我之前也想买这个的，但是除了高一点的量化模型也没有太多的提升，效果也都差不多，token速度还有点慢
@heheimback 是这么回事 跑llm的话 不如7900xtx的960gb的带宽 快很多 跟4090的带宽是一个级别的
-
，
T terry 固定了此主题
-
抄作业结果。
模型：mlasli/Qwen3.8-27B-Heretic-Uncensored-Q6_K-GGUF
显卡：R9700 32gHeretic FP8 测试结果（Vulkan + R9700）
实际输入 tokens
Prefill tok/s TTFT (s) MTP Accept%
2,048 684 26.9 98.5%
32,768 623 78.1 99.0%
65,536 498 162.4 99.3%
对比论坛帖子（ROCm 10 + R9700）
输入 tokens 他的 Prefill 我们的 Prefill 他的 TTFT 我们的 TTFT
2,048 785.5 684 2.68s 26.9s
32,768 555.6 623 59.1s 78.1s
65,536 410.1 498 160.0s 162.4s
分析：我们的 Prefill 速度接近（Vulkan vs ROCm 差异不大）
TTFT 差异大是因为他的 TTFT 只算 prefill，我们的包含其他开销
MTP acceptance 非常高（98-99%），说明 MTP 工作正常
Decode 速度约 45 tok/s，和之前测试一致AI的分析对吗
-
抄作业结果。
模型：mlasli/Qwen3.8-27B-Heretic-Uncensored-Q6_K-GGUF
显卡：R9700 32gHeretic FP8 测试结果（Vulkan + R9700）
实际输入 tokens
Prefill tok/s TTFT (s) MTP Accept%
2,048 684 26.9 98.5%
32,768 623 78.1 99.0%
65,536 498 162.4 99.3%
对比论坛帖子（ROCm 10 + R9700）
输入 tokens 他的 Prefill 我们的 Prefill 他的 TTFT 我们的 TTFT
2,048 785.5 684 2.68s 26.9s
32,768 555.6 623 59.1s 78.1s
65,536 410.1 498 160.0s 162.4s
分析：我们的 Prefill 速度接近（Vulkan vs ROCm 差异不大）
TTFT 差异大是因为他的 TTFT 只算 prefill，我们的包含其他开销
MTP acceptance 非常高（98-99%），说明 MTP 工作正常
Decode 速度约 45 tok/s，和之前测试一致AI的分析对吗
-
Heretic FP8 多维度 MTP 测试结果
内容类型 Prefill Decode MTP Accept%
code 529.8 tok/s 43.6 tok/s 94.5%
math 529.2 tok/s 43.7 tok/s 93.9%
prose 528.5 tok/s 43.1 tok/s 90.4%
tool 527.8 tok/s 43.0 tok/s 89.3%
short 527.1 tok/s 43.0 tok/s 88.2%
long_prompt 526.6 tok/s 42.9 tok/s 87.3%
平均 - 43.2 tok/s 90.6%
