(這是我自己打的, 不是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，希望呢份報告對你有幫助。

硬件配置

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 首日版）：

實測數據

1. Prefill 速度（llama-bench）

解讀：

• 1K-16K 範圍內速度衰減唔多（~12%），日常使用最舒服
• 64K 要 ~200 秒先吐首字

2. Decode 速度

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）：

結論：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）：

結論：

• 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）：

分析：

• 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）

我嘅建議

1. 唔好直接買新卡 —— 先睇下有冇現成 GPU 可以跑
2. 48GB 係甜點 —— 24GB 唔夠（131K ctx 會爆），96GB 太貴
3. [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 留返做備份
4. 一定開 Resizable BAR —— 呢個係 80% 嘅速度
5. cache-ram 唔好慳 —— 長對話體感差異好大；[9/7 更新] 同時一定要加 --no-cache-idle-slots，不然 system RAM 會食到 86%（見文末）
6. headless 機一定要做 GPU PM fix —— 否則會中 runtime suspend 嘅坑
7. [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）：

結論：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、工具調用負載）：

精度越高越快、線性下跌，q5_0 更暴跌 24%。所以原文嘅 q8_0 已改 f16 —— 呢個係「唔好照搬結論、要自己機實測」嘅第二個例證。

3. 質素升級：Q8 唔係一定好（頻寬係王）

我做咗三級質素梯級測試（同 45K ctx、128 tokens、每級 20 次）：

每升一級質素，速度跌 ~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）

現役配置（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. 呢兩日學到嘅嘢

1. 結論唔好照搬 —— KV 量化嘅結果 7900 XTX 同 W7800 完全相反；我信咗「Vulkan 全面贏」都係喺自己機上推翻
2. 先實測先結論 —— SGLang 紙面「支援」，實測用唔到；ROCm 紙面「未完善」，實測快 38%
3. 要記錄數據 —— 冇呢兩日嘅記錄，我唔知自己跑咗幾多、101°C 高峰係咪常態
4. 頻寬係王 —— 27B decode 係純頻寬競爭，質素同速度係一條 spectrum，搵自己嘅平衡點

最後

祝你好運。