Nodes/Anima Block Compile/Anima Block Compile
ComfyUI Node

Anima Block Compile

Anima is slow for its size — this node compiles it one transformer block at a time

By sorryhyun·Created 2 months ago·Updated 2 months ago· 1
Anima Block Compile
  • model
  • MODEL

Here's the thing nobody warns you about before you switch to Anima: it's a 2B DiT and it still feels slow. The community's own timing table puts it at ~10s per image on a 5090 and over a minute on a 4060, at 30–50 steps. It's fast to train, famously, but inference punches below its weight. This node is the speed knob that fits Anima specifically - it applies torch.compile the way Anima's own training pipeline does, one transformer block at a time, instead of compiling the whole DiT in one giant frame.

Anima Block Compile (AnimaBlockCompile) is exactly one node with exactly one input and one output. You drop it between your model loader and your sampler, and it hands back a cloned MODEL with a compile wrapper installed. There are no knobs, no backend picker, no mode dropdown. It always uses the inductor backend with default settings, applied per block - and per the author, that's deliberate: per-block compile is what makes the aggressive mode/fullgraph options unnecessary.

Why per-block instead of whole-model

Anima's diffusion_model.blocks is a plain nn.ModuleList of identical transformer blocks (the architecture is Cosmos-Predict2, so the same pattern shows up in other predict2-based models). Compiling each block on its own gets you two things:

  • Faster compile. Dynamo builds one small graph and reuses it across all N blocks, instead of tracing one giant graph.
  • Fewer graph breaks. Each block is a small, regular subgraph. A whole-model trace is where you hit the classic failure: a graph break that silently falls back to eager and you've paid the compile cost for nothing.

This is the same trick the anima_lora pipeline uses in training/inference (DiT.compile_blocks), so it's not some hobbyist hack - it's the approach the model's own ecosystem converged on.

Mechanically, the node is a thin, Anima-named wrapper around ComfyUI core's set_torch_compile_wrapper(model, keys=[...]), pointed at diffusion_model.blocks.{i} for every block. The bundled TorchCompileModel node only does whole-model compile; KJNodes' TorchCompileModelAdvanced can go per-block but behind a generic name and a layer-name heuristic. This one is the one-purpose version.

The one input and the output

Just model - the MODEL from your loader. The README wires it up as:

UNETLoader ──> Anima Block Compile ──> KSampler / Spectrum KSampler ──> ...

The output is a single MODEL that goes straight into the sampler input. It composes with the Anima adapter and Spectrum KSampler nodes - the compile is installed as a sample-time wrapper and restored after each apply_model, so it plays nice with the rest of the Anima stack.

Install

Clone it and restart. No extra dependencies - it only needs torch, which any ComfyUI install already has, plus ComfyUI's own compile API:

cd ComfyUI/custom_nodes
git clone https://github.com/sorryhyun/ComfyUI-Anima-BlockCompile.git

Then restart ComfyUI. Manager users can just search "Anima Block Compile". There are no model files to download and nothing else to install.

Common issues

Compilation is lazy. It happens on the first sample, so the first generation after you wire this in is slow - that's the compile actually running - and every one after is fast. Don't restart your workflow and conclude it's broken because the first image took 90 seconds.

Windows without MSVC gets you nothing. The inductor backend codegens and compiles C++/CUDA at first sample, which on Windows needs cl.exe from an activated MSVC environment. The node probes for a working C++ compiler up front, and if there isn't one it logs a warning to the console and returns your model untouched - eager, no speedup, but at least the workflow still runs. If you're on ComfyUI portable on Windows and see no change, that warning is why. Install MSVC Build Tools if you want the speedup.

Don't feed it a non-Anima model. It probes for blocks, transformer_blocks, or layers on the diffusion model, and if it finds none it falls back to whole-model compile - which is the slow-to-compile, graph-break-prone path you were trying to avoid. It also disables dynamic VRAM lazy loading (clone(disable_dynamic=True)) because symbolic weights otherwise break per-block matmuls under dynamo's fake-tensor check.

The honest take

Like every torch.compile node, this is experimental - the author says so, and the flag on the node says EXPERIMENTAL. Real community numbers show the payoff is legit: ~53% speedup on high-end GPUs for Flux, big per-iteration gains on 4090-class cards. But whether you see it on Anima depends on your GPU and driver, and the Windows compiler caveat is a real trap. It's one node, zero config, free to try - wire it in, watch the first-gen compile, and check your console for that compiler warning before you blame the node.

Categoryanima

Inputs (1)

NameTypeDefaultDescription
modelMODEL

Outputs (1)

NameTypeDescription
MODELMODEL