Ollama 实战指南：笔记本上跑大模型的正确姿势

Ollama 是什么

一句话：模型管理 + 推理运行时 + 本地 API 三合一。底层是 llama.cpp——一个用 C/C++ 写的 LLM 推理引擎，主打 CPU 与消费级显卡上的高效推理；Ollama 在上面包了一层类似 Docker 的使用体验：ollama run 加模型名，一条命令自动拉权重、加载模型、进入对话。

对开发者的价值：不用折腾 Python 环境、CUDA 版本、依赖冲突，把「本地跑个模型」变成和装个数据库一样简单的事。模型来源是官方模型库，聚合了 llama、qwen、deepseek、gemma 等主流开源系列的打包版本，ollama pull 一条命令就能拉到本地。

安装与首跑

官网下载对应平台的安装包（macOS、Windows、Linux 都有），装完在命令行开跑：

ollama run llama3.2     # 首次运行自动拉取权重，然后进入对话
ollama pull llama3.2    # 只下载不进入对话
ollama list             # 查看本地已有模型
ollama ps               # 查看正在运行的模型
ollama rm llama3.2      # 删除模型

对话界面里输入 /bye 退出。后台服务默认监听 11434 端口，程序化调用都走它。

两个日常细节：模型加载进内存后默认保留一段时间再卸载（可用 keep_alive 参数调整），反复调用不会每次重新加载权重；拉取的体积以 GB 计，视网速几分钟量级完成，同一模型的不同规格用不同 tag 区分（比如 llama3.2 有 1B、3B 两个变体）。权重落盘在用户目录的 .ollama/models 下，几个模型叠加后磁盘占用增长很快，ollama list 能看到各自体积。第一次跑建议先选小规格试试水，确认链路通了再换大模型。

模型选择与硬件匹配

估算方法一句话：内存需求 ≈ 参数量 × 量化位宽 ÷ 8（换算成字节），再留出上下文缓存与运行时开销。下表是常见量级（均为估算，实际随量化方案与上下文长度浮动）：

模型量级	Q4 量化内存占用（估算）	大致适合的机器
7B 级	约 4–6GB	8GB 内存以上的笔记本
13B 级	约 8–10GB	16GB 内存或 12GB 显存显卡
70B 级	40GB 以上	多卡工作站或大内存 Mac

经验法则：在装得下的前提下选最大的模型，宁要大模型的标准量化，不要小模型的极致压缩。两个会推高内存的变量也要留心：上下文窗口调大，KV Cache 的占用跟着涨；显存不够时，llama.cpp 支持把部分层留在 CPU 上运算（分层卸载），用速度换可行性。

量化与 GGUF

**量化（quantization）**是把权重从训练时的 FP16（16 位浮点数）压到 4/5/8 bit 整数表示。收益：体积更小、内存占用更低，在消费级硬件上往往更快——因为推理瓶颈常在内存带宽，数据小了搬得就快。代价：质量略降。Q4 级通常可接受，压到 Q2 级小模型会明显变笨。选档位的经验：多数用途从 Q4 起步，对质量敏感再升 Q5、Q8；同一模型不同档位的差距，往往小于「小模型高量化」与「大模型标准量化」之间的差距。

GGUF 是 llama.cpp 社区的模型文件格式：单文件打包权重与元数据、支持 CPU 与 GPU 混合卸载，是 Ollama 拉取模型的标准形态。模型库里各种 tag（如 7b、7b-q4）就对应不同的量化档位。

Modelfile 自定义

类似 Dockerfile 的机制，把系统提示与采样参数固化成一个可分发的新模型：

FROM llama3.2
SYSTEM 你是团队内部的技术文档助手，用中文回答，保持简洁与准确。
PARAMETER temperature 0.7

ollama create doc-helper -f Modelfile
ollama run doc-helper

适合的场景：团队共享同一套系统提示与参数，省去每人各配一遍的麻烦。PARAMETER 支持的常用项还有 num_ctx（上下文窗口长度）等，按需添加。

API 调用

服务起来之后，程序化调用走本地 API：

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.2",
  "messages": [
    { "role": "user", "content": "用一句话解释什么是容器" }
  ],
  "stream": false
}'

同时提供 OpenAI 兼容端点（/v1/chat/completions）：现有代码里用 openai SDK 的，把 base_url 改到本地就能复用，切换成本几乎为零。除 chat 接口外，还有单轮的 /api/generate 与模型管理的配套端点，覆盖脚本化场景。

适用边界

Ollama 的甜区：个人开发调试、内网工具、隐私敏感不想出本机的数据。CPU 也能跑，只是速度慢一个量级，适合不赶时间的批处理任务。它不适合高并发生产服务——那是 vLLM 的主场（参见本站《vLLM 与 PagedAttention》）。最后提醒一句：本地跑模型不等于免责，敏感数据仍要按公司的数据规范处理，日志与缓存里同样不要留敏感信息。

小结

Ollama 把「本地跑大模型」简化成一条命令：底层 llama.cpp，上层 Docker 式体验加本地 API
硬件匹配用「参数量 × 量化位宽」估算，7B 级 Q4 大致 4–6GB 内存可跑（估算量级）
量化用少量质量换体积与速度，Q4 是常用甜点；GGUF 是标准模型格式
Modelfile 固化系统提示便于团队分发，API 与 OpenAI 兼容方便接入
个人与内网场景首选，高并发生产交给 vLLM