稀疏注意力：能力与发布状态是两回事

2026-08-09

截至 2026-08-09 的 MiniMax H3 仓库 README，「Model Architecture」章节里有两句话是挨着写的。第一句说：为降低长多模态序列的计算开销，H3 原生支持稀疏注意力的训练与推理。第二句紧跟着说：首次开源发布只提供 full attention 的推理，稀疏注意力实现将在未来更新中发布。

这两句必须一起读。只读前半句，会得到「H3 开源版支持稀疏注意力」；只读后半句，会得到「H3 不支持稀疏注意力」。两个结论都是错的，而且第一个错法在转述里出现得特别多——因为前半句听起来更像「亮点」，后半句听起来像「免责声明」，写摘要的人下意识就把后半句砍了。

这篇文章只做一件事：把「模型能力」和「当前发布状态」这两层拆开，并说清楚为什么你不能从中推出任何速度或显存结论。

一、这两句话各自在说什么

先把两层含义对齐。

说的是什么	README 的原话大意	你能据此做的判断
模型能力	H3 原生支持稀疏注意力的训练与推理	这条能力是模型设计与训练阶段就带的，不是事后外挂的补丁
发布状态	首次开源发布只提供 full attention 的推理	你现在拿到的开源版本，推理路径是 full attention
未来计划	稀疏注意力实现将在未来更新中发布	这是官方的计划表述，不是已经发生的事

再补一条 README 在 H3-Omni-Transformer 小节里给的时间线细节：native sparse attention 是在训练的最后阶段引入的，目的是降低长序列的计算开销；而该实现未包含在首次开源发布中，将来单独发布。

「训练最后阶段才引入」这一句信息量不小。它说明稀疏注意力在 H3 这里不是从头到尾贯穿的训练配置，而是在训练流程的后段进入的。至于为什么这么安排、这样做对模型有什么影响——官方没有展开，我们也不去猜。能确定的只有一点：这是模型训练侧的事实，跟你手上那份开源权重能不能跑稀疏推理，是两个独立的问题。

二、为什么 H3 这类模型特别在意注意力的计算成本

想理解「为降低长多模态序列的计算开销」这句话的分量，得看 H3 的序列是怎么攒出来的。

按 README 的数据流，H3-Base 先用各模态对应的 encoder 或 VAE 把不同模态编码好，再组织成一条统一的 packed multimodal sequence，整条序列在进入 H3-Omni-Transformer 之前用 RoPE 捕捉 token 之间的空间与时间关系。分工上，文本由 H3-Encoder 编码，视觉输入由 H3-Encoder 与 H3-VisualVAE 共同编码，音频仅由 H3-AudioVAE 编码。

也就是说，进 Transformer 的不是「一段文本」，而是文本、视觉、音频拼在一起的一条长序列。它有多长，取决于各模态各自压到什么程度：

视觉侧：H3-VisualVAE 是一个时间因果（temporally causal）视频自编码器，空间压缩 16×、时间压缩 4×、24 个 latent 通道，记作 f16t4d24。视觉 latent 进 Omni-Transformer 前还会再 patchify 一次，patch size 在 (time, height, width) 上是 1 × 2 × 2。两级叠起来，进入 Transformer 的视觉 token 有效空间下采样因子是 32×，时间下采样因子仍是 4×。
音频侧：H3-AudioVAE 对每个声道把 32 kHz 音频压成时间速率 40 Hz 的 latent token 序列；左右声道用同一套 encoder 与 decoder 但各自独立处理，解码后再合并。
位置编码：H3-Omni-Transformer 用三维多模态旋转位置编码（MM-RoPE）来表示时间与两个空间维度 (t, h, w) 上的位置关系。

注意视觉侧那个 1 × 2 × 2 的 patch——它只在高和宽上做了 2×，时间维上是 1，没有额外压缩。也就是说时间方向上的 token 数量，基本由 VisualVAE 的 4× 时间压缩决定。视频一长，序列就跟着长。再叠上一条 40 Hz 的音频 latent 序列和文本部分，这条 packed 序列的长度是很容易上去的。

注意力的计算成本随序列长度增长这件事，是所有做长序列的人共同面对的问题。官方那句「为降低长多模态序列的计算开销」，讲的就是这个动机。至于稀疏化之后能省多少——README 没有给任何数字，我们也没有部署过、没有跑过一次推理，所以这篇文章里不会出现任何加速比、吞吐、显存对比。任何号称「稀疏版比 full attention 快 N 倍」的说法，目前都没有官方依据可以支撑。

三、这对你现在的选择意味着什么

把上面的拆解落到实际判断上，有三件事可以确定：

第一，你现在跑的开源版本，推理路径就是 full attention。 README 推荐的推理框架是 SGLang、vLLM、diffusers 与 ComfyUI 四个，但稀疏注意力的实现根本没随首次开源发布放出来，所以换哪个框架都不会凭空多出一条稀疏推理路径。规划算力、评估可行性的时候，就按 full attention 这个前提来。别按「反正它支持稀疏，成本会低一截」去做预期管理——那个实现现在还没发布。

