H3 Text Stage Memory
Because your 32B text encoder and your 33B model want the same VRAM
- clip
- CLIP
One CLIP input, one CLIP output, no widgets. On paper H3 Text Stage Memory is the most skippable node in the pack. It's also the difference between a run that completes on a 24 GB card and one that dies at the first sampling step, and the pack's author is unusually blunt about that: the matched 24 GB test exhausted memory without this handoff.
The problem it solves
The 2026 rule about text encoders is that they're a second VRAM budget, not an afterthought - the encoder file decides whether a model fits at all (our VRAM notes make the same point about Flux 2's Mistral encoder). It applies hard here: MiniMax H3's text encoder is Qwen3-VL 32B, running alongside a 33B diffusion transformer. Those are two big things, and ComfyUI's default residency policy is happy to keep the encoder's weights warm after it's done with them.
That's fine for image models where the encoder is a rounding error. It's fatal for H3, because the sampler needs a measured ~17 GiB of activation workspace on top of the diffusion weights, and the encoder is sitting in the way.
What it does
It clones the CLIP object and wraps its encode_from_tokens_scheduled call. Before that call runs, it unloads all models; the encoding happens; then it unloads all models again, including the Qwen encoder it just used. By the time the sampler starts, the text stage's memory is gone.
Three details worth knowing:
- It still uses ComfyUI's native Qwen encoder and tokenizer. This is a residency policy, not a replacement encoder - nothing about your prompt handling or tokenization changes.
- It respects an explicit high-VRAM launch. If you started ComfyUI in a full-residency mode on purpose, the wrapper returns the clip untouched and unloads nothing. That's a deliberate design choice across the pack's runtime nodes: don't quietly override a user who knows what they're asking for.
- It's a
CLIP, not a model patch, so it slots between your CLIP loader and your text encode without touching anything else.
Cost: unload-and-reload. On a 4090 that's seconds; on a machine swapping to system RAM it's worse, because PCIe is roughly an order of magnitude slower than VRAM bandwidth and there is no way around that.
Where it goes
Put it between the CLIP loader and the text encode node - the pack's own graphs feed it the Qwen text encoder and run the resulting CLIP into CLIP Text Encode. That's it. One wire in, one wire out, and the graph order is the entire configuration.
If you're on a bigger card, this node is still a small net win in wall-clock time for multi-window sequences, because each window's prompt encoding is cheap and the freed residency is what lets the sampler run at normal offloading instead of thrashing. If you're on a card that comfortably holds everything in high-VRAM mode, skip it - it's a no-op there anyway.
Install
Manager → H3 Relay → restart, or:
cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/akatz-ai/h3-relay.git
No pip dependencies (the pack declares none). You'll need the H3 model set - including text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors, a 32B encoder that's NVFP4-quantized for a reason - and ComfyUI 0.37.0+. Note that NVFP4 wants Blackwell silicon; on a 30- or 40-series card you're relying on ComfyUI's fallback handling, and that's a thing to test on your own hardware rather than assume.
And the licence reminder, since H3's weights are the whole reason this node exists: the MiniMax H3 Community Licence excludes the US, EU, UK and South Korea, outputs included.
Where people get burned
Don't expect this to fix a genuinely under-specified machine. It hands memory back and forth; it doesn't make a 12 GB card into a 24 GB card. If you're still OOMing, the levers are window size (smaller), resolution (480 instead of 768), and the Sampling Workspace node's estimate - in that order.
The subtler trap is stacking memory kludges. If you've already launched with --lowvram or a big --reserve-vram because it helped a different model, you're fighting this node rather than helping it: the same low-VRAM flags that rescue a barely-fitting image model can force offload you don't need. Start with default memory flags, add this node, and only then reach for launch-time flags.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CLIP | CLIP | — |