邪修提速：本地qwen3.8+hermes agent
-
Hermes 把上下文压缩和技能维护全切给云 API，本地 GPU 只干主推理（低成本提速思路）
背景：本地 2×2080Ti 跑 Qwen3.8-27B-FP8（vLLM），当 Hermes 的主模型。用久了发现两个后台任务会跟对话抢算力，导致排队卡顿：①长对话到 ~92K 触发上下文压缩时，摘要要在本地模型上跑约 2 分钟，期间对话全卡；②Hermes 会后台自动创建/修改 skills（curator 技能维护 + 后台审查），同样占本地 GPU。
方案：Hermes 的 auxiliary 配置支持每个辅助任务独立路由模型，全部切到便宜的云 API：
auxiliary:
compression: # 上下文压缩（摘要）
provider: xiaomi
model: mimo-v2.5
curator: # skills 自动维护
provider: deepseek
background_review: # 后台审查 fork
provider: deepseek
model: deepseek-v4-flash
skills:
write_approval: true # skill 落盘需我确认，防静默创建
creation_nudge_interval: 0 # 关掉创建提醒效果：
一、本地 GPU 现在只服务主模型对话，辅助任务零占用，压缩触发时对话不再卡 2 分钟。
二、成本极低：MiMo V2.5 上下文 1M，一次压缩约 ¥0.1；DeepSeek 维护任务也就几分钱一次。日均 API 开销几毛钱左右。
三、改配置不用重启 gateway（配置缓存按文件 mtime 失效），随时可回滚（provider 改回 auto 即可）。一点体会：本地显卡算力是稀缺资源，把非关键路径（摘要、维护类任务）外包给廉价云 API，是比换卡更省钱的提速手段。适合"本地推理 + 云辅助"混合架构的朋友。上下文压缩不太吃智商所以个人选择了mimo v2.5，skills稍微复杂点用了DeepSeek。
话外：mimo v2.5真的蠢好在有点便宜。DeepSeek毋庸置疑，但是个人体验本地qwen3.8 27b fb8 kv16在hermes agent代理下不输DeepSeek，甚至要比DeepSeek思考的全面，思考开的high，速度在35-70tok/s，体感很丝滑
-
數據泄露風險確實要分層看，關鍵是「主模型在哪、各 aux 任務送什麼出去」：
一、先分清暴露面
- compression（上下文壓縮）：暴露面最大——它把整個對話濃縮成摘要送給雲 API，等於會話內容全文出境
- curator（技能維護）：送的是技能文件內容（提示詞/規則）
- background_review：送的是待審查的代碼/上下文片段
二、主模型位置決定基線
rock shi 的方案裡主模型是本地（2×2080Ti vLLM），所以 aux 上雲確實引入了「本地內容出境」。如果主模型本來就走雲 API（例如 DeepSeek），aux 也走同一家，數據控制者沒變，新增暴露面最小。三、緩解手段（按敏感度排序）
- 同 provider 聚合：aux 和主模型用同一家雲，避免多一個數據控制者
- 壓縮留本地：compression 最敏感，Hermes 的 auxiliary 配置支持每個任務獨立路由，可以單獨把它指回本地模型（例如本地 llama.cpp 的 endpoint），用「壓縮時卡 2 分鐘」換「內容不出境」
- 技能文件脫敏：curator 上雲前檢查技能裡有沒有機密
- 最敏感的業務：整條鏈路都別上雲
四、一個容易混淆的點
他配置裡的 write_approval: true 擋的是「技能被靜默創建/修改」，擋不住內容出境——兩碼事。真正決定風險的是「哪些內容送到誰手上」，不是「誰能改技能文件」。
