模型A/B部署的工程化实现方案

可视化演示

交互展示模型A/B部署的工程化实现：流量切分、请求镜像、监控对比和自动切换机制。

AB测试部署概览

假设你是一家餐厅的运营负责人，正面临“要不要把招牌菜换成新配方”的抉择。你心里清楚：数据不会说谎，但拍脑袋会。于是你定下规矩——用真实顾客的反应来做决定。你要先想清楚三个问题：想验证什么（新配方是不是更好吃）、在什么场景验证（哪些菜可以冒险）、怎么验证（让多少人试吃）。这就是 A/B 部署的起点。在机器学习世界里，模型 A 是当前线上稳定运行的“老配方”，模型 B 是你的候选“新配方”，A/B 部署的目标就是在真实请求流量中，为两个模型搭建一个公平的“试吃擂台”。

从工程视角看，A/B 部署不是简单的“两个服务都跑起来”，而是一套完整流程：切流（把部分请求引给 B）、镜像（复刻请求给 B 练手）、收集（记录两边表现）、监控（盯住别出事）、切换（用数据拍板）。常见的部署模式有两种：影子模式（shadow mode）指 B 只接收镜像流量，结果不对外返回，相当于后厨试做、不端上桌；金丝雀模式（canary）指 B 真实承接一小部分线上流量，相当于真让一小桌客人尝新菜。两种模式可以衔接使用：先影子热身，再金丝雀小范围试吃。

无论哪种模式，都必须守住一条铁律：切给 A 和 B 的流量加起来要等于总流量。一个请求要么去 A 要么去 B，绝不能“凭空蒸发”或“两边都算”。

$$T = T_A + T_B$$

1. 总流量 T：单位时间内进入系统的全部线上请求数，是整个实验的“分母”，相当于餐厅当天接待的全部顾客。

$$T = T_A + T_B$$

2. A 版本流量 T_A：被切分到旧模型 A 的请求量，继续服务绝大多数熟客。

$$T_A = p_A \times T$$

3. B 版本流量 T_B：切给新模型 B 的请求量，在真实压力下接受检验。

$$T_B = p_B \times T$$

4. 守恒约束：二者之和必须等于总流量，任何“凭空消失”的请求都意味着切分逻辑有 bug。

$$p_A + p_B = 1$$

回到餐厅的比喻：你定下“七成老配方、三成新配方”的规矩后，服务员就要保证每一位进门的顾客都能吃到菜，且只吃一种配方。流量守恒，是这场试吃实验的底线。

基础设施搭建

要给新配方红烧肉试吃，光有配方不够，你得先保证后厨能同时开工：老灶台不停火，新灶台也架起来，两套锅碗瓢盆不能互相污染。在 MLOps 里，这叫基础设施搭建——让 A、B 两个模型版本在同一套服务架构里“和平共处”。

首先是服务架构。A 和 B 通常是同一个服务进程的两个不同版本，它们共享上层的 API 网关和下游的数据库，但模型推理部分各自独立。其次是服务注册发现：A 和 B 启动后都要到注册中心“签到”（比如 Consul、Nacos），网关才能知道此刻有哪些版本可用、各自的地址是什么。第三是配置管理：切流比例、镜像采样率这类参数不能写死在代码里，而要放到配置中心（比如 Apollo），改配置就能动态调权重，就像餐厅改菜单上的供应比例，不用重新装修厨房。

还需要环境隔离。新模型可能是实验性代码，它读的配置、写的日志、占用的资源，都不能和老版本纠缠不清。工程上通常用独立的命名空间、独立的日志目录、独立的指标上报通道来隔离。否则一旦 B 模型写坏了共享的状态，A 模型会被无辜连累——这就像新厨师的备用锅，绝不能和主厨的锅混着刷。

基础设施稳不稳，有一个硬指标：可用性。所谓可用性，就是系统在统计周期内“正常营业”的时间占比，可用性越高，顾客吃闭门羹的概率越低。

$$A = 1 - \frac{D}{T}$$

1. 总时间 T：统计周期内承诺提供服务的时间长度，可以是一天、一月或一年。

$$T = \text{统计周期}$$

2. 故障时长 D：服务不可用（宕机、超时、拒绝服务）的累计时间。

$$D = \sum \text{故障时间片段}$$

3. 可用性 A：1 减去故障占比，得到“正常营业”的比例。

$$A = 1 - \frac{D}{T}$$

4. SLA 目标：A = 0.999 表示 99.9% 可用，一年最多允许约 8.76 小时宕机。

$$A \geq 0.999$$

