AINEWS
Hacker News testers tried Deepgrove's 20 billion parameter AI model on a phone at 120 word pieces a second and found it confidently wrong on a niche fact a peer model handled correctly.
A 20-billion-parameter AI model called Maple-Preview hit a vendor-reported 120 tokens a second on an iPhone this week, and the Hacker News thread under the Show HN post spent most of its attention on a different problem: what on-device models should do when they hit a topic they cannot honestly answer.
"Tokens" are the small word-pieces language models read and write. 120 per second is well past reading speed, which means the model is not the bottleneck in a normal chat session. With no network round trip, the reply arrives at chat latency.
Maple-Preview is the work of Deepgrove, and it pairs two compression techniques that are not new on their own but are new in combination at this scale. "Ternary" means each weight is stored as one of three values, roughly minus one, zero, or plus one, instead of the 16-bit number most open-weight models still ship with. "MoE," short for mixture-of-experts, means only a small slice of the model's parameters is active for any given token; the rest sit idle for that word. Together, those two tricks shrink the working memory the phone has to touch to generate each word. The result, on paper, is a 20-billion-parameter model that fits the throughput budget of a phone chat session without server help.
The 120 tokens a second number is the vendor's. Deepgrove's submission is the only measurement of that throughput in the public receipts; no third-party benchmark on the iPhone run has surfaced. The model itself is publicly available. The Hugging Face model card carries the weights, and a community GGUF mirror lets people run it on consumer hardware without a custom Deepgrove stack. That is enough to test, and the HN thread tested.
The thread's most substantive exchange was a small stress test that did not start as one. A commenter asked the model for the etymology of a common word, the kind of question any fluent chatbot should handle. Maple-Preview answered, fluently and confidently, with an etymology that was wrong. The same commenter then asked a peer model, Qwen 35B-A3B, and got the correct origin. The exchange is not a dunk on Maple-Preview. It is a doorway into what the on-device form factor does to the answer.
On a phone with no network, the model cannot fall back on a web search the way a cloud chatbot can. If it does not know something, it has three honest options. It can say so. It can use a tool the host app wires up for it, a calculator, a local file lookup, a calendar read. Or it can stay inside the narrow set of questions its training actually covers. The HN thread's most constructive commenters landed on roughly the same conclusion: the next gain in on-device models is calibration, with throughput at this scale mostly settled. "Calibration" here means the model knowing when it does not know, and routing around the gap instead of talking through it.
This is also the constructive read of the speed story. Throughput at 20 billion parameters, on a phone, is no longer the bottleneck it was a year ago. An app that wants a local assistant today can reach chat speed with a ternary MoE at this scale, and the weights are small enough to ship inside the app bundle if a developer wants offline guarantees. The bottleneck is the next question: which of those three honest options a phone-sized model picks when a user asks it something outside its training slice.
A few caveats carry. The 120 tokens a second figure is vendor-measured and still needs a third-party on-device run to confirm. The comment-thread etymology test is one anecdote, not a benchmark. The Qwen comparison points at a real gap without measuring it across a proper eval suite. And the calibration framing is a read of one HN thread, not a result. The direction the thread points, though, is the one that matters for the next wave of on-device work: less speed, more honesty about what the model cannot know.