由上海交通大学、当A调度清华大学与生数科技（Shengshu Technology）联合研发的视省最新成果，以预印本形式于2026年6月17日发布于arXiv平台（编号：arXiv:2606.19271v1），频流该研究深入计算机系统与分布式计算领域，媒体旨在解决AI视频流媒体服务的遇上员延核心痛点。

你是迟降成本否察觉，当下的当A调度AI应用正经历从“请求-等待-交付”的传统模式，向“实时流式体验”的视省范式转移？视频不再是生成完毕后一次性交付，而是频流边生成边播放，用户甚至能在生成过程中实时调整指令。媒体这种流畅体验的遇上员延背后，是迟降成本服务器端极其复杂的资源调度挑战。

具体场景如下：当用户在使用AI视频创作工具时，当A调度系统持续生成视频片段，视省用户可能随时发出新指令、频流暂时离开或回归。与此同时，成千上万的用户也在进行类似操作。服务器不仅要追踪每个用户的创作进度，还要在用户非活跃期合理释放资源，并确保用户回归时能瞬间恢复生成——因为流式播放中任何一帧的延迟都会导致卡顿，直接摧毁用户体验。

这一挑战堪比一家繁忙的餐厅，需同时接待数百桌客人，每桌都点无限续杯的特色菜，厨师需预判客人离席与回归的时间，并确保每道菜在三分钟内上桌。传统管理方式对此束手无策。

为此，研究团队开发了TurboServe系统，并在生数科技生产环境中部署验证。实验数据显示，相较于原有基础系统，TurboServe将最坏情况下的单片段生成延迟平均降低37.5%，同时将GPU总运营成本平均削减37.2%。这背后是一套精密的“餐厅调度哲学”。

一、流式视频生成：颠覆传统的服务形态

理解TurboServe的前提，是厘清“流式视频生成”与传统AI服务的本质差异。

传统AI视频生成（如Sora、HunyuanVideo）采用“一次性订单”模式：用户提交提示词，系统运算数秒至数分钟后交付完整视频。服务器仅需处理单一任务，完成后即释放资源，逻辑简单清晰。

而流式视频生成（以Self-Forcing、LongLive、HYWorldPlay等为代表）则采用“逐片段（Chunk）生成+即时播放”模式。用户观看第一段视频时，系统已在生成第二段；用户可随时指令“换个方向”，系统需立即响应并调整后续内容。这是一个持续、交互且有状态的过程——系统必须记忆之前的生成内容（包括KV缓存和时序状态），以确保后续片段在风格和内容上的连贯性。

用餐厅比喻：传统生成是“外卖模式”，订单打包即止；流式生成则是“包厢私厨模式”，厨师常驻包厢，需记住食客偏好，确保每道菜风格统一。

这种“包厢私厨模式”引发了两大核心难题，也是TurboServe攻克的重点：

1. 会话持续时间的极度不均匀：用户行为差异巨大，从几秒到超过两分钟不等。若初始分配不均，可能导致部分GPU堆积大量长期驻留的“老用户”，而其他GPU闲置，造成资源错配。
2. 活跃用户数量的剧烈波动：用户流量呈现明显的高峰与低谷。固定数量的GPU难以应对这种波动：高峰时资源不足导致延迟飙升，低谷时大量GPU空转浪费成本。

这两大因素共同导致了“静态调度失效”困境。研究团队在8块NVIDIA H100 GPU集群上进行的对照实验显示，基础系统（新会话分配至最轻负载GPU后不再调整，GPU数量固定）的最坏单片段延迟高达0.71秒，总GPU成本约为3.99美元。这就是缺乏动态调度能力的代价。

二、三次思想实验：拆解优化路径

研究团队通过三个递进实验，验证了各优化手段的有效性及其协同效应。

实验一：仅实施会话迁移

保持GPU数量不变，系统每10秒监测各GPU负载，将高负载GPU上的部分会话迁移至空闲GPU。
* 结果：最坏情况延迟降低26.53%，成本不变。
* 原理：消除“木桶效应”，避免单点过载拖累整体体验。

实验二：仅实施GPU自动扩缩容

保持会话分配策略不变，根据实时负载动态增减GPU数量。
* 结果：总GPU成本降低32.57%，最坏延迟维持原水平。
* 原理：按需分配资源，避免为应对峰值而全天候维持高配置。

实验三：迁移与扩缩容协同

