How does Sol-H3 make MiniMax-H3 video generation 30 times faster?
A research team has published a full-stack pipeline that accelerates the open-source MiniMax-H3 video model. The optimizations cut memory use by 20 percent and deliver up to 30 times speedup across cloud and edge hardware.
MiniMax-H3 is a 33-billion-parameter video diffusion model released as open source. Its multi-step denoising loop makes each clip slow to produce.
The model needs many iterative steps to turn noise into coherent motion. Early steps set the broad layout. Later steps sharpen texture and detail. Every step runs the full network at the target resolution. That keeps memory high and latency long on both cloud GPUs and edge devices.
A scheduler that changes resolution mid-stream
The authors split generation into two stages. Low-resolution steps run first and establish global structure. High-resolution steps follow and refine local detail. A learned latent-to-latent module bridges the stages. It maps the compressed representation from the low-resolution pass directly into the high-resolution latent space. The traditional VAE decode-reencode cycle disappears entirely.
This mapping is trained to preserve the information that matters for the second stage. No pixels are materialized between stages. The pipeline stays in latent space from start to finish.
A loop that rewrites its own kernels
Operator implementation uses a Recursive Self-Improvement loop. The system searches kernel fusions and memory layouts. Each candidate is measured for latency and checked for numerical agreement with the reference output. The best variant becomes the new baseline for the next search iteration. The process repeats until gains plateau.
The loop runs offline during pipeline construction. Deployment uses the final fused kernels without further search overhead.
What the numbers look like on hardware
A 5-second clip at 1344 by 768 with audio finishes 3.5 times faster than real time on an 8-GB200 node. The same clip fits in memory and completes in under a minute on a single DGX Spark. End-to-end speedup reaches 30 times over the unoptimized baseline. Memory consumption drops by 20 percent.
Thirty times.
The paper does not state how many DGX Spark units exist in the field. It also does not compare against proprietary closed-source video models.
Where the explanation stops
The manuscript describes the scheduler architecture and the RSI loop in algorithmic terms. It does not release the learned latent-to-latent weights. It does not specify the search space boundaries for kernel fusion. It does not quantify numerical drift after many RSI iterations. Anyone reproducing the results will need to reconstruct those pieces from the description alone.
The sources this article was written from
- "arXiv:2609.35110v1
https://arxiv.org/abs/2609.35110v1"