MiniMax H3 FP16 Exact Fix (Legacy) - Star7
Keep it for old workflows, not new ones
- model
- model
The name is a little proud, and the honest label on this node today is "compatibility." MiniMax H3 FP16 Exact Fix (Legacy) - Star7 is the original MODEL → MODEL patch that made native MiniMax H3 generation possible on pre-BF16 GPUs like the RTX 20 series. It's been deprecated since pack v2.0.5, hidden from new-node search, and kept around for one reason: existing workflows that were built around it keep working, because its class ID never changed. If you're starting a new workflow, use the pack's loader instead. If you have an old one, this is the node that keeps it alive.
What it does
It's a post-load patch. You load H3 with a normal UNET loader, then pass the model through this node, and it rewrites the forward passes so FP16 inference doesn't melt. The mechanism is the same "exact" fix the newer loader installs at creation time: the residual stream is held in FP32 across all 50 DiT blocks, attention and MLP branch inputs are cast to FP16 only where it's numerically safe, SwiGLU pointwise math runs in FP32, and the two overflow-prone projections - attention out_proj and MLP fc2 - get protected by power-of-two scales of 64 and 256. That power-of-two transform is what "Exact" means; it doesn't promise bit-identical output across FP16, INT8, and FP32 backends, and you shouldn't expect it to.
Since v2.0.0 the patch is quantization-aware, which was its big fix. The original version called set_model_compute_dtype(FP16), which also flipped on forced weight casting and could silently dequantize your INT8/ConvRot layers into dense FP16 - killing the hardware-friendly quantized path that ComfyUI v0.27.0 made native. The current code detects quantized layers, keeps force_cast_weights=false for them, and only forces FP16 compute where it belongs. On Ampere-and-newer GPUs or slow-FP16 GTX 10-series cards it does nothing at all: it logs and passes the model through untouched.
Inputs and outputs
Two inputs, one output, nothing exotic:
model(MODEL) - the H3 model from your UNET loader.enabled(BOOLEAN, defaulttrue) - flip it tofalseand the model passes through completely unchanged. Handy for A/B testing whether the patch is actually helping.
The model (MODEL) output feeds straight into your existing sampler chain. There's no tuning here - the power-of-two scales are hardcoded constants (the pack's own tests verify they're exact powers of two), so the node is set-and-forget.
Install
ComfyUI Manager, search MiniMax H3 FP16 Exact Fix - Star7 (package minimax-h3-fp16-exact-star7), or:
cd ComfyUI/custom_nodes
git clone https://github.com/star7code/minimax-h3-fp16-exact-star7.git
Restart ComfyUI. No extra Python dependencies and no model downloads - the pack only patches whatever H3 checkpoint you already have in models/diffusion_models.
The one gotcha that matters
Don't use it after the native loader. If you load with MiniMax H3 Native FP16 Loader - Star7, the fix is already in place at creation time, and wiring the legacy patch in after it doubles up on the same overflow repair. The README is blunt about it: the post-load node is a compatibility path, not a byte-for-byte equivalent of the loader's construction-time FP16, so new workflows should pick the loader and let this one sit quietly in old saved graphs. Same house rules as the loader: don't stack it with a second process-wide FP16 fix, and expect the console to warn you if a LoRA's dynamic weight patches are about to dequantize a quantized layer. If you're on a pre-BF16 GPU and this node's log line reads mode=postload-quantized | force-cast=False, your quantized kernels survived and you're getting what this node is for.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| enabled | BOOLEAN | true | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |