← 返回 2026-07-21

FlashRT:引导编码智能体部署实时多模态应用的智能体框架 FlashRT: Agent Harness for Guiding Agents to Deploy Real-Time Multimodal Applications

Krish Agarwal, Zhuoming Chen, Yanyuan Qin, Zhenyu Gu, Atri Rudra, Beidi Chen 📅 2026-07-20 👍 6 2026-07-25 18:30
NP难调度 多GPU部署 多模态服务系统 实时系统 智能体编排 流式推理 编译中间表示

用编码智能体把简单参考实现自动转化为高效多 GPU 部署的实时多模态服务框架

前置知识

流水线并行(Pipeline Parallelism, PP)

流水线并行是一种把模型执行过程按阶段切分、并把不同阶段放到不同计算资源(如不同 GPU)上执行的并行策略。关键前提是相邻阶段之间没有跨阶段的共享持久状态——否则后一阶段某 batch 必须等前一阶段同一 batch 完成,无法跨 batch 重叠。在本文 DiT(扩散 Transformer)+ VAE 两阶段视频生成流水线中,DiT 与 VAE 不共享 KV cache,故可把 DiT 放一组 GPU、VAE 放另一组,让 batch j 的 VAE 解码与 batch j+1 的 DiT 去噪同时进行。更细地,当 DiT 每个去噪步维护独立 per-step KV cache 时,不同去噪步之间也无跨 batch 依赖,可把 n 个去噪步各放一卡形成 stage pipeline parallelism,把可持续周期从 $nT_Q^{SP}(n)$ 降到 $T_Q$。

理解流水线并行是读懂本文性能收益的前提。论文 Appendix A.4 证明,在亚线性序列并行加速($T_Q \le nT_Q^{SP}(n)$)下,stage pipeline parallelism 的可持续周期 $T_{\min}(\rho_{PP}) = T_Q$ 不大于序列并行的 $nT_Q^{SP}(n)$,故帧率更高——这正是 8 GPU 案例研究里 S2V 帧率暴涨到 173.67 FPS 的根源(DiT1–DiT4 各占一卡)。同时流水线并行引入跨卡同步延迟 $\kappa$ 使首帧延迟略增,这解释了为何延迟优化与帧率优化往往是两套不同部署。

序列并行(Sequence Parallelism, SP)

序列并行(SP)指把单个算子(如一次 DiT 去噪步)的输入序列沿序列维度切分到一组 GPU 上并行计算,n 张卡的组记为 SP-n。与流水线并行不同,SP 不切分阶段而是切分同一阶段内部的数据,所有卡协作完成同一算子实例。SP 加速通常亚线性,即 $T_Q^{SP}(n) \ge T_Q/n$,因引入通信与同步开销;论文明确采用假设 $T_Q \le nT_Q^{SP}(n)$ 而不假设线性加速。SP 度越高单个算子实例越快,从而缩短串行关键路径、利于降低延迟;但它不改变'同一资源每 batch 仍要执行全部阶段'的事实,故对帧率的提升受限于各阶段执行时间之和。

SP 是本文延迟优化部署的主要杠杆。Appendix A.3/A.4 的成本模型显示,延迟关键路径权重 $w(P,\rho)$ 由各阶段执行时间之和给出,co-location 下 $d_0^* = T + d(k) + v(k)$,其中 $k$ 即 SP 度——SP 度越高 $d(k),v(k)$ 越小延迟越低。WorldPlay 在 2→4 GPU 共置部署中延迟从 493ms 降到 425ms,正是 SP-2→SP-4 缩短了串行路径。同时亚线性加速也是收益递减的来源:DiT 组每翻倍带来的帧率增长越来越慢,这限制了纯靠堆 GPU 提升帧率的上限。

共置与拆分(Co-location vs Disaggregation)

