有一次旁听内部技术评审，讨论的不是模型能力，而是一张机房扩容单。业务团队希望把几个调用量稳定的任务迁到本地，理由很直接：外部接口按量计费，预算不可控；数据出去一圈，合规同事也要反复确认。有人提议用开源模型，会议室里短暂安静，随后问题变成了：省下来的接口费，会不会转手花在运维上？
先看“免费”背后的账
开源模型的许可宽松，不等于使用成本消失。权重可以下载，推理服务仍要占机器；机器要电、要散热、要人盯着。隐蔽的是版本升级：上游更新节奏不固定，团队若改过推理链路或做过微调，升级就可能变成一次小迁移。把这些放进预算表，开源模型是一笔“前期投入换长期可控”的账，而不是零成本替代。
可控性到底值多少
本地部署的吸引力，常被概括为数据不出域。实际体验里，可控性还包括响应时间、限流策略、日志留存和故障排查。外部接口出问题时，团队能做的通常有限；本地服务出问题时，至少能登录机器看显存、看队列、看日志。对调用量稳定、对数据边界敏感的业务，这部分价值容易算清楚；对需求波动大、团队缺少运维人手的场景，它也可能变成负担。
维护负担常被低估
模型文件只是起点。推理框架、驱动版本、容器镜像、监控告警，任何一环变动都可能影响服务。开源社区活跃，不代表每个分支都适合生产；文档写得清楚，也不代表值班同事能在凌晨快速定位问题。一个常见误区是拿演示环境的表现推生产容量，忽略了并发、长文本和冷启动。真要把开源模型放进核心链路，先准备回退路径，再谈替换比例。
什么时候可以先小步走
如果业务方对延迟要求不苛刻，任务边界清晰，团队里又有人愿意维护服务，那么从旁路任务开始试，比一次性迁移稳妥。可以先用它处理内部摘要、分类或检索增强中的一部分环节，保留外部接口作为兜底。观察一段时间后，再判断是否扩大范围。反过来，如果团队没有明确的值班安排，或者业务对输出稳定性要求很高，继续使用托管服务未必是保守，可能只是诚实的判断。
边界比口号重要
开源模型不是万能钥匙，也不是廉价标签。它提供的是一种可检查、可修改的可能，代价是团队要承担相应的工程责任。讨论它时，少问“能不能替代”，多问“谁来维护、出问题怎么办、升级路径是否清楚”。这些问题没有标准答案，却能把一次技术选型从情绪拉回桌面。