h3.c 的 fast 模式到底删了什么：六个计算轴不能混成一个开关

很多推理工具把优化收进一个 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。