想象一家永远不关门的米其林餐厅。厨房里锅铲翻飞，门口的长队从早排到晚。主厨想换一套新菜单，但他绝不能大喊一声“停！所有客人先等着，我们换菜单”——那等于把客人全赶跑。聪明的后厨会怎么做？在旁边的预备灶台上先把新菜悄悄试做一遍，反复调整火候与摆盘；确认完美后，趁传菜窗口前那一瞬间，把“今日菜单”的牌子轻轻一翻——新菜即刻生效，客人连眨眼的机会都没有，热腾腾的菜就端上桌了。这就是“热加载”的精髓。 ONNX Runtime 的模型热加载与动态版本管理，正是给 AI 推理服务的“后厨”设计的一整套换菜单仪式：新模型在后台静默预加载（预备灶台试菜），原子切换（翻菜单牌），多版本并存（保留菜谱档案柜），健康检查与自动回滚（试菜员把关），A/B 测试（让部分客人先尝新菜）。有了这套机制，线上服务可以像餐厅一样不停业、不熄火，把一个又一个新模型平稳地端上“生产”这张餐桌。

岗位关联

掌握模型热加载与版本管理，你就能在不中断服务的前提下安全地迭代模型——这正是推理平台工程师与 MLOps 工程师日常最核心的硬技能。

目录
  1. 可视化演示
  2. 热加载概念
  3. 双缓冲切换
  4. 版本路由策略
  5. 健康检查回滚
  6. A/B测试支撑
  7. 运行时实现
  8. 部署运维实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

演示ONNX Runtime模型热加载：后台预加载与原子切换零停机更新、灰度发布流量按比例路由，以及多版本监控与回滚机制，支持步进切换与参数调节。

本节配有交互动效（进入视口后自动加载，约 3KB）。

热加载流程 后台预加载新版本 load→switch→serve 原子切换实现零停机更新

热加载概念

一家生意火爆的餐厅最忌讳什么？不是菜品不好吃，而是门口挂出“暂停营业”。那意味着整条街上排队的人转身就走，可能再也不回来。主厨想换菜单，绝不能在大堂喊一嗓子“都等着，我们换个菜单”——那等于让所有客人围观自己手忙脚乱。真正专业的后厨，会在不影响出餐的前提下把新菜备好，趁客人不注意悄悄换掉。

AI 推理服务就是这家餐厅。模型需要持续迭代：数据漂移了要训练新模型，效果不佳要调参重训。但如果每次更新都走“停服→替换文件→重启进程”的老路，服务在重启窗口内会直接不可用，用户请求超时、报错、流失。“零停机更新”因此成为线上推理平台的刚需。它追求的是服务连续性：进程不重启、端口不关闭、请求不断流，模型却已经悄然变为新版本。这种在线迭代方式与“重启部署”的本质区别在于：前者把不可用时间压到趋近于零，后者则必须承担一段明显的服务真空期。

可用性（Availability）正是衡量这种连续性的经典指标。它把系统时间划分为“能服务”和“不能服务”两部分，比值决定了一个系统在用户眼里有多可靠：

热加载的本质，就是让“换菜单”不再需要“暂停营业”。把停服时间从分钟级压到毫秒级甚至零，餐厅的招牌始终亮着，客人随时推门进来都有菜吃——这正是服务连续性对 AI 业务的价值。

A=MTTFMTTF+MTTR\displaystyle A = \frac{\text{MTTF}}{\text{MTTF} + \text{MTTR}}
  1. 平均无故障时间 MTTF系统两次故障之间正常工作的平均时长，是稳定性的尺度，越长越好。
    MTTF\text{MTTF}
  2. 平均修复时间 MTTR从故障发生到服务恢复的耗时，拖得越久，可用性被侵蚀得越狠。
    MTTR\text{MTTR}
  3. 可用性 A正常服务时间在总时间中的占比。热加载把 MTTR 压到趋近于零，可视为“可用性不断提升直到无限接近 1”。
    A=MTTFMTTF+MTTRA = \frac{\text{MTTF}}{\text{MTTF} + \text{MTTR}}

双缓冲切换

