Our small open model answered a stock question in 4.25 s on a 4 GB Galaxy A05s. In that same run, its first turn took 13.4 s, right after a print preview, and that gap is still open.

Both times come from a whole-app run of a test build (31 Oct), with airplane mode on, using 673 MB of model memory. So can it run on a 4 GB phone? On the phone we tested, yes. But "does it run?" is not where the check should stop.

Here is what we measured, in the order we would check it on any budget phone. Every timing below is from one phone model, a Galaxy A05s (4 GB, Snapdragon 680), measured on a real device in Firebase Test Lab (FTL). The one accuracy result is different: it was scored on a server (layer EVAL), and we label it where it appears.

The model is a small open model taught only one app's tasks. That app is our first build, pharmacy software, and the model runs inside its offline edition.

First check: does it fit on the phone?

Three numbers decide whether a model fits: its file size, its memory in use and its first load.

What Measured (FTL) Where it comes from
Model size 489 MB the model file, qwen3-0.6b-v18-Q6_K.gguf
Model memory 673 MB the model in memory during the whole-app run, on a phone with 4 GB in total
First launch 18.8 s the whole-app run, cold_start_ms 18786

The whole-app run: Android 15, airplane mode, run PASSED, test build of 31 Oct. No later merged build has passed a whole-app run yet.

The model fits. But fitting is not the same as being fast enough, so writing speed gets its own test.

Second check: how fast does it write?

This is a separate llama-bench run on the same phone model, with the setting that shipped. The network was not controlled (not airplane mode), so do not read these rows together with the whole-app run above.

Test Context already in place Mean tok/s Standard deviation
Writing, tg64 d0 (empty) 14.82 0.16
Writing, tg64 d768 11.02 0.01
Prompt reading, pp128 d0 (empty) 25.45 1.35
Prompt reading, pp128 d768 20.33 0.07

Layer FTL. Galaxy A05s SM-A057G, Snapdragon 680 'bengal', llama.cpp 620d222 (armv8a), 4 threads. These are the settings that shipped: f16 KV cache, flash-attn 0 (off), repack 0 (off).

How to read the names: tg64 is the writing test and pp128 the prompt-reading test; the number in each name is how many tokens it writes or reads. d0 means the context is empty. d768 means 768 tokens are already in context.

The d0 row is the number people quote: 14.8 tok/s from an empty context. But an app rarely runs with an empty context. A system prompt and chat history push it toward the other row: 11.0 tok/s with 768 tokens already in context. So if your app carries history, read d768 first, and ask any phone benchmark which depth it used.

What this does not show

  • Other phones. These are results from one phone model, the Galaxy A05s.
  • General chat. The model is taught only one app's tasks, so if you need a general chatbot, it is not a fit.
  • Battery or energy use. Energy use was not measured.
  • Answer quality on the phone. A phone timing does not answer that. Accuracy needs an exam on your app's tasks. Our one exam result is on an earlier version and was not run on the phone: 0.6B vs its 8B teacher, +13 pts (95% CI +4.0 to +24.4); v7, not the shipped v18; frozen real test, 40 shops, shop-clustered, scored on a server (layer EVAL).
  • Your app. A build for your app would need its own measurements on your users' devices.

Run the same test on your phone

One phone cannot answer this for the phones your users own. Our tuned weights are private, so you cannot rerun our model. But you can run the same test with the same flags on a public Q6_K file of Qwen3 0.6B. That result describes a different model, so label it as such.

The recipe is on the dataset card of neykosa/phone-llamacpp-bench:

  • Build llama-bench for Android arm64 from llama.cpp commit 620d222. llama.cpp's own NDK guide covers the build.
  • Run the one adb command on the card.
  • Run bench_row.py to turn the llama-bench JSON into a block you can paste.

Post that block in the dataset's Discussions, with your phone model and whether the network was controlled. A run that failed to build or load is useful too. We have not walked an outside build through those steps, so a note on where yours broke helps the next person. Full run conditions are on our benchmarks page.

Disclosure: Team Neykosa builds small open models taught only one app's tasks, to run on its users' own phones and laptops, so read these numbers knowing who measured them. An AI agent wrote this article from our published measurement page with little to no human editing, and it is marked Fully Autonomous on DEV. Every number was checked against our measurement records before publishing. First published on neykosa.com.