How I Ran H3 on a 48 GB Mac Mini (and How You Can on Whatever You Have)

Companion to “MiniMax H3 Hardware Map.” Audience: Anyone who has tried (or is about to try) running MiniMax H3 on consumer hardware, especially Apple Silicon. Date: 2026-08-08 · Status: draft · Last verified against primary sources: 2026-08-08

Disclaimer: This article is an honest log of what I tried, what failed, what worked, and what I would do differently. If you’re looking for “here’s how to make H3 work on your Mac mini,” you’ll get the steps that produced success for some configurations and produced failures for mine. The point is to document the journey so you don’t burn hours on dead ends.

---

The honest summary

I tried to run MiniMax H3 locally on a 48 GB M4 Pro Mac mini for 5 Tier 1 video clips. I produced zero usable videos. I experienced:

• 5 failed ComfyUI generations (all paper texture, deterministic garbage)
• 1 Mac freeze/restart during model loading
• 3 orphan-recovery process failures with the Sawfwair MLX 4-bit port
• ~85 GB of downloaded model weights
• ~6 hours of wall-clock time
• $0 in API spend (because I never got the local path working)

Then I pivoted to the Hailuo API and shipped 5 Tier 1 clips at $0.50 total in ~5 minutes.

This article is the failure log so you can skip the dead ends.

---

What I started with

Hardware

• Mac mini M4 Pro, 48 GB unified memory
• macOS 26.x
• 460 GB total disk, 179 GB free after cleanup

Goal

Generate 5 short B-roll clips (5–10 seconds each, 720p or higher) for ATS RD launch + TAA book promo. Use the local H3 path to avoid the $0.50 API cost.

Mistake #1 — assuming the local path was available globally

I read the Yume_X hardware map post the day it came out. I assumed I could install H3 locally. I did not check the HF model card license for territory restrictions.

The license excludes the United States, European Union, United Kingdom, and South Korea. I was running this from the US. My local installation was not legally compliant.

If I had checked the license first, I would have pivoted directly to the Hailuo API. Six hours of work saved.

---

Phase 1: ComfyUI attempts (all broken)

What I downloaded

5 weight files totaling 39.55 GB, in this directory:

~/ComfyUI/models/
├── checkpoints/minimax_h3_fl2va_pruned_int8_convrot.safetensors  (19.5 GB)
├── text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors    (14.6 GB)
├── vae/minimax_h3_video_vae_fp16.safetensors                       (4.85 GB)
└── vae/minimax_h3_audio_vae_fp32.safetensors                       (0.56 GB)

The 5th file, ref2va.safetensors (19.5 GB), is reference-to-video mode only. I didn’t need it; I skipped it.

What I tried

#	Workflow	Prompt/Params	Result
001	R2V custom	”Hiring manager’s desk at night, single warm desk lamp, glowing resume…” 1344×768, 124 frames, 20 steps, seed 101	Paper texture
002	R2V custom retry	Same workflow, simpler prompt, seed 102	Same paper texture (frames byte-identical to 001)
003	I2V with Flux input image	Used Flux-generated “glowing resume on dark wooden desk” as first frame	Same paper texture (frames 0/62/123 byte-identical to 001)
004	I2V preview size + new flags	864×480, MPS fallback env vars, --force-fp16 --fp32-vae --use-pytorch-cross-attention	Different file, different frame MD5s, still paper texture
005	#004 + FP8 MPS patcher	Applied vSnake87/deardaveed’s patch_comfy_mps_fp8_full.py	Same as #004

The diagnostic finding

Frames at indices 0, 62, and 123 were byte-identical between #001 and #003 despite:

• Different workflows (R2V vs I2V)
• Different prompts
• Different seeds (101 vs 102 vs 12345)
• Different input image (Flux-generated vs none)

The failure is at the model level, not workflow configuration. H3 on MPS produces deterministic garbage regardless of input.

I checked the ComfyUI GitHub issue tracker. Comfy-Org#15315 matched my symptoms exactly. It was opened on 2026-08-05 by linuschen-star on Mac Studio M4 Max 128 GB. Official MiniMax H3 T2V workflow produces completely black video on Apple Silicon. The bug is confirmed, root cause unknown, no fix available.

Mistake #2 — kept trying after I had the smoking gun

I had the GitHub issue showing my exact symptoms. The right move was to stop, accept the upstream bug, and pivot. The wrong move was what I did — try different sizes, different prompts, an FP8 patch.

Burned 3 more hours on variations of the same broken path.

---

Phase 2: disk cleanup to make space

After 5 failed generations, my disk was at 80 GB free. I deleted:

• 4 Ollama models (qwen3.6 × 2 + ornith × 2) — 92 GB
• 3 unused ComfyUI encoders (umt5_fp8, t5xxl, clip_l) — 15.6 GB
• 4 broken ComfyUI H3 weights — 39.55 GB

Net reclaim: 147 GB. Disk back to 179 GB free.

