LFM2.5 vs Qwen3.5 for Mobile Local AI

The comparison in one table

This comparison focuses on the compact instruction-tuned checkpoints relevant to local mobile use: LFM2.5 1.2B Instruct and Qwen3.5 0.8B. It does not compare every model carrying the LFM2.5 or Qwen3.5 family name. Vision, thinking, base, audio, larger dense, and mixture-of-experts variants have different requirements and should be treated as different products.

The upstream model cards are the authority for architecture and intended use. The application is the authority for the exact artifact, quantisation, runtime binding, and modalities it currently exposes. Those two layers should never be collapsed into one claim.

LFM2.5 1.2B Instruct and Qwen3.5 0.8B at a glance

What Liquid AI says about LFM2.5 1.2B

Liquid AI describes LFM2.5 as a family built for on-device deployment. Its official 1.2B Instruct model card identifies a 1.17-billion-parameter model with a hybrid stack of convolution and grouped-query-attention blocks. The card names English, Arabic, Chinese, French, German, Japanese, Korean, and Spanish and publishes separate native, GGUF, and ONNX variants. [1]

That edge positioning is relevant, but vendor performance figures are not a promise for an unrelated phone, quantisation, or application. Decode throughput can change with runtime build, CPU or accelerator path, thread count, prompt length, sampling, temperature, battery state, and heat. A Q4 GGUF in an Android application is not the same test object as the upstream checkpoint running on vendor-selected hardware.

LFM2.5 uses the LFM Open License 1.0 rather than Apache 2.0. The license text includes commercial-use conditions tied to the relevant entity's annual revenue. Anyone distributing a product should read the actual license and record the required release attestation; making an application free does not by itself remove a license condition. [2]

What Qwen says about Qwen3.5 0.8B

Qwen's official model card identifies Qwen3.5 0.8B as a compact post-trained causal model with a hybrid layout that interleaves gated linear-attention blocks and full-attention blocks. The family is trained as a vision-language foundation, and the official card describes broad global linguistic coverage. It also explicitly positions this small checkpoint for prototyping, task-specific fine-tuning, and research or development. [3]

The multimodal upstream architecture does not guarantee image input in a given local app. A GGUF distribution may contain only the language-model portion unless a compatible multimedia projector is also available and the runtime binding supports it. The llama.cpp documentation treats multimodal components as separate conversion artifacts. If the app labels the installed Qwen option text-only, that is the capability the user has, regardless of the base model family. [4]

Qwen3.5 0.8B is published under Apache License 2.0. That can simplify evaluation for organisations that already understand Apache notice and distribution obligations, but it is not a quality score and does not remove the need to review the model card, acceptable use, third-party runtime licenses, and the exact quantised artifact's provenance. [3] [5]

Parameter count does not decide the winner

LFM2.5 1.2B has more parameters than Qwen3.5 0.8B, but architecture, training data, post-training, tokenizer, quantisation, and runtime implementation all affect behaviour. A smaller model may be more useful for one language or constrained prompt, while the larger model may follow another instruction better. Parameter count cannot be converted into a trustworthy percentage advantage.

Artifact size also depends on quantisation and tensor treatment. A Q4_K_M file and a Q4_0 file are not identical formats simply because both names include Q4. llama.cpp provides multiple schemes and mixed-tensor options, and warns against lossy requantisation of already quantised weights. Compare the actual downloads offered by the app rather than estimating from the upstream parameter number. [4]

Runtime memory includes more than stored weights. The key-value cache, prompt tokens, output budget, tokenizer, native buffers, user interface, and any retrieved document text all need room. Android applies device-specific process limits and can reclaim processes under pressure. The model with the smaller final file is not automatically the one with the better sustained mobile experience. [6]

Language coverage: breadth versus verified task quality

Qwen's published language breadth is substantially wider than the eight languages named on the LFM2.5 card. That makes Qwen3.5 an obvious candidate when your required language is absent from LFM2.5's stated list. It still does not prove equal fluency across every language, domain, dialect, script, or quantisation. 'Supported' and 'good enough for this task' are different claims. [1] [3]

Build a small evaluation in the language you use. Ask the model to follow formatting instructions, preserve names and numbers, translate in both directions, explain an ambiguous phrase, and refuse to invent missing facts. If you work across languages in one conversation, test code-switching explicitly. Review outputs with a fluent speaker rather than using the model to grade itself.

