MiniMax H3 on RTX 3060: 12 GB video+audio in ComfyUI, measured on this card

What You'll Build

A locally generated clip with native stereo audio from MiniMax H3, on a 12 GB RTX 3060, using ComfyUI's dynamic VRAM offloading. This is the card Comfy-Org named when it announced the model, and it is the only card in this family where the vendor's claim and the published measurements are about the same piece of hardware — so this page can tell you what a run actually costs here instead of bounding it.

⚠️ Read the licence before you download 42 GB. MiniMax H3 is not open-source. The MiniMax H3 Community License Agreement grants rights only inside its Applicable Territory, and Section I.5 defines the Excluded Territories as "means the European Union, the United Kingdom, the Republic of Korea and the United States of America." Section V.4 extends the restriction to what comes out of the model: "You may not use, reproduce, modify, distribute, or display the MiniMax H3 Works or any of their Outputs or results outside the Applicable Territory." — the output video is covered, not only the weights.

The machine-readable license: facet on the model card is the uninformative other, so any filter or licence-scanner keyed on that field sails straight past the territorial clause; the restriction lives only inside the LICENSE file. The Comfy-Org repack this page installs does not relicense anything, and neither does a community GGUF, int4 or Turbo LoRA built on these weights — each is a Model Derivative and inherits the terms. MiniMax publishes a licence Q&A and an application route for per-deployment licensing at platform.minimax.io/h3-license. This is a summary written by a reader of the text, not legal advice.

Hardware data: RTX 3060 (12GB VRAM) · 39.554 GiB of weights streamed against a 12 GiB card · See benchmark data

ℹ️ This is the card in the announcement — and 768p is still the ceiling. Comfy-Org's day-0 post says of the shrunk weight set: "Combining this with our dynamic VRAM offloading enables a next-generation 2K video model to run locally on a GPU like the RTX 3060.", and its standfirst repeats that "this powerful model is greatly optimized in ComfyUI and can run locally on a 3060." That sentence is the whole basis for min_vram_gb: 12 across every MiniMax H3 recipe on this site, so it is worth saying precisely what it does and does not promise. It is a claim about fit, and it holds. It is not a claim about 2K: H3 reaches 2K through a separate H3-Regenerate-2K module, and the model card states "this module is not yet open-sourced. We will release it once it is ready." What runs on your card is H3-Base, which the same card describes as "H3-Base: Generates audio and video based on the H3-Context-IR output, producing results at 768p resolution." And it is not a claim about speed — see Results.

Requirements

Component	Minimum	This recipe
GPU	12GB VRAM	RTX 3060 (12GB) — not measured by us; the timings in Results are published runs by RTX 3060 12GB owners (/contribute)
RAM	32GB with --disable-pinned-memory; 64GB without	— see Running, this is the prerequisite most likely to waste your download
Storage	39.554 GiB of weights (42.47 GB as HuggingFace reports it), NVMe strongly preferred	—
Software	ComfyUI 0.30.0+, torchaudio, CUDA 13 build of PyTorch	—

The four files the official ComfyUI text-to-video template loads, byte-exact from the Comfy-Org repack's tree API:

File	Bytes	GiB	Destination
minimax_h3_fl2va_pruned_int8_convrot.safetensors	20,970,379,616	19.530	models/diffusion_models/
qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors	15,687,142,551	14.610	models/text_encoders/
minimax_h3_video_vae_fp16.safetensors	5,207,808,496	4.850	models/vae/
minimax_h3_audio_vae_fp32.safetensors	605,254,808	0.564	models/vae/

That sums to 39.554 GiB against a 12 GiB card — a 27.554 GiB shortfall. The decimal restatement, 42.47 GB, is the same number Comfy-Org quotes when it describes shrinking the footprint "reduced by 66%, from 123.6 GB in full precision to 42.5 GB" with the smallest model variants.

What actually gates this card

The intuition to discard first is that a 12 GB card is short of VRAM. It is — but not in the way that produces an out-of-memory error, and not in a way that the card's own shader throughput or on-board memory bandwidth has much to do with. Here is the arithmetic, all of it from comfy/model_management.py at tag v0.30.2 and the byte counts above.

