模型的A/B测试与金丝雀部署

将优化后的模型制品直接部署到生产环境是一项高风险操作，可能危害系统稳定性和业务成果。虽然标准的软件部署可能依靠简单的滚动更新，但模型引入了统计和性能上的不确定性，需要更受控的方式。新的模型版本，即使在离线验证中表现良好，也可能展现出更高的延迟，在实时数据上产生意外的预测分布，或者对面向用户的业务指标造成负面影响。因此，安全部署策略并非可有可无，它们是生产MLOps的基本构成部分。

本节侧重于机器学习 (machine learning)模型的两种主要渐进式交付技术：A/B测试和金丝雀部署。我们将研究如何使用服务网格实现这些模式，以精确控制流量，从而帮助您在全面推广模型更新之前，降低风险并验证其在真实用户环境中的性能。

区分A/B测试与金丝雀部署

尽管A/B测试和金丝雀部署都涉及同时运行多个模型版本，但它们的目标有所不同。

• A/B测试 是一种在线实验技术，用于根据具体的业务指标比较两个或多个模型版本的性能。例如，您可能会测试一个新的推荐模型（版本B）与当前的生产模型（版本A），以查看哪个能产生更高的点击率。流量通常在预定持续时间内进行分割，并通过统计分析结果来选择一个优胜者。

• 金丝雀部署 是一种风险缓解策略，侧重于安全地验证新模型版本的稳定性。新模型（即“金丝雀”）最初只接收一小部分生产流量（例如1%或5%）。系统级指标，如延迟和错误率，会受到严密监控。如果金丝雀按预期执行，其流量份额将逐步增加，直到处理100%的请求。如果出现问题，流量会立即路由回稳定版本，从而最大限度地减少对用户的影响。

简而言之，您使用金丝雀部署来确保新模型不会破坏现有功能，而使用A/B测试来证明新模型可量化 (quantization)地更好。这些策略也可以结合使用；新模型可能首先经过一个短暂的金丝雀阶段来验证其技术稳定性，然后进行更长的A/B测试以衡量其业务影响。

使用服务网格实现流量管理

管理这些部署模式的网络流量需要一个复杂的路由层。直接在您的应用程序代码或模型服务器中实现此逻辑既脆弱又复杂。一个更有效的方法是使用Istio或Linkerd等服务网格。

服务网格作为一个专用基础设施层运行，它拦截并控制微服务之间的所有网络通信。它将流量管理与您的应用程序解耦，使您能够使用Kubernetes自定义资源以声明方式定义复杂的路由规则。

金丝雀部署的流量拆分

对于金丝雀部署，最常见的技术是基于权重 (weight)的路由。使用Istio VirtualService，您可以指定应导向每个模型版本的流量百分比。

设想一个场景，我们有两个Kubernetes Deployments来提供模型服务：model-v1（稳定版本）和model-v2（金丝雀）。以下VirtualService配置将95%的流量导向v1，5%导向v2。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: model-serving-vs
spec:
  hosts:
  - model-inference.production.svc.cluster.local
  http:
  - route:
    - destination:
        host: model-inference-v1
        subset: v1
      weight: 95
    - destination:
        host: model-inference-v2
        subset: v2
      weight: 5

为了推进金丝雀部署，您只需更新此配置中的weight字段，例如，先更新为80/20，然后是50/50，最后是0/100，这个过程可以自动化，我们稍后会看到。

四阶段金丝雀发布中的典型流量分配。随着对其稳定性的信心增强，新版本的流量份额会增加。

用于A/B测试和暗启动的基于请求头的路由

对于A/B测试或内部“暗启动”，您可能需要更细粒度的控制。例如，您可能希望将内部QA团队的所有请求路由到新模型，而所有其他用户则继续使用旧模型。这可以通过基于内容的路由实现，具体来说是匹配HTTP请求头。

以下VirtualService将包含请求头x-user-group: internal-testers的任何请求路由到model-v2，而所有其他流量都流向model-v1。这允许进行有针对性的测试，而不影响普通用户群。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: model-serving-dark-launch
spec:
  hosts:
  - model-inference.production.svc.cluster.local
  http:
  - match:
    - headers:
        x-user-group:
          exact: internal-testers
    route:
    - destination:
        host: model-inference-v2
        subset: v2
  - route:
    - destination:
        host: model-inference-v1
        subset: v1

这种模式对于A/B测试也非常有价值。您可以在应用层将用户分配到实验组（例如group-a或group-b），添加相应的请求头，然后使用服务网格将他们路由到正确的模型版本。

基于指标分析的自动化发布

手动调整流量权重 (weight)和监控仪表盘既繁琐又容易出错。这种架构的真正能力通过自动化得以实现。

Argo Rollouts或Flagger等渐进式交付控制器与服务网格（Istio）以及您的监控系统（例如Prometheus）集成，以创建自动化、闭环的部署流程。

该流程如下：

1. 部署： 新模型版本作为金丝雀部署。
2. 转移流量： 控制器指示服务网格将一小部分流量路由到金丝雀。
3. 测量： 控制器对Prometheus运行一系列自动化查询，以在定义的分析周期内检查重要的服务级别指标（SLI）。这些检查通常包括：
   • 延迟： $p99$ 延迟是否低于SLO（例如，$p99 < 150ms$）？
   • 错误率： HTTP 5xx 服务器错误率是否低于阈值（例如，$< 0.1$）？
   • 业务指标： 在更高级的设置中，它甚至可以查询自定义指标，如平均预测分数，以检查模型特有的性能退化。
4. 决定： 基于分析结果，控制器做出决定。
   • 推广： 如果所有指标都在其阈值内，控制器会增加导向金丝雀的流量权重，并重复分析。
   • 回滚： 如果任何指标未能通过检查，控制器会立即将所有流量移回稳定版本，并标记 (token)发布失败。

这种自动化反馈循环确保有问题的模型版本被自动隔离并回滚，通常在人工操作员注意到问题之前。

自动化金丝雀部署工作流。控制器转移流量，分析来自Prometheus等提供商的指标，并在失败时推广新版本或自动回滚。

通过将这些安全部署实践集成到您的MLOps流水线中，您可以将模型部署从高风险、手动事件转变为例行化、自动化、低风险的流程。这使您的团队能够更快速、更自信地迭代模型，向用户交付改进，同时不损害生产服务的稳定性和性能。