这项由卡内基梅隆大学、AMD和纽约州立大学水牛城分校联合开展的研究以预印本形式于2026年7月20日发布在arXiv平台编号为arXiv:2607.18171v1研究领域归属于机器学习cs.LG。**研究概要当AI应用越来越复杂部署却越来越头疼**近年来语音助手、实时视频生成、AI驱动的虚拟形象这类多模态应用正在以惊人的速度涌现。所谓多模态通俗来说就是同时处理多种信息类型的系统——比如既能听你说话、又能看懂图像、还能生成视频的AI应用。这类应用并不是一个单一的AI模型而是把多个不同类型的模型像流水线一样串联起来先用语音识别模型把你的话转成文字再用大语言模型生成回复然后用文字转语音模型把回复读出来最后用视频生成模型把虚拟人物的嘴巴动作配上去。问题是要让这条流水线跑得既快又稳需要大量专业工程师手工调试——决定哪个模型放在哪块GPU上运行数据怎么在模型之间传递多块GPU之间如何分工协作。每开发一个新应用就得重新做一遍这套工作。随着应用种类越来越多这种纯靠人力的方式显然撑不住了。卡内基梅隆大学等机构的研究团队针对这个痛点开发了一套名为FlashRT的系统。它的核心思路是让AI编程智能体一种能自主写代码和调试的AI来替代人类工程师自动把开发者写的简单、低效的参考代码转化成在多块GPU上高效运行的优化部署方案。实验结果显示FlashRT能将某些应用的响应延迟降低约70倍吞吐量可以理解为单位时间内处理任务的能力提升最高3.6倍甚至在某些场景下超越了专业工程师手工优化的方案。---**一、为什么这个问题如此棘手**先来理解一下部署这件事的难度所在。假设你是一家餐厅的老板厨房里有好几个厨师对应多块GPU你需要安排谁做前菜、谁做主菜、谁做甜点以及什么时候开始做、做好的菜怎么传递给下一道工序。如果只有一桌客人单任务、低吞吐量最优方案可能是让所有厨师合力做每一道菜速度最快但如果有很多桌客人高吞吐量最优方案则是让不同厨师专门负责不同菜品流水线作业。这两种目标之间存在根本性的矛盾没有一种固定安排方案能同时做到两者最优。多模态AI应用的部署也是同样的道理。研究团队在论文中用严格的数学方式证明了这个问题是NP难的——这是计算机科学中的一个专业说法意思是找到全局最优解在计算上极其困难甚至不可能在合理时间内穷举完所有可能性。具体而言他们将多模态部署问题形式化为一个任务图每个计算步骤是图中的一个节点节点之间的数据依赖关系是图中的边。当有多块GPU资源可用时如何把这些节点分配到不同GPU上、如何安排执行顺序就构成了一个调度优化问题而这个问题在数学上可以规约为经典的多机器调度最短完工时间问题后者已被证明是NP难的。现有的一些系统试图自动化这个过程但各有局限。像vLLM-Omni和Cornserve这样的多模态服务框架提供了不错的抽象但它们只支持固定的部署策略比如两个模块之间必须完全分离或同一模块内部必须全部放在一起无法根据具体应用灵活调整。像FlexFlow、GSPMD、Alpa这类自动并行化框架擅长处理深度学习训练任务但对推理流水线和异构模型的组合就力不从心了。像TVM这类编译器框架只优化算子级别的计算不涉及模型之间的调度和放置决策。正因为现有工具都有各自的局限研究团队转向了一个新的方向既然规则化的系统解决不了这个问题能不能让AI自己来想办法---**二、AI编程智能体能做什么又会犯什么错**近年来AI编程智能体在自动写代码和优化代码方面取得了显著进展。研究团队的核心洞察是编程智能体具备人类工程师那种从高层理解整个流程、在不同粒度上灵活思考的能力而这正是解决多模态部署问题所需要的。但是直接把任务扔给智能体——给你一段代码帮我优化成高效的多GPU部署方案——效果并不理想。研究团队在论文中详细描述了两种典型的失败模式通过一个具体案例来说明。这个案例是一个面对面对话智能体用户说话系统通过语音识别把话转成文字再通过大语言模型生成文字回复再通过文字转语音模型合成语音最后通过声音驱动视频模型LiveAvatar生成一个虚拟人物在说话的视频把音视频同步后返回给用户。整个流程用了四个模型分别是Qwen3-ASR语音识别、Qwen3-4B语言模型、Qwen3-TTS文字转语音和LiveAvatar声音转视频。当研究团队给智能体一段简单的单GPU顺序执行代码要求它优化吞吐量也就是每秒能生成多少帧视频时智能体暴露出两个问题。第一个问题是它只看到了应用层面的优化机会却看不到模型内部的优化机会。智能体注意到了可以让TTS模型生成一段音频后就立刻传给视频生成模型处理而不是等TTS全部做完再传这叫流式传输streaming。但它没有意识到LiveAvatar内部的视频扩散模型DiT的每一个去噪步骤都有独立的KV缓存意味着不同去噪步骤可以放在不同GPU上流水线并行执行。它选择了把所有去噪步骤放在同一组GPU上用序列并行的方式运行——这能降低延迟但不能提升吞吐量。第二个问题是不同运行结果之间不稳定。有时候智能体只关注应用层的流式传输优化完全忽略模型层有时候又只关注模型层的并行优化忽略应用层。它无法在单次运行中同时发现和组合多种优化策略。这两个问题说明单纯扔任务的方式行不通需要给智能体一个结构化的工作流程。---**三、FlashRT的核心设计给智能体配上流程图和自我检验机制**FlashRT的设计围绕两个核心思路展开分别解决上述两个失败问题。第一个思路叫做程序链范式chain-of-program灵感来自于大语言模型领域著名的思维链技术——与其让模型直接跳到答案不如让它先一步步推理最后再给出结论。类似地FlashRT不让智能体直接把用户代码改成优化版本而是要求它先把用户代码转化成一个结构化的中间表示IRIntermediate Representation然后在这个中间表示上进行分析最后再生成优化部署方案。这个中间表示本质上是一张描述应用流程的流程图由节点和边构成。节点代表各个计算步骤比如运行语音识别、运行语言模型的第3个去噪步骤边代表节点之间的数据依赖关系。这张图有三个特别重要的设计。首先是层级结构。智能体必须生成一个层级化的图顶层图描述整个应用的工作流程底层嵌套图描述每个模型内部的计算结构。这样一来智能体被迫同时考虑应用层和模型层两个粒度不会只盯着其中一个。其次是节点级别的状态标注。对于图中每个节点智能体必须明确标注它会读取或写入哪些持久状态——所谓持久状态就是跨越多个输入批次保留下来的数据比如KV缓存语言模型为了加速生成而缓存的历史计算结果。如果两个节点共享同一份持久状态那它们就必须按顺序执行如果两个节点的持久状态完全不相交那它们就可以被放到不同GPU上并行执行。通过这个标注机制哪些部分可以解耦、放到不同GPU上这个关键问题就变得一目了然了。第三是边级别的流式传输标注。对于图中每条边即两个节点之间的数据依赖智能体必须明确标注这条边是阻塞的还是流式的。阻塞意味着下游节点必须等上游节点全部完成才能开始流式意味着下游节点可以在上游节点只完成了一部分时就开始处理那一部分。比如语言模型生成文字之后才能开始文字转语音这是阻塞的但文字转语音生成了一段音频之后就可以立刻开始生成视频这是流式的。流式边指出了可以在不同GPU上重叠执行的机会而阻塞边则倾向于把相关节点放在一起。完成中间表示的构建之后FlashRT还给智能体配备了几个分析工具。这些工具会自动分析图的结构和数据依赖关系找出哪些节点可以并行化、哪里存在流式传输的机会并以一种结构化的形式反馈给智能体让后续分析更加可靠、系统。此外还有一个IR解释器能把智能体生成的中间表示图按照拓扑顺序顺序执行智能体可以用它来验证自己的中间表示图是否与用户原始代码的行为一致。第二个思路叫做应用感知的验证循环application-grounded validation loop解决的是智能体生成的部署方案可能有错误、或者只探索了部分优化空间的问题。FlashRT设计了一套自驱动的迭代循环。每一轮迭代智能体提出一个优化假设比如我猜把TTS模型和视频生成模型放到不同GPU上并流式传输能提升吞吐量然后实现这个假设验证正确性最后进行基准测试。验证的方式很关键。智能体无法真的把整个应用前端都运行起来但它可以写测试代码模拟用户输入把输入写入系统的输入缓冲区然后从输出缓冲区读取结果——这和真实用户与系统交互的方式完全一致。通过这种方式智能体可以对比自己的实现和原始参考代码的输出是否完全一致逐元素比对从而发现错误同时通过记录写入输入和读取输出之间的时间差测量真实的端到端延迟和吞吐量。这些通过测试后智能体会把测试结果用于更新一个变体队列——这个队列记录了所有待探索的优化方向并根据测试结果动态调整优先级、添加新的候选方向。比如如果流式传输确实有效智能体会进一步考虑能不能在此基础上再加上模型内部的流水线并行。循环终止的条件是队列中所有待验证的方向都已经被测试过或者被明确排除。---**四、实验一面对面对话智能体70倍延迟压缩是怎么做到的**研究团队用上文提到的面对面对话智能体进行了详细的案例研究结果展示了FlashRT的强大之处。起点是一段顺序执行的单GPU参考代码。这段代码按照语音识别→语言模型→文字转语音→视频生成的顺序一步步等待每个模型全部完成后再进入下一步最终输出音视频。整个流程耗时107.92秒而且必须等全部完成才能开始播放没有帧率这个概念。FlashRT在单GPU上发现的第一个优化是流式传输TTS模型每生成一小段音频就立刻传给LiveAvatar开始生成对应的视频帧不用等TTS全部完成。这个优化把首帧延迟即用户说完话到看到第一帧视频响应的时间从107.92秒降到了3.94秒——降幅约27.4倍。同时视频帧率达到了16.26 FPS每秒帧数。但单GPU上TTS和视频生成还是在抢同一块资源帧率有限。扩展到3块GPU之后FlashRT进一步发现了解耦优化把TTS模型和视频生成模型放到不同GPU上这样TTS在生成第N段音频的时候视频生成可以同时处理第N-1段音频真正实现了并行。结合流式传输延迟进一步降到了1.57秒帧率提升到40.88 FPS——比单GPU方案快了2.5倍。扩展到8块GPU之后FlashRT发现了第三个优化LiveAvatar的视频扩散模型内部有4个去噪步骤每个步骤的KV缓存彼此独立批次N的步骤i只依赖批次N-1的步骤i而不依赖批次N的步骤i-1之前的所有步骤因此可以把4个步骤分别放在4块GPU上像接力赛一样流水线执行。配合TTS与视频生成的解耦这个方案把帧率推高到了173.67 FPS延迟保持在1.66秒与3GPU方案相差无几因为流水线在某种程度上消耗了额外的协调开销。从107.92秒降到1.57秒约70倍的延迟压缩靠的是三层叠加的优化应用层面的流式传输、模块间的解耦并行、以及模型内部的流水线并行。这三层优化的发现正是FlashRT的中间表示分析框架帮助智能体系统性地梳理出来的。---**五、实验二FlashRT能处理哪些不同类型的应用**研究团队还在另外四个完全不同的多模态应用上验证了FlashRT的通用性。第一个是Qwen3-Omni这是阿里巴巴发布的一个原生多模态模型内部由三个组件构成一个思考者语言模型负责生成文字回复一个说话者语言模型把文字转化为音频编码一个声码器把音频编码合成为真实音频。专业工程师已经为Qwen3-Omni开发了vLLM-Omni部署方案实现了组件间的解耦和流式传输。研究团队给FlashRT的智能体只提供了一段顺序执行的单GPU参考代码结果智能体自己发现了与vLLM-Omni相似的解耦和流式传输结构并且由于使用了更轻量级的组件间数据传输方式FlashRT方案的延迟比vLLM-Omni还低25%0.323秒 vs 0.433秒同时保持了实时输出的能力即音频生成速度快于播放速度也就是实时因子RTF小于1。第二个是视频背景编辑器由Krea-Realtime一个自回归视频风格迁移模型和SAM 3Meta开发的目标分割模型组成。用户提供摄像头实时视频流Krea-Realtime对视频进行风格迁移SAM 3分割出用户的身体轮廓然后把风格迁移的结果中用户身体区域替换回原始像素实现只改背景、不改人物的效果。由于视频风格迁移和人体分割两条处理链在最终合成步骤之前完全独立智能体自动把它们分配到不同GPU上并行执行。在4块GPU的方案中将Krea-Realtime的DiT和VAE共同放置在3块GPU上序列并行SAM 3单独放在一块GPU上延迟从1715毫秒降到491毫秒降低3.5倍在5块GPU的方案中把VAE单独分离出来放到第5块GPU上流水线运行帧率从11.54 FPS提升到19.41 FPS相比单GPU基线提升2.8倍。第三个是WorldPlay视频世界模型由华为开发用户通过键盘方向键控制AI实时生成对应视角移动的游戏画面底层由一个自回归DiT和一个流式VAE组成。智能体在这里展示了它理解延迟和吞吐量这两个目标之间根本性权衡的能力。为了降低延迟智能体选择把DiT和VAE放在同一组GPU上做序列并行——共享更多GPU意味着每个步骤单独执行得更快整条串行路径更短延迟从869毫秒降到493毫秒为了提升帧率智能体转而把DiT和VAE分到不同GPU上流水线执行——一批次的VAE和下一批次的DiT可以同时运行帧率从20.4 FPS提升到31.0 FPS。两种方案各有侧重正好对应两种不同的使用需求。随着GPU数量增加到4块乃至6块延迟最低可降到425毫秒比基线低51%帧率最高可达44.3 FPS比基线高2.2倍。第四个是LongLive视频旁白生成器用户实时说话语音识别模型把话转化为文字提示自回归视频模型根据提示持续生成视频画面视频画面会随着用户说话内容动态变化。这里多了一个语音识别ASR模块它只在用户说话时才触发且与视频生成模型之间没有共享的持久状态。智能体把ASR分配到一块独立GPU上异步运行这样语音识别和视频生成可以完全重叠。在2块GPU方案中延迟优化版DiT和VAE共同放置把延迟从674毫秒降到512毫秒帧率提升到36.5 FPS帧率优化版DiT和VAE分别放置把帧率提升到47.8 FPS代价是延迟稍高630毫秒。扩展到8块GPU后帧率最高可达67.4 FPS基线的2.6倍延迟最低可达430毫秒基线的1.6倍。---**六、FlashRT在AMD芯片上同样有效**以上所有实验都在英伟达B200 GPU上进行。研究团队还在AMD MI355X GPU上重复了全部实验测试FlashRT是否只是针对特定硬件写死的方案还是真正通用的。结果相当令人信服。智能体在AMD GPU上从头开始优化完全不知道英伟达上的优化结果发现了与英伟达版本相同类型的部署方案并且复现了同样的延迟-吞吐量权衡规律共同放置降延迟、分离放置提帧率。在延迟方面AMD版本最高同样实现了约70倍的压缩在吞吐量方面AMD版本的提升倍数3.6倍甚至略高于英伟达版本2.8倍。研究团队指出这是因为AMD平台上成熟的专家级优化工具相对较少工程师手工优化的天花板相对较低AI智能体反而有更大的发挥空间。在Qwen3-Omni的测试中FlashRT在AMD MI355X上比vLLM-Omni一个经过专业工程师优化的成熟方案的延迟低65%0.276秒 vs 0.779秒而且同样保持实时输出能力。有一个小例外值得一提在AMD上视频背景编辑器的帧率提升不如英伟达版本明显。研究团队分析原因是AMD上该应用的瓶颈主要在SAM 3的分割路径上把VAE单独分离出去对整体吞吐量的改善有限——瓶颈不在那里。这说明FlashRT不是机械地套用固定策略而是根据具体硬件环境做出了适应性的决策。---**七、支撑这一切的数学延迟和吞吐量的形式化分析**研究团队在论文中给出了相当完整的数学框架支撑上述直觉性的结论。这套框架将应用建模为一个任务图每个批次的计算构成图中的一组操作实例惰性λ0边表示同批次内的数据依赖状态λ1边表示跨批次的状态依赖如KV缓存。在延迟分析方面他们证明了最小可行延迟由任务图中从输入到输出的关键路径决定——路径越短延迟越低。共同放置能消除组件间的数据传输开销等效于把路径上的边权重清零因此共同放置方案在延迟上具有优势。在吞吐量分析方面他们证明了可持续批次周期批次处理间隔的最小值越小吞吐量越高由所有资源中负载最重的那个决定。分离放置把原本在同一资源上的工作负载分摊到不同资源上降低了最重资源的负载从而能支持更小的批次周期和更高的吞吐量。这就是两种方案之间根本性权衡的数学根源。以DiT和VAE的两种部署方案为例研究团队给出了严格的命题和证明当DiT和VAE共同放置时临界延迟等于批次周期加上两个阶段的执行时间之和当两者分离放置时临界延迟更大因为增加了组间传输开销且每个阶段的序列并行度更低但可持续批次周期等于较慢阶段的执行时间而非两者之和。对于DiT内部的序列并行与流水线并行的比较数学分析同样显示序列并行能缩短每步的执行时间从而降低延迟但多步骤的总时间仍然大于单步执行时间因为序列并行加速是次线性的流水线并行的可持续周期只等于单步执行时间因此在吞吐量上具有优势。---**八、当前局限与未来方向**研究团队在论文中坦诚地指出了FlashRT现阶段的两个主要局限。第一个局限是还没有整合针对单个GPU算子比如矩阵乘法、注意力计算的内核级优化智能体。FlashRT目前的优化发生在如何组织多个模型、如何分配GPU资源、如何安排调度这个层面而不涉及怎么让单个计算步骤本身跑得更快这个层面。研究团队认为把内核优化智能体如KernelBench、KernelEvolve等方向的工作与FlashRT的系统级优化结合起来能开辟更广阔的优化空间这是未来工作的方向之一。第二个局限是实验只测试了一种智能体配置——Claude Code搭配Claude Opus 4.8模型使用最大推理深度。不同的底层语言模型、不同的推理深度、不同的智能体脚手架设计可能对FlashRT的效果有显著影响目前还没有系统性地探索过。归根结底FlashRT代表了一种新的技术思路与其费尽心思手工为每个新应用设计部署方案不如给AI智能体配备一套结构化的工作流程让它自己去探索和优化。从实验结果来看在合适的流程设计支撑下这种方式不仅可行而且效果颇为出色。对于那些正在苦于如何高效部署复杂多模态应用的工程师来说这或许提供了一条新的出路。有兴趣深入了解技术细节的读者可以通过arXiv编号2607.18171检索完整论文。---QAQ1FlashRT和vLLM这类现有模型服务框架有什么不同AvLLM等框架提供的是固定的部署策略比如必须完全分离某些组件只适合特定类型的应用更换应用就不适用了。FlashRT不提供固定策略而是让AI编程智能体针对每个具体应用自动分析结构、设计专属部署方案因此能适应各种不同的多模态应用包括视频生成、语音对话、实时渲染等完全不同的场景。Q2FlashRT的中间表示IR在整个流程中起什么作用A中间表示是FlashRT让智能体把用户代码转化成的一张结构化流程图图里每个计算步骤是一个节点节点之间的数据依赖是边。这张图会强制智能体同时分析应用层和模型内部两个粒度标注哪些步骤可以并行因为状态独立、哪些连接可以流式传输不必等前一步全部完成为后续生成优化方案提供清晰的分析基础避免智能体遗漏关键优化机会。Q3FlashRT在AMD和英伟达GPU上的优化结果有差异吗A总体上结论一致共同放置降延迟、分离放置提吞吐量AMD版本延迟最多也能压缩约70倍。吞吐量提升方面AMD反而略好最高达3.6倍英伟达2.8倍因为AMD平台成熟的专家级优化工具相对较少FlashRT的智能体有更大发挥空间。唯一的例外是视频背景编辑器在AMD上帧率提升有限因为该应用的瓶颈在SAM 3分割路径而非VAE分离VAE没有显著改善整体吞吐量。
这项由卡内基梅隆大学、AMD和纽约州立大学水牛城分校联合开展的研究以预印本形式于2026年7月20日发布在arXiv平台编号为arXiv:2607.18171v1研究领域归属于机器学习cs.LG。**研究概要当AI应用越来越复杂部署却越来越头疼**近年来语音助手、实时视频生成、AI驱动的虚拟形象这类多模态应用正在以惊人的速度涌现。所谓多模态通俗来说就是同时处理多种信息类型的系统——比如既能听你说话、又能看懂图像、还能生成视频的AI应用。这类应用并不是一个单一的AI模型而是把多个不同类型的模型像流水线一样串联起来先用语音识别模型把你的话转成文字再用大语言模型生成回复然后用文字转语音模型把回复读出来最后用视频生成模型把虚拟人物的嘴巴动作配上去。问题是要让这条流水线跑得既快又稳需要大量专业工程师手工调试——决定哪个模型放在哪块GPU上运行数据怎么在模型之间传递多块GPU之间如何分工协作。每开发一个新应用就得重新做一遍这套工作。随着应用种类越来越多这种纯靠人力的方式显然撑不住了。卡内基梅隆大学等机构的研究团队针对这个痛点开发了一套名为FlashRT的系统。它的核心思路是让AI编程智能体一种能自主写代码和调试的AI来替代人类工程师自动把开发者写的简单、低效的参考代码转化成在多块GPU上高效运行的优化部署方案。实验结果显示FlashRT能将某些应用的响应延迟降低约70倍吞吐量可以理解为单位时间内处理任务的能力提升最高3.6倍甚至在某些场景下超越了专业工程师手工优化的方案。---**一、为什么这个问题如此棘手**先来理解一下部署这件事的难度所在。假设你是一家餐厅的老板厨房里有好几个厨师对应多块GPU你需要安排谁做前菜、谁做主菜、谁做甜点以及什么时候开始做、做好的菜怎么传递给下一道工序。如果只有一桌客人单任务、低吞吐量最优方案可能是让所有厨师合力做每一道菜速度最快但如果有很多桌客人高吞吐量最优方案则是让不同厨师专门负责不同菜品流水线作业。这两种目标之间存在根本性的矛盾没有一种固定安排方案能同时做到两者最优。多模态AI应用的部署也是同样的道理。研究团队在论文中用严格的数学方式证明了这个问题是NP难的——这是计算机科学中的一个专业说法意思是找到全局最优解在计算上极其困难甚至不可能在合理时间内穷举完所有可能性。具体而言他们将多模态部署问题形式化为一个任务图每个计算步骤是图中的一个节点节点之间的数据依赖关系是图中的边。当有多块GPU资源可用时如何把这些节点分配到不同GPU上、如何安排执行顺序就构成了一个调度优化问题而这个问题在数学上可以规约为经典的多机器调度最短完工时间问题后者已被证明是NP难的。现有的一些系统试图自动化这个过程但各有局限。像vLLM-Omni和Cornserve这样的多模态服务框架提供了不错的抽象但它们只支持固定的部署策略比如两个模块之间必须完全分离或同一模块内部必须全部放在一起无法根据具体应用灵活调整。像FlexFlow、GSPMD、Alpa这类自动并行化框架擅长处理深度学习训练任务但对推理流水线和异构模型的组合就力不从心了。像TVM这类编译器框架只优化算子级别的计算不涉及模型之间的调度和放置决策。正因为现有工具都有各自的局限研究团队转向了一个新的方向既然规则化的系统解决不了这个问题能不能让AI自己来想办法---**二、AI编程智能体能做什么又会犯什么错**近年来AI编程智能体在自动写代码和优化代码方面取得了显著进展。研究团队的核心洞察是编程智能体具备人类工程师那种从高层理解整个流程、在不同粒度上灵活思考的能力而这正是解决多模态部署问题所需要的。但是直接把任务扔给智能体——给你一段代码帮我优化成高效的多GPU部署方案——效果并不理想。研究团队在论文中详细描述了两种典型的失败模式通过一个具体案例来说明。这个案例是一个面对面对话智能体用户说话系统通过语音识别把话转成文字再通过大语言模型生成文字回复再通过文字转语音模型合成语音最后通过声音驱动视频模型LiveAvatar生成一个虚拟人物在说话的视频把音视频同步后返回给用户。整个流程用了四个模型分别是Qwen3-ASR语音识别、Qwen3-4B语言模型、Qwen3-TTS文字转语音和LiveAvatar声音转视频。当研究团队给智能体一段简单的单GPU顺序执行代码要求它优化吞吐量也就是每秒能生成多少帧视频时智能体暴露出两个问题。第一个问题是它只看到了应用层面的优化机会却看不到模型内部的优化机会。智能体注意到了可以让TTS模型生成一段音频后就立刻传给视频生成模型处理而不是等TTS全部做完再传这叫流式传输streaming。但它没有意识到LiveAvatar内部的视频扩散模型DiT的每一个去噪步骤都有独立的KV缓存意味着不同去噪步骤可以放在不同GPU上流水线并行执行。它选择了把所有去噪步骤放在同一组GPU上用序列并行的方式运行——这能降低延迟但不能提升吞吐量。第二个问题是不同运行结果之间不稳定。有时候智能体只关注应用层的流式传输优化完全忽略模型层有时候又只关注模型层的并行优化忽略应用层。它无法在单次运行中同时发现和组合多种优化策略。这两个问题说明单纯扔任务的方式行不通需要给智能体一个结构化的工作流程。---**三、FlashRT的核心设计给智能体配上流程图和自我检验机制**FlashRT的设计围绕两个核心思路展开分别解决上述两个失败问题。第一个思路叫做程序链范式chain-of-program灵感来自于大语言模型领域著名的思维链技术——与其让模型直接跳到答案不如让它先一步步推理最后再给出结论。类似地FlashRT不让智能体直接把用户代码改成优化版本而是要求它先把用户代码转化成一个结构化的中间表示IRIntermediate Representation然后在这个中间表示上进行分析最后再生成优化部署方案。这个中间表示本质上是一张描述应用流程的流程图由节点和边构成。节点代表各个计算步骤比如运行语音识别、运行语言模型的第3个去噪步骤边代表节点之间的数据依赖关系。这张图有三个特别重要的设计。首先是层级结构。智能体必须生成一个层级化的图顶层图描述整个应用的工作流程底层嵌套图描述每个模型内部的计算结构。这样一来智能体被迫同时考虑应用层和模型层两个粒度不会只盯着其中一个。其次是节点级别的状态标注。对于图中每个节点智能体必须明确标注它会读取或写入哪些持久状态——所谓持久状态就是跨越多个输入批次保留下来的数据比如KV缓存语言模型为了加速生成而缓存的历史计算结果。如果两个节点共享同一份持久状态那它们就必须按顺序执行如果两个节点的持久状态完全不相交那它们就可以被放到不同GPU上并行执行。通过这个标注机制哪些部分可以解耦、放到不同GPU上这个关键问题就变得一目了然了。第三是边级别的流式传输标注。对于图中每条边即两个节点之间的数据依赖智能体必须明确标注这条边是阻塞的还是流式的。阻塞意味着下游节点必须等上游节点全部完成才能开始流式意味着下游节点可以在上游节点只完成了一部分时就开始处理那一部分。比如语言模型生成文字之后才能开始文字转语音这是阻塞的但文字转语音生成了一段音频之后就可以立刻开始生成视频这是流式的。流式边指出了可以在不同GPU上重叠执行的机会而阻塞边则倾向于把相关节点放在一起。完成中间表示的构建之后FlashRT还给智能体配备了几个分析工具。这些工具会自动分析图的结构和数据依赖关系找出哪些节点可以并行化、哪里存在流式传输的机会并以一种结构化的形式反馈给智能体让后续分析更加可靠、系统。此外还有一个IR解释器能把智能体生成的中间表示图按照拓扑顺序顺序执行智能体可以用它来验证自己的中间表示图是否与用户原始代码的行为一致。第二个思路叫做应用感知的验证循环application-grounded validation loop解决的是智能体生成的部署方案可能有错误、或者只探索了部分优化空间的问题。FlashRT设计了一套自驱动的迭代循环。每一轮迭代智能体提出一个优化假设比如我猜把TTS模型和视频生成模型放到不同GPU上并流式传输能提升吞吐量然后实现这个假设验证正确性最后进行基准测试。验证的方式很关键。智能体无法真的把整个应用前端都运行起来但它可以写测试代码模拟用户输入把输入写入系统的输入缓冲区然后从输出缓冲区读取结果——这和真实用户与系统交互的方式完全一致。通过这种方式智能体可以对比自己的实现和原始参考代码的输出是否完全一致逐元素比对从而发现错误同时通过记录写入输入和读取输出之间的时间差测量真实的端到端延迟和吞吐量。这些通过测试后智能体会把测试结果用于更新一个变体队列——这个队列记录了所有待探索的优化方向并根据测试结果动态调整优先级、添加新的候选方向。比如如果流式传输确实有效智能体会进一步考虑能不能在此基础上再加上模型内部的流水线并行。循环终止的条件是队列中所有待验证的方向都已经被测试过或者被明确排除。---**四、实验一面对面对话智能体70倍延迟压缩是怎么做到的**研究团队用上文提到的面对面对话智能体进行了详细的案例研究结果展示了FlashRT的强大之处。起点是一段顺序执行的单GPU参考代码。这段代码按照语音识别→语言模型→文字转语音→视频生成的顺序一步步等待每个模型全部完成后再进入下一步最终输出音视频。整个流程耗时107.92秒而且必须等全部完成才能开始播放没有帧率这个概念。FlashRT在单GPU上发现的第一个优化是流式传输TTS模型每生成一小段音频就立刻传给LiveAvatar开始生成对应的视频帧不用等TTS全部完成。这个优化把首帧延迟即用户说完话到看到第一帧视频响应的时间从107.92秒降到了3.94秒——降幅约27.4倍。同时视频帧率达到了16.26 FPS每秒帧数。但单GPU上TTS和视频生成还是在抢同一块资源帧率有限。扩展到3块GPU之后FlashRT进一步发现了解耦优化把TTS模型和视频生成模型放到不同GPU上这样TTS在生成第N段音频的时候视频生成可以同时处理第N-1段音频真正实现了并行。结合流式传输延迟进一步降到了1.57秒帧率提升到40.88 FPS——比单GPU方案快了2.5倍。扩展到8块GPU之后FlashRT发现了第三个优化LiveAvatar的视频扩散模型内部有4个去噪步骤每个步骤的KV缓存彼此独立批次N的步骤i只依赖批次N-1的步骤i而不依赖批次N的步骤i-1之前的所有步骤因此可以把4个步骤分别放在4块GPU上像接力赛一样流水线执行。配合TTS与视频生成的解耦这个方案把帧率推高到了173.67 FPS延迟保持在1.66秒与3GPU方案相差无几因为流水线在某种程度上消耗了额外的协调开销。从107.92秒降到1.57秒约70倍的延迟压缩靠的是三层叠加的优化应用层面的流式传输、模块间的解耦并行、以及模型内部的流水线并行。这三层优化的发现正是FlashRT的中间表示分析框架帮助智能体系统性地梳理出来的。---**五、实验二FlashRT能处理哪些不同类型的应用**研究团队还在另外四个完全不同的多模态应用上验证了FlashRT的通用性。第一个是Qwen3-Omni这是阿里巴巴发布的一个原生多模态模型内部由三个组件构成一个思考者语言模型负责生成文字回复一个说话者语言模型把文字转化为音频编码一个声码器把音频编码合成为真实音频。专业工程师已经为Qwen3-Omni开发了vLLM-Omni部署方案实现了组件间的解耦和流式传输。研究团队给FlashRT的智能体只提供了一段顺序执行的单GPU参考代码结果智能体自己发现了与vLLM-Omni相似的解耦和流式传输结构并且由于使用了更轻量级的组件间数据传输方式FlashRT方案的延迟比vLLM-Omni还低25%0.323秒 vs 0.433秒同时保持了实时输出的能力即音频生成速度快于播放速度也就是实时因子RTF小于1。第二个是视频背景编辑器由Krea-Realtime一个自回归视频风格迁移模型和SAM 3Meta开发的目标分割模型组成。用户提供摄像头实时视频流Krea-Realtime对视频进行风格迁移SAM 3分割出用户的身体轮廓然后把风格迁移的结果中用户身体区域替换回原始像素实现只改背景、不改人物的效果。由于视频风格迁移和人体分割两条处理链在最终合成步骤之前完全独立智能体自动把它们分配到不同GPU上并行执行。在4块GPU的方案中将Krea-Realtime的DiT和VAE共同放置在3块GPU上序列并行SAM 3单独放在一块GPU上延迟从1715毫秒降到491毫秒降低3.5倍在5块GPU的方案中把VAE单独分离出来放到第5块GPU上流水线运行帧率从11.54 FPS提升到19.41 FPS相比单GPU基线提升2.8倍。第三个是WorldPlay视频世界模型由华为开发用户通过键盘方向键控制AI实时生成对应视角移动的游戏画面底层由一个自回归DiT和一个流式VAE组成。智能体在这里展示了它理解延迟和吞吐量这两个目标之间根本性权衡的能力。为了降低延迟智能体选择把DiT和VAE放在同一组GPU上做序列并行——共享更多GPU意味着每个步骤单独执行得更快整条串行路径更短延迟从869毫秒降到493毫秒为了提升帧率智能体转而把DiT和VAE分到不同GPU上流水线执行——一批次的VAE和下一批次的DiT可以同时运行帧率从20.4 FPS提升到31.0 FPS。两种方案各有侧重正好对应两种不同的使用需求。随着GPU数量增加到4块乃至6块延迟最低可降到425毫秒比基线低51%帧率最高可达44.3 FPS比基线高2.2倍。第四个是LongLive视频旁白生成器用户实时说话语音识别模型把话转化为文字提示自回归视频模型根据提示持续生成视频画面视频画面会随着用户说话内容动态变化。这里多了一个语音识别ASR模块它只在用户说话时才触发且与视频生成模型之间没有共享的持久状态。智能体把ASR分配到一块独立GPU上异步运行这样语音识别和视频生成可以完全重叠。在2块GPU方案中延迟优化版DiT和VAE共同放置把延迟从674毫秒降到512毫秒帧率提升到36.5 FPS帧率优化版DiT和VAE分别放置把帧率提升到47.8 FPS代价是延迟稍高630毫秒。扩展到8块GPU后帧率最高可达67.4 FPS基线的2.6倍延迟最低可达430毫秒基线的1.6倍。---**六、FlashRT在AMD芯片上同样有效**以上所有实验都在英伟达B200 GPU上进行。研究团队还在AMD MI355X GPU上重复了全部实验测试FlashRT是否只是针对特定硬件写死的方案还是真正通用的。结果相当令人信服。智能体在AMD GPU上从头开始优化完全不知道英伟达上的优化结果发现了与英伟达版本相同类型的部署方案并且复现了同样的延迟-吞吐量权衡规律共同放置降延迟、分离放置提帧率。在延迟方面AMD版本最高同样实现了约70倍的压缩在吞吐量方面AMD版本的提升倍数3.6倍甚至略高于英伟达版本2.8倍。研究团队指出这是因为AMD平台上成熟的专家级优化工具相对较少工程师手工优化的天花板相对较低AI智能体反而有更大的发挥空间。在Qwen3-Omni的测试中FlashRT在AMD MI355X上比vLLM-Omni一个经过专业工程师优化的成熟方案的延迟低65%0.276秒 vs 0.779秒而且同样保持实时输出能力。有一个小例外值得一提在AMD上视频背景编辑器的帧率提升不如英伟达版本明显。研究团队分析原因是AMD上该应用的瓶颈主要在SAM 3的分割路径上把VAE单独分离出去对整体吞吐量的改善有限——瓶颈不在那里。这说明FlashRT不是机械地套用固定策略而是根据具体硬件环境做出了适应性的决策。---**七、支撑这一切的数学延迟和吞吐量的形式化分析**研究团队在论文中给出了相当完整的数学框架支撑上述直觉性的结论。这套框架将应用建模为一个任务图每个批次的计算构成图中的一组操作实例惰性λ0边表示同批次内的数据依赖状态λ1边表示跨批次的状态依赖如KV缓存。在延迟分析方面他们证明了最小可行延迟由任务图中从输入到输出的关键路径决定——路径越短延迟越低。共同放置能消除组件间的数据传输开销等效于把路径上的边权重清零因此共同放置方案在延迟上具有优势。在吞吐量分析方面他们证明了可持续批次周期批次处理间隔的最小值越小吞吐量越高由所有资源中负载最重的那个决定。分离放置把原本在同一资源上的工作负载分摊到不同资源上降低了最重资源的负载从而能支持更小的批次周期和更高的吞吐量。这就是两种方案之间根本性权衡的数学根源。以DiT和VAE的两种部署方案为例研究团队给出了严格的命题和证明当DiT和VAE共同放置时临界延迟等于批次周期加上两个阶段的执行时间之和当两者分离放置时临界延迟更大因为增加了组间传输开销且每个阶段的序列并行度更低但可持续批次周期等于较慢阶段的执行时间而非两者之和。对于DiT内部的序列并行与流水线并行的比较数学分析同样显示序列并行能缩短每步的执行时间从而降低延迟但多步骤的总时间仍然大于单步执行时间因为序列并行加速是次线性的流水线并行的可持续周期只等于单步执行时间因此在吞吐量上具有优势。---**八、当前局限与未来方向**研究团队在论文中坦诚地指出了FlashRT现阶段的两个主要局限。第一个局限是还没有整合针对单个GPU算子比如矩阵乘法、注意力计算的内核级优化智能体。FlashRT目前的优化发生在如何组织多个模型、如何分配GPU资源、如何安排调度这个层面而不涉及怎么让单个计算步骤本身跑得更快这个层面。研究团队认为把内核优化智能体如KernelBench、KernelEvolve等方向的工作与FlashRT的系统级优化结合起来能开辟更广阔的优化空间这是未来工作的方向之一。第二个局限是实验只测试了一种智能体配置——Claude Code搭配Claude Opus 4.8模型使用最大推理深度。不同的底层语言模型、不同的推理深度、不同的智能体脚手架设计可能对FlashRT的效果有显著影响目前还没有系统性地探索过。归根结底FlashRT代表了一种新的技术思路与其费尽心思手工为每个新应用设计部署方案不如给AI智能体配备一套结构化的工作流程让它自己去探索和优化。从实验结果来看在合适的流程设计支撑下这种方式不仅可行而且效果颇为出色。对于那些正在苦于如何高效部署复杂多模态应用的工程师来说这或许提供了一条新的出路。有兴趣深入了解技术细节的读者可以通过arXiv编号2607.18171检索完整论文。---QAQ1FlashRT和vLLM这类现有模型服务框架有什么不同AvLLM等框架提供的是固定的部署策略比如必须完全分离某些组件只适合特定类型的应用更换应用就不适用了。FlashRT不提供固定策略而是让AI编程智能体针对每个具体应用自动分析结构、设计专属部署方案因此能适应各种不同的多模态应用包括视频生成、语音对话、实时渲染等完全不同的场景。Q2FlashRT的中间表示IR在整个流程中起什么作用A中间表示是FlashRT让智能体把用户代码转化成的一张结构化流程图图里每个计算步骤是一个节点节点之间的数据依赖是边。这张图会强制智能体同时分析应用层和模型内部两个粒度标注哪些步骤可以并行因为状态独立、哪些连接可以流式传输不必等前一步全部完成为后续生成优化方案提供清晰的分析基础避免智能体遗漏关键优化机会。Q3FlashRT在AMD和英伟达GPU上的优化结果有差异吗A总体上结论一致共同放置降延迟、分离放置提吞吐量AMD版本延迟最多也能压缩约70倍。吞吐量提升方面AMD反而略好最高达3.6倍英伟达2.8倍因为AMD平台成熟的专家级优化工具相对较少FlashRT的智能体有更大发挥空间。唯一的例外是视频背景编辑器在AMD上帧率提升有限因为该应用的瓶颈在SAM 3分割路径而非VAE分离VAE没有显著改善整体吞吐量。
