MonarchRT Runtime

Most nodes in ComfyUI are dumb in the best way: they take your model, do a thing, hand it back. This one is dumb in a different way - it does almost nothing. It picks a name off a list and passes it down the wire. But that nothing is load-bearing, because MonarchRT is the one pack where the generation does not happen inside ComfyUI's Python.

What it is actually for

MonarchRT is a research attention method - it swaps the dense self-attention in a video diffusion transformer for Monarch-matrix ("structured sparse") attention, with fused Triton kernels, from Infini-AI-Lab. The training-free route (all this pack runs) applies it at inference to the public Self-Forcing DMD checkpoint, which is Wan2.1-T2V-1.3B based. Self-Forcing is the autoregressive streaming setup the Wan community already knows; the KB's Wan writeup covers why the 1.3B tier is fast but visibly weaker than 14B.

None of that can run in ComfyUI. Upstream needs Triton, flash-attn 2 (there's no SDPA fallback in the cross-attention path), FlashInfer, and a pinned checkout. So the pack runs the pipeline in a separate runtime - a WSL2 distro on Windows, or a plain venv on Linux - and ComfyUI just drives it. The Runtime node is the handshake.

That's also why the node can't let you type a path. The README is explicit that workflows cannot name executables or commands; runtimes come from an administrator file, ComfyUI/user/monarchrt.runtimes.json. If a node graph could spawn arbitrary processes, every shared workflow would be a remote code execution vector. This is the sane design.

Inputs and output

One required input, one optional, one output:

• runtime_id - an enum listing the runtimes registered in monarchrt.runtimes.json. If nothing is configured, the only choice is literally (no runtime configured).
• backend (optional) - runtime default, persistent, or one-shot. runtime default means whatever the admin put in the config entry, and that's one-shot unless they said otherwise.
• runtime - a MONARCHRT_RUNTIME, wire it into the runtime input of MonarchRT Generate.

The two backends are the whole decision here. one-shot starts a fresh process per queue job, so you pay model load and Triton autotune every single time. persistent keeps one warm worker between jobs - model and tuned kernels stay on the GPU until the idle timeout (default 300 s), an unload, or ComfyUI exiting. On the reference machine that's the difference between ~195 s per job and ~10-12 s. It's not a subtle tuning knob, it's a 20x wall-clock difference for iterating.

Install

The node half is trivial; the runtime half is the project.

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

Or search MonarchRT in ComfyUI Manager (the registry listing is "MonarchRT for ComfyUI"). Note what this does not install: the pack declares zero Python dependencies for ComfyUI itself, and the heavy stack lives only in the runtime. It does require ComfyUI ≥ 0.38.0.

Then the real work, paraphrased from docs/SETUP.md:

# inside WSL2 or on the Linux host
uv venv --python 3.10 /opt/monarchrt/venv
# torch 2.8.0+cu128, then the flash-attn 2.8.3 and flashinfer-jit-cache 0.6.3 wheels
# from the GitHub releases listed in runtime/requirements-reference.txt
uv pip install --python /opt/monarchrt/venv/bin/python -r requirements-reference.txt
git clone https://github.com/Infini-AI-Lab/MonarchRT /opt/monarchrt/MonarchRT
git -C /opt/monarchrt/MonarchRT checkout 34867c041ff7d70c699a9149f84857058d8ada92

Then the ~23 GB of weights (Wan2.1 T2V 1.3B at a pinned revision plus self_forcing_dmd.pt), then copy examples/monarchrt.runtimes.example.json to ComfyUI/user/monarchrt.runtimes.json, fill in distro, python, upstream_dir, models_dir, checkpoint, and restart ComfyUI.

Where people get burned

(no runtime configured) is the whole error message. It means the config file is missing, malformed, or wasn't there when ComfyUI started. The path can be overridden with the COMFYUI_MONARCHRT_CONFIG environment variable, which is what you want if you keep ComfyUI configs somewhere tidy. Restart after editing; the node reads the file, not the workflow.

Triton wants a C compiler. The first kernel launch compiles a small C launcher. sudo apt install build-essential covers it; without system packages there's a zig wrapper documented in SETUP.md. If you skip this, nothing tells you until a job dies - which is exactly why the Doctor node exists, so run that first.

Persistent is not free. A warm worker idles at about 18 GB of GPU memory and 14-16 GiB of RAM. Pick one-shot for one-off runs and persistent when you're actually iterating, and stop the worker when you want the card back.

Set offload_text_encoder: true under 40 GB of VRAM. The 11 GB UMT5-XXL encoder otherwise sits on the card and your 24 or 32 GB GPU ends up spilling into shared system memory, which is slow in a way that looks like a hang.