上交大、清华、生数科技联手打造：当AI视频流媒体遇上"智能调度员"，延迟降37%、成本省37%

这项由上海交通大学、清华大学与生数科技（Shengshu Technology）联合开展的研究，以预印本形式于2026年6月17日发布在arXiv平台，编号为arXiv:2606.19271v1，研究方向属于计算机系统与分布式计算领域。

你有没有注意到，现在越来越多的AI应用不再是"你发出请求、等待结果、获得完整视频"这种老式流程，而是变成了一种实时流式体验——视频边生成边播放，用户甚至可以在生成过程中随时调整方向。这种体验看起来很美好，但在幕后，它给服务器带来的挑战远比我们能想象的复杂得多。

把这个场景具体化：某个用户在使用一款AI视频创作工具，系统不断为他生成新的视频片段，他随时可能发出新的指令、暂时离开去喝杯咖啡、或者回来继续创作。与此同时，数百个甚至数千个其他用户也在做同样的事情。服务器不仅要记住每个用户当前创作进行到哪一步，还要在用户不活跃的时候合理分配资源，同时保证当用户回来继续创作时，响应速度必须足够快——因为视频是流式播放的，一旦下一段视频没能及时生成，用户就会看到卡顿，体验直接崩塌。

这个挑战的本质，就像一家超级繁忙的餐厅同时接待数百桌客人，每桌都点了无限续杯的特色菜，厨师们不知道哪桌客人什么时候会突然离席又什么时候突然回来，同时还要保证每道菜都在三分钟内上桌。传统的餐厅管理方式根本应付不来这种场面。

正是为了解决这个问题，研究团队开发了一套名为**TurboServe**的系统，并将其部署在生数科技的实际生产环境中进行验证。实验结果表明，与原有基础系统相比，TurboServe将最坏情况下的单片段生成延迟平均降低了37.5%，同时将GPU总运营成本平均削减了37.2%。这两个数字背后，是一套精妙的"餐厅调度哲学"。

---

一、流式视频生成：一种全新的服务形态

在理解TurboServe之前，先要搞清楚"流式视频生成"到底是什么，以及它为什么与以往的AI服务如此不同。

传统的AI视频生成方式，像Sora或HunyuanVideo，走的是"一次性订单"模式：用户提交一段文字描述，系统在幕后运算几秒到几分钟，最终把完整视频一次性交付给用户。这个过程中，服务器只需要管好这一个任务，任务完成后资源立刻释放，干净利落。

流式视频生成则完全不同。以Self-Forcing、LongLive、HYWorldPlay等新一代系统为代表，视频是逐片段（chunk）生成并立即播放的。用户看到第一段视频的同时，系统已经在生成第二段；用户可以在观看过程中随时说"换个方向"，系统就要立刻响应并调整后续内容。整个过程是持续的、交互的、有状态的——系统必须记住之前生成了什么（包括所谓的KV缓存和时序状态），才能保证后续片段在风格、内容上保持连贯。

用餐厅的比喻来说：传统视频生成是"外卖模式"，一个订单打包好送出去，厨师就不管了；流式视频生成则是"包厢私厨模式"，厨师要常驻包厢，随时响应食客的要求，而且还要记住这桌客人之前吃过什么、口味偏好如何，确保每道新菜与前面的风格一脉相承。

这种"包厢私厨模式"带来了两个根本性的服务难题，也正是TurboServe要攻克的核心战场。

---

二、两大核心难题：时间的不均匀与需求的不均匀

研究团队从生数科技的真实生产日志中提取数据，发现了两个鲜明的规律，这两个规律直接定义了流式视频服务的调度难点。

第一个规律是"会话持续时间的极度不均匀"。有些用户只用几秒钟生成一个短片就离开了，而另一些用户则会持续使用几分钟甚至超过两分钟进行反复创作。从生数科技的真实分布来看，会话时长跨越多个量级，从不足5秒到超过120秒的都有。这意味着如果系统在一开始把某些用户分配到同一台GPU上，随着时间推移，这台GPU上可能积累了大量长期驻留的"老用户"，而另一台GPU却已经空闲下来——就像餐厅里有几桌客人点了套餐、慢悠悠吃了三个小时，导致那几张桌子始终被占用，而其他桌子早已清空但新客人进不来。

