On-device AI · 8 min read

How a language model fits on a phone

Local AI apps ask for a surprising amount of storage, and the reason is not bloat. Understanding where those gigabytes go also explains why the model is fast on a new phone and sluggish on an old one — and what the file name Q3_K_S is actually telling you.

A model is a large pile of numbers

A language model is a set of learned parameters — weights. Each is a number, and there are billions of them. "2B" in a model name means roughly two billion parameters.

Stored at full precision, each weight takes 4 bytes. Two billion weights at 4 bytes each is about 8 GB, for one of the smaller models. That is the problem in one line: the file is large because the numbers are numerous and each one is stored precisely.

Quantisation: fewer bits per number

Quantisation stores each weight using fewer bits. Instead of 32 bits per weight you use 8, or 4, or 3 — with scaling factors per block of weights so the approximation stays close to the original.

The size reduction is roughly linear:

This is lossy compression, like a JPEG. Push it far enough and you see the artefacts — in a language model those appear as vaguer answers, repetition, or a drift away from the question.

Quantisation does not make a model dumber in a uniform way. It makes it less precise, and imprecision shows up first on the hardest inputs.

Reading the file name

A name like Q4_K_M or Q3_K_S is a recipe, not a version number:

So Q3_K_S is a small 3-bit k-quant: aggressively compressed, chosen when fitting on the device matters more than the last few percent of quality.

GGUF: the container

GGUF is the file format that holds the quantised weights plus the metadata a runtime needs — tokeniser, architecture, prompt template. One file, no accompanying directory of config.

It matters for phones because GGUF is designed to be memory-mapped. Rather than reading 1.7 GB into RAM, the runtime maps the file into its address space and the operating system pages in the parts actually being used. That is why a model larger than a phone's free RAM can still run, and why the first answer after opening an app is slower than the next — the pages are still being fetched.

Why it warms the phone

Generating a word — a token — means running the input through those billions of parameters. Then doing it again for the next token. A hundred-word answer is a hundred passes.

That is sustained arithmetic on the CPU or neural accelerator, which is exactly the workload phones are thermally worst at. Devices throttle when hot, so a long uninterrupted generation gets slower as it runs. Well-built local apps pace their work — spacing tasks apart so the chip can cool — rather than queuing everything back to back.

Why old phones struggle

Three constraints, all of them hard:

This is why local AI apps state a minimum device rather than trying to support everything. Below a certain point the experience is not degraded, it is unusable.

The trade you are making

A phone-sized quantised model will not match a large cloud model on hard reasoning. For a bounded task — what does this word mean in this sentence, translate this phrase — it is entirely sufficient, and it comes with three properties a cloud model cannot offer: it works with no connection, it costs nothing per use, and the text never leaves the device.

That is the whole bargain of on-device AI. You give up the largest possible model, and you get privacy, offline capability and no metering.

How ClickBook does it

ClickBook ships a quantised GGUF model and runs it through llama.cpp on your device. On iOS it is bundled in the app, so there is nothing to download. Read more about local AI e-readers, or see how ClickBook works.