minimum_inference_memory() is 0.8 GiB plus EXTRA_RESERVED_VRAM, which is 400 MiB on Linux — 1.191 GiB. On Windows the base is 600 MiB, and a further 100 MiB is added only inside the if WINDOWS branch and only when total_vram exceeds 15 GiB, under the comment "more extra reserved vram on 16GB+ cards". A 12 GB card is below that line, so the Windows floor here is 1.386 GiB, not the 1.484 GiB that applies to larger cards. Check the indentation yourself; it is easy to read wrong.

Stage	Resident weights	ComfyUI's reserve (Linux)	Stage total	Against 12 GiB
Text encode (Qwen3-VL-32B, NVFP4-AWQ)	14.610 GiB	1.191 GiB	15.800 GiB	short by 3.800 GiB
Denoise (the H3 DiT, pruned int8+convrot)	19.530 GiB	1.191 GiB	20.721 GiB	short by 8.721 GiB
Decode (video VAE fp16, 124 frames at 864×480)	4.850 GiB	1.455 GiB	6.305 GiB	clears by 5.695 GiB

Only the last row fits. The decode reserve is not a guess — comfy/sd.py ships a first-party estimator for this VAE, (9.5 × frames × height × width + 270,000,000) × dtype_size × 1.03, which at 124 frames of 864×480 in fp16 gives 1.455 GiB.

The middle row is the page. load_models_gpu computes how much of a model it can leave on the card as max(0, free_mem − minimum_memory_required, min(free_mem × MIN_WEIGHT_MEMORY_RATIO, …)), and MIN_WEIGHT_MEMORY_RATIO is set to 0.0 on NVIDIA — so on this card the resident weight budget is simply free VRAM minus the reserve: at most 10.809 GiB, and less in practice once your desktop has taken its share. The transformer is 19.530 GiB, so at least 8.721 GiB of it is off-card at all times. The model card describes it as "H3-Omni-Transformer is a 33B-parameter dense, single-stream Transformer" — dense, so every sampling step touches every weight. The part that will not fit has to come across PCIe from host memory while the step runs, once per step, for however many steps you ask for.

That is what gates an RTX 3060 here. Not the SMs, and not the 12 GB itself — a card half this size would fail differently, with an error rather than a clock. The resources that decide whether your run finishes, and how long it takes, are system RAM, the PCIe link and the SSD, which is why every prerequisite on this page except the first is about the machine around the card. It is also why the two measured runs below differ by more than four times in wall clock — at different canvases and step counts — while the VRAM peak barely moves. One person has posted readings that show the same pattern one tier up: on the repack's discussion #6, a user posting as UdonJP reports from an RTX 5070 Ti that "VRAM peak was 14,197 MiB for 30 s @ 640x480 and 14,437 MiB for 5 s @ 1344x768" — two jobs an order of magnitude apart in size, near-identical ceilings, both already above a 12 GiB card's whole capacity — and reads it as "ComfyUI's DynamicVRAM keeps the ceiling roughly constant and pays the difference in time rather than VRAM". That is one person's report from one machine rather than a controlled result, and it is corroboration rather than the argument: the argument is load_models_gpu's own budget, above.

Installation

1. Update ComfyUI onto a CUDA 13 PyTorch

H3's nodes ship in ComfyUI core (comfy_extras/nodes_minimax_h3.py), not as a custom node; the ComfyUI announcement pins the floor at 0.30.0. That module imports torchaudio at load time — a hand-built environment with only torch and torchvision fails at startup even though requirements.txt covers it.

The weights ship in an int8 "convrot" format, and the fast kernels for it are gated on the CUDA version your PyTorch was built against rather than on your card. The gate is in ComfyUI's own source: comfy/quant_ops.py reads torch.version.cuda and, below major version 13, calls ck.registry.disable("cuda") and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." Nothing raises — you simply get the generic path, on a card that can least afford it. Order matters: requirements.txt lists torch unpinned, so running it after installing a cu130 build will resolve a default-index wheel over the top and silently undo the fast path. Install the CUDA 13 stack last, from its own index.

