Agent自动优化多GPU部署！AMD联合开源面向实时多模态应用的Harness

正在快速发展的包括语音Agent, 还有实时数字人, 以及交互式视频生成, 然而当模型真正进行部署之时, 问题通常不在于模型自身。

有一个应用, 它是用于面对面对话的, 这个应用先是通过ASR来识别语音, 接着利用LLM生成回复, 之后借助TTS合成语音, 还要经过由DiT与VAE的声音驱动的视频模块生成视频画面, 实际上, 其背后是一条由多种模型拼接起来的复杂流水线。

组件之于同一张GPU上的放置, 组件之于不同GPU的拆分, 流式执行处, 流水线并行适宜处, 直接影响、关乎延迟, 直接影响、关乎吞吐量。

更麻烦之处在于, 每变换一种应用, 那最优的部署方案也会随之发生变化。现有的推理系统一般只是提供有限的固定策略, 而开发者依旧得针对不同的应用手动去修改代码。

助理教授、负责Lab的陈贝迪团队, 联合AMD并与at共同做出了提出这一行为, 该行为所涉及的内容为, 能引导 agent达成系统最优化相关结果产生的一个且仅有的Agent。

只需要开发者去提供那种非常简单的单GPU参考实现, 它便会尝试着去生成针对具体应用以及硬件预算进行优化的多GPU部署, 此部署是经过优化而来的。

团队发布了项目网站, 它以交互方式汇总了部署结果, 此结果是五类实时多模态应用的, 在这个网站上可以切换B200和AMD, 还能查看方案, 该方案是针对不同GPU预算生成的, 有延迟优先和帧率优先两种。

进行实验时, 于B200那儿达成了最高大概70倍的延迟下降, 以及2.8倍的吞吐量升高, 在AMD之上, 吞吐量的最大升高为3.6倍。

就Qwen3 - Omni文本转音频推理而言, 与之相比, 人工设计的vLLM - Omni所实现的响应延迟, 降低的幅度为65%。

01

为什么实时多模态应用

仍然依赖手工部署

着重于一个模型的是传统LLM推理, 与之不同的是, 实时多模态应用更像是一条由很多个模型构建起来的复杂流水线。

这里不存在一种对所有应用都有效的固定部署方案。

要是应用对于响应延迟更为侧重时呢, 把多个组件共同安置、部署于同一GPU组之上, 如此这般或许能够使关键路径得以缩短。要是对持续输出帧率侧重程度更高的话, 将组件分开来进行针对性部署, 放置到不同的GPU上, 再借助跨过batch流水化执行的办法, 通常更加有益于吞吐量这方面的发展。

该论文把现存方案存在的欠缺归纳成三个层面 , 即为: 布置策略存在局限 , 工作负载涉及范围存在局限 , 以及优化的精细程度存在局限。

vLLM - Omni等, 在多模态推理抽象方面有提供, 不过主要是采用固定的阶段划分, 以及部署策略。

诸如GSPMD、Alpa这般的自动并行系统, 在结构相对固定的深度学习任务方面, 反倒更具恰当的适配性。

TVM和TASO则主要关注算子级优化。

对于那种由多个异构模型以及不同运行时所构成的应用, 这些方法在同时去处理应对应用级方面, 还有组件放置方面, 以及模型内并行方面的时候, 是非常困难的。

02

如何让 agent

接管系统优化

直接朝着agent讲出一句“把这段代码优化成多GPU版本”, 其呈现出来的效果并不会处于良好的状态之中。

在针对Agent进行部署优化时, 要是没有工作流引导, 而是直接提出这一要求。那么, 它或许能察觉到语音转向语音视觉变换系统的机会, 然而, 却极有可能错过模型内部结构利用流水线协同计算让任务平行的并行方式。在别的部署运行态里, 它又单单着眼专注放在使模型并行发挥效果上, 根本不在不同优化思路策略下将其组织汇聚结合起来。

不是让Agent一下子就达成代码改写, 而是给出了一种全新的程序链式转换模式准则（chain-of-）。

给开发者提供参考实现的Agent, 会先将其转变为展现为分层图结构的中间形式, 具体而言, 这种中间形式就是IR。

