DMAD 把扩散模型蒸馏成少步采样，真正动手前要先解决的不是效果，而是“从哪个脚本起、配置里哪些字段说了算”。这类仓库通常分成三层：配置文件目录、模型与蒸馏组件目录、训练入口脚本。建议按配置、入口、最小规模三步确认：入口脚本接收哪个配置参数，配置里哪些字段控制学生模型的采样步数、分辨率与批大小，以及在单卡上能跑起来的最小批大小是多少。先跑通一次前向，再谈少步采样的质量。

判断方向：DMAD 少步蒸馏能否跑通，取决于入口脚本、配置字段、显存三者是否匹配，而不是某个固定权重文件。适用场景是自己先做一次蒸馏自测的读者：先用占位命令确认入口，再把步数、分辨率、批大小三类字段压到最小，用日志里的 loss 行和 checkpoint 判断前向是否真的走通，最后固定提示词与随机种子出图对比。边界是：不同仓库的文件名、字段名、默认超参差异很大，本页只给定位方法和骨架，具体值需要结合本地仓库与环境确认。

在仓库目录里找到蒸馏训练入口脚本

常见分层大致是：configs/ 放 YAML 或 JSON 配置；models/、modules/、src/ 放网络结构和蒸馏逻辑；train*.py、scripts/、tools/ 放训练与采样入口。找入口的判断依据不是文件名像不像“train”，而是看哪个脚本里有 argparse 解析、有配置文件加载、有训练循环，并且被 README 的示例命令直接调用。

# 先看顶层结构，再找读配置的脚本（路径以仓库为准）
ls -1

# 找出接收配置参数、或自己加载 yaml/json 的脚本
grep -rn `--include`=*.py -e 'add_argument' -e 'safe_load' -e 'argparse' . \
  | grep -i -e config -e teacher -e student -e distill

确认入口后，启动命令写成占位形式，把路径、配置名、GPU 号替换成仓库里的真实值再执行：

# 占位示例，实际脚本路径与参数名以仓库为准
CUDA_VISIBLE_DEVICES=0 python <repo>/<train_script>.py \
  `--config` <repo>/configs/<distill_config>.yaml \
  `--output`_dir <your_log_dir>

如果同目录下有多个相似脚本，优先选名字里带 distill / few-step / student 的那个，并用 `--help` 看参数列表里有没有 teacher 权重路径这一项，缺这一项的多半只是普通训练脚本。

在配置里定位步数、分辨率、批大小三类字段

配置文件通常很长，但和少步目标直接相关的只有三类字段：学生模型的采样步数（以及对应的 timestep 采样范围）、图像分辨率、批大小与梯度累积。要注意区分 teacher 与 student 两段配置，别把 teacher 的采样步数当成学生的步数改掉，否则出图时看不到少步效果。下面只是结构示意，字段名以仓库实际配置为准：

# 仅示意字段分组，不要直接照抄字段名
data:
  resolution: 512          # 分辨率相关，可能叫 resolution / image_size / size
  batch_size: 1            # 批大小，可能有 per_gpu_batch 之类的变体
train:
  max_steps: 100           # 先跑很少的迭代验证前向
  gradient_accumulation_steps: 1
student:
  num_sampling_steps: 4    # 学生步数，少步蒸馏的核心字段
  timestep_range: []       # 蒸馏时采样的时间步范围，名字差异最大
teacher:
  num_sampling_steps: 50   # teacher 的步数，一般不要和学生混用
  ckpt_path: <path>

定位方法：在配置里搜 step、resolution、batch 三个词，把命中的字段列出来，再看代码里哪一处读取它们传给模型或 dataloader。只改配置但代码里没读，等于没改，这一步建议先用一行日志或断点确认。

以最小规模配置跑通一次蒸馏前向

最小配置的组成建议是：批大小为 1、分辨率降到学生网络能吃下的下限、迭代数设成能走完几百步以内的小值、单卡、先不开分布式和多 worker。目标不是收敛，而是确认 teacher 权重加载、学生前向、loss 回传、checkpoint 保存这条链路通。控制台上通常应出现这几类日志：加载 teacher 权重的路径、学生模型初始化参数数量、dataloader 长度、按 step 打印的 loss 行、以及保存 checkpoint 的写入提示。

报错时的定位顺序建议按依赖与环境的代价从低到高走：先看 Python 与框架版本、CUDA 与驱动是否匹配；再看 teacher 权重路径与格式；然后是配置字段名拼写或类型（字符串当数字用很常见）；最后才怀疑显存不足。显存不足的表现通常是某个 step 前后直接 OOM，而不是配置解析报错，两者不要混在一起排查。

记录单次迭代的显存占用与耗时

这一步是为后面判断能不能加分辨率或批大小留基线。记录字段至少包括：显存峰值、单步耗时、迭代数，以及对应的分辨率、批大小、卡数和精度设置，缺一项后面就没法比较。数值由你自己实测填入，不要沿用别人的数字。

# 采样显存，间隔按需调整
nvidia-smi `--query-gpu`=memory.used `--format`=csv -l 1 > <your_log_dir>/mem.log

# 训练日志里通常已有 step 与耗时，可直接摘取
grep -i -e 'step' -e 'it/s' -e 'sec' <your_log_dir>/train.log | tail -n 20

把改动写回配置并出图对比

改完配置要确认它真的作用到了学生模型上，最直接的方式是出图对比：固定同一组提示词、同一个随机种子、同一份学生权重来源，只改一个变量（例如学生采样步数或分辨率），其余全部锁定。对比时看这几个维度：整体结构是否塌陷、纹理与细节是否明显变糊、颜色与亮度是否偏移、以及同一提示词在不同种子下的一致性。若步数改了但两张图几乎完全一致，多半是配置没被读取，或者采样脚本用的还是旧权重，这时回到配置读取位置核对一遍。

# 占位示例：采样脚本参数名以仓库为准
python <repo>/<sample_script>.py \
  `--config` <repo>/configs/<student_config>.yaml \
  `--ckpt` <your_log_dir>/<checkpoint> \
  `--prompt` '<fixed_prompt>' \
  `--seed` 1234 \
  `--steps` <student_steps> \
  `--outdir` <your_log_dir>/compare

建议每次只动一个字段并把配置文件和输出图目录一起命名归档，之后回溯时能直接对上是哪一版配置产出的哪一批图。少步蒸馏的效果判断依赖多次同条件对比，单张图好看并不能说明学生模型已经学到 teacher 的行为。