What You'll Build
A locally generated clip with native stereo audio from MiniMax H3, on a 16 GB Radeon RX 7800 XT, running ComfyUI through the ROCm stack rather than CUDA. The diffusion transformer alone is 19.53 GiB — larger than the whole card — so this is a streaming workload from the first step, and your system RAM matters more than your VRAM.
⚠️ Read the licence before you download 42 GB. MiniMax H3 is not open source. The MiniMax H3 Community License Agreement is territorially restricted: clause I.5 defines the Excluded Territories as "means the European Union, the United Kingdom, the Republic of Korea and the United States of America.", and clause V.4 reaches what you produce with it — "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 Comfy-Org repack this recipe installs does not relicense anything: its card carries the same
license_name: minimax-h3-community-license-agreementand links back to the same file. Read the agreement yourself — this is a summary by a reader of the text, not legal advice.
Hardware data: RX 7800 XT (16GB VRAM, gfx1101) · 19.53 GiB of int8 diffusion weights against a 16 GiB card · See benchmark data
⚠️ On this model the bigger Radeon is the broken one — do not assume a 7900 XTX is the safer buy. ComfyUI issue #15314 reports that on an RX 7900 XTX (gfx1100, 24 GB, Ubuntu 24.04 / ROCm 7.2.4) the "MiniMax H3 official T2V template (and every variant tried) generates pure noise / mosaic" — at 100% GPU utilisation, with the exact official four-file set. The reporter excluded both text-encoder quants, two samplers, three resolutions, both the HIP and eager backends, out-of-memory, and file integrity. That issue is open and unanswered as of 7 August 2026 — two comments, one of them a bot, no maintainer reply and no linked fix. Its author's own explanation was that the working card is newer silicon; a Comfy-Org contributor removed it — "The 7800 XT isn't RDNA4, so the hypothesis can't be correct." — and put nothing in its place. gfx1100 is unexplained, so this page is scoped to gfx1101 and nothing on it should be read as clearance for a 7900 XTX.
ℹ️ 768p is the ceiling here — the 2K in the marketing is not in the download. H3 reaches 2K through a separate
H3-Regenerate-2Kmodule, and MiniMax's own model card says of it: "this module is not yet open-sourced. We will release it once it is ready." — the official route to 2K is an API call back to MiniMax. The weights licence quoted above governs the MiniMax H3 Works and their Outputs; a hosted service is normally governed by separate platform terms, so read those too before you route anything through it. What runs on your card is H3-Base, whose card states "The shorter side is set to 768 pixels by default."
Requirements
| Component | Minimum | This recipe |
|---|---|---|
| GPU | 16 GB VRAM, RDNA3 (gfx1101) | RX 7800 XT (16GB) — not measured by us; the run cited below is a community report on this card (/contribute) |
| RAM | 64GB recommended; 32GB completes runs but swaps hard | — see Troubleshooting for the two source threads this rests on |
| Storage | 39.554 GiB of weights (42.47 GB as HuggingFace reports it), NVMe strongly preferred | 42.47 GB across four files (byte counts from the HuggingFace tree API) |
| OS | Windows or Linux, per your PyTorch build | Windows — the one report of correct H3 output on this card is a Windows box, and every figure on this page that came from it inherits that |
| Software | ComfyUI 0.30.1+, PyTorch on ROCm | — |
The four files the official text-to-video and image-to-video templates load:
| File | Size | Destination |
|---|---|---|
minimax_h3_fl2va_pruned_int8_convrot.safetensors | 19.530 GiB | ComfyUI/models/diffusion_models/ |
qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors | 14.610 GiB | ComfyUI/models/text_encoders/ |
minimax_h3_video_vae_fp16.safetensors | 4.850 GiB | ComfyUI/models/vae/ |
minimax_h3_audio_vae_fp32.safetensors | 0.564 GiB | ComfyUI/models/vae/ |
Your gfx target, and why it decides the checkpoint
The RX 7800 XT is gfx1101 — Navi 32, RDNA3 — per AMD's own ROCm system-requirements matrix, which lists it at gfx1101 alongside the RX 7900 XTX at gfx1100. Read the gfx id from that table, not from the coarser "select 7000 Series" compatibility page. Two things about that source, since this page's evidence is a Windows box: the gfx id is a property of the silicon and carries across operating systems, but the support claim on that page does not — it is the install-on-Linux matrix, and its footnote narrows even that to Ubuntu 24.04.4 / 22.04.5 and RHEL 10.1 / 9.7. HSA_OVERRIDE_GFX_VERSION is a Linux-only environment variable in the first place, and an officially-supported target does not need it, so on either platform the answer is the same: leave it unset.
That target is also why the int8_convrot diffusion checkpoint is the right one here and the fp8_scaled file (19.519 GiB, almost the same size) is not. The HIP kernels behind H3's quantised path arrived in comfy-kitchen PR #74, which covers gfx1100-gfx1103 — gfx1101 included — and states plainly that "gfx11 has no fp8 WMMA at all", so fp8 operands are widened to bf16 on your card: correct, but slower and with no memory saving. INT8 is the format RDNA3's matrix cores actually execute.
ComfyUI prints which is which at startup, and the line differs by architecture — which is the quickest way to confirm you are reading advice written for your silicon. On RDNA3 it reads Native ops: int8_tensorwise, convrot_w4a4 , emulated ops: float8_e5m2, float8_e4m3fn, mxfp8, nvfp4: fp8 and nvfp4 both emulated. That is the line in the gfx1151 Strix Halo log, and the gfx1100 report prints the same split. An RDNA4 card prints something different — the RX 9070 XT reporter in discussion #17 logs float8_e5m2 and float8_e4m3fn among the native ops on gfx1201 — so an fp8 recommendation sourced from a 9000-series post does not transfer to this card.
The NVFP4 text encoder being emulated is a speed cost, not a memory one. ComfyUI's supports_nvfp4_compute() returns false for every non-NVIDIA device, so the weights are dequantised per operation instead of expanding on load — as the RX 9070 XT reporter in discussion #17 put it, "it stays packed and dequantizes per-op rather than expanding to bf16". The 14.610 GiB file stays 14.610 GiB resident.
A caution about the maturity of that code. The HIP backend is compile-verified on your architecture but not run-verified on it by its author. PR #74 closes by asking for help: "Kernel changes to improve RDNA3 performance can only be properly validated on an actual RDNA3 GPU." — its test suite ran on a gfx1200. PR #93, which ports the partial-rotary rot_dim path H3's split-half RoPE uses, says the same thing more bluntly: "Run-verified on RDNA4 only - the test machine has a single gfx1200, which cannot execute gfx11 or gfx10 code." This recipe rests on a user report, not on vendor validation.
Installation
Order matters, and it is the reverse of the obvious one. ComfyUI's requirements.txt lists torch unpinned, so if you install the ROCm wheels first, pip install -r requirements.txt resolves a default-index wheel over the top and quietly replaces your ROCm build with a CPU one. Do ComfyUI first and the ROCm wheels last.
1. Install ComfyUI and its requirements
H3's nodes ship in ComfyUI core, not as a custom node, and nothing older than 0.30.0 will load these files — v0.30.0 is the release that carries PR #15224, "feat: Support MiniMax-H3". The working report on this card is on 0.30.1.
git clone https://github.com/comfyanonymous/ComfyUI
cd ComfyUI
git fetch --tags && git checkout v0.30.2
pip install -r requirements.txt
Read the next paragraph before you settle on that tag. v0.30.2 (commit dec5d945) is the newest tag as of 7 August 2026 and is dated 2026-08-05 00:47 UTC — which puts it about two days before PR #15243 merged on 2026-08-06 20:36 UTC. That PR is the audio fix discussed under Results, so a pinned v0.30.2 does not contain it and no tag yet does. Pin the tag if you want a reproducible baseline and can live with the sampler workaround below; check out master if you want the audio fix, and accept that you are on an untagged commit.
2. Install a ROCm PyTorch for RDNA3
ComfyUI's own README publishes two AMD routes. Take the RDNA3-specific index, which builds for gfx110X:
pip install --pre --force-reinstall torch torchvision torchaudio \
--index-url https://rocm.nightlies.amd.com/v2/gfx110X-all/
The README files that index under a heading that calls it experimental and notes it has less hardware support than the stable builds — pass that along to yourself before you file a bug. Take it anyway, for two reasons. It is the only one of the two that serves Windows at all: the alternative below sits under a heading reading "AMD GPUs (Linux)", and this page's only evidence of correct H3 output is a Windows box. And it is the family that produces the version string that report is running, PyTorch 2.12.0+rocm7.14.0 — the stable channel produces +rocm7.2-shaped versions instead.
The Linux-only alternative, for completeness:
pip install torch torchvision torchaudio \
--index-url https://download.pytorch.org/whl/rocm7.2
Nobody has reported MiniMax H3 on a gfx1101 card through that channel. The rocmX.Y suffix on it also moves between releases, so read the live README before pinning anything.
Confirm the install took before you download 42 GB: python -c "import torch; print(torch.__version__, torch.cuda.is_available())" should print a version containing rocm and True.
3. Download the four model files
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 internal paths are already diffusion_models/, text_encoders/ and vae/, so --local-dir models puts all four where the loaders look. Pass the filenames as positional arguments, as shown.
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. The ComfyUI tutorial documents this template plus the image-to-video and reference-to-video variants.
If you want to reproduce the verified run rather than merely a run, start with Image to Video. That is the template the RX 7800 XT report used, and video_minimax_h3_i2v.json loads the same four files and the same MiniMaxH3ImageToVideo node as the text-to-video one — connect a first_frame and it switches path by itself. The distinction is not academic on AMD: the gfx1100 failure is specifically on the text-to-video graph, and that reporter's image-to-video attempt failed a different way again, with a SIGABRT crash they log separately as a host-memory problem. Reference-to-video is a third path with its own checkpoint download and its own, larger memory peak — leave it until last.
Running
One honesty note before the command. The RX 7800 XT run this page rests on was not launched this way at all. It was ComfyUI Desktop, with no command-line flags — in the reporter's own words, "I just uses the default Desktop deployment." Two deliberate divergences follow from that. The Installation section above reconstructs the run as a manual git clone deployment, because Desktop is not scriptable and a recipe has to be written as commands; and the flag in the command below is borrowed from two AMD reports on a different card, included because the crash it prevents is cheap to avoid and expensive to diagnose. Neither is part of the configuration anybody has actually proven. If you are already on ComfyUI Desktop and never meet that crash, stay there — you are closer to the verified setup than these instructions are.
python main.py --disable-smart-memory
Queue the template unchanged first, and know what "unchanged" actually means — the values stored on the generation node are not the values it runs. Its width, height and length are all wired inputs, and a connected input beats a stored widget, so the 1344, 768 sitting in MiniMaxH3ImageToVideo never reaches the sampler.
- Resolution comes from a
Resolution Selectornode. In the text-to-video template it is set to16:9 (Widescreen)at 0.4 megapixels, multiple 32 — and the templates ship their own reference table, whose matching row reads0.4 | 16:9 | 864 x 480. The image-to-video template ships the same 0.4 megapixels at1:1 (Square)instead, so its stock canvas is square rather than widescreen. To reach H3's native 1344×768, set the selector to 16:9 at 0.98 megapixels — that is the row that reproduces the node's own stored default. - Length comes from a
Float (duration)primitive through a math expression,max(5, round(a * 24)) + (5 - (max(5, round(a * 24)) % 17)) % 17, which snaps seconds onto H3's 17k+5 frame grid. Both templates ship a duration of 5, giving 124 frames — 5.17 s at the 24 fps theCreateVideonode is set to. The2stored inside that primitive is itself an overridden widget; ignore it. - Steps and sampler are
BasicScheduleratsimple, 20 steps, withKSamplerSelectatres_multistep, in both templates. Remember that combination when you read the audio note under Results.
Why --disable-smart-memory is in that command
It is the documented fix for an AMD-specific crash when the video VAE loads. In discussion #17, a Windows user hit torch.AcceleratorError: CUDA error: invalid argument (hipErrorInvalidValue) the moment MiniMaxH3VideoVAE was requested, and reported the flag fixed it; a second user on the same card under Linux independently confirmed the same flag clears the same crash with no other patches. Both of those reports are on an RX 9070 XT rather than on this card, and the working RX 7800 XT run did not mention hitting it — so treat the flag as cheap insurance rather than a certainty about your box. comfy/cli_args.py describes it as forcing ComfyUI to offload to regular RAM instead of keeping models in VRAM, which is the behaviour you want here anyway.
What the memory actually does on 16 GB
ComfyUI holds one large module on the GPU at a time. The table below is written against a 16 GiB card using ComfyUI's own reserve constants from comfy/model_management.py, and it uses the Linux floor — a 0.8 GiB base plus a 400 MiB extra reserve, giving 1.191 GiB — because that is the smaller of the two and therefore the friendlier case. Windows is tighter; the paragraph under the table works that out, and it is the platform this page's only good run was on.
| Stage | Resident weights | Reserve | Stage total | Against 16 GiB |
|---|---|---|---|---|
| Text encode (Qwen3-VL-32B, NVFP4-AWQ) | 14.610 GiB | 1.191 GiB | 15.800 GiB | clears by 0.200 GiB |
| Denoise (the H3 DiT, pruned int8+convrot) | 19.530 GiB | 1.191 GiB | 20.721 GiB | 4.721 GiB short |
| Decode (video VAE fp16) | 4.850 GiB | 1.455 GiB | 6.305 GiB | clears by 9.695 GiB |
The middle row is the whole story: the diffusion transformer cannot fit, at any resolution, and no flag changes that. ComfyUI streams the shortfall from system RAM and pays for it in wall-clock time rather than in an error. The decode reserve comes from the first-party estimator for this VAE in comfy/sd.py, (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; at 1344×768 it rises to 2.851 GiB, still nowhere near binding.
Two consequences worth planning around.
First, every row moves with your OS — but only one of them changes verdict. EXTRA_RESERVED_VRAM is global: it is 600 MiB on Windows rather than 400, plus another 100 MiB once the card reports more than 15 GiB, which lifts the floor from 1.191 GiB to 1.484 GiB and shifts all three stage totals by 0.293 GiB. Denoise is short either way (21.014 GiB and 5.014 GiB short on Windows, against the 20.721 and 4.721 above), decode clears either way, and only the text-encode row crosses the line: it clears a 16 GiB card by 0.200 GiB on Linux and lands at 16.093 GiB on Windows, over the card.
That matters because the run this page is built on is a Windows run — it completed, with correct video, at the stage total that does not fit. But do not read the Linux column as the safer one just because the number is smaller. The constant's own source comment says why it is bigger:
EXTRA_RESERVED_VRAM = 600 * 1024 * 1024 #Windows is higher because of the shared vram issue
"Windows is higher because of the shared vram issue" — WDDM lets the driver back GPU allocations out of system memory once VRAM is exhausted, so an over-budget stage there degrades into a slow shared-memory spill instead of failing. That is a third candidate for how a 16.093 GiB stage completed, alongside streaming the encoder or placing it on the CPU, and it is the only one of the three with no equivalent on ROCm, where an over-budget allocation is a hard HIP out-of-memory. So a Linux reader gains 0.293 GiB of bookkeeping margin and gives up the net that margin exists to pay for. Treat the extra headroom as real and the extra safety as not.
Second, --lowvram is not the free win it looks like. cli_args.py documents it as putting the text encoders on the CPU when dynamic VRAM is not in use, and the RX 9070 XT reporter in discussion #17 measured that CPU encode at 90-104 seconds per new prompt on a Ryzen 9 3900X. It is cached between runs of the same prompt, which makes it easy to under-count when you benchmark.
Output lands in ComfyUI/output/video/ as an MP4 with the stereo track muxed in.
Results
- Speed: we have not measured this pair, and the backend carries no benchmark rows for it — /check/minimax-h3/rx-7800-xt returns
verdict: unknown. The one on-card figure that exists is a community report in ComfyUI issue #15283, from the same user and the same box as the working-output report below: "I can finish a whole i2v run (0.8 megapixel 5 second 24fps) in 1.5 hour.", adding "I just uses the default Desktop deployment." — i.e. no tuning flags at all, at double the template's stock pixel count. Plan in hours per clip on this card, not minutes. A second commenter in the same thread, claiming the same hardware, reports the opposite end of the spread: "I'm unable to get 0.3 megapixel 5 second output at 24fps at anything lower than an estimated 2 hours." — that one is an estimate rather than a finished run, and the hardware claim is self-reported, but the gap between the two is the honest error bar on an untuned box. Please post a measured run through /contribute. - That the output is correct, not merely that it completes: this is the load-bearing fact for an AMD H3 page, and here it is explicit.
salty-fish-114514, the reporter of issue #15283, ran the "Official MiniMax H3 image-to-video template workflow, unchanged" on "The smallest/pruned model set (nvfp4 qwen3vl, INT8 diffusion model, fp16 video VAE," (the sentence continues onto the next line with the fp32 audio VAE — the same four files installed above). Their setup block has five lines and all five matter: ComfyUI 0.30.1 Desktop, Windows, an "AMD Radeon RX 7800 XT, 16 GB VRAM (ROCm 7.14)", 64 GB of RAM, and PyTorch 2.12.0+rocm7.14.0. They opened the issue about the audio, and said of the picture: "The video comes out perfect", closing with "Video generation works great otherwise". The same box appears on the repack's discussion board under the handlewhw2026, linking back to this issue and repeating the setup block verbatim — "I have run the whole pipeline with amd gpu, although the audio sounds like a blown microphone." The video was looked at and judged good; that is a materially stronger claim than a run that merely finished, and it is the reason this page exists while the 24 GB sibling card does not have one. Read every figure on this page that traces to that report as a Windows figure. - VRAM usage: 20.721 GiB at the binding denoise stage against 16 GiB of card — a 4.721 GiB shortfall that ComfyUI covers by streaming. That pair is the Linux figure, to match the table under Running; on Windows, the platform this page's report was on, the same stage is 21.014 GiB and 5.014 GiB short. Nothing you do changes either way — the transformer streams at both numbers. Derived from the on-disk byte counts above and ComfyUI's own reserve constants, not measured by us; see /check/minimax-h3/rx-7800-xt.
- Quality notes: the audio defect in that report is real and is not an AMD problem — but it is not fully fixed either, and the difference matters on a card this slow. The axis is the sampler.
whitespace-rebel, testing in the same thread, found that "euler_ancestral, lcm, and dpmpp_3m_sde for example completely destroyed the audio during my test run." and advised "Avoid any sampler with 'ancestral' or 'sde' for Minimax H3." Their own recommendation list is a gradient rather than a dichotomy, though, and it puts the official default on the worse-sounding end —gradient_estimationis described as "smoother than dpmpp_2m and res_multistep". That matters becauseres_multistepis what the report was filed from: both official templates shipKSamplerSelectset tores_multistepwithBasicScheduleratsimple, 20 steps — deterministic, and not a low step count. PR #15243 by kijai, merged 6 August 2026, fixes the root cause for the class it names — "Allows audio to work with stochastic samplers and low step counts." — and the template default is in neither category, nor has anyone re-tested that path since the merge. So: treat the sampler swap under Troubleshooting as the remedy that is actually evidenced here, and the PR as a real improvement of unproven reach for the default graph. One more caution from the PR itself, while you compare renders across ComfyUI versions: "Output changes for MiniMax-H3 at every step count.", video included.
For the full benchmark data, see /check/minimax-h3/rx-7800-xt.
Optional: the Turbo LoRA
A community distillation adapter, larryvrh/MiniMax-H3-Turbo-Lora, and its node pack Larryvrh/ComfyUI-MiniMax-H3-Turbo cut sampling to a handful of steps. On a card that measures its clips in hours this is the single most attractive lever available, and it is also the least verified thing on this page: the step-reduction figures come from the adapter's own author, nobody has published a before-and-after on any AMD card, and the pack needs its own sampler because a stock one over-steps H3's separate audio schedule.
Its quality cost is contested even on NVIDIA. Two open threads on the adapter's own discussion board are worth reading before you commit an hour to it: one reports severe visual degradation, ghosting and audio corruption at 4 steps on this exact pruned_int8_convrot checkpoint, and another reports the ckpt850 variant emitting a wall of lora key not loaded warnings. Try the Turbo path after you have a known-good baseline render, never instead of one.
Troubleshooting
ComfyUI dies with no Python traceback on the first sampling step
On Windows this can be a hard native fault rather than an error you can catch. comfy-kitchen issue #61 reports exactly that on gfx1101 — a 0xC0000005 access violation the instant the int8_tensorwise matmul executes, with the process killed before Python regains control. That report is from 30 June 2026 on comfy-kitchen 0.2.15, a month before the HIP backend of PR #74 landed, and it remains open with a contributor pointing at a local workaround branch rather than a merged fix. The practical response is to keep comfy-kitchen current so the HIP backend registers for your architecture, and to check the startup log for a HIP-backend line before blaming the model.
The audio comes out blown-out, crackling or overdriven
Change the sampler before you change anything else, and budget for it. In issue #15283 whitespace-rebel recommends, in order, euler (the most natural-sounding), gradient_estimation, ipndm — explicitly not ipndm_v — deis, and heun with the caveat that it is the slow one. The reporter on this card tried them and confirmed the trade in one sentence: "Thanks a lot! those sampler did help, but at the cost of increased generation time, its quite fair, LoL", then closed the issue. Nobody has published what that surcharge is in minutes, and on a card whose baseline is measured in hours it is the difference between an evening and an overnight — so change one thing, re-render the same seed and prompt, and time both. If you are on a master checkout that includes PR #15243, try the default res_multistep first: the fix may make the swap unnecessary, and nobody has checked.
The run is killed, or the machine swaps itself to a standstill
System RAM ends more H3 runs than VRAM does — ComfyUI stages the full 42.47 GB working set. The RX 7800 XT box this page is built on lists 64 GB, and so does the RX 9070 XT box in discussion #17, whose owner measured why: "Peak system RAM reached about 56GB of 62GB, so 32GB machines will likely struggle."
Note the word struggle, not fail. The same thread's original poster is on 32 GB with an RX 9070 XT and does get output — they report python main.py --disable-smart-memory as "work perfect." — but also that "I fount 32g ram + vram on windows use swap frequencely", with 10-30 GB written to SSD on a single run. So 32 GB is a working configuration that will grind your drive, not a wall. If that is you, add --fast-disk on an NVMe, which cli_args.py documents as preferring disk-backed loading over unpinned RAM — page cache is reclaimable, anonymous memory is not.
Your timings do not scale the way small test renders predicted
They will not. As the latent grows, less of the 19.53 GiB transformer stays resident and more of it crosses the bus every step, so the cost curve steepens rather than staying linear. The RX 9070 XT reporter in discussion #17 quantified this on a 16 GB card of a different architecture — same capacity, same model, so the offload regime is the same arithmetic even though the speeds are not comparable — and found that a low-resolution extrapolation undershot their real 1344×768 run by 38%. Their conclusion: "Don't extrapolate H3 timings on a 16GB card from small test renders." Benchmark at the resolution you intend to use.
You want 2K output
You cannot get it locally. See the note at the top: H3-Regenerate-2K is not part of the open-weights release, and the official path to 2K is an API call back to MiniMax — which puts you under MiniMax's platform terms as well as the weights licence, both of which are worth reading if you are anywhere near an Excluded Territory.
The output is noise rather than video
Do not assume this page's evidence covers you. It is scoped to gfx1101; the open gfx1100 report describes a card that computes at full speed and emits garbage, with no fix and no explanation. Confirm your gfx target first (rocminfo, or the AMD arch line ComfyUI prints at startup), and if you are on gfx1101 and still seeing noise, that thread is where the report belongs — it currently has a sample size of one.
Hit something this page missed? Send it via the submission form — a measured RX 7800 XT run, with flags and wall-clock, is the single most useful thing this page is missing.