第二个规律是"活跃用户数量随时间剧烈波动"。用户不会均匀地分布在一天中，而是会出现明显的高峰和低谷。在高峰时段，同时活跃的会话数量可能急剧攀升；而在低谷期，大量用户同时进入"空闲"状态（比如暂时离开去做别的事），活跃会话数量骤然下降。若用固定数量的GPU来应对这种波动，高峰时资源不够用，低谷时大量GPU白白空转、浪费电费和租金。

这两个问题合在一起，构成了一个经典的"静态调度失效"困境：无论你把GPU配置设得多高，总有时候会同时出现"某台GPU超载导致延迟飙升"和"其他GPU闲置浪费成本"的尴尬局面。

研究团队设计了一套对照实验来量化这个困境。在8块NVIDIA H100 GPU组成的集群上，用生数科技的真实流量重放，基础系统（新来的会话分配给当前最轻的GPU，之后不再调整，GPU数量固定不变）的最坏情况单片段延迟达到0.71秒，总GPU运营成本约为3.99美元。这就是"什么都不做"的代价。

---

三、三次思想实验：逐步拆解解决方案

研究团队没有一上来就抛出完整系统，而是通过三个层层递进的对照实验，清晰地展示了每个优化手段单独能带来多大收益，以及组合起来又会产生怎样的化学反应。

第一个实验是"只做会话迁移"。保持GPU数量不变，但每隔10秒钟，系统会观察当前各GPU上的会话分布情况，把负载最重的GPU上的部分会话挪到相对空闲的GPU上，让各GPU的工作量趋于均衡。结果表明，仅凭这一个手段，最坏情况延迟就降低了26.53%，而成本不变。道理很直接：如果四台GPU中有一台承担了60%的活跃会话，这台GPU处理每个片段的时间自然最长，它决定了整个系统的"最差体验"。把会话均匀分散后，所有GPU的负担都差不多，最慢的那个也快多了。

第二个实验是"只做GPU自动扩缩容"。保持会话分配策略不变，但GPU数量可以根据实时负载动态调整。高峰来临前多开几台GPU；低谷期来临后关掉几台GPU。结果表明，仅凭这一个手段，总GPU成本就降低了32.57%，而最坏延迟维持在原来水平。道理同样清晰：既然用户的活跃程度在波动，就没必要为了应对高峰而全天保持最大配置。

第三个实验是"两者同时做"。周期性迁移加上动态扩缩容，两个手段协同工作。最终结果是最坏延迟降低8.17%、总成本降低40.25%。这里有一个微妙但重要的观察：两者组合的效果并不是简单相加，而是产生了协同增益。原因在于，均衡的会话分布能让负载信号更加准确——当某台GPU不是因为"分配不均"而是真的因为"需求增加"而繁忙时，扩容决策才更精准；反过来，扩容或缩容操作也必须配合会话迁移才能安全执行，否则缩容时那台要被关闭的GPU上的会话怎么办？

这三个实验奠定了TurboServe整个设计哲学的基础：迁移和扩缩容不是两个独立的功能，而是一个协同控制循环中的两个环节。

---

四、TurboServe的整体架构：一个永不停歇的调度大脑

TurboServe的架构由四个主要模块构成，它们像一家现代化餐厅里不同职能的岗位，各司其职又紧密配合。

工作量探测器（Workload Detector）扮演的是"门口迎宾"的角色，它实时监测最近的会话事件：哪些用户刚刚到来，哪些用户刚刚离开，哪些用户从活跃变成了空闲，哪些用户从空闲重新变得活跃。它用一个滑动时间窗口计算当前系统的"繁忙程度"和"波动剧烈程度"，把这些信号传递给其他模块。

放置控制器（Placement Controller）是"排座位的领班"。它负责决定每个活跃会话应该跑在哪块GPU上。当有新会话到来时，它为这个会话找一个当前负载最轻的GPU安家；此后它会持续监测各GPU的负载，一旦发现某台GPU成了"瓶颈"，就把它上面的部分会话迁移走，直到所有GPU的负担趋于均衡。这个过程在每次系统事件（用户到来、离开、活跃状态改变）发生时都会触发。

