用 Ollama 搭建可切换的本地模型开发环境

开发时反复调提示词、验证解析逻辑，每次都调用云端大模型，未必划算。作者推荐用 Ollama 在本机运行开放权重模型，再通过兼容 OpenAI 的接口接入应用，把一部分开发调用搬到本地。

这套方法的价值在于缩短开发反馈、减少 API 账单，并支持离线调试。不过，「改一个 base_url」解决的是接口连接问题，模型效果能否替换，还需要单独验证。

改一个 base_url，究竟能复用多少代码

Ollama 会在 http://localhost:11434 启动本地服务，并在 /v1 提供兼容 OpenAI 的接口。已有 OpenAI SDK 调用的应用，可以沿用客户端和消息结构。

下面这段代码展示了如何把现有客户端指向本地模型：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",  # SDK 要求提供，Ollama 会忽略它
)

resp = client.chat.completions.create(
    model="llama3.2",
    messages=[{"role": "user", "content": "Summarize: the deploy failed because the DB migration timed out."}],
)
print(resp.choices[0].message.content)

注意 base_url、model 和 api_key：示例里的 "ollama" 只是满足 SDK 的参数要求，接入云端服务时仍需配置对应凭据。

因此，标题里的「一处修改」需要结合前提理解。作者建议把 base_url 和 model 放进配置，让业务调用代码保持稳定；原文没有验证 OpenAI API 的全部能力都能无差别迁移。

安装方面，原文提供 Linux 命令 curl -fsSL https://ollama.com/install.sh | sh，macOS 和 Windows 则下载应用。随后执行 ollama pull llama3.2 下载模型，用 ollama run llama3.2 开始对话。

日常管理主要靠三条命令：ollama list 查看已下载模型，ollama ps 查看当前加载到内存的模型，ollama rm llama3.2 删除模型以释放磁盘空间。

本地模型能跑起来，还要能被程序检查

作者引用 Ollama README 的内存经验值：7B 模型至少需要 8 GB RAM，13B 需要 16 GB，33B 需要 32 GB，并建议从 3B 小模型开始，质量不够再往上换。这些是选型参考，不是速度保证。模型装得下，也未必满足你的延迟要求。

真正接入程序后，另一个问题更直接：自由文本不好写断言。作者给出的办法是结构化输出，把 JSON Schema 传给 format，再用 Pydantic 校验结果。

这段代码把客服描述提取成工单对象：

from ollama import chat
from pydantic import BaseModel

class Ticket(BaseModel):
    category: str
    priority: str
    summary: str

response = chat(
    model="llama3.2",
    messages=[{"role": "user", "content": "Customer says checkout returns a 500 error since this morning."}],
    format=Ticket.model_json_schema(),
    options={"temperature": 0},
)
ticket = Ticket.model_validate_json(response.message.content)
print(ticket)

注意 format=Ticket.model_json_schema() 和最后的 model_validate_json：前者给生成结果施加结构约束，后者负责检查收到的内容。使用官方 Python 库前，需要执行 pip install ollama。

这里也有个缺口。作者提到测试可以检查「允许的分类」，但示例里的 category、priority 都只是 str，并没有枚举范围。它能校验字段类型，不能证明分类符合业务规则，更不能证明分类正确。

temperature: 0 有助于提高重复性，也不等于每次输出完全一致。

团队共享的应该是配置和评测样本

提示词和参数散落在不同调用点，容易出现同一个功能、几套设置。作者建议用 Modelfile 固定配置：通过 FROM llama3.2 指定基础模型，通过 PARAMETER temperature 0 设置采样参数，再用 SYSTEM You classify support tickets. Reply only with the requested JSON. 固定任务要求。

执行 ollama create ticket-bot -f Modelfile 创建命名模型，再运行 ollama run ticket-bot，便能按名称调用这套配置。把 Modelfile 放进版本控制，也方便团队查看修改记录；其他成员仍需在各自环境中准备并创建模型。

作者用客服工单分类串起整个流程：本地小模型负责调提示词和解析逻辑，测试检查 JSON 与业务约束，生产环境通过配置切换到托管模型。

但这只是原文的假设方案，没有提供实际项目的成本、速度或准确率数据。

本地模型通过测试，不能证明生产模型也会通过。

所以，上线前必须让生产模型运行同一套评测样本。接口能复用，评测不能省。

我的判断

我认可把 Ollama 用在开发循环和简单任务上。尤其是调试输入输出结构时，离线可用、减少按次计费，都是明确的便利。不过，「免费」只对应没有云端 API 账单，本机仍要承担硬件和运行成本。

相比始终调用生产模型，本地方案增加了行为差异；相比固定返回数据的 mock，它能观察模型如何生成内容，但测试结果也更容易波动。两者适合解决不同问题：解析与异常分支可以用固定样本覆盖，模型是否理解任务则需要实际评测。

作者也划出了边界：小模型不适合悄悄替代高质量推理任务；高流量生产服务应考虑专用推理服务器或托管 API；内存不足时应缩小模型。原文没有给出吞吐量、并发或效果对照，因此这些建议应当作为经验起点，不能当作选型结论。

能拿来做什么

• 如果已有 OpenAI SDK 调用，先把 base_url、model 和凭据集中配置，用一个简单摘要任务验证本地调用链，再决定迁移哪些开发请求。
• 做分类或信息提取时，先定义输出 Schema，并补齐分类枚举等业务约束；把格式校验和内容正确性分开检查。
• 将 Modelfile 与代码一起管理，让提示词和参数的变化可以审查，同时明确团队成员的模型准备步骤。
• 保留一套固定评测样本，每次切换本地或生产模型都重新运行，避免把接口兼容误当成效果兼容。