================================================================================
【詳細教程】本地 27B 主推理 + MiMo 壓縮外判：一套省 token、唔卡機、無人看守的
Hermes + llama.cpp 系統（RTX 3080 20GB 實戰複製指南）

首先感謝上面3090 mimo壓縮的想法,然後融合了大家的設定,下面若果大家有什麼意見歡迎提供給我參考

作者實機：Intel Xeon E5-2696 v4（22C/44T）＋ NVIDIA RTX 3080 20GB ＋ 121GB RAM ＋ Ubuntu
本文所有數字都係實測（bench.py 固定 prompt），唔靠口講。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
0. 呢個系統解決咩問題
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
跑本地大模型做 Agent 有兩個痛點：

1. 長對話觸發「上下文壓縮」時，本地 GPU 要埋頭做摘要 → 對話卡 1–2 分鐘，甚至卡死控制流
2. 主推理放雲端 → token 燒得飛快

解決方案：主推理全本地（0 外部 token），只有「壓縮」外判去 Xiaomi MiMo 最平嘅模型
（mimo-v2.5，Token Plan），配合自己 A/B 實測嘅提速參數。全套仲加咗：Harness 守門
（防自問自答）、2H 互救（自動止血）、watchdog（無人看守）。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 系統架構總覽
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   ┌─────────────────────────────────────────────┐
   │ Hermes Agent（gateway，Telegram） │
   │ 主推理 → 本地 llama.cpp（127.0.0.1:8081） │
   │ 壓縮 → MiMo token-plan-sgp（mimo-v2.5） │
   ├─────────────────────────────────────────────┤
   │ DoubleH Harness（127.0.0.1:17171） │
   │ build_context（規劃）＋ record_result（存證）│
   │ harness-gate 15（硬門檻，防幻覺） │
   ├─────────────────────────────────────────────┤
   │ guardian watchdog + failover + 2h-rescue │
   │ （服務死咗自動 restart，有 cooldown） │
   └─────────────────────────────────────────────┘

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. 硬件／軟件清單
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
硬件：Xeon E5-2696 v4（22C/44T）｜RTX 3080 20GB｜121GB RAM｜Ubuntu（Driver 595.84）
軟件：

• llama.cpp：自編 master（commit cb30059，CUDA 12.4）
• 模型：Qwen3.8-27B-Uncensored-Q4_K_M.gguf（27.3B，Q4_K_M 約 16.8GB，GGUF 內置 MTP nextn head）
• Hermes Agent（doubleh fork）
• Xiaomi MiMo Token Plan（mimo-v2.5，token-plan-sgp 節點）
• systemd user services（llama-qwen38 / hermes-gateway）+ guardian watchdog + 2h-rescue.timer

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. Step 1：模型 + llama.cpp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 下載 Qwen3.8-27B 嘅 GGUF（Q4_K_M 類；留意模型檔要帶 MTP tensors：可以
   strings 模型.gguf | grep nextn 確認有 blk.*.nextn.* 先有 MTP 加速）
2. 編譯 llama.cpp（CUDA）：

   冇系統 cmake 都冇問題——用 pip 裝到自家 venv，唔使 sudo

   python3 -m venv ~/llama_autotune/buildenv
   ~/llama_autotune/buildenv/bin/pip install cmake
   cd ~/llama.cpp && git pull
   ~/llama_autotune/buildenv/bin/cmake -B build -DLLAMA_CUDA=ON -DCMAKE_BUILD_TYPE=Release
   ~/llama_autotune/buildenv/bin/cmake --build build --target llama-server -j 44
3. 確認旗標存在先好加：llama-server --help | grep -E "spec-type|kv-offload|reasoning-effort"
   —— 版本冇嘅旗標唔好硬加（會 NOT READY）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. Step 2：高速啟動參數（實測重點，一個一個講）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
llama-server 啟動參數（Hermes 主模型，ctx 必須 ≥64K）：
--ctx-size 65532 --flash-attn on --kv-offload
--threads 24 --threads-batch 40 --batch-size 4096 --ubatch-size 256
--spec-type draft-mtp --spec-draft-n-max 2
--reasoning-budget 4096 --reasoning-effort low --reasoning-preserve
--cache-type-k q4_0 --cache-type-v q4_0 --parallel 1 --n-gpu-layers 99

