🤖 AI

M*: A Modular, Extensible, Serving System for Multimodal Models

本文介绍了 M*，这是一个模块化且可扩展的推理服务系统，它将复合多模态模型表示为数据流图，以实现灵活的组件组合和分布式优化，在文本生成图像、文本生成语音以及机器人规划等多种任务中，相比现有框架实现了显著的延迟降低和吞吐量提升。

原作者： Atindra Jha, Naomi Sagan, Keisuke Kamahori, Irmak Sivgin, Rohan Sanda, Steven Gao, Mark Horowitz, Luke Zettlemoyer, Olivia Hsu, Jure Leskovec, Baris Kasikci, Stephanie Wang

发布于 2026-06-12

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Atindra Jha, Naomi Sagan, Keisuke Kamahori, Irmak Sivgin, Rohan Sanda, Steven Gao, Mark Horowitz, Luke Zettlemoyer, Olivia Hsu, Jure Leskovec, Baris Kasikci, Stephanie Wang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你正在经营着一家规模宏大、高科技的厨房。

旧方式（现有系统）：
长期以来，AI 模型就像是简单的、单车道的组装线。如果你想烤一个蛋糕（生成文本），每种原料都要走同样的路径：混合、烘焙、抹霜、上菜。像 vLLM 这样的系统就是专门为这种“仅限文本”的组装线而构建的。它们在烤蛋糕方面速度极快。

但现在，AI 正在进入一个新时代。我们不再仅仅是烤蛋糕了；我们正在运行一个复合型厨房。我们的模型可以：

观察一张照片并描述它（视觉）。
聆听一段声音并以另一种声音回复（语音）。
观看一段视频并预测接下来的发展（世界模型）。
根据指令控制机械臂（机器人技术）。

这些新的“复合型”模型非常杂乱。它们并不遵循单一的直线。有时它们需要循环回溯来检查自己的工作（比如扩散模型通过多次迭代优化图像）。有时它们需要同时分裂成三条并行路径（比如从三个不同的角度检查一张图片）。有时它们需要实时流式传输音频，一次只传一个词。

旧的厨房系统（vLLM、SGLang）试图将这些复杂的、多任务的模型强行塞进它们简单的、直线型的组装线中。这就像是试图把一场杂耍表演塞进传送带里。这样做虽然可行，但既缓慢又笨拙，并且需要大量的自定义“胶水”代码来让各个部分粘合在一起。

新解决方案：M*
这篇论文介绍了一种全新的、用于这些复杂 AI 厨房的操作系统。M* 不再强迫模型走直线，而是将它们视为一个动态地图或流程图。

以下是 M* 的工作原理，使用简单的类比说明：

1. “行走图”（地图）

在过去，厨房经理必须知道每道菜的精确食谱。而在 M* 中，模型创建者只需绘制一张厨房的地图（图/Graph）。

节点（Nodes）： 这些是工作站（例如：“视觉站”、“语言站”、“音频站”）。
行走（Walks）： 这是客户订单所经过的具体路线。
- 订单 A（文生图）： 从语言站出发 $\rightarrow$ 在艺术站循环 50 次 $\rightarrow$ 最后到达打印机。
- 订单 B（语音对语音）： 从麦克风站出发 $\rightarrow$ 分裂成两条路径 $\rightarrow$ 重新合并 $\rightarrow$ 到达扬声器。

M* 将其称为行走图（Walk Graph）。它让系统能够理解不同的任务会通过同一个厨房走不同的路径，而无需每次都重写厨房的布局。

2. “指挥家”（交通控制器）

地图绘制完成后，M* 有一位指挥家。这位聪明的交通控制器并不关心食物是什么，只关心食物该去哪里。

如果一个请求需要循环回溯（比如优化图像），指挥家会将它送回循环的起点。
如果一个请求需要分裂成三份（比如同时检查安全性、风格和内容），指挥家会同时向三位不同的厨师发送三份副本。
如果一个请求正在进行音频流式传输，指挥家会确保厨师在整句话结束之前，立即递出第一个词。

3. 灵活的座位（放置/部署）

在旧系统中，如果你有一个大厨（大型 AI 模型），你必须把他们放在一张大桌子（单个 GPU）上。如果你有一个小助手（小型编码器），他们就必须坐在一张小桌子上。
M* 允许你将厨房进行解耦（Disaggregate）。你可以把“视觉厨师”放在一台电脑上，把“语言厨师”放在另一台，把“音频厨师”放在第三台。他们可以实现即时通信。这意味着你可以只针对模型中较慢的部分进行扩容，而不必在那些快速的部分上浪费资金。

