Diffusers 怎样比较不同 scheduler 的采样取舍

在 Diffusers 中换 scheduler，真正难的不是“能不能换”，而是怎么比较才有意义。scheduler 负责去噪过程中的步数、时间步和样本更新规则；同一模型在不同 scheduler 下可能表现出不同的速度、细节和稳定性。最稳妥的做法是：先保留 checkpoint 自带的 scheduler 作为基线，只替换一个兼容候选，并固定提示词、随机种子、步数和硬件。

官方资料入口：https://huggingface.co/docs/diffusers/main/using-diffusers/schedulers

没有一个 scheduler 对所有 checkpoint 和提示词都“最好”。比较时应先看模型家族和默认配置，再用相同输入做小规模对照，最后按目标步数、耗时、画面稳定性和细节取舍做选择。

先把比较对象放在同一条基线上

如果一次比较同时改了 scheduler、提示词、seed、分辨率和推理步数，最后只能知道“结果不一样”，却不能知道差异来自哪里。Diffusers 官方文档也建议把候选 scheduler 放在同一个 pipeline 中尝试，并通过 pipeline.scheduler.compatibles 查看兼容范围。

第一轮对比至少固定这几项：

• 同一个 checkpoint 和 pipeline 类型；
• 同一条 prompt、negative prompt、分辨率和 batch size；
• 同一个随机种子与生成设备；
• 同一个 num_inference_steps，并记录真实耗时；
• 只更改 pipeline.scheduler，其它配置保持不变。

这里的“同一个 seed”不是为了让所有图片完全一样，而是减少随机噪声对观察的干扰。结果仍应按多条 prompt 或多次 seed 观察，不能用一张样例图给 scheduler 排名。

用 from_config() 替换候选，而不是手写一份新配置

scheduler 通常由配置文件定义，本身不携带模型权重。替换时优先从当前 pipeline 的 scheduler.config 创建候选，这样 num_train_timesteps 等与 checkpoint 相关的配置可以继续沿用。

import time
import torch
from diffusers import DiffusionPipeline, DPMSolverMultistepScheduler

# 使用同一个 pipeline，保证模型、VAE 和文本编码器不被比较过程改变
pipeline = DiffusionPipeline.from_pretrained(
    "stabilityai/stable-diffusion-xl-base-1.0",
    torch_dtype=torch.float16,
).to("cuda")

# 记录默认类型，后续把它当成比较基线
default_name = pipeline.scheduler.__class__.__name__

# 从现有配置派生候选，避免丢失 checkpoint 的关键时间步配置
candidate = DPMSolverMultistepScheduler.from_config(
    pipeline.scheduler.config,
    algorithm_type="sde-dpmsolver++",
)
pipeline.scheduler = candidate

# 用固定 seed 和固定步数做一次可复用的对照输入
generator = torch.Generator(device="cuda").manual_seed(20261111)
start = time.perf_counter()
image = pipeline(
    prompt="一座雾气中的海边灯塔，电影感光线",
    negative_prompt="模糊，低对比度",
    num_inference_steps=20,
    generator=generator,
).images[0]
elapsed = time.perf_counter() - start

# 保存的不是“最佳答案”，而是本轮对照的元数据
print({"default_scheduler": default_name, "current_scheduler": pipeline.scheduler.__class__.__name__, "seconds": round(elapsed, 3)})
image.save("scheduler-comparison.png")  # 将结果保存为对照样本，便于人工并排观察

示例的关键点是 from_config() 和固定输入。algorithm_type 只是候选 scheduler 的配置项，是否适合当前 checkpoint 仍要通过对照实验判断；不要把某一种参数组合当成所有模型的通用答案。代码中的打印结果是运行时记录格式，本文配图只是结构说明图，不代表这段代码已经在本机执行。

比较时要同时看速度、步数和画面稳定性

对比表不要只写“质量高低”。更实用的记录方式是把相同 prompt 在不同步数下的耗时、构图保持程度、细节、异常比例和显存占用放在一起。这样可以区分“少跑几步仍可用”和“必须多跑几步才能稳定”这两类结果。

如果改变了 timestep_spacing、use_karras_sigmas、timesteps 或 sigmas，应把这些改变单独记为另一个实验变量。官方文档明确说明，不是所有 scheduler 和 pipeline 都支持自定义 timesteps 或 sigmas，调用前应查看对应 API 的 set_timesteps 能力。

根据采样步数和模型家族做选择

可以先用下面的判断顺序缩小范围：

1. 先看默认 scheduler。它是 checkpoint 发布者已经配好的起点，先测它能让后续对比有参照。
2. 追求通用的速度与质量平衡。可以把 DPMSolverMultistepScheduler 作为候选，但不要脱离具体 checkpoint 直接宣布它必胜。
3. 关注风格和构图变化。EulerDiscreteScheduler 或 EulerAncestralDiscreteScheduler 适合纳入同一组对照，重点观察低步数下的风格与稳定性。
4. 模型属于 FlowMatch 家族时先保持匹配。对 Flux、Qwen-Image 一类模型，应优先保留 FlowMatchEulerDiscreteScheduler，只有明确实验目的时才替换。
5. 模型支持蒸馏或少步生成时另做少步实验。LCMScheduler 需要对应的 LCM 模型或 LoRA；它不是普通 checkpoint 的无条件加速开关。

这套顺序的核心不是记住一个“冠军 scheduler”，而是先排除不匹配的候选，再用相同输入比较剩下的选项。对于自定义 AYS 时间步、Karras sigmas 或 trailing spacing，也应把模型兼容性和步数一起记录，因为时间步分布本身就会改变采样行为。

常见误区与落地结论

只看单张样例图

单张图很容易被 prompt、seed 或偶然构图影响。至少准备几条代表性 prompt，并在相同步数下并排记录；如果结论只在一条 prompt 上成立，就把它写成局部观察。

替换 scheduler 后沿用旧的步数结论

同一个 scheduler 在 10 步、20 步和 30 步下的取舍可能不同。比较时应该把步数当作明确维度，而不是只跑一次默认值。

把兼容列表当成效果排名

pipeline.scheduler.compatibles 解决的是“哪些类可以尝试”，不是“谁的质量最高”。兼容只是入场条件，最终仍要按目标模型和实际任务记录结果。

简化成一句话：保留默认配置做基线，使用 from_config() 只替换 scheduler，固定输入并分档测试步数；如果是 FlowMatch、蒸馏或少步模型，优先遵循模型家族的默认组合。这样得到的选择既能解释，也方便以后复现。

相关问题

scheduler 会重新训练模型吗？

不会。Diffusers 的 scheduler 主要定义推理阶段的去噪更新规则，通常以配置存在，不等同于替换模型权重。

为什么同一个 scheduler 在不同模型上结果不同？

模型的训练方式、预测类型、噪声配置和默认时间步可能不同。scheduler 的表现依赖这些上下文，因此要从 checkpoint 默认配置开始对照。

怎样把比较结果用于生产？

先为业务固定 prompt 集、步数档位和种子策略，再记录平均耗时、失败重试和画面稳定性；最后选择满足质量底线且吞吐可接受的组合，而不是只看单张最好图。