H3RelayInternalFastH3VSA

This is one of those one-in-one-out nodes that looks boring and is quietly doing the hardest engineering in the pack. H3RelayInternalFastH3VSA takes a MODEL in and hands a MODEL back - but that hand-back is where H3 Relay installs its locked MiniMax VSA adapter, converting a dense H3 diffusion model into one that runs through Sol-Attention's VSA layout at ~90% sparsity. That's the entire trick behind the experimental FastH3 path: a distilled four-forward checkpoint that generates much faster than stock H3 because it never computes most of its attention.

It's an internal node. You'll find it under the pack's /internal category, but its real home is inside the expanded subgraphs H3 Relay builds for you - Generate Shot uses it when you run the FastH3 VSA profile, and the H3 Ultimate 2× Enhance graph wires it in after the sigma shift and before the MMH3 engine. Registering it as a normal node is what lets those expanded graphs reopen cleanly. For a user, "understanding" it mostly means understanding the three ways it can fail, because it fails loudly and by design.

The mechanism, in one paragraph

FastVideo distilled FastH3 against a VSA (variable-sparsity attention) layout built out of 4×4×4 video cubes, keeping only ~10% of video blocks routed per forward. Because the checkpoint was distilled against that sparse contract, there is no "dense fallback" - running it dense would just be the wrong model. So this node clones your model and patches every transformer block's attention to route through comfy-kitchen's Sol-Attention CUDA backend, with H3 Relay's own narrow MiniMax adapter (it deliberately does not use the temporary SolAttnMiniMax test node). It validates the contract up front: the model must be a MiniMax H3 diffusion model with to_gate_compress, head dim 128, and no conflicting pre-existing patch - otherwise it errors out rather than silently generating with the wrong attention.

The real requirements - this is where people get burned

Nothing about this node works on a stock install, and the pack says so plainly. It needs:

• the official comfy-kitchen CUDA wheel, version 0.2.33 or newer, with the sol_attn backend and a CUDA device of compute capability 8.0+,
• a ComfyUI build with FastVideo-VSA model support (ComfyUI PR #15958 is still unmerged, so the reference environment pins Kijai's VSA-capable commit rather than assuming stock ComfyUI),
• the FastH3 VSA checkpoint itself - Kijai's INT8 ConvRot repack of FastVideo's 1300-step, four-forward data-free VSA preview (minimax_h3_fastvideo_vsa_datafree_1300step_4step_int8_convrot.safetensors, exact filename enforced).

The validation record is refreshingly narrow: tested on an RTX 4090 running Linux with comfy-kitchen 0.2.33; Windows GPU inference is unvalidated and upstream Sol-Attention edge cases still have known failures. FastVideo itself documents the preview checkpoint as text-to-audio-video only, so reference and sliding-continuation use are experimental inherited behavior, not a supported contract - keep the standard FL2VA/Ref2VA profile as your fallback until a reference-distilled FastH3 release lands.

What to do about it

Treat it like you'd treat any /internal node from this pack: don't hand-wire it, don't delete it from saved workflows, and if ComfyUI flags it as missing, the fix is installing or updating the pack (ComfyUI Manager, search H3 Relay, or git clone https://github.com/akatz-ai/h3-relay into custom_nodes), then restarting. If you are chasing FastH3 speed and you hit this node's error text - "requires the official comfy-kitchen CUDA package," "requires compute capability 8.0+," "sol_attn unavailable" - it's not a bug in your graph. It means the environment the README warns about isn't set up yet. Follow the comfygit_fast_h3_environment/ recipe in the repo rather than improvising, and only move to the FastH3 profile once you've confirmed the VSA runtime actually loads.