如果你跟我一样，日常把 AI 助手当“半个员工”用——写周报、改代码、翻译文档、批量处理文本，大概率也会撞上同一个痛点：云端模型的计费肉眼可见地涨。我原来不怎么在意，觉得每次调用就几分钱，直到一个月底拉账单，光 API 调用就花掉大几十块，那一刻就下定决心，得把这些高频任务挪到本地来。
这个“省钱计划”的核心很简单：把 OpenClaw 这类工具的推理后端，从云端模型换成 Ollama 本地部署的开源模型。用下来发现，只要电脑内存和显存不算太差，本地模型的日常表现完全够用，而且从安装、拉模型、改配置到局域网内其他设备也能调用，整条链路并不复杂，只是有几个配置细节容易踩坑。这篇文章就把我实际落地的完整过程记录下来，从软硬件准备到模型选择，再到局域网 API 的配置与排错，尽量做到你跟着操作一遍就能跑通。
文章适合三类人：一是个人开发者，想给本机 AI 工具接一个免费的推理后端；二是小团队，想把大模型能力共享到办公室局域网内的几台机器；三是单纯被云端 API 账单吓到，想找一条低成本替代路线的朋友。
1. 省钱逻辑与方案选型：本地推理比想象中划算
1.1 算清楚账单，才知道省在哪
先说一个容易忽略的事实：云端模型计费是按 token 算的，不是按“次”算的。你每一次对话、每一次代码补全，背后都是一堆上下文 token 在同时计费。我自己的使用习惯是每天大概四五十次调用，每次平均两千 token 左右。按中等档位的模型单价粗算一下，一天下来就要三四块钱，一个月就是小一百块。如果你的用途偏重代码生成、长文档处理，一次调用轻松上万 token，账单会涨得更快。
而本地部署模型的边际成本几乎为零。Ollama 把模型文件拉到本地硬盘之后，每次推理消耗的只是电费和硬件损耗。就算为了跑模型专门配一台有 16G 内存、8G 显存的主机，一次性投入也就是几百到一千块，用两三个月就回本了。更别说很多人手头本就有配置还行的电脑。
1.2 Ollama 凭什么被选中
其实能跑本地大模型的工具不止一个，我先后试过几类方案，最后留下的确实是 Ollama。
- Ollama：最大的优势是“开箱即用”。模型管理做得极简，一条命令就把模型拉下来，自动处理量化版本、依赖、服务注册这些问题，还为外部应用提供了标准接口。
- llama.cpp：性能调优空间最大，但需要自己编译、自己写启动脚本，不折腾不舒服的人可以选，日常使用者会嫌烦。
- text-generation-webui：功能非常全，浏览器界面、训练、插件都有，但对个人用户来说太重了，显存占用也比 Ollama 高不少。
- vLLM：吞吐能力很强，适合服务端高并发场景，但对硬件和 CUDA 环境要求高，个人跑纯属杀鸡用牛刀。
Ollama 之所以适合 OpenClaw 这种交互式工具，是因为它默认就暴露两个接口：一个是原生的/api/chat，另一个是兼容主流云端接口规范的/v1/chat/completions。OpenClaw 只需要改一个 base_url，就能从云端模型平滑切到本地模型，几乎不需要改业务代码。
1.3 OpenClaw 接上本地模型，玩法立刻不一样
OpenClaw 本身是一个开源 AI 工具壳，真正干活的是背后的大模型。默认情况下它走云端 API，好用是好用，但代价就是你得持续付费。把推理换到本地之后，至少带来三个直接好处。
第一是省钱，这一点不用多说。第二是隐私，代码、文档这类敏感内容不再需要上传到外部服务器，完全在本机流转，对很多场景来说这点很关键。第三是稳定性，本地服务只要机器不关机，随时可用，没有云端限流、网络抖动、接口版本升级这些幺蛾子。
当然，本地模型的上限确实比不上顶级云端模型，尤其在复杂逻辑推理和跨领域泛化上差距明显。但如果你主要用它做代码补全、文本总结、格式转换、中英互译这类任务，一个 7B 参数的量化模型已经能交出相当漂亮的答卷。想明白这个取舍，整个省钱计划就站得住脚了。
2. 环境准备与 Ollama 安装实操
2.1 硬件底线：先看显存和内存
安装之前先对自己的机器做个评估，不然拉了模型跑不动，白费功夫。以我的经验，判断标准其实不复杂，就看两个数字：显存和内存。
| 模型规模 | 建议显存 | 建议内存 | 实际体验 |
|---|---|---|---|
| 3B 量化版 | 4GB 以上 | 16GB | 非常流畅，适合日常对话和轻量任务 |
| 7B 量化版 | 8GB 以上 | 16GB | 流畅，代码和总结类任务的主力 |
| 14B 量化版 | 12GB 以上 | 32GB | 能跑但响应偏慢，适合不赶时间的任务 |
| 30B 以上 | 24GB 以上 | 32GB+ | 个人使用性价比很低，不建议尝试 |
如果你的机器没有独立显卡，但有 32GB 内存，也能靠 CPU 跑模型，只是速度会慢不少。我试过在一台纯 CPU 的办公机上跑 7B 模型，生成一段二百字的总结大约要等上一两分钟，能接受的话也不是不行。
2.2 三种系统的安装过程
Ollama 的安装本身非常省事，不同系统略有区别，我逐个说。
Windows
官方给出的方式有两种。一种是从官网下载安装包，双击一路下一步，安装完系统托盘会出现 Ollama 图标。另一种是用命令装：
winget install Ollama.Ollama装完建议打开 PowerShell 跑一下ollama --version，能输出版本号就说明装好了。Windows 版会把 Ollama 注册成系统服务，但如果你修改了环境变量，需要到系统托盘右键退出一遍再重新打开，服务才会以新配置重启。
Linux
最常用的是官方的一键安装脚本：
curl -fsSL https://ollama.com/install.sh | sh脚本会自动安装命令行工具、下载模型所需的依赖，并注册 systemd 服务。装好之后先启动服务：
systemctl start ollama systemctl enable ollama用ollama --version验证一下，如果命令行找不到命令，重启终端或者执行source /etc/profile刷新路径。
macOS
有 Homebrew 的话很简单：
brew install ollama装完直接ollama serve启动服务。macOS 也可以开个新终端窗口继续操作，服务进程会一直常驻。
2.3 模型拉取：先选对模型再动手
Ollama 装好之后，下一步就是拉模型。官方仓库里有大量模型可选，但千万别一上来就拉最大的。“我全都要”的后果往往是硬盘被塞满、显存被撑爆，然后啥都跑不动。
我建议按用途来选，目前用过比较稳的组合有两套。
日常综合场景，中文输入比较多的话，首选 Qwen 系列。我自己用下来最顺手的是qwen2.5:7b，中文理解力强，写总结、做翻译、改文案都够用。如果机器配置比较紧张，可以从qwen2.5:3b起步，响应飞快，只是长文本推理能力弱一些。
偏代码场景，目前开源模型里比较能打的是 Code 系列。我实测qwen2.5-coder:7b在 Python、JavaScript、SQL 的补全和解释上表现相当不错，比自己硬堆一个大号通用模型要划算得多。
拉取命令很简单：
ollama pull qwen2.5:7b想测试一下模型能不能正常聊天，直接跑：
ollama run qwen2.5:7b进入交互界面后随便聊一句，有正常输出就说明模型和推理链路都没问题。用ollama list可以查看本地已经有哪些模型，后面写接口配置的时候会用到精确的模型名称。
这里补充一个概念：Ollama 默认拉取的是量化版本，也就是把模型权重压缩后存储。量化等级用 Q4_K_M、Q8_0 这类标记，Q4 文件更小、速度更快，Q8 更接近原版效果。Ollama 已经帮你选好了平衡点，日常不用过多纠结。
3. 局域网 API 调用配置全记录
3.1 解开 OLLAMA_HOST 这个关键变量
Ollama 装好之后默认只监听本机回环地址，也就是127.0.0.1:11434。这个设计很安全，但意味着同一局域网里的其他设备根本访问不到。要让手机、同事的电脑、另一台服务器都能调用，必须改动一个环境变量：OLLAMA_HOST。
它的作用就是告诉 Ollama“你的服务应该绑在哪个地址上”。设成0.0.0.0:11434，意思是监听本机所有网卡地址，局域网内的其他设备就能通过你的局域网 IP 访问到 11434 端口。
Linux 上推荐用 systemd 来配置环境变量
systemctl edit ollama编辑窗口里写入：
[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"保存后重载并重启服务：
systemctl daemon-reload systemctl restart ollamaWindows 上通过图形界面设置环境变量
右键“此电脑” → 属性 → 高级系统设置 → 环境变量。在系统变量里新建一个：
变量名：OLLAMA_HOST 变量值：0.0.0.0:11434然后到系统托盘退出 Ollama，重新启动。如果你是直接用后台服务方式跑的，到服务管理器里重启 Ollama 服务也可以。
macOS 用 launchctl 设置
launchctl setenv OLLAMA_HOST "0.0.0.0:11434"然后重启一下 Ollama 进程。
3.2 从本机到局域网的连通性验证
改了环境变量之后，先别急着配 OpenClaw，把网络链路测通是更稳的做法。
在本机执行：
curl http://127.0.0.1:11434/api/tags能返回一段 JSON，里面带模型列表，说明服务本身正常。
接着查看本机的局域网 IP。Windows 用ipconfig，在输出里找“IPv4 地址”；Linux 用hostname -I，第一段数字一般就是局域网地址。假设查出来是192.168.1.100，那么就在本机再验证一次：
curl http://192.168.1.100:11434/api/tags这一步很重要，它能确认服务确实绑定到了局域网网卡上。如果这里都通不了，大概率还是OLLAMA_HOST没生效。
本机通了之后，拿另一台设备测。手机和电脑连同一个 WiFi，浏览器直接打开http://192.168.1.100:11434，能看到Ollama is running的提示就基本稳了。命令行的话也可以这样测：
curl http://192.168.1.100:11434/api/tags3.3 OpenClaw 的模型接入配置
OpenClaw 接上游模型的时候，走的是标准接口协议。Ollama 提供了跟云端大模型 API 同格式的端点，路径是/v1/chat/completions，所以 OpenClaw 那边只需要把 base_url 指到 Ollama 的地址，模型名写成你ollama list里看到的准确名称，就能连通。
我这里给你一个通用的配置示意：
model: provider: openai-compatible base_url: http://192.168.1.100:11434/v1 api_key: ollama model: qwen2.5:7b options: temperature: 0.7 num_ctx: 8192几个要点说一下。api_key这一项可以随便填一个非空字符串，比如ollama，因为本地服务不做鉴权，但 OpenClaw 的接口客户端往往会强制要求这个字段不能为空。base_url注意结尾要带/v1，很多人漏了这个后缀导致一连串 404。model必须和ollama list里的名字完全一致，比如qwen2.5:7b，中间有冒号，不能随便改。
保存配置后重启 OpenClaw，随便发一条指令测试。如果 OpenClaw 的界面里能看到流式回复或者正常回话，就说明整个链路已经打通了。
如果想直接用命令行验证接口，可以发一个完整请求：
curl http://192.168.1.100:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好，用一句话介绍你自己"}], "stream": false }'返回 JSON 里出现content字段，就说明接口没问题。
4. 踩坑实录：常见问题与排查方法
整个部署过程虽然不长，但我在实操中确实踩过不少坑。下面把比较典型的几个问题整理出来，方便你对照排查。
| 现象 | 常见原因 | 解决办法 |
|---|---|---|
| 局域网其他设备访问超时 | 防火墙拦截了 11434 端口 | 在主机防火墙中放行该端口 |
| 改了 OLLAMA_HOST 但局域网仍不通 | 环境变量修改后服务没重启 | 退出 Ollama 重新启动，或 systemctl restart |
| 调用接口返回 404 | base_url 少了 /v1 后缀 | 把地址改成http://IP:11434/v1 |
| OpenClaw 报 401 鉴权失败 | api_key 留空或缺失 | 随便填一个非空字符串 |
| 模型响应特别慢 | 模型偏大或上下文长度过长 | 换更小模型或调低 num_ctx |
| 显存不足或直接报错 | 模型太大，或同时加载了多个模型 | 选择量化版本，设置 OLLAMA_MAX_LOADED_MODELS |
| Windows 下 curl 测试异常 | PowerShell 中 curl 是别名 | 改用 curl.exe 再试 |
4.1 局域网访问失败
最常见的拦路虎其实是防火墙。Linux 上如果开了 firewalld，需要放行端口：
firewall-cmd --permanent --add-port=11434/tcp firewall-cmd --reloadWindows 系统弹窗询问是否允许 Ollama 访问网络时，如果选了“取消”，局域网访问就直接被掐断了。去“Windows 安全中心”里手动加一条入站规则，放行 TCP 11434 端口即可。
还有一个容易忽略的点：确认测试设备真的在同一网段。有些办公室网络开了访客隔离，手机连着 WiFi 是访客网络，和电脑所在网络并不互通。先测ping 192.168.1.100，通了再谈端口。
4.2 配置不生效与运行报错
如果你改完OLLAMA_HOST发现curl 127.0.0.1:11434通，但局域网 IP 不通，多数情况是配置没被重新加载。Ollama 不会热加载环境变量，Windows 托盘里退出再开，或者 Linux 里systemctl restart ollama，这是最常见的解法。
还有一类报错是 OpenClaw 返回 404。这个问题基本可以锁定在 base_url 的写法上，http://IP:11434/v1和http://IP:11434完全是两回事。先手动 curl 一下/v1/chat/completions，就能分清到底是服务没起，还是路径不对。
4.3 性能与显存问题
本地模型的性能瓶颈多半不在模型本身，而在上下文长度。Ollama 默认的num_ctx是 4096，如果你把配置里的num_ctx拉高到 32768，显存占用会成倍上涨，7B 模型甚至可能直接跑爆 8G 显存。我的建议是：日常任务 8192 足够，只有跑长文档分析才临时调高。
另外，如果同时在一台机器上加载多个模型，显存会被瓜分干净。可以通过环境变量OLLAMA_MAX_LOADED_MODELS=1限制同时最多加载一个模型，让它自动在模型之间切换，避免直接被 OOM 干掉。
5. 性能调优与下一步扩展
5.1 Ollama 运行参数调优
链路通了之后，想用得舒坦，还得调几个参数。
OLLAMA_KEEP_ALIVE控制模型在内存中的驻留时长，默认是 5 分钟。如果你每隔几分钟就会发一次请求，模型反复被卸载再加载，每次都要重新等加载，会明显感觉“首字延迟”变长。我习惯设成1h：
systemctl edit ollama写入：
[Service] Environment="OLLAMA_KEEP_ALIVE=1h"如果你的显存宽裕，也可以直接设成-1，表示模型一直驻留。
OLLAMA_NUM_PARALLEL控制同时间并行处理的请求数量，默认是 1。OpenClaw 如果经常多任务并发调用，可以尝试设为 2 或 4。但要注意，并行请求数上去了，显存占用也会同步上升。
5.2 OpenClaw 侧请求策略设置
OpenClaw 这边也有几个值得调整的点。本地模型响应速度比云端慢，所以请求超时要放宽，设置到 120 秒以上比较稳妥。平时如果不需要逐字输出效果，可以关掉流式输出。
还有一个容易被忽略的细节：采样参数。云端模型对temperature默认值设置往往偏高，本地小模型在temperature过高时容易“放飞自我”，编造事实、前后矛盾。我一般把temperature压到 0.6 到 0.7，代码类任务甚至可以到 0.2 左右，输出质量会稳定很多。
5.3 长期运行方案与安全提示
如果你打算让 Ollama 长时间运行，最简单的方案就是用 Docker 部署。官方也提供了镜像：
docker run -d --gpus=all \ -v ollama:/root/.ollama \ -p 11434:11434 \ --name ollama \ ollama/ollama容器方式的好处是环境隔离，卸载、升级、换机迁移都方便，配合 Compose 文件管理起来更有条理。
最后必须提醒一句：Ollama 默认没有鉴权机制，谁拿到你的局域网地址都能直接调用。所以务必只在可信的内网环境中开放服务，不要把 11434 端口直接映射到公网。如果确实需要远程用，优先考虑在系统层面套一层访问控制，比如只允许特定来源 IP 连接，或者配合内网网关做统一授权。
结尾
这套“OpenClaw 省钱计划”我已经实际跑了两个多月，最大的改变是再也不用半夜收到扣费短信了。现在我的配置是：代码类任务走qwen2.5-coder:7b，日常对话和文字处理走qwen2.5:7b，手机上偶尔临时查资料也能直接连家里那台机器，体验几乎和云端模型没有差别。
最后再分享一个小技巧：调试阶段不要光看 OpenClaw 的报错信息，先用 curl 直接打 Ollama 接口，能非常快地定位问题到底出在服务端还是配置端。等配置稳定下来了，建议把OLLAMA_HOST的修改记录和模型列表一起写进 README，方便以后换了机器一键恢复这套环境。
