

随着人工智能从纯文本迈向多模态时代,我们正见证着智能体能力的巨大飞跃。如今,一个先进的多模态大语言模型不仅能理解文字,还能处理图像、音频甚至视频,并生成融合多种模态的回应。然而,在这令人兴奋的能力背后,支撑其运行的推理系统正面临前所未有的复杂挑战。
想象一个典型的智能对话场景:用户上传一张图片并附上文字描述,要求模型"描述图片内容,并根据描述生成一段背景音乐"。这个看似简单的请求,背后却需要视觉编码器解析图像、文本编码器理解指令、大语言模型进行跨模态推理与规划,最后还需音频生成模型合成音乐。这些异构的计算单元如何高效协同?它们产生的大量中间数据(如特征向量、键值缓存)如何在进程间、甚至跨机器快速流转?如何避免不同模块重复加载相同的模型权重,浪费宝贵的GPU内存?
现有解决方案往往将大语言模型和扩散模型等独立部署,缺乏对多模态推理流程的系统级抽象。这导致编排逻辑分散,数据传输路径与特定模型紧耦合,每集成一个新模型都需要付出高昂的改造成本。为了系统性地解决这些问题,美团与北京大学的研究团队提出了 Omni-Flow —— 一个面向多模态推理的统一工作流编排与分布式键值缓存共享框架。

论文标题:OMNI-FLOW: A UNIFIED WORKFLOW ORCHESTRATION AND DISTRIBUTED KV CACHE SHARING FRAMEWORK FOR MULTIMODAL INFERENCE
论文链接:https://arxiv.org/pdf/2606.31093
开源仓库:https://github.com/meituan-longcat/omni-flow.git
研究背景:多模态推理的系统之困
多模态大语言模型应用正日益普及,但其背后的推理框架却未能跟上模型架构快速演进的步伐。现代MLLM的推理过程需要多个异构计算模块协同工作,包括文本编码器、视觉编码器、音频编码器、用于文本生成的大语言模型或用于图像生成的扩散Transformer、扩散去噪模块以及变分自编码器等。

更重要的是,多模态模型架构本身仍在快速演进。图像理解、图像生成、语音识别、语音对话等不同任务具有截然不同的模型拓扑结构。在这个阶段,构建一个能够高效容纳多样化模型架构的统一系统框架,比针对某个固定架构进行激进优化更为紧迫。
任意到任意的多模态模型将多个异构模型组合成单个推理流水线。因此,中间张量和键值缓存不再局限于单个推理引擎内部,而必须在不同计算角色之间高效共享和传输。这一转变引入了多项新的系统需求:资源受限的单节点部署需要本地共享模型权重和键值缓存以避免GPU内存翻倍;跨越多机的高性能部署则需要统一的分布式键值缓存管理机制。同时,持续演进的多模态模型拓扑要求一个灵活的工作流抽象,能够容纳多样化的异构执行流水线。
然而,现有的生产级推理框架缺乏能够共同满足这些需求的系统级抽象。
三层抽象:Omni-Flow的核心架构
Omni-Flow通过三个协同合作的抽象层来组织统一的多模态推理系统:控制流 、数据流 和计算流 。这三个层次解耦又协同,允许模型拓扑、数据移动和底层计算独立演进,共同为快速演进的多模态模型提供了一个统一、可扩展且高效的推理框架。

控制流:声明式的工作流编排
控制流层将"多模态、多异构计算单元的推理流水线"抽象为一个声明式的图领域特定语言,由框架层接管所有调度和数据传输工作,从而将业务侧的计算逻辑从调度细节中彻底解放出来。
其设计追求两个关键目标:通用性——一套抽象覆盖任意异构角色(如LLM、扩散模型、视觉编码器、音频编码器)的任意串联组合;性能——完全异步和去中心化的执行流,以在实时系统中最大化吞吐量。

