A Anaxagore
← 所有项目

Contribution Tasks

huggingface/diffusers

候选人是 GPU kernel / 训练性能工程师，但当前无 GPU。Diffusers 的 schedulers/、scripts/、tests/schedulers/、attention_processor 中的数值正确性、CPU 参考实现、Triton 编译期问题、性能建模与文档/测试基建，都能在 CPU/MPS 上发挥其专长。

当前方向：从扩散模型库扩展为扩散模型基础设施 + 硬件后端适配层（TPU/TorchTPU、tensor-parallel、LoKr、QwenImage/Flux2/Cosmos 等新 pipeline）。

★ 34702Fork 73864 个候选任务Gemini：LongCat-2.0

更新于 2026-11-05T07:57:30+00:00 · 本次生成失败，展示上次结果 · 打开仓库 ↗

一、项目定位

🤗 Diffusers 是 Hugging Face 维护的扩散模型推理与训练工具库，定位是「state-of-the-art pretrained diffusion models for image, audio, and even 3D structures」的模块化工具箱。README 明确把设计哲学写成 usability over performance、simple over easy、customizability over abstraction，因此它不是单一推理引擎，而是由 pipelines / schedulers / models 三层可组合抽象构成的生态入口：pipelines 负责把完整推理串起来（text-to-image、inpainting、video、audio），schedulers 提供不同噪声调度，models 则作为可替换的 UNet / VAE / DiT 等构件。和 ComfyUI、Stable Diffusion WebUI 这类前端/节点工具相比，Diffusers 更接近底层库角色，被大量第三方工具与 Hugging Face Hub 上的 30,000+ checkpoint 直接依赖。当前阶段已是成熟活跃的生产级项目：最近提交热点集中在 docs/source、src/diffusers、tests/models，最近 releases 包括 0.41.0（QwenImage 2.1 pipeline）、0.40.0（tensor-parallel support、improved CLI）、0.39.0（new image and video pipelines），提交里同时有 TPU/TorchTPU backend、LoKr adapter、CLI 改进、device-map 修复等中高等难度特性，说明它正从「扩散模型库」扩展成「扩散模型基础设施 + 硬件后端适配层」。目录规模上 src 1067 项、tests 628 项、docs 512 项、examples 464 项、scripts 96 项，CI 与贡献流程完整（CONTRIBUTING、Makefile、setup.py、release 流程、AI agent 插件 .ai/），属于高频迭代的中大型仓库。

解决什么问题、给谁用

解决的是扩散模型从研究到生产落地之间的工程化断层：原始论文实现分散、scheduler/模型/预处理耦合严重、新模型与新硬件适配成本高。具体而言，它把「加载一个 SOTA pipeline 做推理」降到几行代码，同时把「替换其中某个 scheduler、某个 UNet、加 ControlNet/LoRA、切到 mps/xpu/tpu」做成可组合操作。目标用户与典型场景：(1) 应用层开发者 / 设计师，用 DiffusionPipeline.from_pretrained 在 Hub 上拉 checkpoint 直接跑 text-to-image、img2img、inpainting、ControlNet、视频生成；(2) 算法 / 训练工程师，基于 examples/ 下的 dreambooth、text_to_image、advanced_diffusion_training、consistency_distillation、reinforcement_learning 等脚本做微调、蒸馏、RL 训练；(3) 模型作者 / 集成方，通过 modular pipelines、社区 pipeline、convert_*.py 脚本把自家模型接入 Hub 生态；(4) 推理优化工程师，在 optimization/ 与 benchmarks/ 下做 fp16/编译/并行/量化适配，并把结果接回 pipeline。

同类项目与差别

核心能力

能力在哪成熟度
State-of-the-art diffusion pipelines（text-to-image、img2img、inpainting、ControlNet、video、audio 等）src/diffusers/pipelines/成熟
Modular Diffusers：可组合的 pipeline 组件与子模块src/diffusers/pipelines/ 及 tests/modular_pipelines/成熟
可插拔 schedulers（DDPM、DDIM、Euler、FlowMatch、DPM 等）src/diffusers/schedulers/成熟
预训练 models（UNet、VAE、DiT、Transformer2D、text encoders）作为构建块src/diffusers/models/成熟
LoRA / LoKr / IP-Adapter 等适配器加载与融合src/diffusers/（LoRA 相关模块）、scripts/、tests/lora/成熟
ControlNet、T2I-Adapter、SparseControl 等条件控制src/diffusers/pipelines/controlnet、examples/controlnet成熟
训练与微调脚本（DreamBooth、Text-to-image、Advanced training、Consistency distillation、RL）examples/成熟
多硬件后端：CUDA、MPS (Apple Silicon)、xpu、TPU/TorchTPUsrc/diffusers/、docs/optimization、最近提交含 TorchTPU backendCUDA/MPS 成熟，TPU/TorchTPU 较新（需验证）
tensor-parallel 并行推理支持0.40.0 release notes 明确新增成熟
CLI 工具（diffusers-cli）与 AI agent 插件（.ai/skills、.claude-plugin、.codex-plugin）.ai、AGENTS.md、CLAUDE.md、scripts/成熟
模型转换脚本（convert_*.py）与 Hub 集成scripts/（96 个脚本，大量 convert_*）成熟
ONNX Runtime 导出与推理docker/diffusers-onnxruntime-cpu、docker/diffusers-onnxruntime-cuda成熟
benchmark 与 profiling 工具benchmarks/、examples/profiling成熟
量化（quantization）测试与适配tests/quantization/实验到成熟之间（需验证具体量化路径）

阶段：成熟活跃的生产级库，正处于从「扩散模型推理库」向「扩散模型基础设施 + 多硬件后端适配层」扩张阶段；README 与 releases 未标 Experimental，整体成熟，但部分新后端（如 TPU/TorchTPU、LoKr、tensor-parallel）属较新加入，需按具体子模块评估。

技术栈：Python；PyTorch；HuggingFace Hub / huggingface_hub；HuggingFace doc-builder（文档）；Ruff（pyproject.toml 配置 lint/format/isort）；Makefile（style / fix-copies / pre-release 等）；setup.py + pyproject.toml（包构建与发布）；GitHub Actions CI（.github/workflows）；uv 推荐用于虚拟环境与可编辑安装（AGENTS.md）；ONNX Runtime（docker 镜像与导出路径）；MPS / CUDA / TPU 后端（PyTorch 原生 + 自定义适配）

规模：目录规模：src 1067 项、tests 628 项、docs 512 项、examples 464 项、scripts 96 项、benchmarks 10 项、docker 8 项、utils 31 项；最近提交热点 docs/source (24)、src/diffusers (15)、tests/models (9)、.github/workflows (4)；最近三个 releases 分别为 0.41.0 (2026-10-06)、0.40.0 (2026-08-20)、0.39.0 (2026-07-03)，呈约 1.5 月一次中等版本节奏；Hub 上关联 checkpoint 30,000+；star 具体数字需验证。

二、架构与代码地图

