蓝绿切换前不预热算力池，新版本推理服务大概率会在切流后出现高延迟和超时，正确的做法是先让新服务用镜像流量或合成请求跑满一个预热周期，待显存、缓存和动态批处理都进入稳态再切真实流量。
推理服务蓝绿切换为什么绕不开算力预热
蓝绿切换的逻辑很简单：绿环境还在跑老流量，蓝环境部署新版本，问题在于，很多团队把"部署"等同于"启动进程"，容器起来了，端口通了，健康检查返回200了，就认为新环境准备好了，于是直接切流量，结果第一批请求进来，延迟从50毫秒飙到2秒,甚至大量503。
这不是新版本代码有问题，而是算力池完全没有进入工作状态，大模型推理服务不是普通的Web应用，进程启动只是第一步，模型权重要从磁盘加载到显存，这可能需要几十秒甚至几分钟，CUDA context要初始化，算子要编译，显存池要申请，page cache要填充，更关键的是，服务端的动态批处理逻辑需要看到连续的真实请求分布才能调到最优的batch size和调度策略，你用一个空转的进程去迎接突发流量,等于让一个刚睡醒的人立刻跑百米冲刺。
行业共识认为，蓝绿切换的失败案例中，有相当一部分不是因为代码缺陷，而是因为新环境没有完成算力预热，推理服务蓝绿切换算力预热方案这件事，不能靠加大机器硬扛，硬扛的意思是，你为了防止冷启动失败，准备了两倍甚至三倍的冗余资源，这在流量低谷期尚可，在高峰期，成本压力会让团队放弃蓝绿机制,回到最原始的停机发布。
蓝绿切换算力预热的三个关键阶段
把预热拆开看，它其实覆盖了三个不同的子问题：显存和权重就绪、运行时缓存就绪、调度策略就绪,下面按阶段展开。
预热前的容量评估和资源准备
首先明确一个原则：蓝环境应该放在独立的资源池里，哪怕它和绿环境共享同一个Kubernetes集群，也要用节点亲和性或者独立命名空间隔开，否则预热时的显存申请和GPU显存碎片化,会干扰到正在承接流量的绿环境。
容量评估看两个数：估算的峰值QPS和上下文长度分布，以自研的推理服务为例，一般需要准备1.5倍的冗余显存，因为XGBoost和GBDT这类模型通常小于1GB，但大语言模型的权重动不动就是几十GB，再加上KV Cache,显存占用是动态的。
具体操作上,建议执行以下步骤：
- 根据历史监控，找出过去7天和30天的峰值QPS,取较大值作为预热的压力目标。
- 统计请求的输入token长度分布，特别是P99值，对应到显存里的KV Cache预留。
- 核对新版本依赖的推理引擎版本，如果从vLLM 0.4升级到0.5，注意block manager的行为变化,预留更多显存给连续的物理block。
- 为蓝环境单独配置配额，比如GPU卡的型号和数量,避免和绿环境争抢同一个物理GPU。
预热流量怎么构造
预热流量有两种来源,各有适用场景。
第一种是流量镜像，把绿环境入口处的真实请求复制一份，转发到蓝环境，但不修改绿环境的响应，优点是完全真实，包括用户实际的prompt长度、并发模式、上下文复用行为，缺点是蓝环境会承受双倍流量，需要确保用量不大，或者通过采样比例控制镜像流量，比如只镜像15%的请求。
第二种是合成压测流量，用脚本生成模拟请求,重点覆盖几个关键场景：
- 单轮短对话，token长度在100以内,用于验证基础推理路径。
- 多轮长上下文，模拟1K-8K token的历史对话，用于触发KV Cache的复用和显存分配。
- 并发突发，比如从50并发瞬间提升到300并发,观察动态批处理是否正常合并请求。
- 不同温度参数和采样方式,避免出现算子层面的冷路径。
实际操作中，我们更倾向于先用合成流量做一轮基础预热，再叠加流量镜像做一轮真实形态的打磨，这样既能控制节奏,又能暴露真实场景下的边缘问题。
预热效果怎么验收
不能只看GPU利用率上升到90%就认为预热完成,推荐用三个指标联合判断：
| 指标 | 含义 | 验收标准 |
|---|---|---|
| 首token时延P99 | 用户发出请求到收到第一个token的延迟 | 与绿环境同水位下的偏差不超过15% |
| 显存碎片率 | 显存分配后碎片占空闲显存的比例 | 低于15%，且连续两次GC后无明显变化 |
| 动态batch大小 | 服务端实际合并的批次大小 | 在模拟峰值QPS下，batch大小稳定在预期范围的80%以上 |
很多人忽略的是，预热需要持续一段时间，而不是发几万条请求就结束。一个合理的预热周期至少在10到15分钟之间，让GPU温度、显存频率和网络队列都稳定下来，如果你看到显存占用缓慢爬升，说明还在分配缓存空间,耐心等它走完。
推理服务蓝绿切换方案对比：预热与不预热的差异
有不少团队觉得，新版本只是改了接口逻辑，模型没变，是不是可以跳过预热？我们用一个表格来看清楚差别：
| 对比维度 | 不预热直接切换 | 预热后切换 |
|---|---|---|
| 切流初期错误率 | 可能出现2%-5%的5xx错误 | 错误率接近0 |
| 首token时延 | 切流后5分钟内平均增加60%以上 | 波动小于10% |
| 内存/显存稳定性 | 可能出现OOM或显存溢出 | 稳定在一个水位 |
| 回滚决策 | 因为分不清是代码问题还是热启动问题，容易误操作 | 可以快速定位到代码改动 |
即使推理框架内置了warmup功能，比如TorchServe在模型加载时会自动跑一个假样本，那种预热程度远不足以应对生产流量，它对算子选择和CUDA图捕获有帮助，但对显存池、缓存淘汰、动态批处理几乎没作用，所以不要迷信框架自带的warmup,一定要走独立于框架的预热流程。
预热过程中的常见坑
第一个坑是显存碎片化，预热时如果一次性发送大量超长请求，显存会申请一块很大的KV Cache，释放后留下很多不连续的空洞，后续短请求可能因为找不到连续显存而触发碎片整理，导致延迟抖动，解决办法是预热流量要从小到大递进，先发短请求,再逐渐增加长度。
第二个坑是动态shape被缓存命中反噬，许多推理框架会缓存同一种shape的优化日志，比如ONNX Runtime的tunable op，如果预热数据里缺少某些特殊的attention mask组合，真实流量碰到没见过的shape，就会触发运行时重新调优,那一下可能卡住几十秒。
第三个坑是健康检查与就绪状态脱节，Kubernetes的readinessProbe只探测TCP端口，进程能监听不代表算力就绪，最优做法是在服务内自定义一个/ready接口，在这个接口里主动检查模型权重加载完成、显存池分配完毕、至少成功处理了10个预热请求，才返回200,这样调度器不会把流量打到就绪半程的服务上。
不同推理框架下的预热实操差异
以当前环境里最常见的三种框架做个说明,方便你对照着修改现有配置。
针对vLLM的预热
vLLM在启动时会构建KV Cache管理器和block映射表，预热时要特别注意它的gpu_memory_utilization参数，默认是0.9，意味着预留了10%的显存给中间结果，建议预热阶段把参数调到0.85，防止KV Cache占用过高导致OOM,可以这样验证预热是否到位：
curl -X POST http://blue-env:8000/generate
-d '{"prompt": "测试", "max_tokens": 16}'
连续跑10次，观察vLLM的日志，确认每次请求的调度延迟都小于1毫秒,说明block分配已经进入稳态。
针对Triton Inference Server的预热
Triton支持显式声明模型的输入输出shape，预热建议用concurrency字段设置并发数，同时开启dynamic_batching的max_queue_delay_microseconds，一个常见问题是，Triton的模型加载默认是懒加载，也就是第一次推理时才初始化CUDA context，所以预热的第一步必须主动触发一次推理，让context创建完成，可以在模型配置里加上warmup策略,但更稳妥的做法是用客户端脚本发一个批次的请求。
针对自研推理引擎的预热
自研引擎一般耦合了业务逻辑，比如带检索增强或结果重排，预热时不能只测模型推理，要把上游的向量检索、特征计算一并打通，建议编写一个专门的预热命令，比如
python preheat.py --target-version=blue,它会依次执行：
- 加载词典和模型参数到共享内存
- 初始化faiss索引或向量库连接池
- 发50条覆盖不同类型的模拟请求
- 等待显存利用率和时延稳定
这个脚本放在发布流水线的前置步骤里,由发布系统自动执行。
算力预热的自动化落地思路
手动预热太依赖运维人员的经验，想要稳健，最好把预热流程固化到CI/CD里,简化的步骤是：
- 蓝环境启动完成后,自动触发preheat任务。
- 预热任务先拉取最近半小时的绿环境流量指标，包括平均QPS、token长度P99、并发数。
- 根据指标动态生成合成压测配置，按20%的比例起步，逐步提升到真实峰值的80%。
- 连续三个采样周期内，首token时延P99的波动小于10%,判定为预热成功。
- 预热成功后，更新蓝环境的readiness标记,允许路由服务将流量切过去。
整个过程里，最耗时的是等待显存和缓存进入稳态，有些服务要预热20分钟才能让显存碎片率降下来，这没关系，蓝绿切换本来就要求你能承担得起这份时间成本，预算不够的地区和项目，可以考虑错峰发布，比如在凌晨低峰期做切换，把预热时间拉长到40分钟,这样对机器规格的要求会低一些。
常见问题解答
蓝绿切换时算力预热的最佳时间是多久？
没有一个固定数字，业内专家指出，预热时长取决于模型规模、显存大小和请求分布复杂度，一个70B参数的模型在A100上，权重加载加cuda graph捕获约需3-5分钟，之后至少再给10分钟让动态缓存稳定，如果流量环境中有大量长上下文请求,这个时间还要翻倍。
推理服务蓝绿切换方案对比中，滚动更新和蓝绿切换哪个更需要预热？
滚动更新其实变相继承了预热的负担，因为新Pod每次启动都会经历冷启动，如果逐个替换，旧Pod还在扛流量，新Pod的冷启动对整体延迟的拖累会被持续放大，蓝绿切换至少可以集中预热，代价是资源翻倍,选择哪种方案要看你能接受的发布时长和资源成本。
预热消耗的算力成本怎么算？
预热流量本身不产生业务价值，但它占用了GPU算力，以一张T4卡为例，预热15分钟的电费加上资源损耗，折合下来大概几元到十几元，用更精细的方式，可以把预热放在即将释放的竞价实例上，或者与绿环境的流量低谷对齐，降低额外成本，对于追求稳定性的核心业务,这笔钱不该省。
说到底，推理服务蓝绿切换算力预热方案不是锦上添花，而是切流成功的前置条件，把预热当成发布流程里的一等公民,你的切换才能做到从容不迫。