JR H3 VEDA Attention (Experimental)

H3 at 1.5 MP and fifteen seconds is a pile of attention. Sparsity is the standard answer: stop attending to all of it. VEDA - the official Veda-on-ComfyUI sparse-attention path - predicts which visual key tiles matter and skips the rest, and this node is the adapter that bolts it onto a native H3 MODEL.

To be clear on what this is: it is not VEDA. It doesn't bundle the kernels or download the predictor - it resolves the official node at execution time, calls it on a clone of your model, then attaches guards so you can't quietly stack it on three other attention patches.

Dependencies are most of the story

Skip this and you'll get a clean error, which is at least honest:

1. ComfyUI ≥ 0.38.0.
2. Official Veda-on-ComfyUI installed (ComfyUI Registry ID veda-sparse-attention) and ComfyUI restarted. The JR node looks it up by registered node ID at run time, so a missing install fails at execute, not at import.
3. The predictor weights in models/veda - for the first version, minimax_h3_t2va_veda_8nfe_600step_preview_fp8.safetensors, published by Veda-Sparse on HuggingFace. The dropdown lists whatever .safetensors is in that folder; if the folder isn't registered you'll only ever see the default name.
4. KJNodes if you want the low-VRAM attention and FFN chunking (both default on), and KJNodes plus the matching SageAttention build if you explicitly select a Sage mode for the dense fallback.

Nothing here is auto-installed or vendored, the same policy the pack's Sol/Sage path follows. Missing pieces stop this node, not the rest of the pack.

Inputs that matter, and one that doesn't

model and enable are the obvious pair; enable = false passes your model straight through before any dependency check, which makes it a safe way to A/B without uninstalling anything.

Then predictor, and the two sparsity knobs. generated_sparsity defaults to "90%" - skip 90% of the visual key tiles. A bare integer means something different: 32 keeps that many tiles. reference_sparsity is the same idea for the visual references you conditioned on, and 0% keeps them dense, which is the sensible first move if you're protecting a face or a product shot. Text and audio tokens stay dense in VEDA regardless, so dialogue and audio guidance aren't part of the trade.

full_attention_layers and full_attention_steps take 0-based lists like 0,1,47-49 or 0 - the layers and steps where you refuse to be sparse; leave them empty and you're sparse everywhere. verbose turns on the upstream run statistics. sage_attention is the dense fallback only, with disabled meaning "use whatever attention ComfyUI is configured with"; the eight explicit modes need KJNodes and the right Sage library, and compile is forced off. head_chunks (4, max 56), ffn_chunks (4, max 64) and ffn_seq_threshold (4096) tune the low-VRAM passes, which are on by default and chunk heads/FFN to keep activations down.

Outputs are simply model and status.

Wiring

H3 loader -> LoRA / sigma config ─┬─> Unified V2 / Core Sol-H3 -> sampler
                                  └─> JR H3 VEDA Attention     -> sampler

One branch per comparison run, and never VEDA stacked with Unified/Sol - the guard fails loudly if VEDA is already installed on the model, if the input carries an attention override, DiT block replacements, forward patches or Core sparse callbacks, if Sol-H3/TST is present, or if a TST/Streaming/Cache wrapper is attached. It re-checks at on_pre_run, so a downstream node that swaps the attention stack gets an error instead of a silent downgrade. Native ModelSamplingMiniMaxH3 SigmaShift is fine on either side - it swaps the sampling schedule, not attention - so LoRA → VEDA → SigmaShift → BasicGuider → SamplerCustomAdvanced is a legal layout.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Goldlionren/ComfyUI_JR_MiniMaxH3Node.git
python -m pip install -r ComfyUI_JR_MiniMaxH3Node/requirements.txt   # same Python ComfyUI runs on
git clone https://github.com/veda-sparse/Veda-on-ComfyUI.git        # the actual sparse-attention node

Restart both, hard-refresh the browser, and drop the predictor into models/veda.

Where people get burned

• Status is configuration, not evidence. The status string tells you what you asked for. Whether sparse attention actually ran is in the node's running/done text and the verbose sparse-vs-dense counters - a dense fallback looks exactly like success if you only read status.
• This is unverified performance, and the author says so. Interface and import binding were tested against a production VEDA install; a full GPU quality and speed acceptance against Core Sol-H3 was not. Treat "VEDA is faster" as unproven and A/B it yourself with fixed seed, model, LoRA, conditioning, sigma, steps, resolution, frames and decode path.
• Memory isn't inherited. VEDA receives full QKV, so it doesn't get Core Sol-H3's producer-side VRAM advantage. Sparser attention is not automatically a smaller footprint.
• 8NFE in the filename is not decoration. That predictor is for a roughly eight-step regime; pairing it with a 20-step schedule isn't what the checkpoint was built for.
• The newer R2VA predictor errors out. A fixed-tile R2VA predictor appeared on 2026-10-09 whose metadata the installed VEDA loader can't read (keep_ratio missing). You get a descriptive error and no invented budget - stick with the T2VA predictor for now.