2024年本地跑大模型的场景还处于「能跑就行」的阶段。2026年的今天，我们已经过了那个阶段——现在的问题是选哪个、怎么跑、跑多大。

这两年我折腾了所有主流方案：从抱着显卡跑的 llama.cpp 到一键装的 Ollama，从 GGUF 到 AWQ 量化，从 0.5B 的玩具模型到能实际干活的 7B。这篇文章把踩过的坑和验证过的结论汇总成一张选型地图。

你不需要8张A100。你也不需要16GB显存。你只需要一台上网本的算力，就能跑出一个有用的本地AI服务。

核心结论前置：Ollama 是大多数人的答案，llama.cpp 是进阶玩家的工具箱，MLC-LLM 是移动端的未来，其余方案各有场景但我不会无脑推荐。

下面展开说为什么。

一、先搞清楚你能跑什么

在选引擎之前，先搞清楚你的硬件能跑什么级别的模型。这张表是基于真实运行经验的，不是官方标称。

关键认知： 如果你的需求是翻译、摘要、简单对话、结构化数据提取——1.5B-3B 的模型完全够用，而且快得不像本地模型。 不需要上 7B、不需要 GPU、不需要折腾。

很多人一上来就追大模型，实际上90%的日常任务，小模型跑在CPU上已经比你打字快。

另一个关键认知： 推理速度和模型大小的关系不是线性的。3B 模型的速度大约是 7B 的 3-5 倍。如果你只需要翻译一段话，3B 模型 80 tok/s 的体验是「秒出」，7B 模型 15 tok/s 是「等一下」。差别巨大。

二、引擎选型：四选一

第一名：Ollama（推荐度：⭐⭐⭐⭐⭐）

一句话：如果你只想用不想折腾，装 Ollama。

Ollama 不是一个新的推理引擎——它是 llama.cpp 的封装层。它把模型下载、量化选择、推理参数、API 服务都包成了一个命令的事。

# 安装
curl -fsSL https://ollama.com/install.sh | sh

# 跑一个模型（自动下载+运行）
ollama run qwen2.5:1.5b

# 跑API服务（默认端口11434）
ollama serve

装完 ollama run qwen2.5:1.5b，你就有了一个本地的 ChatGPT——接入任何 OpenAI 兼容客户端（Open WebUI、ChatBox、NextChat），只要把 API base URL 改成 http://localhost:11434。

优势：

• 零配置：一行命令装好，一行命令跑起来
• 模型管理：ollama pull / ollama rm / ollama list，不需要手动去 HuggingFace 翻文件
• API 兼容：原生支持 OpenAI 格式，所有现有客户端直接对接
• 多平台：Linux / macOS / Windows 全支持
• 社区模型库：超过 10 万个模型标签，从 0.5B 到 70B 全覆盖

劣势：

• 定制空间有限（你不能改推理内核参数）
• 对多GPU和分布式场景支持弱（但个人用不到这个）

结论： 个人开发者、单机用户、不想折腾的人，Ollama 就是最终答案。别想了，装它。

第二名：llama.cpp（推荐度：⭐⭐⭐⭐）

一句话：如果你需要精细控制、极度压榨硬件性能、或者想搞懂底层原理——用 llama.cpp。

llama.cpp 是底层推理引擎。Ollama 的底层就是它。如果你直接用它，能得到：

• 更精细的推理参数控制（thread 数、batch size、context size、GPU 层数分配）
• 更小的二进制体积（一个可执行文件，无依赖）
• 能在真正的弱鸡硬件上跑（树莓派、OpenWrt、旧手机）

# 编译（纯CPU版本）
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j

# 推理（手动下载GGUF文件后）
./llama-cli -m qwen2.5-1.5b-q4_k_m.gguf -p "你好" -n 256

什么时候选 llama.cpp 而不是 Ollama：

• 你只有 2GB 内存，需要每 MB 都抠出来给模型
• 你想跑自定义模型格式，不限于GGUF
• 你想嵌入到自己的 C/C++ 项目里（用 llama.h API）
• 你想在嵌入式设备或非常规平台上运行

