本地模型：用 Ollama 跑开源 LLM

为什么要跑本地模型

前面九篇全都在调云端 API，这是开发者入门的最低门槛——几毛钱就能把整个系列跑完。但只要你的项目稍微往前走一步，本地模型的价值就开始显现：

• 隐私与合规——医疗记录、法律文书、企业内部文档，明确不能发到第三方 API
• 成本——批量处理场景（给 10 万条历史数据打标签）用 API 算下来可能几千块，自己一台 Mac 跑一晚上是零边际成本
• 延迟——本地推理省去了网络往返，对话类产品的首 token 延迟能降到几百毫秒
• 可用性——API 会限流、会故障、会涨价，本地不会
• 学习——理解模型的实际参数、量化、内存占用，对做 AI 应用是不可替代的直觉

本篇用 Ollama 做本地模型的入口。它是开源 LLM 领域事实上的"Docker"——统一的命令行、统一的模型仓库、OpenAI 兼容的 HTTP 接口，学会它基本就学会了本地模型的全部常用操作。

安装 Ollama

Ollama 支持 macOS、Linux、Windows。官网 ollama.com 直接下载对应安装包。macOS 也可以 brew install ollama。

安装完成后它会作为后台服务启动，监听 http://localhost:11434。验证：

ollama --version
curl http://localhost:11434
# 返回 "Ollama is running"

第一个本地模型

Ollama 的命令行和 Docker 几乎一样：

# 拉取模型
ollama pull qwen2.5:7b

# 直接命令行对话（交互式）
ollama run qwen2.5:7b

# 列出已下载的模型
ollama list

# 删除模型
ollama rm qwen2.5:7b

第一次 ollama run 会自动先 pull。模型文件会存到 ~/.ollama/models/，一个 7B 量化模型大约 4~5 GB。

模型选型：开源 LLM 一览

2026 年初，开源 LLM 的中文场景主流选择：

通用对话（按综合能力从强到弱）

• qwen2.5:72b、qwen2.5:32b、qwen2.5:7b——阿里通义千问，中文最好，对硬件要求跨度大，各尺寸都能下探
• llama3.3:70b、llama3.2:3b、llama3.2:1b——Meta Llama，英文强中文一般，3B/1B 小模型在移动设备/边缘部署强势
• deepseek-v3、deepseek-r1——DeepSeek，推理强，完整版参数量大对硬件要求高。有官方蒸馏的小版本 deepseek-r1:7b
• gemma3:4b、gemma3:27b——Google 开源，特点是小模型质量相对高

代码

• qwen2.5-coder:7b、qwen2.5-coder:32b——目前开源最强代码模型之一
• codellama:7b——老牌选择，但已被 qwen-coder 系列超过

Embedding

• bge-m3——第 05 篇介绍过的中文 + 多语言最强开源 embedding
• nomic-embed-text——英文场景的轻量选择

入门建议：先装 qwen2.5:7b，4~5 GB 大小，16GB 内存的机器就能跑，中英文能力都不错，覆盖本系列绝大部分场景。

硬件需求快速估算

模型能不能跑起来，核心看你的"可用显存/内存"和模型的"权重大小"能否匹配。一个极其粗略的公式：

运行所需内存 ≈ 模型参数量（B）× 每参数字节数 + 上下文缓存

每参数字节数由量化级别决定。Ollama 默认拉的模型通常是 4-bit 量化（Q4_K_M），即每参数 0.5 字节。几个常见配置的实际门槛：

几个关键提醒：

• Mac Apple Silicon 非常合适——M 系列芯片的统一内存架构让大模型也能跑，M1 Max 32GB 可以舒服跑 13B，M2 Ultra 128GB 可以跑 72B
• 纯 CPU 能跑但慢——没有 GPU 的机器 7B 模型可能只有每秒 5~10 个 token，用来做日常对话就很受挫
• Windows + N 卡——CUDA 支持良好，性能好于同价位 Mac，但要自行管理驱动和显存
• 上下文越长越吃内存——32K 上下文比 4K 上下文多占很多内存，拉不动时先把 context 缩小

量化：怎么把大模型塞进小内存

"量化"是把模型权重从 16-bit 浮点降到 4-bit、8-bit 整数，用精度损失换内存占用。不同量化级别的命名惯例（Ollama / llama.cpp 社区通用）：

• Q4_K_M——4-bit 量化，质量最均衡，Ollama 默认。推荐
• Q5_K_M——5-bit，质量略好于 Q4，内存多 25%
• Q8_0——8-bit，接近无损但内存翻倍
• F16——16-bit 原始精度，主要用于微调或研究

想手动指定量化级别：

ollama pull qwen2.5:7b-instruct-q8_0
ollama pull qwen2.5:7b-instruct-fp16

