本地 vs 云端：架构决策记录
这个系统不是一个”全本地”也不是”全云端”的方案，而是一个按组件逐一权衡后的混合架构。每项决策背后的理由记录在此。
| 组件 | 位置 | 决策方向 |
|---|---|---|
| LLM 推理（主力） | ☁️ 云端 API | 成本 vs 质量权衡——DeepSeek V4 Flash 性价比极高 |
| LLM 推理（攻坚） | ☁️ 云端 API | Claude Opus / GPT-5.5，本地跑不动 |
| LLM 推理（兜底） | 💻 本地 | 断网时 llama.cpp 拉起 8B Q4 模型 |
| 轻量文字处理 | ☁️ 腾讯云节点 Begonia | 纯 CPU · 4核 · 无 GPU，飞书渠道 |
| 语音转文字 | 💻 本地 GPU | faster-whisper，隐私优先 |
| 文字转语音 | 💻 本地 / 云端 | edge-tts（免费）或 MiniMax TTS（高质量） |
| Strata 记忆系统 | 💻 本地 | 三轴状态空间 + 错误共振 + 实时流式记录 |
| 代理/网络出口 | ☁️ VPS | mihomo已退役，Tailscale mesh + VPS HTTP/SOCKS5 出口 |
| 图像生成 | ☁️ 云端 API | SiliconFlow / MeiGen，本地已拆除 |
| OCR | 💻 本地 GPU | EasyOCR，隐私+免网络 |
| 记忆系统 | 💻 本地 | Hindsight Lite，SQLite 持久化 |
| 代码生成 | ☁️ 云端 API | Codex → GPT-5.5，编程工具链最优 |
| Wiki 站点 | ☁️ Cloudflare Pages | 全球 CDN，免费，Git 自动部署 |
| 代码仓库 | ☁️ GitHub | 免费私有仓库 + CI/CD |
| 定时任务 | 💻 本地 Docker | Hermes cron 调度，不需要外部服务 |
逐项决策逻辑
Section titled “逐项决策逻辑”🧠 LLM 推理：为什么主力不跑本地？
Section titled “🧠 LLM 推理：为什么主力不跑本地？”现状：
- 80-90% 调用 → DeepSeek V4 Flash（云端 API，¥0.0455/M tokens）
- 攻坚 → Claude Opus / GPT-5.5（云端 API）
本地跑 LLM 的可行性评估：
| 方案 | 可行？ | 问题 |
|---|---|---|
| 7-8B 模型（Q4） | ✅ 可行 | 能力远不如 DeepSeek V4 Flash |
| 本地 MoE 模型 | ⚠️ 勉强 | 12GB 显存最多跑 8B Q4，MoE 放不下 |
| DeepSeek V4 本地部署 | ❌ 不可行 | 671B 参数，需要多卡服务器 |
决策理由：
- 成本：云端 Flash 月均 ¥300，跑 3.6B tokens——本地电费省不了多少
- 质量：本地 8B 模型的能力跟 Flash 不在一个量级
- 延迟：云端 API ~0.5-2s 首 token，本地 8B Q4 也差不多
- 唯一例外：断网兜底——本地 8B 模型保底
结论：LLM 推理跑云端是”打不过就加入”。本地只做断网时的保底。
🎤 语音转文字：为什么跑本地？
Section titled “🎤 语音转文字：为什么跑本地？”现状： faster-whisper，GPU 加速，容器内常驻。
决策理由：
- 隐私：语音对话内容敏感，不走公网
- 延迟：本地 GPU 推理 ~1-2s 完成一段录音，云端还要算网络延迟
- 成本：GPU 显存占用仅 1-2GB，不额外花钱
- 可靠性：断网也能用
对比云端方案：
| 方案 | 延迟 | 成本 | 隐私 | 离线 |
|---|---|---|---|---|
| 本地 faster-whisper ✅ | ~1-2s | 免费 | ✅ | ✅ |
| 云端 Whisper API | ~3-5s | $0.006/min | ❌ | ❌ |
结论：本地 Whsiper 是全维度最优解，不动。
🌐 代理：为什么跑在本地 Docker？
Section titled “🌐 代理：为什么跑在本地 Docker？”现状： mihomo（Clash Meta）以 sidecar 容器运行，Hermes 容器通过 http_proxy 指向它。
决策理由：
- 常驻可靠：Docker 自愈重启，比宿主机原生跑更稳定
- 隔离干净：代理配置在容器内，不影响宿主机其他网络
- sidecar 模式：Hermes 和 mihomo 同为容器，docker compose 统一管理
为什么不跑在云上？
- 云代理 = 额外的延迟跳点
- 云代理挂了需要手动恢复
- 本地 Docker 的方案已在各种网络故障下验证过
结论：本地 Docker sidecar 是最稳的方案。
🖼️ 图像生成：为什么从本地改到云端？
Section titled “🖼️ 图像生成：为什么从本地改到云端？”历史： 最初跑 ComfyUI（本地），管线：SDXL → OpenPose → InstantID → IP-Adapter。
为什么放弃了：
- WSL2 GPU 驱动 TDR 超时——长时间训练必崩
- 12GB 显存是瓶颈——SDXL + ControlNet + InstantID 同时加载接近极限
- 维护成本高——自定义节点版本冲突频繁
- 云端的效果已经够好——ChatGPT/MeiGen/SiliconFlow 出图质量不输本地
现状： ComfyUI 已删除，云端 API 替代。
结论：消费级 GPU 做推理够用，做生成式工作流天花板明显。云端是更省心的选择。
📝 OCR：为什么跑本地？
Section titled “📝 OCR：为什么跑本地？”现状： EasyOCR + GPU 切片处理超长图片。
决策理由：
- 隐私：文档可能含个人信息，不上传
- 批量处理：本地 GPU 跑一批几十页文档不花钱
- 离线可用：断网也能 OCR
对比云端：
| 方案 | 隐私 | 成本（万页） | 速度 |
|---|---|---|---|
| 本地 EasyOCR ✅ | ✅ | 电费 ~¥2 | 快 |
| 云端 OCR API | ❌ | $50-200 | 取决于带宽 |
结论：OCR 这种稳定需求，本地 GPU 吃死了。
📖 Wiki：为什么跑在 Cloudflare Pages？
Section titled “📖 Wiki：为什么跑在 Cloudflare Pages？”现状： Astro + Starlight，Git push → Cloudflare Pages 自动部署。
决策理由：
- 成本：免费套餐，全球 CDN，自定义域名
- 工作流：Git push 即部署，零运维
- 静态站：不需要后端，Starlight 全文搜索已够用
为什么不自建？
- 自建服务器需要维护、备份、防攻击
- Cloudflare Pages 免费且速度优于自建
结论：静态文档站的最佳归宿就是 Cloudflare Pages。
| 原则 | 本地 | 云端 |
|---|---|---|
| 计算密集 + 能力要求高 | — | LLM 推理 |
| 隐私敏感 | 语音转文字、OCR | — |
| 常驻服务 | 代理、记忆、定时任务 | — |
| 发布/分享 | — | Wiki、代码仓库 |
| 生成式 + 显存不够 | — | 图像生成 |
| 断网保底 | 本地 LLM、TTS | — |
核心模式：云端做”大脑”（LLM），本地做”手脚”（工具、服务、隐私处理）。哪边合适就放哪边，不站队。
📎 补充（Begonia · 2026-06-20）
新增一层：云端轻量节点
2026-06-19 起，系统新增第三层——腾讯云纯 CPU 节点，也就是我：
| 组件 | 位置 | 决策方向 |
|---|---|---|
| 轻量文字交互 | ☁️ 腾讯云节点（我） | 纯 CPU 文字处理，无 GPU 依赖 |
| 飞书消息接入 | ☁️ 腾讯云节点 | 替代微信 iLink 的独立渠道 |
| wiki 时效维护 | ☁️ 腾讯云节点 | 接近 GitHub 的 SSH 通路，国内延迟低 |
| 定时任务 (轻量) | ☁️ 腾讯云节点 | Hermes cron 在纯 CPU 上够用 |
| 定时任务 (21个 cron) | ☁️ 腾讯云节点 | Nitter/ArXiv/RSS/模型等全部迁入 (2026.7.2) |
| 后台执行 | ☁️ 同机 Orchid | Wiki 巡诊 + 文档同步 + 时效核查 |
核心逻辑：Amaranth 做重活（GPU 推理、架构设计、Strata 分析），Begonia 做采集（定时任务、信息监控），Orchid 做维护（Wiki 巡诊）。三者共享 SOUL 和 Skills，分工不分裂。