他们证明了什么？（结果）
作者将 M* 与旧系统（vLLM-Omni、SGLang-Omni、VoxServe）在五种不同类型的复杂模型上进行了对比测试。结果如下：

图像生成 (BAGEL)： 在将文本转化为图像时，M* 比旧系统快了 20% 到 50%。它更高效地处理了优化图像所需的复杂“循环”。
语音 (Qwen3-Omni & Orpheus)： 在生成语音时，M* 的实时性能提升了高达 2.9 倍，并且能同时处理 2.7 倍的请求量。这就像是从缓慢、卡顿的无线电切换到了清晰的现场直播。
机器人技术 (V-JEPA 2)： 在预测未来视频帧以进行机器人规划时，M* 的速度提升了高达 12.5 倍。旧系统必须在每一步都从头开始重新计算；而 M* 记住了之前的步骤，并仅更新新的部分。

核心结论
M* 是一个通用的系统，它不再试图将每个 AI 模型都强行塑造成单一、僵化的形状。相反，它让模型定义自己的形状（图），然后构建一个灵活、高速的引擎来运行这个形状。

这就像是从一个一旦尝试制造汽车而非烤面包机就会崩溃的刚性组装线，转变为一个智能、可适应的工作坊，它可以以同等的速度和效率制造从烤面包机到火箭飞船的一切事物。论文声称，这使得开发者能够以极低的成本部署这些复杂的、多模态的模型，同时获得显著提升的性能。

技术摘要：M* —— 一种面向多模态模型的模块化、可扩展服务系统

1. 问题陈述

AI 领域正在向复合模型架构转型，这些架构集成了多样化的组件，如视觉编码器、语言骨干网络、扩散头（diffusion heads）、音频编解码器和动作生成器。这些模型——包括统一多模态模型（UMMs）、全能模型（Omni models）、语音语言模型（SpeechLMs）、视觉-语言-动作（VLA）策略以及世界模型（World Models）——表现出基于输入模态和任务而显著变化的执行结构。与遵循固定自回归（AR）循环的传统纯文本大语言模型（LLMs）不同，复合模型具有以下特征：

多样化的执行路径： 不同任务（例如图像生成与图像理解）会在同一模型内的不同组件子集间进行遍历。
复杂的控制流： 模式包括非自回归循环（如扩散步数、世界模型展开）、内部并行性（如无分类器指导 CFG 分支）以及流式数据依赖。
异构硬件需求： 组件可能需要被独立缩放，或放置在特定的硬件拓扑结构上。

现有的推理框架（如 vLLM、SGLang）针对自回归文本生成进行了优化。虽然近期的扩展版本（vLLM-Omni、SGLang-Omni）试图通过固定的“阶段”有向无环图（DAG）来支持多模态模型，但它们无法捕捉复杂的模式，如跨阶段循环、内部并行和动态流式传输。这导致了性能低下、物理放置僵化，并且在面对新架构时需要编写大量的自定义“胶水代码”。

2. 方法论：Walk Graph（行走图）抽象

作者提出了 M*，这是一个构建在核心抽象 Walk Graph 之上的通用服务系统。该抽象将模型架构与系统运行时解耦。

2.1 核心定义

M* 中的模型被定义为一个二元组 $(G, W)$ ：

$G$ （计算图）： 一个由异构节点（如编码器、解码器、Transformer 层）和边（张量流）组成的有向图。
$W$ （Walks/行走）： 一组命名的子图，代表特定的模型行为阶段（例如 prefill_text、image_gen）。一个用户请求即为这些 Walk 的序列。

2.2 组合原语

该图使用四种原语进行构建，以处理复杂的控制流：

串行（Sequential）： 将子图链接在一起，使输出馈送到下一个子图。
并行（Parallel）： 子节点扇出执行（例如用于 CFG 分支）。
循环（Loop）： 带有累积输出的有界迭代（例如扩散步数）。
动态循环（DynamicLoop）： 带有每请求早期退出条件的迭代（例如自回归中的终止符 EOS 或世界模型中的可变时界）。

2.3 流式传输与分块

为了支持实时生成（如语音），M* 引入了由 ChunkPolicies（分块策略） 参数化的 StreamingGraphEdges（流式图边）。这些策略决定了消费者节点何时基于累积的输入张量触发。支持的策略包括：

