周五下午，一个小组把某个开源模型的权重拉到本地，打算周一做出演示。到了周一，演示没有出现，问题清单先出现了：许可证能不能商用，量化后效果是否可接受，推理服务怎么监控，出了问题由谁回滚。下载动作很快，后面的工作很慢。
“开放”到底开放了什么
开源模型这个词经常被当作一个文件夹：权重、配置文件、说明文档，打包发出来，看上去就完成了开放。但对使用方来说，真正需要确认的是权限和可复现性。权重能下载，不等于训练数据、训练代码、评测方法都一并可见；许可证允许研究，也不等于允许直接进入生产环境。不同发布方式给出的开放程度并不相同，法务、安全和工程团队应在动手前把边界写清楚。
部署时冒出来的琐碎问题
模型进入内网后，问题会变得具体。显存够不够，推理框架是否支持目标硬件，上下文拉长后延迟如何变化，量化带来的误差落在哪些任务上，日志里该记录哪些字段。这些细节很难靠一次试用回答，需要小规模流量和固定评测集慢慢暴露。
- 先确认许可证和再分发条件，别把“能下载”当成“能随便用”。
- 准备一套贴近业务的小评测集，记录每次模型、提示词和参数的改动。
- 把推理服务当成普通在线服务看待，补上监控、限流、回滚和故障演练。
维护成本常被低估
把开源模型放进业务系统之后，它会像一段长期依赖：需要升级，需要补安全漏洞，需要解释行为变化。上游发布新版本，团队要判断是否跟进；提示词和工具调用改了一行，结果可能就漂移。若没有版本记录和回归测试，所谓自主可控会变成另一种黑箱。开源模型的价值，不在于省掉采购费用，而在于团队能否查看、替换、回滚，并对结果负责。
所以，评估一个开源模型时，除了问“效果怎么样”，还值得追问：许可证能否覆盖我们的使用场景，部署链路能否被复现，出现异常时能否快速退回上一版，团队是否愿意长期维护。回答不了这些问题，下载下来的只是一组文件，不是可用的工程能力。