H3 Sparse Attention (Advanced)

The plain H3 Sparse Attention node gives you one budget and a quality-recovery toggle. The Advanced version is the same trick with the schedule exposed: you decide how much attention gets cut at each point in the denoising run, and you get to pick the backend doing the cutting. Reach for it when the simple node's defaults produce drift and you want to control exactly where attention survives - otherwise start with the non-advanced node and save yourself the knobs.

The core idea is that where you cut attention matters as much as how much you cut. H3 is especially sensitive to reduced attention in the first sampling steps, where the coarse structure of the video is being decided. So instead of one flat budget, you get three windows:

• video_budget (default 0.3) - the budget for the middle steps, the bulk of the run.
• early_steps / early_kv - the first N steps run at their own density (defaults: 2 steps at 50%).
• late_steps / late_kv - the final N steps at their own density (defaults: 2 steps at 50%).

That default shape is the sensible one: keep the middle loose for speed, hold more attention at the edges where it matters. If the windows overlap, the denser of the two requested edge budgets wins. Raise early_kv toward 1.0 when you see prompt or timeline adherence collapse in the opening frames; that's the exact lever the simple node's denser_early_late_steps approximates.

The second difference is the backend combo. auto follows the same fallback chain as the simple node - native INT8 kernel, Sparse Sage, INT8 Triton, FlexAttention, then dense. The explicit choices (Kitchen INT8 geometries at 64x64, 128x128, 128x64, plus experimental "Sol" arms) are hard requirements: pick one and it errors if that backend isn't available, rather than silently switching. That's deliberate - auto exists so you can stay safely hands-off; explicit selection means you're reproducing a specific experiment or your Sparse Sage install is exactly what you want to force. The README is clear that auto never picks the Sol residual arms, which cost sampler time without visible improvement in their tests; they're there for reproducing research, not for daily use.

Output is a patched MODEL into your sampler chain, and the node reports the selected backend and any fallback reason in its status text.

Install and gotchas

Same pack, same story: ComfyUI Manager search "H3 Optimizations", or clone https://github.com/Zironic/H3-Optimizations into custom_nodes and restart. No pip dependencies, native binaries shipped prebuilt.

The two ways people trip on this node: selecting an explicit backend they don't actually have installed (the node errors - switch back to auto), and over-tightening early_kv, which is exactly the window H3 is most fragile in. And remember the bigger picture: no sparse budget is lossless for every prompt. If you set an explicit backend or aggressive window and the result changes, that's the mechanism working as designed - bypass the node entirely to force dense attention and confirm.