扩容少暂停，和扩容很快完成，是两件不同的事。vLLM在10月19日披露Elastic EP的新进展：在特定DeepSeek V4 Pro测试中，从16张GPU扩到20张，服务中断降到0.82秒，但完整操作仍耗时92.34秒。这个反差恰好说明，在线推理的弹性能力不只取决于多快加入显卡，更取决于准备新容量时，原有用户能否继续得到响应。

快速看点：新流程把准备与切换分开；NIXL EP让已有工作节点复用CUDA图；公开测试代码同时检查扩缩容期间的请求与前后准确率。这里的“接近零停机”并非绝对零中断，也不是适用于任意模型、硬件和网络的一秒扩容承诺。

先在后台备齐，再短暂停下来切换

大型混合专家模型把计算分散在多张GPU上，改变参与节点，就可能牵动通信、权重和执行状态。过去即使不重启整个服务，重新组织这些资源也会阻断生成。新方案先让新增节点启动、接收权重、准备通信并完成执行预热；既有节点仍按原拓扑服务，最后才短暂停调度并启用新拓扑。

这与额外复制一套完整模型不是同一个操作。Elastic EP针对正在运行的专家并行部署调整参与规模，帮助团队避免只能按整个副本增减容量的粗粒度选择。但调度平台仍需要决定何时扩容、从哪里获得资源、怎样处理资源不足；引擎具备调整能力，不等于企业已经获得完整自动伸缩系统。

公开的NIXL EP文档给出了动态连接与断开节点的接口，也允许先连接但不激活新增节点。这种“准备好但暂不参与”的状态，是旧服务与新容量能够并存的基础。文档还明确设备通信路径没有自动回退：选中的路径不可用会失败。因此，部署不能只看功能开关，还要验证实际通信依赖。

复用执行图，才避开另一段长等待

只把权重加载移到后台仍不够。CUDA图预先记录GPU执行过程，减少CPU逐个发起操作的开销；若扩缩容改变了图里引用的地址或通信状态，已有节点仍得重新预热和捕获。新方案保持相关缓冲区与执行参数稳定，使保留的节点不必因成员变化丢掉已有图。

新增节点没有旧图可复用，因此要独立完成自己的准备。它们在预热时暂时屏蔽远端通信对象，避免拉着正在处理真实请求的旧节点一起等待。完成切换后，专家负载再在后台重新分配。这里的工程重点是减少互相干扰，而不是把初始化工作凭空消除。

对运维团队而言，这也改变了观察指标。应分别监控准备是否仍在推进、用户生成是否暂停，以及切换后各节点是否恢复正常。仅盯扩容接口返回成功，既看不到中途的请求停顿，也无法判断新增资源是否真正承担了负载；只看平均延迟则可能掩盖少量用户的长尾等待。

0.82秒有明确条件，不是通用SLA

博客测试使用GB200、DeepSeek V4 Pro，张量并行为1，数据与专家并行规模在16和20之间变化；权重已放在共享存储，编译缓存也已预热。引入异步准备与图复用后，扩容中断为0.82秒，缩容为1.96秒。它们是供应商在该配置下测得的结果，本地未独立复现。

可检查的配套测试与上述大模型性能场景应分开看。仓库用DeepSeek-V2-Lite-Chat测试2到4再回到2张GPU，向扩缩容接口发请求，在准备阶段持续发送流量，并用256道GSM8K题检查前后准确率。这提供了可复用的验证骨架，却不是对GB200成绩的独立证明。

测试脚本会区分完整扩缩容耗时和暂停耗时，并检查准备期间确有请求成功完成。准确率还设有阈值和相对初始结果的容忍范围，不能简化成“所有输出完全一致”。生产迁移应根据自身任务补充长上下文、流式生成、工具输出及异常恢复样本，不能直接把数学题分数当作全部业务验收。

后续规划还包括利用快照更快恢复新增工作节点，以及与Dynamo、llm-d等编排器连接。这些属于下一阶段工作，不能把规划写成已经交付的自动伸缩能力。新容量准备仍有时间成本，资源采购、调度和恢复策略也不会因为停顿缩短而自动解决。

小编判断：弹性首先要少打扰现有用户

这项进展值得关注，是因为它把扩容优化从“启动更快”推进到“准备时继续服务”。对在线客服、研发助手和内部知识服务，新增负载到来时先保住已有会话，往往比一张总耗时榜单更接近真实体验。0.82秒可以成为测试目标的参考，不应直接写进客户合同。

实际交付可以先建立小规模基线，分别记录准备、切换、恢复和错误请求，再逐步接入资源调度。扩容成功、用户少受影响和结果质量不退化，必须同时成立。只有把这三项放进同一套验收，昂贵GPU的弹性才会从演示能力变成可管理的生产能力。