每個旗標嘅實測效果：

• ★ --kv-offload：KV cache 放 RAM。短/中 context 解碼快 2.5–3.5 倍（7.8 → ~40 tok/s）。
  長 context（4K tokens）仍有 24.5 t/s。呢個係全個調校最大嘅單一發現。
• ★ --spec-type draft-mtp --spec-draft-n-max 2：用模型內置 MTP head 做投機解碼
  （+33%~145%）。實測 draft acceptance 72%。n-max 2 喺 20GB 卡係 sweet spot
  （n-max 1 得 12.18 t/s，n-max 2 有 12.50 t/s；44 threads 會暴跌 75%！）
• --reasoning-budget 4096：cap thinking token，防止空思考吞晒速度。
• --reasoning-effort low：thinking 深度鎖 low。實測 thinking tokens 減 21%–75%，
  質素冇跌（簡單推理題照答啱）。
• --threads 24 / --threads-batch 40：Xeon 22C 實測 sweet spot。
  陷阱：threads-batch 44（含 hyperthreading）會暴跌到 3 t/s（-75%）！
• --batch-size 4096 / --ubatch-size 256：prefill 效率。
• --cache-type-k/v q4_0：KV 量化要 K/V 對稱！混搭（K q8 / V q4）會令 flash
  attention 靜默回退、速度斷崖但唔報錯。
• ctx 65532：Hermes 主模型硬要求 ≥64K（agent_init.py MINIMUM_CONTEXT_LENGTH），
  設 8K 會令 gateway 起唔到。

提速流程（唔靠網上抄參數）：

1. 固定 bench：~/llama_autotune/bench.py --mode low / --mode e2e（同一個 prompt）
2. 一次只改一個參數，每次 backup unit + restart + READY + bench
3. 退化 ≥15% 或 NOT READY → 自動回退（autotune 腳本做 KEEP/REVERT）
4. 長上下文 smoke test（至少 4K tokens）——避免「只短 prompt 快」
5. 測速前閂 Chrome/Firefox：桌面 compositor + 瀏覽器會偷 GPU 頻寬，
   decode 靜默減半（38 t/s → 9 t/s），唔好誤判係參數問題

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4.5 性能提升總結（系統有幾勁——全部實測數字）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【tok/s 進化旅程】（同一 bench.py 固定 prompt）
階段 短輸出 tok/s 備註
─────────────────────────────────────────────────────────────
最初（舊 bundle、未調參） 7.77 長輸出測試

• MTP（draft-mtp n-max 2） 12.50 舊 bundle
• 新 binary（cb30059）+ --kv-offload ~38–46 大躍進
• --reasoning-effort low 36–40 thinking 減 21–75%
  ─────────────────────────────────────────────────────────────
  而家實測（今日，GPU 7% 負載） e2e ~36–39 / low ~34
  4K 長上下文 smoke ~24.5
  → 由頭到尾淨提升 ≈ 5 倍

【MiMo 壓縮威力】
細 context 摘要：~2 秒
158K tokens 大 context：8.4 秒（超真實 109K session 需求）
vs 以前本地 GPU 做壓縮：卡 60–120 秒 → 而家秒級完成，對話唔再卡

【成個系統有幾勁（一句總結）】
主推理 0 外部 token（全本地）＋ 壓縮秒級外判 MiMo ＋ 64K 長對話自動維持
＋ 無人看守（watchdog + 2H 互救 + gate 守門防幻覺）＝ 每日可以唔使理佢，
淨係喺 Telegram 用，token 幾乎淨係 MiMo 壓縮嗰啲小額。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. Step 3：MiMo Token Plan 設定
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 買 Token Plan（最細檔就夠），攞到 tp- 開頭 key 同區域節點 URL。
   注意：key 係區域綁定！實測 cn/ams 節點 401，只有 sgp 節點 200。
