Ollama 是什么：从模型下载到本地推理

Ollama 解决的是一个很具体的问题：怎样把开源大语言模型下载到本地，并用尽量简单的方式跑起来。

在它出现之前，本地运行模型往往要处理模型权重、量化格式、推理后端、Python 环境、GPU 驱动、启动参数和接口封装。对熟悉机器学习工程的人来说，这些步骤并不陌生；但对只想在电脑上试一个 Llama、Mistral 或 Gemma 的开发者来说，门槛还是偏高。

Ollama 把这些步骤压缩成几条命令：

ollama run llama3

第一次运行时，它会下载模型；下载完成后，会在本地启动推理服务并进入交互式对话。用户不需要先手动找权重文件，也不需要自己写推理服务。模型管理、运行时和本地 HTTP API 都由 Ollama 统一处理。

Ollama 的定位

Ollama 可以理解为本地大模型的运行时和模型管理工具。它做的不是训练模型，也不是一个完整的 AI 应用平台，而是把“下载模型、运行模型、调用模型”这条链路做成开发者能直接使用的本地工具。

它适合几类场景：

• 在个人电脑上快速试用开源模型。
• 为本地应用提供一个 LLM API。
• 搭建不依赖云端模型服务的原型。
• 在 RAG、文本摘要、代码助手等场景中测试本地模型效果。
• 学习不同模型在同一硬件上的响应速度和输出差异。

它不适合被误解成“只要安装就能替代云端大模型”。本地模型的能力受模型规模、量化精度、显存、内存和推理速度影响很大。7B 或 8B 级别模型可以在消费级电脑上跑起来，但推理质量、长文本能力和复杂推理能力仍然要看具体模型。

从下载模型到开始对话

Ollama 的使用路径很短。安装完成后，运行一个模型通常只需要：

ollama run llama3

如果本地没有 llama3，Ollama 会先下载。下载完成后，命令行会进入对话模式：

>>> 解释一下 RAG 是什么

如果只想提前下载模型，可以使用：

ollama pull llama3

查看本地已有模型：

ollama list

删除不再使用的模型：

ollama rm llama3

这套命令把模型当成本地资源来管理。开发者可以像管理 Docker 镜像一样管理本地模型：先拉取，再运行，不需要每次都重新下载。

图 1：Ollama 的基础工作流

flowchart TD
  A["选择模型"] --> B["ollama pull 下载"]
  B --> C["本地模型存储"]
  C --> D["ollama run 启动推理"]
  D --> E["命令行对话"]
  D --> F["HTTP API 调用"]

模型名称和标签

Ollama 的模型通常使用 name:tag 这样的形式。

例如：

ollama run llama3:8b
ollama run llama3:70b

name 表示模型家族，tag 表示具体版本、规模或量化变体。省略 tag 时，Ollama 会使用默认标签。

Llama 3 在 2024 年 4 月进入 Ollama，初始提供 8B 和 70B 两个规模。8B 更适合个人电脑尝试，70B 对硬件要求明显更高。对多数开发者来说，先用 8B 模型测试工作流，再决定是否切换到更大的模型，是更现实的路径。

当时常见的本地模型选择包括：

模型	适合场景	说明
Llama 3 8B	通用问答、摘要、轻量应用原型	规模适中，适合先跑通流程
Llama 3 70B	更高质量的通用生成	对内存和显存要求更高
Mistral 7B	通用文本任务	轻量、响应快，适合开发测试
Gemma	轻量文本生成	Google 发布的开放模型家族
Phi-3	小模型实验、轻量推理	参数规模小，更关注本地可运行性
LLaVA	图文理解实验	用于基础视觉问答场景

选择模型时不要只看参数量。更大的模型通常更强，但也更慢、更占内存。对一个本地知识库问答原型来说，响应速度、中文效果、上下文长度、RAG 配合效果，往往比参数量本身更重要。

本地推理背后的几件事

Ollama 把底层细节藏起来了，但理解这些细节有助于判断它为什么好用，也有助于排查问题。

模型权重

模型权重是模型能力的来源。开源模型发布后，通常会有不同规模和不同格式。直接使用原始权重往往不够方便，尤其是在普通电脑上。

