有团队把开源模型下载到内网，原本以为装好依赖、跑通接口就算完成。真正开会时，话题却转向了许可证能不能覆盖对外服务、日志要不要留存、显卡不够时先砍哪段流程。模型文件躺在目录里，争论从技术细节变成了协作边界。
权重开放，不等于责任也开放
“开源”在这里常指权重可获取、代码可审查，有时还附带训练方法和许可证。但许可证条款差异很大：商用范围、再分发条件、署名要求、是否允许蒸馏，都需要逐条看。把开源模型接进产品前，先让法务和工程一起读许可证，减少事后补材料的麻烦。
另一个容易忽略的点是来源记录。团队内部如果要二次微调，训练数据、脚本版本、评测集应留痕。这样不是为了形式，而是当模型表现变化时，能追到是哪次改动带来的。
评测不是跑一遍公开题
公开评测能提供大致方向，却很难回答业务问题。客服摘要看重事实一致性，代码助手看重可执行率，知识问答还要看拒答边界。可操作的做法是拿真实请求做小评测集，固定输入、记录输出、定期复跑。
- 先定义可接受的失败：答错、漏答、编造、格式错乱，处理方式不同。
- 把推理参数写进评测记录，温度、上下文长度、提示词版本都会影响结果。
- 保留人工复核样本，避免只看自动打分。
成本藏在运维里
开源模型不等于零成本。权重可以免费下载，但推理要占显存，服务要监控，版本要回滚，异常输出要有人处理。若并发不高，小规模部署需要关注的组件较少；若请求集中，排队和超时就会先暴露。团队需要估算峰值、平均延迟和失败重试，而不是只看单次生成速度。
数据治理同样绕不开。内网部署降低了数据外流顾虑，但日志、缓存、临时文件仍可能留下敏感内容。哪些请求可记录、保留多久、谁有权限查看，应在上线前定好。否则模型越用越顺手，清理旧日志越难推进。
先写清楚退出条件
我个人倾向把开源模型看成一个可替换部件，而不是一次性项目。上线时就约定：什么情况下回退到旧流程，什么指标连续异常要停用，模型更新由谁批准。这样争论不会停在“能不能用”，而会落到“怎么用、何时停”。
下载权重只是开场。许可证边界、评测集、推理预算和日志规则，才决定它能不能在内网里稳定待下去。