模型迭代速度越来越快，但线上服务的稳定性不允许我们随随便便把新模型直接推给所有用户。想象一下这样的场景：数据科学家花了两周训练出一个新版本模型，离线评估指标全面领先，可上线后线上转化率却出现明显下滑——这时候如果没有版本管理机制，回滚将是一件手忙脚乱的事情。灰度发布正是为了解决这个问题而生：让新旧版本同时在线，按比例分发流量，用真实数据验证新模型的表现，确认没问题后再逐步扩大范围。
为什么模型部署需要多版本共存架构
传统的模型更新方式是“停服替换”：下载新模型文件，重启服务，旧版本直接下线。这种方式在业务低峰期或许可行，但存在两个致命缺陷。第一，一旦新模型效果异常，需要重新部署旧版本才能恢复，中间的故障窗口可能长达几分钟甚至更久；第二，我们无法对比新旧版本在真实流量上的表现差异，只能凭离线评估做决策，而离线指标与线上效果往往存在偏差。
多版本共存架构的核心思想是把“模型版本”作为一等公民来管理。每个训练完成的模型都赋予唯一版本号，独立部署为一个可服务的实例，由统一的流量入口按策略分发请求。这样做的直接收益是：新版本出现问题时，只需把流量切回旧版本，秒级完成回滚；同时新旧版本并行接收真实流量，为线上A/B对比提供了数据基础。
一个规范的多版本管理系统通常包含四个要素：模型注册中心（记录版本、指标、训练数据等元信息）、制品仓库（存放模型文件）、版本化服务实例（每个版本一个部署单元）以及流量路由层（控制版本间的请求分配）。这四个要素环环相扣，缺一不可。
流量拆分策略与路由实现
灰度发布的关键在于流量如何拆分。最常见的策略有三种：按比例随机分流、按用户标识哈希分流和按特征规则分流。按比例分流实现最简单，比如新旧版本按5%和95%接收请求，但同一个用户可能一会儿命中新版本、一会儿命中旧版本，体验上存在不一致性。按用户哈希分流则对用户ID取哈希后取模，保证同一用户始终命中同一版本，这是A/B测试的标准做法。按特征规则分流更灵活，比如只让某个地区或某个白名单内的用户使用新版本，适合做内部尝鲜或定向验证。
在工程实现上，可以在网关层做路由，也可以在应用层做。下面是一个基于用户哈希的应用层路由示例：
import hashlib
class GrayRouter:
def __init__(self, versions, weights=None):
# versions: {"v1.0.0": 90, "v1.1.0": 10} 权重百分比
self.versions = versions
self.total = sum(versions.values())
def route(self, user_id: str) -> str:
# 对用户ID做哈希，保证同一用户始终命中同一版本
score = int(hashlib.md5(user_id.encode()).hexdigest(), 16) % self.total
cumulative = 0
for version, weight in self.versions.items():
cumulative += weight
if score < cumulative:
return version
return list(self.versions.keys())[-1]
router = GrayRouter({"v1.0.0": 90, "v1.1.0": 10})
print(router.route("user_10086")) # 稳定输出同一个版本
这段代码的要点在于哈希函数的选择。直接用Python内置的hash函数是不行的，因为每次进程重启它的种子会变化，导致用户分流结果不稳定。使用MD5或FNV等确定性哈希才能保证分流的稳定性。另外，调整权重时要意识到：一旦修改总权重比例，部分用户的归属版本会发生变化，所以灰度比例的调整应该渐进式进行，比如从1%到5%再到20%。
如果团队使用Nginx作为入口，也可以用split_clients指令实现按比例分流，配置非常简洁：
upstream model_v1 {
server 10.0.1.10:8500; # 稳定版实例
}
upstream model_v2 {
server 10.0.1.20:8500; # 灰度版实例
}
split_clients "${remote_addr}${http_user_agent}" $model_backend {
5% model_v2;
* model_v1;
}
server {
listen 80;
location /predict {
proxy_pass http://$model_backend;
}
}
基于Kubernetes的多版本部署实践
Kubernetes天然适合多版本共存部署。把每个模型版本打包成一个独立的Deployment，通过Service或Ingress的权重配置控制流量分配，就能实现一套相对完善的灰度体系。假设我们有两个版本，可以使用两个Deployment分别管理：
apiVersion: apps/v1
kind: Deployment
metadata:
name: model-serving-v1
spec:
replicas: 5
selector:
matchLabels:
app: model-serving
version: v1.0.0
template:
metadata:
labels:
app: model-serving
version: v1.0.0
spec:
containers:
- name: serving
image: registry.ipipp.com/model-serving:v1.0.0
resources:
requests: {cpu: "1", memory: 2Gi}
limits: {cpu: "2", memory: 4Gi}
readinessProbe:
httpGet: {path: /health, port: 8500}
initialDelaySeconds: 10
注意镜像地址中应替换为实际可用的仓库域名，例如registry.ipipp.com。两个版本的Deployment通过共享的app标签被同一个Service选中，Kubernetes会自动在两个版本的Pod之间负载均衡。不过原生的负载均衡是均分的，要做精确的灰度比例，推荐引入Istio或Knative这样的服务网格。以Istio为例，通过VirtualService和DestinationRule可以精确控制流量比例，还能按请求头把特定用户的请求强制路由到新版本，方便开发人员自测。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: model-serving
spec:
hosts: [model-serving]
http:
- match:
- headers:
x-gray-user:
exact: "true"
route:
- destination:
host: model-serving
subset: v2
- route:
- destination:
host: model-serving
subset: v2
weight: 10
- destination:
host: model-serving
subset: v1
weight: 90
这套配置的含义是：携带x-gray-user请求头的流量百分之百进入v2版本，其余流量按10%和90%的比例分配。灰度过程中只需修改weight字段并应用配置，几秒钟就能生效，回滚同理，把weight改回0即可，比重新部署快得多。
版本元数据管理与回滚机制
多版本部署运转起来后，版本元数据管理的重要性就凸显了。每个模型版本上线前，应该在模型注册中心登记完整的信息：版本号、训练数据集快照、超参数、离线评估指标、责任人、上线时间。推荐使用MLflow的Model Registry，它提供了版本生命周期的状态管理（如staging、production、archived），配合CI/CD流水线可以做到“只有经过审批的版本才能进入production”。
回滚机制要在设计层面保证“随时可退”。具体来说有三个实践要点：第一，旧版本的Deployment不要急着删除，至少保留最近两到三个稳定版本在线，只是把流量权重归零，这样回滚只需调整权重；第二，模型的推理结果日志必须带上版本号字段，这样监控指标才能按版本维度拆分对比；第三，预发布版本和稳定版本要共享同一套输入校验逻辑，避免因数据格式不兼容导致的隐性错误。
监控方面，灰度期间重点观察两类指标：技术指标包括接口延迟、错误率、QPS承载能力，用来确认新版本的资源开销没有异常；业务指标包括点击率、转化率、用户停留时长等，用来判断新模型是否真正带来了增益。建议按版本维度做实时聚合，当灰度版本的关键指标相对基线下跌超过阈值时，自动触发告警甚至自动回滚，把人工响应时间压缩到最短。
常见坑点与优化建议
实际落地时最容易踩的坑是分流不一致：网关按比例分流，但下游的缓存或会话黏性把请求打乱了，导致同一用户看到两个版本的交替结果。解决方法是分流逻辑只在一个层面实现，其他层面透传版本标识。另一个坑是灰度周期太短，一些业务指标有明显的周期性波动，只观察几个小时容易被噪声误导，通常建议覆盖完整的业务周期再做放量决策。
此外，模型文件通常比较大，多版本共存意味着存储和显存的成倍占用。可以在推理服务里做懒加载，只有接收到流量的版本才常驻显存，权重为零的版本只保留在磁盘上。配合HPA自动伸缩，灰度期间新版本副本数较少也能稳定扛住小流量，全量后再扩容，整体资源成本可控。灰度发布不是一次性的动作，而是应该沉淀为标准流程：每次模型迭代都走“注册、审批、灰度、观察、放量或回滚”的完整闭环，让模型更新像代码发布一样安全可预期。