基础设施就像后厨的灶台和管道，顾客看不到，但一旦漏水全店遭殃。把 A、B 两个版本的注册、配置、隔离做好，你的“双灶台”才能稳稳支撑后面的切流实验。

流量切分路由

试吃规则定好了，接下来服务员要面临一个实际问题：怎么把客人引到两个窗口？流量切分，就是模型 A/B 部署里最关键的“领位员”。它决定了哪些请求去 A、哪些去 B，以及各自占比多少。

切分方式有三类。第一类是按权重随机：每个请求来的时候，生成一个随机数，比如小于 0.7 去 A，否则去 B，最终比例会在大数定律下收敛到 70/30。这种方式最简单，但同一个用户两次请求可能被分到不同版本，体验不一致。第二类是按用户维度路由：以用户 ID 的哈希值做切分，保证同一个用户始终被分到同一版本，避免用户“上一秒吃新配方、下一秒吃老配方”的错乱感。第三类是按规则路由：比如只切分白名单用户、只切分特定地域的请求、只切分 1% 的边缘流量，用于小范围灰度验证。

具体实现时，最常用的技术是一致性哈希。它把用户 ID 映射到一个哈希环上，A 和 B 各占据环上的一段弧，请求落在哪段就路由到哪个版本。这样当你要调整切分比例时，只需要移动环上的节点位置，绝大多数用户的归属不会变化，只有边界上的少量用户会被“搬移”。权重策略的本质，是把每个版本配置的“权重值”换算成真正的流量比例：

$$P_i = \frac{w_i}{\sum_{j=1}^{n} w_j}$$

1. 版本序号 i：当前要计算比例的版本，比如 A 或 B。

$$i \in \{A, B\}$$

2. 权重 w_i：每个版本配置的流量权值，相当于后厨给新窗口安排的服务员人数。

$$w_A = 7, \quad w_B = 3$$

3. 权重总和：所有版本权值相加，得到分母。

$$\sum_{j=1}^{n} w_j = w_A + w_B$$

4. 归一化概率：权值除以总和，得到真正的流量比例。

$$P_A = \frac{7}{10} = 0.7, \quad P_B = \frac{3}{10} = 0.3$$

回到餐厅：权重随机就像门口随机发号，哈希路由就像按桌号固定窗口，规则路由就像“只让会员试新菜”。无论用哪种方式，核心原则都是——让两边承接的流量既真实、又可解释、还能随时调整。

请求镜像复制

试吃还有一个更稳的玩法：与其让真客人冒险吃新配方，不如在老配方的每一道菜上桌之前，顺手多盛一小勺端给新后厨试做。新后厨做完不端给顾客，只是自己练手并且记录“如果是我做，我会做成什么样”。这就是请求镜像（request mirroring）——把真实请求复制一份发给模型 B，B 的结果只用于评估，不返回给用户。

镜像原理很简单：网关收到请求后，除了正常转发给 A，再异步复制一份同样的请求发给 B。对用户来说，线上响应完全由 A 决定，体验不受任何影响；对 B 来说，它却在拿最真实的生产数据练兵。流量复制有两种实现：一种是在网关层旁路复制（比如 Nginx mirror、Envoy shadow），另一种是在服务内部订阅消息队列里的请求流，把符合条件的请求再投递一份给 B。

采样策略决定复制多少：不是所有请求都要镜像，否则 B 后厨会累垮。采样率就是“每几个请求复制一个”：

$$r = \frac{N_m}{N_t}$$

1. 镜像请求数 N_m：复制出来发给模型 B 的请求份数。

$$N_m = \text{被复制的请求数量}$$

2. 总请求数 N_t：进入系统的全部真实请求数。

$$N_t = \text{全部线上请求数量}$$

3. 采样率 r：二者相除，得到复制的比例。

$$r = \frac{N_m}{N_t}$$

4. 取值含义：r = 1 表示全部复制，r = 0.2 表示每 5 个请求复制 1 个。

$$r = 0.2 \Rightarrow N_m = 0.2 \times N_t$$

镜像请求也要注意数据隔离：镜像产生的推理日志、指标数据要打上独立的标记（比如 is_mirror=true），不能被当成真实流量统计，否则会把 A/B 的结果比较搅浑。这就像试做菜的记录要单独记在一本小本子上，不能混进顾客的结账单里。请求镜像的价值，在于让 B 模型零风险地接触真实数据分布，在正式上场前先摸清敌人火力。

结果收集分析