对日常使用，直接 ollama pull qwen2.5:7b 拿默认 Q4 就好，不用纠结。

用 OpenAI SDK 调用 Ollama

这是 Ollama 生态设计上最聪明的一步：它内置了 OpenAI 兼容的 HTTP 接口。你在前面几篇写的所有代码，只要把 base_url 换掉就能切到本地模型：

from openai import OpenAI

client = OpenAI(
    api_key="ollama",  # 任意非空字符串，本地不校验
    base_url="http://localhost:11434/v1",
)

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=[{"role": "user", "content": "用一句话解释什么是协程"}],
)
print(resp.choices[0].message.content)

甚至流式、tools、多轮对话都兼容。这意味着你的应用可以在开发时用云端 API 调试，生产时切到本地部署，代码完全不动。

给 02 篇那个 ai.py 封装加一个环境变量开关就行：

# ai.py
import os
from openai import OpenAI
from dotenv import load_dotenv

load_dotenv()

USE_LOCAL = os.getenv("USE_LOCAL_LLM") == "1"

if USE_LOCAL:
    _client = OpenAI(api_key="ollama", base_url="http://localhost:11434/v1")
    DEFAULT_MODEL = "qwen2.5:7b"
else:
    _client = OpenAI(
        api_key=os.getenv("DEEPSEEK_API_KEY"),
        base_url="https://api.deepseek.com/v1",
    )
    DEFAULT_MODEL = "deepseek-chat"

切换本地/云端只要 export USE_LOCAL_LLM=1，业务代码零改动。

本地 Function Calling 和结构化输出

新版 Ollama 对 Function Calling 和结构化输出的支持已经比较完善，但不是所有模型都一样——模型本身需要在训练时就见过工具调用的数据。推荐在以下模型上使用：

• qwen2.5:7b 及以上——原生支持 Function Calling，质量较好
• llama3.3:70b、llama3.2:3b（instruct 版）——支持但工具选择准确性略弱
• 特定的工具优化版本如 hermes3、firefunction——针对工具调用特别训练过

纯靠 Prompt 让 7B 模型稳定输出 JSON 比云端大模型难一些，搭配 instructor 库（04 篇）的重试机制能大幅提升成功率。

生产部署：从 Ollama 升到 vLLM

Ollama 适合开发、演示、低并发场景。真正上线要处理几十上百并发请求时，Ollama 的单进程串行推理会成为瓶颈，这时候换 vLLM：

• 支持 PagedAttention，KV Cache 使用效率是普通推理的 10 倍以上
• 支持真正的批处理并发，一张 A100 能同时服务几百请求
• 兼容 Hugging Face 模型格式，也兼容 OpenAI API 协议

vLLM 部署复杂度明显高于 Ollama（需要 CUDA、Python 环境、模型下载、可能还要自己做负载均衡），不建议在原型阶段引入。但你要知道它存在，规模上去时能平滑切换。

实战场景：什么时候用本地

结合几个真实场景感受下本地模型的定位：

适合本地的

• 批处理文档打标签、提取结构化字段（不需要最新知识，速度稳定）
• 内部工具类聊天助手（数据不出内网）
• 代码补全（低延迟比 smarts 更重要）
• 边缘设备上的小能力（智能家居语音唤醒、App 内助手）

不适合本地的

• 需要前沿推理能力的任务——开源模型目前仍落后 Claude/GPT 旗舰一档
• 极低频、一次性任务——不如直接调 API 省事
• 对小团队或个人无法摊销 GPU 成本的场景

本地和云端不是二选一，很多成熟产品是混合架构：简单任务走本地省钱，难题路由到云端。

本篇要点

• Ollama 是开源 LLM 的 "Docker"，命令行、模型仓库、OpenAI 兼容 API 一站式
• 入门首选 qwen2.5:7b，4~5GB 大小、16GB 内存可用、中英都强
• 硬件门槛主要看可用内存和量化级别，Apple Silicon 的统一内存很友好
• 通过 base_url=http://localhost:11434/v1 直接复用之前所有 OpenAI SDK 代码
• 生产级部署换 vLLM，开发期 Ollama 足够
• 本地和云端是互补，根据任务特性路由

下一篇

第 11 篇进入 UI 层：用 Streamlit 把前面写好的所有能力（Chat、RAG、Function Calling、Agent）做成一个真正能用的聊天应用，支持流式输出、多轮对话、会话保存、文件上传。这是把 AI 应用推到用户面前的最后一公里，也是 Python 生态相对最省事的一段。

参考资料

• Ollama 官网
• Ollama 模型库
• Ollama GitHub
• vLLM 文档
• llama.cpp 量化说明
• Open WebUI — 本地模型的 ChatGPT 风格前端