vLLM-Omni Diffusers 后端适配器零原生改造在线服务任意 Hugging Face Diffusion Pipeline【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omnivLLM-Omni 的 diffusers 后端适配器Diffusers Backend Adapter提供了一种“黑盒”接入方式无需为模型编写任何原生 pipeline 代码即可通过DiffusionPipeline.from_pretrained()加载任意 Diffusers pipeline 并接入 vLLM-Omni 的在线服务框架。本文基于 examples/online_serving/diffusers_pipeline_adapter/README.md 展开系统讲解该适配器的能力边界、模型支持范围、启动参数、量化配置、注意力后端选择机制以及 Wan 系列模型的特殊配置帮助读者用最少的代码把 text-to-image、image-to-image、text-to-video、image-to-video、text-to-audio 等 Diffusers 模型一键部署为 OpenAI 兼容的在线服务。设计定位黑盒适配器适配器核心实现在 pipeline_diffusers_adapter.py类名为DiffusersAdapterPipeline。从源码注释可以看出其设计哲学整个 pipeline 的加载委托给DiffusionPipeline.from_pretrained()推理过程完全委托给 diffusers 的pipeline.__call__()diffusers 在内部完成完整的去噪循环denoising loop输入请求通过_build_call_kwargs()翻译成 diffusers 的__call__关键字参数输出通过_wrap_output()统一包装为DiffusionOutput支持images、frames、audios三种输出形态对应图片、视频与音频 pipeline。因此diffusers 后端与 vLLM-Omni 原生 pipeline 的定位差异非常明确前者追求“零 per-model 代码即可上线”后者追求对采样循环的精细控制与高性能优化。功能限制哪些能力暂不支持由于黑盒适配器把执行权完全交给 diffusers以下 vLLM-Omni 原生能力目前不支持源码在DiffusersAdapterPipeline._raise_unsupported_features()中会直接抛出NotImplementedError不支持特性原因源码依据CFG 并行执行cfg_parallel_size 1diffusers 通过guidance_scale在内部处理 CFG序列并行sequence_parallel_size 1需要对模型做注意力层定制切分attention surgery张量并行tensor_parallel_size 1需要模型级 layer shardingTeaCache / Cache-DiT 加速需要挂钩到 transformer 块的内部Step-wise 执行连续批处理diffusers 将完整去噪循环封装在内部prepare_encode/denoise_step/step_scheduler/post_decode均被显式拒绝组件级diffusion_offload_configdiffusers 只提供 pipeline 级的 CPU offload 钩子对于这些特性文档与源码都明确建议改用 vLLM-Omni 原生支持的 pipeline。作为替代适配器保留了旧版的整管线 CPU offload 选项--enable-cpu-offload对应pipeline.enable_model_cpu_offload()与--enable-layerwise-offload对应pipeline.enable_sequential_cpu_offload()详见load_weights()中的处理逻辑。模型支持范围原则上任何可以通过DiffusionPipeline.from_pretrained()加载的模型都可以运行覆盖 text-to-image、image-to-image、text-to-video、image-to-video、text-to-audio 等任务类型。为尽力保证 diffusers 后端与原生 diffusers 库输出的一致性以下模型经过了重点验证Qwen/Qwen-ImageTongyi-MAI/Z-Image-TurboWan2.2-I2V-A14B-Diffusers如果发现上述列表之外的其他模型输出与直接运行 diffusers 存在差异官方建议提交 issue 或 PR 帮助修复。快速上手启动 diffusers 后端只需要一个核心参数--diffusion-load-format diffusersCLI 定义见 serve.py可选值还包括default、custom_pipeline、dummy。以 Stable Diffusion v1.5 为例vllm serve stable-diffusion-v1-5/stable-diffusion-v1-5 \ --omni \ --diffusion-load-format diffusers服务启动后直接按照常规方式发送请求即可。text-to-image 的在线请求可参考 examples/online_serving/text_to_image/openai_chat_client.py它演示了如何通过 OpenAI 兼容接口提交prompt、size、num_inference_steps、seed、negative_prompt等字段并取回b64_json结果其他输入/输出模态的请求方式可查阅 docs/serving 目录下的image_generation_api.md、videos_api.md、audio_generate_api.md等接口文档。除了--diffusion-load-format diffusers之外还有两个可选参数--diffusers-load-kwargs与--diffusers-call-kwargs二者仅在搭配--diffusion-load-format diffusers时生效。配置参考--diffusers-load-kwargs加载期配置该参数以 JSON 对象形式原样传给DiffusionPipeline.from_pretrained()适用于 vLLM-Omni 接口中没有暴露的模型特有配置。例如vllm serve stable-diffusion-v1-5/stable-diffusion-v1-5 \ --omni \ --diffusion-load-format diffusers \ --diffusers-load-kwargs {use_safetensors: true}参数优先级规则源码见load_weights()中load_kwargs {torch_dtype: dtype, **self.od_config.diffusers_load_kwargs}的合并顺序vLLM-Omni 接口能表达的参数会被自动适配进来如torch_dtype由--dtype映射若同一参数在 vLLM-Omni 接口与diffusers_load_kwargs中同时出现后者diffusers_load_kwargs优先。CLI 定义在 serve.py 中帮助文本给出的示例还包括{use_safetensors: true, variant: fp16}这类组合用法。--diffusers-call-kwargs调用期配置该参数同样以 JSON 对象传入但会被转发给pipeline.__call__()适用于 vLLM-Omni 在线请求负载中不存在的采样参数。例如negative_prompt的全局兜底值、diffusers 特有的采样字段等。参数优先级规则与load_kwargs相反若同一参数在 vLLM-Omni 接口与diffusers_call_kwargs中同时出现前者请求期设置的采样参数优先。这一点在 pipeline_diffusers_adapter.py 的_build_call_kwargs()中有清晰的实现层次先写入diffusers_call_kwargs的加载期默认值再覆盖 prompt 输入字段最后用请求期的 sampling params 覆盖。此外_build_call_kwargs()还会对传入的 kwargs 做白名单校验通过inspect.signature(self._pipeline.__call__).parameters检查参数是否被该 pipeline 接受不支持的参数会打印 warning 并跳过而不是直接报错。注意vLLM-Omni 中部分采样参数的默认值与 diffusers 可能不同。核对默认值时建议同时参考 vllm_omni/inputs/data.py 中的OmniDiffusionSamplingParams定义如num_inference_steps、guidance_scale、strength、eta、true_cfg_scale等字段均以None表示“未显式设置”由各 pipeline 决定模型级默认与对应 diffusers pipeline 的__call__文档。量化配置diffusers 后端的量化有两条路径路径一Diffusers 原生量化推荐通过diffusers_load_kwargs[quantization_config]传入字典适配器会将其构建为 diffusers 的量化配置对象源码见 quantization_utils.py 的convert_diffusers_quantization_config()dict 形式会被转换成PipelineQuantizationConfig其中quant_mapping里每个组件条目按quant_method映射到 diffusers/transformers 的量化配置类并在调用from_pretrained()之前交由 diffusers 自身校验。路径二vLLM-Omni 量化兼容快捷映射当diffusers_load_kwargs中没有显式quantization_config时适配器会尝试把 vLLM-Omni 的量化配置做一次“礼貌转换”courtesy conversion见apply_diffusers_quantization_config()。目前仅支持online/dynamicfp8→ Diffusers/TorchAO 的Float8DynamicActivationFloat8WeightConfig动态量化online/dynamicint8→ Diffusers/TorchAO 的Int8DynamicActivationInt8WeightConfig动态量化映射目标组件固定为transformer/transformer_2。该路径依赖torchao未安装时会抛出带明确提示的ImportError。通过 vLLM-Omni 接口直接请求动态 FP8 的示例vllm serve Qwen/Qwen-Image \ --omni \ --diffusion-load-format diffusers \ --quantization-config {method: fp8}转换前会对配置做严格校验_validate_fp8_quant_config/_validate_int8_quant_config序列化 checkpointis_checkpoint_fp8_serialized等、非 dynamic 的 activation scheme、weight_block_size、ignored_layers/modules_to_not_convert等都会抛出NotImplementedError。明确不支持的量化方法包括gguf、modelopt、mxfp4、mxfp8、序列化 checkpoint、静态 FP8 配置以及ignored_layers等层名跳过列表。这些场景应通过diffusers_load_kwargs使用 Diffusers 原生配置或改用 vLLM-Omni 原生 pipeline。注意力后端选择diffusers 后端会把 vLLM-Omni 标准的注意力后端设置参见 docs/user_guide/diffusion/attention_backends.md转换成 diffusers 标准。完整映射逻辑位于_set_attention_backend()FLASH_ATTN/FLASH_ATTN_3_HUB/FLASH_ATTN_HUB/SAGE_ATTN/ASCEND等 vLLM-Omni 后端会被翻译为对应的 diffusers 后端名称链逐个尝试transformer.set_attention_backend(backend)直到成功对FLASH_ATTN而言优先尝试 FlashAttention-3含 HuggingFacekernels库的_flash_3_hub/_flash_3_varlen_hub变体再回退 FlashAttention-2flash_hub/flash_varlen_hub/flash/flash_varlen等对SAGE_ATTN同样先尝试 HuggingFacekernels库sage_hub再尝试本地实现sage/sage_varlen平台差异也有处理ROCm 使用aiterXPU 使用_native_xlaNPU 使用_native_npuBlackwellsm_10x/11x/12xGPU 上会自动退避到native因为常规 FA2/FA3 轮子通常是 Hopper 专用CUDNN_ATTN、FLASHINFER_ATTN、TRTLLM_ATTN在 diffusers 适配器中没有对应绑定会直接报错所有尝试失败且用户未显式指定后端时最终回退到 PyTorch 默认 SDPAnative显式指定后端失败则抛出RuntimeError。最终加载成功的注意力后端以及中间失败的尝试若有都会记录到控制台日志便于排查。模型特有设置以 Wan 系列为例diffusers 后端的加载与推理严格遵守 diffusers 库的语义可能与 vLLM-Omni 原生接口在个别模型上存在差异使用前建议核对对应 pipeline 的官方文档。以 Wan 系列视频生成模型为例boundary_ratio与flow_shift这两个参数是在模型初始化时传入的而非推理时。由于 vLLM-Omni 的OmniDiffusionConfig见 vllm_omni/diffusion/data.py恰好包含这两个字段因此可以直接通过vllm serve的命令行参数传入vllm serve Wan2.2-T2V-A14B-Diffusers \ --omni \ --boundary-ratio 0.875 \ --flow-shift 3 \ --diffusion-load-format diffusers两个参数的 CLI 定义见 serve.py--boundary-ratio视频模型中 low/high DiT 的边界切分比例如 Wan2.2 的 0.875--flow-shiftscheduler 的 flow_shift 值例如 720p 建议 5.0、480p 建议 12.0。这些额外的 CLI 参数会原样传入OmniDiffusionConfigdataclass并在模型加载期被访问。适配器内的专门例程WanPipelineUtils见 pipeline_utils.py确保它们被正确设置update_load_kwargs()把od_config.boundary_ratio写入load_kwargs[boundary_ratio]随from_pretrained()传给 Wan pipeline 构造函数apply_post_load_updates()用UniPCMultistepScheduler.from_config(..., flow_shift...)重建 scheduler把flow_shift注入加载后的 pipelinevalidate_runtime_sampling_params()在请求期显式拒绝boundary_ratio/flow_shift的运行时设置提示必须在加载期配置——这与“初始化期参数不可在推理期变更”的 diffusers 语义保持一致。类似地SanaVideoPipelineUtils等模型特定工具类通过PIPELINE_UTILS_REGISTRY注册由get_pipeline_utils_for_config()按 pipeline 类名分发形成“通用基类 模型级钩子”的扩展机制。小结diffusers 后端适配器是 vLLM-Omni 生态中“低门槛接入”的重要一环它把成百上千个 HuggingFace Diffusers 模型以近乎零代码的方式接入 OpenAI 兼容在线服务代价是放弃 CFG 并行、序列并行、缓存加速与 step-wise 连续批处理等原生级优化能力。对追求快速验证、长尾模型覆盖或与 diffusers 生态对齐的场景这是性价比最高的选择对追求极致性能与精细控制的生产级场景则应优先考虑 vLLM-Omni 原生 pipeline。核心源码入口为 pipeline_diffusers_adapter.py 与 quantization_utils.py对应测试见 tests/diffusion/diffusion_backend/test_diffusers_backend.py。【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 vLLM-Omni Diffusers 后端适配器：零原生改造在线服务任意 Hugging Face Diffusion Pipeline
vLLM-Omni Diffusers 后端适配器零原生改造在线服务任意 Hugging Face Diffusion Pipeline【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omnivLLM-Omni 的 diffusers 后端适配器Diffusers Backend Adapter提供了一种“黑盒”接入方式无需为模型编写任何原生 pipeline 代码即可通过DiffusionPipeline.from_pretrained()加载任意 Diffusers pipeline 并接入 vLLM-Omni 的在线服务框架。本文基于 examples/online_serving/diffusers_pipeline_adapter/README.md 展开系统讲解该适配器的能力边界、模型支持范围、启动参数、量化配置、注意力后端选择机制以及 Wan 系列模型的特殊配置帮助读者用最少的代码把 text-to-image、image-to-image、text-to-video、image-to-video、text-to-audio 等 Diffusers 模型一键部署为 OpenAI 兼容的在线服务。设计定位黑盒适配器适配器核心实现在 pipeline_diffusers_adapter.py类名为DiffusersAdapterPipeline。从源码注释可以看出其设计哲学整个 pipeline 的加载委托给DiffusionPipeline.from_pretrained()推理过程完全委托给 diffusers 的pipeline.__call__()diffusers 在内部完成完整的去噪循环denoising loop输入请求通过_build_call_kwargs()翻译成 diffusers 的__call__关键字参数输出通过_wrap_output()统一包装为DiffusionOutput支持images、frames、audios三种输出形态对应图片、视频与音频 pipeline。因此diffusers 后端与 vLLM-Omni 原生 pipeline 的定位差异非常明确前者追求“零 per-model 代码即可上线”后者追求对采样循环的精细控制与高性能优化。功能限制哪些能力暂不支持由于黑盒适配器把执行权完全交给 diffusers以下 vLLM-Omni 原生能力目前不支持源码在DiffusersAdapterPipeline._raise_unsupported_features()中会直接抛出NotImplementedError不支持特性原因源码依据CFG 并行执行cfg_parallel_size 1diffusers 通过guidance_scale在内部处理 CFG序列并行sequence_parallel_size 1需要对模型做注意力层定制切分attention surgery张量并行tensor_parallel_size 1需要模型级 layer shardingTeaCache / Cache-DiT 加速需要挂钩到 transformer 块的内部Step-wise 执行连续批处理diffusers 将完整去噪循环封装在内部prepare_encode/denoise_step/step_scheduler/post_decode均被显式拒绝组件级diffusion_offload_configdiffusers 只提供 pipeline 级的 CPU offload 钩子对于这些特性文档与源码都明确建议改用 vLLM-Omni 原生支持的 pipeline。作为替代适配器保留了旧版的整管线 CPU offload 选项--enable-cpu-offload对应pipeline.enable_model_cpu_offload()与--enable-layerwise-offload对应pipeline.enable_sequential_cpu_offload()详见load_weights()中的处理逻辑。模型支持范围原则上任何可以通过DiffusionPipeline.from_pretrained()加载的模型都可以运行覆盖 text-to-image、image-to-image、text-to-video、image-to-video、text-to-audio 等任务类型。为尽力保证 diffusers 后端与原生 diffusers 库输出的一致性以下模型经过了重点验证Qwen/Qwen-ImageTongyi-MAI/Z-Image-TurboWan2.2-I2V-A14B-Diffusers如果发现上述列表之外的其他模型输出与直接运行 diffusers 存在差异官方建议提交 issue 或 PR 帮助修复。快速上手启动 diffusers 后端只需要一个核心参数--diffusion-load-format diffusersCLI 定义见 serve.py可选值还包括default、custom_pipeline、dummy。以 Stable Diffusion v1.5 为例vllm serve stable-diffusion-v1-5/stable-diffusion-v1-5 \ --omni \ --diffusion-load-format diffusers服务启动后直接按照常规方式发送请求即可。text-to-image 的在线请求可参考 examples/online_serving/text_to_image/openai_chat_client.py它演示了如何通过 OpenAI 兼容接口提交prompt、size、num_inference_steps、seed、negative_prompt等字段并取回b64_json结果其他输入/输出模态的请求方式可查阅 docs/serving 目录下的image_generation_api.md、videos_api.md、audio_generate_api.md等接口文档。除了--diffusion-load-format diffusers之外还有两个可选参数--diffusers-load-kwargs与--diffusers-call-kwargs二者仅在搭配--diffusion-load-format diffusers时生效。配置参考--diffusers-load-kwargs加载期配置该参数以 JSON 对象形式原样传给DiffusionPipeline.from_pretrained()适用于 vLLM-Omni 接口中没有暴露的模型特有配置。例如vllm serve stable-diffusion-v1-5/stable-diffusion-v1-5 \ --omni \ --diffusion-load-format diffusers \ --diffusers-load-kwargs {use_safetensors: true}参数优先级规则源码见load_weights()中load_kwargs {torch_dtype: dtype, **self.od_config.diffusers_load_kwargs}的合并顺序vLLM-Omni 接口能表达的参数会被自动适配进来如torch_dtype由--dtype映射若同一参数在 vLLM-Omni 接口与diffusers_load_kwargs中同时出现后者diffusers_load_kwargs优先。CLI 定义在 serve.py 中帮助文本给出的示例还包括{use_safetensors: true, variant: fp16}这类组合用法。--diffusers-call-kwargs调用期配置该参数同样以 JSON 对象传入但会被转发给pipeline.__call__()适用于 vLLM-Omni 在线请求负载中不存在的采样参数。例如negative_prompt的全局兜底值、diffusers 特有的采样字段等。参数优先级规则与load_kwargs相反若同一参数在 vLLM-Omni 接口与diffusers_call_kwargs中同时出现前者请求期设置的采样参数优先。这一点在 pipeline_diffusers_adapter.py 的_build_call_kwargs()中有清晰的实现层次先写入diffusers_call_kwargs的加载期默认值再覆盖 prompt 输入字段最后用请求期的 sampling params 覆盖。此外_build_call_kwargs()还会对传入的 kwargs 做白名单校验通过inspect.signature(self._pipeline.__call__).parameters检查参数是否被该 pipeline 接受不支持的参数会打印 warning 并跳过而不是直接报错。注意vLLM-Omni 中部分采样参数的默认值与 diffusers 可能不同。核对默认值时建议同时参考 vllm_omni/inputs/data.py 中的OmniDiffusionSamplingParams定义如num_inference_steps、guidance_scale、strength、eta、true_cfg_scale等字段均以None表示“未显式设置”由各 pipeline 决定模型级默认与对应 diffusers pipeline 的__call__文档。量化配置diffusers 后端的量化有两条路径路径一Diffusers 原生量化推荐通过diffusers_load_kwargs[quantization_config]传入字典适配器会将其构建为 diffusers 的量化配置对象源码见 quantization_utils.py 的convert_diffusers_quantization_config()dict 形式会被转换成PipelineQuantizationConfig其中quant_mapping里每个组件条目按quant_method映射到 diffusers/transformers 的量化配置类并在调用from_pretrained()之前交由 diffusers 自身校验。路径二vLLM-Omni 量化兼容快捷映射当diffusers_load_kwargs中没有显式quantization_config时适配器会尝试把 vLLM-Omni 的量化配置做一次“礼貌转换”courtesy conversion见apply_diffusers_quantization_config()。目前仅支持online/dynamicfp8→ Diffusers/TorchAO 的Float8DynamicActivationFloat8WeightConfig动态量化online/dynamicint8→ Diffusers/TorchAO 的Int8DynamicActivationInt8WeightConfig动态量化映射目标组件固定为transformer/transformer_2。该路径依赖torchao未安装时会抛出带明确提示的ImportError。通过 vLLM-Omni 接口直接请求动态 FP8 的示例vllm serve Qwen/Qwen-Image \ --omni \ --diffusion-load-format diffusers \ --quantization-config {method: fp8}转换前会对配置做严格校验_validate_fp8_quant_config/_validate_int8_quant_config序列化 checkpointis_checkpoint_fp8_serialized等、非 dynamic 的 activation scheme、weight_block_size、ignored_layers/modules_to_not_convert等都会抛出NotImplementedError。明确不支持的量化方法包括gguf、modelopt、mxfp4、mxfp8、序列化 checkpoint、静态 FP8 配置以及ignored_layers等层名跳过列表。这些场景应通过diffusers_load_kwargs使用 Diffusers 原生配置或改用 vLLM-Omni 原生 pipeline。注意力后端选择diffusers 后端会把 vLLM-Omni 标准的注意力后端设置参见 docs/user_guide/diffusion/attention_backends.md转换成 diffusers 标准。完整映射逻辑位于_set_attention_backend()FLASH_ATTN/FLASH_ATTN_3_HUB/FLASH_ATTN_HUB/SAGE_ATTN/ASCEND等 vLLM-Omni 后端会被翻译为对应的 diffusers 后端名称链逐个尝试transformer.set_attention_backend(backend)直到成功对FLASH_ATTN而言优先尝试 FlashAttention-3含 HuggingFacekernels库的_flash_3_hub/_flash_3_varlen_hub变体再回退 FlashAttention-2flash_hub/flash_varlen_hub/flash/flash_varlen等对SAGE_ATTN同样先尝试 HuggingFacekernels库sage_hub再尝试本地实现sage/sage_varlen平台差异也有处理ROCm 使用aiterXPU 使用_native_xlaNPU 使用_native_npuBlackwellsm_10x/11x/12xGPU 上会自动退避到native因为常规 FA2/FA3 轮子通常是 Hopper 专用CUDNN_ATTN、FLASHINFER_ATTN、TRTLLM_ATTN在 diffusers 适配器中没有对应绑定会直接报错所有尝试失败且用户未显式指定后端时最终回退到 PyTorch 默认 SDPAnative显式指定后端失败则抛出RuntimeError。最终加载成功的注意力后端以及中间失败的尝试若有都会记录到控制台日志便于排查。模型特有设置以 Wan 系列为例diffusers 后端的加载与推理严格遵守 diffusers 库的语义可能与 vLLM-Omni 原生接口在个别模型上存在差异使用前建议核对对应 pipeline 的官方文档。以 Wan 系列视频生成模型为例boundary_ratio与flow_shift这两个参数是在模型初始化时传入的而非推理时。由于 vLLM-Omni 的OmniDiffusionConfig见 vllm_omni/diffusion/data.py恰好包含这两个字段因此可以直接通过vllm serve的命令行参数传入vllm serve Wan2.2-T2V-A14B-Diffusers \ --omni \ --boundary-ratio 0.875 \ --flow-shift 3 \ --diffusion-load-format diffusers两个参数的 CLI 定义见 serve.py--boundary-ratio视频模型中 low/high DiT 的边界切分比例如 Wan2.2 的 0.875--flow-shiftscheduler 的 flow_shift 值例如 720p 建议 5.0、480p 建议 12.0。这些额外的 CLI 参数会原样传入OmniDiffusionConfigdataclass并在模型加载期被访问。适配器内的专门例程WanPipelineUtils见 pipeline_utils.py确保它们被正确设置update_load_kwargs()把od_config.boundary_ratio写入load_kwargs[boundary_ratio]随from_pretrained()传给 Wan pipeline 构造函数apply_post_load_updates()用UniPCMultistepScheduler.from_config(..., flow_shift...)重建 scheduler把flow_shift注入加载后的 pipelinevalidate_runtime_sampling_params()在请求期显式拒绝boundary_ratio/flow_shift的运行时设置提示必须在加载期配置——这与“初始化期参数不可在推理期变更”的 diffusers 语义保持一致。类似地SanaVideoPipelineUtils等模型特定工具类通过PIPELINE_UTILS_REGISTRY注册由get_pipeline_utils_for_config()按 pipeline 类名分发形成“通用基类 模型级钩子”的扩展机制。小结diffusers 后端适配器是 vLLM-Omni 生态中“低门槛接入”的重要一环它把成百上千个 HuggingFace Diffusers 模型以近乎零代码的方式接入 OpenAI 兼容在线服务代价是放弃 CFG 并行、序列并行、缓存加速与 step-wise 连续批处理等原生级优化能力。对追求快速验证、长尾模型覆盖或与 diffusers 生态对齐的场景这是性价比最高的选择对追求极致性能与精细控制的生产级场景则应优先考虑 vLLM-Omni 原生 pipeline。核心源码入口为 pipeline_diffusers_adapter.py 与 quantization_utils.py对应测试见 tests/diffusion/diffusion_backend/test_diffusers_backend.py。【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考