
很多推理工具把优化收进一个 fast=true。速度变快后,用户只看到总耗时下降,却不知道 程序少算了哪些部分,也不知道画面出错时应该撤回哪个开关。
h3.c 固定版本 8974cc0 把这件事拆得很具体。它允许减少去噪步数、复用完整 DiT 输出、 减少活跃层、复用 Transformer core、缩短中间视频序列,或者降低内部画布。每个选项删掉 的计算不同,保留的信息不同,失效方式也不同。
这篇不回答"哪个 preset 最快"。它只建立一张预算表:改动发生在哪个轴,哪些部分仍 保持新鲜,代价会先出现在哪里,以及如何做单变量验收。

先把 reference、default 和 aggressive 分开
固定 README 提供了一组清楚的对照口径:
| 控制轴 | 慢参考 | 常用设置 | 激进设置 | 实际减少的工作 |
|---|---|---|---|---|
| 去噪时间 | steps 50 |
steps 20 |
steps 4..7 |
DiT forward 次数 |
| 完整去噪器复用 | reuse 1 |
reuse 2 |
reuse 3 |
真实 velocity 求值次数 |
| 网络深度 | layers 50 |
layers 45 |
layers 40 |
每次 forward 的活跃 block |
| Core residual 复用 | core-reuse 1 |
core-reuse 4 |
core-reuse 6 |
Transformer core 刷新次数 |
| 中间序列 | 关闭 | 可选 | token-reduction |
中间 block 的目标视频 token |
| 内部画布 | 输出尺寸 | 384→512 |
320→512 |
DiT 与 VideoVAE 的空间网格 |
这张表用于区分不同计算轴。少跑一次去噪、少跑五层、复用一段 core residual、合并一半 视频 token,都会节省计算,但它们破坏的是不同信息。
steps 50 也不等于跨框架的绝对真值。固定 README 只把它作为当前 Runtime 的慢参考。 不同随机数引擎和执行顺序不保证最终像素与 MLX 完全一致。文章后面的"参考"都使用这个 局部含义。

少 steps:直接把时间轨迹采稀
--steps N 始终表示实际执行 N 次 denoising pass。把 20 降到 4,并不是保留 20 个位置、 只让其中一些位置更便宜,而是直接用更稀的求解轨迹。
这类优化首先影响构图形成、运动推进和后期细节清理。固定 README 记录的 512×512、22 帧 作者实验中,四步路径约 3.5 秒,29-pass 参考约 26.4 秒。fox 与 surfer 的 full-video SSIM 分别约 0.556 和 0.547。它证明速度差异和明显的结果差异同时存在,不能用"仍能识别主体" 替代质量等价。
因此,低 steps 更适合作为构图预览。验收时应先看主体数量、镜头运动和大结构,不要只在 最后一帧检查锐度。

Whole reuse:保留时间点,少算 velocity
--reuse 2 和 --reuse 3 仍沿着 20 个 Euler transition 前进,但不会在每个位置重新运行 完整 DiT。固定版本在 20 steps 下分别执行 11 次和 8 次真实 DiT 求值,其余位置根据最近 两次真实 velocity 做外推。
它删掉的是完整 denoiser evaluation,依赖的是 velocity 在相邻 sigma 区间内足够平滑。 首个和末尾求值保持真实,能限制一部分漂移,却不能保证中间运动、肢体和细节都稳定。
这和少 steps 的差别很实用:
- 少 steps 改变求解网格。
- whole reuse 保留 transition 数量,但把部分模型求值换成外推。
两者都能减少 DiT 计算,失败原因却不同。排查时不能只写"fast 模式画质下降"。
Core reuse:边界每步刷新,昂贵核心少刷新
--core-reuse 复用的不是完整输出。固定 h3.h 明确说明,它会降低 Transformer core 的 重算频率,同时每一步继续刷新 timestep-sensitive 的 patch 与 output head。
可以把路径写成:
text
当前 noisy latent
→ 每步重新做 patch / timestep 输入
→ 复用或重算 Transformer core residual
→ 每步重新做 final head
这比 whole reuse 保留更多当前时间点的信息,也承担另一种假设:Transformer core 对临近 时间点的残差变化足够平滑。reuse 与 core-reuse 在固定实现中互斥,说明它们不是可以 无限叠加的两个倍率开关。
core-reuse 4 是作者标记的 fast 设置,6 属于 aggressive。更高值没有暴露,因为项目 验证中出现主体保真下降。这里的"验证"仍是项目作者报告,不是本文作者本地复现。
因此 whole reuse 与 core reuse 要分别记账。它们删掉的是不同范围的计算,在固定实现中 又彼此互斥,不能合并成一个"复用轴"。
少 layers:每次都跑,但网络变浅
--layers 45 或 40 不只是机械裁掉最后几层。固定源码会保护开头和结尾的结构关键 block, 再依据 checkpoint 中的 AdaLN gate 信号挑选活跃 block。未激活 block 的大权重和 schedule tensor 不保留,因此它同时减少计算和 resident transformer storage。
它改变的是每次 forward 的网络深度。即使每个时间点都运行,较浅网络仍可能丢掉对象关系、 条件服从或细节修复能力。验证时要和相同 steps、相同 reuse、相同 seed 的 50 层结果比较, 否则无法把差异归因给 layer thinning。
把 layers 45 称为"无损"也不准确。更稳妥的说法是:它是固定版本作者验证过的 fast 设置,仍需要针对自己的 prompt、分辨率和主体类型复测。

