ACE-Step 1.5 Runs a Music Model on Your Mac. Nobody Will Quantize the Audio Decoder, and It Turns Out to Be the Cheapest Part.

A look at what the local builds of the open 4B music model actually compress, the one component every packager independently refuses to touch, and how to get a 48kHz stereo track out of an Apple Silicon machine this afternoon.

Line up the community conversions of ACE-Step 1.5 and one pattern repeats in every single one. The MLX int4 repack quantizes dit/decoder.safetensors and leaves the audio VAE dense. The mlx-community 4-bit build says "VAE, tokenizer, and detokenizer kept in full precision." The GGUF port publishes a per-component precision table and writes next to the VAE row: "Always BF16 (small, bandwidth-bound, quality-critical)."

Three people, three toolchains, no coordination, same call.

Here is the part that makes it interesting rather than just prudent. That untouchable VAE is 322MB in BF16. It is the smallest thing in the stack. Whatever is making your local music bundle five gigabytes, it is not the component everyone is protecting.

The precision boundary is real, and it is nearly free

Diffusion models for images tolerate a lot of numerical slop. Nudge a latent and you get a slightly softer picture. Audio does not forgive the same way.

ACE-Step's decoder is an Oobleck autoencoder in stable-audio-tools format, latent dimension 64, downsampling ratio 1,920. Every sample of the final 48kHz stereo waveform passes through it. Error in the diffusion transformer shows up as a different musical arrangement, which is a thing you might not even notice. Error in the audio decoder shows up as hiss, a click, or a metallic ring riding on top of the whole mix, and human hearing is unreasonably good at finding exactly that.

The turbo distillation sharpens the problem. XL Turbo runs in eight steps with no classifier-free guidance, because guidance was distilled into the weights. Few-step samplers have no slack. In a fifty-step trajectory a small per-step error averages out. In an eight-step trajectory each step carries roughly six times the weight, so the same error lands six times harder.

So the packagers are right. What their own numbers also show is that being right here costs almost nothing. From the GGUF card's component table: the XL DiT at Q4_K_M is 2.8GB, the Qwen3-Embedding-0.6B text encoder at Q8_0 is 748MB, and the BF16 VAE is 322MB. That is a complete XL Turbo synthesis stack at roughly 3.9GB with the precision-sensitive part fully untouched.

The same card is worth reading for two more findings that nobody else published: the 4B language-model planner has no Q4_K_M build because it "breaks audio code generation," and the small 0.6B and 1.7B planners ship only in BF16 and Q8_0 because they are "too small for aggressive quantization." That is a real, model-specific map of where compression fails, from a person who did the compressing.

So why is the MLX download five gigabytes?

Because of packaging, not precision.

The mlx-community 4-bit build totals 5.27GB and breaks down as 2.2GB model, 0.7GB VAE, 2.4GB text encoder. That text encoder is Qwen3-Embedding-0.6B, the same 0.6B model the GGUF stack ships at 748MB. Two point four gigabytes for six hundred million parameters is float32. It was never quantized and it was never converted down to bf16 either.

Nearly half that bundle is one small model shipped at four bytes per weight for no stated reason.

This is worth naming because the story that circulates is "audio models resist quantization, so the files stay big." The first half is true and the second half does not follow. The audio-sensitive component is 322MB. The bloat is a float32 text embedder sitting next to it.

If you want the small local build today, the GGUF route is the one that actually delivers it.

What the model is

Some numbers here are genuinely contested between the project's own documents, so take them as a range rather than a spec.

The GitHub README describes XL as a "4B-parameter DiT decoder." The official Diffusers model card calls it "the guidance-distilled 5B-parameter flow-matching DiT," and the Hugging Face widget on that same page reports 4B. I have not found a reconciliation. Call it four to five billion parameters in the DiT and move on.

The rest is stable across sources. Hidden size 2560, 32 layers, 32 attention heads, alternating sliding-window and global attention. Text conditioning from Qwen3-Embedding-0.6B. Audio through the Oobleck VAE. Output is 48kHz stereo, and the documented duration range runs 10 seconds to 600 seconds. Eight sampling steps, guidance-distilled, so a guidance scale above 1.0 is ignored. The official float32 repository is about 20GB on disk, and the XL DiT alone is roughly 9GB in bf16.

