MiniMax H3 Residency Strategy / 低显存驻留策略 (Advanced EXP/T8)

Every H3 workflow ends the same way for a chunk of us: OOM, or a model that gets silently shunted off the card mid-render. The Residency Strategy node is T8's answer to "how much VRAM should this model be allowed to keep resident?" - and the honest headline is that it's a planner, not a fixer. It compiles a policy from your actual runtime state and hands it to you. It does not unload anything itself, and that caution is the point, not a missing feature.

How it works

The node reads telemetry from your current ComfyUI install - model load/offload devices, loaded vs. total size, lowvram patch state, plus AIMDO (comfy-aimdo) managed-VRAM figures when that package is present - and produces a vram_policy object describing how much headroom to reserve. It never unloads other models and never monkey-patches globally. The word "side-effect-free" appears in the node's own description, and it means it.

The strategy Combo is the one knob that matters:

• report_only (default) - observe current residency, change nothing. Great for first runs.
• minimum_memory - reserve 6 GiB; prefers offload and headroom over speed. The 16GB-card careful choice.
• balanced - reserve 4 GiB; a bounded 16GB starting point, and the author explicitly says to re-measure per workflow.
• faster - reserve only 2 GiB; more residency, and the highest activation/OOM risk of the four.

That reserve figure is what comes back as recommended_reserve_gib, alongside current_gate_pass (a BOOLEAN saying whether your setup currently satisfies the policy's safety gate) and a report_json you can actually read. The optional model and clip inputs just make the snapshot more precise; you can run it empty.

The part beginners miss

The vram_policy output is a custom H3_T8_VRAM_POLICY object. Nothing applies it automatically. You wire it into the pack's compatible loader (the Advanced Hybrid Loader) so the policy is enforced before the model loads - that's the "applying remains explicit" contract. policy_epoch is an advanced INT you can ignore until you want versioned policies.

Why design it this way? Because automatic VRAM fiddling is how you get two nodes fighting over memory management and making everything worse. A plan you deliberately opt into is debuggable. If you set faster and start OOMing, the fix is obvious - back to balanced - rather than spelunking through a black box that already silently changed your settings.

Installing it

It's part of the comfyui-minimax-h3-audio-T8 pack: ComfyUI Manager → search "MiniMax H3 Audio T8", or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Update ComfyUI itself first (native MiniMax H3 support is a hard dependency), restart, done. No extra model downloads for this one - it reads state, it doesn't load weights. The report-only default means you can drop it into a workflow, run once, read the JSON, and decide whether the whole residency game is worth playing for your setup.

Where people get burned

Expecting it to rescue an already-OOMing graph. It's a preload-time planner; if H3 won't even load, this won't fix that. And don't take current_gate_pass=true as a guarantee - the gate reflects the policy you chose, so faster passing its own loose gate doesn't make you 16GB-safe. H3's own KB notes there's no verified consumer-VRAM floor for the full weights, so treat every residency answer as "for this workflow, on this machine," not a universal truth.