vLLM-Omni技术报告发布：全模态生成统一服务运行时，79条模型线接入六大负载

2026 年 10 月 9 日——vLLM 社区于 10 月 7 日在 arXiv 发布 vLLM-Omni 技术报告（编号 arXiv:2610.09307，全文 34 页、11 图），并于 10 月 8 日通过官方 X 账号确认。该报告将语音助手、视觉生成、世界模型与机器人闭环等全模态推理负载统一到单一服务运行时之下：一个编排器推动请求跨阶段前进，专用引擎执行计算，OmniConnector 连接器承载数据平面传输，会话控制支撑全双工与闭环负载。按报告支持模型表统计，当前已有 79 条模型线接入，硬件平台横跨 NVIDIA CUDA、AMD ROCm、摩尔线程 MUSA、华为昇腾 NPU 与 Intel XPU 五种。

2026-10-09 · vLLM-Omni · 推理服务 · 全模态生成

一、概览

1.1 发布时间线

据 arXiv 页面信息，这份题为《vLLM-Omni Technical Report: A Unified Serving Runtime for Omni-Modality Generation》的技术报告于 2026 年 10 月 7 日 02:04（UTC）提交 v1 版本，分类为分布式、并行与集群计算（cs.DC），由 vLLM-Omni Team 署名，提交人为 Peiqi Yin。10 月 8 日 10:51（当地时间），vLLM 官方 X 账号 @vllm_project 发布推文确认该报告，附论文与代码仓库链接，官方在推文中表示："语音助手、视觉生成、世界模型和机器人闭环已经让推理服务超越了单一的文本解码循环"，vLLM-Omni 正是为这种混合场景打造的共享控制平面。

从项目沿革看，据 GitHub 仓库 vllm-project/vllm-omni 的更新日志，vLLM 社区于 2025 年 11 月正式发布该仓库，用于支持全模态模型服务；自 0.14.0 版本起，vLLM-Omni 与上游 vLLM 的每个偶数小版本对齐发布稳定版。2026 年 2 月，团队曾发布前作论文《vLLM-Omni: Fully Disaggregated Serving for Any-to-Any Multimodal Models》（arXiv:2602.02204）；本次技术报告是该方向的首份系统性技术文档。项目采用 Apache License 2.0 开源协议。

1.2 项目定位

据 GitHub 仓库描述，vLLM-Omni 的项目口号为"Easy, fast, and cheap omni-modality model serving for everyone"（为人人提供简单、快速、廉价的全模态模型服务）。官方文档将其定位为对 vLLM 的能力扩展：vLLM 原本面向文本自回归生成任务设计，vLLM-Omni 将支持范围扩展到全模态模型推理与服务，具体覆盖三个方向：文本、图像、音频、视频与动作数据的全模态处理；以扩散 Transformer（DiT）为代表的非自回归并行生成架构；从传统文本生成到多模态与动作输出的异构输出形态。

官方表示，vLLM-Omni 的性能来自三方面设计：复用 vLLM 高效 KV 缓存管理带来的先进自回归支持；流水线化的阶段执行重叠以提升吞吐；基于 OmniConnector 的完全分离部署（fully disaggregation）与跨阶段动态资源分配。灵活性方面，官方列出六项能力：异构流水线抽象、与 Hugging Face 主流模型的无缝集成、张量/流水线/数据/专家四种并行策略、流式输出、OpenAI 兼容 API 服务器，以及支持流式音频输入输出的全双工实时服务。

二、问题背景：从单一文本解码循环到多阶段工作流

报告引言部分给出的问题定义是本次发布的核心逻辑。官方指出，与智能系统的交互正在超越以文本为中心的聊天机器人和编码智能体：语音原生助手、视觉生成与编辑、世界模型环境、机器人动作闭环要求模型输出文本、音频、图像、视频与动作等多种形态。这些模型在执行模式上存在分化，报告将其归纳为三类：

