13 个月、30 个 Release、Qwen3-Omni 加速 12.97 倍：vLLM-Omni 用 Stage Graph 重构全模态推理

vLLM-Omni 这个项目，刚过完 13 个月生日——2025-09-11 vLLM 社区把它从 vLLM 主仓拆出来作为独立子项目，定位就一句话：把 vLLM 的高性能文本推理，扩展到「任意输入、任意输出」的全模态场景。截至 2026-10-08，仓库拿到 7,070 颗星、1,867 次 fork、3,373 次 commit、30 个 GitHub Release（v0.31.0rc1 刚在 10-06 发布），Apache-2.0 开源。

如果你关注的是「文本 LLM 的推理优化」，那 SGLang、vLLM 主线已经够你挑了。vLLM-Omni 想解决的是另一类问题：Qwen3-Omni 这种 Thinker → Talker → Code2wav 三段式流水线，BAGEL 这种图文双向生成，再加上 Qwen-Image、Wan2.2、FLUX 这种扩散模型——这些「不是纯自回归文本」的模型，怎么用一套调度器统一起来？

核心架构：Stage Graph + OmniConnector

vLLM-Omni 的技术核心是一篇 arXiv 论文（2602.02204，2026-02 上线）里讲清楚的：把任意复杂的多模态流水线拆成一张 Stage Graph，每个 Stage 可以独立调度、独立优化、独立部署在不同硬件上。

具体到代码，是 vllm_omni/entrypoints/omni_stage.py（Stage 抽象核心）+ vllm_omni/entrypoints/async_omni.py（Orchestrator 编排器）+ vllm_omni/diffusion/（独立 Diffusion 引擎）这三块。Stage 之间通过 OmniConnector 通信——单机用共享内存（5.49ms / 0.53ms 量级），多机用 Mooncake 传输引擎走 TCP 或 RDMA。

这跟 vLLM 主线的关系是：vLLM-Omni 复用了 vLLM 的自回归引擎（包括 PagedAttention、FlashAttention、KV 缓存管理、continuous batching），自己只补全了扩散引擎那块。所以你可以理解成：vLLM 是文本推理的 Linux 内核，vLLM-Omni 是全模态推理的 Kubernetes——一个管单进程调度，一个管跨阶段编排。

数字说话：为什么不是「又一个 Demo 框架」

从论文和官方 release notes 里挑几个实测数据（alphaXiv 综述 + 官方文档）：

• Qwen3-Omni：RTF（Real-Time Factor）降低 90.7%，JCT（Job Completion Time）降低 91.4%；Thinker TPS 提升 12.97 倍，Talker TPS 提升 7.98 倍
• Qwen2.5-Omni：RTF 降 61.4%，JCT 降 61.6%
• BAGEL：文生图加速 2.40 倍，图生图加速 3.72 倍（JCT 从 41.39s 降到 11.12s）
• MiMo-Audio：RTF 从 1.39 降到 0.12，相当于 11.58 倍加速（TTS 实时因子突破）

而传统 Hugging Face Transformers + Diffusers 的方案在 Qwen2.5-Omni 上只能跑到 15.91 tokens/s，vLLM-Omni 能到 78.69 tokens/s——差不多 5 倍吞吐量。

13 个月、30 个 Release，覆盖了什么模型

从 GitHub Releases 拉一遍，能看出项目的「扩品类节奏」：

支持的模型已经从最初的 Qwen-Omni 一家，扩到现在的「全家桶」：Qwen3-Omni、MiniCPM-o 4.5、Cosmos3、HunyuanImage、BAGEL；TTS 侧有 Qwen3-TTS、VoxCPM2、MOSS-TTS、CosyVoice3；扩散侧有 Qwen-Image、Wan2.2、FLUX；机器人侧有 GR00T-N1。

值得注意的还有：v0.14.0 之后，每个偶数 vLLM minor 版本（0.14 → 0.16 → 0.18 → 0.20 → 0.22 → 0.24 → 0.26 → 0.28 → 0.30）都会出一个对齐的 vLLM-Omni 稳定版。这意味着如果你想升级 vLLM 主线，vLLM-Omni 会被一起拖动——hysenlabs 的深度评测 把这称为「coupled upgrades」，需要提前规划版本节奏。

真实场景：谁已经在用了

• AWS：在 SageMaker AI 上跑 vLLM-Omni 部署 TTS 模型，卖点是「开始播放语音时还没生成完」
• NVIDIA：把 vLLM-Omni 接入 Dynamo v1.2.1 的后端，作为分布式推理的一个选项
• 社区：Reddit r/StableDiffusion 上 Cosmos3 Nano 的部署实测、Qwen 3 TTS 高并发速度测试、Krea 2 速度体验 都有用户实测帖
• 中文社区：知乎 和 OSChina 都有解读文

项目边界与坑：谁不该上

hysenlabs 那篇评测总结得很到位，别忽略这几个信号：

• pyproject.toml 仍标着 Development Status 3 – Alpha：Stage 级 API 在 minor 版本之间会变，要用就把代码钉死在特定版本
• 冷启动 ~100s：vs Official 后端 ~11s。容器化自动扩缩容的场景会吃亏，需要 TTS_WARMUP_ON_START=true 预热
• Diffusion Scheduler 当前只支持单请求：吞吐受限，吞吐型场景还不够用
• 不要在 vLLM-Omni 上开 Flash Attention 2：实测反而退化 8%（vLLM 自家注意力优化和 FA2 冲突）
• Orchestrator 1ms 轮询：高并发下可能成单点瓶颈
• D2H2D 跨阶段传输：经 CPU 中转，D2D 直连还在路线图

适合谁：已经在跑 vLLM、需要给自家产品加 TTS / 图像生成 / 视频生成 / 机器人策略模型、有 GPU 预算让 Stage 常驻的 AI 基础设施团队。

不适合谁：纯文本 LLM 场景（直接用 vLLM 主线）、需要稳定 API 表面做长生命周期集成的场景（钉版本但不指望升级）、单卡笔记本跑本地小模型（Ollama 仍是王者，CyberQ 把这俩定位讲得很清楚）。

可执行的下一步建议

1. 先看论文：https://arxiv.org/abs/2602.02204，搞清楚 Stage Graph 抽象对你业务的价值再决定要不要上
2. 跑 Quickstart：https://docs.vllm.ai/projects/vllm-omni/en/latest/getting_started/quickstart/，从离线推理（Offline batched inference）切到 OpenAI 兼容 server 也就几行代码
3. 确认你的模型在 Supported Models 列表 里：不在的话，要么等社区合入，要么自己写 Stage 注册
4. 算账：RTF 90.7% 的降幅在 Qwen3-Omni 上是真实的，但前提是你本来就在跑这套流水线。如果是从零起步，先用 Hugging Face Transformers 跑通，再考虑切换

仓库在这里：https://github.com/vllm-project/vllm-omni。现在 7,070 颗星，比同期的 vLLM 主线早期还快——如果「全模态推理统一框架」这件事能做成，vLLM-Omni 大概率就是那个标准答案。