LingBot-Video 怎么选推理路径？8 步 DMD 不等于小显存

LingBot-Video 怎么选推理路径？8 步 DMD 不等于小显存

准备在一张 48GB 显卡上试用 LingBot-Video，你打开仓库，同时看到 Dense 1.3B、MoE 30B-A3B 和新发布的 8 步 DMD。直觉很容易把它们排成一条线：Dense 小，MoE 强，DMD 又快又省；既然每次只激活约 3B 参数，少跑几步似乎更容易装进显存。

这条推理混合了不同问题。模型规模影响要保存哪些权重；蒸馏配方决定怎样从噪声生成视频；并行和分片决定工作与参数怎样分布。选 LingBot-Video 的推理路径，要先把权重身份、采样配方和运行拓扑对上，再讨论能否装下、是否更快。

这不是抽象的部署原则。官方性能表里，MoE 的一个 FP8 路径比 BF16 更快，每卡显存峰值却更高；新增 DMD 使用 8 步，但仍属于 MoE 30B-A3B，并没有变成 3B 总参数的小模型。把名称当资源承诺，可能从第一条命令就选错实验。

本文核查至 2026 年 9 月 23 日，代码固定为官方仓库提交 dd5c231e793406c6a8893e9e4307008a9c2adfe4。下面的性能数值来自官方文档，不是作者在 A6000 上的实测；文章只完成源码与文档核验，没有运行模型或测量显存。

8 步是一套学生模型配方，不是把 40 改成 8

官方仓库在 9 月 18 日发布了 DMD 蒸馏学生模型。这里的"学生"是经过蒸馏得到的权重，学过特定的少步生成过程，不是普通权重在命令行里换了一个名称。当前下载表把 Dense、MoE 和 MoE-DMD 分开列出：Dense 为 1.3B；MoE 为 30B-A3B，配套 Refiner；DMD 是同一规模标识下的蒸馏版本，公开任务是文本生成视频和文本加首帧生成视频。^1^

因此，两个常见操作都不等价于官方 DMD 路径：给未蒸馏 MoE 设置 8 步，或者加载学生权重却继续使用普通采样器。前者没有得到学生权重，后者没有沿学生训练时的采样轨迹运行。即使程序能输出文件，也不能把它标成正确复现。

官方 DMD 文档将这些条件作为一套配方：学生权重、专用调度器、8 步、引导强度 1 和 shift 3。文档解释，引导效果已经蒸入学生，再沿用普通模型的引导设置会形成额外引导；调度器也必须匹配训练时的步进方式。标准示例使用 480×832、121 帧和 24 FPS。这里的数字用于确认所运行的配方，不是对其他分辨率和帧数的质量保证。\^dmd

源码提供了一个很直接的核对点：统一 runner 在选择 DMD 调度器的分支里替换底层 pipeline 的 scheduler。该操作改变采样过程，不会把用户提供的普通模型权重"转换成学生"。所以启动日志出现调度器名称，只能证明选中了这个执行分支，仍要追查模型目录究竟下载自哪个 checkpoint。\^runner

初次验证时，把"我用了哪个模型目录"和"我用了哪些采样参数"分开记录，比只记一句"跑了 DMD"更有价值。两者只要有一个不匹配，后面的画质和速度比较就可能在比较错误配置。

A3B、8 步、FP8，分别减少什么

MoE 的 A3B 描述激活参数规模，不是整套权重的驻留规模。即使某次计算只使用部分专家，运行系统仍要保存或按其实现方式管理其他专家。是否分片、是否卸载、是否另建缓存，会影响权重具体放在哪里，不能用"本次没激活"推导"完全不占内存"。

8 步主要减少采样迭代次数。它不自动移除文本编码器、VAE，也不自动把 MoE 专家变成更小的 Dense 网络。较少的迭代可能降低去噪耗时，但加载、条件编码、解码与导出仍然存在；端到端时间不应直接按 40÷8 写成五倍加速。

FP8 则涉及特定执行路径中的数值表示与内核。在某些实现里它可以减少存储，在另一些实现里，转换后的缓存会与原权重共存。LingBot-Video 的官方性能说明给出了后一种具体情况：FP8 专家缓存和 BF16 原权重同时驻留。它被定位为速度配置，不能直接视为显存优化。\^perf

以官方 40 步、Base-only、CP8 测试中的 MoE 为例：

路径	稳定单次推理时间	NVML 每卡峰值
Direct Diffusers，BF16 Exact	46.76 秒	83.75 GiB
FP8 expert	36.72 秒	110.80 GiB