两者结合，形成闭环控制。
* 结果：最坏延迟降低8.17%，总成本降低40.25%。
* 洞察：协同效应并非简单叠加。均衡的负载分布使扩缩容决策更精准（区分是分配不均还是需求激增）；而扩缩容操作需配合迁移才能安全执行（如缩容前需迁出会话）。

这三个实验确立了TurboServe的核心哲学：迁移与扩缩容是同一控制回路中的两个协同环节，而非独立功能。

三、TurboServe架构：永不停歇的调度大脑

TurboServe由四大模块构成，形成闭环控制：

1. 工作量探测器（Workload Detector）：“门口迎宾”。实时监测会话事件（到来、离开、活跃/空闲状态切换），计算系统繁忙程度与波动剧烈程度，并向其他模块发送信号。
2. 放置控制器（Placement Controller）：“排座位领班”。决定活跃会话的GPU归属。新会话分配至最轻负载GPU；持续监测负载，一旦某GPU成为瓶颈，立即迁移部分会话以实现负载均衡。
3. 自动扩缩容控制器（Autoscaling Controller）：“餐厅总经理”。根据放置控制器报告的负载比例，对比目标利用率，决定增减GPU。引入迟滞机制，避免短暂波动导致的频繁开关机。
4. 会话管理器（Session Manager）：“后台档案室”。追踪会话状态（位置、数据存放地）。空闲时状态数据移至CPU内存，迁移时负责数据搬运。

这四个模块实时运作，在“服务延迟”与“运营成本”之间寻找动态最优解。

四、调度算法的数学灵魂：定义“最优”

TurboServe将问题形式化为在线调度优化：在每个时刻，最小化GPU运营成本与最差单片段延迟，通过权重参数平衡两者。

• 成本：当前运行GPU数量 × 单价。
• 延迟：所有活跃会话中，最慢会话的单片段生成时间。

针对此双目标优化，TurboServe设计了两个配套算法：

1. 放置控制器算法：迁移感知最小-最大再均衡
2. 策略：贪心局部搜索。保留现有分配，找出最重负载GPU，尝试迁移其会话至其他GPU。
3. 评估：计算“收益” = 最坏延迟降低值 - 迁移耗时（基于α-β通信时延模型）。

4. 执行：仅执行收益为正且最高的迁移方案，直至无正收益方案为止。此策略计算量小，效果接近穷举最优。

5. 自动扩缩容控制器算法：基于迟滞的比例调节

6. 策略：实时跟踪最大GPU负载比例。
7. 扩容：当负载 > 目标利用率 + 容忍余量时，按公式 ceil(活跃会话数 / (目标利用率 × 单GPU最大并发数))新增GPU。
8. 缩容：当负载 < 目标利用率 - 容忍余量时，按比例计算保留GPU数量。
9. 协同规则：缩容前必须先迁移会话；扩容后必须先加载模型再迁移会话。确保状态一致性与资源安全。

五、自适应控制参数：应对不确定性的智慧

TurboServe的目标利用率并非固定，而是根据工作负载的波动剧烈程度动态调整。

• 波动指标：近期新增活跃会话数量的标准差。标准差越大，波动越剧烈。
• 自适应机制：基于历史数据建立“波动级别→最优参数”映射表。
• 低波动（第1级）：目标利用率设为0.80（满载运行，节省成本）。
• 高波动（第10级）：目标利用率降至0.25（留足75%缓冲，应对突发需求）。
• 效果：从第1级到第10级，平均成本增加约2.3倍，这是为“不确定性”支付的保险费。
• 验证：与“预知未来”的理想系统相比，TurboServe的成本仅高出0.73%，证明其仅凭历史数据即可捕捉绝大部分优化空间。

六、运行时机制：高效且安全的会话迁移

算法决定“做什么”，运行时机制决定“怎么做”。TurboServe通过以下设计确保迁移的高效与安全：

1. 批量片段处理（Batching）：将同一GPU上所有待生成下一片段的会话打包，一次性送入模型计算，结果分发。极大提升GPU利用率，类似“一锅出”。
2. GPU-CPU状态卸载：会话空闲时，将其状态数据（KV缓存等）从GPU显存移至CPU内存，释放GPU资源供其他活跃会话使用。用户回归时再加载回GPU。
3. 基于NCCL的零中转迁移：利用NVIDIA NCCL库，实现源GPU到目标GPU的直接数据推送，不经CPU中转，大幅降低迁移延迟。
4. 时机：仅在两个片段生成间的“空档期”进行。
5. 分区设计：GPU内存分为模型参数区（共享、不动）、会话状态区（独有、迁移）、归属表。仅迁移“记忆文件”，不搬“厨房设备”。

