零停机模型更新的滚动部署

我们从其他推理平台迁移过来的客户反馈，在更新模型时，他们往往陷入蓝绿部署（blue-green deployment）和硬切换（hard cutover）之间的两难选择。

蓝绿部署需要与现有集群并行部署一整套新集群，在部署期间计算成本实际上翻倍（且在算力紧张时难以实施）。硬切换成本较低，但却是"全有或全无"：一旦出现问题，部署中途无法暂停。

为降低风险，部分团队将部署安排在非高峰时段以限制影响范围，并人工监控仪表盘数小时。两种方案的操作开销都促使团队倾向于批量更新，但这意味着生产环境中的模型可能比最新版本落后数周。

我们构建了滚动部署（rolling deployment）来解决这些问题。实际效果显示，团队模型更新的频率提升了50-60%，且无需非高峰时段调度和人工值守。

滚动部署的工作原理

滚动部署逐步替换副本。新副本扩容，接收相应比例流量，旧副本缩容。该循环持续进行，直至新部署完全接管服务。

✕

滚动部署：流量逐步从当前部署迁移至候选部署。每一步中，新的候选副本（或部分副本）启动并通过健康检查后，当前组才会被移除。

流量仅在新副本健康后才会迁移，避免了基于时间调度时，副本仍在将数GB模型加载到内存中时流量就已切换的问题。

在部署过程中的任意时刻，你可以：

• 暂停，检查指标或日志后再继续
• 恢复，从上次中断处精确继续
• 取消，优雅地将流量回切至先前部署
• 强制取消，立即回滚
• 强制推进，在一切正常时完成部署

底层机制：编排、流量迁移与自动扩缩容

管理延迟与成本敏感性

两种配置模式应对不同约束：

1. max_surge：先扩容候选副本，再缩容先前副本。过渡期间两个版本同时运行，总容量暂时超过稳态。
2. max_unavailable：先缩容先前副本，再在释放出的容量中扩容候选副本。每一步中总副本数可能低于稳态，但绝不会超出原始资源占用。

我们构建max_surge用于处理延迟敏感场景，允许短暂轻微过度配置。max_unavailable则适用于计算利用率是硬约束的情况。

两种模式均采用百分比（0-50%）控制每步变更的副本数量。百分比越低，步骤越多，部署越慢；百分比越高，步骤越少，部署越快。

✕

滚动部署期间，Max Surge临时运行额外副本，在新版本上线时保持全部容量在线。Max Unavailable则采取相反策略：先移除一个副本，再在现有资源范围内替换，接受短暂容量下降。延迟优先时使用Max Surge；优化计算成本时使用Max Unavailable。

持久化工作流编排

由于涉及副本扩容、健康检查执行和流量迁移，滚动部署可能需要数十分钟才能完成（尤其在高规模场景下）。为确保过渡平滑且能应对故障，必须保证系统是有状态的。

为实现有状态，滚动部署运行在持久化工作流引擎上。每一步都是具有明确定义输入和输出的离散操作。内置自动重试、暂停/恢复语义以及部署状态的完全可见性。部署的完整历史（每一步、状态转换和所有控制操作）均被记录并可查询。

这些预防措施防止系统静默失败并陷入模糊状态。

部署中途负载激增怎么办？

自动扩缩容响应负载变化。滚动部署则迁移负载。如果两者独立运行，可能相互冲突：自动扩缩容可能在部署即将缩容时扩容副本，或者部署可能移除自动扩缩容刚请求的容量。

滚动部署将两个版本视为一个整体进行协调，仅在副本健康且就绪后才迁移流量。随后等待配置的稳定窗口期，再进入下一步。

如果部署中途目标规模发生变化，我们会保持当前流量分配比例，同时调整两个版本的规模以匹配。

可配置的稳定期（0-3600秒）让操作员有时间检查指标，确认新版本表现正常后再进行下一步增量。

客户部署频率提升50-60%

当部署风险降低时，团队会更频繁地发布更新。自接入Baseten平台以来，部分客户报告使用滚动部署后部署频率提升了50-60%。

部署中控制功能在实践中被积极使用：我们看到客户在部署中途暂停检查指标，在出现早期回归迹象时取消，以及在部署看起来健康时强制推进。过去需要在非高峰时段人工值守的部署，现在可以无人值守运行。

致谢

滚动部署由Dedicated Inference团队构建。特别感谢在设计和部署过程中提供反馈的客户（如Speechify）！

如果部署流程占用了你的工程时间，立即开始使用滚动部署，或联系我们与我们的工程师交流。