其一，多阶段自回归全模态与 TTS 流水线，典型形态为"理解模型输出隐藏状态、语音生成模型接续合成音频"的接链方式；其二，迭代式扩散或流匹配生成器，图像与视频生成属于此类；其三，跨步骤携带状态的长生命周期工作负载，世界模型与机器人控制闭环属于此类。

报告认为，现有推理栈通常只为一种架构家族做优化：LLM 服务器在自回归调度与 KV 管理上纵深发展，扩散技术栈则在去噪与并行生成上纵深发展，两类栈都缺少一个让语音、像素或动作经由各自生成器输出的流水线共用的控制平面，因此生产部署常常退化为在互不兼容的运行时之间做临时拼凑。vLLM-Omni 的目标即为这类混合负载提供统一运行时。

三、架构解析：编排器、专用引擎与 OmniConnector

3.1 多阶段服务框架与编排器

报告第二章描述了 vLLM-Omni 的整体架构。系统将每个工作负载组织为多阶段流水线：一个阶段（stage）绑定一个模型组件、一个执行引擎和一份显式的资源预算。编排器（Orchestrator）负责请求准入、跨阶段推进、客户端可见输出的多路分发以及完成判定，官方明确其不参与 token 级调度、paged KV 管理、去噪循环与大张量搬运等具体计算。请求的完成被定义为"模态集合完成"，即最终输出阶段的集合全部执行完毕。

跨阶段流式传输方面，报告介绍了 async_chunk 机制：上游阶段生成的同时，分块将中间结果推给下游预热执行，以此降低首包延迟（TTFP，首个音频包时间）。针对不同负载，系统支持自适应 chunk ramp 策略，依据下游缓冲反馈动态调整分块大小，报告中该策略应用于 Qwen3-TTS。

3.2 执行引擎与阶段复制池

执行引擎按负载类型分化为四类。自回归引擎（AR engine）运行 vLLM 原生的连续批处理、token 采样与 KV 管理，承载全模态理解、TTS 文本前端与双工语音负载；生成引擎处理编解码解码（如 codec-to-wav）等非自回归步骤；扩散引擎在调度器与去噪循环之上支持跨去噪步骤的连续批处理，服务图像与视频生成；面向世界模型的 AR-Diffusion 混合后端则让自回归 runner 本地持有 paged KV 池，在会话内跨分块 rollout 保持 KV 连续性。

报告还介绍了实验性的 Model Runner V2（MRv2）执行路径：将采样状态移至设备端、以全量 CUDA graph 重放执行，减少 CPU 端调度开销。按报告默认配置，CUDA 平台上 Qwen3-TTS 默认启用 MRv2，Qwen3-Omni、MiniCPM-o、Higgs Audio v3、MOSS-TTS-Local、CosyVoice3 默认使用 V1 路径并可选 MRv2；非 CUDA 平台仍使用 V1 路径。

阶段扩展方面，系统为每个逻辑阶段维护一个复制池（StagePool），支持粘性亲和（sticky affinity）与轮询/最短队列两种负载均衡策略；复制池内部支持张量并行、数据并行、流水线并行与专家并行。

3.3 OmniConnector 数据平面与会话控制

中间数据的跨阶段传递由 OmniConnector 承担。报告将载荷归纳为四类：理解模型到语音生成模型的隐藏状态与嵌入、语音生成到声码器的编解码码流（如 RVQ 行）、预填充-解码分离与自回归到扩散交接的 paged KV 块、扩散模型的潜变量与多模态张量。接口层面提供写入、读取、清理与健康检查四类原语；单机默认走共享内存，跨节点支持 Mooncake TCP/RDMA 与 NIXL 等传输引擎后端，控制平面与数据平面相互分离。

会话控制面向长生命周期负载：会话具备身份标识与保留策略，容量准入控制并发会话上限，淘汰策略采用 LRU，fencing 元数据防止旧轮次数据污染新响应。在全双工模式（duplex）下，系统支持边听边说的实时交互，MiniCPM-o 4.5 已支持插话打断（barge-in），报告注明 PersonaPlex 与 Nemotron VoiceChat 尚不支持该特性。

四、API 与模型覆盖：六大负载家族、79 条模型线