Diffusers 在代码组织上呈现典型的「三层可组合抽象 + 一层工程支撑」结构，与 README 宣称的 pipelines / schedulers / models 三核心完全对应。 1) 接入层（Pipelines & Schedulers）：由 src/diffusers/pipelines/ 与 src/diffusers/schedulers/ 组成，是用户直接面对的入口。Pipeline 子类把一次完整推理编排成 text encode → loop denoise → decode 四步；Scheduler 子类决定每一步的噪声尺度与更新规则。新近提交热点（docs/source、tests/pipelines、modular_pipelines）和 0.40 的 tensor-parallel、0.41 的 QwenImage 2.1 都说明这一层仍在快速扩张。 2) 模型层（Models）：src/diffusers/models/ 是 UNet / VAE / DiT / 各 Transformer backbone 的聚集地，按 unets/、transformers/、autoencoders/ 分目录。models 是提交热点之一（tests/models 9 次、src/diffusers 15 次），也是新硬件/新结构适配的核心：ControlNet、LoRA/LoKr adapter、IP-Adapter、QwenImage 2.1、Anima 等都从这里长出来。 3) 执行支撑层（Utils / LoRA / Quantization / Attention）：src/diffusers/utils/、src/diffusers/loaders/（LoRA/LoKr/Textual Inversion 等注入）、src/diffusers/quantization/、src/diffusers/hooks/ 提供设备映射、权重加载、8/4-bit 量化、attention processor、pipeline 函数式调用等横切能力。最近的 LoKr adapter、device-map 修复、TorchTPU backend 都落在这一层。 4) 工程与工具层（scripts / examples / tests / benchmarks / docker / .ai）：scripts/ 96 个 checkpoint 转换脚本是新增模型的主要入口；examples/ 覆盖 DreamBooth、ControlNet、LoRA、Cosmos、CogVideo 等训练/推理模板；tests/ 628 项是回归防线；benchmarks/ 面向推理性能对比；docker/ 提供 CPU/CUDA/ONNX/TensorRT 镜像；.ai/ 给 AI agent 提供 skills。这一层没有 GPU 也能工作：scripts、examples 的 CPU 路径、tests 的 dummy 设备都可以在 MacBook Air 上跑。 整体看，库不是「kernel 仓库」，而是用 PyTorch 把扩散模型各阶段串成可插拔组件；真正的 kernel 优化（FlashAttention、xformers、TensorRT、quantization）通过依赖和 attention processor 接入，不在本仓库内手写 CUDA/Triton。

