vLLM-Omni 架构全景：面向全模态模型的分阶段推理与服务体系
【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni
本文以 vLLM-Omni 的架构总览文档（docs/design/architecture_overview.md）为核心，深入解析其"分阶段（stage-based）"推理架构的设计动机、运行机制与控制面配置模型，并结合仓库源码（vllm_omni/config、vllm_omni/engine）与真实部署文件（qwen3_omni_moe.yaml）逐层验证。读完本文，你将掌握 vLLM-Omni 如何将自回归、生成与扩散三种执行策略编排进同一请求流水线，理解PipelineConfig与DeployConfig的职责边界，并能够解读 Qwen3-Omni、HunyuanImage-3.0、MiniMax-H3、Cosmos3 四类典型全模态模型在其中的阶段映射与服务指标选择。
一、设计目标：从文本 AR 运行时到全模态分阶段执行
vLLM-Omni 的核心目标是为全模态（omni-modality）模型提供快速、易用的推理与服务引擎。它在 vLLM 面向文本的自回归（AR）运行时之上，用阶段式执行（stage-based execution）扩展了对非文本输出和非自回归模型组件的支持。
架构设计遵循四条原则：
- 模态覆盖：支持文本、图像、音频、视频与动作（action）的输入和输出；
- 执行编排：在一个流水线中组合自回归、生成（generation）与扩散（diffusion）三类阶段；
- 复用优先：在合适处直接复用 vLLM 的调度（scheduling）、缓存（cache）、分布式执行与在线服务原语；
- 分层解耦：将模型拓扑、部署放置（placement）、运行时生命周期、传输（transport）与公共 API 关注点分隔到独立层次。
二、服务指标词汇表：按输出模态度量性能
架构文档明确指出，目标指标应跟随输出模态而非模型名称。这套词汇贯穿后续所有模型的性能讨论：
| 指标 | 本文含义 | 最适用于 |
|---|---|---|
| TTFT | 到首个文本 token 的时间 | AR 推理或文本输出 |
| TPOT | 首个 token 之后每个输出 token 的时间 | AR 解码阶段 |
| TTFP | 到首个流式媒体包（如音频）的时间 | 交互式语音与多模态对话 |
| E2EL | 从请求受理到最终输出的端到端延迟 | 图像、视频、音频与动作请求 |
| RTF | 墙钟处理时间除以生成音频时长；低于 1 表示快于实时 | 音频生成 |
| Throughput | 每秒产出的请求数、token 数或媒体秒数 | 离线与并发服务 |
这一设计隐含一个判断：对以扩散生成媒体为主的路径（如 DiT 出图、VAE 出视频），TTFT/TPOT 不再是合适的头号指标，而应聚焦 E2EL、去噪延迟与吞吐。
三、四个代表性模型的阶段映射
架构文档通过四个代表性流水线展示"模型组件 → 阶段本地执行策略"的映射。每个模型可能支持多种PipelineConfig与DeployConfig组合，下表是汇总视图：
| 模型 | 模型自有路径 | vLLM-Omni 阶段视图 | 主要服务目标 |
|---|---|---|---|
| Qwen3-Omni | Thinker → Talker → Code2Wav | 三个阶段，异步分块交接 | TTFT/TTFP、TPOT、E2EL、音频 RTF、并发吞吐 |
| HunyuanImage-3.0 | 多模态 AR 理解/推理 + 图像生成 DiT | 仅 AR、仅 DiT 或拆分 AR → DiT 部署 | DiT E2EL/去噪延迟与图像吞吐；AR 任务的 TTFT/TPOT |
| MiniMax-H3 | 文本编码器 → 任务特定 FL2VA 或 Ref2VA DiT → 视频/音频 VAE 解码器 | 单个注册扩散阶段内的三个逻辑组件/阶段边界 | 视频/音频 E2EL 与媒体吞吐；音频流独立评测时关注 RTF |
| Cosmos3 | 统一 MoT 推理器塔 + 扩散生成器塔 | 一个扩散流水线在阶段内物化两个塔 | 图像/视频/音频/动作 E2EL 与吞吐；同步音频的 RTF |
3.1 Qwen3-Omni：流式 AR 流水线（Thinker → Talker → Code2Wav）
Qwen3-Omni 展示了一条多阶段流式 AR 流水线：Thinker → Talker → Code2Wav。
按阶段的模型架构：
| 阶段 | 模型组件 | 阶段输出 |
|---|---|---|
| Thinker | AuT 音频编码器、SigLIP2 视觉编码器、30B 总参/3B 激活的 Thinker MoE Transformer | 文本 token 与 Talker 的 conditioning |
| Talker | 3B 总参/0.3B 激活的 Talker MoE Transformer，带 MTP 码本预测路径 | 文本 token 与音频 codec token |
| Code2Wav | 约 200M 参数的 ConvNet 音频解码器 | 波形/音频分块 |
代表性阶段执行策略：
| 阶段 | Batching | 注意力与执行 | 并行度 | 量化 |
|---|---|---|---|---|
| Thinker | 连续 batching，配合阶段本地max_num_seqs与 token 预算 | vLLM KV 缓存 AR 注意力；非 eager 时启用 CUDA Graph | 独立阶段放置；沿用 AR 运行时配置的张量并行 | 文档化路径中 ModelOpt FP8/NVFP4 或 AutoRound 检查点只针对 Thinker，编码器保持 BF16 |
| Talker | 对自回归解码请求做连续 batching | KV 缓存 token 解码，异步分块输出到 Code2Wav | 独立阶段放置，通常与 Thinker 分处不同 GPU 或副本 | BF16 基线，不假设通用 Talker 量化路径 |
| Code2Wav | codec 到波形解码的静态/分块 batching | 非 AR 分块音频解码，通常保留 eager 执行 | 独立阶段或同址放置 | BF16 基线，codec/vocoder 精度按模型保留 |
该流水线的主要服务目标是交互响应性：文本看 TTFT、首音频包看 TTFP、自回归解码看 TPOT、完整回答看 E2EL、持续音频服务看 RTF 与吞吐。异步分块与流式主要降低 TTFP 并提升阶段重叠；batching 与 CUDA Graph 主要改善 E2EL 与吞吐。
源码层面，阶段拓扑由StagePipelineConfig（vllm_omni/config/stage_config.py）描述，其中stage_id、model_stage、input_sources、final_output、execution_type定义了阶段身份与连接关系；async_chunk_process_next_stage_input_func/sync_process_input_func字段则对应异步分块与同步两种交接模式的模型自有钩子。部署侧的真实写照见 qwen3_omni_moe.yaml：三个 stage 依次放置在cuda:0（Thinker）与cuda:1（Talker + Code2Wav），通过SharedMemoryConnector完成 stage 间交接，且 stage 1/2 分别声明from_stage_0/from_stage_1的input_connectors。
3.2 HunyuanImage-3.0：共享多模态模型，拆分部署的选择
HunyuanImage-3.0 展示了一个共享多模态模型的灵活部署：仅 AR、仅 DiT，或带连接器的 AR → DiT 流水线。这是一种运行时能力分解，并非宣称官方框架图中存在两个不相关的主干。
按阶段/组件的模型架构：
| 阶段或组件 | 模型组件 | 阶段输出 |
|---|---|---|
| AR 理解/推理 | 理解与生成编码器，馈入 Hunyuan-A13B 仅解码器 Transformer 与文本 detokenizer | 文本回复或图像生成 conditioning |
| 图像生成 | 生成编码器、扩散预测路径/Gen. Decoder、图像 VAE 解码路径 | 图像 latents 与最终图像 |
代表性执行策略：
| 阶段 | Batching | 注意力与执行 | 并行度 | 量化 |
|---|---|---|---|---|
| AR | 服务理解/文本任务时采用标准 vLLM 连续 batching | KV 缓存因果注意力 | 张量/专家并行跟随所选 AR 部署 | 检查点特定；不要将 DiT 的 FP8 设置套用到 AR 检查点 |
| DiT + VAE | 请求 batching 或 step-wise batching；多请求的 Hunyuan step batching 需要TORCH_SDPA | 因模型混合因果与全注意力而使用TORCH_SDPA | 已验证配置含 TP4、TP2+序列并行、TP2+CFG 并行、MoE 专家并行 | DiT 有在线 FP8 与 ModelOpt 混合 FP8/NVFP4 文档；VAE 精度单独保留 |
因此，图像生成主要用每图 E2EL/去噪延迟、峰值内存与每秒图像吞吐度量；TTFT/TPOT 对可选的 AR 理解路径仍有意义，但并非 DiT 路径的头号指标。已验证的 batching、注意力与量化组合见 HunyuanImage-3.0-Instruct.md。
3.3 MiniMax-H3：条件编码、去噪与解码
MiniMax-H3 展示了文本编码、任务特定去噪与媒体解码之间的逻辑组件/阶段边界：Text Encoder → DiT → VAE Decoder。当前注册拓扑将三者同置于一个扩散阶段——这些边界主要用于 profiling 与 offload，独立放置需要未来的多阶段PipelineConfig。
按逻辑组件的模型架构：
| 逻辑组件 | 模型组件 | 组件输出 |
|---|---|---|
| Text Encoder | Tokenizer/processor 与 Qwen3-VL 文本编码器；视觉/音频引用与文本条件一并准备 | 打包的多模态 conditioning |
| DiT | 文本/首帧生成的FL2VADiT，或混合引用的Ref2VADiT | 视频与音频 latent token |
| VAE Decoder | 视频 VAE 与音频 VAE 解码生成的 latents 并组装同步输出 | 解码后的视频帧与立体声波形，附带 FPS 与音频采样率元数据 |
两个 DiT 分区仍处于同一个任务选择点之后，由task决定运行哪个分区。这与 Qwen3-Omni 的三个独立调度阶段不同——尽管两者都产出同步的音频与视频类输出。
代表性组件执行策略：
| 逻辑组件 | Batching | 注意力与执行 | 并行度 | 量化 |
|---|---|---|---|---|
| Text Encoder | 当前同址流水线跟随扩散请求调度器；独立 prompt/引用 batching 需要另设多阶段拓扑 | Qwen3-VL 注意力与多模态预处理 | --text-encoder-tp-size N将编码器切分到前 N 个 DiT rank；独立放置不属于当前拓扑 | BF16/FP32 基线；H3 DiT FP8 路径不量化文本编码器 |
| DiT | 当前 H3 实现每个扩散 batch 执行一个生成请求；服务级吞吐靠并发 | 已验证双 GPU 消费级配置用 cuDNN 注意力；受支持的 Blackwell 配置可用 TRTLLM 注意力或 FlashAttention-4 | 多 GPU 配置下 TP2 + 文本编码器 TP + Ulysses/VAE 并行组；DLO/CPU offload 用传输时间换内存 | 在线 FP8 适用于符合条件的 DiT 线性层，且与逐层 offload 不兼容 |
| VAE Decoder | 每个生成请求后跟随解码；即使去噪未 batching，tile/patch 工作也可分布 | VAE 解码 kernel 而非 DiT 注意力 | 扩散阶段内的 VAE patch 并行与原生 tiled 解码 | BF16/FP32 基线；文档化 H3 FP8 路径保持两个 VAE 不变 |
主要目标为视频/音频 E2EL 与媒体吞吐，逻辑组件边界使 prompt 编码、去噪与 VAE 解码成本可分别度量。TTFT/TPOT 不描述 H3 主生成路径，因为用户可见输出是扩散媒体而非 token 流。硬件特定配置与 warmup 要求见 MiniMax-H3.md。
3.4 Cosmos3：统一的 MoT 推理器与生成器
Cosmos3 展示统一 Mixture-of-Transformers（MoT）推理器与扩散生成器的组合。
按阶段/组件的模型架构：
| 阶段或组件 | 模型组件 | 阶段输出 |
|---|---|---|
| Reasoner 塔 | 带因果注意力的自回归 VLM 路径，覆盖语言与可选视觉/动作上下文；每个生成请求运行一次 | 离散推理/上下文 token |
| Generator 塔 | 对生成器 token 与 reasoner K/V 上下文做全注意力的扩散路径；每个去噪步运行 | 图像、视频、音频或动作 token |
| 共享流水线 | Cosmos3OmniDiffusersPipeline加模态编码器/解码器与 VAE 路径 | 最终图像/视频/音频或动作响应 |
reasoner 与 generator 是模型自有组件，默认不是两个独立的 vLLM-Omni 阶段；当前 Cosmos3 流水线在单个扩散阶段内物化两者，模型级 CPU offload 可在各自阶段间交换 reasoner 与 generator 组件。
代表性执行策略：
| 阶段 | Batching | 注意力与执行 | 并行度 | 量化 |
|---|---|---|---|---|
| Reasoner + generator 流水线 | 仅当所选流水线声明支持请求 batching 或 step 执行时使用；否则用max_num_seqs=1 | reasoner token 用因果注意力、扩散 token 用全注意力；已验证 recipe 使用平台选择的 aiter FlashAttention 路径并回退TORCH_SDPA | transformer 用 Ulysses/上下文并行或张量并行；VAE tiling 与逐层/模型级 offload 应对激活与权重内存 | 扩散流水线支持在线 FP8；AutoRound/检查点特定路径与质量验证独立于 BF16 基线 |
Cosmos3 的主要目标是生成 E2EL 与输出吞吐；动作策略（action-policy）工作负载增加控制回路延迟目标，同步音频工作负载增加 RTF。TTFT/TPOT 只适用于 reasoner-only 服务，不适用于完整扩散生成路径。运行时选择详见 Cosmos3-Nano.md 与 execution_modes.md。
四、为什么阶段式架构是必然结论
四个代表性流水线表明，全模态服务不是单一的执行问题：自回归解码、扩散去噪、多模态编码与媒体解码在调度、注意力、并行度、内存与量化上需求各异，因此需要一种既能独立优化与资源配置、又同属一条请求流水线的执行单元。架构文档用一张观察→设计含义→架构回应的对照表给出推导：
| 观察 | 设计含义 | vLLM-Omni 回应 |
|---|---|---|
| AR、扩散、编码器、解码器执行循环不同 | 单一调度器与单一执行策略无法适配所有组件 | 专门的 AR、generation、diffusion 阶段运行时 |
| 模型可仅 AR、仅 DiT 或 AR → DiT 部署 | 模型结构必须与部署拓扑分离 | PipelineConfig描述逻辑阶段与关系；DeployConfig描述放置与资源 |
| 文本编码器、DiT、VAE 解码器批处理与内存行为不同 | batching、注意力、并行度、量化必须阶段本地化 | 每个阶段携带自己的运行时与引擎配置 |
| MiniMax-H3 可同置或逻辑拆分文本编码器与 VAE 解码器 | 阶段边界应可配置而非强制进程边界 | 逻辑阶段可同置，也可分配独立运行时放置 |
| Qwen3-Omni 跨阶段传递隐状态与 codec 分块 | 大量中间数据需要类型化传输与同步 | OmniConnector传输 payload 与 KV 缓存数据，不拥有模型路由 |
| 请求跨多阶段，可能被取消或产出有序流式输出 | 跨阶段请求状态需要独立控制面 | Orchestrator拥有关联、取消、路由状态与输出排序 |
| Qwen3-Omni 优化首包延迟，图像/视频模型优化 E2EL 与吞吐 | 性能目标必须模型与阶段感知 | TTFT/TPOT/TTFP、E2EL、RTF、吞吐按输出模态度量 |
由此得到阶段的精确定义：它是一个逻辑执行单元，拥有自己的模型组件、执行策略、资源所有权与性能目标。阶段不必然是独立进程——Cosmos3 将 reasoner 与 generator 保留在单个扩散流水线内，MiniMax-H3 则在文本编码、去噪与 VAE 解码之间暴露逻辑边界，两者都是同一抽象的有效映射。
层次分离的完整链路为：
模型结构 计算什么、组件间如何关联 ↓ PipelineConfig 存在哪些逻辑阶段、如何连接 ↓ Stage 运行时策略 每个阶段如何 batching、注意力、并行化与量化 ↓ DeployConfig 阶段运行在哪里，使用哪些设备、副本与连接器AsyncOmniEngine与Orchestrator协调流水线，OmniConnector传输阶段输出，StageRuntime物化所选放置。这种分离让一个逻辑模型支持多种服务拓扑，而无需将模型代码与进程布局或部署资源耦合。
五、系统架构：从入口到输出的核心组件
系统整体由入口、共享的AsyncOmniEngine、请求编排、阶段生命周期管理、AR 与扩散执行模块、模型/层算子、连接器传输与多模态输出组成。AsyncOmniEngine是入口与编排器之间的组合根（composition root）。
核心组件职责如下：
| 组件 | 职责 |
|---|---|
| Entrypoints | 将离线、CLI、OpenAI 兼容与 duplex 请求翻译为引擎操作，并把输出渲染回公共协议 |
| 配置解析 | 将流水线拓扑、部署设置、模型元数据与用户覆盖合并为一份已验证的控制面配置 |
| AsyncOmniEngine | 拥有引擎组合、后台事件循环、阶段初始化、请求提交与输出收集 |
| Orchestrator | 拥有跨阶段请求状态、阶段间路由、请求关联、取消与输出排序；不拥有模型选择或部署放置 |
| StageRuntime | 将逻辑阶段扩展为本地或分布式副本，启动阶段客户端与进程，管理就绪、亲和性、失败与关闭 |
| AR 运行时 | 扩展 vLLM 的调度器、KV 缓存、worker 与 model-runner 路径以支持全模态输入与阶段间输出 |
| 扩散运行时 | 通过扩散 executor、worker、pipeline、加速后端与输出物化调度并执行去噪工作负载 |
| OmniConnector | 传输阶段 payload 与 KV 缓存数据并提供同步；连接器只传输数据，不选择下一逻辑阶段 |
| 多模态输出 | MultimodalPayload将张量内容与元数据分离，OmniRequestOutput通过公共输出路径携带流水线与扩散结果 |
源码佐证：AsyncOmniEngine（vllm_omni/engine/async_omni_engine.py）是一个"瘦代理"，在后台线程中启动Orchestrator，通过 janus 队列与调用方通信；Orchestrator（vllm_omni/engine/orchestrator.py）运行在专用 asyncio 事件循环中，持有OrchestratorRequestState与StagePool列表；StageRuntime（vllm_omni/engine/stage_runtime.py）直接启动阶段进程并创建静态客户端的StagePool；OmniConnectorBase（vllm_omni/distributed/omni_connectors/connectors/base.py）抽象出put/get/cleanup契约，并允许支持 RDMA 等原生 raw 字节拷贝的连接器覆写supports_raw_data。
六、配置与运行时解析：五层控制面
控制面由五个概念层组成。创作输入在运行时进程启动前被一次性解析为完整、可安全传输的配置，从而把阶段拓扑与模型能力同部署放置、进程本地引擎对象区分开：
生产解析边界是 resolver.py 中的resolve_omni_config()。它将类型化构造委托给StageConfigFactory.create_from_model()与VllmOmniConfig.from_pipeline_config()（vllm_omni/config/omni_config.py），随后返回OmniConfigResolution（vllm_omni/config/resolver.py），供AsyncOmniEngine与无头（headless）启动共同消费。在StageRuntime直接消费类型化阶段配置之前，该信封携带有效的PipelineConfig与 OmegaConf 兼容的stage_configs作为临时运行时桥接层——两个视图描述同一份已解析拓扑（含注入阶段）。需要注意：
- 遗留的
stage_argsYAML 路径已移除；模型拓扑现在通过PipelineConfig解析，运行时覆盖由DeployConfig提供； - 类型化路径中，每个阶段配置派生自
BaseVllmOmniStageConfig，并特化为VllmOmniARStageConfig、VllmOmniGenerationStageConfig或VllmOmniDiffusionStageConfig。
6.1 源码级验证：配置所有权规则
从 stage_config.py 源码可确认以下字段级事实：
PipelineConfig（L281-L368）是冻结拓扑的权威来源，字段包括model_type、model_arch、stages、hf_architectures、hf_config_predicate、diffusers_class_name、endpoint_restrictions、default_deploy_config_name与stage_cli_aliases等。其__post_init__会执行拓扑校验：阶段 ID 不可重复、input_sources必须引用存在的阶段且不能自引用、必须存在一个入口阶段（input_sources为空）与一个终结阶段（final_output=True）——没有终结阶段的流水线将导致请求永久挂起（见Orchestrator._route_output的依赖）。StagePipelineConfig（L229-L277）声明单阶段固定拓扑：stage_id、model_stage、execution_type、input_sources、final_output、owns_tokenizer、retains_state_across_chunks、prompt_transform_func、scheduler_cls、model_subdir/tokenizer_subdir、inline_diffusion等。其中execution_type由StageExecutionType枚举给出三种取值：llm_ar、llm_generation、diffusion（L194-L199）；_resolve_scheduler（L202-L219）据此为 AR 阶段选择同步OmniARScheduler或异步OmniARAsyncScheduler，为生成阶段选择OmniGenerationScheduler，扩散阶段则走扩散调度路径。DeployConfig（L543-L576）是用户唯一需要编辑的配置文件（对应deploy/<model>.yaml）。顶层字段（trust_remote_code、distributed_executor_backend、dtype、quantization、enable_prefix_caching、enable_chunked_prefill、data_parallel_size、pipeline_parallel_size）为流水线级设置，统一应用到每个阶段；逐阶段可变的字段（max_num_seqs、devices、GPU 放置等）则放入StageDeployConfig（L371-L498），后者覆盖张量并行、专家并行、max_num_batched_tokens、gpu_memory_utilization、enforce_eager、async_scheduling、扩散专用并行（ulysses_degree、ring_degree、sequence_parallel_size、cfg_parallel_size、vae_patch_parallel_size、text_encoder_tp_size、HSDP 相关字段）、offload 相关（enable_distributed_layerwise_offload、dlo_resident_layers、host_weight_runtime_mode）以及default_sampling_params、input_connectors/output_connectors等传输接线。- 覆盖优先级规则为：调用方显式传入（非 None）值 > deploy YAML >
StageDeployConfig默认值（见 config_factory.py 中_resolve_legacy_from_registry的注释）；CLI 的stage_<id>_<key>形式提供逐阶段覆盖，全局覆盖中非逐阶段字段则流向每个阶段（build_stage_runtime_overrides，L47-L89）。
关键所有权规则可归纳为六条：
PipelineConfig是阶段拓扑、执行类型、模型能力与阶段关系的唯一事实来源；DeployConfig描述放置、副本、设备、连接器与部署期默认值，不重新定义模型图；- CLI 与 Python 覆盖在解析边界应用，受支持处逐阶段覆盖优先于全局值；
OmniConfigResolution是唯一的启动交接物，其pipeline_config与临时stage_configs兼容视图必须描述同一拓扑；StageRuntime拥有启动规划与副本生命周期，ReplicaInitPlan是运行时私有状态而非用户配置对象；VllmConfig与增强版OmniDiffusionConfig在拥有对应引擎的进程中物化。
6.2 真实部署示例：qwen3_omni_moe.yaml
以仓库自带的 qwen3_omni_moe.yaml 为例，可直观看到上述抽象如何落到磁盘配置（已在 2×H100 上验证：stage 0 于cuda:0，stage 1+2 于cuda:1）：
- 顶层
async_chunk: true开启异步分块交接； connectors段定义SharedMemoryConnector，并携带 codec 分块参数（initial_codec_chunk_frames: 4、codec_chunk_frames: 25、codec_left_context_frames: 25）；- stage 0（Thinker）：
max_num_batched_tokens: 32768、max_num_seqs: 64、gpu_memory_utilization: 0.9、moe_backend: triton、devices: "0"、default_sampling_params.temperature: 0.0； - stage 1（Talker）：
gpu_memory_utilization: 0.6、devices: "1"、input_connectors.from_stage_0指向共享内存连接器、采样参数temperature: 0.9、top_k: 50、repetition_penalty: 1.05； - stage 2（Code2Wav）：
max_num_batched_tokens: 65536、gpu_memory_utilization: 0.1、async_scheduling: false、input_connectors.from_stage_1、max_tokens: 65536； platforms段按平台覆写：CUDA 上为 Thinker 保留 MRoPE 的 CUDA 路径（custom_ops: ["+rotary_embedding"]），ROCm 上 stage 2 因 MIOpenconv_transpose1d不可图捕获而enforce_eager: true，NPU 上使用PIECEWISEcudagraph 模式并调整 TP 与显存，XPU 上 stage 0 开 TP4 且全 eager。
该文件注释还解释了省略字段如何回退到默认值，印证了"yaml 逐阶段值 > vLLM 默认"的覆盖语义，是理解阶段配置的最小可运行范本。
七、主要特性概览
特性面与功能设计文档分组对应，以下仅概括各特性的架构角色，配置、兼容性与实现细节以对应设计文档为准。
运行时与阶段执行
- 分离式推理（Disaggregated inference）：逻辑阶段可运行在独立进程、设备或节点上，
Orchestrator保持其声明关系，OmniConnector实现负责传输阶段数据与控制面元数据。详见 disaggregated_inference.md。 - 异步阶段与输出执行：async_chunk.md 在部分阶段输出可用时即转发；async_diffusion_output.md 将设备到主机的输出打包与下一扩散请求重叠；omni_async_output_materialization.md 将 CPU 侧 payload 构造移出 AR 解码关键路径。
- 自动前缀缓存：prefix_caching.md 为具有公共前缀的请求复用 KV 缓存对齐的阶段输出与多模态张量。
通信
- OmniConnector 传输：连接器契约跨阶段边界携带张量、KV 缓存数据与传输元数据；已实现覆盖共享内存与多节点 Mooncake、Mori、Yuanrong 传输，选择与配置模型见 disaggregated_inference.md。
扩散加速
- 请求与 step batching：diffusion_continuous_batching.md 定义请求批与 step 批执行、调度器准入与公共流式输出路径。
- 可组合并行：扩散阶段可按流水线与硬件拓扑组合 CFG-Parallel、Expert Parallel、HSDP、Pipeline Parallel、Sequence Parallel、Tensor Parallel 与 VAE Patch Parallelism。
- 注意力与缓存加速：skip_softmax.md、cache_dit.md 与 teacache.md 在不改变阶段契约的前提下提供后端与去噪步优化。
- 量化与内存效率：quantization.md 解析逐流水线或逐组件量化配置；distributed_layerwise_offload.md 在既有并行拓扑内从主机内存流式搬运扩散块。
八、公共接口：同一引擎边界上的三种接入方式
8.1 离线推理
Omni类提供面向离线批量推理的 Python 接口，可同时携带文本、视频与音频输入：
from vllm_omni.entrypoints.omni import Omni omni = Omni(model="Qwen/Qwen3-Omni-30B-A3B-Instruct") om_inputs = { "prompt": prompt, "multi_modal_data": { "video": video_frames, "audio": audio_signal, }, } outputs = omni.generate(om_inputs, sampling_params_list)8.2 在线服务
OpenAI 兼容服务器使用相同的阶段配置与引擎边界：
vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct --omni --port 8091Qwen3-Omni 聊天请求可包含文本、图像、音频或视频内容，以及面向其各阶段配置的sampling_params_list。完整请求示例见 qwen3_omni 在线服务示例 与 examples 目录。
端点支持的模型相关性：部分流水线还暴露额外的 OpenAI 兼容端点（如联合视频/音频生成），但端点支持是模型特定的——在假设每条 OpenAI 路由适用于每个流水线之前，务必查阅对应模型指南。
九、结语
vLLM-Omni 的阶段式架构回答了全模态推理的一个根本问题：如何让自回归解码、扩散去噪、多模态编码与媒体解码这些执行循环迥异的组件，既能独立优化与资源化，又能无缝编排进同一条请求流水线。其答案是清晰的四层分离——PipelineConfig描述逻辑拓扑、阶段运行时策略承载执行差异、DeployConfig决定物理放置、AsyncOmniEngine/Orchestrator/StageRuntime/OmniConnector负责组合、编排、生命周期与传输。从 Qwen3-Omni 的三阶段流式语音，到 HunyuanImage-3.0 的 AR/DiT 拆分，再到 MiniMax-H3 与 Cosmos3 的组件级边界，这一抽象被反复验证为同一套统一模型。理解这套架构，是阅读仓库内各功能设计文档（docs/design/feature）、部署配置（vllm_omni/deploy）与模型 recipe（recipes）的共同前提。
【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