There is one optional stage that changes your memory budget: a separate "5Hz LM" planner, available at 0.6B, 1.7B, and 4B, which writes a song blueprint (structure, lyrics, captions) before the diffusion transformer runs. You can turn it off and run DiT-only. Most ports default it on.

The licensing is clean, with one document sitting awkwardly next to another

This matters more for music than for images, because a generated track can end up under a paying client's video.

ACE-Step 1.5 is MIT, both the code and the XL Turbo weights. The older 3.5B ACE-Step v1 was Apache 2.0. Two repositories, two licenses, easy to confuse.

The model card states the model was "trained on legally compliant datasets," that "generated music can be used for commercial purposes," and describes the training data as licensed music, royalty-free and public domain material, and synthetic MIDI-to-audio data.

The awkward part: no dataset list is published, no third-party audit exists, and the same project ships a disclaimer acknowledging the risk of "unintentional copyright infringement due to stylistic similarity" while placing responsibility on the user. Both documents are honest on their own terms. Together they say a permissive license is not an indemnity, and nobody in this space is offering one.

Worth being accurate about the competitive picture, since it is easy to oversell: permissive open music models are not rare. YuE is Apache 2.0. MiniMax-Music3's community license permits commercial use with attribution below a revenue threshold. The restrictive cases are MusicGen at CC BY-NC and Stable Audio Open with its own revenue cap. ACE-Step is in the good half of a category that has a good half.

Put this into practice

Three routes, in order of how fast they get you a track.

Route one: mlx-serve, the one-click server.

A native Zig and MLX server under MIT license that ships an 8-bit ACE-Step 1.5 XL Turbo bundle and serves it over HTTP.

1. Install mlx-serve and let it pull the ACE-Step model on first run. The project's own docs put the general server floor at 8GB RAM with 16GB or more recommended.
2. Start it. Default port is 11234.
3. POST to /v1/audio/music-generations. The one required field is prompt. Optional: lyrics (leave empty for an instrumental), duration_seconds (10 to 600), bpm (documented 30 to 300), keyscale, timesignature, vocal_language, seed.

Two parameter formats will trip you up, because they are not what you would guess. timesignature takes an integer, not a fraction: 2, 3, 4, or 6, meaning 2/4, 3/4, 4/4 and 6/8. keyscale uses forms like "C Major" or "Am". Send "4/4" and you have sent a string the endpoint does not parse.

POST http://localhost:11234/v1/audio/music-generations
{
  "prompt": "slow downtempo instrumental, warm analog synth pads, brushed drums, no vocals",
  "duration_seconds": 30,
  "bpm": 84,
  "keyscale": "Dm",
  "timesignature": 4
}

Thirty seconds is the right first length: long enough to hear whether the arrangement holds, short enough that a bad prompt costs you nothing. Get that working before you add lyrics.

Route two: GGUF, if you want the small build.

The acestep.cpp GGUF conversions are the smallest complete stack available and the only ones shipping a published per-component precision rationale. Pull the XL DiT at Q4_K_M, the text encoder at Q8_0, and the BF16 VAE, and you are at roughly 3.9GB. Do not reach for a Q4_K_M planner; it does not exist, on purpose.

Route three: upstream, with the whole control surface.

The ACE-Step 1.5 repository has first-party macOS support. It ships start_gradio_ui_macos.sh and start_api_server_macos.sh, which set ACESTEP_LM_BACKEND=mlx and pass --backend mlx for you and fall back to PyTorch on non-arm64 machines. Gradio comes up on 7860, the REST API on 8001. There is also a packaged macOS build.

This route gets you the planner sizes, the DiT-only toggle, and the task modes turbo drops. It also pulls the full float32 download unless you point it somewhere else yourself.

The thing that will actually bite you: memory, not disk. Two sources disagree and both are probably right about different workloads. mlx-serve recommends a 16GB Mac for general use. Upstream's maintainer, in the MLX tracking issue for the 4B DiT, is more cautious: 16GB is "very tight, may need aggressive chunking," 32GB is "workable with offload," 64GB and up is "comfortable." An 8-bit MLX bundle and a full bf16 DiT are not the same job. Budget by the route you take, and on a 16GB machine close everything else first.

