Will it fit? The sources

This ledger lists every factual claim in Exploded View 001, “Will it fit?”. Each claim is tied to a source, a primary one wherever it exists, with the exact quote or data that supports it. Every number we calculated is recomputed step by step in §2. A second pass (§3) then read the issue as a skeptical editor and tried to disprove each claim. Estimates are labelled as estimates, and the corrections made before publishing are listed in §4.

Checked October 17, 2026 (US Eastern time). All sources were fetched that day.

Status key:

• verified: an exact quote or primary data supports it.
• verified (derived): arithmetic on verified inputs; shown in §2.
• estimate: our own model, labelled as an estimate in the issue.
• corrected: fixed before publishing; see §4.
• removed: cut because it could not be supported.

Claim numbers skip #42–#47, which covered photos cut before publishing.

Sources (P = primary):

Scroll the table sideways to see every column.

File sizes from the Hugging Face API need no quote. The byte counts are the data.

---

1. Claims ledger

A. The model

Scroll the table sideways to see every column.

B. Files and sizes

Scroll the table sideways to see every column.

C. Machines

Scroll the table sideways to see every column.

D. Speed (estimates)

Scroll the table sideways to see every column.

E. Other models in the issue

Scroll the table sideways to see every column.

F. Sizing rules of thumb

Scroll the table sideways to see every column.

G. Publication

Scroll the table sideways to see every column.

