在机器学习平台向生产环境交付推理能力时，模型迭代频繁且效果存在不确定性。Kubernetes 凭借弹性调度和声明式管理，成为部署推理服务的主流载体。但当新模型准备上线，直接替换全部 Pod 会让潜在风险毫无缓冲地暴露给全量用户。灰度发布与 A/B 测试正是用来解决这一矛盾的手段，它们允许新旧推理服务在集群内并存，并按预定策略分配流量，从而用真实请求验证模型表现。
基于服务网格的流量切分原理
在 Kubernetes 中，原生 Service 只能做简单的负载均衡，无法按百分比将请求转发到不同版本的工作负载。要解决这个问题，通常会引入 Istio 这类服务网格。Istio 通过虚拟服务（VirtualService）和目标规则（DestinationRule）将流量治理从应用代码中剥离。推理服务只需正常注册为 Deployment，网格侧根据路由规则把一定比例的请求送往新版本推理 Pod，其余继续访问旧版本。
具体实现时，我们首先用 DestinationRule 定义 subset，把带有 version: v1 和 version: v2 标签的 Pod 分别归类。随后在 VirtualService 中配置权重，例如 v1 占九十，v2 占十。这样外部调用方无感知，而系统已经在用百分之十的真实流量测试新模型。下面给出一段典型的 Istio 路由配置示例，展示如何对推理服务做灰度权重切分。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: infer-svc-dr
spec:
host: infer-service
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: infer-svc-vs
spec:
hosts:
- infer-service
http:
- route:
- destination:
host: infer-service
subset: v1
weight: 90
- destination:
host: infer-service
subset: v2
weight: 10
这种方式的优势在于业务容器不需要任何改造，流量控制完全在基础设施层完成。缺点是需要运维额外的控制平面，并且指标追踪必须打通，否则无法判断新版本推理延迟和准确率是否符合预期。在实践中，我们还会给 v2 配置独立的资源配额，防止其突发消耗影响 v1 的承载能力。
应用层 A/B 测试与请求特征路由
灰度发布侧重按比例放量，而 A/B 测试更强调按请求特征分组。例如我们希望把来自特定用户群或携带特定 HTTP 头的请求固定路由到新推理模型，以对比不同模型的业务指标。此时可以继续使用服务网格，在 VirtualService 中匹配请求头或路径前缀，将匹配流量全部导向 v2，其余维持旧版本。
除了网格方案，轻量场景也可以在推理网关或自定义代理中写分流逻辑。比如网关读取请求中的 user_id，对其取模后决定转发目标。这样做不依赖复杂组件，但分流代码和模型服务耦合更紧。以下示例展示用 Python 在网关层做简单 A/B 分发的思路，根据请求头 x-exp-group 选择不同后端地址。
from flask import Flask, request
import requests
app = Flask(__name__)
V1_URL = "http://infer-v1:8000/predict"
V2_URL = "http://infer-v2:8000/predict"
@app.route("/predict", methods=["POST"])
def predict():
group = request.headers.get("x-exp-group", "control")
data = request.get_json()
if group == "treatment":
resp = requests.post(V2_URL, json=data)
else:
resp = requests.post(V1_URL, json=data)
return resp.json(), resp.status_code
应用层方案灵活度高，能快速接入业务埋点，但要求开发者自己保证转发的一致性和超时控制。若实验组用户被偶然路由到旧版本，A/B 结论就会失真。因此在生产里常把网格路由作为统一入口，应用层只负责补充业务参数，不直接承担核心分流职责。
指标评估与灰度回收策略
无论采用哪种分流方式，推理服务的灰度都必须配套指标回收。我们需要同时收集新旧版本的每秒请求数、P99 延迟、错误率以及模型特有的预测偏移度。Prometheus 配合自定义 exporter 可以拉取推理容器的业务指标，再用 Grafana 分面板对照。只有在新版本关键指标稳定优于或持平旧版本时，才逐步调高其流量权重。
当 A/B 测试达到显著性水平，就要执行回收操作。若是灰度成功，通过修改 VirtualService 权重将 v1 降为零并删除旧 Deployment；若新模型不及预期，则回退权重并保留旧版本。注意删除 Pod 前要先摘流，避免正在处理的推理请求被中断。下面的表格对比了两种实验的回收关注点。
| 实验类型 | 放量方式 | 回收判断依据 |
|---|---|---|
| 灰度发布 | 按权重逐步增加 | 延迟与错误率无劣化 |
| A/B 测试 | 按特征固定分组 | 业务指标显著提升 |
此外，推理服务常使用 GPU 资源，灰度期间双倍实例会带来成本压力。可以通过配置 Pod 优先级和弹性伸缩，在实验结束后快速缩容旧版本。整体来看，Kubernetes 结合流量治理与指标系统，能让推理模型上线从盲目替换演进为可控实验，既保障稳定性也提升迭代效率。
Kubernetes推理服务灰度发布修改时间：2026-08-18 22:36:31