cd ComfyUI
git fetch --tags && git checkout v0.30.2
pip install -r requirements.txt
pip install --force-reinstall --index-url https://download.pytorch.org/whl/cu130 \
  torch torchvision torchaudio

Confirm it took: the startup log prints the torch version and you want +cu130 in it. On an Ampere card the same log will list nvfp4 under emulated ops rather than native ones — that is expected and is not a problem here; see step 3.

2. Download the weights

pip install -U "huggingface_hub[cli]"

hf download Comfy-Org/MiniMax-H3 \
  diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors \
  text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors \
  vae/minimax_h3_video_vae_fp16.safetensors \
  vae/minimax_h3_audio_vae_fp32.safetensors \
  --local-dir models

The repo's own paths are already diffusion_models/, text_encoders/ and vae/, so --local-dir models lands all four files where the loaders look. Run it from the ComfyUI directory step 1 left you in. Pointing --local-dir at models/diffusion_models instead gives you models/diffusion_models/diffusion_models/… and a node that cannot see its own weights.

Pass the filenames as positional arguments, as shown.

3. The text encoder: take nvfp4, and ignore the "30-series needs int8" advice

This is the one install decision where a 12 GB card's answer differs from the advice you will find written for 30-series cards generally, and it is worth spelling out because the counter-argument is prominent.

30-series owners are routinely steered to the int8_convrot encoder instead, on the grounds that nvfp4 needs Blackwell. On raw hardware capability that is right, and you can read the gate rather than take it on trust: supports_nvfp4_compute() in comfy/model_management.py returns False for any device whose compute-capability major version is below 10, and this card is 8.6. But on this card nvfp4 is not being used as a compute format at all. Asked directly in discussion #16 whether nvfp4 was Blackwell-only, Kijai — a Comfy-Org member — answered that it is not, and when pushed added that "it's just used as storage format here, there's nothing hardware specific about that". Two independent things then agree with him, and both are on 30-series hardware:

• In the same thread, an RTX 3060 12GB owner reported the result of trying it: "MiniMax-H3 (960x544x20steps) with ref2va pruned int8 convrot on my RTX 3060 12GB/32GB and it works without any problem (with nvfp4 txt)". (Note the ref2va checkpoint — the reference-to-video sibling of the file installed above, not the fl2va one. Same repack, same quantisation, different graph.)
• The author of a 31 GB-RAM RTX 3090 write-up reaches the same conclusion from the RAM side and recommends keeping the nvfp4 encoder rather than the int8 one when system RAM is the constraint.

The size difference is 14.610 GiB against 25.277 GiB — 10.667 GiB more to download, to hold and to stream on every generation, on a card that is already streaming everything and a machine that may have only 32 GB to hold it in. Take nvfp4.

The honest counterweight: in that same thread a commenter posting as V33rGeer argues the nvfp4 encoder compromises coherence on demanding reference setups and that int8 is simply better "unless your system physically cannot handle it". (A later reply in that thread block-quotes those words back before answering; they are V33rGeer's, and he names no hardware anywhere in the thread — so read it as a quality opinion, not a hardware report, and do not inherit the replier's machine for it.) On this card the exemption is the whole situation. If prompt adherence fails on a complex reference setup, that is the first thing to try changing, and the second is your prompt.

On the int4 shortcut you will be offered. A second RTX 3060 12GB owner suggests one in discussion #35: "why dont you use the int4 version of the qwen3vl? I am also on rtx 3060 12gb + 32 gb ram and am using that." Check the file sizes before you act on it. The community int4_convrot build is 14,952,506,709 B = 13.926 GiB — 0.684 GiB smaller than the nvfp4 file, because nvfp4 is itself a 4-bit format. The person who published the GGUF encoders said as much in discussion #16: "they arent much smaller than the nvfp4 encoder in this repo but it should help A LITTLE i guess". The one genuinely smaller option is a Q2_K GGUF encoder at 7.905 GiB, which will load — qwen3vl is on the ComfyUI-GGUF text-model allow-list, unlike the diffusion GGUFs in Troubleshooting — but nobody has published a result with it, and the text encoder is the component the quality complaints are about. Treat it as an experiment, not a step.

