深入 Diffusers 测试规范为新模型与 Pipeline 编写两层高质量测试【免费下载链接】diffusers Diffusers: State-of-the-art diffusion models for image, video, and audio generation in PyTorch.项目地址: https://gitcode.com/GitHub_Trending/di/diffusers本篇指南系统梳理 diffusers 仓库的官方测试规范源文档位于 .ai/references/testing.md围绕一个新 PR 必须交付什么测试、现有测试文件应该对照什么标准审查展开。文章将讲解 pipeline 级与模型级两层测试的组织方式、config 类 可组合 pytest mixin的新测试风格、LoRA 与模块化modularpipeline 的专属测试套路以及 dummy 组件、group offloading、xfail 等关键约定并结合 tests/pipelines/testing_utils/common.py、tests/pipelines/wan/test_wan.py、tests/pipelines/flux/test_pipeline_flux.py 等仓库源码给出可直接对照的实现依据。读完你既能按规范为 diffusers 写测试也能读懂并审查现有测试文件的每一处细节。总览两个测试层一个 PR 的交付边界任何新引入的 pipeline 都必须同时补齐两个测试层Pipeline 级测试pipeline-level tests—— 每个新 pipeline 都必需模型级测试model-level tests—— 仅当该 pipeline 引入了新的模型类transformer、VAE 等时才必需。而集成/慢测试integration/slow tests与 LoRA 测试不在初始 PR 中加入它们要等与维护者讨论之后、在后续迭代中补充。这一交付边界在文档中写得很明确也决定了下面所有小节的组织方式。通用规则适用于所有测试层无论 pipeline 级还是模型级测试以下规则一律生效。保持组件尺寸极小让测试套件快速运行使用小的num_layers、小的 hidden/attention 维度、低分辨率、少量帧数尺寸量级可参考 tests/pipelines/wan/test_wan.py 中的get_dummy_components与get_dummy_inputs例如 Wan 的 transformer 使用num_attention_heads2、attention_head_dim12、num_layers2VAE 使用base_dim3、num_res_blocks1输入分辨率仅16×16、num_frames9。用真实类构建 dummy 组件而不是手写 mockget_dummy_components必须用真实类在极小配置下构建一个极小维度的真实 VAE、一个来自hf-internal-testing/tiny-random-*仓库的真实 tokenizer。不要在没有充分理由的情况下用手写 mock 替代——例如一个裸nn.Module配SimpleNamespace配置、或一个假 tokenizer。原因很关键mock 是按pipeline 今天从组件上读什么复制出来的因此它只能证明 pipeline 与它自己想象出来的组件一致——当组件重命名了某个配置字段、或 pipeline 开始读取组件并不拥有的字段时测试仍然保持绿色而恰好捕捉 pipeline↔组件之间的这份契约正是 pipeline 测试存在的意义。合理的 stub 场景是组件难以实例化、且对 pipeline 而言只有其 I/O 有意义例如用DummyCosmosSafetyChecker替代庞大的 Cosmos 安全护栏。这种情况下也要把它做成共享的、专门构建的类且必须遵循真实接口。调用层面同样不要打 monkeypatch不要为了捕获被测代码传给某方法如 scheduler 的set_timesteps的参数而去 monkeypatch 组件方法——那同样只是验证调用方与它自己的一致性而非与真实方法契约的一致性。正确做法是调用真实组件并对它产生的状态做断言。初始 PR 的红线不加 LoRA 测试不要把 LoRA 测试 mixin 组合进 pipeline 或模型测试文件详见下文 LoRA 测试 小节也不要添加tests/lora/test_lora_layers_model.py不加集成/慢测试不要添加任何以slow/RUN_SLOW1门控的内容。Pipeline 级测试标准 pipeline文件位置与 pytest 风格测试文件位置tests/pipelines/model/test_pipeline_model.py每个 pipeline 变体如 T2V、I2V一个文件这些测试是 pytest 风格而不是unittest不继承unittest.TestCase没有setUp/tearDownVRAM 的回收由cleanupfixture 负责跳过用pytest.skip/pytest.mark.skip绝不用unittest.skiptmp_path、缓存的base_pipe_output等 fixture 以参数形式注入测试方法。这种风格源自一次重大重构文档提到的 PR #14113把共享基础设施搬进tests/pipelines/testing_utils/包并把旧的单体unittest.TestCase拆成一个配置类 可组合的 pytest mixin。核心参考实现是 tests/pipelines/flux/test_pipeline_flux.py。定义一个配置类PipelinePipelineTesterConfig每个 pipeline 测试文件定义一个且仅一个配置类继承BasePipelineTesterConfig定义于 tests/pipelines/testing_utils/common.py。配置类持有整个测试契约但不做任何断言。它负责pipeline_class被测 pipeline 类required_input_params_in_call_signature必须出现在__call__签名中的参数。能匹配就使用 tests/pipelines/pipeline_params.py 中的规范集合否则内联一个frozenset([...])batch_input_params会被批量化的参数同样优先取规范集合如TEXT_TO_IMAGE_BATCH_PARAMSoutput_shapeget_dummy_inputs()单样本输出的形状——图像 pipeline 为(channels, height, width)视频 pipeline 为(num_frames, channels, height, width)。在 pipeline 专属测试中用self.output_shape断言而不是重复字面量get_dummy_components(...)用真实类在极小配置下构建每个子模块每个模块构建前都执行torch.manual_seed(0)以保证确定性get_dummy_inputs()不接受device/seed参数与旧风格不同用self.get_generator(0)生成器保持尺寸极小并设置output_typept让测试直接用assert_tensors_close比较 torch 张量免去 numpy 往返。注意pt图像布局是(batch, channels, height, width)而np是(batch, height, width, channels)。以 Wan 为例tests/pipelines/wan/test_wan.pyclass WanPipelineTesterConfig(BasePipelineTesterConfig): pipeline_class WanPipeline required_input_params_in_call_signature frozenset( [prompt, negative_prompt, height, width, guidance_scale, prompt_embeds, negative_prompt_embeds] ) batch_input_params frozenset([prompt]) output_shape (9, 3, 16, 16) # Wan 是视频 pipeline暴露的是 num_videos_per_prompt而非基类的 num_images_per_prompt optional_input_params frozenset( [num_inference_steps, num_videos_per_prompt, generator, latents, output_type, return_dict] ) def get_dummy_components(self): torch.manual_seed(0) vae AutoencoderKLWan(base_dim3, z_dim16, dim_mult[1, 1, 1, 1], num_res_blocks1, temperal_downsample[False, True, True]) torch.manual_seed(0) scheduler FlowMatchEulerDiscreteScheduler(shift7.0) config AutoConfig.from_pretrained(hf-internal-testing/tiny-random-t5) # eval()直接构造的模型默认处于训练模式T5 的 dropout 会让输出不确定 text_encoder T5EncoderModel(config).eval() tokenizer AutoTokenizer.from_pretrained(hf-internal-testing/tiny-random-t5) torch.manual_seed(0) transformer WanTransformer3DModel( patch_size(1, 2, 2), num_attention_heads2, attention_head_dim12, in_channels16, out_channels16, text_dim32, freq_dim256, ffn_dim32, num_layers2, cross_attn_normTrue, qk_normrms_norm_across_heads, rope_max_seq_len32, ) return {transformer: transformer, vae: vae, scheduler: scheduler, text_encoder: text_encoder, tokenizer: tokenizer, transformer_2: None} def get_dummy_inputs(self): return { prompt: dance monkey, generator: self.get_generator(0), num_inference_steps: 2, guidance_scale: 6.0, height: 16, width: 16, num_frames: 9, max_sequence_length: 16, output_type: pt, # 直接以 torch 张量比较 }一个关注点一个 mixin一个 mixin 一个测试类将配置类与 mixin 组合每个关注点一个测试类命名为TestPipeline...只组合确实适用的 mixinPipelineTesterMixin—— 核心的保存/加载、dict 与 tuple 输出等价、批处理、dtype/device、回调测试pipeline 专属测试作为方法写在这个类上MemoryTesterMixin—— CPU offload、group offload、layerwise castingCache mixins——PyramidAttentionBroadcastTesterMixin、FasterCacheTesterMixin、FirstBlockCacheTesterMixin、TaylorSeerCacheTesterMixin、MagCacheTesterMixin。Guidance-distilled 模型要覆写缓存配置例如FASTER_CACHE_CONFIG {... is_guidance_distilled: True}。缓存相关测试不要在第一轮引入按个案补充首轮只加PipelineTesterMixin和MemoryTesterMixin相关的测试。PipelineTesterMixin的具体测试方法都定义在 tests/pipelines/testing_utils/common.py 中例如test_save_load_local本地保存/加载前后输出以assert_tensors_close比较、expected_max_difference5e-4、test_pipeline_call_signature检查required_input_params_in_call_signature与optional_input_params是否都出现在__call__签名中、test_inference_batch_consistent/test_inference_batch_single_identical、test_dict_tuple_outputs_equivalent、test_half_precision_inference_no_nanfp16/bf16 推理输出无 NaN、test_save_load_optional_components、test_to_device/test_to_dtype、test_serialization_with_variants等。参考 Wan 的写法测试类极为精简class TestWanPipeline(WanPipelineTesterConfig, PipelineTesterMixin): def test_inference(self): pipe self.get_pipeline() inputs self.get_dummy_inputs() video pipe(**inputs).frames generated_video video[0] assert generated_video.shape self.output_shape # 与固定的 expected_slice 用 assert_tensors_close 比较atol1e-3 class TestWanPipelineMemory(WanPipelineTesterConfig, MemoryTesterMixin): pass基类还提供了BasePipelineOutputMixin同样在 common.py 中它承载get_pipeline()构建被测 pipeline、统一 eval 模式并禁用进度条、run_pipe()在标准 dummy 输入上运行并返回第一个输出以及类作用域 fixturebase_pipe_output每个测试类只计算一次的基准输出因此各 mixin 之间共享同一套构建与基准无需重复代码。无法卸载的组件声明而不是手写 skip叶子级leaf-levelgroup offloading 只挂接受支持的叶子类型——nn.Linear、nn.Conv*、nn.Embedding见 src/diffusers/hooks/_common.py 中的_GO_LC_SUPPORTED_PYTORCH_LAYERS并且每个叶子在自己的forward上按需 onload。因此任何直接读叶子.weight而不调用该叶子的代码都会绕过叶子的 hook用卸载后的权重做计算。修复方式取决于组件归属diffusers 自家模型在ModelMixin子类上设置_supports_group_offloading FalseHunyuanDiT2DModel正是如此。两个 offload mixin 都会尊重该标志并自行跳过缺口被声明在模型上而不是埋在测试文件里第三方组件如 transformers 编码器无法标注在配置类上把它们列进group_offloading_leaf_level_exclude_modules。enable_group_offload会把被排除的组件留在加速器上其余组件包括组件级test_group_offloading_inference会漏掉的 VAE仍然被覆盖。块级block-leveloffloading 通常不受影响所以名字里带 level——两个级别都失败的组件才需要 skip。常见的实例是torch.nn.MultiheadAttention它把self.out_proj.weight直接传给torch.nn.functional.multi_head_attention_forward而不是调用self.out_proj于是挂在out_proj上的 hook 永远不会触发。SiglipVisionModel的 attention pooling 头就包了一个 MHA——参见 tests/pipelines/hunyuan_video/test_hunyuan_video_framepack.py其image_encoder正因此被排除group_offloading_leaf_level_exclude_modules [image_encoder]HunyuanDiTAttentionPool定义于 src/diffusers/models/embeddings.py展示了无 MHA 模块时的同类失败一个普通nn.Module把q_proj/k_proj/v_proj/c_proj的权重直接交给torch.nn.functional.multi_head_attention_forward导致四个投影全部保持卸载状态。HunyuanDiT2DModel因此用_supports_group_offloading False整体退出 group offloading。另外注意在加 skip 或排除项之前先确认失败仍然可以复现——仓库里已有若干过期 skip它们对应的上游原因早已消失。迁移暴露的src/缺口用 xfail 标记不要打补丁当测试迁移暴露出src/中的缺陷时用 xfail 标记该测试而不是顺手修补 pipeline。要求给标记一个模块级名称reason精确指出缺口tests/pipelines/pndm/test_pndm.py 中的PNDM_*系列是完整范例优先strictTrue一旦 pipeline 被修复标记会报告 XPASS 并被删除只有当一个标记覆盖的一组测试并非全部失败时才用strictFalse标记整个测试类能保留 mixin 自带的标记is_memory、require_accelerator逐个覆写继承的测试会丢掉它们声明时携带的装饰器此时需要一并重新声明。以 PNDM 为例PNDMPipeline没有output_typept路径、始终返回 numpy 数组因此NO_PT_OUTPUT pytest.mark.xfail( reasonPNDMPipeline has no output_typept path and always returns a numpy array., strictTrue, )UNSUPPORTED_MEMORY_OPTIMIZATIONS则覆盖三个 src/ 缺口numpy 输出、float32 噪声、缺少model_cpu_offload_seq因其中test_pipeline_level_group_offloading_sanity_checks不跑 pipeline 而通过会 XPASS故strictFalse。from_pipe测试变体 pipeline 复用共享 mixin当一个 pipeline 是既有 pipeline 的变体PAG、AnimateDiff 等时其测试类组合共享的FromPipeTesterMixin位于 tests/pipelines/testing_utils/from_pipe.py从..testing_utils导出。它通过pipeline_class.__name__推导原始 pipeline若需从该类的默认仓库之外拉取原始 pipeline可在测试类上设置original_pipeline_repo。它取代的是 unittest 时代的PipelineFromPipeTesterMixin在 tests/pipelines/test_pipelines_common.py 中。该 mixin 覆盖的典型断言包括test_from_pipe_consistent_configfrom_pipe往返后配置一致、test_from_pipe_consistent_forward_passfrom_pipe与__init__构造的 pipeline 输出一致、且不改变原始 pipeline 的注意力处理器、test_from_pipe_consistent_forward_pass_cpu_offloadCPU offload 下同样成立。硬件缺口条件跳过而不是 xfail当测试只因运行机 cuDNN 构建缺少某算子的 kernel 而失败——报错形如RuntimeError: GET was unable to find an engine to execute this computation例如 Sana 的 depthwiseConv2d在 bfloat16 下触发——应把调用包进skip_if_no_cudnn_engine()定义于 tests/testing_utils.py。它在遇到该错误时跳过、其他RuntimeError原样抛出因此测试在存在 kernel 的机器上仍然运行。PAG pipeline 的专属 mixinPAG pipeline 用PAGPipelineTesterMixin位于 tests/pipelines/pag/testing_utils.py取代PipelineTesterMixin它在base_pipeline_class与测试类上的pag_*旋钮驱动下额外增加test_pag_disable_enable与test_pag_inference。test_pag_applied_layers保留为各 pipeline 专属测试——PAG 解析到哪些层是模型相关的。encode_prompt的隔离测试test_encode_prompt_works_in_isolation会只保留名称中包含text或tokenizer的组件来重建 pipeline。当encode_prompt还需要其他组件——例如用于 chat templating 的processor——就在配置类上把它列进text_stack_component_names而不是重新实现该测试该元组默认值为(text, tokenizer)定义于 common.py。IP-Adapter 测试IP-Adapter 测试放在独立测试类中用is_ip_adapter装饰只继承配置类不继承PipelineTesterMixin。通过标准IPAdapterMixinAPI 加载适配器的 UNet pipeline组合共享的IPAdapterTesterMixin位于 tests/pipelines/testing_utils/ip_adapter.py从..testing_utils导出IP-Adapter API 不同的 pipeline如 Flux则在自家测试旁保留专属 mixin。LoRA 测试与 pipeline 测试同居一室自 PR #14268 起标准 pipeline 的 LoRA 测试紧挨着它的 pipeline 测试——用同一个PipelinePipelineTesterConfig再组合一个 LoRA mixin而不再放在tests/lora/test_lora_layers_model.py。参考TestFluxPipelineLoRA/TestFluxPipelineLoRAMemorytests/pipelines/flux/test_pipeline_flux.py。三个 mixin 及其分工Mixin 位于 tests/pipelines/testing_utils/lora.py从..testing_utils导出每个对应一个TestPipelineLoRA...测试类LoraTesterMixin—— adapter 的 attach/detach、LoRA scale 与 attention-kwargs、fuse/unfuse、多 adapterset/delete/weight、save/load 往返、adapter 元数据在 CPU 上运行LoraMemoryTesterMixin—— LoRA × 内存优化group offload、模型 CPU offload、卸载状态下删除 adapter仅限加速器UNetLoraTesterMixin—— 逐块per-blockscale 测试仅限 UNet pipeline。每个 mixin 单独一个测试类它们都被标记is_lora而标记会作用于继承它的类中的每一个测试——所以绝不能把 LoRA mixin 混进TestPipeline否则会把那些测试也标记成 LoRA 测试。运行方式CI 就是这么跑的pytest tests/pipelines/ -m lora # 只跑 LoRA 测试 pytest -m not lora # 跳过 LoRA 测试契约复用与自跳过配置类上不放任何 LoRA 专属内容。mixin 读取与其他 mixin 相同的契约——pipeline_class、get_dummy_components()、get_dummy_inputs()output_typept——并且当pipeline_class不是LoraBaseMixin子类时自行跳过见BaseLoraTesterMixin.setup_method中的pytest.skip逻辑。被适配的组件从pipeline_class._lora_loadable_modules推导。只有 denoiser 的注意力模块不叫to_q/to_k/to_v/to_out.0时才在测试类上覆写denoiser_target_modules。而未注册的文本编码器架构需要在 tests/pipelines/testing_utils/lora.py 的TEXT_ENCODER_TARGET_MODULES中登记条目按config.model_type索引例如clip_text_model对应[q_proj, k_proj, v_proj, out_proj]而不是做 per-class 覆写。写 pipeline 专属 LoRA 测试pipeline 专属 LoRA 测试是TestPipelineLoRA类上的方法基于共享 helper 编写self.get_pipeline()、self.add_adapters_to_pipeline(pipe, components[...], **lora_config_kwargs)、self.run_pipe(pipe)以及类作用域 fixturebase_pipe_output未适配 pipeline 的基准输出。run_pipe正是产生base_pipe_output的同一入口因此两者可直接比较——不要手写 forward 来对比基准输出。参见TestFluxPipelineLoRA上的test_with_alpha_in_state_dict和test_lora_expansion_works_for_{absent,extra}_keys。加载与保存必须走公开 APIpipe.load_lora_weights、pipeline_class.save_lora_weights、pipe.set_adapters、pipe.unload_lora_weights并用 tests/models/testing_utils/lora.py 的check_if_lora_correctly_set断言 adapter 已正确就位。Nightly LoRA-checkpoint 集成测试加载真实 Hub LoRA 的 nightly 集成测试放在同一文件中独立成类带nightly require_big_accelerator require_peft_backend标记——参见TestFluxLoRAIntegration。它仍不属于初始 PR。模块化Modularpipeline 测试模块化 pipeline 的测试位置在tests/modular_pipelines/model/test_modular_pipeline_model.py每个 blockset / pipeline 变体一个配置类 一组测试类。配置类PipelineModularPipelineTesterConfig继承BaseModularPipelineTesterConfig来自..testing_utils设置pipeline_class、pipeline_blocks_class、pretrained_model_name_or_path、params/batch_params并实现get_dummy_inputs(seed0)。用expected_workflow_blocks固定每个 workflow 的块名 → 类顺序。配置类只持有测试契约、不做断言。一个关注点一个测试类每个关注点一个测试类组合..testing_utils中的 tester mixin保持相互分离——pytest 会沿整个 MRO 读取类级标记把带标记的 mixinis_memory等折进同一类会污染其中所有测试ModularPipelineTesterMixin—— 调用签名、批处理一致性、float16、设备放置、输出无 NaNpipeline 专属测试写在这个类上ModularLoadingTesterMixin——save_pretrained/from_pretrained往返、modular_model_index.json内容、load_components/unload_componentsModularWorkflowTesterMixin—— 由 blocks 类的_workflow_map驱动的一切没有该 map 时自行跳过ModularMemoryTesterMixin—— 自动 CPU offload、group offload、卸载时设备内存回收ModularGuiderTesterMixin—— 仅用于带guider组件的 pipelineModularAutoOffloadTesterMixin—— 可选用于有多个可卸载模型组件的 pipeline在模拟内存压力下断言卸载决策。tiny 仓库必须镜像真实 checkpoint 的形状pretrained_model_name_or_path是带真实组件的小仓库tiny transformer、真实的 scheduler/VAE/tokenizer 配置。开发阶段使用个人仓库最终 tiny 仓库放在hf-internal-testing/下不阻塞合并由维护者在合并前后迁移。关键要求tiny 仓库必须镜像真实 checkpoint 的形状——相同的 index 文件类型、相同的 pipeline 级配置键、配置方式与真实一致的 scheduler。一个不像发布仓库的 fixture 测的是用户永远不会碰到的加载/配置路径而用户真正走的路径反而没被覆盖。如果模型有不同配置的变体base/distilled、不同 schedule就为每个变体做一个 tiny 仓库和一个测试类——参见 flux2 klein 的 base/distilled 拆分。通过跑 pipeline来测块的行为测试块的正确姿势是把它当作 pipeline 来运行init_pipeline()→load_components()→ 调用并断言输出参见 .ai/references/modular.md 中 Running a modular pipeline 一节。配置相关行为用update_components(...)翻转配置值比较两次运行的真实输出输入校验在正常的pipe(...)调用外包pytest.raises。不要直接调用block(components, state)或手工构造PipelineState也不要对声明的规格inputs/intermediate_outputs名称列表做断言——声明不是行为expected_workflow_blocks已经固定了结构。参考实现tests/modular_pipelines/flux2/test_modular_pipeline_flux2_klein.py以及 base/distilled 变体拆分的..._klein_base.py。模型级测试用生成器产出别手写仅当 pipeline 引入新模型类transformer、VAE 等时才需要模型级测试而且不要手写用生成器生成python utils/generate_model_tests.py src/diffusers/models/transformers/transformer_model.py生成脚本位于 utils/generate_model_tests.py它会根据模型基类与属性自动检测应包含的 tester源码中维护着ModelMixin → ModelTesterMixin、_cp_plan → ContextParallelTesterMixin、_supports_gradient_checkpointing → TrainingTesterMixin等映射并常驻输出ModelTesterMixin、MemoryTesterMixin、TorchCompileTesterMixin还会按需追加AttentionTesterMixin/ContextParallelTesterMixin/TrainingTesterMixin。生成后的处理要点初始不带任何--include标志运行。生成器自动检测 mixin/属性只输出常驻 testerModelTesterMixin、MemoryTesterMixin、TorchCompileTesterMixin以及适用的AttentionTesterMixin/ContextParallelTesterMixin/TrainingTesterMixin。可选 tester量化、缓存、single-file、IP adapter 等在与维护者讨论之后再补生成器把文件写到tests/models/transformers/test_models_transformer_model.py或对应的unets/、autoencoders/子目录填写生成出的ModelTesterConfig中的TODOpretrained_model_name_or_path、get_init_dict()tiny 配置、get_dummy_inputs()、input_shape、output_shape。初始化维度保持小尺寸以加速对应的模型级基类BaseModelTesterConfig与ModelTesterMixin定义于 tests/models/testing_utils/common.py初始不要加模型级的LoraTesterMixin来自 tests/models/testing_utils/lora.py与 pipeline 级那个不同——即使模型继承了PeftAdapterMixin也要在初始 PR 中把它从生成文件里移除参考实现tests/models/transformers/test_models_transformer_flux.py。小结一份可对照的检查清单新 pipeline 必带 pipeline 级测试引入新模型类再加模型级测试集成/慢测试与 LoRA 测试不在初始 PR组件尺寸极小化dummy 组件一律用真实类 torch.manual_seed(0)不 monkeypatch 组件方法标准 pipeline一个PipelinePipelineTesterConfig 按关注点拆分的 mixin 测试类首轮仅PipelineTesterMixin与MemoryTesterMixin无法叶子级卸载的组件diffusers 模型用_supports_group_offloading False第三方组件列进group_offloading_leaf_level_exclude_modules而不是手写 skipsrc/缺口用模块级命名、strictTrue默认的 xfail 标记硬件缺口用skip_if_no_cudnn_engine()条件跳过变体 pipeline 组合FromPipeTesterMixinPAG pipeline 用PAGPipelineTesterMixin取代PipelineTesterMixinLoRA 测试与 pipeline 测试同文件is_loramixin 各自独立测试类配置类零 LoRA 内容模块化 pipeline一个配置类 按关注点拆分的 tester 类tiny 仓库镜像真实 checkpoint通过跑 pipeline 测块模型级测试一律由utils/generate_model_tests.py生成填写 TODO、剥离模型级LoraTesterMixin。【免费下载链接】diffusers Diffusers: State-of-the-art diffusion models for image, video, and audio generation in PyTorch.项目地址: https://gitcode.com/GitHub_Trending/di/diffusers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考