这个IR, 它会记录计算节点, 还有数据依赖, 除此之外, 它还要求Agent明确标注三类信息, 其中包括应用和模型内部的图层级, 另外还有每个节点读写的持久状态, 再有就是每条边属于还是。

这些标注很关键。

要是两个节点运用不一样的持久状态, 那它们有可能被分到不同的GPU展开并行执行。要是一条边是这样的情况, 那么下游组件能够在上游还没生成完整结果之际就预先开始工作。

IR生成出来以后, 会借助顺序解释器去检查, 看IR跟原始实现是不是一致的, 之后利用静态分析这个方法, 来找寻能够试一试的、那种分离部署还有并行化的方案。

Agent踏入循环, 提出该项, 优化假定对代码予以修改, 核查逐, 元素输出, 其是否跟基线相符, 接着开展实际测量, 针对延迟以及吞吐量。

测量结果会更新一个候选队列（self-queue）, 这个候选队列能依据测量结果进行动态扩展与重排。新发现的候选方案会被添加入队列之中, 效果欠佳的方案会被移除, 剩余的方案会按照预期收益重新开展排序。

03

从107.92秒降到1.57秒

于面对面对话Agent的那个实验里, 按顺序执行的仅使用单一GPU的基线做法, 那得先把所有与音频以及视频相关的生成任务都给完成，而, 它第一次进行输出的时候, 延迟居然达到了107.92秒。

通过让TTS音频分块提前进入S2V的方式, 仅使用一张GPU, 从而将延迟降至3.94秒。

在增添至三张 GPU 之后, Agent 接着采取行动, 把 TTS 与 S2V 分开进行部署, 要达成的结果是, 让这两个模型可以重叠着去执行, 最终延迟降低到了 1.57 秒, 而帧率则达到了 40.88 FPS。

运用八张 GPU 的情形下, 把那其余的四个去噪步骤, 分别安置到不一样的 GPU 去搞流水线并行, 最终在理论层面上, 可持续帧率达成了 173.67 FPS, 并且把响应延迟维持在了 1.66 秒。

这套方案, 并非是研究人员预先写好的那种规则, 乃是 Agent 借助参考实现, 与 IR 分析, 以及实际测量相结合, 遂一步一步最终组合而成的内容。

在Qwen3 - Omni那儿, 同样发现了LLM, LLM以及它们相互之间的分离部署，还有采取的流式执行方式。

在B200的视频背景编辑实验里头, 帧率先是从基线的6.82 FPS提升到了19.41 FPS, 这提升后的帧率大约是原来帧率的2.8倍。而在AMD的实验当中, 帧率从15.6 FPS提升到了56.8 FPS, 提升后的帧率约为原来的3.6倍。

于B200之上, 把延迟从vLLM - Omni的0.433秒降到0.323秒。在AMD那里, 又从0.779秒下降至0.276秒, 降幅约65%, 并且保持RTF小于1, 能够持续开展实时音频生成。

04

同一套策略不会适合所有应用

最值得留意的所在之处, 并非仅仅是某一个单独的数字, 而是它能够依据应用的目标以及硬件的条件, 进而改变部署的方式。

置DiT与VAE于同一环境中并行部署, 可采用更高序列并行度, 关键路径更短, 所以延迟更低。待将两者分置于不同GPU后, VAE能处理上一批数据, DiT可与此同时去计算下一批数据, 帧率因而更高。

因此，共置部署更偏向低延迟，分离部署更偏向高吞吐量。

于 B200 之上, 从头执行那优化流程, 于 AMD 之上, 同样从头执行该优化流程, 未向 Agent 供给另一种硬件上所产生的结果, 亦未给出硬件专用的提示, 然而最终却还是寻觅到了相似的部署方案, 并且依据不同硬件的性能瓶颈去调整 GPU 的分配。

这表明, agent 开始获得了参与以往高度依靠系统工程人员的工作的机会, 此工作包括, 理解完整的应用, 寻觅并行的机会, 修改部署的代码, 然后依据真实的测量结果来决定下一步。

论文也确切给出了限定条件, 可以这样说, 到目前为止还没有将LLM进行集成从而对Agent予以优化, 并且该实验仅仅针对一种Agent配置展开了测试, 那么当更换模型, 或者降低推理深度, 又或者对Agent进行修改之后, 此时能否维持同样的效果状态, 这是还需要进一步去加以验证的。