什么时候别选： 你有 4GB 以上内存 + 只是想跑个本地服务。选 Ollama，省下的时间写业务代码。

第三名：MLC-LLM（推荐度：⭐⭐⭐）

移动端专用的选项。

MLC-LLM 的独特卖点是它能把模型编译到 Vulkan / Metal / OpenCL 后端——也就是说，你的手机、平板、甚至集成显卡都能跑。它的优化深度比 llama.cpp 更强，在移动设备上性能更好。

如果我上面说的那个 AI 翻译助手 App 要做本地推理，MLC-LLM 是移动端优先选择。

# 安装
pip install mlc-llm

# 跑起来
mlc_llm chat HF://Qwen/Qwen2.5-1.5B-Instruct-q4f16_1-MLC

劣势： 安装过程比 Ollama 复杂，文档碎片化，社区规模小一个数量级。

第四名：剩下的（不推荐）

vLLM —— 个人项目用不上。它是给大并发场景服务的（批量推理、PagedAttention），单用户本地跑没有任何优势，反而内存开销更大。

ExLlamaV2 —— 只支持 Llama 架构的模型，且需要 GPU。如果你的机器有24GB以上显存跑 30B+ 模型，可以考虑。

llama.py / transformers —— 直接跑原始 PyTorch 模型。不要。除非你在做模型训练或微调。推理用这些等于开卡车去买菜。

三、模型选型：小模型里挑能打的

选定了引擎，接下来选模型。下面是经过实际测试的、在消费级硬件上好用的模型推荐。只列 3B 及以下的「轻量实用派」，因为如果你要跑 7B+，你大概率已经有自己的偏好，不需要我推荐。

通用对话/翻译

结论：中文优先直接锁 Qwen2.5 系列。 1.5B 版足够做翻译和结构化输出。3B 版能做有一定质量的对话。而且它对中文 prompt 的理解远超同尺寸的其他模型。

代码补全

代码场景里，DeepSeek 系列在代码填空任务上表现突出。Qwen Coder 在全量代码生成上更好。

Embedding（向量化）

如果你有 RAG 项目需要本地向量化，建议直接上 bge-base。bge-small 虽然小，但语义区分度差距在真实场景里能感受到。

四、量化选择：不要无脑上最低精度

很多人觉得量化越低越好——"Q2 比 Q8 小四倍，肯定选 Q2啊"。错。

量化的核心规则是：在内存够的情况下，选你能跑的最高的量化等级。

我测试了几个常用模型的量化等级在翻译任务上的表现差异（BLEU评分）：

• Q8_0：基准性能（几乎无损）
• Q6_K：损失 ~1-2%，体积减少 25%
• Q4_K_M：甜点——损失 ~3-5%，体积减少 50%
• Q3_K：损失 ~5-10%，体积减少 60%
• Q2_K：损失 ~15%+，不建议用于正式任务

推荐规则：

• 内存充足（>= 8GB）：选 Q8_0 或 Q6_K
• 内存中等（4-8GB）：选 Q4_K_M（这是最通用的甜点）
• 内存紧张（2-4GB）：选 Q4_K_M 跑小一号的模型，不要选 Q2_K 跑大一号的模型
• 极低内存（< 2GB）：你可能需要 0.5B 模型 Q4_K_M，或者放弃本地推理

核心原则：宁可换小模型也不要开低量化。 Q4_K_M 的 3B 模型比 Q2_K 的 7B 模型在实际任务中表现更好——因为低量化带来的精度损失远大于参数量的增加。

五、部署方案：三个典型场景

场景A：本地开发翻译工具（推荐）

ollama pull qwen2.5:3b
ollama run qwen2.5:3b
# API 跑在 localhost:11434

接入任何 OpenAI 客户端。4GB内存的笔记本就能流畅跑。翻译质量足够日常使用。

