MNN vs GGUF on Android: Which Format and When
MNN and GGUF are the two model formats TokForge runs on Android and iPhone. What each one is, which models exist in which format, why the app picks one for your device, and why we will not quote you a speed multiplier.
You mostly do not have to choose. TokForge picks the format your processor can actually run, and for the models that exist in both it defaults to MNN on hardware that supports it. Where the choice is yours it comes down to what you want to do, not to a speed multiplier.
Pick GGUF when you want a specific model from Hugging Face, a specific quantization, or a fine-tune nobody has converted to MNN. The selection is far larger.
Pick MNN when you want the vision and audio capable bundles, or when your device is on the MNN path already and the model you want exists there.
TokForge is free. Android is on Google Play open testing; iPhone and iPad are in open TestFlight beta. No account, and it works with the network off once a model is downloaded.
Reading on a computer? See real measured speeds on the phone-speed leaderboard.
What they actually are
GGUF is the file format used by llama.cpp. It is the lingua franca of local models:
if a model has been released at all, someone has usually published a GGUF conversion of it within days,
at a dozen quantization levels. The quantization is named in the file, so Q4_K_M,
Q4_0 and IQ2_XXS are things you choose deliberately. Almost every local AI
app on Android is a llama.cpp app underneath, which is why they all read the same files.
MNN is Alibaba's inference engine, and its bundles are a directory of pre-converted graph and weight files rather than a single portable blob. Far fewer models exist in it, because somebody has to do the export. In exchange the mobile-specific work has already been done, and the exports can carry components a plain text model does not have, which is how the Qwen3.5 bundles TokForge ships include a visual encoder and the Gemma 4 E2B bundle includes audio.
Which models exist in which format
This is the part of the choice that is actually decided for you most of the time. From the catalogue in the shipping build, three models are offered in both formats:
| Model | MNN bundle | GGUF builds |
|---|---|---|
| Qwen3.5 4B | 2.8 GB | 2.74 GB Q4_K_M, 2.5 GB Q4_0 |
| Qwen3.5 9B | 6.8 GB | 5.68 GB Q4_K_M, 5.2 GB Q4_0 |
| Llama 3.2 3B | 2.5 GB | 2.0 GB Q4_K_M, 1.8 GB Q4_0 |
Everything else is one or the other. MNN only: Qwen3.5 0.8B, Qwen3 1.7B, Qwen3.5 2B, Qwen3.5 27B, Gemma 4 E2B, Llama 3.1 8B Instruct, Mistral 7B Instruct v0.3. GGUF only: Llama 3.2 1B, Gemma 3 4B, Phi-4 Mini Reasoning, DeepSeek R1 Distill 7B, Stheno v3.4 8B, Qwen2.5 14B IQ2_M, Lumimaid-Magnum v4 12B, Rocinante 12B v1.1, Mistral Nemo 12B, Qwen3 30B-A3B IQ2_XXS, plus anything else you pull from Hugging Face yourself.
So the honest framing is not "which format is better", it is "the model I want exists in one of them, and occasionally in both".
Why the app sometimes decides for you
TokForge profiles the processor at startup. If it reports the ARM dot-product instructions, MNN is the primary path for models that have an MNN bundle. If it does not, the app routes to GGUF instead, because the MNN kernels use instructions those cores do not have and the process faults rather than running slowly. This affects a real slice of budget and older hardware, and it is the reason the catalogue carries small GGUF entries that look redundant next to their MNN equivalents. On a device without dot-product support they are not redundant, they are the only thing that loads.
The speed question, and why there is no number on this page
This is the question everyone actually arrives with, so here is a straight answer about what is known and who knows it.
Alibaba's published work on MNN reports a large advantage over llama.cpp on mobile CPU. Independent measurements posted by users land substantially lower, and several of the comparisons circulating are not comparing like with like at all, because they put an MNN bundle at one quantization against a GGUF file at another. A four-bit model against an eight-bit model tells you about the quantization.
We are not going to settle it with a number we have not earned. We do not currently publish a run that holds the model, the quantization, the context length and the handset constant across both engines, and until we do, any multiplier we printed here would be the same kind of claim we spent an audit removing from the rest of this site.
The public leaderboard records the engine on every submission, alongside the device, the chip, the quantization where the submitter's file declares one, the app build, the peak memory and the date. It is not a controlled experiment, it is a pile of real runs from real handsets, and it is honest about being that. If you want to compare, find two rows on hardware close to yours.
Things that matter more than the engine
In practice, on a phone, the following will move your experience further than the format will.
- Model size versus your RAM. A model that is slightly too large for your device gets dropped from memory every time you switch apps, and you pay the load again. The phone RAM calculator works through it.
- Quantization. On a phone, prefer the smaller quantization of a larger model over the larger quantization of a smaller one, then check both on your own handset.
- Context length. Cache grows with it, and it grows in memory you do not have spare.
- Thermals. Sustained generation heats a handset and the chip slows itself down. A number recorded in the first thirty seconds is not the number you live with.
Common questions
Is MNN faster than GGUF on Android?
We are not going to give you a number, because we do not have one we would stand behind. A fair comparison has to hold the model, the quantization, the context length and the handset constant, and we have not published a run that does. What we can point at is the public leaderboard, which carries the engine on every row, so you can look for two rows on hardware close to yours and judge for yourself. Alibaba's own paper claims a large advantage for MNN; independent user reports land well below that. Those two things cannot both be the headline, and neither is our claim to repeat.
Which format does TokForge use by default?
The app decides per device rather than asking you. If the processor supports the dot-product instructions, MNN is the primary path. If it does not, which covers a number of older and budget ARMv8.0 chips, the app routes to GGUF, because the MNN kernels fault on those cores. This is not a preference setting that we hid from you; on the affected devices the other path does not run.
Can I import my own GGUF file?
Yes. TokForge browses Hugging Face inside the app and imports GGUF and MNN files you already have. The curated catalogue is a starting point, not a fence.
Why does the same model take more space in MNN than GGUF?
The MNN bundles TokForge ships for Qwen3.5 are native vision-language exports, so they include the visual encoder alongside the text model, and the Gemma 4 E2B bundle also carries an audio component. You are not comparing like with like on disk. Gemma 4 E2B is 3.6 GB as an MNN bundle, which is more than Qwen3.5 4B at 2.8 GB despite having fewer effective parameters.
Does GGUF quantization mean the same thing in both?
No, and this trips up most comparisons you will read. GGUF names its quantizations explicitly, Q4_K_M, Q4_0, IQ2_XXS and so on, so you know what you picked. The MNN bundles are pre-quantized by whoever exported them and the app does not surface an equivalent label. Comparing an MNN bundle against a GGUF Q8_0 file and reporting the speed difference tells you about the quantization, not about the engine.