One concrete trap in the repo that int4 suggestion points at: the file there named qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors is 27,141,342,223 B = 25.277 GiB — within 71 bytes of Comfy-Org's int8 encoder and 10.667 GiB larger than the nvfp4 file whose name it carries. Download by size as well as by name.

4. Load the official template

Open ComfyUI, go to Template Library, and pick MiniMax H3 Text to Video, or drag in video_minimax_h3_t2v.json. It wires exactly the four files above. The ComfyUI tutorial documents this template plus the I2V and R2V variants.

Running

Start ComfyUI with the offload flag. On a 32 GB machine the default launch is the failure case, not the baseline.

python main.py --disable-pinned-memory

The mechanism is worth thirty seconds because it is the single most likely reason a reader of this page never gets a video out. ComfyUI page-locks host memory to speed up transfers to the GPU. MAX_PINNED_MEMORY is 90 % of system RAM on Linux and 40 % on Windows, and the per-model host buffer is sized at twice the model size — so the 19.530 GiB transformer asks for a 39.060 GiB pinned buffer, which is more than a 32 GB machine physically has. Pinned pages can be neither swapped nor reclaimed, so when the machine runs out the kernel's only remaining move is to kill the process.

The one published measurement taken on an actual 32 GB machine is the RTX 3090 write-up, on a 31,997 MB box: 29,866 MB of host RAM and an OOM-kill on defaults, against 7,508 MB and a completed 15-second clip with the flag. Different card, same transformer — and since the pinned request is sized off the transformer rather than off your VRAM, that is exactly the half of his result which transfers to a 12 GB machine.

What the flag costs you in speed is unmeasured. The mechanism says the answer depends on your RAM rather than on your card: page-locking governs how the weights reach the GPU, not where they sit in between. A machine with room to keep the 42.47 GB weight set in page cache loses nothing by dropping the pin; a 32 GB machine has no such room, so the per-step streaming this card cannot avoid starts arriving off the SSD instead of out of RAM. Nobody has published how large that penalty is at this tier. Take the trade regardless — the alternative on 32 GB is not a slower render but a killed process — and put the weights on the fastest NVMe you have rather than a SATA SSD. If you have 64 GB you keep both the flag and the page cache, and this paragraph does not apply to you.

--fast-disk attacks the same problem from the other end, moving weights into reclaimable page cache rather than anonymous memory — comfy/cli_args.py describes it as "Prefer disk-backed dynamic loading and offload over unpinned RAM." One person reports it clearing 32 GB on its own: in discussion #6, UdonJP posts a three-row table for one job with only the launch flag changed under the heading "One startup flag changes the RAM requirement by ~3.6x.", taking ComfyUI's resident-set peak from 45.4 GiB on defaults to 12.6 GiB with --fast-disk. Read that as one person's pair of readings on a 125 GB box rather than as a specification. And do not treat the two flags as the same lever: --disable-pinned-memory removes the page-locked buffer, while --fast-disk additionally puts the weights somewhere the kernel is allowed to take back — "Anonymous memory cannot be reclaimed — if it does not fit you swap or OOM. Page cache can be reclaimed: the OS drops it and re-reads from NVMe." Whether adding it on top of --disable-pinned-memory buys a 32 GB box anything further is unpublished; the flag on the launch line above is the one the failure mode requires. Do not reach for --lowvram: its own help text in that file says "Doesn't do anything if dynamic vram is enabled."

Neither of the two RTX 3060 owners quoted on this page states which flags they launched with, so the on-card reports do not settle this by themselves — the arithmetic and the 31 GB report do.

Set the canvas down. On this card it is the biggest lever you have.

