TurboServe: 高效且经济地服务流式视频生成

TL;DR TurboServe 是首个针对流式视频生成的服务系统，通过在线调度与自动扩缩容，在真实生产环境中将最差块延迟降低 37.5%，GPU 成本降低 37.2%。

问题

背景

流式视频生成推理正在成为一类全新的服务负载，用户通过长期会话与模型交互，按视频块（chunk）逐步接收生成内容。与离线视频生成或大型语言模型（LLM）的高吞吐批处理服务不同，这类任务要求系统在整个会话生命周期内保持状态，并反复调度每个活跃会话，在每个块上严格遵守低延迟目标。

现有方法局限

目前业界尚缺乏专为流式视频生成设计的推理系统，通常沿用针对 LLM 优化的服务框架（如 vLLM 或 TGI）或通用 GPU 调度器。这些系统存在两个根本性不足：

• 静态放置难以应对会话时长异构：长会话会持续数分钟甚至更久，初始放置后 GPU 负载会随时间漂移，导致部分 GPU 过载而其他空转，产生严重的尾巴延迟。现有系统缺乏在线重均衡机制。
• 固定 GPU 池无视用户需求时变：流式负载的活跃会话数呈突发性波动（burst 与 idle 交替），静态资源配置必然在高峰期丢帧，在低谷期浪费 GPU，总拥有成本（TCO）居高不下。

挑战与重要性

问题难度来自两个维度的异构性：会话时长异构（session duration heterogeneity）使得放置决策必须动态修正；时间维度的用户需求异构（temporal user-demand heterogeneity）要求 GPU 数量实时跟随负载。两者耦合会形成恶性循环：当负载突增时，若同时触发重均衡与扩容，不当的联合决策可能引发状态迁移风暴。随着 Sora 等视频生成模型进入实际应用，交互式视频生成有望成为下一个百亿级市场，延迟稳定性和 GPU 成本效率直接决定商业可行性，因此该问题不仅具有学术挑战性，也受到产业的密切关注。

行业类比

这一问题与 LLM 推理服务从无状态请求进化为有状态会话管理的历程高度相似——正如 vLLM 的 continuous batching 解决了静态批处理低效的痛点，流式视频生成也需要一套能动态编排会话与 GPU 资源的闭环系统。

核心洞察

• **流式视频生成服务的核心矛盾在于会话时长的异质性和用户需求的时间波动**：现有 LLM 或离线视频生成服务系统通常假设请求是独立短事务，无法有效处理长会话的状态保持和跨 GPU 的持续负载均衡。TurboServe 首次将这类工作负载公式化为在线调度问题，并设计闭环架构同时决策会话放置与 GPU 伸缩，直面生产环境中由于会话时长不均导致 GPU 利用率退化、以及突发需求引起的延迟劣化，为实时交互式视频生成服务提供了系统级解决方案。
• **迁移感知放置与负载驱动自动缩放的联合优化是 TurboServe 实现效果提升的关键**：与静态放置或独立扩缩容策略不同，TurboServe 的放置控制器在重新平衡会话时会在线评估迁移开销，避免短视决策；自动缩放控制器则根据实时负载波动快速增减 GPU，二者协同形成闭环反馈。这一设计使得在真实生产跟踪测试中，最差延迟降低 37.5%、总 GPU 成本节省 37.2%，证明联合调度对于状态持久、负载时变的新型流式应用至关重要。

方法

TurboServe 将流式视频生成服务抽象为一个在线调度问题，同时优化会话放置（session placement） 与GPU 资源供给（GPU provisioning）。

输入与工作负载模型

系统接收多个用户的长期会话，每个会话持续生成视频块（chunk），并需在严格延迟目标内交付。工作负载具有两类异构性：

• 会话时长异构：长会话导致初始放置随负载变化逐渐次优；
• 时间需求异构：活跃会话数量在突发与空闲期间剧烈波动。

关键模块：闭环调度算法

核心是一个闭环调度器，包含两个紧密协作的控制器：

• 迁移感知放置控制器：定期评估各 GPU 上的会话分布，计算最优迁移方案以均衡最大每块延迟（per-chunk latency）。它显式考虑迁移代价，避免频繁搬移带来的开销。
• 负载驱动自动缩放控制器：监控整体负载水平，动态调整活跃 GPU 数量。在突发期扩展资源以消化队列，在空闲期收缩以降低成本，实现 GPU 预算与工作负载的匹配。

运行时支撑机制

为支持上述决策，TurboServe 实现了三个关键机制：

1. 合并块处理（coalesced chunk processing）：在同一 GPU 上将多个并发活跃会话的 block 合并为批次，提升吞吐；
2. GPU-CPU 卸载：挂起会话时将其状态从 GPU 内存卸载至 CPU，恢复时重新加载，从而在会话静默期释放 GPU 显存；
3. 基于 NCCL 的 GPU-GPU 迁移：利用 NCCL 集体通信实现高效的跨 GPU 状态迁移，用于在线重平衡。

输出与效果

