13 measured Arm SoCs · 19 models · no download required

Find out before you spend two gigabytes.

A model catalog that ranks on RAM and ISA flags answers "will it fit". It does not answer "will it be usable", and those are different questions: a 4 GB phone can be told a 3B model fits and still watch it generate at 3 tok/s. The only way to learn that has been to download the file first.

ENTITY answers it in half a second on the phone instead, from two measurements and one physical relationship. This page runs that same prediction against silicon somebody has already contributed a benchmark from - so it works on a laptop, for a phone you do not own.

Silicon Free memory right now

Optimising for

Every catalog model predicted on the selected SoC, best first
Model	Download	Decode tok/s	TTFT 512	Fit

Anchor device

CMF Phone 1 · Dimensity 7300 · 2.3 GB free · balanced workload

The chip picker needs JavaScript; the table below does not, and is the same arithmetic.

Recommended: DeepSeek-R1 Distill Qwen 1.5B Q4_0 - Estimated ~13 tok/s generation and ~5.3s to first token on a 512-token prompt. Q4_0 reaches Arm's KleidiAI kernels and stays small, which is what keeps generation quick. Chosen as the best balance of capability and speed for this phone.

Catalog predictions for the anchor device
Model	Download	Decode tok/s	TTFT 512	Fit
Phi-3.5 Mini Instruct Microsoft · Q4_0	2.18 GB	6.3	11.5s	tight Q4_0 reaches KleidiAI on this CPU's dotprod kernels · 2.0 GB of weights against 2.3 GB free leaves little headroom
DeepSeek-R1 Distill Qwen 1.5B DeepSeek · Q4_0	1.07 GB	12.9	5.3s	fits Q4_0 reaches KleidiAI on this CPU's dotprod kernels · 1.8B will decode slowly on this CPU
SmolLM2 1.7B Instruct Hugging Face · Q4_0	994 MB	13.9	5.1s	fits Q4_0 reaches KleidiAI on this CPU's dotprod kernels · 1.7B will decode slowly on this CPU
Llama 3.2 3B Instruct Meta · Q4_0	1.92 GB	7.2	9.6s	tight Q4_0 reaches KleidiAI on this CPU's dotprod kernels · 1.8 GB of weights against 2.3 GB free leaves little headroom
Qwen2.5 3B Instruct Alibaba · Q4_0	1.83 GB	7.6	9.3s	tight Q4_0 reaches KleidiAI on this CPU's dotprod kernels · 1.7 GB of weights against 2.3 GB free leaves little headroom
Qwen2.5 1.5B Instruct Alibaba · Q4_0	938 MB	14.8	4.6s	fits Q4_0 reaches KleidiAI on this CPU's dotprod kernels · 1.5B will decode slowly on this CPU
Qwen2.5 Coder 1.5B Alibaba · Q4_0	938 MB	14.8	4.6s	fits Q4_0 reaches KleidiAI on this CPU's dotprod kernels · 1.5B will decode slowly on this CPU
Llama 3.2 1B Instruct Meta · Q4_0	773 MB	17.9	3.7s	good fit Q4_0 reaches KleidiAI on this CPU's dotprod kernels
Llama 3.2 1B Instruct Meta · Q8_0	1.32 GB	10.5	2.3s	good fit Q8_0 reaches KleidiAI on this CPU's dotprod kernels
Qwen2.5 1.5B Instruct Alibaba · Q8_0	1.65 GB	8.4	2.9s	fits Q8_0 reaches KleidiAI on this CPU's dotprod kernels · 1.5B will decode slowly on this CPU
Llama 3.2 1B Instruct Meta · Q4_K_M · no KleidiAI	808 MB	17.1	4.3s	fits Q4_K_M misses KleidiAI - runs ggml's Arm repack kernels instead
Gemma 2 2B Instruct Google · Q4_K_M · no KleidiAI	1.71 GB	8.1	9.0s	tight Q4_K_M misses KleidiAI - runs ggml's Arm repack kernels instead · 1.6 GB of weights against 2.3 GB free leaves little headroom
Qwen2.5 0.5B Instruct Alibaba · Q4_0	353 MB	39.2	1.5s	good fit Q4_0 reaches KleidiAI on this CPU's dotprod kernels
Qwen2.5 0.5B Instruct Alibaba · Q8_0	531 MB	26.1	0.9s	good fit Q8_0 reaches KleidiAI on this CPU's dotprod kernels
SmolLM2 360M Instruct Hugging Face · Q4_0	230 MB	60.2	1.1s	good fit Q4_0 reaches KleidiAI on this CPU's dotprod kernels
SmolLM2 360M Instruct Hugging Face · Q8_0	386 MB	35.8	0.7s	good fit Q8_0 reaches KleidiAI on this CPU's dotprod kernels
Qwen2.5 7B Instruct Alibaba · Q4_0	4.44 GB	-	-	too big 4.1 GB of weights with only 2.3 GB free right now
Mistral 7B Instruct v0.3 Mistral AI · Q4_K_M · no KleidiAI	4.37 GB	-	-	too big 4.1 GB of weights with only 2.3 GB free right now
Llama 3.2 3B Instruct Meta · Q8_0	3.42 GB	-	-	too big 3.2 GB of weights with only 2.3 GB free right now