配合 SillyTavern 或者 Open WebUI 可以获得聊天界面。用 curl 直接调 API 可以嵌入你的脚本。

curl http://localhost:11434/api/chat -d '{
  "model": "qwen2.5:3b",
  "messages": [{"role": "user", "content": "翻译成英文：今天天气真好"}],
  "stream": false
}'

场景B：RAG + 本地向量化

ollama pull nomic-embed-text
ollama pull qwen2.5:7b

用 Ollama 同时提供 Embedding API 和 Chat API。后端（Python/Go）调用 localhost:11434/api/embeddings 做向量化，用 localhost:11434/api/chat 做生成。

向量数据库用 sqlite-vec 或 ChromaDB（本地文件存储，零运维）。

场景C：移动端嵌入（AI翻译助手App场景）

如果你要做手机App内本地推理：

• Android： 用 MLC-LLM 编译到 Vulkan 后端，或 execuTorch
• iOS： MLC-LLM + Metal 后端，或 CoreML 转换
• 跨平台： Flutter 项目里用 MLC-LLM 的 C++ SDK 封装成 FFI 调用

模型推荐：Qwen2.5-1.5B-Q4_K_M（~1GB），手机上推理速度约 20-40 tok/s。

但这个场景的工程复杂度比桌面端高一个数量级。 我的建议是：MVP先用 Ollama 桌面API验证产品逻辑，稳定了再考虑移动端本地推理。

六、所以：一个决策树

你有多少内存？
├── < 2GB → 放弃本地推理，用云端API
├── 2-4GB → 装 Ollama，跑 Qwen2.5:1.5b Q4_K_M
├── 4-8GB → 装 Ollama，跑 Qwen2.5:3b Q4_K_M
├── 8-16GB → 装 Ollama，跑 Qwen2.5:7b Q4_K_M 或 Qwen2.5:3b Q8_0
└── > 16GB → 装 Ollama，跑 Qwen2.5:14b Q4_K_M（或者上其他7B Q8_0）

看到了吗？无论什么配置，答案里都有 Ollama + Qwen2.5。

不是因为我是阿里水军。是因为在2026年的今天，对于个人开发者，"装好就用、不需运维、跑起来够快、中文友好"这四个要求同时满足的组合，就是 Ollama + Qwen2.5 系列。没有第二个选项能做到同样的平衡。

如果你非要和别人不一样——

• 你要极致省内存 → llama.cpp 自己调参
• 你要移动端跑 → MLC-LLM
• 你要纯英文 → 换 Phi-3.5 或 Llama-3.2

但大多数人不属于这些场景。大多数人的场景是：我有个想法，我需要一个本地AI帮我干活，我不想花三天配环境。

那就装 Ollama。

curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5:3b
ollama serve

三行命令，十分钟，你的本地AI跑起来了。

Running AI Models Locally in 2026 — A Lightweight Inference Guide

In 2024, running LLMs locally was at the "if it runs at all, you win" stage. By 2026, we're past that. The question now is which one, how to run it, and how big should you go.

I've spent the last couple of years testing every mainstream approach: llama.cpp for bare-metal performance, Ollama for zero-setup convenience, GGUF vs AWQ quantization, everything from 0.5B toys to 7B workhorses. This article distills all the trial-and-error into a decision map.

You don't need eight A100s. You don't even need a dedicated GPU. You just need the equivalent of a netbook to run a useful local AI service.

TL;DR: Ollama is the answer for most people. llama.cpp is the power-user toolkit. MLC-LLM is the mobile future. Everything else is niche.

I. What Your Hardware Can Actually Run

Before choosing an engine, know what your hardware supports. These numbers come from real-world experience, not spec sheets.

Key insight: If you need translation, summarization, simple chat, or structured data extraction — a 1.5B-3B model is more than enough, and it's fast enough to feel instant. You don't need 7B. You don't need a GPU. You don't need to overthink it.

Most people chase big models when 90% of daily tasks run perfectly well — and much faster — on small ones.