试吃搞了几天，你必须回答一个问题：新配方到底赢没赢？这就靠意见反馈系统了。你得在顾客吃完后收集反馈：给了多少小费、有没有加菜、有没有皱眉。对应到模型部署里，就是结果收集与指标分析，它是整个 A/B 实验的“记账本”。

埋点设计是第一步。每个请求从进入系统到返回结果，都要记录三段信息：版本标识（这个请求由 A 还是 B 处理）、请求上下文（用户 ID、请求参数、耗时）、业务结果（是否下单、是否点击、是否转化）。这些数据通常通过日志或消息队列（Kafka）上报，再落入数据仓库。指标定义要提早想清楚，常见的线上指标有：响应延迟 P99、错误率、QPS，以及业务侧的转化率、点击率、成单率。业务指标才是最终裁判——模型再准，如果用户不买账也白搭。

数据收集上来后，要通过聚合计算得到可比较的结论。最常用的指标是提升度（lift）：它衡量 B 相对 A 的效果增幅。比如 A 的转化率是 5%，B 是 6%，提升度就是 20%。

$$\text{lift} = \frac{p_B - p_A}{p_A}$$

1. 转化率 p_A：A 版本处理请求后产生业务转化的比例，是实验的基线。

$$p_A = \frac{\text{A 版本转化次数}}{\text{A 版本请求总数}}$$

2. 转化率 p_B：B 版本同样口径下的转化比例。

$$p_B = \frac{\text{B 版本转化次数}}{\text{B 版本请求总数}}$$

3. 分子差值：B 减去 A，得到绝对增幅。

$$p_B - p_A$$

4. 相对提升度：差值除以基线 p_A，得到相对增幅，便于对比不同基线下的实验。

$$\text{lift} = \frac{p_B - p_A}{p_A}$$

最后是存储与检索：指标要按时间维度聚合，画成趋势曲线，让工程师一眼看出 B 是否稳定优于 A。这就像餐厅把每天的试吃意见卡录入系统，按天、按周、按窗口维度对比。结果收集做得越细，后续的“切换决策”就越有底气——数据从来不会骗人，前提是你真的把它记下来了。

部署监控告警

新配方试吃进入第二周，你不可能 24 小时守在店里盯着每一位客人的表情，你需要一套监控系统替你盯着：后厨有没有起火、出菜有没有变慢、顾客有没有掀桌。部署监控，就是 A/B 实验里“不眨眼的值守人”。

健康检查是最基础的一层：每隔几秒对 A、B 两个服务发送探活请求（比如 HTTP /health 接口），检查进程是否存活、依赖的数据库是否连得上。如果 B 挂了，网关要自动把它从路由候选里摘除，避免把流量打进黑洞。性能监控则关注更细的指标：响应延迟的 P50/P95/P99、QPS 变化、内存与 GPU 利用率。B 模型如果推理特别慢，即使效果再好也不能全量上——就像新菜再好吃，出菜要等一小时，客人也会掀桌。

阈值告警是监控的“警报器”。每个指标都要设上下限，比如错误率超过 5% 立即告警、P99 延迟超过 800ms 立即告警。告警一旦触发，值班工程师的钉钉、电话就会被轰炸。错误率是其中最敏感的指标：

$$E = \frac{F}{T}$$

1. 失败请求数 F：返回 5xx 错误、超时或异常的结果数量。

$$F = \text{错误响应请求数}$$

2. 总请求数 T：监控周期内进入服务（或某个版本）的全部请求数。

$$T = \text{监控周期内请求总数}$$

3. 错误率 E：失败请求占总请求的比例。

$$E = \frac{F}{T}$$

4. 告警阈值：E 超过阈值（如 0.05）触发告警，此时应暂停向该版本切流量。

$$E > 0.05 \Rightarrow \text{触发告警}$$

最后把所有指标汇聚到可视化面板（如 Grafana），A、B 两组数据并排展示，切换比例的旋钮旁边就是实时健康状态。这就像餐厅主管的巡店平板：大厅翻台率、后厨出菜速度、顾客差评数一目了然。监控不是给人看的，是给“决策”看的——没有监控的 A/B 实验，等于蒙着眼睛过马路。

自动切换回滚

试吃一个月，数据终于说话了。现在你要做最后一步决策：新配方能不能全面上线？自动切换机制，就是那个“敢拍板、又能反悔”的餐厅总经理。

评估决策不能只看 lift 是正数就切，还要看样本量够不够、指标是否显著、B 的错误率和延迟是否达标。工程上通常设定一组条件，全部满足才允许切换：提升度超过某个阈值 θ、错误率低于安全上限、延迟不劣化。如果有任何一条不满足，就继续保持灰度，或直接回滚。