新菜怎么做才能不打扰客人？答案是预备灶台。后厨角落有一口不被客人看见的灶，新菜在那里反复试做：火候、调味、摆盘，全部演练到位。等到正式开卖那一刻，主灶台的大厨只消把“今日菜单”的牌子轻轻一翻——菜谱变了，但锅里的油还在响，灶火从未熄过。

工程上，这个“预备灶台”叫双缓冲（Double Buffer）。系统同时维护两个模型实例：一个是在接客的“活动实例”（主灶台），一个是正在后台初始化的“预备实例”（预备灶台）。新模型的加载、图优化、权重初始化等耗时操作，全部在预备实例上完成，服务线程全程不参与，因此对线上零干扰。这就是后台预加载——把最费时的准备工作藏到幕后。

整个热更新过程的耗时可以拆成两段：准备工作多慢都没关系，因为它不占线上时间；真正影响请求的只有切换那一瞬：

预加载完成后，切换只需做一个原子操作——替换“当前生效实例”的引用，这是 O(1) 的指针赋值，对并发请求几乎不可感知。流量无缝转移由此实现：切换前新请求走旧实例，切换后新请求走新实例，中间没有任何“黑洞窗口”。预加载阶段还应该做资源预热：跑几个暖身请求，让 CUDA 图、内存池、线程池都热起来，避免新实例“冷启动”导致前几个请求延迟飙升。

所以客人永远看不到后厨的手忙脚乱。菜单牌一翻，新菜就热气腾腾地端上桌——因为他们不知道，这道菜早就在预备灶台上被演练了无数遍。

Thot=Tprepare+Tatomic\displaystyle T_{\text{hot}} = T_{\text{prepare}} + T_{\text{atomic}}
  1. 预加载准备时间 T_prepare新模型加载、图优化、权重初始化等耗时操作，发生在后台线程，线上请求完全不受影响。
    TprepareT_{\text{prepare}}
  2. 原子切换时间 T_atomic替换“当前生效实例”引用的耗时，通常只是一次指针赋值，在 CPU 上是单条指令级别。
    TatomicT_{\text{atomic}}
  3. 热更新总耗时 T_hot用户可感知的更新时间。由于 T_atomic 趋近于零，切换几乎是瞬间完成的。
    Thot=Tprepare+TatomicT_{\text{hot}} = T_{\text{prepare}} + T_{\text{atomic}}

版本路由策略

老顾客总惦记春季那款限定菜，后厨不会把旧菜谱烧掉，而是整整齐齐收进“菜单档案柜”。点单台的服务员手上有本今日供应册：客人点什么菜，她就翻开对应那页；如果当天有特别活动，她还会按主厨交代，给不同桌的客人送上不同版本的菜单。

模型世界也同理。线上系统往往不只跑一个模型版本：正在全量服务的 v1、正在灰度验证的 v2、备用待命的 v3。版本注册表（Registry）就是“菜单档案柜”，登记着每个版本对应的模型实例、状态与元数据。请求到达时，路由层根据版本号或权重，决定把请求分给哪个实例，这就是权重路由。

如果按权重分配流量，一次请求落到版本 v_i 的概率，等于该版本的权重占总权重之和的比例：

多版本共存是版本管理的核心能力。不同版本 session 之间状态完全隔离，互不干扰。但版本不是越多越好——每个实例都占用显存或内存，因此必须有废弃清理策略：当引用计数归零（没有在途请求还在使用它），版本就可从注册表中摘除并释放资源，就像档案柜定期清掉过期菜谱。

档案柜管理得当，餐厅才能既留住老顾客的胃，又大胆尝试新菜。版本注册与路由，给“换菜单”补上了秩序感。

P(vi)=qi∑j=1Nqj\displaystyle P(v_i) = \frac{q_i}{\sum_{j=1}^{N} q_j}
  1. 权重 q_i每个版本被赋予的流量权重，例如 v1 权重 90、v2 权重 10，表示 90% 流量走 v1。
    qiq_i
  2. 权重总和所有在册版本权重之和，将单版本权重归一化到 0 到 1 之间。
    ∑j=1Nqj\sum_{j=1}^{N} q_j
  3. 路由概率 P(v_i)一次请求落到版本 i 的概率。调整权重即可改变流量配比，无需重启服务。
    P(vi)=qi∑j=1NqjP(v_i) = \frac{q_i}{\sum_{j=1}^{N} q_j}

