Sol-H3 Exact Runtime

If you run MiniMax-H3 locally, you already know the shape of the evening: a 33B omni-modal video model, one clip at a time, several minutes per run. Anything that shaves a percentage off that without changing what comes out is worth having. That's this node.

Sol-H3 Exact Runtime takes a MODEL and gives you the same MODEL with H3's affine modulation fused into a Triton kernel. No approximation, no quality knob, no sampler changes. The author's own matched production A/B on an RTX PRO 6000 Blackwell (SM120) measured 263.56 s → 247.30 s sampler time and 312.57 s → 298.69 s end-to-end, with peak VRAM unchanged at 17.18 GB. That's roughly a 6% sampler saving for one node dropped between your other model patches and the sampler.

Why "exact" is the interesting word

The sibling node in this pack, Sol-H3 SOL Attention, gets its speed by not computing all of attention. This one doesn't do that. It rewrites how H3's blocks apply their modulation - the per-token shift/scale and gate arithmetic around attention and the MLP - and checks that its output still matches the native math exactly.

Concretely, it replaces the forward of ComfyUI's native MiniMax H3 DiTBlock. RMSNorm, AdaLN, attention, MLP and the addcmul_ gate all stay native; only the modulation affine moves into a custom kernel that consumes explicit strides. Before trusting a new tensor layout, it clones the first rows, runs the original native math on that clone, and compares with a strict equality check - different layout, different key, so it re-verifies instead of reusing an earlier calibration.

It also fails closed, hard, which is the part worth internalizing. The node declines to run when the contract isn't clean: a block whose forward was replaced by another node, a block carrying forward hooks or a torch.compiled call impl, non-CUDA activations, autograd enabled, CUDA graph capture in progress. You get the untouched H3 block and no error.

Inputs and outputs

There's one input and one output, and no hidden settings:

• model (MODEL) - your base H3 model, after any other MODEL patches.
• Output: MODEL, which wires into the sampler or into a further patch node.

That's it. Order matters more than configuration: apply your model patches, then this, then sample. If you're also using the SOL attention node, exact_fusion=true (its default) already requests the exact runtime, and a second Exact Runtime node downstream merges into the same lifecycle instead of installing a duplicate - so the single-node route is the tidier graph.

Installing it

ComfyUI Manager will find it if you search the pack title, ComfyUI-Sol-H3 (publisher xmarre). Manually:

export COMFYUI_ROOT=/path/to/ComfyUI
cd "$COMFYUI_ROOT/custom_nodes"
git clone https://github.com/xmarre/ComfyUI-Sol-H3.git
cd ComfyUI-Sol-H3
python -m pip install -r requirements.txt

Use the same Python environment ComfyUI runs in - custom nodes share it with your whole install, there's no isolation, and that's where most "it installed but it won't import" pain comes from. On Linux the requirements pull triton>=3.6,<4, nvidia-cutlass-dsl[cu13], cuda-python and apache-tvm-ffi; on Windows those markers simply don't install, which is a hint about what follows. No Sana checkout, no SOL_ROOT, no PYTHONPATH surgery.

Where people get burned

Native Windows runs nothing here. The Exact path is a Triton kernel the author only production-validated on Linux/WSL2, so on sys.platform == "win32" the node is marked ineligible before the kernel is even imported; the untouched H3 block executes and logs exact:native_windows_unvalidated. The node stays in your workflow, does nothing, and doesn't say so loudly. If you're on Windows and expected a speedup, that's your answer - WSL2 on supported hardware.

Exact affine real-activation parity gate failed; disable exact fusion is a real, deliberate error. It means the kernel's output didn't match native math on live activations, which is the node catching something rather than corrupting your clip. Turn exact_fusion off on the SOL node (or bypass this one) and report it.

Packaged Sana source file set mismatch means the vendored Sana source your checkout carries has drifted - usually a local edit to files under sol_h3/_vendor. Update the checkout first; don't patch the vendored tree.

Allocator or comfy_aimdo errors are not evidence this node ran. Check the telemetry: on native Windows the expected state is sparse_calls: 0 plus exact:native_windows_unvalidated, meaning neither custom kernel path executed - debug the ComfyUI/AIMDO side instead.

SageAttention on Blackwell, if you stack it: use KJNodes' auto, not the Triton int8 path, and if you hit a GLIBCXX_3.4.32 not found ABI error, rebuild the package against the same Python/compiler/CUDA toolkit. LD_PRELOAD is not the fix, however tempting.

Leave this one on. It's the lowest-risk speed node in H3 land, and unlike a distilled speed LoRA it doesn't change a single pixel the model wants to produce - it just argues with the rounding, and wins.