自动切换是指通过控制面（配置中心）一键修改路由权重，将 B 的流量从 30% 逐步放大到 50%、80%、100%。这个过程叫灰度发布：每次放量后停留一段时间，观察监控面板，确认安全后再继续放量。最后一步是快速回滚：上线后如果发现问题，必须能在几分钟内把流量全部切回 A。这要求旧版本始终保活——A 的服务节点不能因为 B 全量上线就被立刻销毁，至少要保留足够算力兜底。切换的决策逻辑可以写成：

$$S = (\text{lift} > \theta) \wedge (E_B < E_{th})$$

1. 提升度条件：B 相对 A 的提升度必须显著超过设定的门槛 θ（如 θ = 0.1）。

$$\text{lift} > \theta$$

2. 错误率条件：B 版本自身的错误率必须低于可接受的安全上限 E_th。

$$E_B < E_{th}$$

3. 逻辑与操作：两个条件用逻辑与（∧）连接，缺一不可。

$$S = (\text{条件一}) \wedge (\text{条件二})$$

4. 决策结果：S = 1 表示可以全量切换，S = 0 表示继续灰度或回滚。

$$S \in \{0, 1\}$$

回到餐厅：新菜连续一个月好评率碾压老配方、而且后厨没出过任何差错，你才敢把菜单全面换新；换新后如果有三位客人同时投诉，你立刻翻出老配方重新开火。自动切换的本质不是“相信新模型”，而是“留好退路”。能随时回滚的上线，才是真正安全的发布。

AI 应用场景

Python 演示

"""Model A/B deploy demo: traffic split, request mirror, result collect."""import random  class ABDeploy:    """Simulate an online A/B deployment service."""     def __init__(self, weight_a=0.7, mirror_rate=0.3):        self.weight_a = weight_a        self.mirror_rate = mirror_rate        self.count_a = 0        self.count_b = 0        self.mirror_count = 0        self.latency_list_a = []        self.latency_list_b = []        self.error_count = 0        self.total = 0     def receive_request(self, latency_a, latency_b):        """Receive one request and route it by weight, then mirror."""        self.total += 1        if random.random() < self.weight_a:            # route to version A            self.count_a += 1            self.latency_list_a.append(latency_a)            # mirror a copy to version B with sampling rate            if random.random() < self.mirror_rate:                self.latency_list_b.append(latency_b)                self.mirror_count += 1        else:            # route to version B            self.count_b += 1            self.latency_list_b.append(latency_b)        # simulate small error probability for monitoring        if random.random() < 0.01 and self.total > 0:            self.error_count += 1     def collect_result(self):        """Aggregate metrics from A and B for decision making."""        avg = lambda xs: sum(xs) / len(xs) if xs else 0.0        return {            "traffic_a": self.count_a,            "traffic_b": self.count_b,            "mirror_count": self.mirror_count,            "latency_a": round(avg(self.latency_list_a), 4),            "latency_b": round(avg(self.latency_list_b), 4),            "error_rate_a": round(self.error_count / max(self.total, 1), 4),        }  def main():    deploy = ABDeploy(weight_a=0.7, mirror_rate=0.3)    for _ in range(2000):        # B model is assumed faster: latency_b < latency_a        deploy.receive_request(latency_a=0.15, latency_b=0.10)    result = deploy.collect_result()    for key, value in result.items():        print("{}: {}".format(key, value))    if result["latency_b"] < result["latency_a"]:        print("decision: B latency is lower, expand B traffic")  if __name__ == "__main__":    main()

1. def __init__(self, weight_a=0.7, mirror_rate=0.3):初始化时配置 A 的流量权重和镜像采样率，这是部署的“旋钮”。
2. if random.random() < self.weight_a:流量切分的核心逻辑：随机数小于权重就去 A，否则去 B。
3. self.count_a += 1版本 A 的请求计数器，对应结果收集中的“版本标识”。
4. if random.random() < self.mirror_rate:请求镜像：按采样率把 A 的请求复制一份给 B。
5. self.mirror_count += 1统计镜像请求数量，用于评估镜像带来的算力开销。
6. avg = lambda xs: sum(xs) / len(xs) if xs else 0.0聚合计算平均延迟，对应监控中的性能指标。
7. "error_rate_a": round(...)错误率指标，用于触发告警和切换决策。
8. if result["latency_b"] < result["latency_a"]:评估决策环节：用收集到的结果判断是否扩大新版本流量。

常见误区

面试题