Total: 42 ledger entries (#1 to #41 and #48). 37 verified (10 of them by derivation, and 5 general-method statements: #12, #13, #20, #32, #41). 3 are labelled estimates (#29 to #31). 2 are n/a (#27, #48). 0 unverified claims remain in the issue or the explainer. Claims #49 to #51 were added in the final design (§5).

---

2. Recomputations (step by step)

GiB = 2^30 = 1,073,741,824 B. Every line was rechecked in Python.

• D1. Muse NVFP4 file size. 533,011,023,472 B ÷ 10⁹ = 533.0 GB. 533,011,023,472 ÷ 1,073,741,824 = 496.405 GiB → "496 GiB".
• D2. Muse BF16 file size. 1,644,333,393,864 ÷ 10⁹ = 1,644.3 GB. ÷ 2³⁰ = 1,531.405 GiB → "1,531 GiB".
• D3. Formula at 16 bits. 816×10⁹ × 16 ÷ 8 = 1.632×10¹² B = 1,632 GB. The real file is 0.75% larger.
• D4. Formula at NVFP4 (4.5 bits).
  • 816×10⁹ × 4.5 ÷ 8 = 4.59×10¹¹ B = 459 GB = 459e9 ÷ 2³⁰ = 427.48 GiB (Figure 2 shows "427").
  • Gap: (533.011 − 459) ÷ 533.011 = 13.9% → "14% below".
• D5. Average bits per weight.
  • NVFP4: 533,011,023,472 × 8 ÷ 816×10⁹ = 5.2256 → "5.2".
  • BF16: 1,644,333,393,864 × 8 ÷ 816×10⁹ = 16.12 → "16.1".
• Memory headroom.
  • One Mac: 512 − 496.405 = 15.59 → "16 GiB".
  • Two Macs: 1,024 − 496.405 = 527.59 → "528 GiB".
  • Figure 2 default (2 Macs, 64 GiB reserve): 1,024 − 496.405 − 64 = 463.6 → "464 GiB free" (the explainer shows this).
  • Figure 2, 1 Mac with 64 reserve: 512 − 496.405 − 64 = −48.4 → "48.4 GiB short" (the explainer shows this).
  • Figure 2, Muse BF16 on 2 Macs: 1,531.405 − 1,024 = 507.4 → "507 GiB too big".
• D6. Speed ceiling (MoE).
  • Bytes per token = 42×10⁹ × 5.2256 ÷ 8 = 27.43 GB.
  • Ceiling = 1.2×10¹² ÷ 27.43×10⁹ = 43.74 → "44 tokens/s".
• D7. Speed ceiling (if dense). All 533.011 GB per token. 1.2×10¹² ÷ 533.011×10⁹ = 2.25 tokens/s (the explainer shows "2.3/s"; the email says "about 2").
• D8. Beam bits per weight (total 501.3B):
  • BF16: 933.81 × 2³⁰ = 1,002.67 GB → ×8 ÷ 501.3e9 = 16.00.
  • FP8: 468.72 GiB = 503.28 GB → 8.03.
  • NVFP4: 273 GiB = 293.13 GB → 4.68 → "4.7". With the API bytes (293.63 GB): 4.69.
  • Figure 2, 1 Mac: 512 − 273 − 64 = 175 GiB free (matches the explainer).
• D9. FLUX 3 Image Klein.
  • BF16: 11.2×10⁹ × 8 ÷ 5.6×10⁹ = 16.0.
  • FP8: 5.6×10⁹ × 8 ÷ 5.6×10⁹ = 8.0.
  • FP8 in GiB: 5.6e9 ÷ 2³⁰ = 5.22 GiB.
  • On an 8 GiB GPU: 8 − 5.215 = 2.78 GiB free.
• D10. Rules of thumb.
  • 8×10⁹ × 4.5 ÷ 8 = 4.5 GB.
  • 70×10⁹ × 4.5 ÷ 8 = 39.4 GB → "about 39 GB".
  • 533,011,023,472 × 8 = 4,264,088,187,776 bits = 4.26×10¹² → "about 4.3 trillion".
  • ÷ 2²⁰ (1,048,576) = 4,066,551 → "about 4.1 million" chips. With 10⁶ bits per chip it would be 4.26M, so the 2²⁰ basis matters.
• Experts check. 8 ÷ 256 × 816B = 25.5B < 42B active, so about 16.5B are shared weights. This is consistent with #13 and is not published.

---

3. Second pass: trying to disprove each claim

A second pass read the issue and the explainer again as a skeptical editor trying to find errors. Findings:

• F1. GB or GiB in Meta's "700GB"?
  • The model card does not say. 700 GB = 652 GiB; 700 GiB = 752 GB.
  • Either way, one 512 GiB Mac is below it and two Macs (1,024 GiB) are above it.
  • Action: quote "700 GB" as written, give no conversion, and make no claim that depends on the unit.
  • Apple's footnote "1GB = 1 billion bytes" refers to storage. Treating Mac memory as binary rests on industry practice (S13, JEDEC), not on an Apple statement. Low risk: a 512 GB memory configuration is built from binary-sized parts.
• F2. The speed ceiling's assumptions.
  • (a) The active weights may not be at the 5.2-bit average. Attention, embeddings and shared experts may stay at higher precision, so the real bytes per token could be higher and the ceiling lower.
  • (b) With 2 Macs, each Mac holds half the model. In a pipeline, each token still crosses both Macs in sequence, so one Mac's bandwidth is a fair per-token ceiling. Tensor parallel could beat it, and Meta's "Four Macs serve fastest" hints at that. So the ceiling is not a strict upper bound for every setup.
  • (c) KV cache reads are left out, and they grow with context.
  • Action: the issue says "ceiling, not a benchmark", lists what it ignores, quotes "Four Macs serve fastest", and says "Real speed is lower. We did not measure it." The explainer says "Splitting the work across Macs can change it." This is acceptable as an estimate.
• F3. Is 816B the full parameter count?
  • The BF16 files imply 1,644.3e9 ÷ 2 = 822.2B values at 16 bits, so the files hold about 6B more than the headline. These may be extra heads or encoders, or the headline may be rounded.
  • Using 822.2B as the denominator gives 5.19 bits instead of 5.23. Both round to "5.2", so the issue holds.
  • HF's "Model size" for the NVFP4 repo shows a packed tensor count (the "484B params" figure). That counts packed 4-bit pairs, not weights, so it was not used anywhere.
• F4. "Up to 512 GB" availability. S8 lists 512 GB only for the 36-core/80-core M5 Ultra. Some press (Engadget, via search) reported that the 512 GB build ships later than the base models. The issue says "up to 512 GB" and makes no claim about availability. No change.
• F5. "8 of 256 experts." S2 gives "Experts Activated per Token: 8" and does not say "per layer". In standard MoE, routing happens per MoE layer. The issue says "each token uses 8 of them", which matches the card's wording. No change. It has one primary source; no second source was found.
• F8. "Hugging Face shows GB." A shard of 4,831,841,856 B shows as "4.83 GB" on the HF tree page, so HF uses decimal units. OK.
• F9. The issue says "The published BF16 files are 1,644 GB. That is close." The gap is 0.75%. "Close" is fair.
• F10. The FLUX "exactly 16 and 8 bits". This is exact only because BFL's own sizes are rounded to 11.2 / 5.6 GB. The real files will differ slightly. Wording kept, but note that it rests on BFL's rounded figures.
• F11. Single-source items: #4 (experts), #36 to #38 (FLUX, BFL only) and #17 (NVFP4, NVIDIA only). All are first-party sources about their own product, which is the best available source. No independent second source exists yet for a two-day-old release.
• F12. Wording "Does not fit" in the Figure 2 legend. This is a legend label, not a claim. OK.
• F13. Search-result sources. An earlier draft cited Apple, NVIDIA and the Beam card from search results. All three were re-read in full for this ledger (S8, S9, S11), and the quotes above come from those pages.

---

4. Corrections made before publishing

• Corrected the Muse Spark Open NVFP4 file size from about 480 GB to 533 GB (496 GiB). The earlier figure came from the formula, not the file. The Hugging Face API file sizes sum to 533,011,023,472 B (S3, D1).
• Corrected the average bits per weight from about 4.7 to about 5.2, recomputed from the real bytes (D5).
• Replaced an unsupported explanation of the size gap (“some parts stay at higher precision”) with “The model card does not say why the files are bigger.” No Muse source states the reason.
• Corrected the speed ceiling from about 48 to about 44 tokens per second, now labelled as a ceiling. The earlier figure used the wrong bytes per token (D6).
• Corrected the dense-model speed from about 2.5 to 2.25 tokens per second (about 2) (D7).
• Made the units consistent: “One Mac has 512 GiB. 496 GiB of weights leave 16 GiB.”
• Changed “the unit memory is sold in” to “the unit memory sizes use”. Memory is sold labelled “GB”, but the quantity is binary (S13).
• Fixed the Meta guide link, which returned 404, to dev.meta.ai/docs/cookbook/muse-spark-open-mac.
• Removed “Two years ago this needed a server room”: vague and unsourced.
• Removed per-GPU bandwidth examples that were not sourced to vendor spec pages. Only Apple’s sourced 1.2 TB/s remains.
• Dropped an HBM die photo whose licence could not be verified.

---

5. Claims added in the final design

• #49 (Figure 1): “At 16 bits the formula is within 1% of the real file.” Per D3, (1,644.33 − 1,632) ÷ 1,644.33 = 0.75%. Status: verified (derived).
• #50 (Figure 1): the bar lengths are scaled to the 1,644 GB file.
  • 1,632 ÷ 1,644.33 = 99.25%.
  • 459 ÷ 1,644.33 = 27.91%.
  • 533.01 ÷ 1,644.33 = 32.42%.
  • Status: verified (derived).
• #51 (explainer): “the weights of Muse Spark Open… How does a model that big fit on a desk?” and the 8B / 70B rules of thumb. These are the same claims as #1, #6 and #40.

Interactive figures re-checked. Scripted states of Figures 2 and 3 were compared with §2, and all match. Examples:

• 496 GiB and 464 GiB free; 48.4 GiB short; 15.6 GiB.
• Formula mode 427 GiB.
• Muse BF16 507 GiB too big.
• Beam 273 GiB with 175 GiB free; 468.72 + 64 − 512 = 20.7 GiB short; 933.81 − 512 = 422 GiB too big.
• FLUX 5.22 GiB with 2.78 GiB free; FLUX BF16 10.4 GiB (10.43 to one decimal).
• 27 GB and 44/s; dense 533 GB and 2.3/s.