用户通过Python DSL声明图结构,其核心构建块包括角色(计算单元)、占位符(外部注入数据字段)、全局参数(会话粒度的共享参数)以及跨图引用。其中,每个interface()的输入使用二维列表来建模分支逻辑:外层列表代表OR组(任一组准备就绪即触发),内层列表代表AND组(仅当组内所有字段都已到达时才触发)。框架基于"哪个OR组最先被完全满足"自动选择分支,无需编写任何显式的条件判断代码。
在实现复杂工作流时,框架层面需要解决三类核心的依赖关系问题:菱形依赖(单源数据分叉后下游汇聚)、序列依赖(按序产生的多帧可能乱序到达下游)和多流连接(单源数据的路径数量动态可变)。Omni-Flow通过抽象的"桶"模型来统一处理这些依赖。

桶 是用于在汇聚点同步多路输入、然后触发当前节点前向计算的容器。每个桶由四元组唯一标识,确保不同并发轴的数据不会错乱。桶的内部状态包括必须同步的完整槽位集合、已接收数据的槽位、已收到流结束指示的槽位以及被上游报告为不可达的槽位。当每个必需路径要么已到达、要么被确认为不可达时,桶就会触发并调度当前节点的前向计算。
对于菱形依赖,核心机制是利用分叉源的身份和帧序列号作为种子来计算激活ID。无论路径经过哪些中间节点,只要它们源自同一个分叉源的同一帧,其计算出的激活ID就完全相同,从而落入同一个桶中。对于序列依赖,框架将保序逻辑集中在SessionLoadBalance节点,其他节点完全无需排队。对于多流连接,节点声明activate_by_count,框架在输入到达时强制将这些信号的桶身份重写为同一个常量,使多路输入汇聚到单个桶中,并按字段级别的计数阈值触发。
数据流:统一的分布式数据平面
当前多模态模型正收敛于统一的骨干架构——大语言模型处理跨模态理解,扩散模型负责生成,两者共享完全相同的Transformer权重和键值缓存。同时,可预测的超长上下文任务也必然催生对键值缓存压缩和紧凑化的需求。因此,键值缓存的多角色共享能力已不再是奢侈品,而是架构演进的内在要求。

现有的键值缓存共享方案相对碎片化,难以在少量固定角色之外进行组合。为此,Omni-Flow提出了一个以全局参数池为中心的统一的分布式键值缓存抽象。

