MiniMax-AI / MiniMax-AI/MiniMax-Music3
Community: 2.9x faster consumer-GPU inference (sub-realtime on RTX 4090) + two model-card findings
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 896
- Forks
- 84
- PR merge metrics
- No merged PRs in 30d
Description
Hi MiniMax team — first, thank you for open-weighting Music 3; it is a
remarkable model. We spent a focused engineering session getting it to run as
fast as possible on a single consumer GPU (RTX 4090, Windows, the diffusers
modular pipeline) and open-sourced the result as a local Suno-style studio:
https://github.com/TheDutchRuler/minimax-music3-studio
Measured results (20s songs, warm, seed-fixed, bf16 reference precision):
| Configuration | Per song |
|---|---|
| Reference diffusers pipeline | 50.5s (2.52x realtime) |
| Compiled AR decode (StaticCache + CUDA graphs) + batched-CFG DiT + sliced lm_head + Gumbel-max fused sampling | ~31s |
| Batched "ensemble" generation, 3 variations in one lockstep pass | 17.7s (0.88x realtime) |
The ensemble idea may interest you most: the AR stage is memory-bandwidth
bound (~23GB of weight reads per frame), so K same-prompt variations decoded
in one batch-2K pass amortize the read — the third song is nearly free. All
math stays row-independent and distribution-identical to the reference
sampler (Gumbel-max equivalence unit-tested).
Two findings you may want to reflect in the model card:
-
The low-VRAM snippet is counter-productive for the AR stage. The card
suggestsapply_group_offloading(pipe.language_model, ..., use_stream=True)
for small cards. Because the Global LLM decodes autoregressively at 25
forwards/second, per-layer offload re-streams the full 16.4GB across PCIe
every frame — we measured 10% GPU utilization and effectively no progress.
Additionally,use_stream=Truepins host memory and roughly doubled
process RSS (31-38GB) on a 61GB machine. Whole-component offload
(ComponentsManager.enable_auto_cpu_offload()alone) works well. -
Sample-rate mismatch: the card says 32kHz output, but the diffusers
pipeline reports and produces 44.1kHz (pipe.sampling_rate == 44100).
Also documented in the repo README: negative results (FP8 weight-only via
torchao measured 2.1x slower on Windows/torch 2.11; per-layer offload above)
so others don't repeat them.
This work was engineered end-to-end with Claude (Fable 5 Max) by Anthropic.
Happy to provide more detail on any measurement.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the model card's low-VRAM guidance and stated 32kHz sample rate against the reported diffusers pipeline measurements. Read the repository README for the documented optimization results and negative findings. Done means the model card accurately reflects the supported offload guidance and the pipeline's reported output rate, with the performance context documented where appropriate.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, pytorch
- Domain
- documentation, machine-learning, performance
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100