2. Key 只放本機 env 檔，嚴禁貼 chat / config / log：
   /etc/hermes_secrets/mimo_tokenplan.env（chmod 600）：
   MIMO_API_KEY=tp-xxxxx
   MIMO_BASE_URL=https://token-plan-sgp.xiaomimimo.com/v1
   MIMO_MODEL=mimo-v2.5
3. Hermes config.yaml 接線（config 唔寫 key 明文）：
   auxiliary:
   compression:
   provider: custom
   base_url: https://token-plan-sgp.xiaomimimo.com/v1
   model: mimo-v2.5
   api_key_env: MIMO_API_KEY
   （如果你 Hermes 版本有原生 xiaomi provider，用 provider: xiaomi 都得；
   key 會由 XIAOMI_API_KEY env 讀。以 agent.log 實際輸出為準，唔好靠估）
4. 驗證「真係用緊 MiMo」（唔係「key 檔存在」就算）：
   grep "Auxiliary compression: using" ~/.hermes/logs/agent.log

   應該見到：using custom (mimo-v2.5) at https://token-plan-sgp...

   壓縮成功會見到：commit_status=committed

   真證據喺 agent.log，唔喺 journald；/proc/<pid>/environ 都唔可靠
   （gateway 係 per-turn 載入 .env）
5. 大 session 陷阱：aux call 實測要 33–40s（大 session 更耐）＞ 預設 hygiene
   timeout 30s → 會狂 timeout。修法：
   compression:
   hygiene_timeout_seconds: 120

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. Step 4：Hermes 接入
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
config.yaml：
model:
provider: custom
base_url: http://127.0.0.1:8081/v1
api_key: anything # 本地 endpoint 唔驗證
context_length: 65532
real_context_length: 65532
改完：systemctl --user restart hermes-gateway.service

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
7. Step 5：無人看守（watchdog + 2H 互救）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

• guardian watchdog：監察 llama-qwen38@8081 + hermes-gateway，down 自動 restart
  ＋ failover（local 雲端緊急互切，healthy 5 次自動回滾）
• 2h-rescue.timer（每分鐘）：llama / gateway / Harness 邊個死 restart 邊個，
  帶 lock + cooldown（10 分鐘上限 2 次）防重啟風暴
• Harness 守門：任何多步/高風險操作前 harness-gate 15（FAIL 即停）；
  做完 record_result 存證（做咗乜、證據、回退點）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
8. 驗收清單（全部命令）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
curl -s http://127.0.0.1:8081/v1/models # 本地模型 list
python3 ~/llama_autotune/bench.py --mode low # 短輸出 tok/s
python3 ~/llama_autotune/bench.py --mode e2e # 端到端 tok/s
grep "Auxiliary compression: using" ~/.hermes/logs/agent.log # MiMo 路由證據
grep commit_status ~/.hermes/logs/agent.log | tail # 壓縮成功=committed
systemctl --user is-active 2h-rescue.timer # 互救 timer
harness-gate 15 # 守門（有 planning 證據先 PASS）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
9. 踩過嘅坑（時間線）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 舊 session 205K tokens 撞爆本地 64K → HTTP 400「exceeds context size」→ 長對話
   一定要靠壓縮（或開新 session）維持喺 64K 內
2. threads-batch 44（HT）→ 3 t/s（-75%）
3. KV 混搭 K q8 / V q4 → flash attention 靜默回退
4. 桌面 Chrome/Firefox → GPU 94% → decode 減半（測速前要閂）
5. MiMo key 區域綁定（sgp 先得）；key 貼 chat 過＝洩漏風險
6. hygiene timeout 30s 唔夠大 session 嘅 aux call（33–40s）
7. pkill -f 打到自己個 shell（pattern 匹配到自己）→ 用 pgrep -x 精確名

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10. 風險／回退
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

• MTP 屬實驗功能：異常時刪走 --spec-type draft-mtp --spec-draft-n-max 2 → 回退
• --kv-offload 食少 VRAM 但 64K 全滿 decode 未測極限；同 ComfyUI 唔好同時開
• effort low 係全局：複雜推理任務質素有機會跌，覺得變蠢就刪 flag 或改 medium
• 每個改動都有 backup（~/.config/systemd/user/backup_llama_qwen38/）＋ revert 命令

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
11. 致謝／參考連結
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
特別感謝以下文章同項目（參數同思路大多源自佢哋）：

