把视频模型推理提速一半，画质会掉多少？

让视频模型跑得更快，有一个很直接的办法：让它变差。把步数砍掉一半，降低精度，关掉引导——也就是那一道让画面贴近提示词的第二遍处理。模型渲染会更快，同时它也可能画出更模糊的脸、更平的光线，以及手指数量不对的手。

推理环节的每一次提速都是一笔交易。有些交易不付出肉眼可见的代价，有些代价很大。要分清哪次是哪种，唯一的办法是测量。这套测量不是收尾时额外补的一步，而是工作本身的一部分。

更快的模型，可能已经是另一个模型

让扩散推理变便宜的那些改动，动的都是模型内部的数字：

• 降低精度，用更少的位来存储和相乘数字，每一步都会出现小的舍入误差。
• 更快的注意力内核用不同的顺序、或更低的精度计算同样的东西，结果可能在最后几位上不同。
• 通过蒸馏模型减少步数，得到的是一个学会了模仿原模型的模型，而不是原模型本身。

扩散模型每产出一个结果，都要把网络跑很多遍，每一步的输出喂给下一步。第一步里极小的差异，到最后一个步可能长成一张不同的脸。所以“它跑得更快了”这句话，说明不了它是否还在生成同样的视频。

错误的答案可以看起来很对

这个领域现在已经在测量这件事。AI系统编写GPU内核时，有些内核能通过弱测试，却在强测试下失败。KernelBench-Verified用更强的基线和隐藏的测试输入检验AI编写的内核，发现有些内核跳过了本该做的工作，平均收益变成了亏损。The Correctness Illusion构造了一小组带有已知缺陷的内核，一种常见的单输入形状测试让它们全部通过，而用大量随机输入测试则把每一个都抓了出来。

即便是正确的代码，也可能对同一个请求给出不同的输出。Thinking Machines在语言模型服务器上展示了这一点（《Defeating nondeterminism in LLM inference》）。有些内核在不同批大小下给出略有差异的结果，而批大小会随服务器负载变化。我们改动的每一个内核都是如此，所以测试必须覆盖不止一种情况。

对图像和视频来说，验证更难。两段不同的视频可以看起来都没问题，所以“看起来没问题”不算测试。用同样的提示词和同样的随机起点，原模型给出一个参考视频，我们拿候选结果与它对比。

同样的提示词、同样的随机起点，更快的版本会偏离原模型，它的得分会掉到限值以下。

我们如何验证一次改动

我们的规则是：每一次提速改动，都在同一类型的GPU上与原始模型对比。具体做法是：

1. 渲染参考结果。在同一块GPU、同样的提示词下，运行模型厂商原样交付的原始模型。
2. 渲染候选结果。用同样的提示词和同样的种子——也就是设定随机起点的那些数字——运行改动后的版本。
3. 对比。给候选结果的画面与原模型的接近程度打分，给输出与提示词的匹配程度打分。有人说话时，还要给台词与口型是否对得上打分。
4. 测速。在同一块GPU上，对预热后的候选版本计时。
5. 决定。为每个模型在每种GPU上设定一条质量限值。只有既更快、得分又保持在限值以上的改动才会被接受。

我们试过的一些改动没能通过。有一个更快的设置让画面偏离原模型太远，所以它没有成为默认选项。另一个在短测试里正常，在长而锐利的片段上就崩了。这些改动不会发布。记录下什么失败了，和记录下什么成功了同样有用。

自动调优为什么需要这一步

Deep Variance构建的是自动调优的推理栈：一套面向生产环境扩散工作负载、处于自动巡航状态的推理栈。它跑一个循环：

• 在运行模型的GPU上对每个模型做剖析：速度、内存和输出。
• 针对这块GPU调优每个模型：精度、注意力和内存占用。
• 用上面的步骤验证每一次改动。
• 当模型或GPU发生变化时重新评估，再次调优。

一个自行调优的循环，只有在它能拦住让输出变差的改动时才是安全的。那一步对比就是这道闸。没有它，自动巡航只是用更快的方式犯错。

改动不通过就退回调优环节，通过才发布。

对企业部署意味着什么

当我们在团队自己的GPU上部署这套栈时，验证是工作的一部分，而不是额外附加：

• 在改动任何东西之前，先在团队的GPU和流量上测量模型。
• 把每一次改动与原始模型在那套硬件上的输出做对比。
• 记录结果，让团队能看到改了什么、在质量上付出了什么代价。

在生产环境跑视频模型的团队，承受不起一次无声的质量下滑。客户更不喜欢的那种更便宜的产出，并不真的更便宜。验证用数字说明每一次节省在质量上花了多少钱，团队可以据此用事实做决定。

结论

提速很容易宣称，很难让人相信。当有人向你提供更快的扩散推理时，问三个问题：

• 比什么更快，在哪里测的，用的是哪块GPU？
• 与什么输出相比，用哪些指标衡量？
• 记录在哪里，方便你之后核验？

我们对每一次改动都问自己同样的问题。