顺带说一句 ComfyUI 这一路的额外差别：它教程指向的权重是 Comfy-Org/MiniMax-H3，不是 MiniMaxAI/MiniMax-H3，扩散模型文件名里带 pruned_int8_convrot、文本编码器带 nvfp4_awq，而 MiniMax 官方 README 说自己发布的 checkpoint 精度是 BF16。两边权重形态本来就不是一回事，评估的时候别把两边的结果混着看。至于哪边更好——没有任何公开对比数据，这里不给结论。

第二，「跑得动吗」这个问题，只能引用官方给的示例配置，不能靠算。 README 的部署示例里，SGLang 的启动命令用的是 --num-gpus 4，也就是官方示例使用 4 GPU 配置。这句话的准确读法是：官方给了一个 4 GPU 的示例，README 并没有说这是最低要求，也没有给出任何显存数字。想据此往上或往下推算「几张什么卡够用」，没有依据。

第三，别把架构参数当成性能计算器。 仓库里 transformer/config.json 那张表是公开的硬参数——num_layers 50、num_attention_heads 56、attention_head_dim 128、hidden_size 5376、ffn_dim 14336、patch_size [1, 2, 2] 等等。这些数值之间可以互相印证（比如 patch_size [1,2,2] 与 README 的 1 × 2 × 2 对得上，16 × 2 = 32 与「有效空间下采样 32×」也对得上），但它们不构成任何显存或速度的换算依据。

顺带说一个同样反直觉、同样属于「读错就全错」的事实：H3-Omni-Transformer 是 33B 参数的 dense 单流 Transformer，其中约 13B 参数位于 AdaLN 相关分支；因为 AdaLN 调制输出可以预先计算并缓存，这些参数在「仅推理」的部署中不需要加载。官方发布完整权重是为了支持包括微调在内的后续开发。这条同样只能用来纠正「33B 就等于要装下 33B」的直觉，不能据此换算出具体需要多少显存——官方没给这个数字。

四、「能力 ≠ 发布状态」在 H3 这里不止一处

稀疏注意力不是孤例。同一份 README 里还有别的地方符合同一个模式，看懂一处，其余几处就都能自己判断：

H3-Regenerate-2K：官方讲了它的做法——对 2K 输出不使用传统的专用超分模块，而是让 H3 基础模型以 in-context 的方式重新生成自己的低分辨率结果，好处是能最大程度复用基础模型的生成能力，并复用原始多模态上下文、从而恢复传统超分方法只能「猜」的信息（例如小字与精细细节）。但这个模块尚未开源，官方提供 API 用于验证官方结果。
H3-Context-IR：同样属于完整 H3 系统的一环，走的是官方 API 路径，未开源。

所以读 H3 的文档时，可以固定用两个问题去过一遍每一项能力：这是模型层面具备的能力，还是当前这份开源发布里可运行的东西？ 前者写在架构章节，后者要去看发布说明、仓库文件树和部署章节。这两处对不上的时候，以后者为准——你能跑的只有已经发布的部分。

五、以后怎么核对状态变没变

「将在未来更新中发布」是一个会过期的状态描述。本文的核对日是 2026-08-09，之后它随时可能变。如果你以后需要确认稀疏注意力实现是否已经放出来，靠翻 config 里的键名去猜不是个好办法——config 只给了数值，猜不出发布状态。可靠的做法是回到一手位置去看：

MiniMax-AI/MiniMax-H3 仓库 README 的 Model Architecture 章节，那两句话本身有没有改写；
仓库的发布说明与文件树，是否出现了对应的推理实现；
你实际用的那个推理框架侧的文档——README 给的四个入口分别是 SGLang（docs.sglang.io 的 cookbook 路径 /cookbook/diffusion/MiniMax/MiniMax-H3）、vLLM（recipes.vllm.ai/MiniMaxAI/MiniMax-H3）、diffusers（minimax-h3 分支下的 docs/source/en/api/pipelines/minimax_h3.md）、ComfyUI（docs.comfy.org/tutorials/video/minimax/minimax-h3）。

顺便提醒一句 diffusers 侧的坑，它跟「发布状态」是同一类问题：仓库 requirements.txt 的官方注释写明，官方文档引用的是 diffusers 的 minimax-h3 分支，并给出安装方式 pip install "git+https://github.com/huggingface/diffusers.git@minimax-h3"，注释里说等它落到 PyPI 再收紧版本上界。换句话说，直接装 PyPI 版的 diffusers，可能根本没有 H3 的模型类。功能存在于某个分支，和功能已经进入你 pip install 装到的那个包，是两件事——和稀疏注意力那两句话，是同一种阅读错误。

六、一句话收口

「H3 原生支持稀疏注意力的训练与推理」是模型能力的陈述；「首次开源发布只提供 full attention 的推理」是发布状态的陈述。写文章、做技术选型、给团队做汇报的时候，这两句要么一起出现，要么一句都别引。中间那种只留半句的写法，不管有意无意，都会让读者按一个不存在的前提去做决定。

延伸阅读

本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README、模型配置文件与官方 h3-prompt-writing skill 文档整理，核对日 2026-08-09。本文内容为官方仓库口径，未在本机部署或调用过 H3。模型、部署方式与许可条款以官方最新说明为准。