Gigabyte Radeon Pro W7800 AI TOP 48GB + Qwen3.8-27B 本地部署實測報告
(這是我自己打的, 不是AI Report)
首先，我是一個layman， 一個不懂IT技術的香港普通人。年輕時也曾沉迷打機，能動手自己"砌機"(即組合和安裝電腦硬件)。不過隨著年齡增長，結了婚，有了小朋友，已有二十多年没去深水埗黃金電腦商場。買電腦會考慮買I-mac, mac mini之類的, 說白了就是收入好了, 不再折騰研究組裝，買一體機慳水慳力，可以多留一些時間給老婆仔女。
今年Open Claw大熱，我也手癢在Kimi上買了$199月費試玩。没有研究電腦發展多年的我，驚訝地發現AI Agent(或Harness)+LLM的生產能力已遠超過我想像。孩子大了，時間多了，折騰本質又回來。
當初找資料時，知道Mac Mini M4 16G可以部署試玩，花了$5000HKD，在二手市場買了一個回來日日夜夜研究。結果可想而知，用HKU Nanobot(香港大學的免費開源AI Agent Bot)，部署個什麼4B 8B模型，正中裴多菲那一首詩，「世上有電腦千萬顆，我卻只有一個蘋果；就這一個也已經太多，她早晚要氣死我……」(對原詩句有興趣的話，大家可以去找一找，很像Terry的幽默調侃的風格)。真的，問個天氣都能氣死你。
有句說話「成長就是客觀世界打破主觀世界的一個過程」。接受給水文"4B 7B Token自由"騙了的現實從新出發，在Nanobot上接入Deepseek V4 Flash，終於能實現生產力了。
但我就是不甘心，腰骨好似有股氣一樣，站起來說一定要實現本地部署的，有生產力的方案。坦白說，因為我是一個layman，Deepseek V4 Flash對我來說是完全overkill，我自覺根本用不到他的核心能力。我的需求也很明確，公司有一些資料需要蒐集、整理、分析，小孩被"教育恐怖主義"脅持，參加課外活動比上班更加地獄，我是需要一個有生產力的AI助手幫忙處理他們的日程，才能繼續遊戲人間。
其實調用deepseek api也很便宜，就是要時時想著"慳住洗"(省著用)不爽。本地部署可以隨便用，一家人亂用一通都得。
被水文騙了一次不要緊，精益求精再次做資料蒐集，看了"掄錘者"頻道，發現Terry說的內容都是很juicy，例如"Qwen 3.8 27B 是本地部署模型最好的模型，没有之一。"重點是什麼?不是這一句話"Qwen 3.8 27B 是本地部署模型最好的模型"，這一句隨處可見!重點是他有硬件參數，配置參數，實測接入AI Agent的效果，具體到幾多輪幾多步工作不掉線，能力是deepseek v4 flash 的8成功力。這才是真正的用家體驗。
8月28日，掄錘者出了一個叫"AMD W7900/W7800 48G 性價比如何?...."的視頻，我看了Terry的介紹，消化了在論壇裡多個用家報告AMD Radeon 7900XTX 24G的體驗，立即去網上看一下香港W7800 48G的價錢，發現這個性價比非常適合我。當時標價$24999HKD，我拿到報價單時已是$26999(折合人民幣23100-23200)，印象跟Terry說的差不多，於是果斷下單了，不是買單卡，是買一整部電腦。(買的W7800 48G過程也有一些疑慮，搜遍全網也找不到W7800 48G的體驗報告，我寫的這一篇可能是全網第一篇用家體驗)
配置如下：
AMD Ryzen 5 7500F CPU (Tray, AM5, 6Core/12Threads, 3.7/5.gGHz, 6MB L2, 32MB L3, TDP)
ASUS華碩 TUF GAMING B850I WIFI NEO AM5 ITX MB
Klevv DDR5 FIT V 黑色 6000MHz 32GB Kit (16GB*2, CLS 28-36-36-76)
Gigabyte技嘉 Radeon PRO W7800 AI TOP 48G Graphic Cards (GV-W7800 AI TOP-48G)
NZXT C Series C850 SFX Gold 850W Fully Modular ATX 3.1 Power Supply (80 Plus Gold, Cybenetics A-, 600W 12V-2x6 PCIe 5.1, 10yr warranty)
WD Black M.2. SN7100 1TB SSD (R:7250MB/s, W6900, WDS100T4X0E)
Fractal Design Ridge White ITX Case 白色(PCIe 4.0, FD-C-RID1N-12)
Thermalright AXP120-X67 ARGB Black CPU Cooler(下吹式散熱設計)
你可能會問，為何不買大ATX機箱，散熱較好呀?
香港住屋的面積小早已享譽國際。對一般人來說大一點機箱没什麼問題，對我來說每1cm都是戰場。所以雙卡不在考慮之列，大機箱不在考慮之列，因此最終成品就是這個小型運算中心。
請大家也不用問我硬件軟件資料是怎麼取捨。我的知識面停留在GTR機箱，EDO Ram和DDR Ram，CPU 386 486等等，你折騰我也折不出什麼來，反正我跟商家要求就是三點，機箱要細，散熱要好，電源要穩定。
現在我的工作硬件是這樣的：
Mac Mini M4 16g 256g hardisk + 綠聯外置Docker一個NVME 4TB Hardisk + 獨立Inference Server (W7800 48G)
- mac mini 24/7運行，裝Deeepseek Harness及所有Project
- W7800 電腦 24/7 運行，只做Inference Server
- mac mini 透過家中的hub調用Inference server
錢學森說"系統是指由多個相互關聯，相互作用，相互影響的的部份所組成的具有特定功能的有機整體。"
好了，經過簡短的介紹後，後面就是用以上配置，DSH + Qwen 3.8 27B (xhigh thinking)，3輪69步AI生成的AI Inference Server Report，歡迎大家隨便使用。
(AI生成Report)
️ 9/7 更新（先睇呢段）： 發文後我連續跑咗 48 小時（1,916 個請求、約 8,500 萬 tokens），將所有結論重新實測過。原文有三個結論被推翻：(1) W7800 上面 ROCm 反而快過 Vulkan（prefill +38%、MTP n=8 做到 65.1 t/s）；(2) KV cache 用全精度 f16 最快（q8_0 慢 3%、慳 4GB 但唔值得）；(3) 最終生產配置係 Q6_K + 2 個平行 slot（各 128K）+ f16 KV，唔係 Q8 單 slot。另外新增：SGLang 實測（W7800 上用唔到）、RAM 86% 謎團真相（要加
--no-cache-idle-slots）、兩日實戰數據同溫度記錄。詳細內容喺文末「9/7 更新」一節，原文保留作記錄。
我係邊個
呢篇帖子就係我嘅實測記錄。如果你都係同我一樣，唔係技術人員但想試下本地 AI，希望呢份報告對你有幫助。
硬件配置
| 部件 | 型號 |
|---|---|
| GPU | AMD Radeon Pro W7800 48GB（70 CU · 384-bit · 864 GB/s） |
| CPU | AMD Ryzen 7 7500F |
| 主機板 | ASUS B650M |
| 記憶體 | 32GB DDR5 |
| 存儲 | 1TB NVMe SSD |
| 系統 | Ubuntu 24.04 |
| 驅動 | Mesa Vulkan（RADV） |
BIOS 重要設定：
- Above 4G Decoding（ASUS 新版叫 Above 4G MMIO Limit）→ Enabled
- Resizable BAR → Enabled
軟件棧
- llama.cpp：Vulkan build（cmake -DGGML_VULKAN=ON）
- 模型：Qwen3.8-27B UD-Q4_K_M（Unsloth Dynamic 量化，16.4GB）
- 推理引擎：llama-server（port 8080）
- 前端：Hermes Agent（Mac Mini 遙距控制）
[9/7 更新] 而家生產已轉去 ROCm 7.2.4 build（實測更快，見文末 9/7 更新），模型升級到 UD-Q6_K（22GB），用 systemd 服務自動開機啟動、崩咗自動重啟。Vulkan build 留返做備份。
依賴套件（缺一不可）：
sudo apt install -y mesa-vulkan-drivers vulkan-tools libvulkan-dev \
glslc spirv-headers libshaderc-dev git build-essential cmake ninja-build
️ glslc 唔係 glslang-tools —— 兩個唔同嘅 package。我 first build 時就錯裝咗 glslang-tools，configure 失敗，查咗好耐先發現。
推理服務配置（生產環境）
[9/7 更新] 下面係 9/4 首日版本（Vulkan + Q4 + 單 slot 131K），已退役。而家嘅生產版本（ROCm + Q6_K + 2 slot × 128K + f16 KV）見文末「9/7 更新」第 6 節。
#!/bin/bash
exec ~/llama.cpp/build-vulkan/bin/llama-server \
-m ~/models/Qwen3.8-27B-UD-Q4_K_M.gguf \
--alias qwen3.8-27b --device Vulkan0 \
--fit off -ngl -1 --no-mmap \
--spec-type draft-mtp --spec-draft-n-max 2 \
-c 131072 -ub 512 \
--cache-type-k q8_0 --cache-type-v q8_0 \
--parallel 1 --cache-ram 32768 --flash-attn on \
--mmproj ~/models/mmproj-F16.gguf \
--image-min-tokens 1024 \
--host 0.0.0.0 --port 8080 --jinja --reasoning off
重點參數解讀（9/4 首日版）：
| 參數 | 值 | 原因 |
|---|---|---|
--parallel |
1 | 48GB VRAM 只夠跑 1 個 131K ctx 實例 |
--cache-ram |
32768 | prompt cache 放 system RAM，長對話 98% hit rate |
--spec-draft-n-max |
2 | 實測 sweep 2 最優（37.4 pps / 0.63 接受率） |
--cache-type-k/v |
q8_0 | KV cache 量化，慳 VRAM（9/7 更新：實測 f16 全精度反而更快，已改，見文末） |
--flash-attn |
on | 必須開，唔開會慢好多 |
實測數據
1. Prefill 速度（llama-bench）
| Prompt 長度 | 速度 (t/s) |
|---|---|
| 1K | 504 |
| 4K | 460 |
| 8K | 445 |
| 16K | 439 |
| 32K | 399 |
| 64K | 331 |
解讀：
- 1K-16K 範圍內速度衰減唔多（~12%），日常使用最舒服
- 64K 要 ~200 秒先吐首字
2. Decode 速度
| 場景 | 速度 (t/s) |
|---|---|
| 純 decode（無 MTP） | 29 |
| MTP n-max 2（agent 負載） | 37.4 |
| 散文/創作類 | 27 |
MTP 接受率： 0.63（n-max 2）
對比： 7900 XTX 篇文（lcz.me/topic/1164）MTP 開 73.4 t/s（工具調用負載）。我部 W7800 之前測出 37.4 t/s，以為慢一倍 — 後來照 topic 1164 公開嘅測試題目原樣複製先發現真相（見下節）。
3. 同題目對比實測（2026-09-04，最重要數據）
照 topic/1164 嘅 4 條工具調用題目 + 8 個 mock tools、n-max 5 原樣跑（每題 ×2）：
| 情境 | W7800 實測 | 7900 XTX 原文 | 比例 |
|---|---|---|---|
| 單一工具呼叫 | 56.7 t/s | 81.6 t/s | 0.69 |
| 平行呼叫兩個工具 | 54.8 t/s | 75.7 t/s | 0.72 |
| shell 任務 | 55.9 t/s | 70.8 t/s | 0.79 |
| 長參數工具 | 41.9 t/s | 65.6 t/s | 0.64 |
| 平均 | 52.3 t/s | 73.4 t/s | 0.71 |
結論：52.3 / 73.4 = 71%，幾乎完全等於 CU 數比例 70/96 = 73%！
- 差距係純硬件（7900 XTX 多 26 個 CU），唔係 config 問題
- 之前測到 37.4 t/s 係因為用「agent JSON + markdown 混合」負載 — MTP 接受率得 0.63
- 純工具調用（格式固定）接受率上到 0.78-0.96，速度即刻上返 52 t/s
4. KV cache 全精度 + 大 Context 實測（48GB 夠唔夠？）
Qwen3.8-27B 混合架構發現（讀 GGUF metadata）： 65 層入面得 17 層係 full attention（idx 3, 7, 11 … 63, 64 — 每 4 層一層 + 最後層），其餘 48 層係 SSM（linear attention），完全唔食 KV cache。所以 KV cache 比其他 65 層全 attention 模型細約 4 倍 — hybrid 架構嘅最大好處。
KV 計法：每 full-attn 層 = 4 kv-heads × 256 dim × 2 (K+V) = 2,048 elements/token；全 model = 34,816 elements/token（f16 = 68 KB/token）。
實測 VRAM（全部真機 loaded：Q4_K_M 16.4GB + mmproj 0.9GB + compute buffer）：
| 配置 | VRAM 用量 / 51.5GB | 結果 |
|---|---|---|
| 131K q8_0 KV（現行 production） | 23.0 GB | — |
| 160K f16（全精度） | 29.4 GB（free 22） |  冇 OOM |
| 160K f32（最盡全精度） | 40.7 GB（free 11） | 冇 OOM |
| 256K f16 | 36.9 GB（free 14.6） | 冇 OOM |
256K f16 照跑 topic 1164 題目（n-max 5，每題 ×2）：
| 情境 | 256K f16 | 131K q8_0 | 分別 |
|---|---|---|---|
| 單一工具呼叫 | 59.0 t/s | 56.7 t/s | +4% |
| 平行呼叫兩工具 | 52.4 t/s | 54.8 t/s | -4% |
| shell 任務 | 58.2 t/s | 55.9 t/s | +4% |
| 長參數工具 | 48.7 t/s | 41.9 t/s | +16% |
| 平均 | 54.6 t/s | 52.3 t/s | +4.4% |
結論：
- 48GB 上 160K 全精度（f16）甚至 f32 都冇 OOM；256K f16 都得
- f16 全精度 KV 比 q8_0 快（慳 dequant），大 context + 全精度係「免費升級」
- 推算 256K f32（~54GB）先會 OOM — 呢個先係 48GB 卡嘅物理上限
5. 模型精度升級實測（Q6_K / Q8_K_XL，2026-09-04）
48GB 仲有空間升模型精度，實測三隻 quant（全部 topic 1164 題目、n-max 5 純 MTP）：
| 模型（weights） | Config | VRAM | 平均 decode |
|---|---|---|---|
| UD-Q4_K_M（16.5GB） | 131K q8_0 | 23.0 GB | 52.3 t/s |
| UD-Q4_K_M | 256K f16 | 36.9 GB | 54.6 t/s |
| UD-Q6_K（22.0GB） | 256K f16 | 42.2 GB | 52.3 t/s |
| UD-Q8_K_XL（31.5GB） | 160K f16 | 44.3 GB | 32.9 t/s |
分析：
- Q6_K = 免費升級：質素明顯高過 Q4（6.5bpw vs 4.85bpw），但速度完全一樣（52.3 t/s），256K context 都保得住
- Q8_K_XL 懲罰好大：-37% 速度（32.9 t/s）— 權重 31.5GB，decode 每 token 要讀晒全部權重，撞正記憶體頻寬天花板（864 GB/s ÷ 31.5GB ≈ 27 t/s，實測 32.9 已算好）
- 頻寬模型驗證：Q4 16.5GB → 864/16.5 ≈ 52 t/s（實測 52.3 ✓）
- 結論：Q6_K @ 256K f16 = 甜點（42.2GB，free 9.3GB）；Q8_K_XL 只適合唔介意速度、要最高精度嘅場景
6. 實際使用體驗
- 日常對話（8-16K ctx）：流暢，每秒 30-40 字
- 長文處理（32K+）：首字要等 1-2 分鐘，但可以接受
- Vision（mmproj）：成功讀到相入面嘅品牌/價錢/型號
- 多輪對話：98% cache hit，唔會重新 prefill
踩過嘅坑（重要！）
坑 1：glslc 錯裝
症狀： cmake configure 失敗，報 Could NOT find Vulkan (missing: glslc)
解決： sudo apt install glslc（唔係 glslang-tools）
坑 2：headless GPU runtime PM
症狀： RAM 突然爆（27/32GB + swap）、VRAM 顯示 0GB、decode 由 31 跌到 14 t/s
根因： AMD GPU 冇插 monitor，runtime PM auto → idle 6 秒就 suspend → VRAM 內容搬去 system RAM
解決：
# 立即修復
echo on > /sys/class/drm/card0/device/power/control
# 持久化（systemd unit）
sudo nano /etc/systemd/system/gpu-pm-fix.service
️ 先睇速度先好落結論： ReBAR 開咗之後 driver 會將部分 allocation 放 GTT，單憑 mem_info_vram_used 細 唔可以判斷 model 搬咗 RAM。正確判準：① 實測 decode t/s 有冇跌 ② runtime_status 係咪 suspended ③ host RAM 有冇爆。
坑 4：cache-ram 唔夠 / RAM 爆
症狀： log 出現 making room for prompt cache entry；system RAM 長期 86%
影響： 長對話每輪都要重新 prefill，體感慢
解決： --cache-ram（食 system RAM，唔係 VRAM）
[9/7 更新] 根因補充： making room 本身只係 cache pool 輪替（唔係 OOM），但 RAM 真係爆嘅元兇係 --cache-idle-slots 預設開 —— 每個 slot 嘅 KV state 都 copy 落 system RAM。一定要加 --no-cache-idle-slots，RSS 即刻由 21GB 返到 2-3GB，cache hit 唔受影響（詳見 9/7 更新第 4 節）
坑 5：pkill -f 殺錯
症狀： SSH session 斷線、server 冇起到
根因： pkill -f llama-server 會連自己條 SSH command line 一齊殺
解決： 用 pkill -x llama-server（exact process name match）
我嘅建議
- 唔好直接買新卡 —— 先睇下有冇現成 GPU 可以跑
- 48GB 係甜點 —— 24GB 唔夠（131K ctx 會爆），96GB 太貴
- [9/7 更新] Ubuntu + ROCm 7.2.4 係最穩 —— 原文寫「ROCm 支援未完善」係舊版經驗；A/B 實測 ROCm prefill 快 38%、MTP n=8 做到 65.1 t/s（Vulkan n=8 跌到 33.7），而家生產已轉 ROCm，Vulkan 留返做備份
- 一定開 Resizable BAR —— 呢個係 80% 嘅速度
- cache-ram 唔好慳 —— 長對話體感差異好大；[9/7 更新] 同時一定要加
--no-cache-idle-slots，不然 system RAM 會食到 86%（見文末） - headless 機一定要做 GPU PM fix —— 否則會中 runtime suspend 嘅坑
- [9/7 新增] 結論唔好照搬，自己機實測 —— 7900 XTX 嘅 KV 量化結論喺 W7800 完全相反；SGLang 官方「支援 Radeon」但實測用唔到
9/7 更新：兩日實戰回饋（09-05 09:36 → 09-07 11:00，HKT）
發文之後我冇停手。我裝咗一個小小「數據記錄員」（每 2 秒睇一次 server log，自動記低每個請求嘅速度、tokens、MTP 接受率），又加咗一個溫度監察（每 30 秒讀一次 GPU 溫度、風扇、功率）。48 小時不停跑完，一共 1,916 個請求、約 8,540 萬 tokens 輸出，我將所有舊結論重新實測過。以下係結果。
1. ROCm 原來快過 Vulkan（推翻原文結論）
我原本跟住社區主流「Vulkan 單卡全面贏」，對 ROCm 有少少懷疑。9/4 夜至 9/5 朝做咗完整 A/B（同一 commit、同一模型、同一參數，只換 backend）：
| 測試 | Vulkan | ROCm 7.2.4 |
|---|---|---|
| Prefill 512 tokens | 503 t/s | 693 t/s（+38%） |
| Prefill 4096 tokens | 482 t/s | 668 t/s（+39%） |
| Decode 128 tokens（無 MTP） | 30.6 t/s | 30.7 t/s（平手） |
| MTP n=8 工具調用 | 33.7 t/s（大跌） | 65.1 t/s |
| MTP n=2 工具調用 | 54.3 t/s | 50.2 t/s |
結論：W7800（gfx1100）+ 新版 llama.cpp + ROCm 7.2.4，prefill 快 38%、decode 平手、MTP 長 draft 快兩倍。 「ROCm 支援未完善」係舊版本嘅經驗，在此更正。而家生產已轉 ROCm，Vulkan 留返做備份。
2. KV cache：全精度 f16 最快（同 7900 XTX 相反）
7900 XTX 篇文（topic 1164）實測 KV 量化幾乎唔慢。W7800 實測完全相反（ROCm、n=2、工具調用負載）：
| KV 精度 | 速度 | VRAM 慳 |
|---|---|---|
| f16 | 50.9 t/s | 基準 |
| q8_0 | 49.3 t/s（-3%） | 4.2 GB |
| q4_0 | 48.1 t/s（-5.5%） | 6.7 GB |
| q5_0/q4_1 | 38.7 t/s（-24%！） | 7 GB |
精度越高越快、線性下跌，q5_0 更暴跌 24%。所以原文嘅 q8_0 已改 f16 —— 呢個係「唔好照搬結論、要自己機實測」嘅第二個例證。
3. 質素升級：Q8 唔係一定好（頻寬係王）
我做咗三級質素梯級測試（同 45K ctx、128 tokens、每級 20 次）：
| 量化 | 檔案大小 | 速度 | VRAM |
|---|---|---|---|
| Q4_K_M | 15.3 GiB | 38 t/s | 25.5 GiB |
| Q6_K | 22.0 GiB | 36 t/s | 39.3 GiB（2 slot） |
| Q8_K_XL | 31.5 GiB | 34 t/s | 41.1 GiB |
每升一級質素，速度跌 ~5% —— 因為 decode 係頻寬競爭，檔案越大每 step 要讀越多資料。最終生產我揀 Q6_K + 2 個平行 slot（各 128K）：質素同 Q8 相差唔遠，但同時可以應付兩個對話，單流 ~36 t/s、雙流同時各 ~24-25 t/s。如果你得一個人用，Q8 單 slot（34 t/s）都係好選擇。
4. RAM 86% 謎團揭開：--no-cache-idle-slots
原文講「cache-ram 唔好慳」，但冇寫我踩咗一個坑：30GB RAM 長期食到 86%。9/6 查到元兇：llama.cpp 嘅 --cache-idle-slots 預設係開，每個 slot 嘅 KV state 都會被 copy 落 system RAM，成個 cache pool 食滿 21GB RSS、仲行 swap。加咗 --no-cache-idle-slots 之後 RSS 穩定返 2-3GB，cache hit 完全唔受影響。如果你用 cache-ram，一定同時加呢個 flag。
5. SGLang 實測：「列咗名但未 ready」
9/5 我亦試咗 SGLang（AMD 官方話支援 Radeon）。結果：
- 官方 FP8 量化：server 起得到，但 decode 只有 0.62 t/s（比 llama.cpp 慢 ~100 倍）—— RDNA3 冇原生 FP8 core，要模擬，GPU 100% busy 都係每 token 1.6 秒
- 三條 INT4 路線：全部失敗（loader 唔認 / SSM kernel dtype bug）
- 最新 python-native 版本：起得到、tool call 全部正確，但 decode 只有 4.9 t/s
- 對照組 Qwen3-8B dense：30.2 t/s 完全正常 —— 證明問題唔係 SGLang 本身，係 27B hybrid 架構 + FP8/INT4 支援不足
查咗 AMD 官方 Day-0 文章，支援對象係 Instinct 數據中心卡（MI300X 等），Radeon 只係「列咗名」。W7800 繼續用 llama.cpp ROCm；想 AMD 行 SGLang，正路係 Instinct。
6. 兩日實戰數據（09-05 09:36 → 09-07 11:00）
| 指標 | 值 |
|---|---|
| 總請求 | 1,916 |
| 總輸出 | ~8,540 萬 tokens |
| Decode 速度 | 中位 33.3 t/s（p10 22.6 / p90 54.3 / max 120） |
| MTP 接受率 | 中位 0.70（純工具調用可上 0.91） |
| 最長單次輸出 | 77,000 tokens（9/7 10:45，連生成 5,652 tokens、27.9 t/s 無跌速） |
| 崩潰 / 致命錯誤 | 0 |
| 溫度 | 高峰 junction 101°C（全係 busy 時段）、風扇 max 2,571 rpm、功率 max 230W |
| Prompt cache 重用 | 91% 請求命中 cache（f_sim > 0.9），長對話幾乎唔使重新讀 prompt |
現役配置（9/6 17:15 起）已連續運行 19 個半小時無重啟：VRAM 40/48 GiB、RAM 15/30 GB、GPU busy 時 junction ~93°C。
最終生產配置（9/7 版）：
exec ~/llama.cpp-rocm/build-rocm/bin/llama-server \
-m ~/models/Qwen3.8-27B-UD-Q6_K.gguf \
--mmproj ~/models/mmproj-F16.gguf --image-min-tokens 1024 \
--alias qwen3.8-27b --device ROCm0 --fit off -ngl -1 --no-mmap \
--spec-type draft-mtp --spec-draft-n-max 2 \
-c 262144 -ub 512 \
--cache-type-k f16 --cache-type-v f16 \
--parallel 2 --cache-ram 15360 --no-cache-idle-slots \
--flash-attn on -t 12 -tb 6 \
--host 0.0.0.0 --port 8080 --jinja --reasoning off
（2 個 slot 各 128K、f16 KV、MTP n=2、cache pool 15G、--no-cache-idle-slots 防止 RAM 爆；systemd 自動重啟）
7. 呢兩日學到嘅嘢
- 結論唔好照搬 —— KV 量化嘅結果 7900 XTX 同 W7800 完全相反；我信咗「Vulkan 全面贏」都係喺自己機上推翻
- 先實測先結論 —— SGLang 紙面「支援」，實測用唔到；ROCm 紙面「未完善」，實測快 38%
- 要記錄數據 —— 冇呢兩日嘅記錄，我唔知自己跑咗幾多、101°C 高峰係咪常態
- 頻寬係王 —— 27B decode 係純頻寬競爭，質素同速度係一條 spectrum，搵自己嘅平衡點
最後
祝你好運。