模型升级最怕的不是新版本启动失败，而是少量请求已经切过去，异常却被平均指标掩盖。要做好大模型微服务请求路由与模型版本灰度发布，关键是让请求分组稳定、版本边界清楚，并在扩大流量前明确验证和回滚条件。
下面以一个对话生成服务为例说明操作方法。版本可以是同一模型的不同权重，也可以包含不同的分词器、提示模板或推理参数；比如部署 Qwen2.5-7B-Instruct 时，不能只比较权重文件，还应记录配套配置。示例中的版本代号仅作发布标识，不代表该模型的官方版本号。
先把发布边界和回退条件定清楚
灰度前，为旧版和候选版分别登记镜像摘要、模型文件校验信息、启动参数、提示模板及服务配置。这样即使标签被覆盖，也能确认实际运行内容。旧版副本应保留至新版本通过观察期，且具备独立接收请求的能力。
再选定观测指标：请求成功率、超时率、首 token 延迟、生成速度、输出长度，以及 GPU 显存和队列等待。具体阈值应以当前服务的历史基线和业务目标为准；没有基线时先用离线样例和小流量试运行建立参照，不要套用一个适用于所有模型的固定标准。记录请求 ID、路由版本和耗时，可借助 OpenTelemetry 将链路关联起来，但应避免记录不必要的敏感提示内容。
按流量分组，逐步扩大新版本占比
大模型微服务请求路由与模型版本灰度发布应采用可重复的分流规则。优先用用户或会话标识做哈希分组，使同一会话持续落到同一版本；缺少稳定标识时，才使用请求 ID。随机逐请求切换可能让多轮对话在版本间跳转，增加体验波动，也会让对比结果难以解释。
- 准备双版本：确认旧版仍可接流量，候选版通过启动检查和少量离线请求检查；核对模型文件、依赖、上下文长度及生成参数。
- 开启小流量：先将约 1%—5% 的合格请求路由到候选版。这个起始范围适用于有足够请求量且能快速隔离流量的服务；低流量服务可采用内部验证或定时测试请求，避免样本少却误判。
- 分批观察：按约 5%、20%、50% 逐级增加，最后再全量切换。每一档至少覆盖新副本预热时间及有代表性的负载时段；常见观察窗口可从十几分钟起步，但请求量小、排队明显或存在峰谷时应延长。
- 保持对照：在相近时间段比较新旧版，并按模型、请求类型和流量来源拆分指标。对于流式生成，还要同时检查首 token 延迟和中途断流，不能只看请求最终是否成功。
校验质量，出现异常立即回滚
每个流量档位都要检查技术指标和输出表现。可用固定提示集验证格式、拒答边界和工具调用约束，再抽查脱敏后的代表性结果；不同业务应选用适配的质量标准，不宜只凭单个自动评分决定放量。对话服务若发生格式错误增多、答案截断或明显延迟上升，应先暂停扩流并定位版本差异。
预先写明回滚触发条件，例如候选版的 5xx 或超时持续高于旧版、关键质量检查失败，或延迟越过服务目标。阈值应结合基线、样本量和告警噪声确定；若异常只出现一两个孤立请求，可先核查日志，不必机械切回。确认达到条件后，将路由权重归零并指回旧版，检查在途请求是否完成、队列是否回落，再核实新请求确已不再进入候选版。
回滚后保留发布标识、路由变更时间、错误样例和模型配置差异。不要立刻删除候选版或覆盖旧制品，否则难以复现问题。大模型微服务请求路由与模型版本灰度发布的完成标准，不只是流量切换成功，还包括指标稳定、输出检查通过，并且回退路径经过确认。
常见问题
灰度比例越小越安全吗？
小比例能限制影响面，但请求太少时难以发现低频问题。比例应结合流量规模和风险设定，并保证观察样本足以比较。
可以按每次请求随机切版本吗？
可以用于无状态、互不相关的单次请求；多轮对话更适合按会话或用户稳定分组，避免同一会话跨版本。
新版本只改提示模板，也要灰度吗？
建议至少经过回归检查和小流量验证。提示变化可能影响输出格式、长度和工具调用，不能仅因权重未变就跳过验证。
全量后什么时候删除旧版本？
待全量观察期结束、回滚风险可接受且制品已按规范留存后，再释放旧版运行资源；具体时长取决于流量周期与恢复要求。