自动扩缩容控制器（Autoscaling Controller）是"根据订座情况决定开多少间厨房的餐厅总经理"。它接收放置控制器报告的"当前最繁忙GPU的负载比例"，与一个目标利用率做比较，决定是否需要新增GPU（开新厨房）或关闭GPU（关掉空闲厨房）。为了避免因短暂波动频繁开关GPU造成混乱，它引入了一个迟滞机制——只有当负载持续超过目标上限或持续低于目标下限时，才会触发扩缩容。

会话管理器（Session Manager）则是"后台档案室"，负责追踪每个会话的状态：它现在在哪台GPU上运行？它的状态数据存在哪里？如果它暂时空闲，把数据挪到内存里；如果它需要迁移，把数据从一块GPU搬到另一块GPU。

这四个模块形成了一个闭合的控制回路，自动在"服务延迟"和"运营成本"两个目标之间寻找最优平衡点，而且是实时持续地进行调整，永不停歇。

---

五、调度算法的数学灵魂：如何精确定义"最优"

TurboServe把整个服务问题形式化为一个在线调度优化问题，这套数学框架是理解系统设计选择的关键。

核心的优化目标可以用一句话表达：在每个时刻，同时最小化GPU运营成本和最差单片段延迟，两者用一个权重参数来平衡。成本定义为当前运行的GPU数量乘以每块GPU的单价；延迟定义为当前所有活跃会话中，最慢那个会话的单片段生成时间——因为最慢的那个直接决定了"最差用户体验"。

这个双目标优化有一个天然的张力：如果你只在乎延迟，就应该无限制地多开GPU，这样每台GPU上的会话数量极少，速度极快，但成本爆炸；如果你只在乎成本，就应该把所有会话塞进尽可能少的GPU，但延迟会飙升。权重参数的存在让系统可以在这两个极端之间找到一个合理的中间点。

针对这个优化问题，TurboServe设计了两个配套的算法。

放置控制器的算法叫做"迁移感知最小-最大再均衡"。它的工作方式如下：首先保留现有的会话分配不变（减少不必要的迁移），然后找出当前负载最重的GPU，考虑把它上面的某个会话挪到其他某块GPU上。对于每一种可能的迁移方案，算法会计算一个"收益"：迁移后最坏延迟降低了多少，减去迁移本身消耗的时间（基于经典的α-β通信时延模型估算）。如果存在收益为正的方案，就执行收益最高的那个，然后继续重复这个过程，直到找不到任何有正收益的迁移为止。这是一种贪心的局部搜索策略，每次迭代的计算量很小，但在实践中效果接近于穷举最优解。

自动扩缩容控制器的算法叫做"基于迟滞的比例调节"。它实时跟踪当前最大GPU负载比例，与一个目标利用率做比较。一旦负载超过目标利用率加上一个容忍余量，就触发扩容，新的GPU数量按照"把当前活跃会话数量除以目标利用率和单GPU最大并发数的乘积，向上取整"来计算；一旦负载低于目标利用率减去容忍余量，就触发缩容，同样按比例计算应保留的GPU数量。

这两个算法还有一个关键的协同规则：缩容时必须先迁移再关机（把要关闭的GPU上的会话挪走，才能安全关机）；扩容时必须先开机再迁移（新GPU上线后，立刻把过载GPU的部分会话迁移过来利用新资源）。这个先后顺序保证了系统状态始终一致，不会出现会话数据丢失或GPU资源浪费的情况。

---

六、自适应控制参数：系统如何判断当前应该"激进"还是"保守"

一个优雅的设计细节是TurboServe的控制参数自适应机制。目标利用率这个参数并非固定不变，而是会根据当前工作负载的"波动剧烈程度"动态调整。

系统用一个简单的指标来衡量波动程度：在最近一段时间内，每个时间片内新增活跃会话数量的标准差。标准差大意味着用户行为剧烈波动，高峰期和低谷期之间的落差很大；标准差小意味着用户行为比较平稳。

研究团队从历史数据中提取了10个不同波动级别的典型场景，对每个级别分别做了大量模拟实验，找出在满足延迟约束的前提下成本最低的目标利用率组合，形成一张"波动级别→最优参数"的对照表。在实际运行时，系统每次接收到新事件，就计算当前波动水平，查表取出对应参数，更新控制目标。