接入层调度层模型层执行支撑层工程工具层ai_agent_skills → pipelines：调用调用pipelines → schedulers：配置配置pipelines → models：推理推理pipelines → loaders：注入注入pipelines → quantization：量化量化modular_pipelines → pipelines：组合hooks → pipelines：注入注入hooks → models：注入注入models → attention_processor：注意力loaders → models：注入注入quantization → models：量化量化training_scripts → pipelines：调用调用conversion_scripts → models：转换转换tests → pipelines：回归回归tests → models：回归回归benchmarks → pipelines：性能性能pipelinespipelinesmodular_pipelinesmodular_pipelinesai_agent_skillsai_agent_skillsschedulersschedulershookshooksmodelsmodelsattention_processorattention_processorloadersloadersquantizationquantizationutilsutilstraining_scriptstraining_scriptsbenchmarksbenchmarksteststestsconversion_scriptsconversion_scriptsdockerdockerdocsdocs
Diffusers 三层可组合抽象（pipelines / schedulers / models）+ 工程支撑层，自上而下是调用与注入关系
模块 / 路径职责 · 入口 · 依赖
pipelines
src/diffusers/pipelines/
数百文件，几十个 pipeline 子目录		推理/训练入口，把 text encode、循环去噪、image/audio decode 编排成端到端 pipeline；每个模型族一个子目录（stable_diffusion、flux、qwen_image、hunyuan_video、cosmos 等）
入口：DiffusionPipeline（base pipeline）、StableDiffusionPipeline、FluxPipeline、QwenImagePipeline、HunyuanVideoPipeline、CosmosPredict25Pipeline、各 pipeline 子类的 __call__ / call()
依赖：schedulers, models, utils, loaders
README 与 release 0.41.0（QwenImage 2.1）、0.40.0（tensor-parallel support）、0.39.0（new image and video pipelines）都以此为核心；tests/pipelines/、tests/modular_pipelines/ 是回归重点；提交热点 docs/source 主要就是 pipeline 文档
schedulers
src/diffusers/schedulers/
数十文件		噪声调度抽象，定义 timestep、noise scale、step() 更新规则；是 Diffusers 三大可插拔组件之一
入口：SchedulerMixin / DiffusionScheduler、DDPMScheduler、DDIMScheduler、FlowMatchEulerDiscreteScheduler、AmusedScheduler、UnCLIPScheduler
依赖：utils
FlowMatchEulerDiscreteScheduler 在 Flux/SD3 等新模型中大量使用；scripts/convert_*.py 常直接引用具体 scheduler 类做验证；CONTRIBUTING 列出「New scheduler」是官方贡献路径
models
src/diffusers/models/
数百文件，是 src 中最大子目录		所有扩散模型 backbone：UNet、DiT、Transformer、VAE/Autoencoder、prior；按 unets/、transformers/、autoencoders/ 分目录
入口：UNet2DConditionModel、FluxTransformer2DModel、QwenImageTransformer2DModel、HunyuanVideoTransformer3DModel、AutoencoderKL、AutoencoderKLQwenImage
依赖：utils, quantization
tests/models 提交热点 9 次；新模型（QwenImage 2.1、Anima、Cosmos、CogVideo）都在此新增；attention pattern、LoRA target module 命名都从这里定义
modular_pipelines
src/diffusers/modular_pipelines/
数十文件		Modular Diffusers 机制，把 pipeline 拆成可组合子图（blocks），支持跨模型复用与自动组装
入口：ModularPipeline、BasePipelineBlock、各 block 子类
依赖：pipelines, models, schedulers
docs/source 重点模块，tests/modular_pipelines 单独测试套件，0.39+ 持续投入；AGENTS.md 引用 references/modular.md
loaders
src/diffusers/loaders/
数十文件		LoRA、LoKr、IP-Adapter、Textual Inversion、ControlNet 等权重注入与合并；是扩展已有 pipeline 而不改模型本体的关键层
入口：LoraLoaderMixin、LoKrLoaderMixin、IPAdapterMixin、PeftAdapterMixin 等 mixin
依赖：models, utils
最近提交「[LoRA] add LoKr adapter support (Z-Image, Flux2/Klein)」(#14163) 和「Fix active adapter detection for text encoders」(#14961) 都在此
quantization
src/diffusers/quantization/
数十文件		8-bit / 4-bit 量化后端（bitsandbytes、GGUF 等），让大模型在有限显存下运行
入口：BitsAndBytesConfig、GGUFQuantizationConfig、PipelineQuantizationMixin
依赖：models, utils
tests/quantization/ 独立测试；examples/research_projects/flux_lora_quantization/ 有端到端示例；与端侧部署（TensorRT、量化）直接相关
utils
src/diffusers/utils/
数十文件		设备映射（device_map）、动态 import、dummy 对象、日志、hub 调用等横切基础设施
入口：is_torch_cuda_available、get_device_map、logging、push_to_hub、BaseOutput
依赖：无（底层）
最近提交「Make Stable Diffusion device-map comparisons deterministic」(#15010) 在此；dummy_*.py 让 CPU 环境可 import
hooks
src/diffusers/hooks/
数十文件		pipeline/model 行为注入点：回调、注册、替换子模块前/后处理；用于性能优化、Profiler、自定义调度
入口：HookRegistry、register_pipeline_hook、register_model_hook
依赖：pipelines, models
examples/profiling/ 使用；是扩展 pipeline 不改源码的官方方式
attention_processor
src/diffusers/models/attention_processor.py
单文件但核心		注意力实现调度中心：xformers、FlashAttention、SDPA、Triton 等 backend 都通过这里挂入
入口：AttentionProcessor、AttnProcessor2_0、XFormersAttnProcessor、FlashAttnProcessor
依赖：models
对 GPU kernel 工程师是最接近「kernel 层」的入口；TensorRT/FlashAttention 适配都改这里
training_scripts
examples/
464 文件		DreamBooth、ControlNet、LoRA、Cosmos、CogVideo 等训练/推理模板，覆盖 SD1.5/SDXL/Flux/SD3/QwenImage 等主流模型
入口：train_dreambooth_lora_flux.py、train_controlnet.py、train_text_to_image.py、train_cogvideox_lora.py、train_cosmos_predict25_lora.py
依赖：pipelines, models, loaders
examples 目录是「没有 GPU 也能读」的最佳入口；advanced_diffusion_training/、research_projects/ 有高级优化
conversion_scripts
scripts/
96 文件		把外部 checkpoint（原始训练格式）转成 Diffusers 目录结构；96 个脚本几乎覆盖所有主流扩散模型
入口：convert_flux_to_diffusers.py、convert_sd3_to_diffusers.py、convert_cogvideox_to_diffusers.py、convert_qwen_image_to_diffusers.py（需验证）
依赖：pipelines, models, schedulers
新增模型必先走这里；脚本头部有完整命令行示例，可直接在 CPU 跑
tests
tests/
628 文件		回归防线：按 models/、pipelines/、schedulers/、quantization/、modular_pipelines/ 分套件
入口：tests/models/、tests/pipelines/、tests/schedulers/、tests/quantization/、conftest.py
依赖：所有 src 模块
提交热点 tests/models 9 次、tests/pipelines 2 次；conftest.py 有 dummy device 支持 CPU 运行
benchmarks
benchmarks/
10 文件		推理性能对比：Flux、LTX、SDXL、Wan 等模型的标准 benchmark
入口：benchmarking_flux.py、benchmarking_ltx.py、benchmarking_sdxl.py、benchmarking_wan.py、run_all.py
依赖：pipelines
对性能工程师友好；可在 Colab T4 上做最终确认
docker
docker/
8 文件		预构建镜像：CPU、CUDA、ONNX Runtime、TensorRT、xformers 等组合
入口：diffusers-pytorch-cuda、diffusers-onnxruntime-cuda、diffusers-pytorch-cpu 等 Dockerfile
依赖：pipelines
端侧部署（TensorRT、ONNX）参考；无 GPU 可用 diffusers-pytorch-cpu
ai_agent_skills
src/diffusers/commands/ 与 .ai/skills
数十文件		diffusers-cli 与 AI agent（Claude Code、Codex、Cursor）的 skills 系统，把贡献规范、模型集成、pipeline 编写等封装成可调用技能
入口：diffusers-cli skills list/add/update、SKILL.md、AGENTS.md
依赖：所有 src 模块
AGENTS.md 明确指向 references/ 下的 code_style.md、models.md、pipelines.md、modular.md、testing.md
docs
docs/source/
512 文件		Sphinx 文档源；提交热点 24 次，是全仓库最活跃目录
入口：_toctree.yml、各 pipeline/model/scheduler 的 md/rst
依赖：pipelines, models, schedulers
Modular Diffusers、Optimization、Training 等章节是深入理解架构的最佳读物
目录树（按文件数）
  • src/ 1067 个文件
    diffusers
  • tests/ 628 个文件
    __init__.py, conftest.py, fixtures, hooks, lora, models, modular_pipelines, others, pipelines, quantization, remote, schedulers, single_file, testing_utils.py
  • docs/ 512 个文件
    README.md, TRANSLATING.md, source
  • examples/ 464 个文件
    README.md, advanced_diffusion_training, amused, cogvideo, cogview4-control, community, conftest.py, consistency_distillation, controlnet, cosmos, cosmos3, custom_diffusion, discrete_diffusion, dreambooth
  • scripts/ 96 个文件
    __init__.py, change_naming_configs_and_checkpoints.py, conversion_ldm_uncond.py, convert_ace_step_to_diffusers.py, convert_amused.py, convert_anima_to_diffusers.py, convert_animatediff_motion_lora_to_diffusers.py, convert_animatediff_motion_module_to_diffusers.py, convert_animatediff_sparsectrl_to_diffusers.py, convert_anyflow_to_diffusers.py, convert_asymmetric_vqgan_to_diffusers.py, convert_aura_flow_to_diffusers.py, convert_blipdiffusion_to_diffusers.py, convert_cogvideox_to_diffusers.py
  • .github/ 46 个文件
    ISSUE_TEMPLATE, PULL_REQUEST_TEMPLATE.md, actions, dependabot.yml, labeler.yml, workflows
  • utils/ 31 个文件
    check_ai.py, check_config_docstrings.py, check_copies.py, check_doc_toc.py, check_dummies.py, check_forward_call_docstrings.py, check_inits.py, check_repo.py, check_return_annotations.py, check_support_list.py, check_table.py, check_test_missing.py, consolidated_test_report.py, custom_init_isort.py
  • .ai/ 17 个文件
    .claude-plugin, .codex-plugin, AGENTS.md, plugin.json, references, skills
  • benchmarks/ 10 个文件
    README.md, __init__.py, benchmarking_flux.py, benchmarking_ltx.py, benchmarking_sdxl.py, benchmarking_utils.py, benchmarking_wan.py, push_results.py, requirements.txt, run_all.py
  • docker/ 8 个文件
    diffusers-cli-cuda, diffusers-doc-builder, diffusers-onnxruntime-cpu, diffusers-onnxruntime-cuda, diffusers-pytorch-cpu, diffusers-pytorch-cuda, diffusers-pytorch-minimum-cuda, diffusers-pytorch-xformers-cuda
  • .claude-plugin/ 1 个文件
    marketplace.json
  • .gitignore/ 1 个文件
  • AGENTS.md/ 1 个文件
  • CITATION.cff/ 1 个文件
  • CLAUDE.md/ 1 个文件
  • CODE_OF_CONDUCT.md/ 1 个文件

一次调用怎么流过这些模块

一次典型推理（以 Stable Diffusion text-to-image 为例）从用户调用 StableDiffusionPipeline.__call__() 开始，完整路径如下： 1) 输入处理与配置分发：__call__() 接收 prompt、negative_prompt、num_inference_steps、guidance_scale 等参数，由 pipelines/stable_diffusion/pipeline_stable_diffusion.py 内的 DiffusionPipeline 基类统一调度。BaseOutput 等 dataclass 在 utils 层定义，用于承载最终结果。 2) Text Encoding：prompt 送入 CLIP/T5 等 text encoder（models/transformers/ 下的 CLIPTextModel 等），输出 encoder_hidden_states。这一步在 CPU 上也能跑，是 Apple Silicon MPS 优化的重点之一。 3) Scheduler 初始化：根据 config 选择具体 scheduler（如 DDIMScheduler、FlowMatchEulerDiscreteScheduler），调用 scheduler.set_timesteps(num_inference_steps) 生成离散时间步序列。Scheduler 是纯 Python/NumPy 逻辑，不依赖 GPU。 4) Latent 初始化与循环去噪：生成初始噪声 latent（randn），进入 for t in scheduler.timesteps 循环。每一步调用 UNet/Transformer 的 forward，传入 latent、t、encoder_hidden_states，得到 noise_pred；再用 scheduler.step() 更新 latent。这是计算密集区，FlashAttention / xformers / TensorRT 通过 attention_processor.py 挂入。LoRA/LoKr 在 loaders 层通过 mixin 注入 UNet，不改变 pipeline 代码。 5) Decode 与输出：循环结束后 latent 送入 VAE decoder（models/autoencoders/ 下的 AutoencoderKL）还原为像素图像，封装进 BaseOutput.images。 6) 后处理：image_processor（utils 内）做归一化、to PIL 等。 关键数据结构：BaseOutput（承载 images/audios）、SchedulerOutput（prev_sample 等）、encoder_hidden_states、latent、noise_pred。调度点：pipeline 的循环、scheduler.step()、attention_processor 的 dispatch、loaders 的 adapter merge。 训练路径类似，但由 examples/ 下的训练脚本（train_dreambooth_lora_flux.py 等）直接调用 pipeline 组件 + accelerator + PEFT，不经过 pipeline.__call__。

