新模型离线表现更好，不代表上线后一定更稳。对大模型微服务请求路由与模型版本灰度发布而言，关键收益是把风险限制在一部分流量内，并用线上数据决定是否继续扩量。与一次性切换相比，灰度发布多了路由和观测工作，但能在问题扩大前暂停或回滚。
先让比较成立：同一批请求看两个版本
比较时应记录版本、流量比例、时间段和请求特征。至少区分输入长度、任务类型及是否命中缓存；否则流量构成变化可能被误判为模型差异。可以通过支持加权路由的网关（如 Envoy）分配版本流量，并用 Prometheus 汇总指标。确保两个版本使用相同的超时、重试和资源统计口径。
五项指标分别回答什么问题
1. 延迟：用户是否等得更久
同时观察首 token 延迟和完整请求延迟的 p95、p99，而不只看平均值。生成式请求的输出长度会显著影响总耗时；应按相近输入、输出长度分组比较。若新版本尾部延迟持续升高，先限制扩量，再检查模型加载、排队和批处理设置。
2. 错误率：失败是否增加
统计超时、服务端错误、连接中断及无效响应占比，并区分模型自身异常和路由故障。错误率从低基线出现持续上升，比单个尖峰更值得关注。上线前可为每类错误设定停止线，例如超过历史基线并连续多个观测窗口出现时暂停；具体阈值取决于服务的错误预算和流量规模。
3. 吞吐与排队：单位时间处理能力是否改变
看每秒完成请求数、排队时间及队列长度。请求数相同不等于计算负载相同，长上下文与短问答消耗差异可能很大。若灰度版本吞吐下降且等待时间上升，可能需要检查并发上限或批处理策略，而不是单纯增加流量。
4. 输出质量：响应是否仍满足任务要求
选择与具体业务相符的线上信号：结构化输出可看解析成功率，工具调用可看调用成功率，问答服务可抽样检查事实错误和不完整回答。质量指标应与延迟、错误率并列观察，不能用“请求成功返回”代替答案合格。
5. 单位成本：每个有效结果是否更贵
将模型推理资源、输入与输出 token 用量等成本，除以成功且符合要求的请求数。按相同流量窗口比较，并注明硬件、上下文长度和批处理条件。新版本即使更快，若单位成本明显上升，也需要判断质量提升是否足以抵消开销。
灰度相对一次性切换的收益与代价
一次性切换配置简单，适合新旧版本差异小、回滚快速且线上风险较低的变更；缺点是故障影响范围可能迅速扩大。灰度能限制早期影响、积累真实负载下的证据，也便于定位版本差异，但需要维护版本路由、指标看板和回滚流程。大模型微服务请求路由与模型版本灰度发布尤其适合模型权重、推理框架或提示模板有实质变化的场景。
按指标推进的操作步骤
- 固定比较口径：记录旧版基线，明确延迟、错误率、质量和成本的停止条件。
- 先验证新版本健康、容量与回滚路径，再从少量流量开始；常见做法是按 1%、5%、20%、50%逐步扩量，但比例和观察时长应按流量与风险调整。
- 每次扩量后观察多个完整业务周期，核对五项指标及请求构成；异常时冻结扩量，不要同时改多个配置。
- 触发停止条件便切回旧版，并保存版本、路由比例、时间段和异常指标，供复盘确认。
最终判断不应只看“是否发布成功”，而要看新版本在同等请求条件下是否兼顾质量、延迟与成本。用这五项指标形成证据，再决定继续扩量、调整或回滚，才是大模型微服务请求路由与模型版本灰度发布相较一次性切换的实际收益。
常见问题
灰度比例越小越安全吗？
小比例能缩小初期影响，但流量太少时指标波动大、发现问题也慢。应结合请求量和风险选比例。
观察多久再扩量？
至少覆盖有代表性的流量变化；低流量服务可延长观察，不能只凭固定分钟数判断。
质量指标暂时不可自动化怎么办？
先选可量化的任务信号并安排人工抽查，同时把抽样范围和判断标准记录下来，不要将其误称为完整质量评估。
什么时候一次性切换更合适？
变更风险低、影响面可控、旧版能快速恢复且灰度路由成本不划算时，可以考虑一次性切换，但仍需保留监控和回滚手段。
