Hot take: Meta's Mac-ready open model proves memory, not FLOPs, is the local AI budget

Meta released the weights of Muse Spark Open on October 15, and the headline everyone repeated was that it runs on a Mac. The detail that matters is the footnote: you need roughly a terabyte of memory to do it.

Here is what was reported, and nothing more. TechCrunch and Engadget both covered the release. Meta describes it as the most capable US open-weight model to date. It is a mixture-of-experts model, about 816 billion parameters in total with around 42 billion active per token, and a context window of up to a million tokens. It is tuned for Apple silicon. The benchmark claims are Meta's own, so treat them as claims until someone independent measures them.

My take: this is the right direction wearing an awkward outfit.

I have spent years arguing that models should run where the data is. On-device, offline, under your control. So a frontier-class model with downloadable weights and a local runtime path is exactly the shift I want. It means a hospital, a defence unit or a factory floor can keep every token inside its own perimeter.

But "runs on a Mac" and "runs on a Mac you can buy" are different sentences. A model that needs a pooled cluster of high-end desktops is not an on-device model in the sense most teams mean. It is a private server that happens to have a nice case.

That is not a criticism of the release. It is a reminder to read the memory line before the marketing line.

Here is the part people skip. With a sparse model you pay memory for total parameters and compute for active ones. The 42 billion active figure is why generation can be fast. The 816 billion total is why the machine is expensive. Memory, not FLOPs, is the budget that decides whether you can deploy it.

I have seen this play out in offline deployments I have worked on. In a defence deployment, the question was never "what is the best model?" It was "what is the best model that fits the hardware we are allowed to put in that room?" The answer was almost always smaller than anyone wanted, and almost always good enough once the task was scoped properly.

So what should a practitioner do with this release?

First, do not rebuild your stack around it this week. Self-reported benchmarks on a model you cannot fit on your hardware are a poor basis for an architecture decision.

Second, do use it as a ceiling. Open weights at this scale give you a strong reference point. Distil from it, evaluate your smaller models against it, and find out how much of the gap actually matters for your task.

Third, check the licence. Open-weight is not the same as open source. Read the terms before you ship anything commercial on it, especially in regulated sectors where your legal team will ask.

Fourth, measure it yourself. If you have the hardware, run your own evaluation on your own data, including the languages your users speak. In my own work on hallucination in Indic languages, headline benchmarks told me very little about behaviour in the languages that actually mattered.

The bigger signal is the pairing. A model lab and a hardware vendor designing for each other, with the weights in the open, is how local inference becomes normal. Today the entry ticket is steep. Hardware gets cheaper faster than most people budget for, and the techniques that shrink models keep improving.

I would rather see the industry optimise for the machine in the room than for the data centre across the ocean. This release is a step toward that, even if the first step is a big one.

If you are choosing between a hosted API and local weights this quarter, do the boring arithmetic first: memory, latency, licence, and what happens to your data on each path.

Takeaway: the future of AI is local, but the memory line decides when it arrives for you.