Running an LLM on your phone
Yes — small models (3–8B class) run on phones. Each tracked model page answers with a per-build table at 4K context — measured weights, labeled totals, usable RAM at 60% of the sticker.
The tracked phone models
One row per tracked phone model — the RAM door class is the headline answer; the full per-build tables (file sizes, quant ladders, which phones fit) live on each page.
Runs on a phone
| Model | Maker | Released | Params | Max ctx | Phone-class answer | Evidence |
|---|---|---|---|---|---|---|
| Gemma 4 E4B on a phone | 2026-03-31 | 8B total / ~4.5B effective | 4K | 12GB-class phone, tight Q4_K_M · 4K ctx | provisional | |
| Gemma 3n E4B on a phone | 2025-06-26 | 4.4B effective / 7.8B total | 4K | 8GB-class phone, razor-tight Q4_K_M · 4K ctx | provisional | |
| Qwen3 4B on a phone | Alibaba | 2025-04-27 | 4B dense | 4K | 6GB-class phone, tight Q4_K_M · 4K ctx | provisional |
| Phi-4 mini on a phone | Microsoft | 2025-02-26 | 3.8B dense | 4K | 6GB-class phone, razor-tight Q4_K_M · 4K ctx | provisional |
| Llama 3.2 3B on a phone | Meta | 2024-09-23 | 3.2B dense | 4K | 6GB-class phone, tight Q4_K_M · 4K ctx | provisional |
Phone answers count usable RAM at 60% of the sticker number, at 4K context — each phone page carries the per-build table and the measured file sizes.
Badges: measured = real file bytes at a pinned revision · reported = sourced and re-checkable · provisional = mixed evidence, order-of-magnitude only. Ordered by release date, newest first (ties: free RAM); positions never move when measurements update.
How we count it
How we count phone RAM
Phone answers on this site count usable RAM at 60% of the sticker number, at 4K context. The 60% is a deliberately conservative default: maintained per-device memory-budget tables span roughly 49–81% usable across real phones, because the OS and background apps take the rest. Below the line there is no swap — the app dies instead of slowing down — so every door class in the tables is a hard fit, not a comfort rating. iOS adds a second constraint: a hard per-app memory cap, usually the real binding limit; a memory entitlement raises it. Each model page's tag table carries the sources behind these numbers.
Why 4K context
All phone totals are counted at 4K context. Two reasons: it is a phone-typical default, and at 4K the KV cache is small next to the weights — a few hundred MB against multi-GB weight files — so the deciding factor is almost always free RAM for the weights, not context. The per-build tables on each page keep the two apart: measured weights, plus an explicit KV allowance, plus a runtime reserve. Push context far beyond 4K and the KV term grows, at which point that page's totals stop applying — re-check the breakdown before trusting a larger-context run.
What "tight" and "razor-tight" mean
Every door-class answer uses the site-wide margin thresholds. tight means the build fits with less than about 2.5 GiB to spare — it runs, but little else can share memory at the same time. razor-tight is the edge of that: fits measured in tenths of a GiB (one tracked build clears an 8GB-class phone with 0.1 GiB to spare). Comfortable tiers are called out by name (12GB, 16GB). The thresholds are the same across the site, so tight on a phone means exactly what it means on a desktop GPU page.
Running them on a phone
The practical path on both platforms is an on-device app: install it, download the model build, and the chat runs on the phone. Four names do almost all of that work across the tracked pages. The first thing to match is not the brand but the file format — most of the builds in the tables above are GGUF files, while Google AI Edge Gallery instead runs LiteRT builds, Google's own on-device format. Which app carries which build differs per model: each tracked page's how-to-run table lists the exact paths for that model.
Getting started in three steps
1. Pick an app by format: GGUF builds open in PocketPal (or llama.cpp on Android), LiteRT builds open in Google AI Edge Gallery. 2. Download a build from the model's tracked-builds table. 3. Import it in the app and start chatting — the complete setup guides live at each project's page linked below.
PocketPal — the easiest first step (iOS and Android)
A chat app that loads GGUF files directly: import the build from the model's page and the model runs on the phone. It is the one name that appears on both platforms across the tracked pages, which makes it the default answer when you just want to try a build.
LLM Farm — the iOS tinkerer's door (iOS)
The second iOS app in the tables, built on llama.cpp and loading the same GGUF builds. One caveat as of September 2026: it is not listed on the App Store — the project's own README calls it "temporarily unavailable". Its website still claims otherwise and we side with the README — so if you cannot find it in the App Store, that is not you; the practical iOS path is PocketPal unless you build LLM Farm from source.
Google AI Edge Gallery — the official LiteRT door (iOS and Android)
Google's official app for on-device AI. It runs LiteRT builds — published by Google as the litert-community collection — rather than GGUF, so a model only gets a Gallery row in our tables if Google ships that model in LiteRT form. That is also why a tracked model can have no Gallery row at all: no LiteRT build, no file for the app to load.
llama.cpp — the command-line base layer (Android)
The command-line project that apps like LLM Farm are built on, and the tracked path to run a model on Android without any app wrapper: inside the Termux terminal, or as a prebuilt APK. It loads GGUF builds and exposes every parameter — the tradeoff is a terminal, not a chat window.
FAQ
Can a phone run an LLM offline?
Yes — phone builds run on the phone itself: the model downloads once, and inference runs on-device, no connection needed. Each tracked page lists the exact builds measured and what they need in free RAM.
Why does RAM matter more than storage for phone LLMs?
While a model runs, it must sit in RAM: phone math counts usable RAM at 60% of the sticker number, because the OS and background apps keep the rest — and below the line there is no swap, the app dies instead of slowing down. Storage only holds the file between runs.
Which app should I use to run a model on my phone?
Match the file format first: PocketPal loads GGUF builds on both platforms, LLM Farm is the second iOS door (as of September 2026 it is not listed on the App Store, so PocketPal is the practical first stop), Google AI Edge Gallery runs LiteRT builds, and llama.cpp runs on Android from Termux or as an APK. Each tracked page's how-to-run table lists the exact paths for that model. (The app guide)
Is an iPhone or an Android phone better for running LLMs?
Both run the tracked builds — the difference is which limit bites first. The usable-RAM percentage applies on both, but on iOS the binding constraint is usually a hard per-app memory cap rather than the percentage; a memory entitlement can raise that cap. The per-build tables on each page show which phone classes fit either way. (How we count phone RAM)
Why does the app crash instead of slowing down when memory runs out?
Phones have no swap: when memory runs out the app dies instead of slowing down. That is why every phone answer on this site is a hard fit check against usable RAM — if the build fits, it runs; if it does not, no setting rescues it. Each page's table marks the line per build. (How we count phone RAM)
Can I use the same GGUF file as on my PC?
Yes — the GGUF builds listed on each page's tracked-builds table are ordinary GGUF files; a phone app reads the same file you would run on a desktop. The caveat is format support: some apps use their own compiled formats and do not load GGUF, so make sure the app you pick reads the format you downloaded. (The app guide)
Does context length matter on phones?
Every phone table on this site is counted at 4K context — a phone-typical default. At 4K the KV cache is a few hundred MB next to multi-GB weight files, so the deciding factor is almost always free RAM for the weights, not context. Push context far beyond 4K and the KV term grows, at which point the totals stop applying — each page's per-build breakdown separates weights, KV, and reserve. (Why 4K context)
Will my phone overheat or slow down on long chats?
Sustained generation is where phones differ: thermal throttling typically cuts speed within the first minute, so treat any speed number as a cold-start figure. Throttling affects speed, not fit — a build that fits keeps fitting and just runs slower. Each tracked page carries the thermal numbers and their sources in its provenance section.
What do “tight” and “razor-tight” mean in the tables?
They are margin labels on the fit verdicts. tight means the build fits with less than about 2.5 GiB to spare; razor-tight means it barely fits — tenths of a GiB (one tracked build clears an 8GB-class phone with 0.1 GiB to spare). The same thresholds run site-wide, so a tight phone verdict matches a tight desktop-GPU verdict. (The thresholds)