从实验结果来看，波动最低的第1级场景对应的目标利用率是0.80（即GPU可以用到80%满载），而波动最高的第10级场景对应的目标利用率降低到0.25（GPU只用到25%满载，留出75%的缓冲空间）。这个规律非常符合直觉：在平静的时候把GPU用满以节省成本；在剧烈波动的时候留足余量以应对突然涌来的需求。从第1级到第10级，平均GPU成本大约增加了2.3倍，这正是"为不确定性支付的保险费"。

研究团队还用一个"离线预知未来"的理想对照实验来验证这个自适应机制有多接近理论最优：给对照组系统提前知道未来每个时间窗口内会有多少用户活跃，让它每30秒都能做出完美的扩缩容决策；而TurboServe只能看到过去的历史，不知道未来。结果是，TurboServe的总成本与"预知未来的理想系统"相差仅0.73%。换言之，仅凭对历史波动模式的观察，系统就能捕捉到几乎全部可以节省的成本空间。

---

七、运行时机制：如何让会话"搬家"变得既快又安全

调度算法决定了"应该怎么做"，而运行时机制决定了"能不能高效地做到"。TurboServe在实现层面有几个关键设计。

首先是"批量片段处理"机制。每台GPU上可能同时运行多个活跃会话，如果每个会话的片段生成都要独占GPU跑一遍模型，效率极低。TurboServe把同一台GPU上所有当前"轮到生成下一片段"的会话打包成一个批次，一次性送入模型完成计算，结果再分发给各个会话。这类似于一个厨师一次性炒一大锅不同口味的菜（用隔断分开），而不是挨个一道道炒。这种"合并批处理"大幅提高了GPU利用率。

其次是"GPU-CPU状态卸载"机制。当某个会话进入空闲状态（用户暂时离开），它的状态数据（记忆着之前生成了什么的"记忆文件"）会被从GPU显存复制到普通内存（CPU侧）中保存，GPU的计算资源和显存立刻释放给其他活跃会话使用。等用户回来时，再把数据从内存重新加载回GPU，继续生成。这个设计的核心洞察是：空闲会话不需要占用宝贵的GPU资源，但也不应该被彻底清除——它的历史状态是生成连贯视频的必要条件。

第三个机制是"基于NCCL的GPU间直接迁移"。NCCL是NVIDIA专门为多GPU间高效通信设计的通信库，TurboServe利用它实现了"源GPU直接把状态数据推送给目标GPU"的零中转迁移——数据不需要经过CPU内存中转，大大降低了迁移延迟。迁移只在两个片段生成之间的"空档期"进行，以保证不打断正在进行的生成任务。迁移完成后，系统才更新"这个会话现在归属于哪台GPU"的记录，确保不会出现两台GPU同时为同一个会话生成片段的混乱情况。

每台GPU的内存被组织成三个区域：所有会话共用的模型参数区（最大、最重要、永不移动）；每个会话独有的状态区（记录该会话的历史信息，迁移时只需移动这部分）；以及会话归属表（记录哪个会话在哪台GPU上）。这种分区设计让迁移操作的数据量降到最小——只搬"记忆文件"，不搬"厨房设备"。

实测数据显示，在H20和B300 GPU上，单次会话迁移的平均耗时在23到30毫秒之间，仅占单片段生成时间（约1000毫秒）的2%到3%。对比之下，一旦某台GPU过载导致的延迟惩罚可能高达数百毫秒。由此可见，只要迁移时机选择得当，迁移成本完全可以被延迟收益所覆盖。

---

八、真实数据验证：性能提升有多稳健？

研究团队在生数科技的两套生产集群上进行了全面评测：集群1包含16块NVIDIA H20 GPU，集群2包含64块NVIDIA B300 GPU。测试使用了两种规格的流式视频生成模型（参数量约为1.3B和7B），以及六条从真实生产流量中提取的工作负载轨迹（T1-T6），涵盖了不同的用户规模、会话时长分布和活跃度波动模式。

评测指标分两个维度：在成本相同的前提下比较延迟（谁能用同样的钱提供更快的服务？），以及在延迟约束相同的前提下比较成本（谁能满足同样的速度要求花更少的钱？）。

对比基准选择了三种常见的通用调度策略：最基础的轮询分配加固定GPU数量；负载感知的贪心分配（把新会话分配给当前CPU利用率最低的GPU）；以及内存感知的贪心分配（把新会话分配给当前显存占用最低的GPU）。

