vLLM-Omni 上线：多模态推理更简单、更快、更省

自项目开始，vLLM 一直专注于为大语言模型（LLM）提供高吞吐、低显存的推理能力。但今天的生成式模型已经远不止“文本输入、文本输出”：新的模型可以同时理解和生成文本、图像、音频、视频，背后也不再是单一自回归架构，而是由编码器、语言模型、扩散模型等异构组件拼接而成。

vLLM-Omni 是最早一批支持“omni-modality”模型推理的开源框架之一，它把 vLLM 在文本推理上的性能优势，扩展到了多模态和非自回归推理领域。

为什么需要 vLLM-Omni？

传统推理引擎大多为纯文本自回归（Autoregressive, AR）任务优化。随着模型进化为可以“看、听、说”的全能代理（omni agents），底层推理系统也不得不同时面对：

1. 1. 真·全模态：一条请求里既有文本，又有图片、音频甚至视频，输出形式也不再单一。
2. 2. 超越自回归：扩散 Transformer（Diffusion Transformer, DiT）等 并行生成模型 需要不同于 LLM 的调度和内存管理策略。
3. 3. 异构推理流水线：一次调用往往会经过“多模态编码 → LLM 推理 → 扩散生成”等多个异构组件，资源分配和调度更像一条复杂的作业流水线，而不是单一模型调用。

如果仍然用针对纯文本 LLM 的架构去硬撑这些多模态场景，常见的问题包括：

• • 模型被紧耦合在一个进程里，无法按阶段独立扩缩容；
• • 文本与图像/音频的吞吐和延迟特性完全不同，很难做到资源利用最大化；
• • 一条请求里混合多种模型时，调度逻辑易于失控、难以观测和调优。

vLLM-Omni 的目标，就是给推理工程师提供一个更贴近“真实多模态工作流”的框架：把不同推理阶段拆开管理、各自优化，同时保持整体体验尽可能接近“用 vLLM 起一个服务”的熟悉路径。

架构一览：从数据流出发重构推理系统

vLLM-Omni 不是在 vLLM 外面再包一层，而是从数据流（data flow）的角度重新拆解了整个推理路径。它引入了一个完全解耦的流水线架构，让不同阶段可以按需分配资源，并通过统一调度衔接起来。

在这套架构中，一个 omni-modality 推理请求大致会经过三类组件：

• • 模态编码器（Modality Encoders）：负责高效地把多模态输入编码成向量或中间表示，例如 ViT 视觉编码器、Whisper 等语音编码器。
• • LLM 核心（LLM Core）：基于 vLLM 的自回归文本/隐藏状态生成部分，可以是一个或多个语言模型，用于思考、规划和多轮对话。
• • 模态生成器（Modality Generators）：用于生成图片、音频或视频的解码头，例如 DiT 等扩散模型。

这些组件并不是简单串联，而是通过 vLLM-Omni 的管线调度在不同 GPU/节点间协同工作。对于工程团队来说，这意味着：

• • 可以针对不同阶段单独做扩缩容和部署拓扑设计；
• • 可以根据业务瓶颈（如图像生成 vs 文本推理）调整资源分配；
• • 可以在不破坏整体架构的前提下替换局部组件（例如切换为新的视觉编码器）。

关键特性：简单、灵活、高性能

从推理服务工程师的视角看，vLLM-Omni 的设计目标可以浓缩成三个词：Simplicity（简单）、Flexibility（灵活）、Performance（性能）。

1. 简单：会用 vLLM，就会用 vLLM-Omni

• • 沿用 vLLM 的使用体验：已经熟悉 vLLM 的同学，可以在几乎不改心智模型的情况下迁移到 vLLM-Omni。
• • 继续支持 Hugging Face 模型：多模态模型仍然通过熟悉的 HF 接口接入。
• • 提供 OpenAI 兼容的 API Server：方便直接挂到现有的应用或网关后面。

对很多团队来说，这意味着可以在保持“一个标准入口”的基础上，把后端升级为多模态和多阶段推理系统，而不必重写整个服务层。

2. 灵活：用 OmniStage 抽象描述整个工作流

vLLM-Omni 提供了一个称为 OmniStage 的抽象，用来描述和拼接各种 omni-modality 模型：

• • 你可以把多模态编码器、LLM、扩散生成头等视为不同的 Stage；
• • 通过 OmniStage 定义数据在各个 Stage 之间的流动方式；
• • 当前已支持 Qwen-Omni、Qwen-Image 等代表性 omni 模型，后续会持续扩展。