这里"更快但更占显存"不是矛盾：优化对象不同，运行时保留的对象也不同。表中任务使用同一规定输入与输出设置，能够说明这两个路径在该测试中的取舍，却不能推导所有 FP8 实现都更费显存，更不能拿来预测单卡 A6000 的结果。

这也改变了排障顺序。如果问题发生在模型加载阶段，优先追查权重、复制份数和装载位置；如果加载成功、去噪中途 OOM，再查看分辨率、帧数、激活与执行方式；如果最后解码失败，则应核对 VAE 路径。这个顺序是作者的诊断建议，不是声称某个开关能保证解决对应故障。

先把"模型、采样、拓扑"做成一张核对表

启动命令很长时，最容易遗漏的不是参数本身，而是参数属于哪一层。建议把一次运行拆成三栏记录，而不是把所有值塞进一个"配置"字段。

第一栏是模型身份：模型目录、下载来源、提交或版本、是否为 Dense、普通 MoE 还是 MoE-DMD，以及目录中 Transformer 是否确实来自 student checkpoint。这里的关键是证明"加载了谁"，不能用 scheduler 名称代替 checkpoint 证据。

第二栏是采样契约：scheduler、steps、guidance、shift、分辨率、帧数、FPS、seed 和 attention/TF32 相关开关。DMD 的 8 步、guidance 1、shift 3 应作为一个组合记录；如果只写"8 steps"，后来很难判断是学生配方还是普通 MoE 的随手改参。

第三栏是运行拓扑：GPU 型号和数量、进程数、CP 设置、DiT-FSDP 与 VLM-FSDP 是否开启、Refiner 与 Rewriter 是否加入、模型放在 GPU 还是存在 CPU/offload 路径。拓扑栏回答的是"工作和驻留对象怎样分布"，不是再抄一遍模型名称。

这三栏还应各自有一个状态：planned 表示准备执行，loaded 表示日志已经确认对象被加载，observed 表示资源和输出已经记录。这样"命令写了 DMD"与"运行时确认用了 DMD"之间的差异会被保留下来。作者建议的状态字段不是官方 schema，也不替代官方日志；它只是避免把计划配置误写成运行事实。

如果一次启动同时接入 Rewriter、Base DiT 和 Refiner，最好把它们写成三个可折叠的组件块。每块记录输入、开始/结束时间和显存峰值，失败时标出最后一个成功组件。这样可以区分"文本结构化阶段没有完成"和"视频去噪完成但 VAE 解码失败"，也避免把整条流水线只归结为一条 OOM。

多卡先回答"分了什么"，再加总显存

官方同时提供 Context Parallel 和 FSDP。前者在这里用于上下文计算的并行，不能因为命令中写了 CP8，就假定所有权重都已经切成八份。FSDP 是另一组明确控制权重分片的设置。

当前推理文档把 DiT 与 VLM 分片分开说明。DiT 分片开关处理已加载的 Transformer；文本编码侧的 VLM 要用独立开关，VAE、scheduler 和提示特征也不是由 DiT 开关一并切分。因而"开了 FSDP"仍不完整：应该说清楚是哪个组件、多少进程、什么并行组合。\^parallel

官方同一组 40 步 MoE 测试中，CP8 的 Direct Diffusers 路径每卡峰值为 83.75 GiB；加入 DiT-FSDP8 后变为 37.61 GiB，稳定单次推理从 46.76 秒变为 54.78 秒。它展示的是容量与运行时间的交换，而非"多一个并行开关就更快"。两行均不包含 Refiner，也不是 DMD 学生模型测试。\^perf

此外，GPU 分片成功之前还存在主机侧的装载过程。官方文档指出，每个 rank 会先在 CPU 上构建 Transformer，再进行 FSDP；多进程启动因此可能给系统内存带来压力。只把八张卡的显存相加，既没有描述每卡分配，也没有覆盖 CPU 初始化阶段。

对于现有的 48GB 单卡，较小的 Dense 可以作为优先验证的候选，这是基于模型规模和已有入口作出的工程选择，不是保证任何分辨率都能跑。对于多卡机器，应该先确认目标路径是否真正分片了主要驻留组件，再用日志和测量验证容量。本文不沿用旧稿的固定主机内存建议，也不把官方其他环境的峰值折算成 A6000 保证。

同一个失败，要按加载、去噪、落盘三段定位