健康检查回滚

新菜推出当天，餐厅会安排一位试菜员蹲在后厨门边，随时尝下一道即将出餐的菜。如果连续几道菜味道不对，试菜员立刻吹哨：撤菜！把招牌菜换回来！绝不能让差评像滚雪球一样扩散到整条街。

线上模型对应的是健康探针（Health Probe）。新版本切换后，系统持续观测错误率、P99 延迟、内存占用等指标。但真实业务的指标天然带噪声——一次网络抖动、一台宿主机毛刺，都可能让指标短暂“吓人”。不能因为一次抖动就大惊小怪，所以要用平滑算法过滤噪声，业界常用 EWMA（指数加权移动平均），它像试菜员的舌头：既尝得出当下这口的味道，又不会因为一口太咸就否定整桌菜：

当平滑后的指标越过阈值（例如错误率超过 5%），系统判定新版本“不健康”，触发自动回滚：路由权重瞬间切回上一个健康版本，新实例被标记异常并隔离，不再接收新流量。这就是失败隔离——坏版本被关进“隔离包间”，不能影响其他桌客人。整个回滚路径依赖双缓冲的原子切换机制，所以回滚同样是零停机的。切换确认（冒烟测试）是最后一道关卡：切换完成后立即对关键链路发一组探针请求，确认推理结果有效，才宣告切换成功；确认失败则马上回滚。

试菜员的舌头不是摆设，而是餐厅的底线。健康探针、自动回滚与失败隔离，共同构成 AI 服务的“底线守护者”。

St=αxt+(1−α)St−1\displaystyle S_t = \alpha x_t + (1-\alpha) S_{t-1}
  1. 最新观测值 x_t当前时间窗口的错误率或延迟等原始指标，是“这一口菜的味道”。
    xtx_t
  2. 平滑系数 α对最新观测赋予的权重，α 越大，系统对最新指标越敏感，回滚反应越快。
    α,St−1\alpha, S_{t-1}
  3. EWMA 平滑值 S_t融合历史与当下后的健康指标。当 S_t 越过高阈值，判定新版本不健康。
    St=αxt+(1−α)St−1S_t = \alpha x_t + (1-\alpha) S_{t-1}

A/B测试支撑

新菜到底受不受欢迎？主厨再自信也不能拍脑袋。聪明的做法：今天 10% 的桌子送上新菜单，其余 90% 桌子照旧。把两拨客人的“光盘率”和“皱眉率”记下来，一周后算账——新菜单完胜就全量换，拉胯就立刻撤。这就是用数据做决策。

A/B 测试正是这个思路。通过版本路由策略，把一小部分生产流量分配给新模型 v2，其余流量继续走旧模型 v1，两个版本并行收集业务指标：准确率、点击率、解决率、延迟分布。要比较新旧模型的优劣，需要计算提升率（lift），它衡量新模型相对旧模型进步了多少：

A/B 测试背后是灰度发布的节奏：先 10% 流量观察，稳定后扩大到 50%，完全没问题再 100% 全量。每一步扩流都通过权重路由的配置热更新完成，不需要重启服务。观测窗口要覆盖至少一个完整业务周期（比如一整天），避免“凌晨测试数据好、白天流量大就翻车”的假象。结合健康检查机制，任何一步异常都可以中止实验并自动回滚。

菜单牌不能拍脑袋翻，要让数据先点头。流量分配、灰度扩流、指标对比——A/B 测试让“换菜单”从一门手艺变成一门科学。

lift=pnew−poldpold\displaystyle \text{lift} = \frac{p_{\text{new}} - p_{\text{old}}}{p_{\text{old}}}
  1. 旧版本指标 p_old对照组（v1）在观测窗口内的效果指标，是 baseline。
    poldp_{\text{old}}
  2. 新版本指标 p_new实验组（v2）在同样条件下的效果指标。
    pnewp_{\text{new}}
  3. 提升率 lift新版本相对旧版本的增益比例。lift 为正说明新模型值得扩大流量。
    lift=pnew−poldpold\text{lift} = \frac{p_{\text{new}} - p_{\text{old}}}{p_{\text{old}}}

