ComfyUI 新增核心稀疏注意力节点与 Comfy 编译器

块稀疏注意力：一个节点，三个后端

新的 块稀疏注意力 节点（类别 advanced/model，标记为实验性）位于 comfy_extras/nodes_sparse_attention.py，并将每个查询块路由到仅已选择的键块子集。相对速度提升随序列长度增加，这正是 10 秒 H3 片段的范围。min_tokens 保护器会自动保持短序列为稠密状态。

同一节点中提供了三种选择模式：

• Sol-Attn (自适应 tau)：分数分布 Sigmas 中的每头自适应阈值。tau 1.0 保留约 16% 的键块精确值，1.5 约 7%，2.0 约 2.7%。这是无需特殊训练权重即可工作的模式。
• top-k (SLA)：所有地方固定 keep_percent 的键块。这与 lightx2v SLA 风格涡轮 LoRA 蒸馏所匹配的内容一致，因此仅推荐与这些训练权重一起使用。
• VSA (FastVideo)：具有粗略压缩分支的立方体平铺，匹配 FastH3-VSA 训练设置中的 10% 保留率。当存在时，它使用模型的 to_gate_compress 图层。

调度窗口（start_percent / end_percent，默认 0.2 到 1.0）保持早期去噪步骤为稠密，两个 H3 特定高级选项处理条件：sink_conditioning 精确关注打包的文本/音频/参考行（~3% 成本），以便提示和音频不会降级，而 extra_tokens 添加超出选定块的最高分 Token 以保持更接近稠密状态。

直到现在，此功能仅作为单独的社区节点包存在，社区测试表明没有匹配的稀疏后端，LoRA 本身无效。核心节点将这三种方法整合到一个界面背后，因此单个工作流可以通过更改一个组合框在 Sol-Attn、SLA 和 VSA 之间切换。

来自 PR #15861 的 Comfy 编译器基准测试：RTX 5060 上 MiniMax H3 720p 158 帧显示，一旦内存编译器激活，VRAM 占用稳定且迭代率高得多。

Comfy 编译器：更少的分配，更快的步骤

Comfy 编译器（PR #15861）是一个两层编译过程：

1. aimdo 内存编译器（在 comfy-aimdo 0.5.0 中）预先计算并最小化内存分配，将 CUDA 分配调用减少为一次性设置，并保持推理内存稳定和恒定。根据 PR，这消除了分配器抖动以及动态 VRAM 压力与 CUDA 报告数字之间的竞争，并确保物理 VRAM 峰值与逻辑分配峰值匹配，而不是让已释放的分配留在缓存中。
2. 上层是 CUDA 图。内存编译器产生的稳定虚拟地址使得图录制安全；同步仅在第一个 Transformer 块上需要。

实际效果体现在 PR 基准测试中：RTX 5060 上之前因无迭代活动而停滞的 MiniMax H3 720p 158 帧运行，在更改后每步完成时间约为 43 秒，而 MiniMax 音乐 3 AR 采样在同一卡上获得了约 35% 的步骤吞吐量。

全部模型中使用预取器的加上 MiniMax H3 都在初始合并中转换。WAN 列为未来工作，这将以相同方式提高其最大可行生成大小。

之前：H3 运行准备 19.9 GB 的分阶段权重，然后静默几分钟。更改后，相同的运行显示稳定的每步进度。

注意事项：早期 OOM 和取消崩溃

Banodoco Discord 中的社区测试在前几天标记了两个粗糙边缘。当 Comfy 编译器也激活时，稀疏运行可能会 OOM，而在加载稀疏节点时取消运行可能会导致 ComfyUI 崩溃。后续提交（#16148，“暂停 Comfy 编译器以进行长期稀疏分配”）已经解决了交互问题，并且 --disable-comfy-compiler 仍可作为回退标志可用。节点的稠密回退路径意味着如果序列落在调度窗口之外或低于 min_tokens，它只是运行正常的稠密后端，无需重新布线。

可用性

这两个功能都在当前 ComfyUI 构建中：块稀疏注意力节点需要 comfy-kitchen 0.2.33（已在 requirements.txt 中），而 Comfy 编译器是核心的一部分，带有 comfy-aimdo 0.5.2。最新安装不需要额外的安装步骤；使用 MiniMax H3 工作流的用户只需将节点放在模型加载器和采样器之间。