Tokenizer design can also affect prompt length. The same sentence may consume different numbers of tokens in two models, changing how much history fits in a fixed mobile budget. The only useful comparison is generated with each model's correct tokenizer and chat template; feeding one model another family's template can create an artificial failure.

Context claims are not mobile usability claims

Both families publish substantial upstream context capabilities, but a declared maximum is not a sensible default for a phone. Long prompts increase prefill work before the first visible token and can expand the key-value cache. An interactive app should publish a tested budget for its exact artifact and runtime and may use a much smaller default to keep chats responsive.

Do not compare one model at its maximum advertised context and the other at an app default. Use the same useful input: the same recent messages, system instruction, document excerpt, and output cap. Record time to first visible output separately from subsequent streaming. If the task involves a long document, retrieval of a few cited passages may be more reliable and efficient than filling a huge context window.

A model card's maximum also says nothing about how an app truncates conversation history. Good orchestration preserves the system instruction, recent turns, required source passages, and the current question while clearly signalling when older context has been omitted. Poor orchestration can make either model look inconsistent.

Which model should you choose?

Choose LFM2.5 1.2B as your first test when your language is in its named set, you value its explicit edge focus, its exact artifact fits comfortably, and the LFM license conditions are acceptable for your use. Choose Qwen3.5 0.8B as your first test when you need a language outside that set, prefer Apache 2.0, or want to evaluate the smaller upstream checkpoint's fit on constrained hardware. [1] [2] [3] [5]

For personal mobile chat, the decisive evidence should be a same-device comparison. Use the same app version, runtime path where possible, sampling settings, prompt budget, temperature, and prompts. Cold-start each model, then repeat enough generations to observe heat and stability. Hide the model name while judging answers to reduce expectation bias.

Keep both only if the benefit justifies storage. One may become a quick everyday model and the other a fallback for a particular language or writing style. If neither passes the task, do not force a winner: a different local model or an explicitly chosen cloud tool may be more appropriate.

A task-first choice guide

A fair mobile comparison protocol

Begin with a cold launch and confirm the intended model is active. Send one exact-answer prompt to test instruction following and expose load time. Then run a balanced set: short factual extraction from supplied text, rewriting with constraints, a multilingual task if relevant, summarisation, and one task where the correct answer is to admit missing information. Validate factual claims against the supplied source rather than rewarding confident prose.

Observe the product as well as the answer. Does visible output begin promptly? Does Stop actually cancel? Can the next prompt be sent? Does the selected model survive reopening? Does the app explain a load failure or remain stuck in a thinking state? A marginally preferred response is not worth a model path that corrupts downloads, loses selection, overheats the phone, or cannot recover from cancellation.

1. Use the same app build and fully charged device under similar thermal conditions.
2. Record exact model artifact and quantisation for each run.
3. Fix system prompt, sampling settings, prompt budget, and output cap.
4. Measure cold load, time to first visible output, and completion separately.
5. Judge anonymised outputs against task-specific criteria.
6. Repeat the set to expose variability, heat, and memory leaks.
7. Test stop, model switch, app restart, and airplane-mode recovery.

The CuriousLM comparison boundary

CuriousLM's catalog can expose exact pinned LFM2.5 and Qwen3.5 artifacts, but catalog presence, artifact verification, runtime wiring, and release qualification are separate facts. The model manager is expected to show the actual download, license, modality, device requirements, and availability reason. It should not convert an upstream family capability into an unsupported app feature.

For the compact variants discussed here, CuriousLM treats the current GGUF paths as text-model choices. Image understanding belongs to separately qualified vision models and projector artifacts. Model downloads are explicit, selected state is local, and ordinary inference does not fall back to a hosted CuriousLM model when the phone cannot load one.

CuriousLM does not publish a universal LFM2.5-versus-Qwen3.5 winner because the repository has no evidence for one across Android devices. The defensible recommendation is to start with the smallest qualified option that meets your language, license, and task requirements, then use a repeatable test on your own phone. That conclusion may change when an artifact, runtime ABI, prompt template, or app version changes.

Limitations of this comparison

This guide does not report synthetic benchmark scores, crowdsourced ratings, download counts, or tokens-per-second measurements. Those values would not establish performance for the exact CuriousLM artifact on the reader's device. It also does not compare vision-enabled variants, thinking variants, larger family members, or fine-tunes.

Model cards are publisher statements, not independent guarantees. Both models can generate false, biased, unsafe, or fabricated content. Neither should be trusted as professional medical, legal, financial, or safety advice. Recheck the current model card and license before distribution because repositories and product qualification can change after this article's publication date.