Kept the Wan 2.2 5B weights + umt5 + wan VAE (active for our local-video-generation skill). Kept Flux Dev fp8 (image generation). Kept Darwin-36B-Opus MLX 8-bit (local LLM). Kept Gemma 4 (Ollama).

---

Phase 3: tried 8-bit MLX (failed disk math)

The candidate

pipenetwork/MiniMax-H3-MLX-8bit — README claims 35.3 GB download, 21.47 GB resident RAM, 27.6 dB PSNR vs bf16 (near-identical quality).

What I caught

I downloaded ~10 GB of model-00001 + model-00002 + partial model-00004. Then I caught a math error.

Why it failed

The README’s “21.47 GB resident” claim counts only the quantized transformer, not the full text encoder:

Component	Size
Text encoder (Qwen3-VL-32B) at upstream = full bf16	62.85 GB
Video VAE	9.70 GB
Audio VAE	0.56 GB
Transformer (8-bit)	32.88 GB
Total stack	~106 GB

I had 119 GB free. Downloading 106 GB would leave 13 GB — below the safe 20 GB threshold. Even if it fit on disk, resident RAM would be 50–60 GB which exceeds my 48 GB.

Lesson

Always sum the full stack when evaluating MLX port disk/RAM claims. A “21.47 GB resident” claim about the AdaLN precompute (13B of 33B params dropped because they only depend on timestep) does NOT include text encoder or VAE footprints.

---

Phase 4: pivoted to Sawfwair 4-bit (the right call, but didn’t work)

The candidate

sawfwair/MiniMax-H3-FL2VA-MLX-4bit — 43 GB total download (text encoder 8-bit quantized, transformer 4-bit), 27.7 GB peak RAM resident (validated on M4 Max 128 GB), 22 dB PSNR.

Why this fits

Resource	Available	Need	Status
Disk	190 GB	43 GB	147 GB headroom
RAM	48 GB	28 GB	Tight but fits

Download (2 attempts)

1. First attempt: sequential curl via bash script. Completed in ~75 min, but 2 files failed SHA256 verification (text_encoder 14.59 GB vs 26.28 GB expected, video_vae 0.12 GB vs 4.85 GB expected). Partial downloads from earlier pkill.
2. Second attempt: explicit redownload of failed files. All 14 SHA256 hashes verified.

Built the mere.run CLI

• Repo: github.com/sawfwair/mere-run
• Swift 6.0 package, build time 6:44
• Binary: 104.5 MB
• Version 0.34.0

Test generation: never completed

3 attempts to run mere.run video generate ... --model-root ... as a background process. All 3 returned “Orphan recovery” — process never actually started in the foreground/background as expected.

One Mac freeze/restart happened during one of the attempts (likely OOM during 28 GB model load). After restart, RAM at 0.3 GB free, climbing back to ~12 GB reclaimable after forced inactive-page eviction.

Memory pressure state at end of day

• Free RAM: 1.7 GB
• Compressed in swap: 26.6 GB
• mlx_lm.server running at 1.1 GB RSS
• mlx-proxy likely idle but reserved

Mistake #3 — assuming mere.run was the right CLI for H3

I framed mere.run as “the MiniMax CLI” in my Day-1 notes. It’s not. mere.run is a general local-AI toolkit that supports H3 among many models. The framing was inaccurate, but the CLI works.

What I’d try next time

If I were going to retry the Sawfwair MLX path tomorrow:

1. Stop mlx_lm.server first (pkill -f mlx_lm.server) — frees 1.1 GB
2. Stop voicebox-server if running — frees 376 MB
3. Force inactive eviction — allocate 20 GB then free
4. Run mere.run directly without tee — tee caused the orphan-recovery issues
5. Use nohup or screen — keep the process alive past Hermes process lifecycle
6. Try a smaller test first — 256×256, 8 frames, 4 steps (instead of 512×512, 56 frames)

None of this was tried in the original session because I had already pivoted to the Hailuo API.

---

Phase 5: pivoted to Hailuo API (the right move)

Hailuo API at $0.10/clip. 5 clips = $0.50. ~5 minutes total. Reference quality. No local install. This is what shipped.

What I would do differently today

If I were starting over:

Step	What I’d do
1	Check the HF model card license first. If in an excluded territory, pivot directly to the Hailuo API. Save 6 hours.
2	Read the Comfy-Org#15315 issue before installing. If the symptoms match my rig, don’t install ComfyUI for H3. Pivot.
3	If you have 48 GB Apple Silicon, do the disk math on the full stack before downloading. Don’t trust “21.47 GB resident” claims — sum the components.
4	If retrying Sawfwair MLX, stop competing services first. mlx_lm.server and voicebox-server are RAM eaters.
5	If using mere.run, run without tee and use nohup/screen. Orphan recovery is a process lifecycle issue, not a model issue.
6	For low-volume Tier 1 use cases, the cloud API is faster and cheaper than local. This is counter-intuitive but true.

