当网关在自动切换模型时遇到显存不足，需要先区分“进程可用显存不足”和“卡上剩余显存不足”。前者会直接抛 OOM，后者会随着请求排队逐渐暴露。触发热迁移的条件不只是设一条水位线，而是一组由探测信号、持续时间和低风险迁移路径组成的规则。下面给出可执行的条件配置思路和验证方法。

判断：显存不足触发热迁移，不应只由单一阈值驱动。建议由运行时健康指标 + 持续时间 + 迁移目标预检三部分构成，并把“切换请求”作为默认动作，“进程级热迁移”作为后备动作。开启前必须配置冷却窗口和失败回滚，否则会出现迁移风暴。

先定义“显存不足”的可观测信号

网关要拿到可直接判断的信号，而不是靠猜测。通常可以取三类：GPU 显存利用率（如 nvidia-smi 的 used/total）、推理服务自身的 OOM 错误计数、以及网关已经捕获的请求失败率或排队长度。建议把“显存剩余低于阈值”和“持续一定时间”同时作为触发条件，避免把瞬时波动当成故障。

trigger:
  - metric: gpu_mem_free_ratio
    below: 0.05
    for: 30s
    on_error: cuda_oom
    action: migrate

这里的名字是示意，需要根据网关实际支持的指标表达式改写。验证这个方法：在测试环境里用一个超长 prompt 或大 batch 把显存占满，观察网关是否只在持续时间满足后才动作。风险边界是不要把阈值设到接近 0，否则从信号发出到迁移完成前，已有请求会持续失败。

把“自动切换模型”和“热迁移”拆开配置

网关上最常见的自动切换其实分两步：先把新请求路由到备用节点，再对存量请求做进程级迁移。两步的条件要分开写。切换新请求的条件是目标节点有足够剩余显存；迁移存量请求的条件是目标节点已确认能加载该模型，并且当前节点没有正在进行的迁移。

if current_node.gpu_mem_free < limit:
    if no_ongoing_migration and target_node.model_ready:
        switch_registry = target_node
        start_async_migrate(current_node, target_node)
    else:
        return "backoff"

这个伪代码可以直接映射到网关规则引擎里。实际部署中，可以用一个健康检查接口或模型预热接口来提供 model_ready 状态。注意：如果只切换请求而不迁移存量连接，调用方只能感知到部分新请求成功，所以需要明确“迁移完成”的判定标准，例如目标节点处理了第一个请求。

防抖动与回滚条件

热迁移一旦失败，不能原地重试到拖垮整个网关。建议配置三项：最小迁移间隔、最大尝试次数、回滚条件。回滚条件通常用目标节点的显存余量来表示，也可以用目标节点在迁移过程中的错误率。

migration_policy:
  min_interval: 300s
  max_attempts: 3
  rollback_on: target_node.gpu_mem_free < 0.1

冷却时间过短会频繁迁移，导致请求毛刺；过长会让故障持续更久。回滚触达后，网关应回到上一可用状态，并记录一次失败事件。验证方式：人为在目标节点上加载一个大模型占满显存，再触发迁移，确认按配置取消迁移而不是硬切。

验证清单

• 用高并发或大请求占满显存，确认服务报 OOM 还是缓慢拒绝，先明确故障特征。
• 观察网关状态接口中的显存指标是否持续更新，确认数据源有效。
• 人为占用目标节点显存，验证迁移条件被拒绝。
• 关闭目标节点，验证超时回滚，而不是一直等待。
• 迁移完成后，发送新请求并确认由目标节点处理。

这些步骤只能在测试环境里先跑通。生产环境要把上述条件结合你的网关日志、指标采集间隔和模型加载耗时再做调整。