4.1 API 体系

报告第四章描述了两套 API。第一套为 OpenAI 兼容 API：chat completions 接口支持 SSE 流式输出文本与 base64 音频增量；speech 接口兼容 OpenAI speech 契约并提供批量合成与音色管理、WebSocket 流式合成；image 接口覆盖图像生成与编辑；video 接口采用异步任务提交加同步字节拉取模式；realtime 接口提供 WebSocket 上的视频对话、实时视频与 OpenAI 风格 realtime 事件流。第二套为面向机器人的 OpenPI 端点：采用 msgpack over WebSocket 传输，策略配置广播动作时域（action horizon）、动作键与图像分辨率等参数，支持会话重置与空闲超时。API 服务器支持多进程部署（--api-server-count 参数），当前版本对扩散阶段的多进程部署有限制。

4.2 六大负载家族

报告摘要将支持的工作负载归纳为 omni（全模态）、TTS、image/video（图像视频）、world-model（世界模型）、robot（机器人）与 duplex（双工）六大家族。按报告支持模型表（Table 2）逐行统计，当前共收录 79 条模型线，分布如下：

数据口径：模型线数量按论文 Table 2 逐行统计得出，同一模型的不同变体（如 Wan2.1 与 Wan2.2-T2V、Wan2.2-I2V）各计为一行。

4.3 硬件平台与效率栈

硬件平台方面，报告第三章介绍了五种平台的插件化支持：NVIDIA CUDA 为默认平台、覆盖范围最广；AMD ROCm 采用 Triton attention 路径；摩尔线程 MUSA 平台已接入；华为昇腾 NPU 平台配备专属 worker 实现与 hccl 通信、支持 MXFP8/MXFP4 量化与 msModelSlim 量化工具链；Intel XPU 平台配备专属 worker 与 xccl/ccl 通信库。

效率栈覆盖四个层面。量化支持 FP8/INT8、ModelOpt FP8 与 NVFP4、GGUF、AutoRound/INC、SVDQuant W4A4 与 bitsandbytes 等格式与工具；显存卸载支持分层 CPU offload 与 sleep mode L1 模式；编译加速包含 CUDA graph 与 regional torch.compile；扩散专属缓存包含 TeaCache、Cache-DiT 两个一级缓存与 MagCache 次级缓存。

生态方面，官方运营 recipes 部署配方站点（recipes.vllm.ai）、与 ComfyUI 建立客户端集成、通过导入时的版本偏差检测保持与上游 vLLM 对齐，并与强化学习训练框架 VeRL-Omni 打通训练-推理交接（v0.2.0 已支持基于 vLLM-Omni 的扩散 RL、Qwen3-Omni 多模态训练的 DPO 与 GSPO、LoRA 动态挂载与 sleep/wake 显存管理）。近四个版本的演进重点如下：

五、评测数据：H100/H200 上的关键数字

5.1 评测口径

报告第五章说明，评测跑在多模态 nightly CI 上，图像、视频与世界模型组使用 NVIDIA H100，语音组（Qwen3-Omni、TTS 组合与 MiniCPM-o）使用 H200；nightly CI 数据冻结于 2026 年 9 月 14 日，评测以 Qwen3-Omni 为主。指标覆盖 TTFT（首个文本 token 延迟）、TTFP（首个音频包延迟）、TPOT（每输出 token 时间）、端到端时延（E2EL）与 RTF（实时率，音频合成时间与音频时长的比值，低于 1 表示快于实时）。GPU 配置按负载划分：全模态 2-3 卡、TTS 组 2 卡（融合版 Qwen3-TTS 单卡）、Qwen-Image 单卡或 4 卡、Wan 单卡、Cosmos3 演示 2 卡、MiniMax H3 4 卡。

5.2 Qwen3-Omni 全模态负载

在固定长度负载（输入 2500 token、输出 900 token）、2 卡 H200、并发 32 的设置下，MRv2 执行路径与默认 V1 路径的对比如下：

