Nodes/H3 Relay/H3 Sampling Workspace
ComfyUI Node

H3 Sampling Workspace

Tell ComfyUI how much room H3 actually needs

By akatz-ai·Created 2 months ago·Updated a day ago· 30
H3 Sampling Workspace
  • model
  • latent
  • conditioning
  • MODEL
◄activation_memory_gib17.0►

ComfyUI estimates how much VRAM a sampling step will need, and it estimates it from the model's own formula. For MiniMax H3 that estimate is wrong in the expensive direction: the pack's notes describe stock estimation loading 19.3 GiB of weights and failing on the first sampling step of a 24 GB card.

H3 Sampling Workspace replaces the estimate with a measured one. It's a residency node, not a quality node - it changes nothing about what H3 generates, only how much room ComfyUI reserves before it starts.

What it does

It wraps the model's outer sampling call. Inside that wrapper it overrides memory_required to max(native_estimate, activation_memory_gib × 2^30), so ComfyUI's placement logic gets a realistic number for the activation workspace instead of an optimistic one. In normal (offloading) mode it also unloads all resident models just before sampling, and again just after - the second unload is what matters for H3 specifically, because native decoding needs room and the diffusion model doesn't need to be there for it.

In explicit high-VRAM mode it skips the unloads entirely, keeping the model resident. Same tolerance for user intent as the rest of the pack's runtime nodes.

Three inputs are required and only one of them does anything numerically. model is the one that gets patched. latent and conditioning aren't read at all by the implementation - they exist to force this node to evaluate after your guides are encoded and before the guider runs. That's a slightly odd design when you first notice it, and it's honest about the tradeoff: it's the only way to hang a residency policy at the right point in a graph without a callback system. Wire the same latent and conditioning you're about to sample and don't think about it again.

activation_memory_gib is the real dial. Default 17.0, range 0–128, half-GiB steps. The tooltip is careful to say it's "estimated sampling workspace used by native model placement; not a GPU memory cap" - and that distinction is the whole node. You're not limiting anything; you're declaring a reservation.

One MODEL output, which goes into your guider.

Picking the number

17 GiB is the character-swap recipe at a 124-frame window. Person Removal uses 4 GiB at its qualified 22-frame window, which makes sense - a quarter of the temporal extent is nowhere near a quarter of the peak, and the removal path floods attention with a mask that changes residency rather than growth. If you're between those two, scale roughly with window frames and watch your actual peak.

Set it too low and you're back to the stock failure: the sampler gets a placement plan that doesn't fit and OOMs mid-step. Set it too high and ComfyUI offloads more aggressively than necessary, which costs you speed rather than correctness. Wrong in the safe direction is the correct default here.

Install

Manager → H3 Relay → restart, or:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/akatz-ai/h3-relay.git

Needs the full H3 model set and ComfyUI 0.37.0+. The pack declares no pip dependencies; this node uses comfy.patcher_extension, so it's tied to ComfyUI's internal wrapper API and is one of the places a ComfyUI update could bite before anything else in the pack does.

Usual licence caveat on the weights: US, EU, UK and Korea are excluded from the MiniMax H3 Community Licence, outputs included.

Where people get burned

The failure that will waste your afternoon: this node must sit after the guides, and if it's before them, the guides' own encoding happens outside the wrapped call and the memory relief arrives too late. In the reference graphs it's placed after Apply History and Apply Edit Mask, with the guider immediately after it. Follow that order.

Second, the semantics. People read "activation memory" and assume it caps VRAM usage, then complain the node "doesn't work" when a 12 GB card still OOMs. It reserves and unloads; it doesn't compress. If you genuinely can't fit H3, the lever is a smaller window or 480p, not a bigger number here.

Third, full-residency mode. If you launched ComfyUI with high-VRAM forced, this node silently does much less - no unloads - and the pack's own validation found that full residency exceeded physical 24 GB capacity. That result is why the qualified target runs normal offloading. If you're chasing someone's benchmark numbers and getting OOMs, check how they launched.

CategoryH3 Relay/Runtime

Inputs (4)

NameTypeDefaultDescription
modelMODEL—
latentLATENT—
conditioningCONDITIONING—
activation_memory_gibFLOAT17.00–128Estimated sampling workspace used by native model placement; not a GPU memory cap.

Outputs (1)

NameTypeDescription
MODELMODEL—