运行时实现

讲了这么多仪式，具体到后厨日常怎么落地？得有一本账：哪个灶台在烧哪道菜、哪口锅预备给谁、上一道菜的锅谁来刷。落到 ONNX Runtime，这本账就是代码里的会话管理与句柄交换。

ONNX Runtime 中，加载一个模型就是创建一个 InferenceSession。会话（Session）有完整的生命周期：创建（加载 ONNX 文件、图优化、绑定执行提供方）→ 预热（跑 Run 触发 CUDA 图编译）→ 服务（持续处理 infer 请求）→ 销毁（释放显存与内存）。热加载要做的，是让“服务中”这个状态不被打断，安全地完成“销毁前一个、服务下一个”的交接。

代码上的关键设计是句柄交换：用一个受并发控制保护的引用（如原子共享指针）指向当前活动会话。推理请求先获取这个句柄，再在会话上执行 Run；切换时只在临界区内把句柄指向新会话，然后等旧会话的引用计数归零再销毁。这个设计的正确性条件可以写成：

并发兼容由此保证：切换不再需要阻塞所有请求，因为每个请求持有自己的句柄副本，旧请求跑完后自然释放。内存管理上要小心：新旧会话同时存在的那段窗口期内资源是叠加的，所以预加载新会话前要评估显存余量，必要时先淘汰最老的会话；ONNX Runtime 的 arena 策略和线程池配置也可以复用，避免重复申请。

账本记清楚，后厨就不会在高峰期手忙脚乱。从会话创建到句柄交换再到资源回收，每个环节都有序，热加载就只是一次优雅的交接班。

δ=TswitchTinflight≪1\displaystyle \delta = \frac{T_{\text{switch}}}{T_{\text{inflight}}} \ll 1
  1. 切换耗时 T_switch原子替换句柄的耗时，纳秒级，短到请求无法察觉。
    TswitchT_{\text{switch}}
  2. 在途请求生存期 T_inflight一个请求从获取句柄到完成推理的持续时间，毫秒级。
    TinflightT_{\text{inflight}}
  3. 比值 δ切换耗时与请求生存期之比远小于 1，说明切换不会打断任何正在执行的请求，并发兼容由此达成。
    δ=TswitchTinflight≪1\delta = \frac{T_{\text{switch}}}{T_{\text{inflight}}} \ll 1

部署运维实践

换菜单不能靠主厨心情，要固化成标准流程：新菜研发→试菜验收→预备灶台试做→翻牌→盯口碑。这本手册之所以厚，是因为每一步都有检查项，任何一个新人照着做都不会出错。

模型部署同样要流程化，这就是 CI/CD 集成。模型训练产出的 .onnx 文件像新菜配方一样提交到模型仓库，流水线自动触发“上新流程”：构建镜像、推送模型版本、向推理服务下发“预加载 v3”指令。发布时序是标准化的四段式：

四个阶段里，T_preload 与线上服务并行，不阻塞任何请求；T_switch 趋近于零，所以总停机时间约等于零。构建和观测阶段的监控告警是安全网：Prometheus 采集推理延迟、错误率、GPU 利用率，Grafana 可视化，告警规则与健康检查联动——指标异常时不需要人肉介入，控制面自动回滚。资源预热要纳入容量规划：新旧模型同时驻留时的峰值显存不能超过节点上限，否则会 OOM 崩掉整桌宴席。常见的做法是给预加载设定错峰窗口，或在节点上预留 20% 的资源余量。

当换菜单变成一本手册、一条流水线，餐厅就具备了每天上新菜的能力。你的 AI 服务，从此也能像呼吸一样自然地迭代。