把错误都归到"显存不够"会让排障失去方向。一次视频任务至少可以分成三个观察段：模型加载与初始化、去噪循环、解码与文件落盘。每段的失败对象不同，应该保留的证据也不同。

加载段失败时，先保存完整模型目录的文件清单、每个进程的启动日志和主机内存峰值。此时不要急着减小帧数，因为问题可能是重复加载、rank 在 CPU 上构建完整 Transformer，或同时保留了原权重与转换缓存。若只看最终的 CUDA OOM 行，无法知道失败发生在分片前还是分片后。

去噪段失败时，再记录当前步数、活动分辨率、帧数、专家路径、attention 实现和每卡 NVML 峰值。DMD 少步只改变循环长度，不会把每一步需要的模型组件删除；普通 MoE、DMD、FP8 expert 的工作集也不能只用一个"参数量"字段替代。若在同一输入下只改一个拓扑开关，才能说明这次变化与峰值或耗时的关系。

落盘段失败时，重点看 VAE、输出格式、文件系统和导出耗时。任务已经完成去噪不代表视频已经可用；同样，目录里出现 MP4 也不等于动作质量通过。至少要记录文件是否完整、帧数是否符合预期、编码是否能再次读取，以及失败时最后一个可验证的中间状态。

这个三段划分也解释了为什么"换成 8 步"不能作为万能修复。它可能减少去噪循环的计算时间，却不一定改变模型加载、文本编码或最终解码的瓶颈。真正的优化动作应先对应到失败段，再选择权重、采样、分辨率或拓扑变量。

官方有性能表，为什么还不能填自己的 DMD 耗时

当前性能文档对测量范围写得很具体：5 秒、24 FPS、121 帧、480×832、Base-only T2V，采样使用 40 步、guidance 3、shift 3，采用指定精度与 attention 路径。它没有测试在线服务调度、连续批处理和多请求并发。\^perf

这张表首先不是 8 步 DMD 的成绩单。即使 Dense、MoE 和 DMD 共用部分 runner，也不能把普通 MoE 的时间简单除以五填进 DMD 行，更不能从单请求耗时推导排队压力下的吞吐。

表中"完整运行时间"和"稳定单次推理时间"也不应混用。前者覆盖新建进程到完整视频落盘和清理，包含加载等过程，但文档说明权重可能已经进入系统页缓存，因此不是严格磁盘冷启动；后者来自常驻进程预热后的请求。用户偶尔启动一次脚本，更关心前一类体验；准备做常驻服务，则还要补测队列、并发和资源竞争。

还有一个容易忽略的版本问题：性能文档标注了基础矩阵对应的冻结 revision，并说明后续清理没有重跑全部矩阵。把今天下载的代码与表中数字放在一起时，要保留这层对应关系。最新代码、最新模型和旧测试表来自同一仓库，不代表已经构成一次共同验证过的运行。

因此，现阶段能确认的是官方提供了具体路径和相应测量说明；我们自己的硬件、DMD 端到端时间与输出质量仍需测试。这种留白应体现在记录里，而不是被"约五倍""48GB 足够"之类估算填满。

第一轮运行应验证一套明确的组合

如果目标是确认环境与输入流程，先选 Dense 的 Base-only 路径；如果目标是评估少步 MoE，就明确选 DMD 学生，不再拿它与普通 MoE 混记。无论选哪条，第一轮都使用仓库配套的结构化提示词，暂时排除改写器与输入格式变化带来的影响。

以 DMD 为例，官方要求模型根目录包含模型索引、Transformer、文本编码器、processor、VAE 与 scheduler 等组件，Transformer 必须是学生权重。只下载一份 Transformer 导出，不等于准备好了完整运行目录。\^dmd

在已按官方说明安装依赖并准备完整学生模型目录的前提下，可以从这个入口开始：

MODEL_DIR=/path/to/complete-dmd-model \
  bash scripts/single-gpu/run_moe_dmd_t2v.sh

这条命令是入口示例，本文没有执行。固定提交下的脚本明确传入 DMD 的调度器、步数和引导设置，默认使用配套结构化提示词，不启动 Refiner。运行前仍需确认当前 GPU、软件环境与权重装载方式是否支持这条路径；"目录在 single-gpu 下"只表示启动形式，并不承诺任意单卡容量都够。\^script

把输出目录与下面这份简短记录放在一起，才能解释后续差异：

