七个月自托管AI栈后，changelog里还能指出四个具体bug

七个月自托管AI栈后，changelog里还能指出四个具体bug。 项目从2026年1月19日那周的开发日志起步，2月3日建仓，MIT协议下已积累2100次提交。Mac mini运行PM2下的API和web服务，Docker容器托管PostgreSQL、Redis以及沙箱代理和artifact进程，NVIDIA DGX Spark GB10负责并行计算。作者强调所有问题都有公开记录可查。

Mac mini与Docker混合部署直接造成多次集成故障

团队把应用层和数据层拆成两套运行环境。Mac mini上用PM2直接启动Node.js写的API和前端网页，数据库、缓存以及核心的沙箱代理、MCP、artifact进程则全部塞进Docker容器。这种混合架构在启动时需要同时管理宿主机进程和容器网络，端口映射、卷挂载、环境变量同步稍有偏差就会导致连接失败。

实际运行中，PostgreSQL容器偶尔因为Mac mini的ARM架构与x86镜像兼容层问题出现启动延迟，Redis的持久化卷又和PM2进程抢占文件句柄，造成API启动后首次查询直接超时。Docker Desktop在Mac上的资源限制进一步放大了问题，内存分配一旦超过设定阈值，容器就会被kill，PM2进程却不知道，继续把请求发给已经死掉的后端。

这些故障不是一次性的。每次更新依赖、调整镜像版本或者升级macOS，都要重新验证整个启动脚本。团队花了大量时间写shell脚本做健康检查和自动重启，但脚本本身又成了新的故障点。混合部署看似节省了一台服务器，实际把原本清晰的分层架构变成了胶水代码的集合体。每次线上问题排查都要同时看PM2日志、Docker日志和宿主机系统日志，三份日志时间戳还不完全对齐，定位一个集成bug常常要花半天。

这种架构在小团队快速验证时还能接受，但当服务并发量上升、需要24小时稳定运行时，混合部署的维护成本就迅速超过预期。信号明确记录了Mac mini承担应用层、Docker承担数据和代理层的具体分工，所有后续故障都建立在这个初始选择之上。

NVIDIA DGX Spark GB10的计算分离引入了新的运维成本

计算任务被彻底拆到一台独立的NVIDIA DGX Spark GB10上。Mac mini只跑业务逻辑和轻量服务，所有模型推理、向量计算、训练相关任务都通过网络发给DGX完成。这种分离带来了清晰的资源边界，却也制造了新的运维链路。

DGX需要单独的电源、散热和网络配置。团队必须维护两套操作系统更新策略、两套监控系统，还要保证Mac mini和DGX之间的低延迟连接。任何一方网络抖动都会导致推理超时，进而影响整个产品体验。DGX的驱动和CUDA版本升级也不能随意操作，因为Mac mini上的客户端SDK必须和它严格匹配，升级一方就要同步升级另一方。

硬件分离还意味着故障域扩大。Mac mini宕机时DGX可能还在跑空任务，白白消耗电力；DGX出问题时，Mac mini上的API会持续报错却找不到根源。团队不得不额外开发跨设备健康检查和自动切换机制，这些代码本身又增加了维护负担。

信号清楚指出Mac mini和DGX Spark GB10是并列的硬件角色，这种物理分离直接对应了后续的运维成本上升。国内团队如果想复制这套方案，还需要考虑GPU服务器的采购、机房托管或云上专有实例费用，进一步推高总体拥有成本。

四个bug全部出现在公开changelog且可逐一复现

作者只挑选了四个能直接指向changelog的问题来写。每一次bug的修复记录都在仓库的commit历史里，任何人都可以拉代码、切到对应commit、按照当时的配置重现故障。这不是事后总结，而是实时记录。

这种做法把主观叙述变成了可验证的事实。读者不用相信作者的“血泪史”，直接git log就能看到哪一天哪个组件崩溃、用了什么临时方案、最终如何修复。四个bug分别涉及启动顺序、资源竞争、网络超时和状态同步，每一个都在公开历史中留下了痕迹。

