FLUXSPIKEY

FLUXSPIKEY is the master switch for the two speed tricks in the FLUXNATION pack: block-sparse "spike" attention and step caching. FLUXNATION is a fused FP8 CUDA kernel for FLUX.1 that replaces ComfyUI's SingleStreamBlock, and it activates on its own at startup - these nodes are how you control it without restarting ComfyUI. FLUXSPIKEY is the light switch. Wire a MODEL in, flip the two booleans, and the same MODEL comes back out. Nothing else happens at this node; the work happens inside the patched forward pass it's telling the kernel to use.

The two inputs are the only two it has:

• spike (default true) - toggles block-sparse spike attention. With it on, once the denoise passes switch_pct of its steps, each attention layer stops computing full attention and instead scores its 32-token blocks by dot-product similarity, computes only the top fraction, and skips the rest. The README claims ~90% of attention FLOPs disappear on those steps, and the whole point of the mechanism is that image structure is already locked in by the time it engages.
• step_cache (default true) - toggles step caching. When both are on, spike steps alternate: one step computes spike attention and fills a cache per SSB block, the next step replays that cached output with zero attention compute. The alternating pattern is why the 20-step runs on the README's benchmark drop to ~9.3s from ~13–14s stock on a 4090. Turn this off and you get the sparsity savings but lose the replay savings.

So why would you ever flip either off? A few real reasons. The first is quality forensics: if a generated image looks subtly off, the fastest test is to set both to false, rerun with the same seed, and see whether the difference is in the spike path or the fused kernel itself. The second is benchmarking - this is a "no fallbacks" pack; if the kernel path has a bug, it crashes rather than silently degrading, so A/B testing against stock is the standard way to confirm you're not the bug. The third is low-VRAM: the pack ships a separate run_nvidia_gpu_spike_lowvram.bat profile for 8–12GB cards that cranks spike to aggressive settings, and the README is upfront that the quality trade-off is real there. If you're on that profile and something looks rough, this is the node where you dial the aggression back.

There's also a stability angle worth knowing. The kernel's history is a single visible commit titled "Fix Triton kernel hang when block_count=0" - the block-scoring path had a way to end up with zero selected blocks per head, and a hang is exactly the failure mode you don't want mid-generation. If you ever hit a stall that smells like Triton, spike off is your immediate escape hatch, and the guard logic (force at least the top-scoring block per head) is what the fix added.

Install is the pack install, which is genuinely fiddly and worth repeating because it's the same for every node here. It is not a one-command ComfyUI Manager install you can count on. The README path:

git clone https://github.com/ULT7RA/cuda-kernels.git
# copy FLUXNATION/custom_nodes/FLUXNATION/ -> ComfyUI/custom_nodes/FLUXNATION/
cd FLUXNATION
build_ext.bat

The build needs Visual Studio 2022, CUDA Toolkit 12.x, and Python 3.10, and it compiles specifically for SM 8.9 (RTX 4090-class Ada) - setup_ext.py hardcodes -arch=sm_89, so other cards need the script edited. It also expects CUTLASS headers in cutlass/include that the repo doesn't ship, so budget for fetching those. There's no requirements.txt; it relies on the torch and Triton already in your ComfyUI environment. The recommended launch sets FLUX_SPIKE=1 FLUX_SPIKE_SWITCH=0.50 FLUX_SPIKE_CAP=0.45 FLUX_SPIKE_TAU=0.05 FLUX_SPIKE_CACHE=1 before starting ComfyUI, and the kernel engages at startup whether or not a node is in the graph. The env vars set the default; this node overrides it live.

One thing to know before you trust it: this pack is new, single-author, and essentially unvalidated. The announcement thread on r/StableDiffusion (April 2026) drew a skeptical crowd - the few replies called it self-promotion and questioned whether the account was a bot. The kernel is genuinely impressive in concept and the code is readable, but treat FLUXSPIKEY as a switch for an experiment, not as infrastructure. Verify output quality at your own settings before you rely on it for real work.