Honest limitations

Nobody has published a listening test. There is no bf16 versus 8-bit versus 4-bit perceptual comparison for ACE-Step anywhere I could find. The GGUF card is the closest thing, and it publishes where quantization breaks rather than how it degrades. The bf16 repack asserts "negligible quality loss" with no measurement attached. If you are choosing between the 8-bit and int4 builds, you are choosing on vibes, and so is everyone else.

XL Turbo cannot do stems, but ACE-Step can. This distinction matters and it is easy to get wrong. ACE-Step 1.5 supports track separation and multi-track layering through its extract and lego tasks. The XL Turbo checkpoint drops extract, lego, and complete. If your workflow needs separated instrument tracks, do not conclude the model can't do it. Use XL base instead and give up the eight-step speed.

Turbo trades variety for speed. The project's model zoo rates XL Turbo very high on quality and medium on diversity, against high-and-high for XL base. If you generate twenty candidates to pick from, turbo will keep handing you cousins of the same idea.

The Apple Silicon path is young enough to have shipped a real correctness bug. The MLX condition_embedder hardcoded a 2560x2560 linear layer while XL's encoder outputs dimension 2048, which crashed every 4B model on Apple Silicon. Filed as issue #995, fixed by PR #1002. Not a complaint, a calibration: this code is months old, not years.

Every Apple Silicon speed claim is a vendor claim. The only official Apple number in the whole ACE-Step family comes from the older v1 model: on an M2 Max, 26.43 seconds to render one minute of audio at 27 steps, a real-time factor of 2.27. Everything faster that you read about 1.5 is unreplicated. Measure it yourself before you plan around it.

Repack ambiguity is a real cost. Several community builds circulate with similar names and different contents, and at least two mlx-community cards label themselves "3.5B" when 3.5B is the v1 model. The non-XL ACE-Step 1.5 DiT is roughly 2B. Read the config before you commit to a multi-gigabyte download.

What I would watch

Local music generation on a Mac works today, on hardware plenty of people already own, with a license that lets you sell the output. That question is settled.

The one I would rather see answered is whether the caution around the audio decoder is load-bearing or inherited. Every packager holds the VAE dense, they all give the same reason, and none of them has published a measurement showing what happens when you don't. It costs 322MB to be careful, so nobody has had a reason to test it. That is a completely rational place to end up and also the exact shape of an assumption that never gets checked.

Somebody with an M-series Mac and an afternoon could settle it: quantize the Oobleck VAE to 8-bit, generate the same seed through both, and listen. If the careful version is audibly better, that is a useful published fact about where perceptual information lives in a music model. If it isn't, that is a more useful one.

If you run that test, post the files. Right now the measurement does not exist anywhere public.

---

Medium metadata

Primary sources

• ACE-Step 1.5 repository (MIT): https://github.com/ace-step/ACE-Step-1.5
• ACE-Step v1 repository (Apache 2.0, 3.5B): https://github.com/ace-step/ACE-Step
• XL Turbo model card: https://huggingface.co/ACE-Step/acestep-v15-xl-turbo
• XL Turbo Diffusers card (the 5B figure): https://huggingface.co/ACE-Step/acestep-v15-xl-turbo-diffusers
• Oobleck VAE card: https://huggingface.co/ACE-Step/ace-step-v1.5-1d-vae-stable-audio-format
• GGUF conversions and the per-component precision table: https://huggingface.co/Serveurperso/ACE-Step-1.5-GGUF
• MLX XL int4 repack: https://huggingface.co/mochiexists528/ace-step-mlx-weights-xl-q4
• mlx-community 4-bit build: https://huggingface.co/mlx-community/ACE-Step1.5-MLX-4bit
• mlx-serve: https://github.com/ddalcu/mlx-serve
• Upstream API parameter documentation: https://github.com/ace-step/ACE-Step-1.5/blob/main/docs/en/API.md
• Apple Silicon memory guidance, upstream issue #995: https://github.com/ace-step/ACE-Step-1.5/issues/995
• macOS install notes: https://github.com/ace-step/ACE-Step-1.5/blob/main/docs/en/INSTALL.md
• Technical report: https://arxiv.org/abs/2602.00744