Queue the template unchanged first. Its ResolutionSelector is set to 16:9 at 0.4 megapixels with a multiple of 32, and its two outputs are wired into the generation node's width and height inputs — a connected input beats the stored widget value, so the 1344×768 sitting in the node's widgets never reaches the sampler. sqrt(0.4 × 1024² / (16×9)) = 53.9695, rounded to the nearest 32 per axis, gives 864 × 480. Frame count snaps to a 17k+5 grid at 24 fps, so a 5-second request becomes 124 frames; the node's own tooltip gives the trained range as 124-362.

The template ships a reference table for that one number, and every canvas anyone has reported from this card is a row in it:

megapixels	16:9 output	what was reported here
0.4	864 × 480	the template default; the 4.5-minute Turbo run below
0.5	960 × 544	the "works without any problem" run in discussion #16
0.98	1344 × 768	the generation node's own default, and H3's MAX_PIXELS constant
1.0	1376 × 768	the 20-minute run below — one row above the model's own cap

Stay at 0.4 for anything you are still iterating on. BASE_SHORT_EDGE is 768 and MAX_PIXELS is 768 * 1344 in comfy_extras/nodes_minimax_h3.py, so 0.98 MP is the native canvas and the RTX 3090 write-up's summary — "Practical canvas ceiling is 1344x768" — is a statement about the model, not about your card. Your card's ceiling is lower for a different reason: cost. Every extra token is paid for twice here, once in compute and once in transfer, because the transformer is not resident — and a 12 GB card is under maximal offload pressure at every canvas, so the second half of that bill never goes away. Nobody has published a scaling curve for this tier, but the owner of the two runs below put the practical version of it plainly in discussion #30: "render times grow exponentially as the resolution, video length, and the number of steps increase". Frame count is the other half of the same lever — the RTX 3090 write-up measured 124 frames at ~12 s/step against 362 frames at ~67 s/step on one card and concludes "Extrapolate by frames superlinearly, never by a flat per-step figure."

Output lands in ComfyUI/output/video/ as an MP4 with the stereo track already muxed in.

Results

• Speed — this is the one page in this family with numbers taken on its own card. Our catalogue still holds no benchmark for the pair: /check/minimax-h3/rtx-3060 returns verdict: unknown with an empty benchmark list. What exists is published by owners. Near the native canvas, at 24 steps, plan in tens of minutes: an RTX 3060 12GB owner reported in discussion #30 — "RTX 3060 12GB | T2V | 1376x768 | 24 steps | 3 sec (20 min was crazy!)" — twenty minutes for three seconds of video. At the template's own 864×480, with an 8-step Turbo LoRA, the same owner measured 4.5 minutes for five seconds (see the section below for why that run is a lead rather than a benchmark). Both figures give the card, the canvas, the step count and the duration; neither says which of the repack's weight files was loaded, and the two differ in canvas, steps and clip length at once — so read them as two points on this card, not as a controlled comparison.

  Between those two sits the number most readers actually want, and nobody has published it. The stock 20-step path at the template's own 864×480 is the obvious first thing to run on this card and there is no measured figure for it anywhere — not on the repack's discussion board, not in the ComfyUI tracker. A release-week guide does carry a 12 GB row with that configuration attached, but it cites no source and its own authors disclose that they did not run the model, so it is a number with no provenance rather than a third datapoint. What the two runs above do bound is the shape: the same card needs 4.5 minutes for five seconds once the step count is cut to 8, and twenty minutes for three seconds at 24 steps a row above the model's own canvas cap. Expect the stock path to sit between them and closer to the slower end, and expect your own RAM and SSD to move it — see Running. A measured stock-path run posted through /contribute would replace this whole paragraph, and it is the single most useful thing a 3060 owner could contribute to this page.

• VRAM usage: 20.721 GiB at the binding denoise stage — 19.530 GiB of int8 transformer weights plus ComfyUI's 1.191 GiB inference reserve floor — against a 12 GiB card, so at most 10.809 GiB is resident and at least 8.721 GiB streams. Derived from the on-disk byte counts and ComfyUI's own constants, not measured by us. The nearest measured readings are one tier up and are quoted in full at the top of this page: UdonJP's 14,197 MiB and 14,437 MiB whole-run peaks on a 16 GB RTX 5070 Ti, one person's report from one machine. Both exceed a 12 GiB card outright, which is corroboration that this card must offload rather than fit — and that it does not OOM anyway is the point of the whole page. Live data, when it exists, will be at /check/minimax-h3/rtx-3060.

