SparkDiffusion Runtime

The most important thing to understand about this pack is that it does not run inside ComfyUI. There's no SparkDiffusion loaded into ComfyUI's Python, no torch import at startup, no weights in your models folder. What you get instead is a set of nodes that write a little job file and start a separate Python process in its own environment, where the actual AlibabaResearch SparkDiffusion code runs. The Runtime node is where you tell it which second Python that is.

That design is unusual and it's the whole point. SparkDiffusion wants Triton ≥ 3.4, a CUDA 12.8+ PyTorch build, and FP8 W8A8 kernels - exactly the kind of requirements list that, installed into ComfyUI's environment alongside thirty other custom nodes, breaks everything. So the pack keeps it out. requirements.txt in the repo is deliberately empty.

What you actually set here

Four required fields, in order of how much you'll care:

• backend - auto, windows-native, wsl2, or linux. auto picks Windows-native on Windows and Linux elsewhere. If you're on Windows with an RTX 40/50 card, override it to wsl2: upstream's row-wise FP8 GEMM doesn't exist in Windows PyTorch builds, so WSL2 is the only place you get the exact upstream path.
• quantization - fp8 (default) or bf16. FP8 is upstream's W8A8 quantization on the FFN and all attention projections and it's a big part of the speed. bf16 is the escape hatch when FP8 misbehaves.
• fused_kernels - on by default. These are upstream's Triton inference kernels for RoLA sparse attention. Turning them off isn't a free simplification: it needs an external thu-ml/SLA checkout, and the node will refuse the combination if you don't give it one.
• torch_compile - the one that surprises people, because it defaults to off while upstream always compiles. Reason: every ComfyUI run spawns a fresh runtime process and pays the compile cost again. On the author's 5090, a 14B 720P 3-step run takes 54 s of denoise uncompiled versus 93–228 s compiled - but the second video in the same process drops from 39 s to 21.6 s. So: leave it off for one-off runs, turn it on together with num_videos ≥ 2.

The path fields

sparkdiffusion_repo, python, model_root, wsl_distro and sla_src are strings. Leave them blank and the node falls back to the environment variable, then to sparkdiffusion_config.json next to the README. Resolution order is node field > env var > config file, which is nice: nothing about where your models live ends up baked into a shared workflow JSON.

fp8_compat is the Windows compromise - auto emulates row-wise FP8 with a tensor-wise GEMM plus an epilogue when the PyTorch build lacks the real thing, off makes it fail loudly instead, force forces the emulation. And timeout_seconds defaults to 3600, with 0 meaning no timeout.

The single output is runtime (type SPARKDIFFUSION_RUNTIME), and there is exactly one thing to do with it: wire it into SparkDiffusion Text To Video, Image To Video, or Doctor.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/hiroki-abe-58/ComfyUI-SparkDiffusion

Or via Manager: search SparkDiffusion and restart. Neither method installs a single package into ComfyUI's Python. Then build the runtime separately - on Linux/WSL2 that's a venv with a CUDA PyTorch and requirements-runtime.txt, plus a clone of the upstream SparkDiffusion repo.

Where people get burned

Three things. First, expecting the nodes to do anything before the runtime exists - they won't; the node is a launcher. Second, one process per run: every generation reloads the umT5 encoder and, for 14B, the checkpoint plus FP8 conversion. That's the pack's top roadmap item, not something you misconfigured. Third, VRAM: 14B profiles want roughly 24 GiB free, 28 GiB for I2V 720P. If your steps crawl and VRAM sits at 100%, you're spilling to system RAM, not hitting a bug. Run the Doctor node before you blame anything else.