vLLM-Omni 架构全景：面向全模态模型的分阶段推理与服务体系

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-OmniThinker → Talker → Code2Wav三个阶段异步分块交接TTFT/TTFP、TPOT、E2EL、音频 RTF、并发吞吐HunyuanImage-3.0多模态 AR 理解/推理 图像生成 DiT仅 AR、仅 DiT 或拆分 AR → DiT 部署DiT E2EL/去噪延迟与图像吞吐AR 任务的 TTFT/TPOTMiniMax-H3文本编码器 → 任务特定 FL2VA 或 Ref2VA DiT → 视频/音频 VAE 解码器单个注册扩散阶段内的三个逻辑组件/阶段边界视频/音频 E2EL 与媒体吞吐音频流独立评测时关注 RTFCosmos3统一 MoT 推理器塔 扩散生成器塔一个扩散流水线在阶段内物化两个塔图像/视频/音频/动作 E2EL 与吞吐同步音频的 RTF3.1 Qwen3-Omni流式 AR 流水线Thinker → Talker → Code2WavQwen3-Omni 展示了一条多阶段流式 AR 流水线Thinker → Talker → Code2Wav。按阶段的模型架构阶段模型组件阶段输出ThinkerAuT 音频编码器、SigLIP2 视觉编码器、30B 总参/3B 激活的 Thinker MoE Transformer文本 token 与 Talker 的 conditioningTalker3B 总参/0.3B 激活的 Talker MoE Transformer带 MTP 码本预测路径文本 token 与音频 codec tokenCode2Wav约 200M 参数的 ConvNet 音频解码器波形/音频分块代表性阶段执行策略阶段Batching注意力与执行并行度量化Thinker连续 batching配合阶段本地max_num_seqs与 token 预算vLLM KV 缓存 AR 注意力非 eager 时启用 CUDA Graph独立阶段放置沿用 AR 运行时配置的张量并行文档化路径中 ModelOpt FP8/NVFP4 或 AutoRound 检查点只针对 Thinker编码器保持 BF16Talker对自回归解码请求做连续 batchingKV 缓存 token 解码异步分块输出到 Code2Wav独立阶段放置通常与 Thinker 分处不同 GPU 或副本BF16 基线不假设通用 Talker 量化路径Code2Wavcodec 到波形解码的静态/分块 batching非 AR 分块音频解码通常保留 eager 执行独立阶段或同址放置BF16 基线codec/vocoder 精度按模型保留该流水线的主要服务目标是交互响应性文本看 TTFT、首音频包看 TTFP、自回归解码看 TPOT、完整回答看 E2EL、持续音频服务看 RTF 与吞吐。异步分块与流式主要降低 TTFP 并提升阶段重叠batching 与 CUDA Graph 主要改善 E2EL 与吞吐。源码层面阶段拓扑由StagePipelineConfigvllm_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:0Thinker与cuda:1Talker 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 连续 batchingKV 缓存因果注意力张量/专家并行跟随所选 AR 部署检查点特定不要将 DiT 的 FP8 设置套用到 AR 检查点DiT VAE请求 batching 或 step-wise batching多请求的 Hunyuan step batching 需要TORCH_SDPA因模型混合因果与全注意力而使用TORCH_SDPA已验证配置含 TP4、TP2序列并行、TP2CFG 并行、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 EncoderTokenizer/processor 与 Qwen3-VL 文本编码器视觉/音频引用与文本条件一并准备打包的多模态 conditioningDiT文本/首帧生成的FL2VADiT或混合引用的Ref2VADiT视频与音频 latent tokenVAE 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每个生成请求后跟随解码即使去噪未 batchingtile/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-TransformersMoT推理器与扩散生成器的组合。按阶段/组件的模型架构阶段或组件模型组件阶段输出Reasoner 塔带因果注意力的自回归 VLM 路径覆盖语言与可选视觉/动作上下文每个生成请求运行一次离散推理/上下文 tokenGenerator 塔对生成器 token 与 reasoner K/V 上下文做全注意力的扩散路径每个去噪步运行图像、视频、音频或动作 token共享流水线Cosmos3OmniDiffusersPipeline加模态编码器/解码器与 VAE 路径最终图像/视频/音频或动作响应reasoner 与 generator 是模型自有组件默认不是两个独立的 vLLM-Omni 阶段当前 Cosmos3 流水线在单个扩散阶段内物化两者模型级 CPU offload 可在各自阶段间交换 reasoner 与 generator 组件。代表性执行策略阶段Batching注意力与执行并行度量化Reasoner generator 流水线仅当所选流水线声明支持请求 batching 或 step 执行时使用否则用max_num_seqs1reasoner token 用因果注意力、扩散 token 用全注意力已验证 recipe 使用平台选择的 aiter FlashAttention 路径并回退TORCH_SDPAtransformer 用 Ulysses/上下文并行或张量并行VAE tiling 与逐层/模型级 offload 应对激活与权重内存扩散流水线支持在线 FP8AutoRound/检查点特定路径与质量验证独立于 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通过公共输出路径携带流水线与扩散结果源码佐证AsyncOmniEnginevllm_omni/engine/async_omni_engine.py是一个瘦代理在后台线程中启动Orchestrator通过 janus 队列与调用方通信Orchestratorvllm_omni/engine/orchestrator.py运行在专用 asyncio 事件循环中持有OrchestratorRequestState与StagePool列表StageRuntimevllm_omni/engine/stage_runtime.py直接启动阶段进程并创建静态客户端的StagePoolOmniConnectorBasevllm_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随后返回OmniConfigResolutionvllm_omni/config/resolver.py供AsyncOmniEngine与无头headless启动共同消费。在StageRuntime直接消费类型化阶段配置之前该信封携带有效的PipelineConfig与 OmegaConf 兼容的stage_configs作为临时运行时桥接层——两个视图描述同一份已解析拓扑含注入阶段。需要注意遗留的stage_argsYAML 路径已移除模型拓扑现在通过PipelineConfig解析运行时覆盖由DeployConfig提供类型化路径中每个阶段配置派生自BaseVllmOmniStageConfig并特化为VllmOmniARStageConfig、VllmOmniGenerationStageConfig或VllmOmniDiffusionStageConfig。6.1 源码级验证配置所有权规则从 stage_config.py 源码可确认以下字段级事实PipelineConfigL281-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_outputTrue——没有终结阶段的流水线将导致请求永久挂起见Orchestrator._route_output的依赖。StagePipelineConfigL229-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、diffusionL194-L199_resolve_schedulerL202-L219据此为 AR 阶段选择同步OmniARScheduler或异步OmniARAsyncScheduler为生成阶段选择OmniGenerationScheduler扩散阶段则走扩散调度路径。DeployConfigL543-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 放置等则放入StageDeployConfigL371-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_overridesL47-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:0stage 12 于cuda:1顶层async_chunk: true开启异步分块交接connectors段定义SharedMemoryConnector并携带 codec 分块参数initial_codec_chunk_frames: 4、codec_chunk_frames: 25、codec_left_context_frames: 25stage 0Thinkermax_num_batched_tokens: 32768、max_num_seqs: 64、gpu_memory_utilization: 0.9、moe_backend: triton、devices: 0、default_sampling_params.temperature: 0.0stage 1Talkergpu_memory_utilization: 0.6、devices: 1、input_connectors.from_stage_0指向共享内存连接器、采样参数temperature: 0.9、top_k: 50、repetition_penalty: 1.05stage 2Code2Wavmax_num_batched_tokens: 65536、gpu_memory_utilization: 0.1、async_scheduling: false、input_connectors.from_stage_1、max_tokens: 65536platforms段按平台覆写CUDA 上为 Thinker 保留 MRoPE 的 CUDA 路径custom_ops: [rotary_embedding]ROCm 上 stage 2 因 MIOpenconv_transpose1d不可图捕获而enforce_eager: trueNPU 上使用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 batchingdiffusion_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(modelQwen/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与模型 reciperecipes的共同前提。【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考