• Quality notes: the model's known weakness is faces, and it is a model property rather than a card one — you cannot buy out of it with a bigger canvas. The same RTX 3060 owner opened discussion #30 with "MiniMax heavily distorts faces on wide shots. Distortions happen regardless of input res (even at 720p, very bad). Close/medium shots look fine!", and after re-testing at a higher resolution and 24 steps reported the same artefacts. Frame for close and medium shots. He is also blunt about the audio on his own runs — the voice-over prompt ignored, words hallucinated, custom audio glitching mid-generation — which is worth reading before you plan a workflow around the synchronised soundtrack. EasyCache, the accelerator you will be pointed at first, has one published complaint against it and no published defence: a commenter in the same thread says "Using 'EasyCache' node also degrades the quality of the final result.", and nobody has posted an A/B of the node on this card or on any 12 GB card. Run your own at a fixed seed before leaving it on, and judge it by looking at the clip rather than by a difference metric.

For the full benchmark data, see /check/minimax-h3/rtx-3060.

Optional: the 8-step Turbo path — a well-populated lead, still not a benchmark

The 4.5-minute figure above is the fastest number anyone has published on this card, and it is the one to be most careful with. Its author's own post in discussion #35 says: "Everything was tested on an RTX 3060 12GB. Rendering a 5-second video at 864x480 resolution with Turbo at 8 steps took 4.5 minutes." Read what else that run changed:

1. an 8-step Turbo LoRA driven by a third-party node pack, Larryvrh/ComfyUI-MiniMax-H3-Turbo;
2. Kijai's experimental minimax_h3_video_vae_int8_convrot.safetensors (2.954 GiB, against the official VAE's 4.850 GiB), from a repo whose card states the runtime condition itself: "int8_convrot VAE needs ComfyUI 0.31.0 or you get black outputs";
3. and therefore a ComfyUI newer than the v0.30.2 tag this page installs. That VAE arrived in ComfyUI PR #15334, whose author writes "Adds suppport for int8_convrot quantized VAE for MiniMax-H3, tested that the VAE quality looks fine and it's about 1.5x faster." — merged on 6 August 2026, a day after v0.30.2 was tagged. grep -i convrot comfy/sd.py at v0.30.2 returns nothing; on master it returns the int8+convrot decoder branch.

Three non-stock components, one run, one person. And the only direct quality question that run drew — "Seems interesting, have the turbo node degraded the quality?" — is still unanswered in that thread.

What has changed since the rest of this family was written is the packaging, not the breadth and not the rigour. A second repository appeared — drbaph/MiniMax-H3-Turbo-Lora-ComfyUI, six files, Apache-2.0 tagged, published 6 August 2026 — and it is easy to read as a second opinion. It is not. Its own card opens by calling the contents "third-party ComfyUI compatibility conversions of the original" Turbo LoRA by larryvrh, states that its author did not train or distil the weights, and its six filenames correspond one-for-one with larryvrh's six. Same weights, same distillation, same single author behind them — so no amount of it adds up to a second measurement.

It is still the version you would reach for here, for a mechanical reason worth knowing: the card describes the files as "modified compatibility versions intended to allow the compatible LoRA adapters to load with ComfyUI's built-in MiniMax-H3 LoRA loader when using the pruned/curve-form model", and the pruned checkpoint is exactly what this page installs. A second reporter in discussion #30 gives working settings — 2.8 LoRA strength at 4 steps, with "1.0 MP is the sweet spot." — but names no hardware and gives no timing, so it does not transfer to this card as a number. Follow this path if you are willing to run experimental components; do not plan a schedule on it. Note also that the Apache-2.0 tag on an adapter covers the adapter — the base weights it loads against stay under the territorial agreement described at the top of this page.

Troubleshooting

ComfyUI is killed, or throws MemoryError, while loading the model

