Best Local AI Models for Phones and Laptops in 2026: Bonsai, Qwen, Gemma, and More Compared
Editorial standards and source policy: Editorial standards, Team. Content links to primary sources; see Methodology.
Compare lightweight, locally-runnable AI models—including Qwen, Gemma, and Bonsai—by size, RAM requirements, compatible runtimes, and license terms.
Decision in 20 seconds
Compare lightweight, locally-runnable AI models—including Qwen, Gemma, and Bonsai—by size, RAM requirements, compatible runtimes, and license terms.
Who this is for
Product managers and Developers who want a repeatable, low-noise way to track AI updates and turn them into decisions.
Key takeaways
- Current Official Snapshot (as of mid-2026)
- Choose by Device First—Not by Ranking
- Five Tasks Where Local Models Truly Shine
- How to Read the Device Selection Table
Last checked: 2026-07-16.
Talking about “local AI” today isn’t just about whether a model starts. The real question is: Can your phone or laptop run a specific task reliably—within acceptable memory, speed, and battery limits?
Bonsai 27B has recently entered mobile discussions—but its official repository currently returns a 404. Until verified weights and reproducible builds are available, treat aggregated signals as unconfirmed. For most users, quantized models like Qwen (3B–8B) and Gemma (4B–12B) remain the most practical daily drivers. The 27B tier is better suited for high-memory devices—or experimental, highly compressed deployment paths.
Current Official Snapshot (as of mid-2026)
| Path | Public Size / Format | Realistic Device Starting Point | Good First Task to Test | Verification Priority |
|---|---|---|---|---|
| Bonsai 27B | Reported as 27B, 1-bit/ternary; official repo unverified | No device recommendation yet | Wait for downloadable weights & reproducible setup | Model card, weights, package size, license |
| Qwen 3B–8B (quantized) | Open weights, multiple sizes | 8–16 GB unified memory / RAM | Chinese summarization, structured extraction, lightweight code explanation | Specific model card, quantization format (e.g., GGUF, AWQ), context length support |
| Gemma 3 (4B / 12B) | Google’s open model family | 8 GB RAM minimum; 12B strongly prefers 16 GB+ | English writing, multimodal understanding (text + image), edge-side prototyping | Gemma Terms of Use, backend compatibility (e.g., Ollama, LM Studio, llama.cpp) |
| 1B–4B lightweight models | Small footprint, widely supported (GGUF, iOS/Android formats) | Most recent smartphones or ultralight laptops | Offline classification, fixed-format parsing, privacy-first tasks | Don’t expect broad knowledge—treat as task-specific tools |
Choose by Device First—Not by Ranking
Phones face constraints beyond raw RAM. The OS consumes memory; after loading a model, you still need space for KV cache, runtime overhead, and input buffers. Long-context inference adds further pressure. A model file labeled “8GB” does not mean it runs smoothly on an 8GB phone.
Laptops require similar nuance: distinguish between unified memory (e.g., Apple M-series) and discrete GPU VRAM—and note whether your runtime offloads layers to CPU during inference.
The most pragmatic first step?
✅ Check your available idle memory, then pick a model size that fits comfortably—not just barely.
If your device has only 8 GB of available RAM, start with 4-bit quantized models in the 1B–4B range. With 16 GB of RAM, you can consider 7B–12B models—but still constrain context length. Only Apple Silicon or high-memory systems with 24 GB or 32 GB+ RAM are suitable for serious experimentation with larger models. Models at the 27B scale should only enter concrete recommendations once their weights, quantization methods, inference runners, and real-world device performance have all been publicly documented and verified.
Five Tasks Where Local Models Truly Shine
- Offline summarization of sensitive text, such as meeting notes, unreleased product specs, or personal journals.
- Structured data extraction, e.g., converting batches of invoices or forms into JSON.
- Short-answer Q&A in offline environments.
- Low-latency text rewriting, like paraphrasing or tone adjustment.
- Prompt engineering and data pipeline validation by developers, run locally during development.
For tasks requiring real-time web access, strong reasoning, or processing extremely long documents, cloud-based models usually remain faster and more practical.
How to Read the Device Selection Table
Track four key metrics:
- Model file size
- Peak memory usage after loading
- Time-to-first-token (TTFT)
- Sustained generation speed (tokens per second)
Reporting only tokens/s is insufficient: a model may appear fast but crash on long inputs due to memory pressure—or suffer high TTFT despite decent throughput afterward.
On mobile devices, also measure temperature rise and battery drain after 10 minutes of continuous inference.
On laptops, note whether inference impacts background apps—especially browsers and IDEs.
Who Are Bonsai, Qwen, and Gemma For?
- Bonsai: Best for users exploring extreme model compression and mobile LLM deployment—focus is on faithfully reproducing official runtime paths.
- Qwen: Offers broad size options, strong Chinese-language performance, and rich community-supported deployment guides—ideal for integrating local models into real-world Chinese workflows.
- Gemma: Designed for developers already using Google AI tooling who need an open-weight model for multimodal experiments or tight integration with existing infrastructure.
Choosing isn’t about ranking models globally—it’s about running fair, side-by-side tests on the same device, with identical inputs and consistent evaluation criteria.
Licenses and Privacy Go Beyond “Running Locally”
Running models locally reduces the risk of sending prompts to third-party APIs—but download tools, model managers, telemetry, and plugins may still phone home. Always audit:
- The model’s license terms
- The inference runner’s privacy settings and update behavior
For commercial use, archive the model card and license file on the day you deploy. Just because weights are downloadable doesn’t mean they’re cleared for every use case.
Specific Models & Sizes: Start With What You Can Actually Download
How to Roughly Estimate 4-bit Weight Size
Without quantization metadata, the theoretical lower bound for 4-bit weights is roughly 0.5 GB per billion parameters:
- 0.6B ≈ 0.3 GB
- 1.7B ≈ 0.85 GB
- 4B ≈ 2 GB
- 8B ≈ 4 GB
- 12B ≈ 6 GB
- 27B ≈ 13.5 GB
In practice, GGUF, MLX, or other quantization packages include additional data—scales, zero points, vocabularies, and metadata—so actual file sizes are larger. At runtime, you also need memory for the KV cache, computation buffers, and the inference engine itself.
| Model Size | Theoretical 4-bit Weight Size | Realistic Hardware Tier | Suitable Tasks |
|---|---|---|---|
| 0.6B–1.7B | 0.3–0.85 GB | Fits on 8 GB phones or laptops (with effort) | Classification, rewriting, fixed-format extraction |
| 4B | ~2 GB | Minimum 8 GB RAM; 12–16 GB recommended | Chinese summarization, light Q&A, short code explanation |
| 8B | ~4 GB | Stable on 16 GB systems | General chat, moderately complex extraction, coding assistance |
| 12B–14B | ~6–7 GB | Tight on 16 GB; 24 GB+ preferred | Higher-quality text and multimodal tasks |
| 27B–32B | ~13.5–16 GB | Requires 24–32 GB+ RAM; phones only via highly specialized compression | Experimental use, quality-first local inference |
Why Longer Context Uses More Memory
The model file size stays fixed—but the KV cache grows linearly with context length. Actual memory usage depends on multiple factors: number of layers, hidden dimension size, number of KV heads, data type (e.g., FP16 vs. Q4_K), and how well the inference engine optimizes memory layout. So there’s no single formula to derive memory use from parameter count alone.
For example, the same quantized 8B model may behave very differently at 4K, 16K, or 32K context—running smoothly in one case but crashing in another.
- On phones: cap context at 2K–4K.
- On 16 GB laptops: start with 4K–8K, then monitor peak memory usage.
Qwen3-2507’s larger variants officially support up to 256K context, even scaling to 1M—but that reflects model capability, not practical feasibility on consumer hardware.
How to Choose an Inference Engine
llama.cpp works well with GGUF models and supports CPU/GPU hybrid offloading across a wide range of hardware.
Ollama builds on top of it, offering simpler model downloading, running, and a local API.
LM Studio is ideal for GUI-based experimentation on desktops.
MLX/MLX-LM is optimized for Apple Silicon.
For Android/iOS, consider MLC, MediaPipe/LiteRT, ExecuTorch, or vendor-provided native runtimes.
Before choosing a model, verify that your target runtime supports both its architecture and quantization format — otherwise, even having the weights won’t let it run on your device.
| Runtime | Common Platforms | Pros | Limitations |
|---|---|---|---|
llama.cpp |
macOS, Linux, Windows, Android, etc. | Broad GGUF ecosystem; flexible CPU/GPU hybrid offloading | Many configuration options; mobile integration requires engineering effort |
| Ollama | macOS, Linux, Windows | Simple model download & local API | Fewer quantization/format options and less low-level control than raw llama.cpp |
| LM Studio | Desktop (Windows/macOS) | GUI interface, model search, built-in local server | Not suitable for embedding into mobile apps |
| MLX-LM | Apple Silicon only | Efficient unified memory usage; clear Python workflow | Apple-platform exclusive |
Practical Device-Specific Recommendations
- 8 GB RAM devices: Stick to 0.6B–4B models, and limit context length.
- 16 GB devices (Apple Silicon or standard laptops): Target 4B–8B models; test 12B models only with short contexts.
- 24–32 GB RAM: Seriously compare 12B–14B models; try heavily quantized 27B variants.
- 64 GB RAM: You can comfortably run 27B–32B models locally.
On smartphones, distinguish between “can launch” and “usable daily”: sustained speed, thermal throttling, battery drain, background process termination, and app package size all matter.
Licenses and Model Provenance
The official Qwen3 repository and its individual checkpoint model cards are the authoritative sources for licensing information. Gemma uses its own distinct license terms and should not be loosely labeled as “Apache/MIT-style open source.” The Ollama library serves only as a distribution channel—it does not replace or override the upstream license.
When downloading quantized packages, always verify:
- Which base or instruct version the quantization is built upon;
- Who performed the quantization;
- Whether the tokenizer or chat template has been modified.
Avoid using quantized packages whose lineage cannot be traced back to an official upstream model card—especially in commercial products.
What do Q2, Q3, Q4, and Q5 quantization labels mean?
GGUF filenames commonly include tags like Q2_K, Q3_K_M, Q4_K_M, Q5_K_M, and Q8_0.
- Lower numbers (e.g., Q2) usually mean smaller file sizes and lower memory usage—but with more noticeable quality loss.
- The K series uses grouped quantization; suffixes like M, S, or L denote different configurations within that family.
- For most users, Q4_K_M strikes the best balance between size and quality.
- Drop to Q3_K_M or Q2_K only if memory is severely constrained.
- If you have ample RAM and prioritize code generation or factual accuracy, consider testing Q5_K_M or Q8_0.
Note: Quantization changes only how weights are stored—it doesn’t alter the model’s parameter count or architecture. It also won’t magically enable unsupported architectures on incompatible runtimes.
Apple Silicon uses unified memory: the model, KV cache, OS, and other apps all share the same memory pool. On discrete-GPU systems, insufficient VRAM triggers CPU offloading—a separate performance consideration. Don’t equate “16GB unified memory” with “16GB system RAM + 8GB dedicated GPU memory”—they’re fundamentally different configurations.
Official & Primary Sources
- Qwen official GitHub: Official model family
- Google Gemma: Models and license terms
- llama.cpp: GGUF-based local inference
- Ollama library: Local model distribution
Further Reading
Related reading
FAQ
How much time does this take? 20–25 minutes per week is enough if you use one signal source and keep a strict timebox.
What if I miss something important? If it truly matters, it will resurface across multiple sources. A consistent weekly routine beats daily scanning without decisions.
What should I do after I shortlist items? Pick one concrete follow-up: prototype, benchmark, add to a watchlist, or validate with users—then write down the source link.