很多团队第一次接触开源模型，是从一条部署命令开始的。模型权重下载下来，推理服务跑起来，演示效果不差，会议室里便有了“可以上线”的气氛。真正把服务搬进内网、接上业务数据之后，问题才一个个浮出来：显存够不够，延迟稳不稳，许可证允许怎么用，出了错由谁定位。它给的是可获取的起点，不是可交付的终点。
先别急着问效果，先问边界
在公开演示里，输入输出都干净；到了内网，用户会粘贴格式混乱的表格，会追问上下文之外的信息，也会把模型当成搜索引擎。模型并不能自动理解你的业务约束。它更像一块可裁剪的原材料：团队需要决定哪些请求该拒答，哪些字段必须脱敏，哪些回答要附上依据。把这些边界写进系统提示、检索流程和人工复核环节，通常比反复调温度参数管用。
许可证也是边界的一部分。不同开源模型的授权条款对商用、再分发、署名有不同要求，有的还涉及额外限制。法务与工程最好在选型时就坐在一起，把“能不能用”拆成“怎么用、用到什么程度、改了什么要不要说明”。这类工作不产生演示效果，却决定后续会不会返工。
维护成本藏在版本和评估里
模型文件很大，更新却不总是平滑的。上游发布新版本，团队如果直接替换，可能发现某些长尾请求的表现变了；如果长期冻结版本，又可能错过修复。比较稳妥的做法是保留可回滚的版本记录，同时建立一小套贴近业务的评估集：不是追求漂亮分数，而是看关键场景有没有退化。评估集不需要一开始就很庞大，但需要有人负责更新，否则它会迅速过期。
另一个容易被低估的环节是推理资源。开源模型可以自己部署，意味着硬件、并发、监控和容灾都要自己兜底。演示时一台机器足够，上线后请求量波动、长文本增多、上下文变长，都会改变资源曲线。提前做容量假设，保留降级策略，事后扩容时才不至于手忙脚乱。这里没有统一答案，只有与业务节奏匹配的取舍。
把“开放”用在对的地方
开源模型真正的价值，不只是省下一笔调用费用，而是让团队能检查、替换和组合。遇到特定领域的表达习惯，可以通过检索增强或轻量微调去适配；遇到合规要求，可以把推理放在自己的环境里；遇到供应商策略变化，至少还有迁移空间。但这些好处有前提：团队愿意维护数据管道，愿意记录实验，愿意把模型当成系统组件而不是万能接口。
所以，评价一个候选模型是否合适，不妨先问四个问题：它允许我们怎么用？它在我们的关键场景里稳定吗？出问题时能不能定位到数据、提示还是模型本身？如果上游停止更新，我们还能不能继续维护？这些问题没有演示视频好看，却贴近真实的落地。
把权重交出来，也把责任一并交了出来。把服务放进内网只是开始，后面的边界、版本、评估和运维，才是长期功课。