They fit a 27-billion-parameter model on an iPhone. The compression is real. The capability is the part nobody measured.

The claim that went around this week is the kind that gets reposted before anyone reads the second paragraph: a startup called PrismML has taken Alibaba's 27-billion-parameter Qwen3.6 model, squeezed it from roughly 54 gigabytes down to under four, and run the whole thing on an iPhone 17 Pro with every parameter active. Apple, according to CNBC, is in early talks to license or possibly buy the technology. A 27B model in your pocket, no cloud, no round-trip, no data leaving the phone. The chart goes up and to the right.

Here is the thing worth saying before the reposting starts: the compression is real, and it is good work. Fourteen-to-one on memory is not a rounding trick. But "fits on the phone" and "is as good as the model it came from" are two different sentences, and only one of them got quoted. The number everyone repeated is the compression ratio. The number that decides whether it means anything is in the footnote, and the footnote says the model you fit on the phone is not the model you started with. It is a smaller, blunter thing wearing the same parameter count. How much blunter is the entire question — and PrismML has given us exactly one figure to answer it, measured in a way it has not shown.

What ternary actually does

Start with the mechanism, because the mechanism is where the honesty lives. A normal model stores each of its weights as a 16-bit number — a reasonably precise value with a decimal tail. PrismML's product, which it calls Bonsai, throws almost all of that away. In the ternary build, every weight is forced to one of three values: negative, zero, or positive — mathematically {–α, 0, +α}. Three states is log-base-two of three, about 1.58 bits per weight. The one-bit build is even more extreme: two values, a single bit. To stop the whole thing from collapsing into noise, each small group of weights keeps one full-precision scaling factor, α, that says how big "positive" and "negative" are for that group. That is the trick, and it is a clever one.

It is also not new, and PrismML does not really claim it is. Quantizing a network down to roughly 1.58 bits is the idea behind Microsoft Research's BitNet work; ternary weights have a literature that predates this launch by years. What PrismML says it has done is make the method hold up at 27 billion parameters, on a phone, with all the weights loaded at once rather than streamed. That is a genuine engineering result. Credit where it is due: they published one-bit and ternary builds of an open-weights model anyone can pull down and check, which is more than most of the labs bragging about bigger numbers ever do. If the chart only goes up, look harder — but this chart at least comes with the raw material to look.

The one number they gave us, and what it hides

So look. PrismML reports that the ternary Bonsai build "retains 94.6% of the FP16 baseline," and the one-bit build retains 89.5%. Set aside for a moment that one write-up of the same launch described the compression as coming with "no claimed performance loss," which cannot be true at the same time as a published 5.4% loss — someone's marketing copy and someone's benchmark table are not reading each other. Take the 94.6% at face value and ask the two questions that number is designed to make you skip.

First: 94.6% of what, measured how? "Retains 94.6% of the baseline" is an average, and an average across an unnamed basket of benchmarks is the single most flattering way to report a lossy transform. The 5.4% you gave up is not spread evenly like butter. Quantization damage concentrates — it lands hardest on exactly the things you buy a 27-billion-parameter model to get: multi-step reasoning, long-context recall, arithmetic, the rare tokens and low-probability continuations where the precise decimal tail was doing the work. A model can score 95% of baseline on a broad average while losing fifteen or twenty points on the one eval that represents why you didn't just run an 8B. Averages hide the tail, and the tail is the product. Which benchmarks, and what was the spread? The post doesn't say. That is the footnote.

An average across an unnamed basket of benchmarks is the single most flattering way to report a lossy transform. The 5.4% you gave up is not spread evenly like butter.

Second, and quieter: which build actually ran on the phone? The arithmetic is worth doing out loud. Twenty-seven billion weights at 1.58 bits each is about 5.3 gigabytes before you add the per-group scaling factors — comfortably above the "under 4GB" headline. The one-bit build, at roughly a bit per weight plus scales, is the one that lands under four. If the phone demo ran the one-bit build to hit the memory number, then the model in the viral clip is the 89.5% one, not the 94.6% one — you were shown the better accuracy figure and the smaller memory figure, which may belong to two different models. I am not asserting that they did this; I am saying the published numbers don't foreclose it, and a launch that wanted to be trusted would have said, in one sentence, exactly which build fit and exactly what that build scored. The absence of that sentence is information.