在随机多模态负载（Random-MM）上，MRv2 将端到端时延降低 15%-33%，其中音频加图像加视频组合一臂从 5.28 秒降至 3.53 秒；实时率从 0.10-0.15 收敛至 0.09-0.11；理解阶段 TTFT 偏差保持在 3% 以内。纯文本负载路由方面，并发 1 时与仅运行理解模型的 vLLM 相比差距在 6% 以内；并发 32 时端到端时延相同（均为 13.7 秒），TTFT 为 860 毫秒对 562 毫秒。

async_chunk 跨阶段分块的消融实验（2 卡 H100、并发 32）显示，关闭分块时 TTFT 为 3420.1 毫秒、端到端时延 136.62 秒、RTF 0.927；开启分块后三项分别改善至 507.8 毫秒、72.63 秒与 0.630。复制池扩展实验（3 卡 H100、复制数 2）显示并发 8 时音频首包 486.5 毫秒、RTF 0.190；并发 32 时 RTF 反而升至 0.732，报告将其归因于理解阶段准入与跨阶段交接成为瓶颈。

5.3 TTS 语音合成负载

TTS 组评测在 H200 上进行，使用 Seed-TTS 英文测试集。Qwen3-TTS 融合单卡部署（talker 自带流式编解码解码器直接输出 PCM）与两阶段双卡部署的对比如下：

其余 TTS 引擎在默认与调优配置下的表现汇总如下：

注：吞吐单位"音频秒/秒"（audio-seconds per second）表示系统每秒可合成的音频时长；WER 为词错误率，数值越低越好。以上数据均出自报告第五章评测表。

5.4 图像、视频与世界模型负载

图像组评测在 H100 上进行。Qwen-Image 文生图 512×512 分辨率、20 步采样在单卡上延迟 2.41 秒、吞吐 0.415 请求/秒、峰值显存 55121 MiB；启用 step-exec 并发批处理后并发 8 时吞吐升至 0.816 请求/秒（单请求延迟升至 9.66 秒）；4 卡加 Cache-DiT 缓存后延迟降至 1.60 秒、吞吐 0.559 请求/秒。1536×1536 分辨率、35 步采样的高分辨率场景下，单卡延迟 23.60 秒，Ulysses2 加 CFG2 并行降至 8.22 秒，4 卡加 Cache-DiT 进一步降至 5.20 秒（吞吐 0.192 请求/秒）。图像编辑场景中，Qwen-Image-Edit 512×512、20 步延迟从 8.84 秒降至加 Cache-DiT 后的 3.47 秒；双图编辑从 13.84 秒降至 3.59 秒。

视频组方面，Wan2.2-I2V-A14B 在 832×480 分辨率、81 帧、4 步采样下单卡延迟 26.20 秒，USP2 加 HSDP 并行降至 18.04 秒；1280×720、121 帧的 USP2 配置延迟 96.19 秒。世界模型方面，Cosmos3-Nano 官方演示配置（2 卡 H100）文生图 1024×1024、4 步延迟 0.83 秒；1280×720、189 帧的文生视频、图生视频与视频续写延迟分别为 28.88 秒、28.07 秒与 28.17 秒。全模态视频生成方面，MiniMax H3（4 卡 H100、1344×768、209 帧、8 步）文生视频 31.15 秒、加扩散缓存卸载 30.75 秒、图文到视频 32.53 秒、视频到视频 103.18 秒。

5.5 全双工负载

全双工组在单卡 H200 上评测 MiniCPM-o 4.5 挑战集：并发从 1 升至 8 时，音频首包从 433 毫秒升至 1533 毫秒，RTF 从 0.18 升至 0.90，吞吐从 1.37 升至 2.10 请求/秒；并发 8 下 128 条输出的话术错误率（WER）为 1.6%。报告同时披露一项未计入结果的实验：轮次模式的 MRv2 配置（PR #8222）将并发 8 首包压至 658 毫秒、吞吐提至 5.49 请求/秒，但 13% 的输出在目标语句结束后追加无关语音（对应 WER 12.9%/11.0%），团队因此未将其作为正式结果报告。双工 Seed-TTS 会话在并发 1 下运行四轮对话的 RTF 约为 1.088。

