事情起因很简单：有次半夜我在改一段涉及公司核心业务的代码，想用 AI 帮忙生成测试用例，但那段代码有商业敏感信息，传到云端的 DeepSeek、GPT 我心里没底。于是我开始折腾本地部署。
折腾了两个月，我把 Ollama + Open WebUI 这套组合彻底跑顺了。结论先放这：如果你是程序员、有一台 16G+ 内存的机器，本地跑个 7B-14B 的模型完全够用，而且不用担心数据外泄。这篇就是完整教程，把我踩的坑都写出来，让你少走弯路。
这是 2026 AI 编程工具与大模型终极指南 的 Cluster 文章。本地部署适合的是"隐私敏感 + 中等复杂度"的场景，如果你要处理超长代码库或复杂推理，还是得用云端大模型——这两者定位不同，我在文末会说清边界。
别一上来就装，先想清楚你要解决啥：
| 你的需求 | 该不该本地部署 |
|---|---|
| 隐私敏感代码（公司核心业务） | ✅ 强烈推荐 |
| 离线/断网环境开发 | ✅ 推荐 |
| 学大模型原理、做 RAG 实验 | ✅ 推荐 |
| 要最强推理能力（写复杂算法） | ❌ 用云端 |
| 要处理超长上下文（整个代码库） | ❌ 本地显存撑不住 |
（实测）我自己的实际用途是：日常写测试用例、生成注释、做简单的代码解释，这些 7B 模型完全够。复杂架构设计我还是上 DeepSeek/Claude。认清边界，本地部署才不鸡肋。
很多人一听说本地大模型就以为要买 4090，其实不一定。
| 模型大小 | 参数量 | 最低内存/显存 | 适合场景 |
|---|---|---|---|
| Qwen2.5 7B | 7B | 8G（CPU 也能跑） | 日常问答、代码补全 |
| DeepSeek-Coder 6.7B | 6.7B | 8G | 编程专用 |
| Qwen2.5 14B | 14B | 16G | 质量明显提升 |
| GLM-4 9B | 9B | 12G | 中文表现好 |
（来源：Ollama 官方模型页 requirements + 我实测）我主力机是 32G 内存 + RTX 3060（12G 显存），跑 Qwen2.5 14B 量化版很流畅，大约 20-30 token/s。没有独立显卡也能跑，只是慢，CPU 模式 7B 大概 5-8 token/s，聊胜于无。
观点：对程序员来说，先用现有机器跑 7B 跑通流程，比一上来就买卡强。等确认自己真用得起来，再考虑升级硬件。
Ollama 是目前本地跑大模型最省心的方案，把模型量化、推理引擎、API 全打包好了。
curl -fsSL https://ollama.com/install.sh | sh
装完验证：
ollama --version
（实测）我是在 Ubuntu 22.04 上装的，一行命令搞定。装完默认会起一个后台服务，监听 127.0.0.1:11434。如果你想局域网其他机器访问，需要改监听地址：
# 编辑 systemd 服务
sudo systemctl edit ollama
# 在打开的配置里加：
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
然后 sudo systemctl restart ollama。改完用 curl http://你的IP:11434/api/tags 验证能否从其他机器访问。
去 ollama.com 下安装包，图形化安装。Mac 用户注意：M 系列芯片统一内存，跑大模型有天然优势，M2 16G 跑 7B 很顺。
模型是 Ollama 的核心。直接用命令拉：
# 编程场景推荐
ollama pull qwen2.5-coder:7b
# 中文通用场景
ollama pull qwen2.5:7b
# 中文编程强模型
ollama pull deepseek-coder:6.7b
拉完后看看本地有哪些模型：
ollama list
先跑一把试试：
ollama run qwen2.5-coder:7b "用 Java 写一个线程安全的单例，要用双重检查锁"
（实测）第一次拉模型可能等几分钟（几个 G），之后跑就是秒级响应。模型默认存在 ~/.ollama/models，如果你系统盘小，可以软链到数据盘：
# 停服务
sudo systemctl stop ollama
# 移动目录
mv ~/.ollama /data/ollama
ln -s /data/ollama ~/.ollama
sudo systemctl start ollama
光命令行不够直观。Open WebUI 给你一个类似 ChatGPT 的网页界面，还自带 RAG（上传文档问问题）。
docker run -d \ --name open-webui \ -p 3000:8080 \ -v open-webui:/app/backend/data \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ --add-host=host.docker.internal:host-gateway \ ghcr.io/open-webui/open-webui:main
起完访问 http://localhost:3000，第一个注册的账号是管理员。
（实测）这里有三个坑我替你踩过：
坑 1：容器连不上 Ollama。如果你 Ollama 装在宿主机上，Open WebUI 在容器里，得用 host.docker.internal 加 --add-host 指向宿主机。少了这两行，容器里访问 localhost:11434 访问的是容器自己，连不上。
坑 2：Ollama 没改成 0.0.0.0。哪怕用了 host.docker.internal，如果 Ollama 还监听 127.0.0.1，容器一样连不上。记得按第一步那样改 OLLAMA_HOST。
坑 3：首次加载大模型超时。Open WebUI 默认请求超时短，14B 模型首次加载要 30 秒以上，容易超时报错。在 Open WebUI 的「设置 - 连接」里把超时调到 600 秒。
装这套不是为了聊天，是为了在程序里调用。Ollama 自带 OpenAI 兼容 API，这意味着你用任何 OpenAI SDK 都能接。
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "qwen2.5-coder:7b",
"messages": [{"role":"user","content":"解释一下 Spring 的 @Transactional 失效场景"}]
}'
（实测）我在一个内部工具里，把本地模型当"代码注释生成器"用，跑得很稳。核心就是当 OpenAI 客户端用，把 base-url 指向本地：
// 用 openai 官方 java SDK（兼容 ollama）
OpenAIClient client = OpenAIClient.builder()
.baseUrl("http://localhost:11434/v1")
.apiKey("ollama") // ollama 不校验 key，随便填
.build();
ChatCompletionRequest req = ChatCompletionRequest.builder()
.model("qwen2.5-coder:7b")
.messages(List.of(
new Message("system", "你是 Java 注释生成器，只输出注释不输出代码"),
new Message("user", "为这段方法生成 javadoc：\n" + methodCode)
))
.build();
ChatCompletion resp = client.chatCompletions(req);
String comment = resp.choices().get(0).message().content();
一个关键细节：本地模型并发能力弱，别像调云端 API 那样无脑并发。我踩过的坑——批量给 50 个方法生成注释，5 个并发就把 12G 显存撑爆了 OOM。本地调用要串行或低并发（2-3），并且做超时和重试。
跑起来之后，调几个参数能明显改善体验。
# 查看 GPU 是否被用上
ollama ps
# 看输出里 PROCESSOR 列，显示 100% GPU 才算正常用上显卡
如果显示 100% CPU，说明没识别到显卡。Linux 下需要装好 NVIDIA Container Toolkit（如果用容器）或确认驱动正常。N 卡用户验证：
nvidia-smi # 能输出说明驱动 OK
默认上下文只有 2048 token，问稍长代码就被截断。在 Open WebUI 的模型设置里，或 API 调用时加参数：
{
"model": "qwen2.5-coder:7b",
"messages": [...],
"options": {
"num_ctx": 8192,
"temperature": 0.3
}
}
（实测）num_ctx 调大会吃更多显存。7B 模型在 12G 显存上，num_ctx 8192 是比较稳的上限，再大可能 OOM。温度调 0.2-0.4 适合写代码，调高适合创意输出。
默认模型不跑时会被卸载，下次又要重新加载（慢）。设常驻：
# 让模型在内存里多待 30 分钟
OLLAMA_KEEP_ALIVE=30m ollama serve
或者在 API 请求里加 "keep_alive": "30m"。对频繁调用很有用。
场景一：敏感代码生成测试。公司一个计费模块，逻辑不能外传。我用本地 Qwen2.5-coder 给它生成 JUnit 测试，把方法签名和实现贴进去，覆盖正常分支和异常分支。质量不如 Claude，但胜在不出网，合规。
场景二：内网文档问答。团队有几十份内部技术文档（架构图、规范、事故复盘），用 Open WebUI 的 RAG 功能上传后，新人问"我们的限流怎么做"能直接答出来，比翻 wiki 快。
场景三：断网移动办公。高铁上没网，还能用本地模型写注释、做代码解释。虽然不能做复杂任务，但聊胜于无，关键是思路不断。
| 坑 | 现象 | 解法 |
|---|---|---|
| 容器连不上 Ollama | Open WebUI 报连接失败 | host.docker.internal + OLLAMA_HOST=0.0.0.0 |
| 模型加载超时 | 大模型首次调用卡死 | 调大 Open WebUI 请求超时到 600s |
| 显存 OOM | 并发调用就崩 | 串行或限并发 2-3 |
| 中文回答差 | 输出机翻感 | 换 Qwen/GLM，别用纯英文模型 |
| 上下文截断 | 长代码答一半 | 调大 num_ctx |
| 系统盘满 | 模型存满 C 盘 | 软链 models 到数据盘 |
观点收尾：
适合：隐私敏感的开发者、有 16G+ 内存的程序员、想学大模型落地的人、断网环境工作者。
不适合：追求极致推理质量的人（本地 14B 仍不如 GPT-5/Claude）、显存低于 8G 的老机器（跑得起来但体验差）、需要处理整个代码库的人（上下文撑不住）。
如果你只是为了省钱不用云端 API，那我不太推荐折腾——本地部署的电费、折旧算下来，未必比按量付费的云 API 便宜，而且质量和便捷度都差一截。本地部署真正的价值在隐私和可控，不在省钱。
想看更多大模型的实战用法，可以读 DeepSeek 高级用法：10 个 Prompt 技巧，那篇讲的是怎么用好云端大模型；和这篇的"本地部署"互补。编程工具本身的深度评测，见 Claude Code 深度评测。
# 安装
curl -fsSL https://ollama.com/install.sh | sh
# 拉模型
ollama pull qwen2.5-coder:7b
# 命令行对话
ollama run qwen2.5-coder:7b
# 查看运行状态
ollama ps
# Open WebUI（Docker）
docker run -d --name open-webui -p 3000:8080
-v open-webui:/app/backend/data
-e OLLAMA_BASE_URL=http://host.docker.internal:11434
--add-host=host.docker.internal:host-gateway
ghcr.io/open-webui/open-webui:main
# API 调用
curl http://localhost:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{"model":"qwen2.5-coder:7b","messages":[{"role":"user","content":"hi"}]}'