一个常见的场景是：团队把开源模型部署到内网后，第一周最常被问的问题不是“效果怎么样”，而是“接口昨天还能用，今天怎么变了”。模型文件还在，推理服务却因为依赖升级、显存分配或提示词模板调整而表现不稳。大家原本以为接入是终点，结果它只是把问题从“能不能跑”换成了“能不能长期跑”。
先别急着看演示
演示环境里，输入几条干净问题，输出看起来像模像样，很容易让人产生“已经可用”的错觉。但企业内网里的输入往往带着历史数据、缩写、错别字和互相矛盾的约束。开源模型能不能接住这些，不取决于一次演示，而取决于你有没有一套贴着业务的评估集。
评估集不需要一开始就很大，但要有代表性：真实工单、客服记录、内部文档问答、代码片段，都可以按任务拆开。每条样本要写清楚期望输出和不可接受的输出。否则团队会在“感觉还行”和“这里不对”之间反复拉扯，最后把问题归因于模型本身。
版本和许可证，都是工程问题
开源模型的一个现实麻烦是版本。权重、推理框架、量化方式、提示词模板，任何一层变动都可能改变输出。没有版本记录，出了问题就很难回滚。比较稳妥的做法是把模型文件、依赖锁文件、评估结果和上线配置放在一起管理，让每次变更都有据可查。这不是过度设计，而是把“可复现”当成基础能力。
许可证也常被放在上线前才看。不同许可证对商用、再分发、衍生模型和专利授权的要求不一样，有些条款还需要结合使用方式判断。这里不适合靠印象拍板，逐条核对并留下记录，比事后补救省事。开源模型带来的不是一句“可私有化”就能解决的事，它把法务、安全和工程拉到了同一张桌子上。
运维是长期账
推理服务上线后，成本不会只体现在显卡上。监控、日志、限流、故障切换、模型更新、用户反馈回收，都是持续投入。尤其当多个业务共用一套服务时，谁负责改提示词、谁批准模型升级、出问题找谁，需要提前写清楚。否则一个看似通用的接口，最后会变成没人敢动的黑盒。
- 给每次模型变更留评估记录，不只看平均表现，也看边界输入。
- 把许可证和数据处理要求写进上线清单，而不是留在聊天记录里。
- 为接口设版本号和回滚路径，避免一次升级影响全部调用方。
- 明确业务方与平台方的维护边界，减少“都能改、都没人负责”的状态。
所以，开源模型真正的门槛在接入之后。它降低了获取权重的门槛，却没有自动降低治理门槛。团队如果只盯着演示效果，很容易低估版本、评估和运维的长期成本；反过来，把这些基础工作做在前面，模型迭代才不会变成一次次救火。对企业来说，值得问的不是“要不要用”，而是“准备用什么方式长期维护它”。