六、相关工作与生态位

报告第六章将 vLLM-Omni 与近期出现的同类系统并列：SGLang-Omni 同样采用阶段导向设计；M* 提出 Walk Graphs 通用 DAG 调度（arXiv:2606.12688）；xDiT、Diffusers 与 SGLang-Diffusion 属于扩散模型库与并行扩散推理方向；Mooncake 是面向 LLM 的 KV 缓存中心化分离架构，其 AR 到 DiT 交接能力已被 vLLM-Omni 作为连接器后端集成；EPD 与 xLLM 属于边缘侧预取分离与推理服务方向；OpenPI 为机器人策略服务提供了参照端点。报告未与上述系统给出横向性能对比数据。

从公开信息看，vLLM-Omni 的差异化位置体现在三点：其一，单一编排器加阶段复制池加连接器的架构覆盖自回归、扩散与动作三类执行模式；其二，模型表覆盖从 TTS 到 VLA 的完整谱系且持续跟随上游 vLLM 偶数版本演进；其三，评测直接挂在项目 nightly CI 上，性能数据与日常回归绑定。

七、局限披露与后续方向

官方在结论章节披露了当前边界：扩散 paged KV 已在选定的 DiT 管线上可用，但覆盖范围与缓存感知准入尚未全面铺开；更广泛的会话型负载评测、闭环机器人负载评测与跨硬件平台的系统性测量被列为未来工作。报告还如实记录了一处工程问题：MRv2 路径下 Qwen3-Omni 在受测提交上存在启动缺陷（共享的 MRv2 模型状态代码读取了仅融合版 Qwen3-TTS talker 才定义的流式解码器属性），团队以一行防御性判断修复后完成评测。

后续值得关注的进展节点包括：技术报告对应能力向 vLLM-Omni 稳定版的回迁节奏；MiniMax H3 Turbo 在 NVIDIA Blackwell 与昇腾 950 上的实时推理表现；0.30.0 引入的引擎自有会话全双工框架在更多双工模型上的推广；以及 VeRL-Omni 侧扩散强化学习负载对推理侧的反馈。

八、同期发布：上游 vLLM 0.31.0 版本

8.1 发布概况

在 vLLM-Omni 技术报告发布前两天，vLLM 主线于 10 月 5 日在 GitHub 发布 v0.31.0 版本（release 创建于 10 月 2 日）。据官方发布说明，该版本包含 717 个提交，来自 307 位贡献者，其中 96 位为首次贡献。版本亮点集中在 DeepSeek-V4.1-Flash 性能优化、快速重启、Model Runner V2 与投机解码、大规模服务、调度控制、HiSparse 加固与安全加固七个方向。

8.2 模型支持与专项优化

新模型能力方面，0.31.0 新增 MiMo V2 的 MXFP4 MoE、BF16 MoE 路由器与 DFlash 草稿支持，GLM-5.2-MXFP4 走 ROCm DeepSeek-V3.2 路径，AMD-Quark 混合精度的 DeepSeek-V4.1-Flash-MXFP4 与 GLM-5.3-Flash Quark MXFP4 检查点，DiffusionGemma 结构化生成模式，以及 Granite 4.2 内置思维解析器。

既有模型的专项优化集中在五款模型上，其中国产模型占四席：

8.3 硬件平台、分发与破坏性变更

硬件平台方面：NVIDIA 侧升级 FlashInfer 0.7.0.post1，提供 Rubin 的 CUDA 13.4 nightly 镜像；AMD ROCm 侧升级 AITER v0.1.23、torch 2.13 与 Triton 3.8，Hy4 路径经 torch.compile 后解码时延降低 13 倍，并提供 Kimi-K3 a4w4 FlyDSL kernel；Intel XPU 侧升级 PyTorch 2.14，XPU graph 默认启用，融合 QK RMSNorm、RoPE 与门控后解码区提速 55%；CPU 侧为 Intel Diamond Rapids 提供 FP8 W8A8 支持，Arm paged attention 提速最高 25%。