Compared to what?

Here is the comparison the demo is built to keep you from making. The headline pits the compressed 27B against the full-precision 27B, and 94.6% sounds like a bargain against that yardstick. But nobody deploying a model on a phone is choosing between a 4GB Bonsai and a 54GB original — the 54GB original was never going to run on the handset. The real choice, the one that decides whether any of this matters, is between PrismML's roughly-4GB compressed 27B and whatever else also fits in roughly 4GB: a well-trained 7-or-8-billion-parameter model at a boring, well-understood 4-bit quantization, which is a mature technique that lands in about the same memory envelope.

That is the head-to-head that settles it. Does a 1.58-bit 27B actually beat a clean 4-bit 8B at the same footprint, on named tasks, with error bars? Because it is not obvious that it does. There is a real school of thought that says spending your bit budget on more parameters at lower precision wins, and another that says you're better off with fewer parameters kept sharp — and the honest answer is that it depends on the task, which is precisely why you have to name the tasks. PrismML's numbers compare Bonsai to the model it compressed. The number that would tell you whether to ship it compares Bonsai to the alternative you'd actually ship instead. That number is not in the announcement. Until it is, "27B on a phone" is a memory-footprint claim doing an impression of a capability claim.

The speed and energy figures need a denominator

The rest of the pitch is a set of ratios: PrismML says the compressed models use ten to fifteen times less memory, generate responses six to eight times faster, and consume three to six times less energy than "conventional versions running on existing hardware." These are the numbers most likely to be quietly true and still misleading, because a ratio is only as good as its denominator, and the denominator here is a shrug. Faster than what, on what silicon, at what context length, at what batch size? Fewer bits mean less memory traffic, and on a memory-bound phone that genuinely can translate into real speed and real battery — the direction is right. But "six to eight times faster" than a full-precision 27B that could never have run on the device in the first place is a comparison to a hypothetical, and a comparison to a hypothetical is a number with the error bars sawn off. Six-to-eight against a 4-bit 8B on the same A-series chip would be a real claim. That is not the one on offer.

Why Apple is circling the router, not the model

The strategic tell is in who's interested and in what they'd be buying. Apple's own on-device model, AFM 3 Core Advanced, is reported at around 20 billion parameters, so a method that lets a 27B run in the same memory class is directly on Apple's roadmap for a faster, more private Siri that keeps more work on the phone. But note what Apple would actually be acquiring. It would not be Bonsai — a compressed build of somebody else's open-weights Chinese model is not a thing Apple ships. It would be the compressor: the routing method that decides which groups of weights can survive being crushed to a bit and which need more, and how to place the scaling factors so the whole thing doesn't fall over. One trade write-up put it well — Apple wants the router, not the model. That framing is the most useful sentence written about this launch, because it tells you where the value is and, by omission, where it isn't. The asset is a technique. Whether the technique holds up is a benchmarking question, and benchmarking questions are answered with named evals and error bars, not compression ratios.

None of this is a takedown. I want to be precise, because precision is the whole job: PrismML appears to have done something genuinely useful, on open weights, that anyone can verify — and "anyone can verify" is the highest compliment I hand out. The compression is real. The memory numbers are probably real. The direction on speed and battery is plausible. What is missing is the only thing that converts a good compression result into a good model: a head-to-head against the alternative that fits the same budget, on tasks with names, with the spread reported, telling us where the 5.4% went. That is a week of work for a team that clearly knows how to do it. Publish that table and the "27B on a phone" headline earns its reposts. Until then, it is the compression that fits on the phone. Whether the capability came along for the ride is a number they have not shown you — and if a chart only goes up, that missing number is the one to ask for first.