把开源模型部署到内网，演示往往很顺利：一条命令拉起服务，接口能通，回答也像样。摩擦通常出现在之后——有人问，下个月模型升级时，提示词还兼容吗？上个月那批失败请求，谁负责归档？如果新版本在某个业务场景里表现变化，回退要多久？
跑通和可持续使用是两件事
开源模型吸引人的地方，不只是可下载的权重，而是团队能检查行为、替换组件、按业务裁剪。代价是这些自由会把工程责任前移：部署只是起点，版本、评测、日志、权限和回退都要有人管。若只把模型当成一次性的项目交付，问题会在日常使用里慢慢暴露。
先核对许可证，再谈技术接入
许可证常被放到后面看，却值得提前确认。不同项目的授权条款、商用条件、再分发要求并不一样，有的还涉及模型输出或衍生作品的处理方式。这里不适合凭印象判断，应该让法务和工程一起读原文，记录允许与不允许的边界。开源并不等于所有资料都开放，训练数据、评测细节和权重许可可能各自独立。
评估集要来自真实业务
演示阶段的几个问题，无法支撑长期维护。一种做法是从业务里收集一批有代表性的请求，连同已知的失败样本，做成小而稳定的评估集。每次换版本、调量化、改提示词，都跑同一组问题，记录差异。评估不追求漂亮分数，而是帮助团队发现“原来能答对、现在答偏”的回归。
- 保留固定问题与期望要点，避免只凭主观感受判断。
- 记录失败原因：检索缺失、指令冲突、上下文截断，还是工具调用不稳定。
- 把评估结果和版本号、配置一起存档，方便回查。
把回退当成常规能力
升级模型时，回退路径常被放到后面。新版本可能在某些场景表现变化，团队需要能快速切回旧配置，而不是临时重装。模型文件、推理参数、提示词模板、依赖库版本可以一起管理；对外服务保留灰度入口，先让少量请求经过新版本，观察日志和评估结果，再扩大范围。日志要脱敏，但失败样本要可追溯，否则评估集很难更新。
边界需要写清楚
开源模型常被期待“什么都能做”，实际使用中，边界需要说清楚：哪些任务允许自动执行，哪些必须人工确认；上下文多长会截断；工具调用失败时如何降级；许可证是否允许当前分发方式。把这些写进接入文档，是把模型当长期组件管理的一部分。它的价值不在于一次部署，而在于团队能否持续理解它、约束它，并在业务变化时替换它。