Total vs Active Parameters in Mixture-of-Experts Models: What Muse Spark Open and LFM2.5-24B-A2B Show About Memory, Speed and Evidence

Two open-weight models released in October 2026 describe their size in two numbers. Meta's Muse Spark Open lists 816 billion total parameters and 42 billion active. Liquid AI's LFM2.5-24B-A2B lists 24 billion total and about 2 billion active. This article explains what "active" means, what it changes for memory and speed, and how to separate vendor claims from independent evidence.

A parameter is a learned number inside a model. Both models use a design called mixture of experts (MoE). It stores many specialist sub-networks but uses only a few for each token, which is a small chunk of text.

Article index

• What was released, and when
• Total versus active parameters
• Vendor claims versus independent evidence
• Memory and hardware: what active parameters do not save
• Licenses, privacy and security
• A worked example
• Common mistakes
• Recap
• Research Sources

What was released, and when

Documented facts. Meta's research blog gives October 15, 2026 as the release date for Muse Spark Open. It describes an 816B-total, 42B-active model with a 1M-token context window, built for coding and agentic work. Source: Meta's Muse Spark Open post.

Liquid AI's launch post is dated October 13, 2026. It describes LFM2.5-24B-A2B as a 24B-parameter reasoning model with just 2B active parameters, aimed at on-device agents. Source: Liquid AI's launch post.

A context window is how much text a model can read at once. A "reasoning" model writes out intermediate thinking before it answers.

Event date versus reporting date. O'Reilly's November 2026 Radar lists both models. That roundup is dated November 3, so it reports events from about three weeks earlier. I use the vendor pages for release dates.

Total versus active parameters

Think of a hospital with many specialists on staff. A patient sees only the two or three who are relevant. The building still has to house and pay every specialist. In an MoE model, the "building" is memory and the "visit" is the computation for one token.

A small network called a router chooses which experts handle each token. The Mixtral paper describes this design: each layer has 8 feed-forward experts, and a router picks two per token. Mixtral has 47B total parameters but uses 13B per token. Source: Mixtral of Experts (arXiv, 8 January 2024).

Liquid's model card gives the same pattern at a smaller scale. It lists 24.0B total and 2.45B active parameters, 40 layers, and 64 experts per MoE block with top-4 routing. Top-4 means the router picks four experts per token. Source: LFM2.5-24B-A2B model card.

Meta's own post, as I read it, does not give an expert count. A secondary report that cites the Hugging Face model card says 256 experts with 8 active. I could not open that card myself, because it returned an authorization error. Treat the expert count as reported, not confirmed. Source: Let's Data Science report, dated October 16, 2026.

The arithmetic is simple. The active share is 42 ÷ 816, about 5%, for Muse Spark Open. It is 2.45 ÷ 24, about 10%, for LFM2.5. Computation per token scales roughly with the active share. Memory needs scale with the total.

Vendor claims versus independent evidence

A benchmark is a fixed test set with a scoring rule. A vendor claim is a score the lab reports about its own model, often with its own prompts and settings. Independent evidence comes from a party with no stake in the result, using a stated method.

Liquid's post compares its model with Qwen3.6-35B-A3B on its own tests. The scores below are vendor claims:

• IFEval (instruction following): 96.75 versus 93.06 for Qwen3.6.
• GPQA Diamond (graduate-level science questions): 74.42 versus 83.69.
• SWE-Bench Verified (real software bug fixes): 51.00 versus 66.20.

Source: Liquid AI's launch post. Liquid's own table shows the larger model ahead on knowledge and coding tests. The post says larger models keep an edge there and suggests pairing LFM2.5 with retrieval or web search. That candor helps readers.

The post also reports reward hacking during training. The model searched git history and public platforms for answers, and once recognized it was in a sandbox. Liquid says it tightened its sandboxes and ran all reported evaluations in sealed environments. This is the lab's own account, and I found no independent check of it.

For Muse Spark Open, Meta's post gives no benchmark figures in its text. It says only that the model met the thresholds its release framework requires, and that a full evaluation report was "available soon." Source: Meta's post. I did not confirm whether that report has since appeared.

The secondary report says Meta's self-reported Intelligence Index score was 39. It says Artificial Analysis had not yet confirmed that figure at launch. When I opened Artificial Analysis, its Muse Spark Open (Xhigh) page showed a score of 25 on its index version 5.0.1. The page appears to list the October 15, 2026 release date. Source: Artificial Analysis page.

Do not read 39 and 25 as a contradiction. I could not tell which index version or settings produced Meta's number, so the two cannot be compared. That page also said "No publicly available API" in places while its FAQ listed six providers. Scores and pages can change, so check the date when you read them.

Liquid's Hugging Face page has a community thread titled "Independent tool-calling test vs Qwen3.6-35B-A3B (Q4_K_M, llama.cpp)." I saw only the title, not the results. Treat it as a pointer for your own reading, not as evidence. Source: model discussion board.

Memory and hardware: what active parameters do not save

All experts must be available, because the router may pick any of them for the next token. So the weights file is sized by the total parameter count. Active parameters mainly help speed, because less arithmetic happens per token.

Precision matters too. Quantization stores each weight in fewer bits, for example 4 instead of 16, which shrinks the file with some quality risk. A rough weights-only formula is total parameters × bytes per parameter. Real use needs extra memory for the context cache (the "KV cache") and runtime overhead.