Ollama 会把模型打包成可直接拉取和运行的形式。用户通过模型名下载，不需要手动处理权重目录。

量化

很多本地模型会使用量化版本。量化可以降低模型体积和内存占用，让较大的模型在普通硬件上运行。

代价是精度可能下降。对于摘要、简单问答、结构化改写等任务，量化模型常常够用；对于复杂推理、长文本分析、代码生成等任务，就需要实际测试。

推理服务

当模型运行起来后，Ollama 会在本地提供服务。命令行对话只是其中一种使用方式。更常见的工程用法是让应用通过 HTTP API 调用本地模型。

默认服务地址通常是：

http://localhost:11434

这意味着本地程序可以像调用远程模型 API 一样调用 Ollama，只是请求不会离开本机。

用 API 调用 Ollama

Ollama 的一个重要价值是把本地模型变成可编程接口。

最直接的是 /api/generate。它适合单轮文本生成：

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "用三句话解释什么是向量数据库",
  "stream": false
}'

如果应用需要多轮对话，可以使用 /api/chat，把历史消息作为数组传入：

curl http://localhost:11434/api/chat -d '{
  "model": "llama3",
  "messages": [
    {
      "role": "user",
      "content": "Ollama 适合做什么？"
    }
  ],
  "stream": false
}'

这类接口让 Ollama 很容易接入已有应用。例如一个笔记软件可以把选中的文本发给本地模型做摘要；一个内部工具可以把日志片段发给模型做初步解释；一个 RAG 原型可以把检索结果拼成上下文，再交给本地模型生成答案。

图 2：应用通过本地 API 使用 Ollama

sequenceDiagram
  participant App as 本地应用
  participant Ollama as Ollama 服务
  participant Model as 本地模型
  App->>Ollama: POST /api/chat
  Ollama->>Model: 加载模型并生成
  Model-->>Ollama: 返回 tokens
  Ollama-->>App: 返回响应文本

Ollama 也提供 OpenAI Chat Completions API 的兼容能力。对已经围绕 OpenAI SDK 写过代码的项目来说，这降低了本地模型替换实验的成本。不过兼容不等于完全等价。不同模型的提示模板、上下文长度、输出稳定性和函数能力并不相同，迁移时仍然要单独测试。

Modelfile：把模型配置写下来

如果只是临时对话，ollama run 已经够用。若要做一个稳定的应用，就需要把系统提示词、参数和基础模型固定下来。Ollama 用 Modelfile 描述这件事。

一个简单的 Modelfile 可以这样写：

FROM llama3