跨L1/L2/L3存储层次的分配与回收被统一到单一数据平面下,所有数据传输——无论是不同角色之间,还是同一角色的不同副本之间——都通过直接的数据平面通道统一路由。与仅开放单一固定传输路径的预填充/解码分离方案不同,全局参数池建立了一个全连接的数据网络:任何角色或副本都可以向任何其他方推送或拉取数据,无需任何硬编码的配对假设。推理引擎仅负责前向计算,完全无需关心数据的位置和所有权。这种统一的设计可以自然地扩展到任意数量的协作角色,而无需修改架构。
数据流子系统采用客户端-服务器架构:MemoryManager作为核心服务器组件,统一管理所有内存池并处理RPC请求;MemoryManagerClient则嵌入在每个角色进程中,通过ZMQ IPC与服务器通信。内存根据用途分为三大池:
全局参数池:键值缓存的指定目的地,采用分页、分层存储层次,基于热/冷数据访问模式在层级间自动迁移数据。 临时缓冲区池:中间数据的传输枢纽,在系统内部嵌套,自动完成不同角色接口间输入输出张量的零拷贝、低延迟传输。 权重共享:模型权重的共享层,基于结构化通用名称进行匹配,使同一GPU上的多个共址角色能够复用完全相同的物理权重,将GPU内存开销降至单个副本的水平。
计算流:统一异构计算接口
原生多模态模型推理框架的计算平面解决了一个基本矛盾:模型拓扑在不同模态间高度流动,但推理执行必须保持高效。其策略是在所有模态进入大语言模型骨干之前,将它们统一为单一的隐藏状态表示,从而使成熟的LLM优化技术能够统一应用于任何模态。
计算流层将SGLang视为一个深度可定制的LLM内核,通过统一接口接管其内存和采样,并强制模态编码器和扩散模型收敛到相同的前向执行路径。其核心机制包括前缀匹配、接口抽象与键值缓存接管,以及扩散模型复用LLM路径。
前缀匹配 被分解为两种共享底层机制的模式。完全匹配适用于没有复杂模态输出的场景,服务器运行所有模态编码器以获得精确的片段长度,将隐藏状态拼接成完整序列,并进行逐页前缀匹配。增量匹配适用于输入引用了先前模态输出的场景,客户端携带一个步进偏移量声明其已获取的数据位置,服务器将历史截断到该位置,仅处理新的增量数据。两种模式共享相同的底层链式分页哈希机制:每个页面的哈希编码了其前驱的哈希,因此只有当整个前缀逐页匹配时,哈希值才相等。
框架并不直接使用SGLang的原生内存和采样逻辑,而是通过统一的插件单例"挖空"SGLang运行时,将控制权完全转移到框架的数据平面。这包括抽象化的I/O参数接口和整体的键值缓存接管。
一个关键的工程决策是:扩散(DiT)模块不使用原生扩散运行时,而是复用完整的大语言模型基础设施——相同的引擎和调度栈、相同的分页键值缓存以及相同的权重共享机制。复用的结构是一个具有运行时插件选择的共享基类:LLM和DiT都继承自相同的键值缓存和权重管理基类,环境开关在运行时切换它们各自的实现。DiT去噪步骤被组织为沿标准分页注意力路径执行的序列,图像和时间步数据作为前向批次的额外字段传递。
这样做的动机是并行对齐。权重和键值缓存共享要求两个角色在张量并行、专家并行等并行策略上采用相同的切分维度。原生扩散栈缺乏专家并行支持,使得跨角色共享不切实际。将DiT移植到LLM路径上,强制两个角色采用相同的并行语义,使它们能够直接共享物理权重和键值缓存。
创新与贡献
Omni-Flow的主要贡献可以概括为以下四个方面:
统一的声明式工作流抽象:将多模态推理建模为执行图,支持异构计算角色、条件执行、多产出流式传输、灵活的连接模式以及带循环的迭代工作流。 统一的数据平面:管理中间张量和键值缓存的生命周期,将缓存管理、数据传输、分层存储和零拷贝共享统一到单一框架中,实现高效的跨角色、跨机器资源共享。 统一的异构计算抽象:使兼容的扩散Transformer能够复用LLM推理引擎的执行基础设施,在提高资源复用率的同时减少模型适配开销。 完整的系统实现与验证:在SGLang之上实现了Omni-Flow,并在代表性的多模态模型上验证了其有效性、通用性和可扩展性。
应用与展望
Omni-Flow已经成功支持了三种典型场景:DeepSeek-V2纯大语言模型推理(预填充/解码分离、流式词元输出)、LongCat-Next多模态对话(具有不同头部的大语言模型)以及HunyuanImage-3图像生成流水线(LLM+DiT)。
该框架目前仍处于早期阶段,未来的工作方向包括:
性能优化:下一阶段的核心,目标是向实时推理演进。 深化分布式键值缓存:支持更多注意力变体、分层传输策略、不同张量并行配置下的高效传输、一致性并行支持、键值缓存分片的智能选择等。 更复杂的调度策略:例如缓存感知调度,基于每个副本的键值缓存命中状态做出路由决策。 强化学习集成:当前模型权重已由框架统一管理,强化学习训练中的参数同步将自然受益于此共享基础设施。 支持更多模型形式:持续扩展框架的模型覆盖范围。
结语
多模态人工智能的浪潮已至,而支撑其高效、稳定、规模化服务的系统基础设施必须同步演进。Omni-Flow通过控制流、数据流、计算流三层精心设计的抽象,为复杂多模态推理工作流提供了统一的编排、传输与资源共享方案。它不仅在学术上提出了创新的系统设计,更通过开源实践为社区提供了可复用的工程框架。
随着模型能力的边界不断被突破,像Omni-Flow这样着眼于系统级挑战的框架,将成为释放多模态大模型真正潜力的关键基石。其设计思想——通过清晰抽象解耦复杂性、通过统一平面实现高效共享——或许也将为未来更广义的异构AI计算系统提供有益的借鉴。
> 本文由 Intern-S2 等 AI 生成,机智流编辑部校对
-- 完 --
机智流推荐阅读:
1.
2.
3.
4.
cc | 大模型技术交流群 hf | HuggingFace 高赞论文分享群 lc|LangChain 技术交流群 code | AI Coding 交流群 具身 | 具身智能交流群 硬件 | AI 硬件交流群 推理 | AI 推理框架交流群 智能体 | Agent 技术交流群