技术落地设计 · 在 EVO-X2 128GB 硬件上确保"真正好用" · v1.0
本地模型好用落地设计
核心问题：35B MoE 与 27B 稠密特调"用哪个加载哪个"，如何确保客户真正用起来、能替代多少 API 能力。答案：EVO-X2 的内存预算足够同时驻留主力模型，按任务路由即可；销售型生产企业 80–90% 的数据服务场景本地可替代。
平台：EVO-X2 128GB（96GB 可分 GPU / 256GB/s）
策略：多模型同时驻留 + 按任务路由
替代率：本地覆盖 80–90%，云端只兜底 10–20%
1内存预算：多模型同时驻留可行
EVO-X2 128GB 统一内存、可分配 96GB 给 GPU——这决定了你不用"加载一个卸一个"，主力模型可以常驻，切换近乎无感。Ollama 原生支持多模型常驻（keep_alive）。
| 模型 | 量化 | 占用 | 用途 | 驻留策略 |
|---|
| Qwen3.6-35B-A3B（MoE，激活 3B） | Q5_K_M | ≈25GB | 通用分析：周报/归因/问答/深度分析（主力） | 常驻（keep_alive=-1） |
| Qwen 27B 稠密（特调版） | Q4_K_M | ≈20GB | 特调业务场景：固定格式输出、行业术语（备用主力） | 按需加载（业务批处理时） |
| Qwen3-14B | Q5_K_M | ≈10GB | 规则任务：查数、工具调用、格式提取（快） | 常驻 |
| bge-m3（嵌入） | fp16 | ≈2GB | RAG 向量化 | 常驻 |
| KV cache（32K 上下文 × 常驻模型） | — | ≈8–12GB | 长上下文缓存 | — |
✅ 合计常驻约 45–49GB（35B MoE + 14B + 嵌入 + KV），加 27B 特调也仅约 65–69GB —— 远小于 96GB 可用额度，还剩 30GB 余量。结论：不用做"加载卸载"的取舍，四个模型可以同时住在内存里，Agent 按任务路由即可。
2"用哪个加载哪个"：模型路由规则
MoE 和稠密特调不是二选一，是分工。默认 MoE 干活，特调只在特定场景顶上。
| 任务类型 | 用哪个 | 为什么 |
|---|
| 经营分析 / 周报 / 归因 / 深度问答 | 35B MoE（常驻） | 通用推理强、速度快（25–35 Token/s），覆盖 80% 场景 |
| 固定格式输出（特定报表/单据） | 27B 稠密特调（按需） | 微调后输出格式绝对稳定、术语准确——但只在真的需要时才上 |
| 查数 / 工具调用 / 简短提取 | 14B（常驻） | 快、省，杀鸡不用牛刀 |
| 文档检索问答（RAG） | bge-m3 检索 + 14B/35B 生成 | 检索质量决定效果，模型只是最后一步 |
| 超长文本 / 极难推理 / 新知识 | 云端 API（兜底） | 占比 10–20%，可脱敏后走云端 |
切换实操（Ollama）
- 常驻：
ollama run qwen35b --keepalive -1（-1 = 永不卸载）
- 按需：27B 特调只在批处理任务前
ollama run qwen27b，处理完自动让出内存
- Agent 路由：Hermes Agent 注册"任务分类→模型名"映射，查数走 14B、分析走 35B、特调格式走 27B
- 不用人肉切换：Ollama 内存不够时会自动驱逐冷模型，配置好 keepalive 就不用管
3确保"真正好用"的 8 项配置
- 量化别省内存，用 Q5_K_M 起（内存不是瓶颈）：Q4→Q5 质量提升明显，256GB/s 带宽下速度损失可接受；Q8 对 30B 级没必要
- 上下文设 32K：128GB 内存完全扛得住，RAG 检索片段+历史对话放得下
- KV cache 量化开启：再省 20–30% 缓存内存，速度影响小
- 系统提示词写死业务上下文：公司背景+数据口径+输出格式（周报模板）全部写进 system prompt，效果翻倍
- 温度设置：分析/周报类 0.3–0.5（稳定），创意类 0.8+
- 工具调用用 Qwen 原生 function calling：配 Hermes Agent，查库/发消息都走结构化调用，比让模型自由发挥稳得多
- RAG 分块 500–1000 字+保留标题：检索 top-k 先 5–10，人工抽查 10 条检索结果再上模型
- POC 定基线：先用云端 API 在客户数据上跑出效果样例作为"及格线"，本地模型复现达到 90% 即算过——效果好差有基准，不凭感觉
4本地模型替代 API 能力清单（最重要）
销售型生产企业典型的数据服务场景，逐项标注本地能否替代：本地可替代部分替代仍需云端
| 能力场景 | 判定 | 说明 |
|---|
| 经营数据问答（自然语言查数+解释） | 替代 | 35B MoE 查库+解释完全够用 |
| 周报/月报生成（模板化） | 替代 | 模板+填空式，本地主力场景 |
| 异常归因分析（销量暴跌原因） | 替代 | 关联数据+规则推理，35B 级足够 |
| 库存/断码预警生成 | 替代 | 规则触发+文案生成，14B 就够 |
| RAG 文档问答（手册/合同/台账） | 替代 | 检索质量决定效果，模型是最后一步 |
| 非结构化数据提取（订单/单据→表） | 替代 | 结构化提取是 30B 级强项 |
| 长文摘要 / 简报解读 | 替代 | 30B 级摘要质量够用 |
| 简单脚本/公式生成（数据分析小工具） | 部分 | 简单脚本行；复杂代码仍建议云端 |
| 营销文案/创意写作 | 部分 | 初稿行，精品文案差口气 |
| 多模态（看图/听语音） | 云端 | 本地方案不含视觉模型；业务需要时单独接 API |
| 超长上下文（>32K 多文档分析） | 云端 | 超出本地上下文时兜底 |
| 最新知识（模型知识截止后的事） | 云端 | 本地模型知识有时效，实时信息走 API |
| 极难推理（复杂数学/长链推理） | 云端 | 占比极小，可脱敏后走云端 |
🎯 结论：销售型生产企业的数据服务，本地替代率 80–90%。真正必须走云端的（多模态/超长/最新知识/极难推理）业务占比小、且多为可脱敏内容——云端月预算 200 内是够的。
527B 稠密特调策略（别重蹈 7B 覆辙）
- 前期（0–3 个月）默认不微调：35B MoE + 提示词 + RAG 覆盖 90% 场景——微调只在"格式/术语必须绝对稳定"时才有价值
- 什么时候才值得特调：客户跑通 3 个月后，积累了足够的真实问答/报表数据（500–2000 条），且格式要求确实稳不下来——再考虑 QLoRA
- 特调用 27B 稠密、不用 30B MoE：dense 微调后特定任务输出更稳；用 QLoRA（4bit 基础）在 EVO-X2 上也能训，样本量小（数百条）即可
- 特调验收：拿 30 条客户真实场景测试，对比"特调前/后"的输出稳定性与准确率，达标才切换路由
- 特调是增值服务，不是标配：可以作为阶段三之后的"加项"向客户报价（如 5,000–10,000 一次特调服务），而不是白送
6效果保障流程（客户感知"好用"）
- POC 定基线：客户数据（脱敏）→ 云端 API 生成周报/预警样例 → 老板认可效果
- 本地复现：35B MoE 在本地跑同一任务，达到样例 90% 效果即通过（有基准，不凭感觉）
- 分步放量：先上线"规则明确"任务（预警/查数/周报模板）→ 稳定 2–3 周 → 再开放归因/深度分析
- 效果监控：每周抽查 5 条输出，记录"达标/偏差"，连续不达标就调（提示词→RAG→换模型→最后才微调）
- 兜底开关：Agent 设"置信度低→自动转云端 API"的开关，本地不行就静默切云端，客户无感