首先感謝上面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 為準——硬件唔同結果會差好多。