AI 推理服务如何进行灰度发布，新模型应该怎样逐步扩大流量

AI模型从测试环境进入生产环境以后，真正的风险往往并不是模型能不能启动，而是它在真实流量、真实数据和真实资源竞争环境下会表现成什么样。新模型可能准确率提高，却消耗更多显存；可能单请求速度很快，却在高并发时出现严重尾延迟；也可能模型本身没有问题，但新的预处理逻辑导致异常输入增加。因此，生产环境通常不会一次性把全部流量切换到新版本，而是通过灰度发布逐步验证。

灰度发布的基本思想，是让旧模型和新模型在一段时间内同时存在，然后通过流量路由控制新模型接收的请求比例。流量比例可以由API网关、负载均衡器、服务网格或者应用自身的路由层控制。例如，一个推理服务同时运行模型V1和V2，路由层可以让一部分符合条件的请求进入V2，其余请求继续进入V1。这样即使新模型出现问题，也只会影响有限范围的流量。

这里需要区分灰度发布和A/B测试。灰度发布首先关注的是新版本能否安全承接生产流量，包括错误率、延迟、吞吐量、资源消耗和稳定性。A/B测试则更加关注不同版本对业务指标的差异，例如推荐点击率、转化率、任务完成率或者用户反馈。两者可以同时使用，但并不是同一个概念。

开始灰度之前，首先应该建立旧模型的生产基线。没有基线，就很难判断新模型到底发生了什么变化。基线至少应该包括请求量、P50/P95/P99延迟、错误率、超时率、吞吐量、CPU使用率、GPU利用率、显存占用以及单位请求资源成本。对于大语言模型，还可以记录首Token延迟、Token生成速度、输入和输出Token数量等指标。

新模型上线时，第一阶段不应该机械地规定必须使用1%的流量。流量比例应该根据系统规模和风险确定。一个每秒只有几十个请求的系统，即使分配1%的流量，也可能长时间只有很少的样本，无法发现问题；而一个大型AI平台的1%流量可能已经对应大量GPU请求。因此，更合理的做法是同时考虑流量比例和实际请求数量。

灰度阶段还应该保证测试流量具有代表性。如果新模型只接收到简单输入，而生产环境的大部分请求都是长文本、复杂图片或者高峰时段请求，那么灰度结果很可能失真。对于需要测试不同负载的系统，可以分别观察短请求、长请求、高并发、低并发以及不同业务类型下的表现。

流量放大应该采用阶段式策略，但不需要固定成“1%、5%、20%、100%”这种模板。一个常见思路是从较小规模开始，在确认关键指标稳定以后增加流量，然后再次观察。如果新版本在每一个阶段都保持在预先定义的安全范围内，再进入下一阶段。具体阶段可以根据业务风险和请求量设置。

灰度过程中最重要的是定义清晰的停止条件。比如错误率持续高于生产基线、P99延迟明显恶化、GPU显存出现持续增长、OOM数量增加、请求超时增加，或者模型业务指标出现显著回归，都可以成为暂停放量的条件。这里不应该规定一个所有AI服务都适用的固定数字，例如“P99超过500毫秒就回滚”，因为不同模型的正常延迟可能相差几个数量级。

回滚机制应该在灰度开始以前就准备好。理想情况下，旧模型版本仍然保持可用，流量路由只需要修改版本权重即可停止新模型接收流量。如果必须重新下载旧模型、重新构建镜像或者等待GPU节点启动，那么所谓的“自动回滚”可能在真正发生事故时并不够快。

对于高价值模型，可以进一步设置自动保护机制。例如，当新版本的错误率、超时率或者资源异常达到预先定义的条件时，系统自动停止继续扩大流量；如果问题持续存在，则将新版本流量降低或者切换回稳定版本。自动回滚的判断应该基于经过验证的业务和技术指标，而不是一个随意选择的阈值。

资源容量是AI灰度发布中非常容易被忽略的问题。新旧模型同时运行意味着一段时间内需要同时承担两套模型的资源需求。如果V1已经占用了大部分GPU显存，那么即使V2只接收很少的请求，也可能因为模型权重加载而导致节点无法容纳两个实例。因此，在灰度之前应该计算模型权重、运行时缓存、KV Cache以及并发请求所需要的显存，并确认节点有足够余量。

GPU利用率也不能单独作为扩容指标。GPU利用率较高可能意味着计算能力已经成为瓶颈，也可能只是某些kernel正在持续执行；GPU利用率不高时，系统仍然可能受到显存、CPU预处理、网络或者请求队列限制。自动扩缩容可以使用Kubernetes Horizontal Pod Autoscaler，也可以使用自定义指标，但对于GPU推理服务，通常需要结合请求队列长度、并发数、延迟、吞吐量和GPU资源指标共同判断。

