H3 VAE 固定显卡（稳定解码）

H3 decoding is where "stable" workflows quietly stop being stable. You get a lovely sampled latent and then the VAE decode picks the worst possible moment to hop devices, or the dynamic weight-streaming kicks in mid-decode, and suddenly you're chasing CUDA errors instead of watching a render. H3PinnedVAEDevice exists to make that stop: it pins the VAE to one GPU, with dynamic streaming disabled, so decode always runs where you told it to.

It's a small node with a precise job, and it's the natural partner to H3LatentPhaseBarrier. The barrier frees VRAM before the decode phase; this node locks the decode to a chosen card so the freed space is actually usable there.

How it works

Under the hood it clones your VAE and rebuilds it with a patcher that has dynamic loading turned off (disable_dynamic=True), then sets the load device to your chosen GPU and the offload device to ComfyUI's normal VAE offload device. The clone's first-stage model is wired to that patcher, so everything the decoder touches lives on the pinned device. Your original VAE isn't mutated - you get a pinned copy out.

The interface is two inputs and one output:

• vae (VAE) - the H3 VAE from your model loader.
• device - an enum of GPU device options, default gpu:0. Pick the physical card you want the decode on.
• Output: vae (VAE) - the pinned clone, wired into your VAE decode node.

It deliberately refuses to pin to CPU - this node's whole point is "decode on a GPU, stably," and a CPU pin would defeat it.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/bo341805sg/ComfyUI-CineTimeline
# restart ComfyUI

Or ComfyUI Manager → search "CineTimeline". No extra dependencies for the node itself.

Gotchas

• Physical GPU numbering matters. The README calls this out specifically: if ComfyUI is started with CUDA_VISIBLE_DEVICES reordering CUDA device IDs, the pack converts back to physical GPU numbers rather than trusting cuda:0. So gpu:0 here means physical GPU 0, not necessarily "the first device Python sees." If your decode keeps landing somewhere surprising, check your CUDA_VISIBLE_DEVICES setup first.
• The clone holds weights. Pinning a VAE means those weights stay resident on that card until freed. On a two-GPU rig that's the point (you're dedicating one card's headroom to decode); on a single card, "pin to gpu:0" is mostly a no-op that adds an explicit device guarantee without changing much - it shines when you have a second GPU to spare.
• It pairs with, but doesn't replace, H3LatentPhaseBarrier. Pin decides where the decode runs; the barrier decides when the resident models get evicted so the decode has room. In the pack's dual-GPU production workflow you often see both.

Reach for it when your H3 decode is flaky on a multi-GPU box, or when you want the decode on the non-sampling card so the sampler and decoder don't fight over the same VRAM. It's the kind of node that does one thing, does it invisibly, and saves you the hour of debugging it prevents.