夜里十一点，内网机房的部署脚本终于跑通了。权重从外网拷进来，绕过代理，落在两块本地盘上。屏幕上跳出一行正常的回复，负责实施的工程师松了口气，旁边的运维却没走，问了一句：这东西以后谁负责升级？
这个问题听起来像流程问题，其实是采购问题。把开源模型搬进自己的机器，最容易被忽略的一点是，它并非一次性交付的软件，而是一个会持续变化的上游项目。
权重下载完成，工作量才刚开始
README 里通常写着显存需求和几个示例命令，不会写许可证的边界、量化版本的行为差异、上下文长度的实测值，这些都要自己补。团队常常在前两周就遇到一个具体麻烦：同一份权重，fp16 与 4bit 量化在结构化输出上的稳定性不同，前者能跑通的提示词，后者会漏字段。
这是取舍，并非缺陷。量化省下的显存，最终要用提示词的健壮性和人工复核补回来。做预算时把这一块算进去，比事后抱怨模型“不稳定”更实际。
许可证是工程约束，不只是法务文件
很多团队把许可证当成签字前才看的材料。实际上它决定了架构：能不能商用、能否再分发、改名后是否需要保留声明、某些条款是否随下游调用传递。这些约束会落到代码仓库的依赖清单里，和框架版本并列。
- 把许可证条款摘要写进部署文档，注明触发条件；
- 记录权重来源、下载时间与提交哈希，避免“同名不同物”；
- 对再分发场景单独确认，不靠口头判断。
同名仓库更新的代价
上游仓库改动很常见：修正配置、换 tokenizer、调整默认参数。公告里一句轻描淡写的话，落到下游就是输出格式变了、分隔符变了。建议锁定版本，保存 tokenizer 文件与推理配置，把升级当成一次需要回归测试的发布，而不是随手拉取。
有人会说，这样用开源模型还有什么意义。意义在于可检查：你能看到权重、看到配置、看到推理代码，能在本地复现一次失败，而不是只能提交工单等待。这种可检查性在排查线上问题时非常值钱，前提是你真的去看。
评测得自己做
公开评测反映的是通用能力，落到具体业务上帮助有限。更实用的做法是攒一个小规模的内部样本集，几十到几百条，覆盖真实输入里的脏数据，固定下来，每次换版本跑一遍。样本集本身也会成为团队资产，比任何一次口头评估都可靠。
最后是关于边界的判断。开源模型给人的掌控感是有限的：你能改代码，但改不动预训练留下的能力边界；你能部署到自己的机器，但推理成本、长尾场景的稳定性、内容安全的兜底仍然要自己承担。
回到机房那个问题。比较稳妥的答案是：把它当成一个有明确维护成本的基础设施部件，指派负责人，写清升级节奏，再决定要不要用。这样它才是一个可以长期相处的选择，而不是一次性的技术尝鲜。