AREX Feed Article
vLLM 项目发布 vLLM-Omni 技术报告，称其为面向全模态生成的统一服务运行时
10 月 8 日，vLLM 项目的 X 账号 发帖宣布分享 vLLM-Omni 技术报告，并附上论文与代码仓库两条短链。报告已在 ：编号 2610.09307，标题为《vLLM-Omni Technical Report: A Unified Serving Runtime for Omni-Modality Generation》，10 月 7 日提交，共 34 页、11 张图，作者栏署名 Omni Team。对应的代码仓库是 ，其 README 已把这次发布列入 2026 年 10 月的 Latest News，描述为一个面向文本、音频、图像、视频与动作生成的统一服务运行时。
帖文描述的问题很具体：语音助手、视觉生成、世界模型与机器人回路，已经把服务推到单一文本解码循环之外；多阶段自回归流水线、迭代扩散、跨步骤携带状态的会话，执行模式各不相同。LLM 服务器与扩散栈各自只深耕其中一类，生产部署往往要把互不相通的运行时拼接起来。按帖文的说法，vLLM-Omni 就是这类混合负载的共享控制平面：orchestrator（编排层）跨阶段推进每个请求，专用引擎执行计算，connector（连接器）传递载荷，同一会话语路让双工、世界模型与机器人回路留在同一个运行时上。
stage 与 orchestrator：推进请求的是控制面，计算在引擎里
vLLM-Omni 的发布公告出现在 2025 年 11 月 30 日的 上；2026 年 2 月的论文（）提出了把任意到任意模型分解成互连 stage（阶段）的抽象。这份报告在引言里写明新增的部分：最初的系统已经引入 stage 图、解耦引擎和 connector 支撑的传输，而报告把编排、流式进度、replica 池、中间数据移动与会话都变成显式的运行时关注点。
报告对 stage 的定义是：一个模型组件、一个执行引擎、一份资源预算。stage 之间交换有类型的中间状态：hidden states（隐藏状态）、codec codes（编解码 token）、latents（潜变量）、打包的 KV blocks（键值缓存块），可以同机共置，也可以跨进程、跨设备、跨主机拆开。stage 之上只有一个 orchestrator，掌管请求准入、跨阶段推进、客户端可见的进度与完成判定；报告同时划出边界：orchestrator 不调度 stage 内部的 token、不管 paged KV、不去噪扩散步骤、不搬运大张量，这些分别归执行引擎、中间数据管理和 OmniConnector。
请求的完成按「模态集合」判定：每个请求带一组最终输出 stage，全部排空才算完成。一个语音请求可以在 thinker 文本仍流式输出的同时开始重建波形，两者都结束才收尾。
容量扩展交给 StagePool：每个逻辑 stage 一个池，池内是彼此独立的 replica（副本）引擎；请求以粘性亲和绑定 replica，保持流式更新、多轮追加与 stage 内 KV 局部性，未绑定的请求按轮询或队列长度均衡分流；张量并行、数据并行、流水线并行与专家并行都在 replica 内部完成。引擎按阶段类型专业化，报告的解释是：自回归解码、非自回归张量生成与迭代扩散如果塞进同一个 worker，调度假设互不兼容。thinker、talker 这类自回归 stage 复用 vLLM 的 worker 与调度栈，可导出 hidden states 给下游；code2wav 这类非自回归的编解码、波形 stage 由 generation worker 执行，返回张量而非词表 logits；扩散 stage 用独立的 diffusion engine，支持把单个去噪步作为可调度单位、跨请求批处理，以及 TeaCache、Cache-DiT 一类步间缓存。面向世界模型的 AR–Diffusion 后端在 vLLM 的 block manager 上加了 runner 本地 paged KV，让会话级 KV 在分块 rollout 之间保留。每个 stage 可独立选择 vLLM V1 或实验性的 Model Runner V2（MRv2）。
控制面与数据面：OmniConnector 搬运四类载荷
报告把调度信号与重载荷拆成两条路。准入、路由、取消、完成等信号留在 orchestrator 路径；hidden states、codec chunk、latent、打包 KV 这些字节走 OmniConnector 数据面。connector 只暴露 put、get、cleanup、health 这类窄接口：生产者把载荷按 key 发布，返回共享内存名或远端传输句柄这类能挤进控制队列的小元数据，消费者凭它取回数据；connector 不解释载荷的语义。报告也明确了两者的分工：中间数据管理回答每条边要传什么、何时就绪，connector 回答字节放在哪、如何在进程或主机之间复制。
后端选择跟着部署位置走：单机默认走共享内存，跨节点支持面向存储与传输引擎的后端，包括 Mooncake 的 TCP 与 RDMA 路径，每条 stage 边可以独立选择。四类载荷在报告里写得很清楚：thinker→talker 传选定层 hidden states、prompt embeddings 与 token 元数据；talker→code2wav 传 RVQ 这类离散 codec codes；prefill–decode 与 AR→DiT 边搬从 paged block table 抽出的 KV blocks；DiT→VAE 边搬 latents。交付有两种模式：async-chunk（token 或 frame 一就绪就发布，消费者预热、边生成边消费）与 full-payload（攒完一次发布）；语音路径默认偏向 chunk，部分 TTS 路径还会按下游缓冲反馈动态调整 chunk 大小。
报告把会话控制设计成同一控制面的延伸：会话有比单次生成更长的身份，可 open、update、signal、close；容量准入能在部署饱和时拒绝新会话，空闲租约、显式重置与驱逐负责回收资源；fencing 元数据防止旧 turn 的迟到更新改写新响应。双工用 open/append/signal/close 加硬性会话上限，世界模型用类型化 session 加 LRU 回收，视频与机器人入口暴露 start、interaction 或 infer、stop 或 reset。paged KV 留在引擎 KV 池里，非 KV 的世界模型状态（如 latent ring）交给带设备字节记账的 session-state 层管理。
六类负载，两套接口：OpenAI 兼容面与 OpenPI
报告描述的服务面有两套，都绑定同一个 Omni 进程和同一条已加载的多阶段流水线。一套是 OpenAI 兼容的 HTTP 与 WebSocket：chat 支持图像、音频、视频内容与文本和/或音频输出，用 SSE（服务器推送事件）增量推送；speech 提供整段音频字节、分块原始音频或 SSE；图像生成与编辑沿用标准图像契约；视频有异步任务与同步返回两条路；另有 realtime 与 duplex（双工）的 WebSocket 会话。另一套是机器人策略用的 OpenPI 端点：用 msgpack（二进制序列化格式）走 WebSocket，执行从观测到动作的循环。
报告按服务拓扑把负载分成六类：AR Omni、TTS/语音、扩散图像视频、世界模型、视觉-语言-动作（VLA）/机器人、全双工。仓库 README 列出的支持面包括 Qwen3-Omni、MiniCPM-o 4.5、Cosmos3、HunyuanImage、BAGEL；Qwen3-TTS、CosyVoice3 等文本转语音（TTS）模型；MiniMax H3、LingBot World、Wan2.2 等扩散模型；以及 π0.5、GR00T-N1.7 等机器人策略模型。
硬件一侧，报告沿用了 vLLM 的插件路径：进程启动时解析出一个 OmniPlatform，CUDA 是默认，ROCm 与 MUSA 复用共享 GPU worker 并注入平台补丁，Ascend NPU 与 Intel XPU 用专属 worker 与集合通信后端，控制面语义不随设备改变。训练侧，报告提到 VeRL-Omni 这类框架把 vLLM-Omni 当 rollout 与服务后端，配合 LoRA 增删、sleep/wake 等控制面钩子；权重同步与优化器状态留在训练系统。
语音自测：async-chunk、MRv2 与 TTS 的数字
报告的数字来自项目公开的多模态 nightly CI：硬件是 H100，TTS 与 MiniCPM-o 的表则在 H200 上，评测聚焦 Qwen3-Omni；报告称所列 cell 均成功完成。指标里，TTFT 是首个文本 token 的延迟，TTFP 是首个音频包的延迟，RTF 是合成耗时与音频时长的比值（小于 1 表示快于实时播放），E2EL 是从客户端提交到响应完成的墙钟时间。
Qwen3-Omni 是 thinker→talker→code2wav 三阶段流水线。在 2×H100 的 Fixed-Len-2500/900 压测里，开不开 async-chunk 的差别随负载放大：并发 32 时，平均 TTFT 从 3,420.1 ms 降到 507.8 ms，平均 E2EL 从 136.62 s 降到 72.63 s，平均 RTF 从 0.927 降到 0.630。
需要手动开启的 MRv2 配置在 2×H200 上把并发 32 的平均 E2EL 从 75.06 s 压到 39.53 s，平均 RTF 从 0.423 降到 0.212，音频 TTFP 从 1,064.6 ms 降到 500.4 ms，代价是 thinker TTFT 略升（322.2 到 336.3 ms）。报告也写明：在实测 commit 上，MRv2 配置会因为共享的 model-state 代码读取只有融合版 Qwen3-TTS talker 才定义的属性而启动失败，所有 MRv2 数字都加了一行 guard 修补。
文本-only 路径还留着一个未查清的差异：并发 32 时，Omni 与 thinker-only vLLM 的 E2EL 同为 13.7 s，但 TTFT 分别是 860 ms 与 562 ms；报告写道，「尚未定位差距中有多少来自 thinker 前面的 stage 图与 orchestrator」。
Qwen3-TTS 的融合单卡配置（talker 与 Code2Wav 合并到一张卡，默认是两张）在每个 cell 都更快：C=8 时 CustomVoice 吞吐从 81.1 升到 111.6 audio-s/s（每秒生成的音频秒数），为原来的 1.38 倍；C=64 时达到 612.1 audio-s/s，C=1 的中位 TTFP 从 21.5 ms 降到 15.3 ms。CosyVoice3 的 packed streaming 配置把 C=64 的吞吐从 4.9 提升到 78.4 audio-s/s（约为原来的 16 倍），同点中位 TTFP 从 51.1 s 降到 1.7 s；Whisper 词错误率（WER）3.6%，默认配置为 3.9%。
扩散、视频与双工：另一半实测记录
图像侧，Qwen-Image 的 CI 配方在单张 H100 上跑 512²/20 步平均 2.41 s；换成 4 卡、把 attention 与 CFG 分片（Ulysses2+CFG2）再加 Cache-DiT，512² 降到 1.60 s，1536²/35 步从单卡 23.60 s 降到 5.20 s。
视频侧，Wan2.2-I2V-A14B（832×480、81 帧、4 步）用 USP2+HSDP 切片把端到端从 26.20 s 降到 18.04 s；MiniMax-H3 在 4×H100 上 T2V 平均 31.15 s，V2V 平均 103.18 s，报告将其归因于在文本之外还要以输入视频张量为条件。
双工负载测的是 MiniCPM-o 4.5，单张 H200：并发从 1 升到 8，平均 TTFP 从 433.3 ms 涨到 1,533.4 ms，平均 RTF 从 0.180 升到 0.895，吞吐从 1.37 到 2.10 req/s（每秒请求数）；并发 8 时 128 条输出的 Whisper WER 为 1.6%。报告另外测了一个更快的 turn-mode MRv2 配置，并发 8 时 TTFP 658 ms、5.49 req/s，但它不能可靠停止，13% 的输出在目标句子后追加了无关语音，WER 升到 12.9%（原生 chat template 下 11.0%），因此没有被当作结果报告。
两则外部回应与报告标注的边界
发布之后，有两则带具体信息的外部回应。回复中， 称他在一台 RTX 5090 上「独立复现」了 Qwen3-TTS 路径：经 vLLM-Omni 的首个音频延迟中位数 47 ms，而经普通 transformers 约 2.3 s；该说法为其本人自述，本文仅作转述。引用帖中， 称其正在用 vLLM-Omni 实践 Qwen-Image 部署。帖文最后感谢 vLLM 与 vLLM-Omni 团队，并称欢迎贡献。
报告在结论里列明了尚未完成的部分：扩散 paged KV 目前只在选定的 DiT 流水线上可用，覆盖面与缓存感知的准入仍不均衡；更广泛的会话负载、闭环机器人评测与跨硬件平台的测量，都还列在未来工作里。