Block Swap LTX (RAM Offload)

BlockSwapLTX is the same RAM-offload idea as its sibling BlockSwap - park N transformer blocks in system RAM, stream each to the GPU only for its forward pass, LoRAs baked into the CPU masters once at load. But it adds two things that make it the correct pick for a growing share of modern checkpoints: it looks up the repeated-block list under either .blocks or .transformer_blocks, and it understands fp8 weights wrapped in comfy_kitchen QuantizedTensor subclasses.

Why that second bit matters: LTX-2.3 22B bf16 is 43 GB. The fp8 version is roughly half, and that's the one people actually run on 24 GB cards - the README's test of ltx-2-3-22b-dev-fp8.safetensors (48 transformer blocks) finished a 360×360, 49-frame I2V in 40.2 s with 12 blocks swapped (auto-raised to 14), 17.9 GB resident. Without the node, the same card was packed to the brim and took 47.4 s. And critically, fp8 checkpoints from any family want this class - including the Wan 2.2 A14B dual-expert fp8 checkpoints, where the plain BlockSwap node is the trap people fall into: it just doesn't move QuantizedTensor weights.

How the fp8 handling differs

Plain tensors can be swapped in place with the .data repointing trick - the fast path with no attribute churn. QuantizedTensor wrappers can't: their device is fixed at construction and the real payload lives in an inner _qdata, so swapped fp8 params get exchanged at the module-attribute level instead. There's also a guard that unpins before the base model's .to() runs, because a sibling ModelPatcher clone (say, a chain without this node) calling unpatch_model → model.to() rebuilds the wrappers, frees a still-pinned payload, and poisons the CUDA context with a delayed invalid argument.

Inputs and output

Same shape as the whole pack: model (MODEL, placed after LoRA loaders), blocks_to_swap (default 20, 0–80, auto-raised if the resident part won't fit VRAM), and pin_memory (default true, page-locks the CPU copies). Output is a single MODEL to wire into ModelSamplingSD3 → KSampler.

Installing

Same pack, same nothing to download: Manager → search "ComfyUI-JITBlockSwap", or git clone https://github.com/lovemachine100/ComfyUI-JITBlockSwap into custom_nodes/, then restart. No dependencies, no model files, no key.

The launch-flag stack that makes it behave

Beyond the universal --disable-dynamic-vram (without it the node is a silent pass-through that only logs to the console), the Wan 2.2 I2V A14B fp8 dual-expert config needs all three, per the README's verified run:

--disable-dynamic-vram   # required for the node to act at all
--disable-pinned-memory  # else the switch to the second expert dies with CUDA error: invalid argument
--reserve-vram 3.0       # gives BlockSwap a real weight budget on both experts

That dual-expert run - 720×1280, 77 frames, 4 steps split across the high/low experts - completed in 12 min 31 s on a 4090, with both experts getting 24/40 blocks auto-raised into RAM. It's the closest thing this pack has to a reference workflow, and it's a good template for any fp8 Wan 2.2 setup.

Troubleshooting worth knowing

• fp8 + runtime LoRA can crawl for hours. With --disable-dynamic-vram, ComfyUI's legacy loader merges a LoRA into fp8 weights per-key on a VRAM-packed GPU before this node's hook ever runs. BlockSwap can't help there. Pre-merge the LoRA into the checkpoint, or run fp8+LoRA under dynamic VRAM (where this node is a no-op). fp16/bf16 + LoRA are unaffected.
• 40 GB-class bf16 checkpoints can throw CUDA error: invalid argument on the next transfer even when every load phase synchronized cleanly. Root cause is Windows commit-charge exhaustion - the swap masters plus LoRA backups pile ~40 GB of committed CPU memory on top, and once you hit the RAM+pagefile limit the driver refuses the staging allocation. Fix: a large fixed pagefile (e.g. 64 GB - commit is reserved, not written, so it costs no I/O) or run those checkpoints without swap. And after any failed run, restart ComfyUI before queueing anything else; the dead model's commit lingers and can sink the next, otherwise-fine job.

This is a niche-in-a-niche node - zero Google impressions at the time of writing - but if your library is fp8-scaled DiTs, it's the one that actually works.