Second key insight: Speed doesn't scale linearly with size. A 3B model runs 3-5x faster than a 7B. For translation, 80 tok/s means "instant" while 15 tok/s means "wait a second." The difference in user experience is enormous.

II. Engine Selection: Pick One of Four

#1: Ollama (⭐⭐⭐⭐⭐)

One line: if you want to use AI, not configure AI — install Ollama.

Ollama wraps llama.cpp with a model management layer. Downloads, quantization, inference params, API server — all in one command.

# Install
curl -fsSL https://ollama.com/install.sh | sh

# Download and run
ollama run qwen2.5:1.5b

# API server (port 11434)
ollama serve

After ollama run qwen2.5:1.5b, you have a local ChatGPT. Any OpenAI-compatible client (Open WebUI, ChatBox, NextChat) works by pointing to http://localhost:11434.

Pros:

• Zero config: one command to install, one to run
• Model management: ollama pull / rm / list — no manual HuggingFace file hunting
• API compatibility: native OpenAI format, works with all existing clients
• Cross-platform: Linux, macOS, Windows
• Community library: 100K+ model tags, from 0.5B to 70B

Cons:

• Limited customization (can't tweak kernel-level inference params)
• Weak multi-GPU / distributed support (irrelevant for personal use)

Verdict: For individual developers and single-machine users who just want results — Ollama is the final answer. Stop deliberating and install it.

#2: llama.cpp (⭐⭐⭐⭐)

One line: if you need fine-grained control, squeeze every MB of performance, or understand the internals — use llama.cpp.

llama.cpp is the underlying inference engine. Ollama runs on top of it. Using it directly gives you:

• Finer parameter control (threads, batch size, context size, GPU layer split)
• Smaller binary (single executable, zero dependencies)
• Runs on absurdly weak hardware (Raspberry Pi, OpenWrt, old phones)

# Build (CPU-only)
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j

# Inference (after manually downloading a GGUF file)
./llama-cli -m qwen2.5-1.5b-q4_k_m.gguf -p "Hello" -n 256

When to choose llama.cpp over Ollama:

• You have only 2GB RAM and need every last MB for the model
• You want to run custom model formats, not just GGUF
• You're embedding inference into a C/C++ project (via llama.h API)
• You're running on embedded or unusual platforms

When not to: You have 4GB+ RAM and just want to run a local service. Pick Ollama. Use the saved time to build your product.

#3: MLC-LLM (⭐⭐⭐)

Mobile-first option.

MLC-LLM's killer feature: it compiles models to Vulkan / Metal / OpenCL backends. Your phone, tablet, or integrated GPU can run models. Its optimization depth exceeds llama.cpp on mobile hardware.

For the AI translation app scenario I've discussed before, MLC-LLM is the mobile-native choice.

pip install mlc-llm
mlc_llm chat HF://Qwen/Qwen2.5-1.5B-Instruct-q4f16_1-MLC

Cons: Installation is more involved than Ollama. Documentation is fragmented. Community is an order of magnitude smaller.

#4: Everything Else (Not Recommended)

vLLM — Overkill for personal use. Designed for high-concurrency batch inference (PagedAttention). For single-user local inference it consumes more memory with zero benefit.

ExLlamaV2 — Llama-architecture only, GPU required. Only worth considering if you have 24GB+ VRAM and want to run 30B+ models.

llama.py / transformers — Running raw PyTorch models for inference. Don't. Unless you're training or fine-tuning. Using these for inference is like driving a semi-truck to buy groceries.

III. Model Selection: Best Small Models

Engine chosen. Now the model. These recommendations are limited to 3B and below — the "lightweight practical" tier. If you're running 7B+, you probably already know what you want.

General Chat / Translation

Chinese-first users: lock in Qwen2.5. The 1.5B version handles translation and structured output with ease. The 3B version delivers genuinely decent conversation quality. And its Chinese prompt understanding far exceeds anything else in its size class.

Code Completion

DeepSeek excels at code infilling. Qwen Coder wins at full-segment generation.

Embedding (Vectorization)

For local RAG, go straight to bge-base. bge-small works but the semantic discrimination gap is noticeable in real-world retrieval.

IV. Quantization: Don't Auto-Pick the Lowest

Many people assume lower quantization is always better — "Q2 is 4x smaller than Q8, always pick Q2." Wrong.

Golden rule: run the highest quantization your memory can fit.

My BLEU score tests across quantization levels on translation tasks:

• Q8_0: Baseline (near-lossless)
• Q6_K: ~1-2% loss, 25% smaller
• Q4_K_M: Sweet spot — ~3-5% loss, 50% smaller
• Q3_K: ~5-10% loss, 60% smaller
• Q2_K: ~15%+ loss, not recommended for real work

Rules:

• Plenty of RAM (8GB+): Q8_0 or Q6_K
• Moderate RAM (4-8GB): Q4_K_M (the universal sweet spot)
• Tight RAM (2-4GB): Q4_K_M on a smaller model, not Q2_K on a larger one
• Minimal RAM (<2GB): 0.5B model at Q4_K_M, or give up on local inference

Core principle: go down a model size before going down a quantization level. A 3B model at Q4_K_M consistently outperforms a 7B model at Q2_K on real tasks — because quantization loss hurts more than parameter count helps.

V. Deployment: Three Typical Scenarios

Scenario A: Local Dev Tool / Translation

ollama pull qwen2.5:3b
ollama serve
# API at localhost:11434

Plug into any OpenAI client. Runs smoothly on a 4GB laptop. Translation quality is good enough for daily use.

curl http://localhost:11434/api/chat -d '{
  "model": "qwen2.5:3b",
  "messages": [{"role": "user", "content": "Translate to Chinese: The weather is nice today"}],
  "stream": false
}'