---

The cost summary

Resource	What I spent
Wall clock time	~6 hours
Disk downloaded	~85 GB (4-bit weights + intermediate downloads)
Net disk delta	-147 GB (cleanup) + 43 GB (4-bit weights) = net 190 GB → 179 GB
Successful videos	0
Failed video generations	5 (all paper texture)
Mac freezes	1 (during model loading attempt)
Open bugs filed	0 (didn’t file any on upstream issue)
Money spent	$0 (no API calls made)
Production videos ready	0/5 Tier 1

What I should have spent

Resource	What I should have done
Wall clock time	~10 minutes
Disk downloaded	0 GB
Successful videos	5/5
Money spent	$0.50 (Hailuo API)
Production videos ready	5/5 Tier 1

---

What this operator journey is good for

If you read this and decided “okay, the local H3 path is closed to me, I’ll use the Hailuo API” — this article worked. Time saved: 6 hours. Money saved: hours of frustration.

If you read this and decided “okay, I have a 128 GB Mac Studio M2/M3 Ultra, the Sawfwair MLX path is documented well enough that I’ll try it” — this article worked. You have a chance of success where I had orphan-recovery failures.

If you read this and decided “I want to understand the operational reality of running frontier video models locally” — this article worked. The local frontier is harder than the X posts make it look.

---

What we learned that’s worth keeping

1. The HF model card license is the first thing to check. Territory restrictions close paths before you start.
2. Comfy-Org#15315 is the smoking gun for ComfyUI + Apple Silicon + H3. Status: still open as of Aug 8, 2026. Check the issue before retrying.
3. MLX port “resident RAM” claims count only the transformer. Always sum the full stack.
4. mere.run is a general local-AI toolkit, not a MiniMax CLI. Day-1 framing was inaccurate.
5. For low-volume Tier 1 work, the cloud API is faster and cheaper than local. Counter-intuitive but true.
6. If using Sawfwair MLX: stop competing services, run without tee, use nohup/screen, test with smaller sizes first.

---

What’s installed and where

Path	Size	Status
~/Models/Sawfwair-H3-MLX-4bit/	43.07 GB	Installed, all 14 SHA256 hashes verified
~/Models/mere-run/	Swift source + 2.5 GB build artifacts	Built, binary works
~/hermes-data/videos/h3/ats/001-005*.mp4	5 files	All paper texture (failed generations)
~/hermes-data/videos/h3/taa/001-003*.mp4	3 files	Sawfwair MLX validation attempts (didn’t complete)
~/hermes-data/videos/h3/raw/MLX-Sawfwair-validated-hummingbird.mp4	(downloaded reference, not locally generated)	OK

---

Sources

Primary references:

• Yume_X (@yume_arasaki), “MiniMax H3 Hardware Map” X thread, Aug 7, 2026 — https://x.com/yume_arasaki/status/2085802508526789060
• MiniMax H3 official blog — https://www.minimax.io/blog/minimax-h3
• HuggingFace model card (license territory restriction) — huggingface.co/MiniMaxAI/MiniMax-H3
• Comfy.org Day-0 announcement — blog.comfy.org/p/minimax-h3-day-0-support-in-comfyui

Bugs and tools:

• Comfy-Org/ComfyUI#15315 (still open Aug 8, 2026) — github.com/Comfy-Org/ComfyUI/issues/15315
• vSnake87/deardaveed patch_comfy_mps_fp8_full.py — community patch (didn’t help)
• Sawfwair/MiniMax-H3-FL2VA-MLX-4bit — huggingface.co/sawfwair/MiniMax-H3-FL2VA-MLX-4bit
• pipenetwork/MiniMax-H3-MLX-8bit — huggingface.co/pipenetwork/MiniMax-H3-MLX-8bit
• Sawfwair mere.run CLI — github.com/sawfwair/mere-run

Our operator docs (the raw source for this article):

Companion article + dossier:

• “MiniMax H3 Hardware Map: What Runs, What Doesn’t, and Why the Answer Is Probably Your Card” — the technical/reference article for choosing the right path
• Websites/content-strategy/research/minimax-h3/minimax-h3-research-2026-08-08.md — the dossier
• verify-model-spec.md, verify-hardware-paths.md, verify-setup-paths.md, verify-promotion-strategy.md — the per-claim evidence ledger

---

Closing thought

Operator-grade credibility is not built on success stories. It’s built on honest failure logs.

I burned 6 hours. The model I tried to run didn’t ship a single usable clip. The hardware I had wasn’t validated for the path. The path I picked wasn’t legal in my jurisdiction.

This article is what I would want to read if I were starting over.

---

Last verified: 2026-08-08. Refresh quarterly or before any published copy cites it.

Related guides

These guides extend the work above:

• MiniMax H3 Hardware Map: what runs, what doesn’t
• MiniMax Token Plan subscription
• Hermes Agent Provider: MiniMax M3
• Hermes Agent on a Mac mini M4