把模型权重下载下来，在本地跑通一个接口，通常只花一个下午。等它进入测试环境，问题才慢慢浮出来：推理框架升级后显存占用变了，依赖包互相打架，某个量化版本在长文本上开始胡言乱语。此时你面对的已经不是“能不能用”，而是“谁来一直管”。
开源模型容易让人产生一种错觉：代码和权重都在手里，成本就归零了。实际上，开放的是修改与部署的可能性，不是维护责任。模型文件只是起点，后面还有容器镜像、推理服务、监控、日志、访问控制、版本回滚。每一项都不显眼，却会在日常里反复消耗人力。
下载之后，账单才开始
企业里常见的路径是，先由一个小组做概念验证，选一个开源模型跑通业务场景，再交给平台团队上线。交接时容易被忽略的是知识：为什么选这个版本，改过哪些提示词，评测集放在哪里，出现异常时先看哪项指标。缺少这些上下文，后来者只能重新摸索，维护成本被悄悄放大。
许可证也需要认真读。不同开源模型对商用、再分发、署名和衍生作品的要求并不一样，有的还附带使用限制。把权重放进产品之前，法务和工程需要一起确认边界，而不是等到发布前才补材料。
真正稀缺的是可持续的评测
模型更新很快，今天能用的版本，过一段时间可能被新权重替代。替换之前，需要一套稳定的评测集：既包含通用能力，也包含业务里的边角问题。没有评测，升级就变成凭感觉；有了评测，至少能知道变化发生在哪里。评测集本身也要维护，否则它会慢慢偏离真实流量。
- 记录模型版本、量化方式和推理参数，避免“环境一变就找不到原因”。
- 把提示词、评测样本和部署配置纳入版本管理，让回滚有据可依。
- 明确安全责任：输入过滤、输出审查、权限隔离，不能因为模型在本地运行就省略。
这也是开源模型在企业里的真实位置：它把选择权交出来，同时把运营能力的要求摆到台面上。能自托管，不等于能自愈；能修改，不等于该无限修改。团队需要判断哪些改动值得跟进，哪些可以停留在当前版本。
所以，讨论开源模型时，不妨少问“它能不能替代谁”，多问“我们能不能持续养好它”。前者是发布会上的问题，后者才是值班表上的问题。把维护边界想清楚，开放才真正变成可用的自由。