H3-World: a knowing license override, then a second wall the license had nothing to do with
The first write-up here called this "the reproduction that never reached the GPU" and stopped at the license. That framing needs a correction, not a reversal: the license block was real and stands as documented below, but Gavin reviewed it and explicitly authorized proceeding anyway, knowingly, for a private on-rig test with no distribution. That's his call to make on his own hardware. What follows is what happened when we actually tried — and it turns out the license was never the thing that would have stopped this rig. A second, independent wall was waiting behind it.
What H3-World claims
H3-World is a third-party project (Tencent, National University of Singapore, Hong Kong Polytechnic University) that adds action-conditioned control on top of the base MiniMax H3 video model already in production here. The mechanism: feed it one still frame and a scene prompt, then hold a key combination (WASD for character motion, IJKL for camera) for the whole clip, and it generates video where the subject and camera move according to that held input. Mechanically it's a rank-32 LoRA plus a directed-attention patch, 65.6M trainable parameters (0.199% of the 33B H3 backbone), trained on 8,000 gameplay clips from the ABot-World-Explorer-500h dataset, released alongside a paper (arXiv 2609.01560) and a patched fork of DiffSynth-Studio.
One framing correction on "keyboard-controlled": the repo's own inference entrypoint (code/abot/infer.py) takes --action-preset from a fixed list (still, forward, back, strafe-left, ...) chosen once, up front, for the entire 124-frame render — not a live per-frame keystroke stream. Gavin already knew this going in; it isn't being raised here as a gotcha that undermines the experiment. The actual point of interest is adherence quality: does a held-preset action signal actually steer the generated motion the way the paper claims, compared to how this rig's other prompting approaches steer motion today. That's a real, answerable question, and the plan below was built to answer it — right up until the second wall.
Blocker one: the license, overridden knowingly
MiniMax H3's own weights ship under the MiniMax H3 Community License Agreement. Section V.4 is unconditional: "You may not use, reproduce, modify, distribute, or display the MiniMax H3 Works or any of their Outputs or results outside the Applicable Territory," and Section I.5 names the United States as one of the excluded territories, with no personal-use carve-out anywhere in the document (checked twice to be sure of that). This rig is in the United States, so on a literal reading this is a hard stop.
Gavin reviewed that finding and chose to proceed anyway for a private, non-distributed test on his own hardware. That's a real, informed decision, not a claim that the restriction doesn't exist or doesn't apply — it's a knowing override of a restriction he has the standing to accept the risk on. The investigation moved forward on that basis.
Blocker two: a wall the license never touched
With the license question set aside, the real remaining question was whether this rig's single RTX 3090 (24GB VRAM, 62GB host RAM) could run H3-World at all. Four things were checked, in order, before anything was downloaded:
Disk: fits, on the right mount. The base model is ~135GB (33B-parameter dense transformer plus a full Qwen3-VL-32B text encoder, both at BF16). The root filesystem only has 96GB free, but the actual ComfyUI/model storage lives on a separate 1.5TB mount (/mnt/DataLinux) with 396GB free. Not the blocker.
Quantized/pruned substitutes: real, but incompatible. MiniMax's own pruned/int8 repacks are already on this rig running production H3 today (minimax_h3_ref2va_pruned_int8_convrot.safetensors, 20GB, plus a w4a8-mixed variant and a hybrid int8 build). Community GGUF quantizations of vanilla H3 also genuinely exist — a Hugging Face search turns up over two dozen (unsloth/MiniMax-H3-GGUF, vantagewithai/MiniMax-H3-comfyUI-GGUF, Abiray/MiniMax-H3-Pruned-GGUF, and more). Neither category is usable here, and reading H3-World's actual patch code (code/diffsynth_h3_action.patch, applied to a pinned DiffSynth-Studio commit) shows why:
- The patch adds one zero-initialized FiLM modulation pair (
action_scale,action_shift) per transformer layer, wired in by index (self.blocks[i]↔action_scale[i]) right after each block's existing AdaLN norm. That indexing assumes the full, unpruned 50-layer topology the LoRA was trained against. The pruned checkpoints on this rig have already dropped the "13B of AdaLN branches skippable at inference" — a materially different layer/AdaLN structure the LoRA's per-layer indexing was never trained to match. - Both the pruned repacks and the community GGUF builds are quantized in ways (int8/w4a8 rotation transforms, GGUF block quantization) that put the base weights in a different numerical basis than the BF16 tensors the LoRA's low-rank deltas were computed against. Composing a BF16-trained LoRA onto a rotated/block-quantized weight without re-deriving the adapter in that basis doesn't error — it silently produces the wrong output, the same failure mode the H3-World authors' own code explicitly guards against (
infer.pyandtrain_v2.pyboth hard-check, viainspect.getsource, that the exact patched DiffSynth code is what's actually loaded, specifically because a mismatch here runs cleanly and just quietly produces meaningless video). - More fundamentally: every one of those quantized/pruned builds — including the ones already on this rig — targets ComfyUI's own native inference stack (custom nodes over
nodes_minimax_h3.py). H3-World's entire codebase is built on DiffSynth-Studio, a separate Python framework with its own model classes, loader, and pipeline units. There is no ComfyUI node for H3-World at all; a repo-wide search turns up zero references to ComfyUI anywhere in it. Porting the patch onto a quantized ComfyUI-native checkpoint wouldn't be applying an existing adapter — it would mean reimplementing the directed-attention masking, per-latent action-text injection, and Token Refiner resegmentation as new ComfyUI nodes from scratch. That's a real engineering project, not a shortcut, and it's exactly the "porting the quantization work yourself" the brief already flagged as out of scope.
VRAM/RAM: the actual, independent wall. DiffSynth-Studio's own load_pipeline() in infer.py does support single-GPU inference via CPU weight offload (offload_device="cpu", params paged to the GPU per layer) — so a 24GB card isn't automatically disqualifying on its own. But offload only works if the full BF16 weight set can live in host RAM between layers: ~66GB for the 33B transformer plus ~64GB for the Qwen3-VL-32B text encoder, roughly 130GB combined. This rig has 62GB of RAM total (31GB swap, ~93GB hard ceiling even fully swapped, and only ~36GB actually free right now with a production job already running at 43% GPU utilization). That's short of the requirement independent of anything to do with VRAM, quantization, or the license — even a perfectly licensed, perfectly patched, perfectly single-GPU-capable checkpoint still doesn't fit in this box's memory.
Where it landed
Genuinely blocked, and for a reason that has nothing to do with the license this time: no combination of quantization or pruning gets H3-World's own patch and checkpoint onto this rig's inference stack without redoing the porting work MiniMax's own quantization teams haven't published, and even setting that aside, the unquantized path DiffSynth-Studio does support needs roughly 130GB of host RAM this box doesn't have. No checkpoint was downloaded, no LoRA was staged, and nothing was submitted to Concourse — there was no ComfyUI workflow to submit in the first place, since H3-World has no ComfyUI integration to dispatch through. No media in this entry, and that's the correct outcome again: the wall was found before anything reached the GPU, same as the first attempt, just a different wall this time.