FixedChunkPolicy：每隔 $K$ 个项目触发一次。
SlidingWindowChunkPolicy：当缓冲区持有 $W$ 个项目时触发，并向前推进 $S$ 个单位。
LeftContextChunkPolicy：在分块前拼接上下文帧。

2.4 运行时架构

M* 运行时通过分布式架构执行 Walk Graph：

Conductor（指挥官）： 维护每个请求的状态，并通过 ZeroMQ 向 Worker 分发任务。
Workers（工作节点）： 每个 GPU rank 对应一个进程，执行本地子图。它们支持连续批处理（continuous batching）、**CUDA 图捕获（CUDA-graph capture）**和 torch.compile。
Engines（引擎）： 特化的推理实例（例如，为具有 FlashInfer 分页注意力机制的 Transformer 提供的 KVCacheEngine，以及用于简单节点的 StatelessEngine）。
Placement（放置）： 用户定义从 GraphNodes 到 GPU rank 的映射。这实现了灵活的策略，如预填充-解码解耦（prefill-decode disaggregation）、编码器/解码器解耦以及组件的独立缩放。

3. 核心贡献

Walk Graph 抽象： 一种统一的表示方法，能够将任意复合模型结构（循环、并行、流式传输）作为数据流图进行捕捉，超越了固定阶段 DAG 的局限性。
模块化运行时： 该系统将图抽象编译为高性能执行，在不要求模型特定胶水代码的情况下，跨模态集成最先进的优化技术（分页注意力、CUDA 图）。
灵活的物理放置： 提供了解耦的 API，允许部署者将组件任意映射到硬件，从而实现独立缩放和跨不同请求类型的资源共享。
流式支持： 通过分块策略原生处理生产者-消费者模式，这对于实时语音和视频生成至关重要。

4. 实验结果

作者在五个代表性模型上评估了 M*：BAGEL (UMM)、Qwen3-Omni (Omni)、Orpheus (SpeechLM)、V-JEPA 2 (World Model) 和 $\pi$ 0.5 (VLA)。

BAGEL (文本生成图像与图像编辑):
- 与 vLLM-Omni 相比，M* 在文本生成图像任务中实现了 ~30% 更低的 p50 端到端延迟，在图像编辑任务（含 CFG 并行）中实现了 ~50% 更低的延迟。
- M* 使用单一配置即可优化所有模态，而 vLLM-Omni 则需要在不同配置之间进行权衡（例如单阶段 vs 多阶段），这会降低特定任务的性能。
- 增益归功于 M* 对 CFG 分支的分页 KV 缓存管理，避免了 vLLM-Omni 中使用的密集张量拼接。
Qwen3-Omni (文本转语音):
- 在 Seed-TTS 基准测试中，相比于 vLLM-Omni 和 SGLang-Omni，M* 提供了高达 2.9 倍更低的实时因子 (RTF) 和 2.7 倍更高的吞吐量。
- 在 Batch Size 为 16 时，吞吐量比 vLLM-Omni 高出约 15%。
- 提升源于子模块级的 CUDA 图捕获（使得整个 Talker 循环可以作为一个图运行）以及消除了同位置组件之间的进程间通信。
Orpheus (语音):
- M* 实现了比 VoxServe（一种专门的语音服务系统）更低 13.6% 的 p50 RTF，且吞吐量提升在 20% 到 52% 之间。
V-JEPA 2 (机器人规划/世界模型):
- 对于动作条件下的展开（rollout），在展开时界为 30 时，M* 的表现最高超过原生 Meta 实现 12.5 倍。
- 这是通过将展开过程编码为 DynamicLoop 并结合分页注意力 KV 缓存实现的，避免了基准方案中由于手动编写循环而导致的昂贵重复预填充。

5. 意义与主张

论文声称 M* 为高效服务复杂的下一代复合模型铺平了道路，且开发工作量极小。通过将多模态推理视为图遍历，M* 允许模型作者只需声明一次架构，即可让部署者动态优化物理放置和执行。

作者断言，M* 在多种任务中均能达到或超越最先进的模态特定基准（如 VoxServe）以及通用框架（如 vLLM-Omni）。M* 处理任意循环、并行和流式传输的能力，且无需自定义胶水代码，解决了当前服务栈中根本性的抽象失配问题，从而促进了统一多模态、全能模型及世界模型在现实应用中的部署。