MiniMax H3 Before the Weights: A Memory Estimate's Limits
IMAGE, VIDEO & AUDIO
MiniMax H3 Before the Weights: A Memory Estimate's Limits
Before the H3 files arrived, a capacity calculation could only identify likely constraints. It could not establish a working local pipeline. The later release reports and encoder experiment linked here provide narrower evidence about actual configurations, which should be read separately from the original estimate.
In this article
The initial announcement promised weights within days. This article records the pre-release capacity calculation. The weights were subsequently published, and the later reports below provide evidence that was not available for that first estimate.
Announced service capabilities
· Length: 5–15 seconds
· Audio: dialogue, SFX, and BGM generated together with the video (stereo)
· Input: text + up to 9 images + 3 videos + 3 audio = 12 references in one context
· Modes: text→video, first/last frame, reference→video, natural-language video editing
· Prompt: up to 7,000 characters
The key is the "12 references at once" part. Before, you'd feed a character image to one model, a motion video to another, a voice to a third, then stitch it all together. H3 handles it in a single call — "follow the Hitchcock camera move from Video 1, have the character from Image 2 sing with the voice from Audio 3," that kind of thing.
Launch service pricing
$0.13 per second at 2K — about $1.95 for a 15-second clip. Versus competitors:
One trap: the length of any reference videos you feed in is added to the billed time. Make a 5s video with a 3s reference and you're billed for 8s. Don't forget this when you're budgeting.
The original local-memory estimate
This section began as a pre-release estimate, before the exact parameter count and pipeline were public. The later release supersedes those guesses. The examples below now explain why parameter count alone cannot decide GPU fit.
A text model from the same company cannot establish the video model’s size. Video resolution also does not uniquely determine parameter count. A defensible estimate needs the actual component files and runtime allocations.
My expectations, in three scenarios:
Count the encoder, transformer, audio components, cached conditioning and runtime buffers together. Resolution and frame count can change peak usage even when weight files stay identical. A successful load is only the first stage of the test.
For reference: the text model M3 was ~143GB even Q4-quantized, effectively unrunnable in a normal home setup. A video model won't be that bad, but let's not get optimistic.
Weight-release and license conditions
The license turned out to be the MiniMax Community License: commercial use only for organizations under $20M annual revenue, with attribution required. That's not OSI-certified open source — it's "source-available," the same shape as Meta's Llama.
Practically free for individual creators, indie studios, and early startups. But a bigger ad production? Maybe not. And as of Aug 2, there still aren't any downloadable files — it's a "within days" promise.
Post-release evidence
If you want to try it right now, the API is the way. A 15s 2K clip at $1.95 is less than lunch money — testing with your own prompts beats a hundred reviews.
The early estimate could not establish whether a particular consumer GPU would run the final pipeline. The artifact, encoder placement, quantization, resolution and offloading path all affect that result. Do not use the hosted 2K specification as the local configuration.
For post-release evidence, read the early community timing roundup and the later 1080 Ti encoder experiment. The latter includes a specific prompt and controls; neither is a general fit guarantee for every H3 workflow.
Related on this blog: MiniMax's open music model · my first impressions of those open weights
Hardware estimates are my speculation and will be updated against the official model card.
Open Source Factory · opensourcefactory1.blogspot.com
Comments
Post a Comment