技术团队把一份模型权重下载到测试机时，讨论往往很具体：显存够不够、推理延迟能不能接受、许可证是否允许商用。等到要把模型放进企业内网，问题会换一批：出了故障谁修，版本怎么跟，日志和输入数据是否会被带出边界。开源模型在这里不是一个“免费替代品”的标签，而是一组需要接手的责任。
先看许可证。权重可下载，不等于可以随意使用。不同许可证对商用、再分发、修改后发布、附加声明的要求并不相同，有些还会对服务化调用提出条件。企业法务和技术团队需要一起读原文，而不是只看社区里的转述。一个容易被忽略的点是“可审计”：团队能否说明模型来自哪里、改过什么、依赖哪些组件。这种透明度，只有配合内部记录才成立。
维护责任从下载那一刻开始
把模型部署进内网，通常意味着外网更新通道被切断。模型版本、推理框架、依赖库和安全补丁都需要内部流程承接。这里没有一键升级的浪漫，更多是变更记录、回滚方案和值班安排。若团队规模有限，是否有人长期跟踪上游变更，是否能在出现问题时定位到具体组件，往往决定项目能否稳定运行；模型本身的功能清单只是其中一项。开源模型常被当作“可控”的理由，但可控的前提是有人真正控制它。
评测也需要重新设计。公开评测集能提供参考，却很难覆盖企业自己的输入分布。一种务实的做法是准备一小批贴近业务的样本，记录模型在边界情况下的表现，并保留人工复核通道。评测不是一次性打分，而是持续观察：新版本是否改变了输出风格，微调后是否损伤了原有能力，提示词和检索组件的变化是否被误归因于模型。把这些记录留下来，后续更换模型或调整参数时才有依据。
数据回流与边界
内网部署常被理解为数据不出门，但日志、监控、反馈数据仍可能流动。需要提前约定哪些数据可以留存、留存多久、谁有权查看，以及是否用于后续训练。若计划用业务数据做微调，数据清洗和授权问题会先于算法问题出现。一个谨慎的做法是把“模型能力”和“数据责任”分开评审：能力不达标可以换方案，数据边界失守则很难补救。
所以，开源模型适合什么样的团队？我的判断是，适合愿意把一部分工程责任留在内部的团队，而不是只想省掉采购流程的团队。它提供的是可检查、可替换的起点，不是免维护的终点。部署前不妨让技术、法务和业务坐在一起，把许可证、维护人、评测集和数据边界写成几页纸。几页纸不能保证项目成功，但能筛掉那些把它当成万能开关的期待。