1加载 pipelineDiffusionPipeline.from_pretrained · src/diffusers/pipelines/diffusion_pipeline.py（需验证）2文本编码CLIPTextModel · src/diffusers/models/transformers/clip_text_model.py（需验证）3初始化调度scheduler.set_timesteps · src/diffusers/schedulers/scheduling_utils.py（需验证）4循环去噪UNet2DConditionModel / FluxTransformer2D · src/diffusers/models/5调度更新scheduler.step · src/diffusers/schedulers/6VAE 解码AutoencoderKL · src/diffusers/models/autoencoders/autoencoder_kl.py7后处理输出image_processor · src/diffusers/utils/image_processor.py（需验证）

关键类型与函数

名称路径用途
DiffusionPipelinesrc/diffusers/pipelines/diffusion_pipeline.py（需验证）
StableDiffusionPipelinesrc/diffusers/pipelines/stable_diffusion/pipeline_stable_diffusion.py
FluxPipelinesrc/diffusers/pipelines/flux/pipeline_flux.py
QwenImagePipelinesrc/diffusers/pipelines/qwen_image/pipeline_qwen_image.py（需验证）
SchedulerMixin / DiffusionSchedulersrc/diffusers/schedulers/scheduling_utils.py（需验证）
FlowMatchEulerDiscreteSchedulersrc/diffusers/schedulers/flow_match_euler_discrete.py（需验证）
UNet2DConditionModelsrc/diffusers/models/unets/unet_2d_condition.py
FluxTransformer2DModelsrc/diffusers/models/transformers/flux_transformer_2d_model.py（需验证）
AutoencoderKLsrc/diffusers/models/autoencoders/autoencoder_kl.py
AttentionProcessorsrc/diffusers/models/attention_processor.py
LoraLoaderMixinsrc/diffusers/loaders/lora_loader.py（需验证）
BaseOutputsrc/diffusers/utils/base_output.py（需验证）
ModularPipelinesrc/diffusers/modular_pipelines/modular_pipeline.py（需验证）

扩展点

最近在动的地方

建议阅读顺序

  1. README.md — 三层可组合抽象总览（pipelines / schedulers / models）
  2. PHILOSOPHY.md — 设计哲学：usability over performance
  3. AGENTS.md 与 .ai/references — 编码规范、模型/管道/模块化流水线约定
  4. src/diffusers/pipelines/diffusion_pipeline.py（需验证） — DiffusionPipeline 基类
  5. src/diffusers/pipelines/stable_diffusion/pipeline_stable_diffusion.py — 最经典 pipeline 实现
  6. src/diffusers/schedulers/scheduling_utils.py（需验证） — Scheduler 基类
  7. src/diffusers/models/unets/unet_2d_condition.py — 经典 UNet
  8. src/diffusers/models/attention_processor.py — attention backend 调度中心
  9. src/diffusers/loaders/ — LoRA/LoKr adapter 注入机制
  10. tests/conftest.py — dummy device、CPU 运行支持

三、本地跑起来（没有 GPU 的 Mac）

安装

  1. # 1. 用 uv 创建虚拟环境（AGENTS.md / CLAUDE.md 推荐方式）
  2. uv venv && source .venv/bin/activate
  3. # 2. 安装 PyTorch CPU 版本（Apple Silicon 用 MPS 后端）
  4. pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu
  5. # 3. 以 editable 模式安装 diffusers，跳过 GPU-only 依赖
  6. uv pip install -e .
  7. # 4. 验证安装
  8. python -c "import diffusers; print(diffusers.__version__)"
  9. # 注意：不安装 diffusers[onnxruntime-cuda] / tensorrt / xformers 等 GPU-only 依赖
  10. # pyproject.toml 中无强制 GPU 依赖，但部分 pipeline 运行时需 torch.cuda

哪些路径能真跑

["可 CPU/MPS 执行：src/diffusers/schedulers/（纯数学计算）、src/diffusers/models/ 中模型前向（小模型）、scripts/*.py 中 checkpoint 转换（map_location='cpu'）、tests/schedulers/、tests/others/、tests/quantization/ 部分、utils/check_*.py 系列", '可读代码但需 Colab T4 验证：tests/pipelines/（多数需 GPU 标记 slow+cuda）、tests/models/（大模型推理）、tests/modular_pipelines/、examples/ 中所有 train_*.py 和 pipeline 运行、benchmarks/、src/diffusers/pipelines/ 实际推理', '纯 CPU 安全：src/diffusers/utils/、src/diffusers/loaders/（LoRA 加载逻辑）、src/diffusers/quantization/ 配置部分']