实测数据：在H20和B300 GPU上，单次会话迁移耗时仅23-30毫秒，占单片段生成时间（~1000ms）的2%-3%。远低于过载导致的延迟惩罚，证明迁移成本完全可控。

七、真实数据验证：稳健的性能提升

研究团队在生数科技的两套生产集群（16块H20 GPU、64块B300 GPU）上，使用1.3B和7B参数模型及6条真实流量轨迹进行了全面评测。

• 对比基准：轮询分配+固定GPU、负载感知贪心分配、内存感知贪心分配。
• 性能结果：
• 延迟：TurboServe在所有12个测试场景中均优于基准，平均降低最坏延迟37.5%，最大降幅51.6%。
• 成本：TurboServe在所有场景中均最优，平均降低GPU运营成本37.2%，最大降幅49.0%。
• 消融实验：
• 去掉迁移功能：成本平均增加15.0%。
• 去掉自动扩缩容：成本平均增加42.9%。
• 结论：自动扩缩容对成本控制贡献更大，迁移则提升资源利用率。
• 算法效率：在64块GPU集群上，单次调度决策耗时<15毫秒（<2%单片段时间）。与穷举最优解差距仅3.6%（最大6.5%），但速度提升10倍以上。

调度快照分析：系统在前两分钟适应负载，GPU数量从8块收缩至1块再扩展至6块；随后随负载增加扩展至11块；后半段随会话结束回落至4-8块。每两分钟窗口内发生20-70次迁移，持续平衡负载。

结语：静态配置无法应对动态世界

TurboServe解决的虽是后台问题，但直接决定了前端用户体验与商业可行性。其核心洞见在于：流式服务的本质是时间演化的，因此服务系统必须是持续自适应的。将“会话去哪台GPU”与“开多少台GPU”纳入同一闭合控制回路，实现协同反馈，是同时降低延迟与成本的关键。

此外，流式视频生成与LLM服务存在本质区别：
1. 状态生命周期：视频会话状态需长期保存并反复激活，而LLM请求状态通常即时释放。
2. 延迟约束：视频要求每一帧在固定窗口内完成，任何超时即卡顿；LLM优化整体完成时间或Token级延迟。

因此，直接套用vLLM等LLM调度方案并不适用。TurboServe为流式视频服务开辟了新领域，未来可探索跨数据中心迁移、用户行为预测及异构集群配置等方向。

Q&A

Q1：TurboServe的会话迁移会不会导致视频生成中断或内容不连贯？

A：不会。TurboServe的迁移设计专门规避了此问题：
1. 时机选择：迁移仅在两个视频片段之间的“空档期”进行，不中断正在进行的生成计算。
2. 三步一致性协议：
* 源GPU完成当前片段后冻结状态数据。
* 目标GPU拉取并验证数据完整性。
* 最后更新会话归属记录。
3. 状态完整性：迁移包含完整的历史状态（如KV缓存），目标GPU可从完全相同的断点继续生成，确保视频风格与内容连贯，无可见断层。

Q2：流式视频生成服务和普通大语言模型服务有什么本质区别，为什么不能直接用vLLM这类现有系统？

A：两者在两个关键维度存在本质差异：
1. 状态生命周期：LLM服务请求状态在响应完成后即刻释放；流式视频生成的会话状态需在多次“活跃-空闲”交替中持续保存，时间跨度可达数分钟甚至更长。
2. 延迟约束：LLM通常优化整体完成时间或Token级延迟；流式视频生成要求每一个片段必须在固定时间窗口内完成，因为视频实时播放，任何一帧超时都会造成可见卡顿。
这些差异使得现有LLM调度系统无法直接适配流式视频场景。

Q3：TurboServe自动扩缩容时，新GPU从启动到可以接受会话需要多长时间，这段时间会不会影响高峰期的响应？

A：TurboServe通过预置基础设施最小化此延迟：
1. 预缓存：在集群管理系统中，GPU服务器的容器镜像、运行环境和模型参数检查点已预先缓存在本地存储。
2. 快速启动：扩容时无需从远端拉取镜像或下载权重。过程分为两步：集群管理器分配GPU并加入服务池 → TurboServe本地加载模型并热身。
3. 效果：避免网络传输瓶颈，启动速度远快于传统云端冷启动，足以在需求高峰真正到来前完成准备，不影响高峰期响应。