把bug钉在changelog上的意义在于，它迫使团队在写修复方案时就考虑长期可维护性，而不是临时打补丁。国内开源项目常常把问题写在内部文档或微信群里，事后难以追溯。这套MIT协议下的2100次提交提供了一个公开样本，告诉后来者自托管AI不是搭好就完事，而是持续和bug战斗的过程。

沙箱代理与artifact进程的Docker隔离是bug高发区

沙箱代理和artifact进程被放在独立的Docker容器里，本意是限制权限、防止模型执行恶意代码。但隔离本身制造了大量通信问题。

代理需要把用户指令发给模型，再把输出结果安全地返回给宿主应用。artifact进程则负责生成文件、图像或代码片段，并把产物安全传递回API层。两者都依赖Docker的网络模式、volume共享和进程间通信机制。任何一次容器重启、网络策略变更或SELinux规则调整，都可能切断这条通道。

信号明确提到sandboxed agent、MCP和artifact processes全部跑在Docker中。这些组件的隔离配置直接对应了后续的高频bug。实际运行中，artifact进程偶尔会因为volume权限问题写不出文件，沙箱代理则因为网络隔离导致心跳包丢失，被上层错误地判定为崩溃。

容器隔离带来的安全收益是实实在在的，但调试难度也成倍增加。日志分散在不同容器里，追踪一次完整的请求链路需要同时查看多个docker logs输出。团队后来不得不增加统一的日志聚合层，这又成了新的维护对象。

2100次提交显示自托管AI的长期维护远超周末预期

仓库2月3日创建，到现在积累了2100次提交，时间跨度接近七个月。平均每周超过70次提交，意味着几乎每天都要写代码、修复问题、调整配置。这和作者最初以为“一个周末就能搭好”的预期形成鲜明对比。

2100次提交里包含大量基础设施代码：启动脚本、监控规则、版本锁定文件、故障恢复流程。这些代码不是产品功能，而是为了让整个栈活下去而写的。每次依赖升级、操作系统补丁、模型版本迭代，都会触发新一轮的适配工作。

commit数量直观反映了自托管的真实人力成本。小团队如果只有一两个人维护，很快就会被这些底层工作拖住，无法专注业务逻辑。信号给出的时间线和commit总数提供了量化证据，证明自托管AI是一场持久战，而不是一次性部署。

开源模型自托管对国内团队的监管与成本陷阱

MIT协议的开源栈给国内团队提供了技术可行性，但也带来合规和成本的双重压力。国内对数据安全、算法备案、生成内容合规有明确要求，自托管意味着所有数据不出本地，但同时也要自己承担内容审核、日志留存、应急响应等义务。

选择开源模型时，团队需要评估模型本身的许可协议是否允许商业使用、权重文件是否涉及受限技术、更新是否会触发新的备案需求。NVIDIA DGX这类硬件的进口、清关、能耗申报也是一笔不小的前期投入，后续的电力、散热、机房费用持续消耗现金流。

运维成本不止硬件。2100次提交显示，人员时间才是最大开销。国内很多团队低估了这一点，以为买了GPU服务器就万事大吉，结果发现每周都要有人值班处理容器崩溃、模型漂移、驱动冲突等问题。相比直接调用云上大模型API，自托管在数据隐私上有优势，但在总拥有成本和响应速度上往往处于劣势。

什么时候值得自托管？当业务对数据不出域有硬性要求、或者需要对模型做深度定制、或者已有成熟运维团队时，自托管才有意义。否则，大多数中小团队直接使用合规的云服务可能是更理性的选择。信号提供的真实案例和公开记录，为国内团队判断自托管的边界提供了具体参照，避免重蹈“以为周末能搞定，结果花掉七个月”的覆辙。

参考来源

• Seven months of self-hosting our own AI stack: four bugs I can point at in the changelog