分发渠道方面，PyPI 默认 wheel 基于 CUDA 13.0，另提供 ROCm 7.2.3 与 XPU wheel；Docker 镜像提供 CUDA 13.0（默认）、CUDA 12.9、ROCm、CPU 与 XPU 五种。依赖方面，版本绑定 FlashInfer 0.7.0.post1、Transformers 5.17.0 与 XGrammar 0.2.7。

破坏性变更方面，升级时需要注意：tokenizer_mode="slow" 被移除；在线量化参数 quantization="fp8" 重定向至 fp8_per_tensor 简写，Quark 静默在线量化被移除；AllSpark INT8 W8A16 GEMM 后端被移除；--enforce-eager 同时禁用 JIT kernel 预热；XPU graph 默认启用且 VLLM_XPU_ENABLE_XPU_GRAPH 环境变量被移除；transformers 依赖在 requirements 中新增了版本上界。

8.4 与 vLLM-Omni 的关系

两个发布同属 vllm-project 组织且相互衔接：vLLM-Omni 最新的 0.30.0 版本基于上游 vLLM 0.30.0 重建，其文档明确以"每个偶数小版本"为对齐节奏，照此推断其下一个稳定版将基于 vLLM 0.32.0；0.31.0 作为奇数版本主要是主线自身的演进节点。技术层面，Model Runner V2 执行路径在两个项目中同步推进——上游 0.31.0 为 MRV2 补齐草稿模型投机解码与自定义 logits 处理器，vLLM-Omni 技术报告中的 MRv2 则将其应用到全模态与 TTS 负载并给出评测数据。

九、行业观察

从行业视角看，本次技术报告释放的信号有三层。第一层是推理服务范式的迁移：语音助手、视频生成与世界模型负载的增长使"推理服务"的外延从文本解码循环扩展到多模态工作流编排，报告对三类执行模式的抽象为这一趋势提供了系统化表述。第二层是开源推理栈的竞争焦点上移：SGLang-Omni、M* 与 vLLM-Omni 在同一时间窗口内出现，竞争从单模型推理效率转向异构流水线的调度与数据平面设计。第三层是硬件适配面的扩张：单一框架同时覆盖 NVIDIA、AMD、摩尔线程、华为昇腾与 Intel 五种平台，其中昇腾平台支持 MXFP8/MXFP4 与 MiniMax H3 Turbo 实时推理，国产芯片在全模态推理软件栈中的位置得到具体化。

把时间线放在一起看，10 月 5 日 vLLM 0.31.0 发布、10 月 7 日 vLLM-Omni 技术报告提交、10 月 8 日官推确认，vLLM 生态的文本主线与全模态支线在同一周内先后交出节点性成果：前者以 717 个提交继续压深单模型推理的效率与规模上限，后者则把推理服务的边界推进到文本之外的六类负载。对中文模型生态而言，两条线上的投入同样密集——0.31.0 的专项优化名单里 DeepSeek-V4.1-Flash、GLM-5.3-Flash、Qwen3.8-Flash-Next、Kimi K3、MiniMax-M3 占据主体，vLLM-Omni 的 79 条模型线中国产模型过半。开源推理基础设施对国产模型的适配深度，正在成为衡量模型影响力的一项间接指标。

对中文模型生态而言，这份支持模型表中出现了大量国产模型：全模态的 Qwen3-Omni、Ming-flash-omni 2.0、MiMo-Audio、Step-Audio2，TTS 的 Qwen3-TTS、CosyVoice3、IndexTTS、MOSS-TTS、GLM-TTS、dots.tts，图像的 Qwen-Image、Z-Image-Turbo、HunyuanImage-3.0、GLM-Image、LongCat-Image，视频的 Wan2.1/2.2、HunyuanVideo-1.5、MiniMax H3、MAGI-2 与机器人的 InternVLA-A1 等。全模态模型的部署基础设施呈现向统一运行时收敛的态势，后续各模型在新一代推理栈上的适配速度值得关注。