内部技术底稿 · 与运营基板配套 · v1.0
硬件与部署实现方案：小型服务器 + 本地 NAS
落地你的构想：公司内搭"小型服务器 + 本地 NAS"，部署多模型 + Agent 抓手工具，处理数据相关内部事务；数据不出厂、计算本地化、备份独立、单人可远程维护
计算：小型服务器（EVO-X2 128GB 统一内存为推荐核心）
存储：本地 NAS（RAID + 快照 + 异地备份）
模型：多模型（小 7–14B + 大 30B MoE + 嵌入）
编排：Hermes Agent 抓手工具 + 云端 API 兜底
1架构总览：三层分工
核心原则：数据归 NAS、计算归服务器、触达归手机。数据资产是客户的命根子，必须落在独立存储上；模型和 Agent 在服务器上跑；结果推到你/老板的手机。
存储层本地 NAS（数据资产主存储）
- 清洗后的数据资产包、SQLite 库、文档/手册
- 模型权重库（供服务器挂载加载）
- RAID1/5 + 每日快照 + Tailscale 异地备份
计算层小型服务器（计算核心）
- Ollama 多模型（小模型快处理 + 30B MoE 深分析）
- Hermes Agent + 工具函数（查库/出报告/推送）
- SQLite/Chroma 向量库 + Streamlit 看板
- Ubuntu 24.04，ROCm 驱动，功耗 ~100W
触达层老板端 + 你（运维）
- 老板手机：微信图文周报/预警（免装 APP）
- 老板浏览器：内网看板，随时查数
- 你：Tailscale 远程巡检/更新/扩容（异地维护）
数据流：网店/进销存导出 → NAS 落盘 → 服务器清洗/计算 → 模型/Agent 分析 → 看板/微信推送
备份链：NAS RAID → NAS 每日快照 → Tailscale 异地副本（到你本地）
2硬件选型推荐
"小型服务器 + 本地 NAS" = 把原来单台 EVO-X2 的职责拆成计算与存储两块。服务器管算力，NAS 管数据和备份。
| 组件 | 推荐配置 | 说明 | 预算（元） |
|---|
| 小型服务器（计算） | GMKtec EVO-X2 128GB（统一内存） | 2 万内本地流畅跑 30B MoE（25–35 Token/s），功耗仅 ~100W、静音，适合办公室 24h 开机；AMD 核显 + ROCm | 15,000–18,000 |
| 替代方案（可选） | 塔式工作站：Ryzen9/i7 + RTX 4060 16GB + 64GB 内存 | 独显生态成熟（CUDA 坑少），适合以 7–14B 模型为主、偶尔上 30B；功耗与噪音略高 | 12,000–15,000 |
| 本地 NAS（存储） | 群晖 DS423+ / 威联通 TS-464（4 盘位） | 品牌 NAS 省事、自带快照/RAID/APP；DIY（TrueNAS/OMV）更省但费时，单人做样板不推荐 DIY | 2,500–3,500 |
| NAS 硬盘 | 4×2TB NAS 盘（WD Red / 希捷酷狼），RAID5 | 可用容量约 6TB，坏一块不丢数据；留 1 个热备位更好 | 2,000–2,600 |
| 网络 | 千兆内网 + Tailscale 组网 | 服务器-NAS 走内网千兆（读写模型/数据）；你走 Tailscale 远程运维 | 0–300 |
| UPS（可选） | 600VA 在线式 UPS | 厂区断电频繁时必配，保护 NAS 和服务器，避免 RAID 重建/数据损坏 | 400–600 |
💰 采购预算合计：约 2.0–2.6 万元（EVO-X2 + NAS + 4 盘位；UPS 另算 400–600）。比单机 EVO-X2 方案多约 4–6 千，换来的是数据资产独立存储 + 双备份 + 可扩展。
3多模型部署与路由
"多模型"不是全堆大模型，而是按任务分轨：日常活儿用小模型（快），复杂分析上 30B MoE（准），超长/疑难走云端 API（兜底）。权重全部存 NAS，按需加载。
| 模型 | 角色 | 用途 | 速度 / 占用 |
|---|
| Qwen3 7B–14B（小模型） | 日常快处理 | 数据问答、工具调用、摘要、规则任务、报表说明 | 快（40+ Token/s），约 8–14GB |
| Qwen3.6-35B-A3B（30B MoE） | 复杂分析 | 经营周报生成、异常归因、深度经营分析 | 25–35 Token/s，约 20GB |
| bge-m3（嵌入模型） | 向量化 | 产品手册/合同/会议纪要检索（RAG） | 轻量，纯本地 |
| DeepSeek V4 Flash（云端 API） | 兜底 | 超长文本、复杂推理、本地不擅长的任务 | 按量付费，月均 <200 元 |
🎯 路由规则：Agent 收到任务先试小模型 → 任务复杂或小模型输出不达标时切30B MoE → 仍不够（超长/推理难）才走云端 API。敏感数据永远只进本地模型。
4Agent 抓手工具清单（数据相关内部事务）
定位是"抓手工具"不是"业务系统"：帮公司处理数据相关的杂事，不碰经营决策与人事。
| 工具 | 输入 | 输出 | 数据来源 |
|---|
| 经营周报 | 本周时间范围 | 微信图文简报（销量异动/库存预警/TOP 变化） | SQLite + 模型 |
| 数据问答 | 老板自然语言问题（如"上月华东卖了多少"） | SQL 查询结果 + 一句解释 | SQLite + 小模型 |
| 库存盘点辅助 | 库存表/进销存导出 | 异常项（超储/临期/断货风险）+ 建议 | SQLite + 30B MoE |
| 文档检索（RAG） | 问题（如"XX 产品的退换货政策"） | 产品手册/合同片段 + 引用位置 | NAS 文档 → Chroma + bge-m3 |
| 报表生成 | 指标/维度选择 | Excel/图表（月度销售、区域分布等） | SQLite + 工具函数 |
| 会议纪要整理（可选） | 录音转写文本 | 要点/待办清单（仅辅助，不替人决策） | 云端 API（非敏感）或本地 |
5为什么这样搭：vs 单机 EVO-X2
原方案：单机 EVO-X2（一台全干）
- 数据、模型、看板全在机器本机盘
- 备份靠本机快照，机器挂了数据跟着悬
- 扩容要拆机加盘，型号不通用
- 职责不清：数据资产和计算绑在一起
- 优点：成本最低、部署最简单
新方案：小型服务器 + 本地 NAS（推荐）
- 数据资产独立落 NAS：RAID+快照+异地，双保险
- 模型权重存 NAS：换模型/扩容不占服务器盘
- 职责分离：数据归存储层、计算归服务器，好维护
- 可扩展：盘位不够加盘即可，热插拔
- 成本只多 4–6 千，换来的是"数据资产安全"这个卖点
6优化建议（基于现有模型与工具栈）
- 服务器首选 EVO-X2 128GB：统一内存方案至今仍是"2 万内跑 30B MoE"性价比最优解；替代方案才考虑独显工作站（CUDA 坑少、模型生态更顺）。
- 模型权重放 NAS：Ollama 通过 NFS/SMB 挂载 NAS 模型目录，换模型不用挪服务器盘；服务器本地盘只放系统。
- 双轨路由省资源：日常任务别上 30B，小模型又快又省，把 30B MoE 留给周报/归因这类"值钱"的活。
- Agent 工具模板化：工具函数库做成模板，第二客户只改数据库连接和口径，这是复制最快的部分。
- 三层备份链：NAS RAID（防坏盘）→ NAS 每日快照（防误删/勒索）→ Tailscale 异地副本到你本地（防火灾/被盗）。
- 数据不出厂红线：NAS 只暴露内网，Tailscale 只放行你的设备；云端 API 只接非敏感任务。
- UPS 看厂区环境：断电频繁的厂区必配 600VA UPS，避免 RAID 重建和数据损坏——这是硬件维护费里最值钱的一环。
- POC 先行：ROCm/驱动兼容性是全链最大坑，签客户前在自己样机跑通一遍，别到客户现场才试。
7部署步骤（采购到验收）
- 采购：服务器 + NAS + 4×2TB 硬盘（预留 1–2 周物流）
- 服务器：装 Ubuntu 24.04，系统盘/数据盘分区，开 SSH
- NAS：初始化 RAID5，建共享目录 data / backup / models
- 挂载：服务器挂载 NAS 目录，验证读写速度（千兆）
- 模型：装 Ollama，从 NAS 加载小模型 + 30B MoE + bge-m3
- 驱动：ROCm 配置验证，跑通 25–35 Token/s（最大坑，预留 1–2 天）
- 数据：清洗脚本 + SQLite 入库（数据落 NAS）
- Agent：Hermes Agent + 工具函数 + 微信推送 + Streamlit 看板
- 运维：Tailscale 组网 + 三层备份验证 + 备份还原演练
- 交付：架构图 + 运维手册 + 验收演示（老板手机收周报）
📌 与基板的衔接：本方案对应运营基板"阶段三"——服务器+NAS 搭建、多模型/Agent 抓手工具。前期（阶段一/二）数据清洗、建库看板零硬件投入；到阶段三才采购本方案硬件，报价含硬件（约 2–2.6 万），此后月维护费覆盖"数据资产维护 + 硬件设备维护"两块。
8本地模型效果风险控制（技术实操）
把"效果不好"拆成可管理的技术动作：任务分层、模型选型、RAG 调试、微调决策、POC 流程。
| 任务类型 | 用什么 | 验收标准 |
|---|
| 规则明确：周报模板填充、断码/库存预警触发、数据问答（查数） | 本地小模型（7–14B）即可 | 格式正确 + 规则正确（数字/预警条件对） |
| 复杂分析：经营归因、深度分析、报告润色（核心价值，数据敏感） | 30B MoE（本地 · 主力） | 逻辑通顺 + 数据引用准确（可人工复核） |
| 超长文本 / 疑难推理 / 开放式创作（占比小、可脱敏） | 云端大模型 API（DeepSeek · 保险丝） | 客户感知"够用、省事"，月预算 200 内 |
模型选型速查（别再犯"7B 当主力"的错）
- 7–14B：工具调用、数据问答、格式提取——快但浅，别让它做深分析
- 30B MoE（Qwen3.6-35B-A3B）：周报/归因/分析——本地分析主力（智商≈Claude 3.5 Sonnet 级）
- bge-m3：只做嵌入，不做推理
- DeepSeek API：疑难兜底，月预算 200 内
RAG 效果调试清单（效果差先查这里，别怪模型）
- ☐ 知识库文档先清洗：去噪、去重、统一格式（直接用阶段一的数据资产包）
- ☐ 分块大小：500–1000 字/块，保留标题，别切碎
- ☐ 嵌入模型选对：bge-m3 中文效果好；top-k 先取 5–10 再调
- ☐ 检索结果人工抽查 10 条：检索相关了再上模型，检索不对模型再聪明也没用
- ☐ 提示词给足上下文：检索片段 + 问题 + 输出格式全部写进 prompt
微调决策树（前期默认不微调）
- 输出格式不固定 → 先改提示词（90% 情况解决）
- 行业术语/黑话多 → 先做 RAG 喂资料（再解决 80%）
- 真需要固定格式+术语 → 才考虑 QLoRA，且先用 7–14B 小模型练手，别一上来微调 30B
POC 先行操作（客户掏钱前必做）
- 客户真实数据（脱敏后）→ 云端 API 生成 1 份周报样例 + 1 份断码预警样例
- 拿样例跟老板过："本地跑的就是这个效果（数据不出厂），复杂部分云端补"
- 老板认可 → 下单硬件；不认可 → 先调数据/指标，别让硬件背锅