Built with Muse Spark Open
Copyright (c) 2026 Meta Platforms, Inc.
Muse Spark Open 2-bit, 62 of 62 layers, 5 ranks on 4 Apple Silicon machines. Mixed-bit MLX build of Muse-Spark-Open-816B-A42B (2-bit routed experts), text only. The answer and speed figures below come from one real run of the full, unpruned model; anything marked not measured was not measured.
What this is
A re-quantization of Meta's Muse Spark Open (816B total / 42B active, 256 experts, top-8, 62 layers) into the MLX affine format, built from AMD's public FP8 checkpoint so that no step goes through a lower-precision intermediate. It targets memory-limited Apple Silicon clusters (Omarchy Linux and macOS).
Lineage and credit
- Meta Platforms, Inc.: Muse Spark Open (
meta-models/Muse-Spark-Open-816B-A42B), released under the Muse Model License (LICENSE.md and USE_POLICY.md in this repo, unchanged). - AMD:
amd/Muse-Spark-Open-816B-A42B-Quark-PTPC-FP8, revision52cace63f43ed9fc6acef6dcd391adb02f4bfbe1, produced with AMD Quark (PTPC FP8: weights FP8 E4M3 per-channel). This model is derived from that checkpoint; Modifications Copyright(c) 2026 Advanced Micro Devices, Inc. All rights reserved.
Recipe (exact; see recipe.json and BUILD.md to reproduce)
| group | tensors | bits | group size |
|---|---|---|---|
| routed experts | mlp.switch_mlp.{gate,up,down}_proj (256 experts each, 4096x4096) |
2 | 128 |
| attention | self_attn.{q,k,v,o,gate}_proj |
4 | 64 |
| latent expert projections | mlp.{pre,post}_expert_proj |
4 | 64 |
| embedding | embed_tokens |
4 | 64 |
| output head | lm_head |
6 | 64 |
| router, norms, residual gates | unquantized (router float32) |
MLX affine: per group a bf16 scale and bias (128 values for the routed experts, 64 elsewhere). Tensor names equal the mlx-community/Muse-Spark-Open-816B-A42B-3bit text layout. Vision, audio, vision adapter and projection are not included (text only).
Size
- Checkpoint size: 237,429,698,758 bytes (237.43 GB) in 63 safetensors files (measured on the finished files; identical to the byte-exact prediction of the recipe's size formula). 2,425 tensors, exactly the tensor names and dtypes of the published
mlx-community/Muse-Spark-Open-816B-A42B-3bittext layout (widths differ with bits). - Difference from the other public MLX build of this model that I found,
staccs/Muse-Spark-Open-816B-A42B-lecore-mlx(revision2dbcb1edf83885c3e4c294e8dcc3e02dd484a60d, 260,260,340,459 bytes of safetensors; itsconfig.jsonlists 2-, 3-, 4- and 6-bit modules, all with group size 64): here every routed expert is 2-bit with group size 128 (2.25 bits per weight including the bf16 scale and bias), which is the main reason this checkpoint is 237,429,698,758 bytes. No quality comparison is made; quality of this checkpoint is NOT MEASURED.
Weight-level checks
On layer 1 (expert 5 gate/up/down and attention q/k/o/gate), against the FP8 source: relative RMS error 2-bit g128 (used) = 0.42-0.44 (2-bit g64 = 0.39-0.40, not used), 4-bit g64 = 0.09-0.10. The published mlx-community 3bit repo differs from the same FP8 weights by 0.19-0.21 on the same tensors. These are single-layer weight errors, not model quality.
Quality
The full 62-layer model answered three short prompts coherently and identically on repeat (greedy decoding; a second pass gave byte-identical text), and this is not a quality score and there is no independent reference to compare it with. Only these three prompts were checked; no benchmark was run.
| Prompt | Output |
|---|---|
What is 17 times 23? Answer with only the number. |
391 |
What is the capital of Australia? Answer in one sentence. |
The capital of Australia is Canberra. |
Write a Python function is_prime(n). Code only. |
starts def is_prime(n):, tests isinstance(n, int) and n < 2, returns True for 2 and 3, returns False for multiples of 2 and 3, then continues with a loop; the output was cut at the 64-token limit |
The prompts were sent as raw completions with the answer channel forced (<|start|>assistant to=user<|message|>) after the standard system header, temperature 0. Prompt length was 158 to 161 tokens.
Speed and hardware (this cluster, this run)
All 62 layers ran on Apple Silicon GPUs through MLX: no layer on a CPU, no expert pruned, nothing substituted. The model was split across 5 ranks on 4 machines, in rank order:
| Rank | Machine | Layers | Weights |
|---|---|---|---|
| 0 | Mac Studio (M1 Ultra) | 38-61 and lm_head (24 layers) | 92.4 GB |
| 1 | 14-inch MacBook Pro (M2 Max), process A | 26-37 (12) | 45.5 GB |
| 2 | 14-inch MacBook Pro (M2 Max), process B | 14-25 (12) | 45.5 GB |
| 3 | 16-inch MacBook Pro (M1 Max) | 2-13 (12) | 45.5 GB |
| 4 | 13-inch MacBook Pro (M1) | 0-1 and the embedding (2) | 8.6 GB |
The ranks form a pipeline over a local network (omarchy-cluster), with MLX_DISABLE_COMPILE=1, default kernels, the raw completions route and temperature 0. Loading took about 10 min 45 s from the start of the serve to a healthy gateway.
Timing at a 158 to 161 token prompt (TTFT is the prefill time and decode is the tokens per second reported by the gateway; each prompt was run twice):
| Prompt | TTFT | Decode | Output tokens |
|---|---|---|---|
| 17 x 23 | 26.5 s, 26.7 s | 3.86, 3.95 tok/s | 2 |
| capital of Australia | 26.1 s, 26.2 s | 2.23, 2.18 tok/s | 8 |
| is_prime | 25.9 s, 26.0 s | 2.00, 2.03 tok/s | 64 |
The speed is this cluster's, over this network and pipeline, and it is not a property of the checkpoint alone: decode was about 2.0 tok/s on the 64-token output. Per generated token (is_prime run), the Mac Studio rank spent about 437 ms of about 507 ms waiting for the other ranks to return, and its own step took about 44 ms, so the time went into the ring path through the other ranks, not the Studio rank. Not measured: peak memory per node, prefill tokens per second, and outputs of 128 or 256 tokens. The cluster stopped when the 13-inch machine's GPU hung during a longer request (the first 128-token try), and the same machine hung in an earlier attempt; the cause is not proven. Stability over longer outputs was not shown, so no 128 or 256-token figures are given.
How to run
- Get the files:
hf download <this repo> --local-dir Muse-2bit(about 237 GB in 63 files; check them withSHA256SUMS, and per tensor withTENSOR_SHA256.txt). - This checkpoint was run with the omarchy-cluster pipeline over MLX; the setup is described in
docs/muse-spark.mdof https://github.com/joshuaswarren/omarchy-mlx, and the conversion tools are intools/muse-2bit/of the same repository. The exact mlx and mlx-lm builds are not listed here.config.jsoncarries the per-module quantization (experts 2-bit g128,lm_head6-bit g64, default 4-bit g64);model_typeismuse_spark, the same as the published mlx-community quants. - Memory: the weights alone are 237.4 GB, so this needs several machines or one very large unified-memory machine; the run above used 4 machines.
- Chat template:
chat_template.jinjais the file from the mlx-community 3bit text repo (byte-equal). It has nodisable_reasoningswitch, so achat_template_kwargssetting of that name changes nothing when this template is used; its generation prompt is only<|start|>assistant. - To rebuild from AMD's FP8 checkpoint: see
BUILD.md,recipe.jsonandscripts/(converter sha256 inrecipe.json).
Limitations
2-bit routed experts are a large quality risk (see Quality). Text only. Not evaluated for safety; see the Usage Policy. The cluster stopped when the 13-inch machine's GPU hung during a longer request; the same machine hung in an earlier attempt. Stability over longer outputs was not shown.
License
Muse Model License (LICENSE.md) and Muse Spark Open Usage Policy (USE_POLICY.md) are included unchanged and apply to this model and to any derivative of it. Built with Muse Spark Open.
Provenance of this build (measured)
- Built 2026-10-15 (CDT) with
requant_stream.py(sha2569a2fa17a762c8806da6297376088a7dcefce794e15a3ce73d537dc13cb77f3b8), mlx 0.32.3 on a Mac Studio (layers 0-13), mlx 0.32.4 on a Linux Apple-Silicon laptop (CPU; layers 14-61) and mlx 0.32.4 on a Linux x86 host (CPU; the shared embedding, lm_head and final-norm part), source revision52cace63f43ed9fc6acef6dcd391adb02f4bfbe1. No pruning. SHA256SUMS(whole-file) andTENSOR_SHA256.txt(per tensor: file, name, dtype, shape, sha256) are in this repo. Whole-file hashes can differ between platforms for identical tensors (MLX writes tensors in hash-map order); verify per tensor.- An independent check (a separate numpy FP8 decoder and quantizer) reproduced one expert tensor's dequantization and its 2-bit g128 requantization bit for bit.