共置(co-location)指把多个流水线阶段放在同一组 GPU 资源上串行执行,因数据不跨组,同步延迟 $\kappa_{u,v,0}(\rho_{col})=0$,关键路径最短故延迟最低;代价是同一资源每 batch 必须串行执行全部阶段,可持续周期 $T_{\min}$ 由各阶段时间之和决定、吞吐受限。拆分(disaggregation)则把不同阶段放到互不相交的 GPU 组上,使不同 batch 的不同阶段能在各自资源上并行重叠,可持续周期降到 $\max(d(k_D), v(k_V))$(取较慢阶段)、帧率提升;代价是跨组传输引入 $\kappa_{u,v,0} > 0$ 使首帧延迟增加。论文 Appendix A.3 严格证明:在'赋予阶段全部资源不慢于子集'的温和假设下,co-location 最小化 $d_0^*$,而拆分可在 $T_{\min}$ 上更优。

这是贯穿全文全部实验的核心权衡,几乎所有结果表(Table 4/6/8/9)都呈现'同预算下延迟优化=共置、帧率优化=拆分'的对偶。例如 WorldPlay 2 GPU:共置 SP-2 得 493ms/25.5 FPS,拆分得 625ms/31.0 FPS。理解这一对偶才能读懂为何 FlashRT 在每个预算都同时给出两种部署变体,以及为何 Appendix B 说'在匹配 SP 度下拆分几乎不增加延迟却显著提升帧率'——因为延迟跟踪串行求和 $d(k)+v(k)$ 而帧率跟踪流水线取最大值 $\max(d,v)$,两者响应加 GPU 的机制不同。

中间表示(Intermediate Representation, IR)

中间表示(IR)是编译器在把前端源码逐步 lowering 到后端机器码过程中使用的、与具体前后端解耦的结构化程序表示,使每个编译 pass 聚焦一个变换。FlashRT 借鉴该思想,让智能体把人类参考实现先转写成层次化有向无环图(DAG)IR:顶层图建模整体应用工作流,嵌套子图刻画可暴露的模型内计算(如 DiT 去噪步);节点封装自包含操作,边表示数据依赖。IR 之上挂三类关键标注:图层次性、节点级持久状态读写(恢复 $\lambda=1$ 跨 batch 状态依赖边)、边级 blocking/streaming 标注。FlashRT 还提供一个顺序解释器,可按拓扑序执行 IR 并与基线在同样输入上逐元素比对,验证 IR 正确性。

IR 是 chain-of-program 范式的核心载体,是消除 naive 智能体两类失败的关键。naive 智能体之所以漏掉 S2V 流水线并行、单次只抓一个优化轴,正因为它试图一步直译;强制先建 IR、做静态分析,迫使智能体在多粒度上系统性暴露并行与流式机会。论文强调'节点级状态标注恢复跨 batch 边、边级流式标注标出重叠点',这些正是规则系统无法定义的异构最优粒度。没有 IR 这一层,agent-driven 部署的鲁棒性就无从谈起,也就没有后续变体队列的可靠初始化。

TTFO 延迟与可持续周期

论文用两个形式化量刻画部署好坏。TTFO 用最小可行显示偏移 $d_0^*(\rho,A) = \sup_{j,k}(Y_{j,k} - jT - k\Delta)$ 衡量,其中 $Y_{j,k}=C_{j,o(k)}$ 是 chunk $(j,k)$ 变为可显示的时刻,$T$ 为 batch 周期、$\Delta=T/N$ 为子区间;越小越好。其下界由关键路径给出(Lemma A.2):$d_0^* \ge w(P,\rho) + (1-\Lambda(P))T - k\Delta$,即延迟由从入口到输出的最重逻辑路径决定。可持续吞吐用最重负载资源周期 $T_{\min}(\rho) = \max_{r\in R} W_r(\rho)$、$W_r(\rho)=\sum_{v:\rho(v)=r}\tau_v(\rho)$(Lemma A.3)衡量;峰值显示帧率为 $N/T_{\min}$。这两个量精准编码'co-location 降 $d_0^*$、disaggregation 降 $T_{\min}$'的对偶。

这两个量是全部实验指标的数学根基。理解了 $d_0^*$ 由关键路径权重决定、$T_{\min}$ 由最重资源负载决定,就能看懂为何共置(短路径、无 $\kappa$)优化延迟、拆分(负载摊薄到多资源)优化帧率。论文还借此在 Appendix A.2 把部署搜索归约到经典非抢占式多机调度 $P||C_{\max}$ 证明其 NP 难,从而论证'最优部署既不能由固定策略规定也不能精确求解,必须靠智能体联合推理程序结构、资源分配、调度与并行'这一核心立论,是全文理论基石。

