1. Ollama 到底在做什么？

从功能上看，Ollama可以理解为一个“本地大模型管理器”。
它做的事情很聚焦：在一台普通电脑或服务器上，下载、运行和管理各种开源大模型，并提供统一的 CLI 和 REST API 接口。(GitHub)

它的几个关键点，可以简单概括成几句话：

• 支持 macOS、Windows、Linux，多平台统一体验。(Ollama)
• 通过命令行 ollama run xxx 就能拉取并运行模型，不需要手工折腾环境。(GitHub)
• 自动暴露本地 HTTP 接口（默认为 localhost:11434），方便接入现有项目。(Ollama Documentation)
• 自带一个模型“应用商店”式的 Library，里面可以找到 Llama、Mistral、DeepSeek、Gemma、Qwen 等一长串名字。(Ollama)

某种意义上，Ollama 把“本地 LLM”这件事，做成了类似 Docker + 包管理器的体验：
模型是镜像，ollama run 就像 docker run，而 Modelfile 则像是 Dockerfile 的近亲。(Medium)

Ollama 官网：https://ollama.com/

---

2. 深夜安装：从下载到第一个回复

团队真正接触 Ollama，是在一次“别下班了先把环境搞出来”的晚上。

一个同事先打开官网，按系统下载对应的安装包：Windows 下是 .exe，macOS 是 .pkg，Linux 则可以用脚本安装。(multimodalai.substack.com)

在一台 Linux 服务器上，安装过程几乎可以缩成一行命令：

# Linux / macOS 常见安装方式之一
curl https://ollama.ai/install.sh | sh

Windows 上则更“正常”：直接双击安装器，一路“下一步”即可。(Collabnix)

安装结束后，只需要一个简单的命令，就能拉起服务并跑模型。那天晚上，团队做的第一件事就是试一试 Llama 系列模型：

# 启动服务（大多数情况下会自动启动）
ollama serve

# 拉取并运行一个模型，比如 Llama 3.2
ollama run llama3.2

终端里出现了熟悉的对话提示符，光标一闪一闪，像是在提醒：
“好了，可以和本地的大模型说话了。”

---

3. 办公桌上的那台电脑

为了让不写代码的同事也能理解发生了什么，团队专门做了一张截图：

下图里的场景，大概就是一个典型的“本地 LLM 工作台”：一台笔记本，屏幕上是满满的代码与终端窗口，桌边可能还有一杯已经凉掉的咖啡。

在这样的环境里，本地 LLM 的价值开始变得具象：
一切都在自己机器上发生。模型参数、上下文、调试日志，都不再需要穿越公网。

---

4. 从命令行到 REST API：Ollama 真正的用武之地

玩了一会命令行聊天之后，开发同事很快就把视线转向了更现实的问题：

“能不能把它接到现有的服务里，给真正的业务用？”

Ollama 默认会在本地启动一个 HTTP 服务，只要能发 HTTP 请求，就能跟模型对话。官方文档里给出的例子非常直接：(Ollama Documentation)

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Explain what a REST API is in one paragraph."
}'

这一点，对任何已有的后端服务都非常友好：
不用额外引入复杂 SDK，只要项目里本来就有 HTTP 客户端，就能完成对接。

在团队的代码库里，一个典型的封装函数大概会长成下面这样（以 Python 为例）：

import requests

def call_local_llm(prompt: str, model: str = "llama3.2") -> str:
    payload = {
        "model": model,
        "prompt": prompt,
        "stream": False
    }
    resp = requests.post("http://localhost:11434/api/generate", json=payload, timeout=120)
    resp.raise_for_status()
    data = resp.json()
    # Ollama 的 API 返回字段中通常包含完整响应文本
    return data.get("response", "").strip()

这一层封装之后，上层业务根本不需要关心后面跑的是哪一家的模型，只要传入 prompt，就能拿到结果。

Ollama API 文档：https://docs.ollama.com/api/introduction

---

5. 用 Python / JavaScript 把模型“嵌进项目”

命令行和裸 curl 只是起点。对真正要在工程里长期使用的大模型来说，更稳妥的方式是通过官方或社区 SDK。

Ollama 已经提供了官方的 Python 和 JavaScript 库，可以直接在代码里调用本地模型。(Ollama)

以 Python 为例，典型流程大致如下：

# 安装 Python SDK
pip install ollama

然后在项目的某个模块里写入类似的封装：

import ollama

def summarize_text(text: str) -> str:
    response = ollama.generate(
        model="llama3.2",
        prompt=f"请用三句话总结这段内容：\n\n{text}"
    )
    # 官方 Python 库通常会把模型回答放在 'response' 字段中
    return response.get("response", "").strip()

前端或其他服务只要调用这个函数，就相当于在后台“悄悄”访问了本地大模型。

Ollama GitHub 仓库：https://github.com/ollama/ollama

---

6. Library 里的“模型超市”：从聊天到写代码

随着环境稳定下来，团队开始在 Ollama 的 Library 里“逛超市”。(Ollama)

有适合对话的 Llama、Mistral、Hermes，有偏代码生成的 CodeLlama、Devstral，也有专门做 Embedding 的 mxbai-embed-large，还有视觉模型、推理模型、轻量小模型等等。

从命令行看，这些模型只是一行命令的差别：

# 聊天 / 通用模型
ollama run llama3.2

# 偏代码生成
ollama run qwen2.5-coder

# 生成文本向量做检索
ollama run mxbai-embed-large "需要向量化的文本"

# 跑 DeepSeek R1 这样的推理模型
ollama run deepseek-r1

在具体业务上，这种“一键换模型”的模式很实用：
当团队想给代码审查流程增加一点“智能点评”时，只要把原来调用的 model 换成偏代码的那一个；
当需要做 RAG 检索时，只要接上 Embedding 模型即可。

本地 LLM 教程示例：https://blog.langformers.com/ollama-local-llms/

---

7. 隐私、延迟与成本：本地 LLM 带来的真实变化

等到第一个完整版本上线之后，团队才真正感受到“本地 LLM”带来的差异。

• 隐私：
  日志和调试信息完全留在内部环境里，甚至可以在无外网的机器上运行。对涉及源代码、财务数据或用户隐私的场景，这一点非常关键。(Medium)
• 延迟：
  内网调用本地模型，省去了跨地域网络带来的抖动。很多交互已经能做到接近“本机应用”的流畅程度。
• 成本：
  只要硬件够用，运行成本几乎就是电费和硬件折旧。对于高并发、长上下文、频繁调用的后台任务，本地推理往往会比按 Token 计费的云端 API 更可控。(Medium)

某些团队甚至会把 Ollama 跑在一台带 GPU 的服务器上，然后通过 GitHub Actions 或 CI/CD 流水线，让它参与代码审查、自动回复 PR 评论，成为“隐形同事”。(Medium)

---

8. 什么时候值得考虑 Ollama？

对读者来说，可以简单用两个问题来判断：

1. 场景是否对隐私和数据控制很敏感？
   比如源代码、未发布产品方案、内部财务报表等。
2. 是否愿意为大模型准备一台相对靠谱的机器（至少 16GB 内存，更好是带 GPU）？(Langformers Blog)

如果答案都偏向“是”，那么让模型在本地“落地”，而不是完全依赖外部 API，就会是一个值得认真尝试的方向。

---