对于需要快速验证新模型、新架构的研究/工程团队来说，这个抽象可以让你更容易地在“生产可用”与“研究探索”之间切换，而不必每次都从零搭一套分布式推理系统。

3. 高性能：流水线并行让每个阶段都在忙

在性能层面，vLLM-Omni 通过流水线分阶段执行（pipelined stage execution）来提升整体吞吐：

• • 当某个 Stage 正在处理一批请求时，其他 Stage 不必空等，可以处理其它批次；
• • 通过合理的调度策略，尽可能减少 GPU 闲置时间；
• • 在异构模型组合的场景下，把“最慢阶段”对整体吞吐的拖累降到更小。

我们也将 vLLM-Omni 与 Hugging Face Transformers 做了对比基准测试，以展示在 omni-modality 推理场景下的效率优势。对于需要在有限预算下支撑高并发、长会话的推理服务，这种系统级优化通常会直接体现在 GPU 利用率和成本曲线上。

Roadmap：为未来的全模态推理预留空间

vLLM-Omni 仍在高速演进中。接下来，我们会围绕“更多模型支持 + 更强的推理效率 + 更好的框架弹性”几个维度持续打磨：

• • 扩展模型支持：跟进更多开源 omni 模型和扩散 Transformer，一旦社区里出现新的代表性架构，会尽量第一时间接入。
• • 自适应框架优化：持续演进框架本身，以更好地支持新出现的 omni-modality 模型和执行模式，让它既能跑稳定生产，又能承载前沿研究。
• • 更深的 vLLM 集成：逐步把 omni 能力上游合入 vLLM，使多模态成为 vLLM 生态的一等公民，而不是“外挂模块”。
• • 扩散加速：在并行推理（DP/TP/SP/USP）、缓存加速（TeaCache/DBCache）和算力加速（量化、稀疏注意力等）方面持续优化。
• • 完全解耦的推理阶段：基于 OmniStage 抽象，进一步把 encoder / prefill / decode / generation 等阶段完全解藕开来，提高吞吐、降低延迟。
• • 硬件支持：延续 vLLM 硬件插件系统的思路，把 vLLM-Omni 的能力扩展到更多硬件后端，让多模态推理在更多平台上“跑得起、跑得稳、跑得快”。

对于已经在生产环境里跑多模态模型的团队来说，这意味着可以在不频繁“推倒重来”的前提下，沿着一条持续演进的路线升级底层推理基础设施。

快速上手：从安装到示例工作流

vLLM-Omni 的首个 v0.11.0rc 版本基于 vLLM v0.11.0 构建，安装与使用路径延续了 vLLM 的风格。

安装

详细安装步骤请参考官方文档：
https://vllm-omni.readthedocs.io/en/latest/getting_started/installation/

这里给出一个典型路径的心智模型：

1. 1. 按照文档要求准备好 GPU、驱动与依赖环境；
2. 2. 安装 vLLM-Omni 所需的软件包；
3. 3. 根据业务需求选择要启用的模型与 Stage 组合。

运行 omni-modality 模型

想要快速体验 omni-modality 工作流，可以直接参考仓库中的示例：

https://github.com/vllm-project/vllm-omni/tree/main/examples

其中包含了针对图像、音频和视频生成的脚本，可以帮助你：

• • 理解不同 Stage 在实际工作流中的组合方式；
• • 作为起点扩展出自己的 pipeline；
• • 结合 Gradio Demo 快速验证交互体验。

vLLM-Omni 还提供了 Gradio 支持，下面这个示例展示了如何用 vLLM-Omni 以可视化方式服务 Qwen-Image 等模型（详见文中配图）。

加入社区：一起打磨全模态推理基础设施

vLLM-Omni 目前仍只是全模态推理的起点，我们正在积极支持更多架构，也期待社区一起参与路线图讨论和特性设计。

• • 代码与文档：
  GitHub 仓库：https://github.com/vllm-project/vllm-omni
  文档站点：https://vllm-omni.readthedocs.io/en/latest/
• • Slack 讨论：欢迎在 vLLM Slack 的 -omni 频道提问和反馈：https://slack.vllm.ai
• • 每周例会：我们在每周二晚 19:30（PDT）举办线上例会，讨论 roadmap 与特性设计，报名入口：https://tinyurl.com/vllm-omni-meeting

如果你正在为多模态模型搭建推理服务，或者在探索新的 omni-modality 模型形态，非常欢迎加入社区，一起把“多模态推理简单、够快、成本可控”这件事做扎实。