在自己电脑上跑大模型：Ollama 部署与调优上手
你有没有算过一个月在云端大模型接口上花了多少钱？随手问几句不心疼，可一旦把它接进自己的工具链——每天自动总结几十篇文章、批量翻译、给博客写摘要——账单就按 token 往上涨，而且没上限。更别说有些内容你压根不想发出去：内部文档、合同草稿、客户名单。
Ollama 解决的是三件事：模型跑在你自己的机器上，断网能用，不按 token 计费。它把下载权重、管理显存、暴露 HTTP 接口打包成一个命令行工具加一条常驻服务，你不用懂 CUDA，也不用装 Python 环境、手写推理脚本。
本地跑图什么
不是追求最强效果——本机能跑的模型和云端旗舰差距明显。图的是另外几件事：
- 数据不出门：推理全在本机完成，请求不经过外部服务。
- 断网可用：权重在硬盘上，没网照样跑。
- 成本固定：投入是硬盘和内存，跑一万次和一次的成本一样。
- 随便折腾：改提示词、换量化、挂几个模型对比，不用担心额度。
能干的事大致这几类，选型时对号入座：
| 用途 | 模型规模 | 实际体验 |
|---|---|---|
| 日常对话、润色 | 7B 到 14B | 中文流畅，响应快 |
| 代码补全、解释脚本 | 7B 偏代码的模型 | 常用语法可靠，复杂重构会跑偏 |
| 文档问答 | 7B 到 32B | 要长上下文，显存得留足 |
| 批量翻译 | 7B 以上 | 术语一致性弱一点，但可控 |
| 结构化抽取 | 14B 以上更稳 | 小模型容易破坏 JSON |
三行命令跑起来
官方提供一键安装脚本，从官网下载执行即可；Windows 和 macOS 是双击安装包，装完后台服务就起来了。Linux 上用脚本装完会自动注册成系统服务并加进开机启动。装完先确认服务活着：
ollama --version
ollama list列表一开始是空的。然后拉一个模型直接对话：
ollama run qwen2.5就这一条，它会自动下载默认尺寸的权重，下完直接进交互界面，输入 /bye 退出。体积按量化等级不同，7B 大概四五 GB，14B 八九 GB，32B 二十 GB 上下。第一次拉模型考验的是网速和硬盘，不是 CPU。
习惯容器化的话用 Docker，注意必须挂模型目录，否则重建一次容器就要重下几十 GB：
docker run -d \
--name ollama \
--restart unless-stopped \
-p 11434:11434 \
-v /opt/ollama:/root/.ollama \
-e OLLAMA_HOST=0.0.0.0:11434 \
ollama/ollama有 NVIDIA 显卡的机器要加 --gpus all 把 GPU 暴露进容器，否则会退化成纯 CPU 推理，慢一个数量级。compose 写法：
services:
ollama:
image: ollama/ollama
container_name: ollama
restart: unless-stopped
ports:
- "11434:11434"
environment:
- OLLAMA_HOST=0.0.0.0:11434
- OLLAMA_KEEP_ALIVE=30m
volumes:
- ./ollama:/root/.ollama
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]docker compose up -d
docker exec -it ollama ollama pull qwen2.5常用命令
| 命令 | 作用 | 备注 |
|---|---|---|
| list | 列出本地模型 | 带体积，方便清硬盘 |
| pull | 下载模型 | 断了重跑会续传 |
| run | 加载并对话 | 没下载会先自动下载 |
| ps | 看已加载的模型 | 能看到占多少显存 |
| rm | 删模型 | 真删文件，立刻释放空间 |
| show | 看模型详情 | 含量化方式、默认提示词 |
ps 值得多用。模型加载后会驻留一段时间，默认五分钟，可用 OLLAMA_KEEP_ALIVE 调整：频繁调用设长一点省掉反复加载的几秒，偶尔用就设短点把显存还给别的程序。
你的机器能跑多大
关键不是 CPU 多强，而是显存或统一内存够不够把整个模型装进去。按常见四位量化估算：
| 参数规模 | 大致需要 | 适合的机器 |
|---|---|---|
| 7B | 约 8 GB | 8G 显存显卡，或 16G 内存台式机 |
| 14B | 约 16 GB | 12G 到 16G 显存，或 32G 内存 |
| 32B | 约 32 GB | 24G 显存勉强，统一内存机型更合适 |
| 70B | 64 GB 以上 | 多卡工作站，个人不建议 |
这些数字是「装得下」的底线，不是「跑得爽」的标准。上下文越长，键值缓存占得越多，实际占用会超出表格估算，显存刚好等于模型大小时往往一开长对话就爆。
GPU 支持方面：NVIDIA 最完整，装好驱动就能用；AMD 在 Linux 下有支持但配置麻烦；Apple 芯片用统一内存，跑 14B 到 32B 很舒服。纯 CPU 要有心理准备，7B 模型在主流桌面 CPU 上大概每秒三到八个 token，写千字文章要等几分钟。所以很多人的用法是：小模型本地当日常助手，难题再上云端。这不丢人，是合理分工。
接口怎么接
服务默认在 11434 端口提供 HTTP 接口，最常用的是单轮补全和多轮对话两个端点：
curl http://127.0.0.1:11434/api/generate -d '{
"model": "qwen2.5",
"prompt": "用一句话解释什么是反向代理",
"stream": false
}'多轮对话要把历史带上，结构是标准的 role / content：
curl http://127.0.0.1:11434/api/chat -d '{
"model": "qwen2.5",
"messages": [
{ "role": "system", "content": "你是一个简洁的运维助手" },
{ "role": "user", "content": "Nginx 的 proxy_pass 后面加不加斜杠有什么区别？" }
],
"stream": false
}'默认流式返回，一行一个 JSON 片段；脚本调用建议关掉流式，解析更省心。
更实用的是它也提供兼容 OpenAI 的接口，路径是 /v1。那些只支持 OpenAI 格式的第三方工具，把 base URL 改成 http://你的地址:11434/v1、Key 随便填个非空字符串，就能直连本地模型。很多客户端和编辑器插件都支持，改一行地址就切过来，这是它生态能滚起来的关键设计。
用 Modelfile 固化一个助手
每次都手打系统提示词太累，也容易前后不一致。Modelfile 就是给模型做一份配置档，固定提示词、温度、上下文长度：
FROM qwen2.5
PARAMETER temperature 0.3
PARAMETER num_ctx 8192
SYSTEM """
你是一名中文技术博客的编辑。回答要直接、具体，
先给结论再解释原因。不确定的内容要明确说不知道，
不要编造命令参数或配置项。
"""ollama create blog-editor -f ./Modelfile
ollama run blog-editor之后用 blog-editor 这个名字调用就自动带上提示词。改需求时改文件再 create 一次，同名覆盖，基础模型不会重复下载。团队共用一台推理机时特别有用——每人建一个名字，提示词互不干扰。
让它开机自启
用脚本安装在 Linux 上通常已经注册了服务，systemctl status ollama 确认即可。想自己控制路径和参数，手写一个更清晰，存成 /etc/systemd/system/ollama.service：
[Unit]
Description=Ollama Service
After=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/ollama serve
Restart=always
RestartSec=3
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/data/ollama/models"
Environment="OLLAMA_KEEP_ALIVE=30m"
User=ollama
[Install]
WantedBy=multi-user.targetsystemctl daemon-reload
systemctl enable --now ollama
systemctl status ollama --no-pagerOLLAMA_MODELS 指向的目录要提前建好并给对权限，否则服务会因写不进模型文件而起不来，日志里一堆权限拒绝，容易误判成显存不足。
图形界面
命令行只适合临时试模型，每天用还是要有界面。接口已经暴露好了，任何支持自定义 API 地址的第三方 Web 聊天界面都能接上来：在设置里填服务地址和端口，模型列表自动读出来，剩下就是点选和对话。挑的时候看两点——能不能改 base URL、能不能设系统提示词。
踩坑清单
下载慢得像没进度
权重文件大，首次拉取吃网络。断线重连是安全的，重复执行拉取会从断点继续；走代理的环境记得给命令行进程设好代理变量。卡住时先中断再重跑，比干等有效。
显存不够，偷偷卸载到内存
最坑的一个。装不下时它不报错，而是把一部分层放到系统内存里靠 CPU 算。于是你看 ps 里模型确实加载成功，速度却掉到每秒一两个 token，主观上像卡死。判断方式：看占用是否明显超过显卡显存，或者换个更小的量化版本对比。遇到这种情况，换量化比硬扛明智。
上下文设太大直接爆
把上下文设到三万多是看着美，但键值缓存按比例膨胀，显存瞬间见底。文档问答确实需要长上下文，那就得同时把模型规模降下来——7B 配长上下文往往比 32B 配短上下文更实用。
只监听本机，局域网访问不了
默认只绑 127.0.0.1，你在另一台机器上访问 IP 加端口会直接连不上。改成监听所有网卡就设 OLLAMA_HOST=0.0.0.0:11434 再重启服务。别忘了防火墙，端口通了但没放行症状完全一样。一旦对外监听，同网段的人都能白嫖你的算力，内网也建议加一道认证或限制来源。
容器里的模型每次都没了
九成是忘了挂载模型目录。容器层是临时的，几十 GB 的权重必须落在宿主机卷里。用 compose 时注意相对路径是相对 compose 文件所在目录，不是当前工作目录。
适合谁
适合你，如果：有能跑动 7B 以上模型的机器、对数据外发有顾虑、想做批量任务又不想按次付费。它最舒服的定位是「第二个助手」，日常重复任务交给它，复杂判断交给云端。
不适合：需要最强推理和长文档处理能力、需要高并发服务多人、或者完全没时间折腾。别为了「技术自主」硬上，工具是拿来用的，不是拿来供的。