Tdeploy=Tbuild+Tpreload+Tswitch+Tobserve\displaystyle T_{\text{deploy}} = T_{\text{build}} + T_{\text{preload}} + T_{\text{switch}} + T_{\text{observe}}
  1. 构建时间 T_buildonnx 产物打包、上传模型仓库的耗时，属于发布准备阶段。
    TbuildT_{\text{build}}
  2. 预加载时间 T_preload后台初始化并预热新会话的耗时，与线上服务完全并行。
    TpreloadT_{\text{preload}}
  3. 原子切换时间 T_switch句柄替换的耗时，趋近于零，是“菜单牌翻面”的瞬间。
    TswitchT_{\text{switch}}
  4. 观测时间 T_observe切换后确认指标稳定所需的时长，稳了才宣告发布成功。
    Tdeploy=Tbuild+Tpreload+Tswitch+TobserveT_{\text{deploy}} = T_{\text{build}} + T_{\text{preload}} + T_{\text{switch}} + T_{\text{observe}}

AI 应用场景

电商推荐模型每日热更

阶段：模型部署与上线

解决的问题：传统方式要等凌晨低峰期停机替换模型，一次更新 10 分钟，遇到大促根本不敢动；用热加载后更新在后台预加载完成，切换仅需毫秒级，全天任何时段都可以安全上新模型。

具体案例：某电商平台每天凌晨用最新用户行为数据训练推荐模型，产出 onnx 后推送到模型仓库。推理平台收到信号后自动预加载、原子切换、观察指标，全程无人工干预。早上 8 点流量高峰来临时，新模型早已稳稳服务中。

客服意图识别 A/B 测试

阶段：模型评估与灰度发布

解决的问题：直接全量上新模型风险太大，万一效果倒退，客服机器人的解决率会立刻下滑。利用权重路由把 10% 流量分给新模型，与旧模型并行对比，数据说话。

具体案例：算法团队训出新版意图识别模型后，平台把 v1 权重设为 90、v2 设为 10。观测窗口内对比两版的意图命中率与兜底转人工率，确认 lift 为正后逐步扩流到 50%、100%。每一步扩流都是配置热更新，线上零感知。

金融风控模型紧急回滚

阶段：模型监控与应急响应

解决的问题：风控模型一旦误杀率飙升，会直接阻断大量正常用户交易。健康探针 + EWMA 能在指标恶化初期就捕捉异常，自动回滚到上一版本，避免损失扩大。

具体案例：某支付平台上线新版反欺诈模型后，EWMA 平滑的错误率在 5 分钟内越过阈值。系统自动把流量切回旧版本，新版本实例被隔离标记待查。用户交易几乎无感，事后排查发现是训练数据分布偏移导致。

Python 演示

python99 行
"""ONNX Runtime 模型热加载与动态版本管理演示比喻: 餐厅后厨换菜单 - 预备灶台试菜, 翻菜单牌, 按桌号分流"""import randomimport threadingimport time  class ModelSession:    """模拟 InferenceSession: 一个版本的模型实例"""     def __init__(self, version, latency=0.005):        self.version = version        self.latency = latency        self._count = 0     def predict(self, sample):        time.sleep(self.latency)        self._count += 1        return "v%d>%s" % (self.version, sample)     def get_count(self):        return self._count  class VersionRouter:    """版本注册表 + 权重路由 + 双缓冲热切换"""     def __init__(self, initial_version=1):        self._pool = {}        self._weights = {}        self._lock = threading.Lock()        self._active = ModelSession(initial_version)        self._pool[initial_version] = self._active        self._weights[initial_version] = 1.0     def preload(self, version):        """后台预加载: 在预备灶台上试做新菜"""        with self._lock:            if version in self._pool:                return            session = ModelSession(version, latency=0.002)            session.predict("warmup")            self._pool[version] = session     def set_weight(self, version, weight):        """调整流量权重: 决定每桌客人拿哪份菜单"""        with self._lock:            self._weights[version] = weight     def activate(self, version):        """原子切换: 把菜单牌瞬间翻到新版本"""        with self._lock:            if version not in self._pool:                raise ValueError("版本 %d 未预加载" % version)            self._active = self._pool[version]            for v in list(self._weights.keys()):                if v != version:                    del self._weights[v]            self._weights[version] = 1.0     def predict(self, sample):        """按权重路由到对应版本并执行推理"""        with self._lock:            versions = list(self._weights.keys())            probs = [self._weights[v] for v in versions]            chosen = random.choices(versions, weights=probs, k=1)[0]            session = self._pool[chosen]            return session.predict(sample)     def active_version(self):        with self._lock:            return self._active.version  def main():    router = VersionRouter(initial_version=1)    print("上线 v1, 权重=1.0")    for i in range(5):        print(router.predict("req-%d" % i))     print("后台预加载 v2 ...")    router.preload(2)    print("v2 就绪, 开始 A/B: v1 占 80%, v2 占 20%")    router.set_weight(2, 0.2)    router.set_weight(1, 0.8)    for i in range(10):        print(router.predict("ab-%d" % i))     print("A/B 通过, 原子切换到 v2 ...")    router.activate(2)    assert router.active_version() == 2    for i in range(5):        print(router.predict("req-%d" % i))    print("热加载完成, 服务从未中断")  if __name__ == "__main__":    main()
目的：用约 70 行代码演示了模型热加载的核心机制——后台预加载新会话、权重路由分配流量（A/B 测试）、原子切换活动版本，全程模拟服务不中断。
  1. self._pool[version] = session新模型如同新菜在预备灶台试做完成，被登记进“菜单档案柜”。
  2. session.predict("warmup")暖身请求，让 CUDA 图、内存池热起来，避免新实例冷启动延迟。
  3. self._weights[version] = weight调权重就是告诉服务员“今天 20% 的桌子试新菜单”。
  4. self._active = self._pool[version]原子切换的核心一步：菜单牌翻面，新版本即刻生效。
  5. random.choices(versions, weights=probs, k=1)按权重路由请求，落在哪个版本由概率决定。
  6. for v in list(self._weights.keys()): if v != version: del self._weights[v]全量切换后清掉旧版本权重，实现“废弃清理”。