最小可运行

  1. # 1. 无条件生成（DDPM，小模型，CPU 可跑）
  2. python -c "from diffusers import DiffusionPipeline, UNet2DModel, DDPMScheduler; import torch; model = UNet2DModel.from_pretrained('google/ddpm-cat-256'); scheduler = DDPMScheduler.from_pretrained('google/ddpm-cat-256'); scheduler.set_timesteps(10); x = torch.randn(1, 3, model.config.sample_size, model.config.sample_size); [x := scheduler.step(model(x, t).sample, t, x).prev_sample for t in scheduler.timesteps]; print('DDPM sample done, shape:', x.shape)"
  3. # 2. Scheduler 纯计算测试
  4. python -c "from diffusers import DDIMScheduler; s = DDIMScheduler.from_pretrained('CompVis/stable-diffusion-v1-4', subfolder='scheduler'); s.set_timesteps(10); print('Scheduler timesteps:', s.timesteps)"
  5. # 3. 加载 pipeline 但不执行前向（验证 from_pretrained）
  6. python -c "from diffusers import StableDiffusionPipeline; pipe = StableDiffusionPipeline.from_pretrained('stable-diffusion-v1-5/stable-diffusion-v1-5', torch_dtype=torch.float32); print('Pipeline loaded, device:', pipe.device)"
  7. # 4. 运行单个 scheduler 测试（CPU 安全）
  8. python -m pytest tests/schedulers/test_scheduling_ddim.py -x -q
  9. # 5. 运行 utils 检查脚本
  10. python utils/check_repo.py --check_modular || echo 'check_repo completed'
  11. # 6. 验证 CLI 安装
  12. diffusers-cli skills list

测试

pytest 框架，tests/ 下 628 项分目录。CPU 子集：tests/schedulers/、tests/others/、tests/testing_utils.py、tests/quantization/ 部分、tests/lora/ 部分。运行命令：python -m pytest tests/schedulers/ tests/others/ -x -q --no-header。耗时：CPU 上 scheduler 测试约 1-3 分钟。注意：tests/pipelines/ 和 tests/models/ 多数带 @slow 和 @require_torch_cuda 标记，默认跳过；强制跑会失败。CI 用 pytest + markers 控制，见 .github/workflows。

调试

CI

GitHub Actions（.github/workflows 46 项）。PR 必跑：lint（ruff，见 pyproject.toml）、make fix-copies 一致性检查、pytest 单元测试（分 slow/fast markers）。会被卡住：ruff 格式错误（line-length 119、import 排序）、check_copies 检测到未同步的 # Copied from 注释、tests_fetcher.py 检测到缺少测试覆盖、typos 检查（_typos.toml）。PR 模板要求填写变更描述。Nightly 跑完整 slow tests 需 GPU。

坑

四、维护者与社区

高频活跃：最近 10 个 commit 集中在 2026-10-06 ~ 2026-10-12（7 天内），覆盖 scheduler 修复、TPU/TorchTPU backend、LoKr adapter、CLI 改进、device-map 修复、docs 更新等多条线；最近三个 release 0.39.0（2026-07-03）、0.40.0（2026-08-20）、0.41.0（2026-10-06），约 6–8 周一个小版本。commit 热点集中在 docs/source（24）、src/diffusers（15）、tests/models（9）、.github/workflows（4），说明是文档、核心代码与模型测试三线并进的迭代节奏。

谁角色依据
sayakpaul核心维护者 / review 主力，关注 performance、KV cache offloading、scheduler 正确性Issue 14833「Enable KV cache offloading」assignee 为 sayakpaul，且其在 scheduler、pipeline、performance 相关 issue/PR 上频繁 review
yiyixuxuModular Diffusers 方向维护者Issue 15009「SequentialPipelineBlocks gets required wrong in both inputs and required_inputs」assignee 为 yiyixuxu，且 tests/modular_pipelines 提交热点与其相关
kashifmodels / 加载侧维护者Issue 13279「AutoencoderRAE loading error with older transformers」assignee 为 kashif，涉及模型加载兼容性
HuggingFace 团队维护者群体（未在证据中具名的 reviewer）跨 pipelines / schedulers / quantization / CLI / docs 的 review 与合并近 7 天内合并了 #15010、#14863、#14943、#15001、#14039、#14163、#14911、#14481、#14961、#14973、#14926、#14957 等多条 PR，覆盖 device-map、CLI、TPU、LoKr、CI、docs、image_processor 等多条线，说明存在多位具提交/合并权限的维护者，但证据未给出全部名字

流程与 Review 风格

CONTRIBUTING.md 定义了清晰的 9 级贡献梯度：1) 在 discussion forum 或 Discord 提问/回答；2) 开 Issue 或 Discussion；3) 回答 Issue/Discussion；4) 修「Good first issue」；5) 贡献 docs；6) 贡献 Community Pipeline；7) 贡献 examples；8) 修「Good second issue」；9) 新增 pipeline/model/scheduler（需先读 PHILOSOPHY.md）。所有 4–9 类贡献都走 PR 流程，AGENTS.md/CLAUDE.md 要求提交前跑 make style 和 make fix-copies。pyproject.toml 配置 ruff 做 lint/format（line-length 119，忽略 E501、C901、E721、E741、F402、F823；__init__.py 单独放宽 E402/F401/F403/F811；dummy_*.py 放宽 F401），isort 要求 2 行空行且 known-first-party=diffusers。CONTRIBUTING.md 未提及 CLA/DCO，LICENSE 为 Apache 2.0。setup.py 与 Makefile 给出 release 流程（make pre-release / pre-patch → fix-copies → release branch → nightly tests → tag → twine upload）。README 与 CONTRIBUTING 都明确鼓励先「say 👋 in our public Discord channel」。

从近期 PR 看，review 响应快（同一天内多次合并）、覆盖面细：#15012 修 VaeImageProcessor.denormalize 的 NumPy 输入、#14972 修 text-encoder LoRA alpha_pattern keys、#15003 修 KDPM2DiscreteScheduler sigmas_interpol 的 zero-safe 几何平均、#14948 修 Wan video-to-video cache context、#14931 修 Anima from_single_file 的 prefix 与 llm_adapter 键——都是针对具体 bug 的精准修复，说明 reviewer 会仔细看实现细节并要求正确性证据。Issue 侧常见标签包括 bug、performance、help wanted、contributions-welcome、Good first issue、Good second issue、needs-env-info，说明 review 方希望报告者提供可复现环境与最小示例。多个 issue 带有 stale 标签（如 #12771、#12386、#12760、#11002），说明长期无响应/无进展的 issue 会被自动标记清理。

渠道

这里的规矩

维护者现在最想要的帮助

五、切入方案

建议长期负责：src/diffusers/schedulers/ + tests/schedulers/ + scripts/ 的 CPU 可验证层，并横向覆盖 benchmarks/ 的 CPU/MPS 基线
scheduler 是 README 明列的三核心构件之一，纯数学计算天然 CPU/MPS 可跑；scripts/ 是新增模型入口、96 个脚本都依赖 CPU 权重映射；benchmarks/ 当前只有 GPU 基线，与 README 宣称的 Apple Silicon 支持直接冲突。三者合起来构成一个「无 GPU 也能端到端验证」的闭环：新 scheduler 有回归、新模型脚本有 smoke test、新硬件路径有 CPU 基线。这条路从 sayakpaul 关注的 scheduler 正确性、到 yiyixuxu 的模块化管线、再到 kashif 的模型加载都能自然衔接，是通向维护者身份的稳妥路径。