如果使用Kubernetes部署推理服务，还应该提前考虑新旧版本的实例数量和节点容量。例如旧版本需要若干GPU实例，新版本灰度阶段又需要额外GPU，那么集群是否能够及时调度新Pod就是实际问题。如果没有足够的GPU容量，模型可能根本无法按照设计比例灰度。自动扩容也受到GPU节点启动时间影响，因此不能把它理解成普通CPU Web服务那样几秒钟就完成扩容。

GPU共享也不应该简单地被视为绝对禁止。对于显存需求较低、隔离能力明确的工作负载，可以根据硬件和平台能力采用MIG、时间切片或其他资源隔离方式。但如果两个模型的显存需求接近设备容量，或者对延迟非常敏感，就应该避免资源争抢。最终应该根据实际资源压力和隔离能力决定部署方式。

多GPU模型还需要考虑硬件拓扑。如果模型采用张量并行或者其他跨GPU计算方式，那么GPU之间的通信性能会直接影响推理吞吐和延迟。NVLink可以提高同一节点部分GPU之间的数据交换效率，但它并不意味着网络层可以简单地把请求“路由到本地NVLink GPU”。真正需要优化的是模型实例的GPU放置、并行策略以及跨设备通信，而不是把NVLink当成普通网络路由机制。

新旧模型在灰度期间同时运行也不是问题本身。真正需要检查的是接口和数据契约是否兼容。例如新版本修改了输入字段、输出结构、Tokenizer、模型格式或者后处理逻辑，就必须确认调用方能够正确处理两套版本。对于会话式大语言模型，还需要考虑会话状态、缓存和KV Cache。如果同一个会话频繁在不同版本之间切换，可能导致缓存无法复用或者出现行为不一致，因此可以根据业务需要采用会话级固定路由。

灰度策略还应该考虑用户分群。有些业务适合随机按请求分流，有些则更适合按照用户、租户、地区、设备或者业务类型进行固定分组。固定分组可以避免同一个用户不断看到不同版本，也有利于比较长期业务指标。但具体采用哪种方式，需要根据服务是否有状态以及实验设计决定。

模型效果指标尤其重要。新模型不能只因为“延迟更低”就自动获得全量流量，也不能因为“准确率更高”就忽略GPU成本。生产决策通常需要同时考虑模型效果、技术性能和业务成本。例如一个推荐模型可能需要同时观察推荐质量、响应时间和单位请求成本；一个大语言模型则可能需要同时观察任务成功率、首Token延迟、生成速度、上下文长度和GPU资源消耗。

对于生成式AI，还应该持续观察异常输出、安全策略触发率和人工反馈。如果模型在正常性能指标上表现很好，却出现敏感信息泄露、工具调用异常或者提示词注入防护失效，那么单纯扩大流量显然没有意义。因此，安全指标也应该进入灰度门槛，而不是等全量发布以后再检查。

当新模型经过多个阶段的生产验证以后，是否进入全量发布，应该根据上线前制定的验收标准决定。这里没有必要要求所有指标都必须比旧模型更好。不同版本可能存在性能、成本和模型效果之间的取舍。更合理的方法是提前规定哪些指标必须达到最低要求，哪些指标允许一定范围的变化，以及哪些情况属于不可接受的回归。

全量发布以后，旧版本也不应该立即删除。对于重要服务，可以保留经过验证的稳定版本一段时间，以便在发现延迟、模型效果或者资源问题时快速回退。确认新版本稳定运行以后，再根据资源成本和版本生命周期策略逐步清理旧模型实例和模型制品。

因此，一套成熟的AI灰度发布体系，核心并不是规定一个固定的流量百分比，而是建立可控的实验环境。新旧版本需要能够同时运行，流量路由必须能够精确调整，指标必须能够实时比较，资源容量必须提前验证，异常必须能够停止放量，严重问题必须能够快速回滚，同时还要考虑会话状态、模型效果和安全风险。

AI模型的灰度发布最终解决的是一个非常实际的问题：不要让一个未经真实生产验证的新模型一次性承担全部风险。通过小规模流量、真实数据、连续监控和可逆发布，把模型从“实验室里运行正常”逐步验证到“生产环境能够稳定工作”。当技术性能、资源消耗、业务效果和安全指标都达到预先定义的要求以后，再扩大流量，才是一套真正可执行的生产模型发布流程。