常见误区

误区我刚学 ONNX Runtime 时以为，把新的 .onnx 文件覆盖到旧路径，下次请求就会自动用新模型，跟更新配置文件一样。

正解覆盖文件后，内存中的旧 InferenceSession 拿的还是旧模型图。热加载必须显式创建新 session、后台预加载，再通过原子操作替换当前生效的引用。好比菜单牌翻面前，必须先有人在预备灶台把菜真正做出来——光把菜谱改一改，锅里的菜不会自己变。

为何常见：文件系统的直觉“改文件=改程序”误导了我们，但推理引擎的内存模型不是这样工作的。

误区很多人认为原子切换就像拔网线换路由器，中间总有一小段空白期，丢掉几个请求很正常。

正解双缓冲 + 句柄交换下，切换只是替换一个引用，不消耗可感知时间；旧实例会等引用计数归零才销毁，在途请求总能被新旧实例之一完整处理。请求不会丢，就像服务员换菜单时，手里的菜并不会掉在地上。

为何常见：把“进程重启的停机窗口”直觉带入了热加载，忽略了引用计数与原子替换的机制。

误区既然多版本并存没坏处，那就把所有历史版本都驻留在内存里，想切哪个切哪个。

正解每个 session 都占用显存和内存，多版本并存有硬性资源上限。工程实践通常只保留“当前版本 + 上一版本 + 灰度中的版本”，其余引用归零后立即清理。菜单档案柜可以放很多菜谱，但不能把每道菜都同时摆在灶台上。

为何常见：把版本管理理解成“留着总不亏”，忽略了硬件资源的真实约束。

误区新模型加载不报错、能跑通一次推理，就认为万事大吉，可以全量切换了。

正解加载成功只代表“能跑”，不代表“服务得好”。新模型可能精度退化、延迟飙升、内存泄漏，必须经过健康检查（错误率、延迟、冒烟测试）和观测窗口确认，才允许扩流。试菜员说“熟了”和“好吃”是两码事。

为何常见：把“能加载”与“服务得好”混为一谈，忽略了模型退化这种软性风险。

面试题

Q1. 模型热加载的核心目标是什么？

单选题 · easy

  • A.提升单次推理速度
  • B.不中断服务更新模型← 正确答案
  • C.显著减小模型体积
  • D.降低显存资源占用

答案：B。热加载追求的是服务连续性——更新模型时请求不断流。就像餐厅换菜单不能挂“暂停营业”，速度、体积、显存都不是热加载的核心目标。选 B。

