MiniMax H3 Runs on One AMD Radeon Now. Read the Benchmark File, Not the Headline.
A local video-plus-audio pipeline for a single 32 GB Radeon shipped this morning. It comes with a 16.66 percent speedup, a performance target its own authors admit they missed, and a measured audio defect that nobody in this category is talking about.
Somewhere in the benchmark file for a release that went live at 06:56 UTC this morning is this sentence: "The 20% end-to-end latency engineering target remains unmet; the 19.99% throughput gain is a different metric."
That is a vendor telling you, in its own launch document, that it aimed for a number and did not reach it, and then refusing to let a nearby number that did clear 20 stand in for it. I have read a lot of model cards this year. I cannot remember the last time one did that.
The release is EliovpAI/MiniMax-H3-W4A8-Paiton-RDNA4, and the headline is genuinely good news: MiniMax H3, the 33-billion-parameter open model that generates video with its own synchronized soundtrack, now has a documented path onto a single AMD card. Radeon owners have spent two years reading local-generation benchmarks they could not reproduce. That ended this morning.
But the speedup is the least interesting thing in the package. The interesting things are in BENCHMARKS.md, and one of them is a defect in the audio that will land in your timeline if you use any model in this category.
What actually shipped
One 32 GB Radeon AI PRO R9700 on gfx1201. The default workflow produces a continuous 15.0833-second clip at 864×480, 24 fps, with native 32 kHz stereo audio generated jointly with the picture rather than added afterward. Install is one command that clones a repo and runs launch.sh, which pulls a versioned container image, verifies checkpoints against a lock file, and opens ComfyUI on localhost with the workflow already wired and an engine toggle sitting in the graph.
The comparison is Paiton, a compiled runtime, against the stock path. Same pinned checkpoints, same Turbo adapter, same sampler settings, so the only variable is the engine. Paiton takes 332.85 seconds against 399.40 stock. That is 16.66 percent lower latency and 19.99 percent more finished clips per hour, from 9.01 to 10.82, with fresh prompt conditioning and MP4 writing inside the clock.
All three paired long clips came out with equal video and audio latents and byte-identical MP4 files. So whatever else is true about quality, the two engines are producing the same bits. The comparison is exact in a way most engine comparisons are not.
Where the time went, and where it refused to go
This is the table that should change how you plan a shoot day. Component means, in seconds, stock against Paiton:
| Component | Stock | Paiton |
|---|---|---|
| conditioning | 21.718 | 10.821 |
| sampling | 317.987 | 262.296 |
| video decode | 42.521 | 42.473 |
| audio decode | 3.345 | 3.370 |
| encode and mux | 13.800 | 13.873 |
Conditioning roughly halved. Sampling dropped 55 seconds. And video decode moved by forty-eight thousandths of a second, which is to say it did not move at all.
Sit with that. The video VAE is 42.5 seconds of a 333-second job. Roughly one eighth of your wall clock is a decoder that nobody has optimized, on any platform, in any of the four speed releases that shipped this week. Every optimization effort in open video generation this year has gone into the denoiser: fewer steps, fewer guidance branches, cheaper attention, compiled kernels. Sampling has now been attacked from four directions in two weeks.
Keep that up and the decoder becomes the whole story. Cut sampling another 40 percent and the job falls to about 228 seconds, at which point video decode is 18.6 percent of your wall clock without having improved by a millisecond. The team that publishes a faster video VAE without changing a single pixel will buy creators more hours than the next distilled adapter will, and right now nobody is working on it, because decoders do not make good headlines.
The audio finding that should worry you
Buried in the correctness section is this. On a "pouring water" prompt, the four-step model produced audio with two channel samples at or above full scale, peaking around 1.00053. The eight-step version of the same prompt produced five such samples, peaking around 1.02007. The file says the native waveform reaches its decoder clamp, and then adds a sentence I want to frame: "No normalization, audio replacement or mixing hides these shared limitations."
Here is why that matters and why it almost certainly is not an AMD problem.
Clipping means the waveform tried to go louder than the format can represent, so the tops of the peaks get flattened into a straight line. That flattening is distortion, and it is baked into the file you receive. You did not cause it in your export. You cannot fix it by turning the clip down afterward, because the shape is already gone. And a track that peaks above full scale will fail a broadcast loudness check and can trip a platform's audio processing into doing something ugly on its own.
I doubt this is specific to the Radeon build. The audio VAE in this package is the only component left unquantized, so what came out is close to what the upstream model produces, and nothing in the compilation work touched the audio path. That is an inference and not a proof: I have not measured MiniMax H3's hosted output or its Blackwell and Apple ports, and neither has anyone else in public. The only reason we know it is happening here is that one team decoded its own output to float, counted samples at maximum, and printed the number. Nobody else in this category publishes that measurement, which is exactly why the question is open rather than settled.
There is a related detail in the same file that tells you how carefully somebody was watching. The clip contains 165,600 audio samples at 32 kHz, which is 5.175 seconds, against 5.1667 seconds of video. AAC decoding returns 165,888 because of padding. The card explicitly warns against describing the result as exactly five seconds or as sample-aligned. If you are cutting these into a sequence and trusting the durations to match, they do not.
One more structural note. Everything in this pipeline is quantized except one thing. The denoiser is W4A8. The text encoder is NVFP4 storage with FP16 compute. The video VAE is INT8 weights with BF16 compute. The audio VAE is left at full FP32. Somebody decided audio was where the bits had to stay, and given what the peak measurements show even at full precision, that was the right call.
The rejected experiments are the best writing in the file
Most releases publish the path that worked. This one publishes the paths that did not, and the failures are more instructive than the win.
A 4 GiB host memory cache saved about 1.3 seconds and caused the process to swap. Rejected.
Selective decoder projections saved roughly one second and changed the pixels, at an RMSE of 0.00189. Not promoted. A one-second gain in exchange for a different image is a bad trade and they said so.
Wider tiles, extra pipeline stages, alternate attention barriers and video-decoder graph capture all "lost or did not help."
And the one I keep thinking about: a bounded 11.34 GB conversion to W4A4 ran natively on RDNA4's INT4 WMMA instructions, produced a coherent clip, changed image detail and composition, and came out slower than the compiled W4A8 path at roughly seven seconds per denoiser evaluation.
Lower bit width did not mean faster. It meant slower and different pixels. That runs directly against the instinct every one of us has absorbed from a year of quantization headlines, which is that fewer bits is a strict improvement you pay for only in quality. On this hardware, at this precision, you paid twice. The team ran the experiment, got a result that undercut the fashionable direction, and published it anyway.
Put this into practice
If you have the card, the whole thing is one command:
git clone --depth 1 https://github.com/Eliovp-BV/paiton-vllm-plugin.git \
&& cd paiton-vllm-plugin && ./models/MiniMax-H3/launch.sh
Open 127.0.0.1:8190/?paiton=1. The Turbo8 fifteen-second workflow loads with the engine toggle already in the graph. Edit the prompt, fix the seed, hit Run. Budget an hour before your first clip: the container image is about 6 GB, the weights are 33.96 GB, and you want 60 GB free on an SSD. Don't skip the seed. Comparing engines with a floating seed tells you nothing.
To verify the vendor's own numbers rather than trusting them, stop the interface and run each engine into its own fresh directory:
./launch.sh --stop
./run.sh benchmark --engine stock --preset turbo8 --frames 362 --output /outputs/stock-15s
./run.sh benchmark --engine paiton --preset turbo8 --frames 362 --output /outputs/paiton-15s
./run.sh report /outputs/paiton-15s
Never reuse an output directory. Request 362 frames rather than 360, because H3 snaps frame counts upward to a 17k+5 grid and 360 silently becomes 362 anyway.
If you don't have the card, do the thing this release taught me to do, on whatever model you are already using. Check your generated audio for clipping. It takes thirty seconds:
ffmpeg -hide_banner -i clip.mp4 -map 0:a -c:a pcm_f32le -f wav - \
| ffmpeg -hide_banner -i - -af astats -f null - 2>&1 \
| grep -E "Peak level|Peak count"
The first pass decodes the audio to 32-bit float so peaks above full scale survive instead of being clamped by the integer conversion. The second pass measures them. Read the Overall block. Any Peak level dB at or above 0.000000 means you have samples pinned at maximum, and Peak count tells you how many. A handful of samples in a five-second clip is what this release measured and reported honestly. Hundreds means something in your chain is driving the signal hard and you should find out what before it reaches a client.
Run this on the last five clips you generated with any native-audio model. I did, and I stopped assuming the soundtrack was clean.
Honest limitations
This is Linux with Docker and working /dev/kfd and /dev/dri access, on one specific GPU. Not Windows, not a gaming Radeon, not "AMD support" in general. The pinned stack is exact: Torch 2.12.0+rocm7.14.0, Triton 3.7.1 ROCm, one named ComfyUI commit.
The card states outright that "original full-precision quality parity is unproven." Everything measured here compares two engines running the same lossy quantized checkpoint against each other. Nobody has compared this output against BF16 MiniMax H3. You are getting a rigorously verified equality with a path that is itself a compromise, and the size of that compromise is unmeasured.
Prompt adherence fails in documented ways. Four-step pouring produces two bottles when you asked for one. Eight-step pouring produces one bottle with too much foam and an incomplete final placement. The four-step fox and barista clips were reviewed and passed, including speech and lip sync on the barista, but those confirmations cover those clips and not your prompts.
The whole evidence base is a handful of fixed prompts at two presets. The file says so: "Sample size is small and fixed, without a general performance guarantee." Hosted context processing, 2K regeneration, image and reference conditioning, larger canvases and other durations are all outside the qualification.
And the licence is the real gate. MiniMax H3 ships under a community licence with territory and commercial-scale restrictions that the Paiton package does not and cannot relicense. The runtime bindings are Apache 2.0. The model is not. Read the terms before you put any of this in front of a paying client.
What I'd actually like to see next
I want the component table to become standard. Not the speedup, the table. When a project tells me conditioning fell from 21.7 to 10.8 seconds while video decode sat at 42.5 and did not budge, I can plan around it, I can tell where the next win is, and I can catch the moment a headline number is being carried by one phase while the rest of the pipeline stands still. A single percentage cannot do any of that.
The same team shipped an RDNA4 FLUX.2 Klein package two days before this one, with the same habit of naming what it did not achieve. Two releases is not a pattern yet. Three would be.
In the meantime, go run the ffmpeg check on your last five clips. If you find clipping in output from a model whose card says nothing about it, that is worth writing up, and I would like to read it.
Medium metadata
Primary sources:
- Release: https://huggingface.co/EliovpAI/MiniMax-H3-W4A8-Paiton-RDNA4
- Benchmarks: https://huggingface.co/EliovpAI/MiniMax-H3-W4A8-Paiton-RDNA4/blob/main/BENCHMARKS.md
- Runtime: https://github.com/Eliovp-BV/paiton-vllm-plugin
- Base model and licence: https://huggingface.co/MiniMaxAI/MiniMax-H3