研究动机

实时多模态应用(语音智能体、交互式视频生成等)把异构模型组合成复杂流水线,其高效部署需要在放置(placement)、流式(streaming)和模型内并行(intra-model parallelism)上做应用相关的决策。现有系统存在三类硬伤:第一,vLLM-Omni、Cornserve、ModServe 等多模态框架虽提供抽象,但只能执行静态部署策略(强制阶段间拆分、阶段内共置);第二,FlexFlow、GSPMD、Alpa、Unity 等自动并行系统只能针对单一固定负载(稠密 DNN 训练)选择切分,无法泛化到由不相交运行时组成的异构推理流水线;第三,TVM、TASO、Halide 等编译器只优化算子级,碰不到设备放置、阶段重叠等关键决策。因此每出现一个新应用都要专家手工打造高效实现,而新应用数量持续增长,手工方式不可扩展。作者还在第 3 节证明该部署问题即便在无依赖、无通信、单一 batch 退化为非抢占式多机调度时也是 NP 难的。

本文的目标是构建一个理想的服务系统:让开发者只需写出直观、未优化、单 GPU 的参考实现,系统就能自动为每个应用的个体需求派生出专用系统基础设施,并能灵活地在延迟与吞吐等目标之间权衡。具体而言,目标是输入同步单 GPU 参考实现 $P_{ref}$(定义应用语义与持久状态作用域),输出一个在行为等价前提下使用拆分、共置、流式和模型内并行的多 GPU 部署 $P_{dep}$,并使应用级指标(如 TTFO 延迟、可持续帧率)达到或超过专家手工系统,且整个过程除提供参考实现外无需人工干预。系统应同时满足三个理想性质:不受限的部署范围、负载灵活性、自适应优化粒度。

与已有工作不同的是,本文的独特切入点是认识到编码智能体(coding agent)天然具备为复杂多模态流水线编写高效端到端实现的能力——它能用高层推理在自适应、异构的粒度上组织目标流水线,从而缩小部署搜索空间。这与基于规则的系统有本质区别:规则系统要么被固定部署策略锁死,要么面对核级这种过大搜索空间而失效,而最优粒度本就应在不同流水线组件间异构存在,规则系统甚至无法正确定义该粒度。作者的关键洞察是:智能体能像人一样跨粒度推理,但直接单步把基线翻译成部署会失败,因此需要 chain-of-program 式的分层规划与自驱动验证循环来约束智能体。这是把'智能体做系统优化'从核级扩展到端到端多模态部署的首次尝试。

核心方法

FlashRT 的整体思路是:与其手工为每个应用写高效实现,不如用编码智能体去'读'参考实现、'推理'其结构、再'生成'应用专用部署。直觉上类比两点——一是大模型的 chain-of-thought(先推理再回答),二是编译器通过中间表示把前端逐步 lowering 到后端。据此 FlashRT 设计了 chain-of-program 范式:智能体先把用户参考实现转写成结构化 IR 以显式化数据依赖与持久状态作用域,再用顺序解释器验证 IR 正确性,再做静态分析识别候选变换,最后进入测量门控的优化循环迭代地实现、验证、基准测试每个候选。该流程全程由通用编码智能体自主完成,无需人工提示部署策略,且能自适应地为每个应用探索从应用级到模型级的异构粒度优化,最终在不同硬件预算下灵活权衡 TTFO 延迟与系统吞吐。

