模型服务路由与版本灰度发布：从请求指标到流量比例

同一个模型服务可以同时运行多个版本，但请求不能只靠“新版本上线”来分配。大模型微服务请求路由与模型版本灰度发布，核心是先明确哪些请求该去哪个版本，再用可观察、可回退的方式逐步验证变更。理解这两步，就能把版本更新从一次性切换变成可控过程。

先看请求：路由依据什么决定

路由器通常位于调用方与模型服务之间。它接收请求后，可以根据模型名称、API 路径、调用方标识、区域或请求中的任务类型，选择对应的服务实例。比如，文本生成与向量化任务可能需要不同的模型端点；同一种任务也可以按版本标签分流。

分流规则应使用服务实际能获得、且含义稳定的字段。若依据用户标识分流，要注意标识缺失、匿名请求和不同标识格式；若依据请求内容分类，则需考虑分类本身的延迟、误判和数据处理要求。不要仅凭请求到达顺序随机切换版本，否则同一会话可能前后落到不同模型，结果不易比较。

大模型微服务请求路由与模型版本灰度发布不是简单地把流量百分比调高。每次扩大比例前，都要同时检查服务是否稳定、回答质量是否符合预期，以及新旧版本是否接收了可比较的请求。

固定版本边界：记录模型文件或模型标识、分词器、推理参数、提示模板和服务配置。只改其中一项也应留下版本记录，避免问题出现后无法判断变更来源。
选择分流方式：按比例随机分流适合快速观察整体表现，但单次小样本可能波动较大；按调用方或会话固定分流，便于持续比较，也更适合有连续交互的业务，不过不同组的请求特征可能不一致。
设置小流量观察：先让少量请求进入新版本，再按预先约定的观察窗口逐步增加比例。实际起点和每次增幅应根据请求量、错误影响范围及回滚速度决定，不存在适用于所有服务的固定比例。
并排比较指标：记录请求成功率、超时与错误类型、响应延迟、输入输出长度和资源消耗。质量指标应结合任务设计，例如用固定测试集、人工抽查或适用的自动评估方法检查输出；单看延迟变快，不能证明回答质量没有下降。
扩大或回退：若新版本的关键指标持续符合门槛，再进入下一档流量；若错误、延迟或质量问题超过预设阈值，立即把路由切回稳定版本，并保留日志与版本信息供排查。

新旧版本应在相近时间接收相似请求。流量高峰、输入长度变化、批处理配置不同，都可能影响延迟和成本。样本较少时，不宜只因某几次结果就扩大流量；可以延长观察，或按任务类型、输入长度分组比较。

影子测试会把请求复制给候选版本，但通常不把候选结果返回给调用方，适合观察兼容性和资源开销。它可能带来额外推理成本，也涉及请求数据能否复制的问题。用户灰度则真实返回新版本结果，能观察实际交互影响，但出错时用户会直接感知。两者用途不同，不能互相替代。

回滚不只是把权重改回旧版本。还要确认旧模型实例仍可用，路由配置可恢复，客户端与接口格式兼容，必要的缓存或会话处理不会阻碍切换。可在发布前演练一次从新版本切回稳定版本，并确认监控能看出流量确实回到了旧版本。

落实大模型微服务请求路由与模型版本灰度发布时，可以把流程写成一张发布清单：登记候选版本与差异；确认监控、质量检查和回滚负责人；设定观察窗口、扩量条件与停止条件；执行分流；按同一口径比较新旧版本；达标后继续扩大，异常则切回并记录原因。这样每次发布都有明确依据，而不是凭感觉决定比例。

不一定。流量越小，影响范围越有限，但样本积累更慢。应结合请求量、风险和发现问题后的回滚时间选择起点。

可以，但模型和模板同时变化会增加归因难度。若目标是验证模型版本，最好固定其他配置；若一起修改，应分别记录并设计对照。

当预先定义的稳定性、延迟和质量指标在有代表性的请求上达到要求，且回滚路径可用时，可按计划扩大至全量；不应只以运行时长作为依据。

归根结底，路由负责把请求送到合适的版本，灰度负责控制新版本影响范围。把分流规则、比较指标和回滚条件提前确定，才能让大模型微服务请求路由与模型版本灰度发布既可执行，也可复盘。