我把生产环境跑在自己 NAS 上，一年了
我把好几个对外服务的生产环境，跑在自己家里的 NAS 上。
朋友第一次听说时的反应基本一致：疯了吧，不心疼可用性？
跑了一年，这篇把这笔账完整算一遍。
不是炫技，是因为自部署与否，本质上是一组可以理性计算的产品决策，不是信仰问题。
成本结构：先算钱，再谈情怀
拿跑得最久的数据服务举例。
云上跑，成本大头两块：计算与带宽按月付费，数据库与存储按量累积。
而这个服务真正的技术重心——LLM 调用与数据抓取——开销在 API 账单上，跟部署在哪无关。
搬到 NAS 之后：部署相关的成本（计算、带宽、存储）变成近似零的边际成本，一次性硬件投入摊到两三年里可以忽略。
总账：月成本降到全云方案的零头。
但这个结论有适用边界：成立的前提是"计算与带宽不是服务的核心竞争力"。算力密集、延迟敏感、商业 SLA 的服务，云的成本就该花。
自部署省的是"部署税"，不是"产品成本"。
架构：分层分发是自部署的灵魂
家庭环境先天劣势：没有固定公网 IP，上行带宽有限。
我的解法是把架构拆成两层，各自取长：
动态层跑在家里：数据库、任务队列、LLM 编排、管理后台——只需要自己和少数授权者访问，通过 Cloudflare Tunnel 穿透暴露。
静态层推出去：前端页面和数据快照，由家里的定时任务每 10 分钟 rsync 推到一台小 VPS 上，Nginx 直接分发。用户访问的全是静态内容，享受 VPS 的稳定出口。
数据走密钥路径：动态数据以带密钥前缀的路径放在 VPS 上，配限速防爬，入口不对普通访客暴露。
这个分层的妙处：家里的故障只影响"生产内容"，不影响"服务用户"。NAS 重启的十分钟里，公网用户看到的站点一切如常，只是数据没有更新。
故障域被架构切开了。
自愈设计：三个层次
自部署最大的隐性成本是"你要当自己的运维"。我的原则：凡是人肉修过两次的故障，第三次必须自愈。
第一层，服务自启：所有常驻服务配自动重启与开机自启。NAS 断电重启是家常便饭，服务必须自己回来。
第二层，内容自愈：静态分发用对账式推送（目标端缺什么补什么），推送任务用文件锁防止并发踩踏。就算 VPS 上文件被误删，下一轮推送自动补齐。
第三层，配置快照：反向代理、隧道、定时任务的所有关键配置定期快照。改配置出问题时，回滚是恢复一条快照，而不是凭记忆重配。
外加一套健康探针：隧道通不通、源站响应码、数据新鲜度——探针接通知，出问题手机先知道，而不是等用户反馈。
什么时候不该自部署（丑话说前面）
四种情况我建议直接上云：
延迟敏感型：实时交互、在线推理、直播——家庭宽带的上下行和抖动撑不住。
合规敏感型：大规模用户隐私数据存储，家用环境的物理安全与备份冗余达不到水位。
高可用承诺型：对外承诺 SLA 的商业服务，断电断网风险不可控。
团队协作密集型：多人高频部署的环境，远程家区的协作摩擦会吃掉省下的钱。
自部署教我的产品思维
最后说个意外收获。
云服务把运维复杂度藏在账单里，自部署把账单换成复杂度——你会被迫真正理解自己的服务到底消耗什么、什么会坏、坏了影响谁。
这份理解反过来会让你在云端做架构决策时更省：知道哪些冗余是真冗余，哪些是花钱买心安。
自部署不是省钱的技巧，是把基础设施当产品经营的修炼。
集群的完整分工见 算力集群演进记；NAS 上跑业务大模型的决策框架见 本地还是云端。
← 返回博客列表 · 相关阅读：算力集群演进记 · Layer 0 控制图