Q2. 双缓冲切换中的“缓冲”指的是什么？

单选题 · easy

  • A.磁盘读写缓存区
  • B.两个模型实例交替← 正确答案
  • C.网络传输缓冲区
  • D.CPU 多级缓存层

答案：B。双缓冲指系统同时维护“活动实例”和“预备实例”，一个是正在服务的旧模型，一个是后台预加载的新模型。切换时替换引用即可。类比预备灶台与主灶台的关系。选 B。

Q3. “原子切换”在热加载中意味着什么？

单选题 · easy

  • A.切换动作不可分割← 正确答案
  • B.切换前必须重启
  • C.切换中暂停服务
  • D.切换重复尝试多次

答案：A。原子切换指替换“当前生效实例”引用的操作对并发请求不可分割，如同菜单牌的一翻，瞬间完成且没有中间态。重启或暂停都与“零停机”背道而驰。选 A。

Q4. 后台预加载新模型时，旧模型应该如何处理？

单选题 · mid

  • A.立即释放内存空间
  • B.继续服务到切换完成← 正确答案
  • C.暂停推理等待切换
  • D.重新编译全新模型

答案：B。新旧模型在切换窗口内并存：新模型在后台预热，旧模型继续处理请求，直到原子切换后引用计数归零才释放。就像新菜在预备灶台试做时，主灶台一刻不停。选 B。

Q5. 版本路由概率的计算依赖于什么？

单选题 · mid

  • A.各版本模型精度
  • B.分发的流量权重← 正确答案
  • C.传入请求的体积
  • D.模型训练的轮数

答案：B。P(v_i) = q_i / Σq_j，路由概率只由权重决定。调权重就改变流量配比，是 A/B 测试和灰度发布的基础。模型精度、请求体积、训练轮数都不参与路由计算。选 B。

Q6. EWMA 公式中平滑系数 α 越大，表示什么？

单选题 · mid

  • A.指标越平滑稳定
  • B.越看重最新观测← 正确答案
  • C.历史数据权重越高
  • D.回滚速度越缓慢

答案：B。S_t = αx_t + (1-α)S_{t-1}，α 是对最新观测 x_t 的权重。α 越大，系统对最新指标越敏感，发现异常后回滚反应越快，但也会放大噪声。选 B。

Q7. 以下哪些场景适合使用模型热加载？

多选题 · mid

  • A.持续交付新迭代← 正确答案
  • B.A/B 灰度测试← 正确答案
  • C.离线批量训练
  • D.灰度发布新版本← 正确答案

答案：ABD。热加载服务于在线推理场景：持续交付（A）、A/B 测试（B）、灰度发布（D）都需要不中断地切换或分流模型。离线训练（C）不涉及线上服务，不需要热加载。选 A、B、D。

Q8. 新模型切换后指标异常，正确的处理方式是？

单选题 · hard

  • A.忽略异常继续运行
  • B.健康检查自动回滚← 正确答案
  • C.清理删除旧模型
  • D.立即重启全部服务

答案：B。健康探针通过 EWMA 平滑指标，越阈值后自动回滚到上一健康版本，并隔离异常实例。删除旧模型和重启服务都违背了热加载的零停机原则。选 B。

Q9. 热加载切换开销包含以下哪些部分？

多选题 · hard

  • A.模型预加载耗时← 正确答案
  • B.原子替换引用耗时← 正确答案
  • C.离线训练阶段耗时
  • D.在途请求的处理耗时

答案：AB。热更新总耗时 T_hot = T_prepare + T_atomic，即预加载耗时（A）与原子替换耗时（B）。训练（C）发生在发布之前，在途请求处理（D）是正常服务时间，都不属于切换开销。选 A、B。

Q10. 高并发下热加载的正确性主要依赖什么机制？

单选题 · extreme

  • A.新旧实例并行存续← 正确答案
  • B.立即强杀旧实例
  • C.加锁阻塞全部请求
  • D.重启全部工作节点

答案：A。切换后旧实例不立即销毁，而是等引用计数归零（在途请求全部完成）才释放，新旧实例并行存续保证请求不丢。强杀旧实例会中断在途请求，加锁阻塞与重启则破坏零停机。选 A。