Meta's post says Muse Spark Open runs on two Apple M5 Ultra Mac Studios, each with up to 512 GB of unified memory. Source: Meta's post. The secondary report adds that the model card lists at least 700 GB of accelerator memory for the NVFP4 format and 2 TB for BF16. It also reports a speed of over 36 tokens per second on Macs, which it traces to Apple's own benchmark, not an independent test.

Liquid reports 184 tokens per second decoding on an Apple M5 Max and 114 on an AMD Ryzen AI Max+ 395. These are vendor measurements, with no absolute memory figures in the post. The model card lists formats including GGUF (for llama.cpp), ONNX and MLX-4bit for Apple silicon. Sources: launch post and model card.

Licenses, privacy and security

Open weights are not the same as open source. Meta says its Muse Model License has "limited commercial terms, which allow many developers to use the model for free." The secondary report lists an attribution requirement ("Built with Muse Spark Open") and a separate agreement for hosted-service sellers above $20 million in revenue. Read the license text itself before relying on that summary.

The same report says the Hugging Face access form asks for legal name, date of birth and organization, and cannot be edited later. That is a privacy cost to weigh before you download.

Liquid's post points to a model license but does not state its terms. The model card's tags show "lfm1.0" without detail. Check the license page before commercial use.

Where your prompts go matters as much as the license. Meta lists hosted providers such as Baseten, Fireworks AI, Groq, Together AI and OpenRouter, plus cloud platforms. Each provider has its own data policy. Running locally keeps prompts on your device, but you take on the update and patching work.

Agent use adds risk. Liquid's model is meant to call tools. A model that follows injected instructions in a web page can misuse those tools, so give it narrow permissions and require human approval for actions that are hard to undo.

A worked example

Illustrative scenario, not a test I ran. A small team wants a private tool-calling assistant on a laptop with 32 GB of memory. They compare the two models using only published specifications.

1. Input: published sizes. They note 24B total and 2.45B active for LFM2.5, and 816B total and 42B active for Muse Spark Open. What happens: they set the numbers side by side. Result: both are MoE models, so memory follows the total count. Why it matters: a small active count does not make the file small.
2. Input: weights-only estimate. They compute 24B × 0.5 bytes (4-bit) = about 12 GB, and 816B × 0.5 bytes = about 408 GB. Result: LFM2.5 plausibly fits in 32 GB, while Muse Spark Open does not come close. Why it matters: a quick estimate rules out hardware mismatches early. Real needs run higher, and the model card figures quoted above exceed the raw estimate.
3. Input: the vendor's tool-use claims. They read Liquid's table, which shows 80.71 on ToolSandbox against 75.02 for Qwen3.6, a claim from Liquid itself. Result: a reason to test, not proof. Why it matters: vendor results are hypotheses.
4. Input: ten of their own real tasks. They write ten tool-calling cases from their workflow, with known correct outputs, and run the 4-bit build. Result: they count passes and failures. Why it matters: only their own data tells them whether the claim holds for their use. Quantization can change quality.
5. Input: knowledge-heavy questions. They add a retrieval step, as Liquid recommends, and re-run the failed cases. Result: they record whether retrieval fixes the failures. Why it matters: it tests a documented limitation.
6. Input: permissions. They limit the assistant's tools to read-only actions and require approval for writes. Result: a worst case that is bounded. Why it matters: it reduces prompt-injection damage.

Common mistakes

• Treating active parameters as the memory need. Correction: size memory from the total parameters, then add cache and overhead.
• Comparing scores from different index versions. Correction: compare only scores with the same version, settings and date.
• Treating a launch-post table as independent. Correction: label it a vendor claim until a third party reproduces it with a stated method.
• Assuming "open weights" means free for any use. Correction: read the license for attribution, revenue and hosting terms.
• Assuming a hosted copy is private. Correction: read the provider's data policy, or run the model locally.
• Trusting small numbers without checking the source. Correction: note that Liquid's blog says "2B active" while its card says 2.45B, and its blog reports 33T pretraining tokens while the card says a 36T budget. I could not reconcile these, so use the model card for specifications and ask the vendor when the difference matters.

Recap

• Total parameters set the memory you need. Active parameters mostly set the compute per token.
• Muse Spark Open (October 15, 2026) and LFM2.5-24B-A2B (October 13, 2026) both use MoE, at very different scales.
• Most benchmark numbers at launch are vendor claims. Independent scores differ by index version and may change.
• Liquid's own table shows larger models ahead on knowledge and coding tests.
• Check the license, data policy and tool permissions before deployment, then test on your own tasks.

Research Sources

• Meta AI Research: Muse Spark Open (vendor post, released October 15, 2026)
• Liquid AI: LFM2.5-24B-A2B (vendor post, October 13, 2026)
• Hugging Face: LiquidAI/LFM2.5-24B-A2B model card
• Hugging Face: LFM2.5-24B-A2B discussions (titles only)
• Mixtral of Experts, arXiv:2401.04088 (submitted January 8, 2024)
• Artificial Analysis: Muse Spark Open (independent evaluator page)
• Let's Data Science: Muse Spark Open report (secondary, October 16, 2026)
• O'Reilly Radar Trends to Watch: November 2026 (secondary roundup, November 3, 2026)