• sudoingX/qwen38-mtp（MTP 旗標發現同實測）: https://github.com/sudoingX/qwen38-mtp
• Habr 實戰「Qwen3.6-27B 推到 73 tok/s」: https://habr.com/en/articles/1042716/
• unsloth Qwen3.6-27B MTP GGUF 討論: https://huggingface.co/unsloth/Qwen3.6-27B-MTP-GGUF/discussions/6
• lcz.me「RTX 3080 20G + llama.cpp + Hermes 實戰心得」: https://lcz.me/topic/1020/
• MiMo Token Plan 官方文檔: https://mimo.mi.com/docs/zh-CN/tokenplan/Token Plan/quick-access
• llama.cpp 官方: https://github.com/ggerganov/llama.cpp

有問題歡迎交流；參數請以自己機器的 bench 為準——硬件唔同結果會差好多。

大家好，我想請教 AMD 多卡在 Ubuntu 上跑 ComfyUI / MINI MAX H3大型視聽模型的實戰建議。

現有平台（不換主機板/不換整機）

• 主機板：X99（兩條 PCIe 3.0 x16）
• CPU：E5-2696 v4
• RAM：128GB DDR4
• 電源：1600W
• 系統：Ubuntu
• 現用 GPU：RTX 3080 20GB（ComfyUI 可跑，但想為未來大型模型升級）

購買計劃

• 目標：2× AMD Radeon AI PRO R9700 32GB

使用場景

• ComfyUI（本地）
• MiniMax H3（特別關心 Ref2VA / R2V，有音訊+視頻聯合生成）
• 希望穩定、盡量避免 OOM 卡死（我知道 DDR4RAM 不能當 VRAM 保底）

想請教幾個具體問題（希望有實測/經驗分享）

1. 在 Ubuntu 上，2× R9700 32GB 跑 ComfyUI（含 H3/R2V）是否整體穩定？ROCm 生態會唔會經常缺加速庫／插件不兼容？
2. 多卡方面：在 PCIe 3.0 x16 + x16（無 NVLink）下，實際可行的多卡策略係咩？
   • 係「一個模型做分割（TP/並行）」可行？
   • 定係只建議「兩張卡各自跑不同任務/服務」？
     -MINIMAX H3 24B 這麼大如何平均分割到兩張顯示卡？
     -deep Seek建議我用sg lg組成一個陣列兩張32gb的造成一個虛擬的樸然後自己分割兩邊任務其實是不是他在幻想？
3. 對 MiniMax H3（Ref2VA）呢類大模型：

• 2×32GB 是否夠用做 768p/720p 短片段（例如 5–10 秒）？
• 128GB RAM 會唔會成為硬瓶頸？

如果有：

• 你哋用 AMD/ROCm 跑 ComfyUI 或 H3 的版本組合（Ubuntu/ROCm/torch）
• 穩定性/性能實測（VRAM 峰值、RAM 佔用、OOM 情況）
  我都非常感謝！

上面用ai寫的所以有點談技術參考,全程都是用deepseek +Trai.我用的是
技加小雕rtx 3070我改16gb'已經在家中試了兩個星期本地部署但是連最基本系統運行都出錯。顯示卡去到改裝店面燒甜甜圈半個小時也沒有出事，但是一插3070基本上三分鐘內直接黑屏沒有顯示，hermes用deep seed api所以你而沒有問題，可以正常通話
結論就是這張卡只能在windows環境下面使用因為缺少nv控制面板,所有驅動cuda補丁都叫hermes打好仍然不行,如果要在unbuntu 做本地部署的兄弟要避雷3070

我这台机器平台是华南金牌 X99 F8，长期用途是本地 AI 推理 + 日常桌面操作。电源是 1600W，显卡供电使用两条独立 PCIe 线，供电与线材层面我可以确定没有偷懒。之前我一直用一张 RTX 3080（20GB 改卡）在 Ubuntu 下跑模型、开浏览器、做长任务都能稳定两天不掉线，所以我原本以为换上 RTX 3070 也应该只是“装好驱动就行”。