核心创新是两点结合:(1) chain-of-program 的分层规划——不让智能体在单一巨型步骤里直译,而是先建 IR 再翻译。IR 强制暴露三个结构属性:图层次性(顶层应用图 + 嵌套的模型内图,迫使智能体考虑多粒度优化而非只盯高层工作流)、节点级状态标注(每个节点声明持久状态读写,恢复跨 batch 的 $\lambda=1$ 状态依赖边,从而阻止智能体漏掉拆分/流水线机会)、边级流式标注(每条数据边显式标 blocking 或 streaming,标出消费者可提前启动的重叠点)。(2) 应用接地的验证循环——智能体不只提出假设并实现,还自己设计模拟真实用户体验的测试夹具(向前端输入缓冲写、从输出缓冲读),把正确性与延迟/吞吐测量绑定到真实用户交互。这与已有核级智能体工作的本质区别在于:核级正确性与性能有明确定义,而多模态流水线高度应用相关,必须靠接地测试来定义。

方法步骤详情

完整步骤如下:① 输入同步单 GPU 参考实现 $P_{ref}$,仅给定应用与 GPU 预算,不提示任何部署策略。② 智能体把参考实现转写为层次化 DAG IR:构建顶层应用图与嵌套的模型内图,节点封装自包含操作,边表示数据依赖;对每个节点标注持久状态读写(对应 $\lambda=1$ 跨 batch 边),对每条数据边标注 blocking/streaming。③ 智能体用提供的顺序解释器在相同样例输入上执行基线与 IR,逐元素比较输出以确认 IR 正确。④ 智能体调用提供的静态分析工具,扫描 IR 图、边依赖与共享持久状态,确定性地找出可并行节点与流式机会。⑤ 由 IR 分析初始化一个'变体队列',每个变体是一条带合法性理由与瓶颈目标的候选变换。⑥ 每轮迭代:智能体先提假设(命名变换分析与目标瓶颈),在隔离环境实现该变体,再做逐元素输出等价性验证,出错则调试;通过后基准测试延迟与吞吐。⑦ 智能体用测量结果更新队列:追加结果暗示的新变体、按预期影响重排待测变体。⑧ 循环仅当所有变体均被测量或因文档化原因移除时终止。⑨ 输出能在不同硬件预算下灵活权衡 TTFO 延迟与吞吐的多 GPU 部署 $P_{dep}$。

技术新颖性

技术新颖性体现在四个方面。其一,这是首个把编码智能体用于跨多个模型运行时的端到端多模态部署优化(而非仅核级生成或局部代码优化),填补了服务系统与算子编译器之间的粒度空白。其二,chain-of-program 范式把 chain-of-thought 与编译器多 pass lowering 的思想迁移到智能体部署:用层次化 IR(图层次、状态标注、流式标注三属性)显式化那些规则系统无法定义的异构最优粒度,从而可靠地暴露拆分与流水线机会。其三,自驱动验证循环配合'自演化变体队列'强制智能体既探索多样化策略又考虑策略组合(通过重评估机制),解决了 naive 智能体单次只抓一个优化轴的痛点。其四,应用接地的测试夹具让智能体在没有真实前端的情况下,仍能按模拟用户交互定义正确性与测量指标,把高度应用相关的验证变得可自动化。这些设计共同让一个通用智能体无需人工干预即可在 B200 与 MI355X 上泛化到高度多样的应用。

不同智能体工作流总览:(a) FlashRT 输入示例;(b) naive 智能体的结果;(c) FlashRT 如何消除失败模式。
Figure 2: 不同智能体工作流总览:(a) FlashRT 输入示例;(b) naive 智能体的结果;(c) FlashRT 如何消除失败模式。

实验结果

核心发现可归纳为四点。其一,案例研究(面对面会话智能体)展示智能体能按 GPU 预算逐级组合优化轴:单 GPU 仅靠 TTS 分块流入 S2V 的流式就把 TTFO 从 107.92s 降到 3.94s(27.4×);8 GPU 再叠加 TTS/S2V 拆分与 S2V 去噪步流水线并行,帧率飙到 173.67 FPS,总延迟降幅约 70×。其二,与专家系统正面对比:Qwen3-Omni 上 FlashRT 用 3 GPU 达 0.323s,比专家 vLLM-Omni 的 0.433s 低 25%,证明智能体生成部署可击败人工实现。其三,泛化到视频背景编辑器、WorldPlay、LongLive 等额外应用,在每个预算都自动给出延迟优先(共置高 SP 度)与帧率优先(拆分流水线)两种部署,精确印证附录 A.3/A.4 的共置/拆分对偶。其四,跨硬件泛化:AMD MI355X 同样复现这些部署族与权衡,最高 70× 延迟降幅、3.6× 吞吐,Qwen3-Omni 上 0.276s 击败 vLLM-Omni 0.779s(低 65%),证明智能体驱动优化在工程成熟度较低平台增益更大。

