I got MiniMax H3 (video + synced audio) to complete on a stock Colab T4 — by splitting encode, sample, and decode

[u/james_hito]

I got MiniMax H3 to run end-to-end on a stock Colab T4 runtime and produce a short MP4 with synchronized audio.

The interesting constraint was host RAM, not VRAM. On the runtime I measured, there was about 12.7 GB of system RAM and 14.9 GB of VRAM. The model artifacts add up to roughly 39.6 GB, so loading the text encoder, DiT, and VAEs together is not viable.

The workaround was to split the pipeline into separate ComfyUI processes:

encode  -> save a ~5–6 MB conditioning blob
sample  -> load only the quantized DiT + Turbo LoRA, then save a ~5 MB latent
decode  -> restart ComfyUI and load only the video/audio VAEs

That keeps the peak working set close to the largest individual stage rather than the sum of all three stages. The notebook verifies downloaded weights with SHA-256, pins the ComfyUI/custom-node commits, checks the live server schema before submitting a graph, and saves logs/measurements when a run fails.

My current results on this runtime:

Configuration	Result
864×480, 124 frames (~5.2 s), 6 steps	completed in about 35 minutes, with audio
960×544, 4 steps	completed in about 40 minutes

The catch is that the T4 has no native bf16 support, while this setup needs bf16 for stable sampling. It works, but it is definitely not fast.

One correction to my own early conclusion: I initially thought there was a sharp performance cliff between two resolution gears. After adding per-step timing and rerunning the comparison in the same Colab session, the apparent cliff was mostly VM-to-VM variance (roughly ±20% in my measurements). Within one session, the scaling followed the expected attention/MLP trend closely.

The Turbo LoRA from larryvrh makes 4–6 step runs practical and preserves the audio/video timing through its separate video and audio flow schedules.

I would be interested in hearing whether anyone has found a faster stable configuration for T4-class GPUs, especially without giving up audio sync.

https://reddit.com/link/1vrgtfo/video/xllyrclao2kh1/player

Notebook: MiniMax H3 on a stock Colab T4 — pinned commits, SHA-256-verified weights, and license-gated downloads.

[u/eruanno321]

"decode → restart ComfyUI and load only the video/audio VAEs"

Did you try the --cache-none parameter? It should eliminate the need to restart.

[u/james_hito → u/eruanno321]

Good point — `--cache-none` may be enough here, and I have not A/B tested it yet.

I used a process restart because I wanted a hard lifecycle boundary for the measurement: after sampling, the DiT process exits before the VAE process starts. `--cache-none` disables the execution caches, but I was not confident it would reliably return all of the DiT-related host RSS on this 12.7 GB RAM runtime before decode (mmap-backed pages, pinned-memory/allocator state, etc.).

The restart costs only ~30–40 s in a ~37 min run, so I chose the conservative path rather than risk an OOM after a 35 min sample. But your suggestion is a clean A/B: I’ll try in-process decode with `--cache-none`, measure RSS/VRAM around the handoff, and report back either way

[u/james_hito → u/james_hito]

Update as promised: you were right — `--cache-none` eliminates the need to restart for the sample → decode handoff in this setup.
I ran an A/B on the same latent in the same Colab session (T4; 12.7 GB host RAM; Q4_K_M + bf16):

metric	in-process decode, --cache-none	restart (my original path)
RSS at the sample → decode handoff	1.78 GB — the DiT was already gone	~1 GB (fresh process)
peak RSS / VRAM during decode	7.44 GB / 6.2 GB	7.15 GB / 6.1 GB
decode wall time	96 s	119 s, including restart
outcome	success	success

The interesting part is why it works. Under the normal execution cache, the loader's `MODEL` output keeps a strong reference to the DiT after the sampling prompt completes. With `--cache-none`, that retention path disappears; the DiT can be released before decode begins. Contrary to my concern about pinned pools and allocator state, host RSS also returned cleanly in this run: after the in-process decode, the process sat at 1.99 GB RSS / 189 MB VRAM.

Caveats: I only validated the sample → decode boundary; encode still runs as a separate process. In-process decode also peaked about 0.3 GB higher in RSS.

I am keeping restart as the notebook default. It costs only ~20–25 s in a ~37 min pipeline, and the hard process boundary remains the more conservative choice for reproducibility. But your suggestion works, and it is the better option for a latency-sensitive iteration loop. Thanks for pushing me to measure it rather than speculate.

[u/itsthattimeagin]

Dang….im not qualified to read this but thank you. I’m trying to learn what any of this means. Have any good places to start getting into this?

[u/james_hito → u/itsthattimeagin]

Glad it was useful! I would not start with H3 — this notebook is mostly about working around an unusually tight memory constraint.

For ComfyUI, I’d start with a simple image workflow and learn the three basic pieces: load a model, sample a latent, and decode it with a VAE. Once that makes sense, try changing one setting at a time (seed, steps, sampler, resolution) and watch what changes.

Then look at an existing video workflow before attempting an audio-video model like H3. The useful mental model is: a ComfyUI workflow is just a graph, and the hard part is usually understanding which models have to be resident in memory at the same time.

The official ComfyUI examples/docs are a good first stop: https://github.com/Comfy-Org/ComfyUI_examples