System RAM, not VRAM, is what usually ends an H3 run on this card — which is why --disable-pinned-memory is in the launch command above rather than here. If ComfyUI dies during the model load even with the flag set, look for the line Enabled pinned memory in the startup log: if it is present, the flag did not take effect. Adding swap does not help on its own, because pinned pages cannot be paged out; the RTX 3090 write-up also measured --disable-smart-memory, --high-ram, --reserve-vram and --cache-lru and found each of them made this failure mode worse rather than better.

A MemoryError raised specifically by UNETLoader has a second, duller cause — a truncated download. A user who hit it on this repack confirmed the file was the right byte size but the wrong hash. Re-hashing a 21 GB file is cheaper than re-diagnosing it.

Generation is far slower than the numbers above

Grep the startup log for Failed to import comfy_kitchen. When that backend fails to import, the int8 convrot fast path dies silently while ComfyUI carries on running normally — one buried error line and no other symptom. The same applies to a torch build below cu130. On a card whose whole performance story is offload, either one turns a slow run into a much slower one.

Device-mismatch RuntimeError during VAE decode

Partial CPU offloading of the H3 video VAE used to crash with Expected all tensors to be on the same device, from comfy/ldm/minimax/vae.py. That was ComfyUI issue #15251, filed from a card small enough that the VAE itself had to offload, and it is now closed as fixed upstream. Check your ComfyUI version before anything else if you see it: Installation step 1 pins v0.30.2, which is well past the fix.

You are unlikely to reach the video-VAE case here: the decode row in the table above clears a 12 GiB card by 5.695 GiB, so the video VAE does not have to offload on this card. What you can still hit is the audio VAE — two lines in comfy/ldm/minimax/audio_vae.py are a separate and, per the same notes, still-open case, met when feeding a reference video's audio track.

The GGUF quantisations still will not load on stock ComfyUI

Pruned Q4 GGUF builds of the transformer circulate at 10.596 GiB and 10.636 GiB — minimax_h3_fl2va_pruned_fp8_Q4_0.gguf at 11,377,542,880 B in molbal/MiniMax-H3-GGUF and minimax_h3_fl2va_pruned-Q4_K_M.gguf at 11,420,663,904 B in leejet/MiniMax-H3-GGUF, both from the tree API — and they look like the obvious answer for a 12 GB card. Note where they are not: the two GGUF repos named in the discussion threads cited above, Abiray/MiniMax-H3-GGUF and realrebelai/MiniMax-H3_GGUFs, publish no transformer smaller than 14.50 GiB, so following the thread will not lead you to these files. With the stock loader they remain a dead end, for a mechanical reason you can check yourself: ComfyUI-GGUF/loader.py gates diffusion models against an IMG_ARCH_LIST of flux, sd1, sdxl, sd3, aura, hidream, cosmos, ltxv, hyvid, wan, lumina2 and qwen_image — with nothing for H3, unchanged as of this writing. Issue #471 requests H3 support and is still open. The text encoder is the exception: qwen3vl is on the same file's TXT_ARCH_LIST, so the encoder GGUFs do load.

You have a second GPU in the machine

A 12 GB card is often the secondary one. Dynamic VRAM streaming has an open multi-GPU failure — HostBuffer.read_file_slice failed cascading into a spurious CUDA out-of-memory — filed in ComfyUI issue #15255 from a box with an RTX 3060 12GB as the second card. The maintainers' note at the top of that thread says it has been reported to NVIDIA and gives the workaround: "To workaround, please start comfy with --cuda-device 0 (or a higher number) to restrict comfy to a single GPU or use --disable-pinned-memory for multi GPU functionality". The second half of that is already your launch line.

You want 2K output

You cannot get it locally today. See the note at the top: H3-Regenerate-2K is not part of the open-weights release, and the official route to 2K is to feed your local 768p result back to MiniMax's hosted API — a call that falls under the same territorial licence.

Nothing here matches your problem

Runtime errors belong at ComfyUI/issues and template problems at workflow_templates/issues. And if you get a clean run on this card, a timing sent through /contribute is worth more to the next reader than every derived number on this page — a measured stock-path 864×480 run is the single most useful thing still missing here.