这张 RTX 3070 是 16GB 软改卡（店铺 Windows 下甜甜圈烤机 30 分钟没问题，Windows 日常也正常）。但在 Ubuntu 上作为桌面显示卡使用时，问题非常明确：系统能启动、主板 Debug 码常见显示 AA（表示已过 POST），但进入桌面后只要做一点“真实图形负载”的动作（例如打开 Chrome、拖动窗口、甚至某些情况下打开文件管理器），就会出现黑屏，随后 Xorg 进入半死/僵死状态，必须重启才能恢复。

软件环境方面：我明确切到了 Xorg（不是 Wayland），NVIDIA 驱动版本为 595.84。最初还观察到 nvidia-settings 出现黑屏/界面极简，后来核实原因是 userspace 版本不匹配：nvidia-settings 510.47 对应 driver 595.84，这能解释“控制面板不好用”，但无法解释“整套图形栈挂死”。真正关键的证据来自内核日志与 nvidia-smi：黑屏复发时会出现 NVRM: Xid 相关错误（典型包括 Xid 8/16/158/154 等组合），并且 nvidia-smi 会从“正常返回”变成 timeout，甚至输出 System is not in ready state；同时 Xorg 进程可能卡入 Dl+，/tmp 下的 X socket 异常，导致 xset/xrandr/nvidia-settings 都无法再连接显示。换句话说，这不是“某个应用崩了”，而是 GPU 显示引擎/驱动栈级别的 hang。

为了避免“没人操作就误判稳定”，我这次排查采用了严格流程：每次 reboot 后先做 baseline（确认 P8 idle 正常、无 Xid），然后再做对照测试：Files、Chrome（禁用 GPU 加速）、Chrome（正常 GPU 加速），并且同时开三个 watcher 持续记录 nvidia-smi 状态与 journalctl -k。曾经出现过一次“轻负载 10–15 分钟看似稳定”的假象，但关键转折点在于：只要上真正持续渲染压力（例如 glxgears 持续 OpenGL 渲染 60fps），大约 3 分钟内就必定触发 hang，Xid 连发，随后 nvidia-smi 也会挂死。这说明问题并非“网页/文件管理器特例”，而是只要进入持续的桌面显示渲染链路，就会触发。

我也尝试过一些常见“软件止血”方案：停用 nvidia-powerd（日志里曾提示 unsupported）、关闭 compositor、以及用 nvidia-smi 做功耗墙/锁频（-pl、-lgc）来避免 P8→P0 的跳频触发。确实存在“降低功耗 + 降低频率能延迟复发”的现象，例如 1500MHz 在某些更保守功耗墙下能撑更久，但一旦进入真实桌面渲染压力，仍会复发。最终结论很明确：在 Linux 的桌面显示路径下，这张 3070 软改卡的稳定性无法通过简单锁频/限功耗从根本解决，最多只能“延迟死亡”。另外我还观察到该卡的 power limit 显示过 270W（明显高于常见 3070 的 220W 级别），这与软改/改 BIOS power table 的可能性一致，但是否为唯一根因我不做绝对断言；我只能说它与“显示引擎 hang + 传感器/状态 not ready”这类症状高度吻合。

结论与建议：Windows 下烤机通过，并不等价于 Linux 下桌面显示稳定；尤其是软改卡/改 BIOS 卡，在 Linux 驱动与显示栈组合下更容易暴露问题。若要长期稳定做 AI 和长任务，我建议用 3080 作为主显示与主力计算；3070 如果要保留，最多建议作为 headless compute（不承担桌面显示、尽量不跑 OpenGL/桌面渲染），并且仍需做一次纯 CUDA 计算侧的压力测试，确认不会把整套驱动栈拖死。对我这次案例来说，3070 在 Ubuntu/Xorg 的“桌面显示”用途上已经试到尽头，继续在同一路线耗时间意义不大。