把模型权重下载到本地，跑通一段问答，屏幕上出现还算通顺的回答——这是很多团队接触开源模型的起点。演示往往顺利，真正的麻烦在后面：同一句提示词，今天和下周的回答不一致；换一台机器，速度掉下来；上游仓库更新后，原本能用的工具调用开始报错。此时问题已不在“模型能不能回答”，而在“这套东西能不能被日常使用”。
可运行不等于可维护
开源模型提供的是权重、配置和许可证的组合，不附带一套贴合你业务的使用说明。它像一块可替换的零件，装进系统后，周围还有推理引擎、量化方式、上下文拼接、缓存和监控。任何一层变动，都可能让输出发生漂移。团队若只记录模型名称，过几周就很难复现一次失败。
更稳妥的做法，是把模型当成依赖项管理。至少记录模型修订号、量化精度、推理框架版本、提示词模板和采样参数。它们不必复杂，但要和代码一起进入版本库。这样出现异常时，能先判断是模型变了，还是外围链路变了。
评测要从自己的任务长出来
公开评测能提供背景，却很难回答“它在我们的工单摘要里是否稳定”。比较实际的方式，是从真实任务中抽一小批样本，覆盖常见输入、边界输入和容易混淆的表达，人工标注可接受与否。每次替换模型或调整参数，都跑同一组样本，观察失败类型，而不只看一个总分。
这里容易忽略的是口径。谁来判断回答合格？允许多长？引用来源是否必须出现？这些规则若没有写下来，评测就会变成个人感觉的集合。开源模型并不会自动带来透明度，透明度来自团队愿意把判断标准摊开。
成本藏在推理之外
部署成本不只是算力账单。还有环境维护、故障排查、输出审核和用户等待。一个模型在演示里响应很快，不代表在并发请求下仍然可接受；本地运行看似省去接口费用，也可能把运维压力转移到内部。把这些隐性工作计入，才能判断自托管是否合适。
另一个边界是数据。开源模型不等于可以随意投喂数据。许可证、训练数据来源和输出责任都需要确认。涉及客户信息或合同文本时，团队应明确哪些数据可以进入推理链路，哪些只能留在受控环境。这里没有统一答案，只有是否提前约定。
把回退路径留在设计里
日常工具需要可回退。新版本上线前保留旧配置，关键流程保留人工接管入口，异常输出能被记录和追踪。这样即使某次更新带来波动，也不至于让整个流程停摆。开源模型的价值，不在于一次演示多亮眼，而在于团队能否围绕它建立一套可替换、可检查、可收回的工程习惯。
所以，下次演示跑通之后，不妨先问几个不浪漫的问题：这次用的到底是哪个修订版？失败样本由谁保存？如果明天要换回去，需要改几处配置？回答完这些，开源模型才算真正进入工作流。