多模态 AI 为什么响应慢？EAServe 从流水线入口重新设计调度，吞吐最高达 Dynamo 的 4.3 倍

现在多模态大模型已经广泛落地到视觉问答、音视频内容理解、智能语音交互等各类场景，随着部署规模不断扩大，如何在严格的延迟约束下提升GPU利用率、降低服务成本，成为了企业面临的核心问题。针对这一问题，来自佐治亚大学、西部数据、德克萨斯大学阿灵顿分校的研究团队联合提出了EAServe，一套专为多模态大模型设计的感知编码阶段的拆解式服务框架。

论文标题：EAServe: Encode-Aware Disaggregated Serving for Multimodal Large Language Models

论文链接：https://arxiv.org/pdf/2609.31551

研究背景

对于纯文本大语言模型的推理服务，行业已经形成了成熟的优化方案：将推理过程拆分为计算密集的Prefill阶段和内存带宽密集的Decode阶段，分别部署在独立的GPU池中按需扩缩容，能大幅提升资源利用率。但多模态大模型在这两个阶段之前，新增了Encode阶段，需要先将图片、音频、视频等非文本输入转换为大语言模型可以处理的嵌入向量，形成了Encode-Prefill-Decode的三阶段EPD流水线，也带来了新的调度挑战。

现有多模态服务框架大多没有针对三阶段的特性做协同优化，要么沿用纯文本的调度逻辑忽略Encode阶段的存在，要么把Encode当成独立的透传服务，不控制向下游发送任务的节奏。这种设计导致Encode阶段成了整个流水线的瓶颈：单个Encode请求的计算量很小，无法填满现代GPU的算力，而如果等待更多请求凑成大批次再处理，又会大幅增加首词元延迟。最终的结果是Encode阶段的GPU长期处于低利用率状态，下游的Prefill和Decode资源却在空等任务，整个流水线的资源分配严重失衡，既浪费了硬件成本，又无法满足用户的延迟要求。

研究团队测试发现，在主流的LLaVA-v1.6-34B模型部署中，就算加入简单的固定大小微批次处理，Encode的GPU利用率仍然很低，同时加速后的Encode会向下游发送大量请求，导致Decode阶段的延迟大幅上升，并没有从根本上解决资源失衡的问题。

核心设计思路

研究团队提出，可以将Encode阶段从被动的流水线入口，转为整个EPD流水线的控制节点，从三个耦合的维度协同优化：控制任务向下游发送的时机、决定Prefill任务的执行位置、合理分配Encode GPU的共享资源。基于这一思路设计的EAServe采用两层协同的架构，上层为混合自动选择（HAS）模块，负责线下搜索最优的部署配置，下层为三个感知Encode特性的运行时机制，负责在线适配负载波动，保证延迟约束。

HAS模块解决的是人工配置调优的痛点：EPD流水线的配置包含GPU资源在三个阶段的分配、Encode的最大批次大小、Prefill任务的卸载比例三个核心参数，参数之间高度耦合，就算是8GPU的部署环境，也有数百种可行配置，人工调优几乎不可能完成。HAS先通过并行的单阶段性能 profiling 筛选掉明显存在瓶颈的配置，只保留3个左右均衡的候选配置，再针对每个候选的参数范围用TPE贝叶斯优化做端到端的搜索，仅需要数十次测试就能找到接近最优的配置，搜索效率远高于随机搜索和坐标下降法。

运行时的三个机制分别对应三个优化维度：第一个是负载自适应微批次调度，放弃传统的固定超时阈值，而是基于请求的泊松到达特性推导出自适应的等待阈值，请求到达率高的时候自动缩短等待时间，避免延迟上升，到达率低的时候适当延长等待时间凑更大的批次提升GPU利用率，同时设置1000毫秒的硬超时兜底，避免单个请求等待过久。

第二个是速率控制的部分Prefill卸载，将部分Prefill任务调度到Encode所在的GPU上执行，消化Encode阶段的空闲算力，同时采用缺口计数器路由机制，严格保证配置的卸载比例，不会出现连续大量请求发往同一侧的情况，减少下游队列的波动，还会将同一目的地的嵌入打包传输，降低跨GPU的传输开销。

第三个是动态SM分区，Encode和本地Prefill共享同一块GPU时，需要保证Encode的延迟不受影响，同时尽可能多的把空闲资源分给Prefill。EAServe先通过线下profiling生成每个批次大小对应的最小SM需求表，运行时每处理一个批次，就按当前批次大小给Encode分配刚好满足延迟要求的SM资源，剩下的全部分给本地Prefill，通过libsmctrl的TPC掩码实现SM分区，切换延迟不到一微秒，不会影响任务执行。

性能测试结果

研究团队在8卡NVIDIA RTX 6000 Ada的服务器上，针对图像、视频、音频三类模态的主流多模态大模型做了测试，分别是图像场景的LLaVA-v1.6-34B、视频场景的Qwen2.5-VL-32B、音频场景的Ultravox-v0.6-27B，对比的基线方案包括vLLM、NVIDIA Dynamo、EPDServe和HydraInfer，设置了从严格到宽松的5个SLO等级，以SLO达标吞吐量（Goodput）作为核心性能指标。

测试结果显示，在相同的SLO约束下，EAServe的Goodput最高比NVIDIA Dynamo高4.3倍，比vLLM高1.7倍，同时整个EPD流水线的GPU利用率更均衡，尾部延迟也大幅下降。以图像场景LLaVA模型、中等SLO等级为例，EAServe的Goodput达到1.93 req/s，而vLLM和Dynamo分别只有1.11 req/s和0.95 req/s；在2 req/s的请求率下，EAServe将P99首词元延迟从Dynamo的233.8秒降到10.8秒，P99词元生成间隔从764毫秒降到72毫秒，性能提升十分显著。

EAServe的性能提升在不同模态下有不同的来源：图像场景下自适应微批次和本地Prefill卸载的贡献最大，视频场景下Encode阶段计算量较大，HAS自动选择关闭本地卸载，收益主要来自自适应微批次和最优的GPU资源分配，音频场景下Encode计算量很小，本地Prefill卸载消化了绝大部分空闲算力，是性能提升的主要来源。

跨平台测试显示，在8卡A100 SXM4的服务器上，EAServe仍然保持明显的性能优势，吞吐量达到EPDServe的4.86倍、HydraInfer的3.25倍，P99首词元延迟也远低于两个基线方案。消融实验证明，动态SM分区相比静态分区和无分区方案，吞吐量提升3%-9%，P99首词元延迟降低11%-19%，P99词元生成间隔降低22%-42%；针对请求到达模式的测试显示，就算是比泊松分布突发程度高一倍的流量，EAServe的吞吐量仅下降3%，P99首词元延迟的上升也在可接受范围内，稳定性表现良好。

总结与展望

EAServe创新性地将Encode阶段作为多模态大模型服务流水线的控制核心，通过线下自动配置搜索和线上自适应调度的协同设计，解决了三阶段流水线资源失衡的痛点，大幅提升了GPU利用率和服务性能，能够帮助企业降低多模态大模型的部署成本，提升用户体验。未来研究团队还将把EAServe扩展到多节点数据中心规模，优化跨节点的嵌入传输开销，同时加入在线到达率预估能力，适配更多样的负载特征。