调度器输出的放置决策和 GPU 规模直接作用于推理服务，使系统在真实生产轨迹上（最多 64 个 NVIDIA B300 GPU）平均降低 37.5% 的最差每块延迟和 37.2% 的总 GPU 运行成本。

与同类方法的差异

与面向 LLM 的 serving 系统（如 vLLM）不同，TurboServe 专门针对流式视频生成的会话状态保存、长生命周期调度与动态 GPU 伸缩进行设计，而非简单的请求-响应批处理。其迁移感知重平衡与负载驱动伸缩的闭环设计，是目前首个为流式视频生成服务量身定制的方案。

实验

实验设计：TurboServe 在来自 Shengshu Technology 的真实生产轨迹上进行评估，涵盖多种模型尺寸，并在最多 64 块 NVIDIA B300 GPU 的集群上测试。对比基线服务配置，测量端到端延迟和 GPU 运营成本，并通过消融研究分析各机制贡献。

关键发现：TurboServe 将最差单块延迟降低 37.5%，总 GPU 运营成本平均降低 37.2%。closed-loop 调度器通过迁移感知的放置控制器重平衡会话分布，结合负载驱动的自动缩放动态调整 GPU 数量，有效应对了会话时长异质性和用户需求波动带来的挑战。合并块处理（coalesced chunk processing）和 GPU-CPU 卸载进一步提升了资源利用率。

基线对比解读：传统静态或反应式服务系统无法适应流式视频生成的动态特性，长会话导致 GPU 负载不均，突发流量浪费资源。TurboServe 的在线调度、会话迁移和自动缩放协同作用，在保证延迟目标的同时显著降低成本，证明了联合优化放置与供给在流式视频生成服务中的价值。

行业影响

落地场景

TurboServe 面向流式视频生成服务（如 Sora、Kling 等模型的实时推理），可落地于需要逐帧或分块生成视频且要求低延迟、高并发的产品：

• 交互式视频创作工具：用户一边输入提示词，一边得到流式生成的视频预览，类似实时绘画的“动图”体验。
• 虚拟主播 / 数字人直播：根据弹幕或脚本动态生成短视频片段并叠加到直播流。
• 游戏实时过场动画：根据玩家选择实时生成个性化的剧情视频。
• 个性化视频广告：基于用户画像即时生成商品展示视频并推送给用户。

商业价值

• 降本：负载驱动的自动扩缩（autoscaling）与迁移感知的会话放置（migration-aware placement）使总 GPU 运行成本平均降低 37.2%，尤其适合波峰波谷明显的视频生成服务。
• 体验提升：最差每块延迟（per-chunk latency）降低 37.5%，避免毛刺导致的卡顿，提升用户留存与付费意愿。
• 增收：更流畅的实时生成体验可直接提高交互类应用的转化率和时长，且成本下降使服务能覆盖更多长尾用户。

与现有产品 / 工作流的接口

TurboServe 可作为模型推理之上的会话调度层，无缝集成到现有 stack：

• 暴露标准 API 管理视频生成会话的创建、挂起、恢复与销毁，可与 Triton Inference Server 或 Ray Serve 配合使用。
• 会话状态通过 GPU-CPU offloading 实现，可对接 Kubernetes 的容器编排，实现弹性 GPU 供给。
• 推理后端兼容主流的扩散模型（DiT），仅需模型支持分块自回归生成；输出视频流可接入现有转码 / CDN 管线（如 FFmpeg + RTMP）。

具体落地 use case

1. 电商直播实时商品展示：主播展示商品时，AI 根据观众弹幕要求（如“看内侧结构”）即时生成商品内部构造的动态视频，低延迟返回并贴入直播画面，提升互动转化。
2. 短视频平台 AI 生成服务：平台提供“故事模式”，用户连续输入剧情，系统流式生成连载视频；TurboServe 自动管理成千上万的并发会话，在流量低谷时缩容降本，高峰时扩容保流畅。

局限

• **迁移开销与调度最优性**：论文依赖 NCCL 基 GPU-GPU 迁移实现在线重平衡，但迁移操作本身会引入传输延迟和可能的会话暂停，尤其当模型参数规模较大时，迁移成本可能抵消放置优化的收益。调度算法采用基于启发式的闭环控制，缺乏全局最优性保证，在负载剧烈波动时可能触发过于频繁的迁移，导致系统抖动。
• **模型与框架的耦合性**：TurboServe 针对流式视频生成设计，但评估仅覆盖基于特定扩散架构的模型，未验证对自回归类或混合架构视频模型的支持。不同模型的显存占用、计算图特性和批处理效率差异可能影响 `coalesced chunk processing` 和 `GPU-CPU offloading` 的有效性，系统可移植性存在不确定性。
• **生产环境可扩展性**：实验最大规模为 64 块 B300 GPU，未探究更大集群（数百 GPU）下的调度复杂度、跨节点通信瓶颈以及中心化调度器的单点性能压力。所使用的生产痕迹仅来自一家厂商，可能无法泛化到更广泛用户行为与负载模式，实际部署时的适应性有待检验。