面对面会话智能体:顺序用户基线与 FlashRT 智能体在 1/3/8 GPU 下若干部署的对比。
Table 1: 面对面会话智能体:顺序用户基线与 FlashRT 智能体在 1/3/8 GPU 下若干部署的对比。
LiveAvatar 会话智能体部署的放置 ρ(约定同 Table 7);顺序基线与流式部署省略(全部节点在一卡)。
Table 2: LiveAvatar 会话智能体部署的放置 ρ(约定同 Table 7);顺序基线与流式部署省略(全部节点在一卡)。
FlashRT 与手工工程化的 vLLM-Omni 部署在 2 GPU 上服务 Qwen3-Omni 的对比。
Table 3: FlashRT 与手工工程化的 vLLM-Omni 部署在 2 GPU 上服务 Qwen3-Omni 的对比。
视频背景编辑器:智能体发现的部署与顺序基线的对比。
Table 4: 视频背景编辑器:智能体发现的部署与顺序基线的对比。
视频背景编辑器部署的放置 ρ;延迟优化版把 DiT 与 VAE 共置于 4 GPU,帧率优化版把 VAE 拆到第 5 卡。
Table 5: 视频背景编辑器部署的放置 ρ;延迟优化版把 DiT 与 VAE 共置于 4 GPU,帧率优化版把 VAE 拆到第 5 卡。
WorldPlay 在 1 与 2 GPU 下的部署对比。
Table 6: WorldPlay 在 1 与 2 GPU 下的部署对比。
WorldPlay 延迟/帧率优化部署在 2 GPU 上的放置 ρ。
Table 7: WorldPlay 延迟/帧率优化部署在 2 GPU 上的放置 ρ。
LongLive 视频解说在 1 与 2 GPU 下的部署对比。
Table 8: LongLive 视频解说在 1 与 2 GPU 下的部署对比。
FlashRT 智能体在 AMD MI355X 上为全部五个应用从零重优化的部署(同参考实现与同 GPU 预算)。
Table 9: FlashRT 智能体在 AMD MI355X 上为全部五个应用从零重优化的部署(同参考实现与同 GPU 预算)。
查看结构化数据
任务指标本文基线提升
面对面会话智能体(LiveAvatar)TTFO 延迟 Latency (s) 1.66(8 GPU 流式+拆分+S2V 流水线并行) 107.92(1 GPU 顺序基线) 约 70× 延迟降低
面对面会话智能体帧率 Frame rate (FPS) 173.67(8 GPU) 基线离线生成不可播放(记为 –) 从不可实时播放到 173.67 FPS 实时可播放
Qwen3-Omni 文本转语音响应延迟(B200) Latency (s) 0.323(3 GPU,RTF<1) 0.433(vLLM-Omni 3 GPU 专家实现) 延迟降低 25%
Qwen3-Omni 响应延迟(AMD MI355X) Latency (s) 0.276 0.779(vLLM-Omni) 延迟降低 65%
视频背景编辑器(Krea-Realtime+SAM3)延迟 Latency (ms) 491(4 GPU 延迟优化) 1715(1 GPU 顺序) 延迟降低 3.5×
视频背景编辑器帧率 Frame rate (FPS) 19.41(5 GPU 帧率优化) 6.82 帧率提升 2.8×
WorldPlay 视频世界模型(6 GPU 综合优化) Latency / FPS 447ms / 44.3 FPS 869ms / 20.4 FPS 延迟降约 51%,帧率约 2.2×
LongLive 视频解说(8 GPU 帧率优化) Latency / FPS 462ms / 67.4 FPS 674ms / 25.8 FPS 延迟降约 1.6×,帧率约 2.6×

局限与改进

