深夜跑通一个开源模型的演示，第二天却被问到一个更基础的问题：许可证允许这样用吗？这不是扫兴，而是很多团队真正开始接触模型时遇到的落差。权重文件可以下载，推理脚本也能跑，但“能运行”与“能放心用”之间，仍有一段需要逐条确认的距离。
把开源模型等同于“源码全开”是一种常见误会。更准确地说，市面上不少项目开放的是权重、推理代码，或许还有部分训练配置；训练数据、清洗流程、完整训练日志未必一起给出。于是模型可以复现一次推理，却未必能复现一次训练。对研究者，这影响结论的可验证性；对企业，这影响故障归因和后续微调的边界。
许可证不是附件，而是产品边界的一部分
许可证常被放到采购或法务流程的最后，实际却应更早进入技术选型。有的条款限制商用场景，有的要求衍生模型沿用相同许可，有的对用户规模或服务形态提出条件。条款文字不一定难懂，难的是把它映射到具体业务：内部工具、对外 API、嵌入硬件、二次分发，风险并不相同。技术团队若只看效果演示，法务团队若只看条款文本，中间就会留下解释空白。
另一个容易被低估的是数据来源。开放权重不披露训练数据，并不意味着数据问题不存在。部署方需要判断模型输出是否可能触碰第三方权利，也要评估敏感信息、版权内容和行业合规要求。这里没有一劳永逸的答案，只有是否愿意把问题提前问清楚。
评估要回到自己的任务
公开评测能提供参照，但很难替代本地评估。同一个模型在通用问答里表现平稳，换到长文档抽取、代码补全或多轮工具调用，错误形态会完全不同。更务实的做法是拿一小批真实任务做对照：哪些输入会触发胡编，哪些边界条件会漏答，延迟和成本是否可接受，更新后行为是否漂移。评估集不必宏大，但要能暴露失败模式。
开源模型的价值，也正在这里：它把一部分控制权交回使用方。可以本地部署，可以针对领域数据微调，可以在许可证允许的范围内审计和替换组件。但这份控制权附带维护责任。版本更新、安全修补、推理优化、回归测试，都需要有人持续投入。把“可下载”当成“零成本”，往往会在上线后补交学费。
落地前值得追问的几件事
- 许可证是否覆盖计划中的使用方式，衍生模型和分发方式是否清楚？
- 训练数据与清洗流程披露到什么程度，能否支撑必要的合规判断？
- 推理可复现是否足够，训练可复现是否被承诺，更新节奏是否透明？
- 本地评估是否覆盖真实失败模式，维护成本是否纳入预算？
这些问题不一定会阻止采用，却会改变采用的方式。开源模型不是免费替代品，也不是一句“开放”就能概括的答案。它更像一份需要共同解释的契约：技术团队读性能，法务团队读条款，业务团队读边界。把这三者放在同一张桌上，下载下来的权重才可能变成可长期运行的系统。