Why a prediction is possible at all

One division, not a fitted curve

Generating one token reads essentially every weight once. So the rate a phone can generate is the rate it can move bytes, divided by how many bytes the model is:

decode tok/s × model bytes = bytes the chip streams per second

The left side is two numbers already on the leaderboard. The right side is a property of the silicon and should not care which model produced it. That is a claim with a sharp edge: measure two different models on one chip and the two products must agree, or the reasoning is wrong.

Prompt processing is a different quantity - a GEMM over the whole prompt, so it tracks compute rather than memory - and it is derived the same way, from prompt tok/s × parameters with the quantization's kernel path divided out.

The test, on the two chips that were measured on more than one model

Cross-model prediction error per SoC
SoC	Predicted from	Predicted	Measured	Error
Dimensity 8300	Qwen2.5 0.5B Instruct Q8_0	35.9	30.5	+17.8%
Dimensity 7300	Qwen2.5 0.5B Instruct Q8_0	18.4	17.8	+3.2%

On the Dimensity 7300 a 531 MB Q8_0 model predicts a 773 MB Q4_0 model's generation rate to within a few percent - different model, different family, different quantization, one constant. On the Dimensity 8300 it does not, and the reason is visible in the same dataset: that chip's four contributed passes disagree with each other by 54% end to end, so there is no stable constant there to find. The method reports the spread rather than the average.

Four of these chips are floors - the real silicon is faster

Tensor G5, Snapdragon 8 Gen 2, Snapdragon 865, Snapdragon 8 Gen 1 were measured before v3.5.0 fixed the thread-derivation rule, so each ran on 2 of its 4-6 performance cores. The old rule counted cores within 10% of the fastest clock, and every modern flagship puts its prime core 17-20% above its own big cluster, so the count collapsed to 1 and was clamped to 2 - the defect this project published as falsified.

That makes these four numbers a lower bound with a known direction: a Tensor G5 or an 8 Gen 2 will beat what this page predicts for it, not fall short. Which is the useful way round - a floor you can name is worth more than an average you cannot.

A second check: the crowd against the lab

The app's probe was calibrated in a controlled session on the CMF Phone 1 - unplugged, thermally settled, llama-bench -p 512 -n 128 -r 3. Rebuilding the same two constants from nothing but unsupervised field submissions of that chip lands at 25.8 GB/s against the lab's 26.2, a -1.7% difference, and a compute score of 1.07 against the lab's 1.00, +7.3%. Nobody who submitted those runs was following the benchmark protocol.

What this is, and what it is not

It is an estimate, and the app says so on screen too

It cannot see thermal headroom, memory pressure from other apps, or the vendor's scheduler. Treat it as an order-of-magnitude guide that keeps you off a model your phone cannot serve, not as a benchmark result.
Error bars are drawn from the runs a chip actually has, so the 3 chips with repeats carry one and the rest do not. The run count is on screen either way; single passes on the same phone and model have disagreed by 19.6%.
Free memory is the axis, not installed RAM, because that is what a model has to fit into - and it moves with whatever else is running. The same phone really does have less room when it is busy.
Below 5 tok/s no recommendation is made at all. A reply arriving slower than you can read is not a smaller win; it is a different outcome.

Where the numbers come from

The 19 models are extracted from the app's own ModelCatalog.kt at build time - both copies of it, asserted identical - so this page cannot describe a catalog the app does not ship.
The prediction is a transcription of DeviceProbe.kt. A fixture of eight device profiles × 19 models - every estimate, fit verdict and recommendation - is generated from this page's code and asserted against the Kotlin original inside the app's unit test suite, so the two cannot drift apart quietly.
The per-SoC constants are derived from the public contributed dataset by scripts/derive-silicon.mjs; every device offered above is a device someone actually ran ENTITY Bench on.
Porting the probe to a page is also what found a bug in it: the app used to price a cramped fit at a fixed penalty the capability term simply outbid, and would recommend a 2.18 GB download at 6.3 tok/s over a 1.7B model at 14.6. A tight fit is now excluded outright.

Prefer a measurement to a prediction: ENTITY Bench runs the real thing on your phone in a few minutes, and the leaderboard is where its result would land.