Scenario B: RAG + Local Embedding

ollama pull nomic-embed-text
ollama pull qwen2.5:7b

Ollama provides both Embedding API and Chat API. Backend code calls localhost:11434/api/embeddings for vectorization and localhost:11434/api/chat for generation. Vector DB can be sqlite-vec or ChromaDB (zero-ops local files).

Scenario C: Mobile Embedding (AI Translation App)

For on-device inference in a mobile app:

• Android: MLC-LLM with Vulkan backend, or ExecuTorch
• iOS: MLC-LLM + Metal, or CoreML conversion
• Cross-platform (Flutter): MLC-LLM C++ SDK via FFI

Model recommendation: Qwen2.5-1.5B-Q4_K_M (~1GB), 20-40 tok/s on a phone.

But mobile inference is an order of magnitude more complex than desktop. My advice: validate your product logic with Ollama on desktop first, then optimize for mobile once you have product-market fit.

VI. The Decision Tree

How much RAM do you have?
├── < 2GB → Forget local. Use cloud APIs.
├── 2-4GB → Install Ollama, run Qwen2.5:1.5b Q4_K_M
├── 4-8GB → Install Ollama, run Qwen2.5:3b Q4_K_M
├── 8-16GB → Install Ollama, run Qwen2.5:7b Q4_K_M or Qwen2.5:3b Q8_0
└── > 16GB → Install Ollama, run Qwen2.5:14b Q4_K_M (or 7B Q8_0)

Notice the pattern? Every path ends with Ollama + Qwen2.5.

This isn't because I'm an Alibaba shill. It's because in 2026, for individual developers, the combination that satisfies "install and use, zero ops, fast enough, Chinese-friendly" is Ollama + Qwen2.5 series. No second option achieves the same balance.

If you really must be different:

• Maximize memory efficiency → llama.cpp with hand-tuned params
• Mobile deployment → MLC-LLM
• English-only → Phi-3.5 or Llama-3.2

But most people don't belong to these scenarios. Most people's scenario is: I have an idea, I need local AI to help me build it, I don't want to spend three days configuring the environment.

Install Ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5:3b
ollama serve

Three commands, ten minutes. Your local AI is running.