它现在缺什么（你无 GPU 也能补）

缺口依据为什么是你
scheduler 层缺少 CPU 友好的数值回归测试与文档对照commit 热点里 docs/source 24 次、src/diffusers 15 次，但 tests/schedulers/ 在热点中明显靠后；README 与 PHILOSOPHY.md 强调 schedulers 是可组合构件，而最近 #15010 刚修了 'device-map comparisons deterministic' 说明数值/设备一致性是持续痛点。scripts/conversion_ldm_uncond.py 等纯 CPU 脚本存在，但 scheduler 自身的回归覆盖并不显式。这是纯数学/张量形状层面的工作，MacBook Air CPU 即可跑，不需要 GPU。你擅长算子数值正确性验证，能直接把 scheduler 的 step/scale_model_input 输出做成带 tolerance 的回归用例，补到 tests/schedulers/。
scripts/ 下 96 个 checkpoint 转换脚本缺少统一 smoke test 与输入输出契约scripts/ 目录 96 个文件，convert_ace_step_to_diffusers.py、convert_anima_to_diffusers.py 等都有 docstring 示例，但仓库里没有 tests/scripts/ 或统一入口验证这些脚本至少能 import、解析参数、在 map_location='cpu' 下跑通权重映射。CONTRIBUTING 把 'contribute examples' 列为高优先级，而脚本是新增模型的主要入口。你熟悉 checkpoint 映射与权重重命名，可写一个 smoke test 框架（解析 argparse、mock 一个小 state_dict、跑映射函数），纯 CPU 即可，无需真实大模型。
benchmarks/ 只有 10 个文件、缺少 CPU/MPS 可跑的性能基线benchmarks/ 含 benchmarking_flux.py、benchmarking_sdxl.py、benchmarking_wan.py 等，全部面向 GPU 推理；README 里 run_all.py 需要 CUDA。而 README 明确写了 Apple Silicon 支持，说明 MPS/CPU 路径是被官方承认的使用场景，却没有对应基准。你擅长性能基准与 profiling，可基于 examples/profiling/profiling_pipelines.py 扩展一套 CPU/MPS 基准（latency、peak memory、scheduler 步时），用 PyTorch 的 CPU profiler 即可。
Modular Diffusers 测试覆盖不足，SequentialPipelineBlocks 边界条件有已知 bugtests/modular_pipelines 在 commit 热点只出现 1 次；community 证据显示 Issue #15009「SequentialPipelineBlocks gets required wrong in both inputs and required_inputs」assignee 为 yiyixuxu，说明模块化管线仍在快速迭代且测试跟不上。模块化管线本质是 Python 图遍历与输入输出契约检查，CPU 即可。你可针对 SequentialPipelineBlocks、InputMap 等补边界用例，直接与 #15009 对齐。
LoKr adapter (#14163) 刚合并但缺少与 LoRA 的数值对照测试最近 commit #14163 添加了 LoKr adapter support，tests/lora/ 存在但主要面向 LoRA；LoKr 与 LoRA 的等价性/差异没有在测试层固化。你擅长 LoRA/adapter 融合，可在 tests/lora/ 加 LoKr vs LoRA 对照测试（相同 seed、相同输入下输出差异的 bound），小模型即可在 CPU 跑。
TorchTPU backend (#14039) 刚合入但缺少非 TPU 设备的 fallback 测试#14039 是 '[TPU] TorchTPU backend integration - eager / torch.compile / tp'，属于新后端；仓库里 docker/ 有 diffusers-pytorch-cpu、diffusers-onnxruntime-cpu 等多种非 GPU 镜像，说明多后端是战略方向。你熟悉多后端适配，可针对 TorchTPU 的 PyTorch fallback 路径（CPU 执行）补测试，确保非 TPU 环境下不回归。
docs/source 文档与代码 docstring 之间存在漂移，check_config_docstrings.py 等未覆盖全部模块docs/source 提交 24 次（热点最高），utils/ 有 check_config_docstrings.py、check_forward_call_docstrings.py、check_doc_toc.py 等，但最近 #14973 '[docs] Community methods'、#14926 '[docs] Jobs guide' 说明文档仍在大量扩写，漂移是持续风险。你可扩展 check_* 系列脚本，让它自动比对 src/diffusers 中类的 docstring 与 docs/source 中的描述，纯 CPU 静态检查。
Community Pipeline 镜像与 examples/community/ 缺少 CI 级回归examples/community/ 下 100+ 个 pipeline（pipeline_null_text_inversion.py、pipeline_flux_with_cfg.py 等），utils/notify_community_pipelines_mirror.py 存在说明有镜像机制，但没有证据表明每次 CI 会跑这些社区管线的 smoke test。你可写一个社区管线 smoke runner（import + 构造最小 mock 输入），在 CPU 上保证不因核心 API 变更而静默坏掉。

第 1–30 天：看懂并露面

第 31–60 天：稳定产出

第 61–90 天：接管一块

第一批 PR

题目范围为什么安全
[tests] Add CPU regression tests for DDPMScheduler and FlowMatchEulerDiscreteSchedulertests/schedulers/ 新增 test_scheduler_cpu_regression.py，覆盖 get_timesteps / step / scale_model_input 的数值对照纯数学计算，MacBook Air CPU 即可跑；不触碰 src 代码，只补测试；与 PHILOSOPHY 强调的 scheduler 构件对齐
[scripts] Add smoke test harness for checkpoint conversion scriptstests/scripts/ 新增 test_conversion_scripts_smoke.py，mock 小 state_dict 验证 5–10 个 convert_*.py 的映射函数可 import 且输出键一致map_location='cpu' 运行，无需 GPU；不改动 scripts/ 本身，只加测试；scripts/ 96 个文件是新增模型入口，回归价值高
[docs] Fix scheduler docstring drift in FlowMatchEulerDiscreteSchedulersrc/diffusers/schedulers/ 的 docstring 修正 + docs/source 对应段落对齐docs/source 是提交热点（24 次），docstring 漂移是持续风险；改动限于文档字符串，不影响运行时
[benchmarks] Add CPU/MPS profiling mode to benchmarking_utils.pybenchmarks/benchmarking_utils.py 新增 device='cpu'/'mps' 路径，输出 latency + peak_memoryREADME 明确支持 Apple Silicon，补 CPU/MPS 基线与官方立场一致；只在 benchmarks/ 内改动，不影响 src
[utils] Extend check_config_docstrings.py to detect docs/source ↔ src docstring driftutils/check_config_docstrings.py 扩展为双向比对脚本，CI 可跑utils/ 已有 check_* 系列，扩展风格一致；纯静态检查，无运行时影响

怎么知道自己站住了

风险与对策
  • 仓库迭代极快（7 天内 10+ commit），你的 PR 可能迅速冲突：保持每个 PR 小而专注（单文件/单模块），rebase 频率提高；优先做测试/文档类 PR，这类冲突概率低于 src 改动
  • 无 GPU 导致无法验证 CUDA 路径的真实数值正确性：把验证拆成两层：CPU 数值回归（本地）+ Colab T4 最终确认（阶段 90 前申请免费 T4 做几十分钟验证）；在 PR 描述显式标注 'verified on CPU, CUDA pending'
  • 核心维护者关注点可能不在 scheduler/scripts，你的方向被边缘化：用证据绑定：scheduler 是 README 三核心之一、scripts 是新增模型入口、benchmarks CPU 基线直接支持官方 Apple Silicon 立场；在 PR 描述引用 PHILOSOPHY 与 README 原文
  • tests/schedulers/ 现有测试可能已隐含 GPU 假设，CPU 运行会暴露环境差异：先跑全量现有测试建立 baseline，再决定是加 skipIf(not cuda) 还是统一改用 CPU 小模型；与 sayakpaul 在 Issue 中对齐测试策略
  • scripts/ 96 个脚本质量参差不齐，smoke test 可能触发隐藏 bug 被误认为你的 PR 引入：smoke test 只验证 import + 映射函数输出键一致性，不验证数值；发现已有 bug 单独开 Issue，不阻塞你的 PR
  • MacBook Air 16GB 内存受限，部分测试可能 OOM：在 tests/conftest.py 加 device fixture 自动降级到 CPU + 小 batch；benchmark 默认用 64x64 或更小分辨率
  • Hugging Face 仓库权限申请流程不透明，triage 权限可能延迟：先从 Issue 回复、Discord 帮助、PR review 贡献可见度；权限是结果而非前提

六、怎么介入这个项目

社区入口：discord.gg/G7tWnz98XR · img.shields.io/discord/82381315959200153

建议顺序

成为长期维护者的路径
  • 首个 PR 落在 tests/schedulers/ 或 tests/scripts/，只补测试不改 src，降低 review 门槛
  • 第二个 PR 进入 schedulers 或 attention_processor 的数值正确性修复，与 PHILOSOPHY 的 scheduler 构件对齐
  • 第三个 PR 进入 loaders/ 或 quantization 的 CPU 路径，建立性能/适配器子模块 ownership

七、任务卡

任务 1优先 · low · CPU · 2 个晚上

[tests] 为 FlowMatchEulerDiscreteScheduler 补 CPU 数值回归测试

Issue #14953 · PNDMScheduler.set_timesteps crashes with NumPy broadcasting error for fewer than 4 inference steps ↗

已有 PR #149631 条评论bugschedulers更新 2026-10-10

用到的专长：算子数值正确性验证 + CPU 参考实现。

目标：在 tests/schedulers/ 新增 CPU 回归测试，覆盖 FlowMatchEulerDiscreteScheduler 的 get_timesteps / step / scale_model_input，对齐 #14953 修复风格。

为什么值得长期做：scheduler 是 Diffusers 三大可插拔构件之一，数值正确性是核心职责；补测试可直接进入 schedulers 维护路径。

怎么介入：建议先评论 #14953 说明将提独立测试 PR，避免与 #14963 冲突。
第一个 PR 的边界：仅新增 tests/schedulers/test_flow_match_euler_cpu_regression.py 一个文件，不动 src。
第一步：git checkout main && pytest tests/schedulers/ -x -q 确认现有测试在 CPU 可跑；阅读 src/diffusers/schedulers/flow_match_euler_discrete.py。
本机怎么复现 / 验证：pytest tests/schedulers/test_flow_match_euler_cpu_regression.py -v # 在 Mac CPU 直接跑
认领留言（英文，可直接贴到 Issue）
I'll add a CPU-only regression test for FlowMatchEulerDiscreteScheduler covering get_timesteps/step/scale_model_input (incl. edge cases like num_inference_steps=1/2/3, shift variants, and Karras sigmas). First PR will only add a new test file under tests/schedulers/ and will not modify src/. Target: within 2 evenings. Please confirm if you'd prefer a single focused file or a shared helper in conftest.py.
大致实施方案
  • 新建 tests/schedulers/test_flow_match_euler_cpu_regression.py（新增）
  • 构造已知 timesteps 与 sigma 序列，断言 step() 输出数值在 tolerance 内
  • 覆盖边界：num_inference_steps 为 1/2/3、shift=0 与非零、Karras sigmas 开关
  • 本地 pytest 验证；补充 docstring 说明测试为 CPU-only
可能涉及的目录或文件
  • tests/schedulers/test_flow_match_euler_cpu_regression.py（新增）
  • tests/schedulers/conftest.py 可能需补充共享 fixture
验收方式
  • pytest tests/schedulers/test_flow_match_euler_cpu_regression.py -v 在 MacBook Air CPU 通过
  • 对照 #14953 的修复，确认新测试能捕获回归
开工前问题与风险

向维护者确认

  • 测试应仅覆盖 FlowMatchEulerDiscreteScheduler，还是同时覆盖 DPMSolverMultistepScheduler 以对齐 #12771？
  • 是否需要将共享 helper 抽到 tests/schedulers/conftest.py？

风险

  • 几
  • 乎
  • 为
  • 零
  • ：
  • 只
  • 改
  • 测
  • 试
  • 文
  • 件
  • ，
  • 不
  • 动
  • s
  • r
  • c
  • 。
任务 2优先 · medium · Mac · 2 个晚上

[tests] 为 schedulers 在 MPS/CPU 上补 NaN / 越界契约测试（对齐 #15002）

Issue #15002 · KDPM2DiscreteScheduler produces NaN on final step due to zero-sigma interpolation ↗

已有 PR #150031 条评论bug更新 2026-10-10

用到的专长：算子数值正确性 + 多后端（CPU/MPS）契约测试。

目标：在 tests/schedulers/ 新增契约测试，断言 KDPM2DiscreteScheduler 在最终步不产生 NaN/Inf，并覆盖 CPU/MPS 双路径。

为什么值得长期做：scheduler 数值稳定性直接影响训练/推理正确性；补契约测试可防止回归，属于核心维护职责。

怎么介入：建议评论 #15002 说明将提独立测试 PR，不动 src。
第一个 PR 的边界：仅新增 tests/schedulers/test_kdpm2_discrete_nan_guard.py，不动 src。
第一步：阅读 src/diffusers/schedulers/scheduling_kdpm2_discrete.py 的 sigmas_interpol 逻辑；复现 #15002 的 NaN 场景。
本机怎么复现 / 验证：pytest tests/schedulers/test_kdpm2_discrete_nan_guard.py -v # CPU 必跑；MPS 在 Mac 自动检测
认领留言（英文，可直接贴到 Issue）
I'll add a CPU/MPS contract test asserting KDPM2DiscreteScheduler does not produce NaN/Inf on the final step (zero-sigma interpolation). First PR will only add a new test file under tests/schedulers/ and will not modify src/. Target: within 2 evenings. Please confirm if you'd prefer a focused file or a shared helper.
大致实施方案
  • 新建 tests/schedulers/test_kdpm2_discrete_nan_guard.py（新增）
  • 构造最终步 sigma→0 的输入，断言输出无 NaN/Inf
  • 通过 pytest.mark 区分 device=cpu/mps，MPS 不可用时 skip
  • 本地在 CPU 跑通；MPS 在 Mac 上验证
可能涉及的目录或文件
  • tests/schedulers/test_kdpm2_discrete_nan_guard.py（新增）
验收方式
  • pytest tests/schedulers/test_kdpm2_discrete_nan_guard.py -v 在 Mac CPU 通过
  • 在 Apple Silicon 上确认 MPS 路径也可跑（若可用）
开工前问题与风险

向维护者确认

  • 测试应仅覆盖 KDPM2DiscreteScheduler，还是扩展到所有会产生 zero-sigma 的 scheduler？
  • 是否需要将 NaN guard 抽为共享 helper？

风险

  • 低
  • ：
  • 仅
  • 新
  • 增
  • 测
  • 试
  • ；
  • 若
  • 需
  • 修
  • 改
  • s
  • r
  • c
  • 则
  • 拆
  • 独
  • 立
  • P
  • R
  • 。
任务 3可选 · medium · Colab T4 · 3 个晚上（含 Colab T4 最终确认）

[models] 审阅 WanCausalConv3d F.pad 优化（#14993）并补 CPU 数值一致性测试

Issue #14993 · WanCausalConv3d copies every activation with F.pad. Let the conv do the spatial padding. ↗

无人认领1 条评论更新 2026-10-08

用到的专长：GPU kernel 审阅 + CPU 数值一致性验证。

目标：审阅 #14993 的 F.pad 优化方案，并在 tests/models/ 新增 CPU 数值一致性测试，断言优化前后输出 bit-identical（float32）。

为什么值得长期做：WanCausalConv3d 是视频生成核心算子；审阅其优化并补 CPU 数值一致性测试，可进入 models/autoencoders 维护路径。

怎么介入：建议评论 #14993 说明将提独立测试 PR，不动 src。
第一个 PR 的边界：仅新增 tests/models/test_wan_causal_conv_cpu.py，不动 src。
第一步：阅读 src/diffusers/models/autoencoders/autoencoder_kl_wan.py 中 WanCausalConv3d.forward；理解 F.pad 与 conv padding 等价性。
本机怎么复现 / 验证：pytest tests/models/test_wan_causal_conv_cpu.py -v # CPU 复现；Colab T4 做最终 GPU 验证
认领留言（英文，可直接贴到 Issue）
I'll review the F.pad optimization in WanCausalConv3d and add a CPU-only numerical consistency test asserting bit-identical outputs (float32) between the old (F.pad + unpadded conv) and new (conv with padding) paths. First PR will only add a new test file under tests/models/ and will not modify src/. Target: within 3 evenings (incl. Colab T4 final check). Please confirm if QwenImageCausalConv3d should be covered in the same PR.
大致实施方案
  • 在 tests/models/test_wan_causal_conv_cpu.py（新增）中构造 float32 输入
  • 分别调用旧路径（F.pad + unpadded conv）与新路径（conv 自带 padding），断言输出相等
  • 在 Colab T4 上验证 GPU 路径也保持 bit-identical（最终确认）
  • 本地 CPU 跑通
可能涉及的目录或文件
  • tests/models/test_wan_causal_conv_cpu.py（新增）
验收方式
  • pytest tests/models/test_wan_causal_conv_cpu.py -v 在 MacBook Air CPU 通过
  • Colab T4 上验证 GPU 路径 bit-identical
开工前问题与风险

向维护者确认

  • 测试应仅覆盖 WanCausalConv3d，还是同时覆盖 QwenImageCausalConv3d？
  • 是否允许测试依赖真实模型权重，还是严格用随机输入？

风险

  • 中
  • ：
  • 需
  • 理
  • 解
  • c
  • o
  • n
  • v
  • p
  • a
  • d
  • d
  • i
  • n
  • g
  • 语
  • 义
  • ；
  • 但
  • 测
  • 试
  • 本
  • 身
  • 不
  • 动
  • s
  • r
  • c
  • 。
任务 4可选 · medium · Mac · 2 个晚上（仅评论）

[review] 审阅 llama.cpp/ggml 量化集成提案（#14841）并给出 CPU/MPS 基准建议

Issue #14841 · Explore llama.cpp/ggml quantization kernels for our GGUF integration ↗

无人认领2 条评论performance更新 2026-10-08

用到的专长：量化内核审阅 + 性能基准建模。

目标：审阅 #14841 的 ggml 量化内核集成方案，在 Issue 下给出 CPU/MPS 基准建议（哪些内核适用、如何接入 GGUFQuantizer）。

为什么值得长期做：GGUF 量化是端侧部署关键路径；审阅集成提案并给出 CPU/MPS 基准建议，可进入 quantization 维护路径。

怎么介入：建议直接在 #14841 下评论，先对齐方案再动手。
第一个 PR 的边界：第一阶段仅在 Issue #14841 下评论，不动代码；后续视反馈提独立 benchmark PR。
第一步：阅读 src/diffusers/quantization/ 下 GGUFQuantizer 实现；阅读 https://huggingface.co/blog/transformers-llama-cpp-quants。
本机怎么复现 / 验证：阅读 src/diffusers/quantization/ 与 GGUFQuantizer 代码；在 Mac CPU/MPS 上跑现有 GGUF 示例（如有）
认领留言（英文，可直接贴到 Issue）
I'll review the ggml quantization kernel integration proposal and comment on which kernels are most applicable to diffusion models (quantization/norm likely; attn depends on our attention dispatch). I'll also suggest a path to plug them into GGUFQuantizer via the kernels library, and outline a CPU/MPS benchmark plan. Target: within 2 evenings for the initial review comment. Please confirm if a follow-up PR with an MPS benchmark script would be welcome.
大致实施方案
  • 在 Issue #14841 下评论，列出适用于扩散模型的内核（quantization/norm 优先）
  • 给出接入 GGUFQuantizer 的路径建议（通过 kernels 库）
  • 若维护者同意，可后续提 PR 补 MPS/CPU 基准脚本
可能涉及的目录或文件
  • Issue #14841 评论
  • 后续可能 PR：examples/research_projects/gguf_mps_benchmark/（新增）
验收方式
  • 在 Issue 下获得维护者回应；若提 PR，在 Mac CPU/MPS 跑通基准
开工前问题与风险

向维护者确认

  • 哪些 ggml 内核最适用于扩散模型（quantization/norm vs attn）？
  • 是否允许在 Mac MPS 上验证？

风险

  • 低
  • ：
  • 仅
  • 评
  • 论
  • 与
  • 建
  • 议
  • ，
  • 不
  • 动
  • 代
  • 码
  • 。