FastH3 Omni: Distilled MiniMax H3 Runs Video+Audio on 36GB Mac with INT6
FastH3 Omni, a distilled version of MiniMax H3, enables local video-with-audio generation on a 36GB M4 Max Mac by using MLX and INT6 quantization to reduce peak memory from 123GB to 19.5GB, though benchmarks are limited to a single device and quality trade-offs remain unverified.
What FastH3 Is and Its Relationship to H3
The original H3 (H3-Omni-Transformer) is a 33B-parameter dense single-stream Transformer with three key traits: native dual-channel audio (video and audio generated in one forward pass, not silent video plus TTS), 768p base resolution (2K comes from a not-fully-open-sourced second-stage upscaler), and an open-source minimum usable set of ~42.5GB with BF16 full precision at ~123.6GB.
FastH3 is a distilled, slimmed-down version from the FastVideo project (Hao AI Lab, UCSD), hosted at FastVideo/FastH3-Omni-MLX on Hugging Face. It distills MiniMax H3 into few-step checkpoints: V1 (4 steps), V2 (8 steps, higher quality), and a Trim variant (42 transformer blocks, rank-16 AdaLN). The same codebase supports Apple Silicon via native MLX runtime and NVIDIA DGX Spark (GB10 / CUDA 13), with two Sparks able to collaborate on one clip. The core value remains: video + audio in one forward pass, locally, offline, no cloud upload.
How 19.5GB Was Achieved (Technical Breakdown)
Compressing the 123.6GB full-precision H3 to a 19.5 GiB peak on a 36GB machine relies on three techniques.
First: Four-Stage Phased Loading
H3 requires not only model weights but also a large text encoder, denoising working memory, and video/audio decoders. Loading everything at once would exceed 36GB unified memory. FastH3's Mac path runs in stages: encode prompt → denoise (video and audio together) → decode (frames + audio track) → export. Each stage loads only the weights needed at that moment and releases them afterward. The text encoder reads Qwen3-VL intermediate layers, skipping the last 14 layers, and streams the remaining layers, keeping only the prompt-relevant embedding rows. This reduced encoding time from ~80 seconds (cache miss) to ~17 seconds.
Second: INT6 Quantization
Weights are compressed from BF16 (16-bit) to 6-bit storage. Official benchmarks compare three tiers: INT8 retains more original weights (more stable quality), INT4 leaves most room for activations (lowest memory), and INT6 is the default, balancing weight and activation memory. INT6 is not a native MLX type; FastVideo affine-quantizes it and unpacks at runtime (see counter-intuitive point below).
Third: TAEH3 Preview Decoder
The full H3 VAE targets quality, taking 104 seconds for tiled decoding on M4 Max. TAEH3 is a preview path that finishes in 1 second, at the cost of softer details in hair, fabric, and distant scenery. Official guidance: use TAEH3 for rapid prompt verification, then switch to full VAE for final output.
Counter-Intuitive Finding: Smaller Weights ≠ Faster
H3 multiplies massive video/audio matrices. In this shape, unpacking quantized weights back to BF16 and using MLX's dense matmul is faster than a quantized kernel. Official measurement: 4-step INT6 denoising dropped from 386.47s to 348.75s, with bit-exact latent outputs, while MLX peak memory rose only from 19.31 GiB to 19.46 GiB. Quantization here primarily saves memory, not compute time.
Real-World Numbers
Official benchmarks on M4 Max 36GB , same prompt and seed, 832×480 / 124 frames / 4 steps :
Wall-clock time barely changes; peak memory shifts. INT6 end-to-end for a 124-frame (~5s, 24fps) clip: ~456 seconds ≈ 7.6 minutes. Acceptable for offline rendering, not real-time.
Memory scale comparison: from BF16 full suite 123.6GB down to FastH3 INT6 peak 19.5 GiB — local audio-video threshold cut from 128GB to 36GB.
On NVIDIA side, speedup is more dramatic: official vLLM-Omni H3 on a single DGX Spark at 1024×576, 5s, 50 steps takes 1881s; same shape with 4-step FastH3 takes 268s, ~7× faster. 832×480 is 8.4×, 1344×768 is 7.9×. Mac numbers aren't directly comparable due to unified memory and MLX path, but conclusion holds: few-step distillation is the key lever for local video generation.
Critical Caveat: Official Tests Only on One Machine
All Mac numbers come from a single M4 Max 36GB. No tests on M5 Max, 64GB models, 768p or longer video speed/quality boundaries, nor INT6 vs INT8 quality comparisons. "36GB Mac can run" is officially backed, but "runs smoothly", "quality loss", "768p OOM risk" have no official answers.
Two details:
INT6 is more aggressive than INT8 ; quality loss unquantified. For fidelity, INT8 or slower 8-step V2 are safer, at memory/time cost.
36GB machine at 19.5 GiB peak leaves only ~16 GiB for system + context. Higher resolution, longer video, or full VAE (more memory and time) will quickly tighten headroom, risking swap or OOM.
Additional context: the official 36GB recipe sets metal_wired_limit_gib (MLX fixed wired memory limit) to 27 GiB . This implies that on larger-memory machines, raising this limit or running 8-step V2 / Trim / higher resolution will likely push peak toward 27 GiB. So 64GB models with limit raised probably peak near 27 GiB, but no official 64GB benchmark exists yet.
Should You Adopt? (Decision Matrix)
Have a 36GB+ Mac (M4/M5 Max) → Can try. First officially backed "Mac local audio-video", offline, no cloud, no API fees. Start with TAEH3 for quick prompt validation.
Want 768p / long video / fidelity → Stick to 128GB+ or accept full VAE's extra time/memory. 36GB for these is "runs but tight".
Need production volume / speed → Don't bet on Mac. Previous 256GB M5 Ultra test on original H3 confirmed: Mac wins on "fits + quiet + power-efficient", loses on "slow output". It's an offline renderer, not real-time production. For speed, look at NVIDIA (DGX Spark single unit 7×) or cloud APIs.
Compliance → H3 uses MiniMax H3 Community License, which explicitly excludes USA, EU, UK, Korea from "local / self-hosted deployment" — domestic users running locally are fully compliant. Enterprises with annual revenue >$20M need separate commercial license; commercial product UI must credit "MiniMax H3".
Closing
From "128GB minimum" to "36GB can try", FastH3 slices another notch off the local audio-video barrier. Combined with H3 open-sourcing, community quantization, and Apple Silicon inference progress, local video generation is genuinely moving toward democratization.
But remember: official tests cover only one 36GB M4 Max. Don't let "can run" blind you — validate with small samples first. When official benchmarks for M5 Max 64GB, 768p, and long video arrive, we'll revisit with a "truly daily-drivable" hands-on.
Note: Mac benchmark data sourced from FastVideo / Hao AI Lab (UCSD) official blog and Hugging Face repo FastVideo/FastH3-Omni-MLX , all on M4 Max 36GB. H3 baseline (33B dense, 768p, open-source minimum 42.5GB, BF16 full 123.6GB, Community License geo-restrictions) from our September original H3 hands-on and analysis. 64GB model higher peak memory inferred from official metal_wired_limit_gib=27 config, not an official benchmark.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Lao Guo's Learning Space
AI learning, discussion, and hands‑on practice with self‑reflection
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
