MiniMax-AI / MiniMax-AI/MiniMax-Music3

Community: 2.9x faster consumer-GPU inference (sub-realtime on RTX 4090) + two model-card findings

Open
#2 3 comments 3 reactions 0 assignees View on GitHub

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:

  1. The low-VRAM snippet is counter-productive for the AR stage. The card
    suggests apply_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=True pins host memory and roughly doubled
    process RSS (31-38GB) on a 61GB machine. Whole-component offload
    (ComponentsManager.enable_auto_cpu_offload() alone) works well.

  2. 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.