记录内容	它排除的混淆
代码提交、模型来源及版本、完整启动命令	普通权重与学生权重、旧脚本与新脚本混用
提示词文件、首帧文件及各自校验值	换模型时顺便换了任务输入
调度器、步数、引导、shift、精度和种子	以为只换权重，实际连采样配方也变了
GPU型号、进程数、CP与各组件FSDP设置	把总显存当成单进程可用显存
启动到落盘时间、常驻请求时间、CPU/GPU峰值	把加载成本藏进或排除出不同的时间列
输出文件及任务失败现象	有MP4就被误记成质量通过

这份记录是作者建议，不是官方输出格式。第一次无需填出完整性能排行榜；更重要的是明确哪些指标已测、哪些未测，并让下一轮能够重复同一输入。

比较实验要先锁定一个基线

如果文章或项目要比较 Dense、普通 MoE 和 DMD，第一轮不宜同时改变模型、输入、分辨率和并行方式。更实际的顺序是先用 Dense 完成一条最小 Base-only smoke，确认提示词、首帧、VAE 和导出链路可用；再用普通 MoE 固定同一任务，确认大模型路径的加载与输出；最后才接入 DMD student，并保留与普通 MoE 不同的 scheduler 和 guidance 配方。

这不是要求三个模型使用同一套不匹配参数，而是要求比较前先知道每套模型的有效配方。每一轮只改变一个主要问题：若想问"学生权重是否能少跑几步"，就固定任务、尺寸、帧数、GPU 和输出格式；若想问"FSDP 是否降低单卡驻留"，就固定模型和采样，把进程数与分片组合单独列出；若想问"FP8 是否值得"，就同时看速度、峰值、初始化时间和输出差异，不能只挑最快的一列。

还要保存失败样本。成功视频可以说明这次任务跑完，但不能说明路径在更长视频、另一种提示词或下一次冷启动中仍然成立。失败样本应带上失败阶段、最后日志、资源峰值和输入校验值；如果后来修复，也要保留修复前记录，避免只留下成功结果而丢失边界。

最终报告可以把结论分成三种：配方已按预期运行、资源取舍已在当前分母下观察到、输出质量仍需人工或任务指标复核。三者不能合并成一个"通过"。这样的分层记录，才能让下一次扩大分辨率、加入 Refiner 或迁移到多卡时，知道哪些结论可以继承，哪些必须重新测量。

需要改写提示词时，再单独接入 Rewriter。官方把它分为基础模型扩写与加载适配器后的结构化转换两个语义阶段；这是另一段运行成本，不能从 Base-only 结果推算全流程。需要 Refiner 时也单独增加，并重新记录耗时与峰值。runner 还会因指定独立 Refiner 目录而启用它，不能只检查命令里有没有一个布尔开关。\^prompt\^runner

接下来比较的是产出，不只是完成了几步

首轮输出后，先核对任务是否完成，再比较画面。以"机械臂把杯子放到托盘上"为例，除了杯子是否好看，还要看抓取与释放是否连贯、物体身份有没有变化、末尾是否真的落在托盘上。仅选一个漂亮帧，不能证明整段动作成立。

如果要比较普通 MoE 与 DMD，应各用与权重匹配的完整配方，固定同一组任务和输出规格，保存失败样本，同时测端到端成本。不要为了看起来控制了变量而强迫两者使用同一个不匹配的 scheduler；这里比较的是两套有效运行方案，之后才有条件进一步归因。

固定种子也不意味着跨内核逐位相同。官方 DMD 文档对 attention 和 TF32 有额外复现条件，普通快速开始路径并不承诺逐位复现。我们的首轮目标可以是任务结果与资源记录可核查；只有在研究数值对齐时，才把执行内核和相关开关继续纳入严格控制。\^dmd

最终，Dense、普通 MoE、DMD 不是"低配、中配、高配"三个档位。Dense 可以承担较小模型的入口验证；普通 MoE 提供标准采样的比较基础；DMD 值得用于评估少步路径，但它仍有自己的权重、调度器和容量前提。先证明选中的组合确实按预期运行，再判断生成结果是否值得它的时间与资源，才不会把一个新模型名称误当成已经解决的部署问题。

Footnotes

1. 官方 README：模型列表与发布记录，核查于2026-09-23。\^dmd: 官方 DMD 学生采样说明。少步配方与复现条件为官方说明，本文未复测。\^runner: 统一 runner 源码，调度器替换与Refiner启用条件。\^perf: 官方性能与显存文档。引用其40步Base-only测试，非本文硬件实测，非DMD性能。\^parallel: 官方 DiT 推理与分片说明。\^script: 官方 DMD T2V 单进程脚本。\^prompt: 官方提示词准备说明。 ↩