Token reduction:只缩目标视频中段,并保留 full-resolution bypass
--token-reduction 最容易被误解成普通 resize。固定 README 与 h3_dit.c 显示,它只在 中间 DiT blocks 把目标视频后缀中横向相邻 token 两两配对。文本、音频、条件和参考 token 保持原长度,完整分辨率状态还会作为 bypass 保存。
恢复时,每个原 token 保留自己的原值,再加上配对分支学到的更新。它减少的是中间 block 处理的目标视频序列长度,不是把最终视频简单缩小后放大。
这种设计保留了单个 token 原有的高频差异,但配对分支只能学习共享更新,所以构图仍可能 偏离 close path。固定 README 的作者 A/B 中,45 layers + reuse 2 加 token reduction 后, 512 方形测试的 denoise 从 16.69 秒降到 12.60 秒。项目同时明确说明 composition 可能变化。
这组数字只能写成固定设备与固定测试下的作者报告。本文没有在本地复现,也不能把它外推 到其他 Apple 芯片、画布、参考媒体或长视频。
内部画布:模型少看像素,输出尺寸保持不变
--render-width 与 --render-height 会让 DiT 和 VideoVAE 在较小的同宽高比画布上运行, 最后再把 RGB 帧放大到请求的输出尺寸。文件分辨率仍可写成 512×512,但模型实际生成的 空间网格已经变小。
它优先损失文字、面部、小物体和精细纹理。这个代价与 token reduction 不同:后者保留 full-resolution residual,内部画布从模型输入阶段就减少空间网格,后续放大无法恢复没有 生成的细节。
因此,发布测试结果时必须同时记录 render size 与 output size。只写"512×512 输出"会 隐藏真正的计算条件。

组合开关时,误差不是简单相加
固定 README 留下了一个很有价值的失败样本:layers 40 + reuse 3 + token-reduction 的 组合出现色环、轮廓和重影肢体,即使 latent norm 仍可接受。
这说明内部数值没有爆炸,不等于视觉结果通过。三个开关分别减少深度、真实求值次数和 中间序列,叠加后可能同时削弱构图更新、运动连续性和局部恢复。单项在少量样本上可用, 也不能推出组合后仍可用。
组合实验应遵循两个顺序:
- 每次只改一个轴,先建立各自相对慢参考的差异。
- 只有单项通过后才测试组合,并把组合视为新的配置,不继承单项结论。

一张可执行的验收表
可复用的产物是一张每次运行都能填写的表:
| 字段 | 必须记录什么 |
|---|---|
| 固定输入 | commit、模型包、prompt、seed、参考媒体、帧数、输出与内部画布 |
| 计算预算 | steps、reuse 或 core-reuse、layers、token reduction、数值路径 |
| 阶段性能 | DiT、VideoVAE、AudioVAE、总耗时、峰值 live storage |
| 语义结果 | 主体数量、身份、构图、动作、镜头、音画关系 |
| 视觉失败 | 肢体、轮廓、色环、纹理、文字、细小物体、闪烁 |
| 对照 | 同输入慢参考、单变量差异、完整输出与关键帧 |
| 证据等级 | 项目作者报告、本地实验或生产观测 |
SSIM、latent norm 和总耗时都可以保留,但不能单独决定通过。视频还需要逐帧与运动检查, 音画模型还要检查声音事件是否与画面动作一致。

本文能确认什么
固定 8974cc0 可以确认这些开关的参数合同、互斥关系、源码中的保留路径和项目作者公开 的样本结果。它足以解释不同 fast 模式删掉了什么计算。
本文没有在本地 Apple Silicon 上运行权重,没有做盲测,也没有验证不同设备、长视频、 多参考输入或组合配置。所有速度与质量数字都保持 AUTHOR_REPORTED。本地效果是 NOT_RUN_H3C_LOCAL_RUNTIME,生产适用性是 UNKNOWN。
当一个 Runtime 暴露多个加速开关时,先问"它少算了哪个轴",再问"快了多少"。知道 被删掉的计算,才能选择对照、识别失败,并在结果变化时撤回正确的开关。

参考资料
- antirez/h3.c 固定源码:github.com/antirez/h3....
- 固定 README:github.com/antirez/h3....
- 固定公共参数:github.com/antirez/h3....
- 固定 DiT 实现:github.com/antirez/h3....
证据边界
- 参数、互斥、token reduction 与 active block 实现:
SOURCE_VERIFIED。 - README 中速度、SSIM、视觉结果和推荐档位:
AUTHOR_REPORTED。 - 六轴预算表与验收表:作者工程分析。
- 本地速度、画质、跨设备泛化和生产稳定性:
NOT_RUN / UNKNOWN。