在延迟对比方面，TurboServe在所有12个测试场景（2种模型×2个集群×3条轨迹）中均优于所有基准，平均降低最坏延迟37.5%，最大降幅达51.6%。在成本对比方面，TurboServe同样在所有场景中均最优，平均降低GPU运营成本37.2%，最大降幅达49.0%。

消融实验进一步确认了每个机制的独立贡献：去掉迁移功能后，成本平均增加15.0%（最多增加28.0%）；去掉自动扩缩容功能后，成本平均增加42.9%（最多增加80.4%）。两者相比，自动扩缩容对成本的贡献更显著，因为它直接决定了"开多少GPU"这个最根本的成本驱动因素；迁移的贡献在于提高资源利用率、减少为了应对负载不均而不得不多开的"保险GPU"数量。

在调度算法效率方面，迁移感知最小-最大再均衡算法在64块GPU规模的集群上完成一次调度决策只需不到15毫秒，不到单片段生成时间的2%。与理论最优的穷举搜索相比，TurboServe的解与最优解的平均差距仅3.6%（最大6.5%），但计算速度快了10倍以上。

一份12分钟的调度快照清晰地展示了系统在实际运行中的行为模式：在前两分钟内，GPU数量从8块先收缩至1块再逐步扩展到6块（系统在适应初始负载）；在接下来的几分钟里随着工作负载增加，GPU数量稳步扩张到11块；在后半段随着部分会话结束，GPU数量回落并稳定在4到8块之间。与此同时，每个两分钟窗口内都有20到70次不等的会话迁移发生，持续地平衡各GPU之间的负载分布。

---

说到底，TurboServe解决的问题听起来很"后台"——用户压根不会看到什么调度算法或GPU迁移，他们感受到的只是视频流不卡顿、生成速度够快。但正是这些隐藏在幕后的系统设计，决定了一款AI视频产品能否在大规模用户场景下真正可用，以及运营这款产品的成本是否可以承受。

TurboServe的核心洞见可以提炼为一个简洁的系统哲学：静态配置无法应对动态世界，任何时刻的"最优配置"都只在那个时刻成立，而流式服务的本质是时间演化的，因此服务系统必须是持续自适应的。把"会话去哪台GPU"和"要开多少台GPU"这两个决策放进同一个闭合控制回路，让它们互相反馈、协同调整，正是TurboServe能同时降低延迟和成本的根本原因。

还有一个值得思考的启示：当AI应用从"批处理"转向"流式交互"，整个服务基础设施的设计逻辑都需要重新审视。LLM服务领域已经为此积累了大量经验，但流式视频生成在"状态生命周期"和"延迟约束"两个维度上与LLM服务有本质区别，照搬LLM的调度方案并不适用。TurboServe的工作在某种意义上是为流式视频服务划定了一个新的研究领域的起点——这个领域还有大量问题尚待探索，比如跨数据中心的会话迁移、更复杂的用户行为预测模型、以及异构GPU集群上的动态配置等。有兴趣深入了解的读者，可以通过arXiv编号2606.19271查阅完整论文，或访问项目代码库 github.com/shengshu-ai/TurboServe 获取实现细节。

---

Q&A

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

A：TurboServe的迁移设计专门避免了这个问题。迁移只在两个视频片段之间的"空档期"进行，不会打断正在进行的生成计算。系统采用三步一致性协议：源GPU完成当前片段后冻结状态数据，目标GPU拉取并验证数据完整性，最后才更新会话归属记录。由于迁移的是完整的历史状态（包括KV缓存等时序信息），目标GPU可以从完全相同的断点继续生成，用户看到的视频在风格和内容上保持连贯，不会出现明显断层。

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

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

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

A：TurboServe通过预先准备好的基础设施来最小化这个延迟。在生数科技的集群管理系统中，每台GPU服务器的容器镜像、运行环境和模型参数检查点都已经预先缓存在本地存储上，扩容时无需从远端拉取镜像或下载模型权重。扩容操作分两步：集群管理器分配GPU并将其加入TurboServe服务池，然后TurboServe在本地加载模型并完成热身。由于避免了网络传输瓶颈，这个过程比传统云端冷启动快得多，足以在需求高峰真正到来之前完成准备。