RuntimeError: aimdo memory compile error` from `malloc_graph_pause()`.

快速结论：在启用 aimdo（comfy-compiler）后，于工作流中使用分段生效的 Block Sparse Attention 等自定义注意力节点时，内存分配图会反复 break 并累积，最终显存不足（OOM）；部分场景直接报 RuntimeError: aimdo memory compile error from malloc_graph_pause(). 优先排查 aimdo 版本、是否有修复版 PR、以及能否用 --disable-comfy-compiler 规避。

适用环境：Issue 已确认/出现的环境包括：Linux（另有 Windows 报告）、Python 3.14.7、Torch 2.13 + CUDA 13.0、RTX 4060 8GB + 16GB RAM、RTX 4090 24GB + 128GB RAM、4070Ti Super；comfy-aimdo 0.5.2、comfy-kitchen 0.2.33；自定义节点涉及 KJNodes 的 Block Sparse Attention（Sol-Attn）、`ModelAttentionBackend`、`MiniMax H3 Chunk FeedForward`。模型为 MiniMax H3 系列（kijay 4bit w4a8 fl2va、Spark-H3 块稀疏补丁）。

最快修复方案：暂无确认的一步修复方案。Issue 中实际生效过的规避方式是启动时加 --disable-comfy-compiler（关闭 comfy compiler/aimdo 路径），有用户反馈显存占用降到约 5.7GB/8GB 且不再 OOM。另有用户在本地按 reviewer 建议移动 patch.vsa_rope_freqs() 调用位置后 graph breaks 大幅下降，但这属于源码改动，并非官方已合并的修复。

注意事项：关闭 comfy-compiler 会牺牲 aimdo 带来的显存利用率；该做法只是规避，不代表根因修复。#16148 合并后仍有用户报告未彻底解决，尤其调整 Block Sparse Attention 的 start/end 值（如 end=0.9）时仍 OOM。修改源码前请先备份，并确认与当前 master 是否一致。

问题场景

用户在 ComfyUI 中运行 MiniMax H3 视频生成工作流，使用 kijay 的 4bit w4a8 fl2va 模型、Sage Attention 模型预览，并接入 KJNodes 的 Block Sparse Attention（int8 Sol-Attn）节点。当该稀疏注意力节点开始生效（约第 5 步）后，显存占用逐步上升直至 OOM。绕过 / 旁路 Block Sparse Attention 节点时，即使显存接近 8GB 满载也能正常完成生成。

后续报告显示该问题不限于低显存：24GB 的 RTX 4090 上同样出现 graph breaks 大量增长；在带 tiled 高分辨率第二遍的 MiniMax-H3 + Spark-H3 块稀疏补丁图中，graph breaks 计数逐步上升（48 → 54 → 104 → 154），最终以 RuntimeError: aimdo memory compile error from malloc_graph_pause() 结束而非 OOM。

报错原文

RuntimeError: aimdo memory compile error` from `malloc_graph_pause()`.

相关日志中还出现 OOM 请求 1.36 GiB、而当时仅剩 2.82 GiB 可用，用户判断为显存碎片化而非单纯耗尽；以及 graph breaks 数量异常增长。

原因分析

根据讨论，可能原因如下：

aimdo / comfy-compiler 的分配图（类似 CUDA graph 的记录与回放）在遇到 Block Sparse Attention 这类在不同步数才激活、切换执行路径的节点时，会把每一步视为不同路径，持续产生新的分支与 graph breaks，导致分配记录不断累积，最终 OOM。
PR #16148 合并后仍有遗留路径：用户分析指出 patch.vsa_rope_freqs() 会分配并缓存一个 padded tensor，且该调用位于 pause_malloc_graph() 作用域之外；当工作流在不同 token 数下二次采样、构建第二个 VSA plan 时，会产生 rogue allocation（游离分配）。把该调用移入 pause_malloc_graph() 作用域后，graph breaks 从 156/199 降到 12/9，且更高 token 数也能跑完。
有用户实测关闭 comfy-compiler 后显存回落且无 OOM，侧面印证问题出在 aimdo/compiler 的分配图路径，而不是稀疏注意力节点本身。

环境排查

确认 comfy-aimdo 版本（报告中为 0.5.2，有用户表示 0.4.15 时无此问题）。
确认 ComfyUI 是否为最新 master，以及是否已包含 #16148 及之后的提交（如 a99d1f9c）。
确认 comfy-kitchen 版本（报告中为 0.2.33）。
确认 Torch 与 CUDA 版本（报告中为 Torch 2.13 + CUDA 13.0）。
确认显卡与显存/内存（RTX 4060 8GB、RTX 4090 24GB、4070Ti Super 均有出现）。
确认是否启用了自定义注意力节点及相关节点：Block Sparse Attention（Sol-Attn）、`ModelAttentionBackend`（comfy kitchen attention）、`MiniMax H3 Chunk FeedForward`、Spark-H3 块稀疏补丁。
确认 Block Sparse Attention 的 start/end 参数取值，以及工作流是否存在多次采样/不同 token 数。
确认启动参数是否包含 --lowvram、--vram-headroom、--reserve-vram 等显存相关选项。

解决步骤

先排查是否由自定义节点触发：按 Issue 记录，绕过 / 旁路 Block Sparse Attention 节点后生成可正常完成，可作为对照验证。
可优先尝试规避：启动 ComfyUI 时加 --disable-comfy-compiler，关闭 comfy compiler/aimdo 路径。有用户实测显存占用显著下降（8GB 中约 5.7GB），生成速度接近且不再 OOM。
调整 Block Sparse Attention 的 start/end 参数做对照：将 end 设为 1 时同一渲染可完成，设为 0.9 时会 OOM；也有用户将 start_percent 设为 0 或 0.2 进行测试对比。
更新到已包含相关修复的 ComfyUI 版本；但注意 #16148 合并后仍有用户反馈未完全解决。
如需在本地验证 reviewer 的建议改动（非官方合并方案）：在 patch.vsa_rope_freqs() 相关逻辑中，将 freqs = patch.vsa_rope_freqs(rope_freqs, plan) 移入 pause_malloc_graph() 作用域内（即在 n = plan["n"] 之后调用），并从下方 if patch.vsa: 块中移除该调用。此改动需自行备份，且仅基于用户反馈。
若仍持续崩溃，可收集 graph breaks 计数、报错堆栈与显存曲线，反馈到原 Issue 或关联 Issue #16150 / PR #16148。

验证方法

使用相同工作流与参数重新生成，观察是否不再出现 aimdo memory compile error from malloc_graph_pause()，graph breaks 计数是否不再持续增长；显存占用是否稳定在可控范围而非逐步爬升；原本会 OOM 的长帧数渲染（如 277 帧、end=0.9 的场景）能否完整跑完。