作者明确承认两点局限:一是尚未集成 LLM 核优化智能体,因此加速只能来自在给定算子上组合部署策略,SP 加速始终是亚线性的,核级重写可能进一步释放性能;二是实验只测了一种智能体配置(Claude Opus 4.8,effort=max),未测试换模型、降低推理深度或修改智能体脚手架时框架如何表现。从结果本身还可观察到:B200 与 MI355X 上视频背景编辑器帧率难以同比例提升,因 MI355X 上被 SAM 3 分割路径卡住,拆分 VAE 几乎不再带来额外吞吐;亚线性 SP 加速意味着 DiT 组每翻倍收益递减,帧率增长慢于 GPU 数。此外,naive 智能体在案例研究中出现的两类失败(漏掉模型级流水线并行、单次只抓一个优化轴)虽被 FlashRT 工作流消除,但读者无法从论文直接获知该工作流对更弱智能体是否仍鲁棒。

独立分析的弱点

第一,成本与确定性:全程调用 Claude Opus 4.8 且 effort=max,单应用迭代多轮,API 调用与运行时开销高,论文也未报告端到端 agent 运行耗时与 token 消耗,更未给出多次重复运行的结果方差,工程落地难以预估成本与稳定性。改进方向是引入轻量模型 + 缓存 IR 分析、对变体队列做并行探索以降本,并报告成功率与方差。第二,强依赖智能体能力:框架效果高度依赖智能体的推理与代码能力,论文只验证一种配置,若换更弱模型或更低 effort,chain-of-program 与验证循环是否仍能稳定发现 S2V 流水线并行未经验证。改进方向是做智能体消融与失败注入研究。第三,缺乏核级优化闭环:亚线性 SP 加速是性能天花板,未集成核优化智能体导致大 GPU 预算下收益递减明显。改进方向是把核优化智能体接入变体队列,让粒度可下沉到算子内部。第四,应用集偏窄且多为'有清晰拆分结构'的应用:对于状态耦合更强、依赖更复杂的应用(如多轮记忆、强化式 VLA),IR 状态标注与拆分合法性是否仍易被智能体识别存疑。改进方向是扩展到更耦合的应用并量化 IR 分析的漏检率。

未来方向

作者明确点名的未来工作有两项:集成 LLM 核优化智能体以拓宽优化空间;测试框架在修改智能体设置(换模型、降推理深度、改脚手架)下的表现。基于成果可延伸的方向包括:把 chain-of-program 范式推广到训练侧(如多模态训练流水线的自动并行与放置),因为本文的 NP 难论证同样适用于训练;把 IR 与变体队列做成可被人类专家增补约束的协作接口,让专家以'硬约束/软提示'形式注入领域知识再交回智能体;研究在线自适应部署——当负载模式或硬件可用度变化时,让智能体增量式重排而不是从零重跑;将应用接地测试夹具扩展为在线 A/B 与真实流量回放,使优化目标更贴近生产指标;以及理论上刻画 chain-of-program 在何种应用类上具备 PAC 式保证,把当前的经验性'更鲁棒'形式化。

复现评估

复现友好度较高。论文提供了 GitHub 仓库(Infini-AI-Lab/FlashRT)与项目网站,代码与示例可获取。实验使用标准公开模型:Qwen3-ASR、Qwen3-4B、Qwen3-TTS、Qwen3-Omni、LiveAvatar、HY-WorldPlay 5B、LongLive-2.0-5B、Krea-Realtime、SAM 3,参考实现风格在图 2a 给出伪代码。硬件门槛较高:需 8×NVIDIA B200 或 8×AMD MI355X 节点,对多数研究组不友好;但部署族(共置/拆分/SP/PP)与 Appendix A 的成本模型可在更小 GPU 上部分复现定性结论。智能体侧固定使用 Claude Code + Claude Opus 4.8(effort=max,Auto 权限模式),这意味着复现还需 Anthropic API 访问与相应费用,且由于大模型采样非完全确定性,多次运行可能略有差异——论文未给出方差或种子。整体难度中等偏高:代码与参考实现开源降低了门槛,但旗舰 GPU 与高端闭源智能体 API 是主要瓶颈。