MiniMax H3 (ComfyUI)

Local reference-to-video generation via ComfyUI on a single RTX 3090 — one real video produced, several ways to set the GPU on fire trying for a second one.

Goals

Take a free, community-shared ComfyUI workflow for MiniMax H3 (a newly-released video model, paired in the source workflow with LTX 2.3 and Wan 2.2 5B as optional upscalers) and get it running end-to-end, fully local, on the existing comfyui-ideogram container. Dogfooded 2026-08-04 across several coding-agent runs, starting from a Patreon post advertising "12x faster" upscaling and ending in a paused experiment after a hard reboot, an OOM-killed process, and a wasted ten minutes of mouse-driven browser automation.

Effectiveness

In progress. The model does work — one clean generation (864×480, 5.17s, synced audio) completed and was delivered. But every attempt since to reproduce that with a different reference image has hit a different failure mode, and the actual safe operating envelope on this card is still not nailed down. Not yet a repeatable workflow.

After-Action Report — 2026-08-04

Five incidents. One successful video. Here's what broke.

1. The full comparison workflow saturates a 24GB card by itself

What happened: The source workflow bundles a no-upscale baseline alongside LTX 2.3 and Wan 2.2 5B upscale branches in one prompt graph. Running it as shipped — all three branches loaded — pushed VRAM to 23.2GB/24GB at 100% utilization mid-sampling. The box became unresponsive and needed a hard reboot.

Why: MiniMax H3's own diffusion model is ~21GB int8-quantized before anything else loads. Its text encoder (Qwen3VL-8B/32B depending on variant) and VAE add several more GB on top. Adding an upscale stage to an already-maxed pipeline leaves zero headroom — there's no OOM error, just a system-wide freeze.

Fix: Run only the "no upscale" baseline branch; explicitly bypass the LTX/Wan groups so their models never load at all.

2. ComfyUI's own process leaked ~52GB of host RAM, independent of VRAM

What happened: Across several runs earlier in the day, the ComfyUI Python process's resident memory grew to ~52GB — on a 62GB box. Available RAM dropped to ~1GB, swap nearly filled, load average hit 27. The kernel OOM-killer fired and killed an unrelated claude process (confirmed in dmesg), which turned out to be this agent's own tool-call bridge — every MCP tool call started failing with generic connection errors, with no obvious link back to a GPU workload.

Why: Repeated generations without a container restart accumulate memory ComfyUI never releases. This is a host-RAM problem, not just a VRAM one — monitoring only nvidia-smi misses it entirely.

Fix: docker restart comfyui-ideogram reclaims it immediately (confirmed: freed ~49GB in seconds, container back to healthy). Going forward, any generation-monitoring loop polls free -m alongside nvidia-smi, not GPU memory alone.

3. Ten minutes of mouse-driven browser automation, zero progress

What happened: A coding subagent, working from the ComfyUI web UI instead of its HTTP API, spent about ten minutes repeatedly panning/dragging the node-graph canvas with agent-browser mouse commands and taking screenshots — never actually queuing a job. GPU sat idle the entire time; from the outside this looked identical to a genuine hang.

Why: ComfyUI's web canvas is not built for reliable programmatic navigation — coordinates drift, screenshots require visual inspection to interpret, and there's no feedback loop confirming an action landed until something is queued (or isn't).

Fix: ComfyUI exposes everything needed via HTTP (/prompt, /queue, /history, /object_info, /interrupt) and the container filesystem. window.app.graphToPrompt() via a single one-time browser eval is a legitimate way to dump a loaded workflow's JSON — but that's the only acceptable UI touchpoint. Everything else — editing the graph, swapping reference images, submitting jobs, monitoring — goes through curl/API, never the canvas.

4. The safety valve was tuned more conservatively than the model's actual proven envelope

What happened: After incidents #1 and #2, a hard VRAM interrupt threshold of 21,500 MiB was set for all future runs. The next attempt — using the correct no-upscale-only branch, correct API-only approach — got cleanly through model load and into the actual sampling step, then crossed 21,500 MiB (peak: 22,631 MiB) and was auto-interrupted. No crash, no video either.

Why: The threshold was picked as a round, cautious number after the incident #1 freeze, without reference to what this specific (correct, no-upscale) branch actually needs. It turned out the identical branch had already completed successfully earlier in the day at a similar or higher peak, on the same card, with headroom to spare (24,576 MiB total).

Fix: not yet applied — flagged for the next attempt: raise the ceiling to ~23,000–23,500 MiB (still >1GB under the card's total) now that a real peak-VRAM data point exists for this specific workflow, rather than re-guessing a round number.

5. Two coding-agent contexts worked the same GPU task without either one noticing the other

What happened: A subagent spawned for this task and the coding agent's own persistent WhatsApp session both ended up independently monitoring/interrupting jobs against the same ComfyUI instance mid-session, each initially assuming a "mystery third process" was responsible for an over-threshold job neither of them had queued.

Why: Orchestration hygiene, not a ComfyUI problem — a subagent's completion wasn't confirmed before letting a second, longer-lived agent context pick up related work on the same resource.

Fix: Explicitly stand down one context before handing a shared GPU resource to another; don't let a persistent session and an ephemeral subagent operate on the same container concurrently.

Systemic observations

A model this large leaves no margin for guessing. At ~21GB base weight alone, MiniMax H3 on a 24GB card means every additional GB — an upscale branch, a second concurrent process, an unrelated app's VRAM use — is the difference between "works" and "hard reboot." Safety margins need to be measured against real peak-usage data, not picked as a round number in advance.

Host RAM is as real a failure mode here as VRAM. GPU-focused monitoring (nvidia-smi alone) missed the actual incident that took down agent infrastructure — the OOM-killer took a completely unrelated process with it. Any GPU workload doing sustained container work needs both watched together.

Deterministic interfaces aren't optional for this kind of work. The single biggest time sink of the day (ten minutes, zero output) was mouse-driven browser automation standing in for what a single curl -X POST /prompt call does reliably. If a tool exposes an API, use the API — full stop.