SYSTEM """
你是一个技术文档助手。回答要准确、简洁，不确定时说明缺少依据。
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 4096

然后创建一个新模型：

ollama create tech-doc-assistant -f Modelfile
ollama run tech-doc-assistant

FROM 指定基础模型。SYSTEM 指定系统消息。PARAMETER 调整生成参数。

这让模型配置从“命令行里临时试出来的参数”变成了可以保存、复制和交付的文件。团队成员拿到同一个 Modelfile，可以创建同名模型，减少环境差异。

常见参数包括：

参数	作用	使用建议
temperature	控制输出随机性	问答和文档任务可以低一些
top_p	控制采样范围	常和 temperature 配合
num_ctx	设置上下文窗口大小	RAG 和长文本任务需要关注
num_predict	限制生成长度	避免模型输出过长
stop	设置停止词	适合固定格式输出

参数不是越大越好。num_ctx 增大后会增加内存占用和推理成本；temperature 太高会让回答更发散；num_predict 太小可能截断答案。工程上更常见的做法是为不同任务准备不同模型配置。

Embedding 和 RAG 原型

2024 年 4 月，Ollama 开始支持 embedding 模型。这让它不仅能运行生成模型，也能参与 RAG 链路中的向量化步骤。

例如可以先拉取 embedding 模型：

ollama pull mxbai-embed-large

再生成文本向量：

curl http://localhost:11434/api/embed -d '{
  "model": "mxbai-embed-large",
  "input": "Ollama 可以在本地运行大语言模型"
}'

一个最小 RAG 原型可以这样组成：

1. 用 embedding 模型把文档片段转成向量。
2. 把向量存入本地向量库或简单索引。
3. 用户提问时检索相关片段。
4. 把片段和问题一起发给 llama3 这类生成模型。
5. 让模型根据检索结果回答。

这套方案的优点是数据可以留在本地，适合学习、原型验证和小规模私有资料问答。它的限制也很清楚：本地硬件会限制模型规模和响应速度，embedding 模型、切分策略、检索质量都会影响最终答案。

图 3：Ollama 参与本地 RAG 原型

flowchart TD
  A["本地文档"] --> B["切分 Chunk"]
  B --> C["Ollama Embedding 模型"]
  C --> D["向量索引"]
  Q["用户问题"] --> E["检索相关 Chunk"]
  D --> E
  E --> F["拼接上下文"]
  F --> G["Ollama 生成模型"]
  G --> H["返回答案"]

本地运行的优势

Ollama 受欢迎，不只是因为命令简单。它背后对应了几个真实需求。

数据不离开本机

对私密笔记、内部文档、客户资料、代码片段来说，把内容发到云端模型并不总是合适。本地模型可以降低数据外传风险。

这并不等于“天然安全”。如果把 Ollama 服务暴露到局域网或公网，仍然需要访问控制、网络隔离和日志管理。默认本地使用和生产级安全部署是两回事。

成本可控

本地推理不按 token 计费。只要硬件已经具备，反复实验的边际成本很低。开发者可以用它测试提示词、RAG 流程和应用交互，而不用担心每次请求都产生 API 费用。

代价是硬件成本和等待时间。大模型在普通电脑上推理可能很慢，长上下文和大批量请求更明显。

开发体验稳定

Ollama 把模型服务固定在本地端口。应用开发时，不需要每次都处理远程鉴权、网络波动和额度限制。对离线演示、教学环境、内部原型来说，这种稳定性很有价值。

需要注意的限制

本地模型不是云端模型的简单平替。

第一，模型能力有限。小模型适合摘要、改写、分类、简单问答，但复杂推理、长文档综合、严格代码生成不一定稳定。

第二，硬件决定体验。内存不足时模型无法加载；显存不足时速度可能明显下降；笔记本长时间推理还会带来发热和功耗问题。

第三，模型之间差异很大。相同提示词在 Llama 3、Mistral、Gemma、Phi-3 上可能表现不同。应用如果依赖固定输出格式，必须做模型级测试。

第四，OpenAI 兼容接口不能消除模型差异。接口格式可以相似，但模型能力、上下文长度、系统提示词遵循程度和输出风格不会自动一致。

第五，生产服务还需要额外工程。并发控制、鉴权、监控、限流、日志脱敏、模型预热、失败重试，都不应该被忽略。

一个适合入门的实践路径

如果只是第一次接触 Ollama，可以按下面的顺序走：

1. 安装 Ollama。
2. 运行 ollama run llama3，确认模型能下载和对话。
3. 用 ollama list 查看本地模型。
4. 用 /api/generate 写一个最小 curl 调用。
5. 用 /api/chat 测试多轮对话。
6. 写一个 Modelfile，固定系统提示词和参数。
7. 尝试 embedding 模型，跑一个很小的 RAG 原型。
8. 对比不同模型在同一任务上的速度和答案质量。

这条路径能覆盖 Ollama 的核心能力：命令行、模型管理、本地 API、自定义模型配置和 RAG 基础组件。

小结

Ollama 的价值不在于让每个人都变成模型工程师，而在于把本地运行开源模型这件事变成普通开发者可以直接操作的工作流。

它把模型下载、模型运行、本地 API、参数配置和自定义模型封装在一起。对个人开发者，它是试用开源模型的低门槛入口；对应用开发者，它是一个方便的本地 LLM 后端；对 RAG 原型，它可以同时承担 embedding 和生成模型的角色。

真正使用时，需要把它放回工程约束里看：模型是否适合任务，硬件是否跑得动，接口是否满足应用，数据是否需要留在本地，输出质量是否经过评测。把这些问题想清楚，Ollama 就不只是一个“本地聊天命令”，而是本地大模型应用开发的一块基础设施。