1. 省钱计划的由来：云端接口账单与本地化思路
不知道你们有没有这种经历：本地跑着一个挺顺手的AI助手项目（我这里就说OpenClaw吧，一款开源的个人AI助理工具），日常让它帮忙整理邮件、列一下周报提纲、回几句不痛不痒的客套话，用起来确实方便。但到了月底一看云端API账单，整个人就清醒了——哪怕只是中轻度使用，一个月也得几十上百块。我当时就在想，这钱花得冤不冤？于是就有了这套“OpenClaw省钱计划”：把模型后端从商业云端API切到Ollama本地部署，走局域网API调用。
这个思路其实特别直白：OpenClaw本身只是一个壳，负责对接你的提示词、工具调用、上下文管理，真正干脑力活的是背后的大模型。你给它配什么样的后端，它就有什么样的“智商”和“身价”。商业云端API按token收费，贵在方便和聪明；Ollama本地部署完全免费，代价是你得有一台像样的电脑。那问题就变成了：本地模型到底够不够日常用？答案是，大部分场景够，而且省下来的钱真能看得见。
先说清楚一件事：这不是什么高深技术，门槛比想象中低得多。你不需要从头训练模型，不需要写复杂代码，只需要装一个Ollama运行时，拉一个开源模型权重，改一下OpenClaw的配置文件，把它指向局域网内的Ollama服务就行。整个过程我实测下来，从零到跑通大概一个下午，中间踩的坑我会在后文全部列出来。
此文谁适合看？已经被云端API价格劝退的AI工具党、想在自己电脑上跑通本地模型但不清楚怎么跟现有项目对接的朋友，还有单纯想搞明白“局域网API调用”到底是怎么一回事的同学。下面按我的实操顺序来写，尽量把每一步为什么这么做也说清楚。
2. 先掂量家底：硬件配置与模型选型之间的取舍
在动手装Ollama之前，最好先想明白一个问题：你的机器扛得住多大的模型？这一步做错了，后面全是白折腾。
2.1 内存和显存才是决定性因素
本地跑大模型不吃CPU主频，吃的是内存带宽和显存容量，尤其是显存。模型推理的时候，所有权重都要加载进显存里，显存不够就只能退到内存，速度直接掉一个数量级。我用的是一块中等偏上的消费级显卡，显存16G，跑7B~14B参数量的量化模型非常舒服，跑更大的模型就明显吃力。
给你一个粗略的选型参考表（基于我的实测和社区反馈综合）：
| 模型参数量 | 量化精度 | 显存需求 | 内存需求 | 日常体验 |
|---|---|---|---|---|
| 1.5B | Q4 | 2G左右 | 4G | 飞快，但不聪明 |
| 7B~8B | Q4 | 6G~8G | 8G+ | 速度流畅，日常够用 |
| 13B~14B | Q4 | 10G~12G | 16G+ | 稍慢，但效果明显更好 |
| 30B+ | Q4 | 20G+ | 32G+ | 卡顿，不推荐家用 |
注意这里说的是“显存不够时用内存兜底”的情况，如果你显卡显存很小，比如只有4G，强行拉7B模型大概率会很痛苦。建议新手从这个区间选：显存6G以上就试7B~8B，显存12G以上就试13B~14B。没有独立显卡的朋友也不必灰心，纯CPU推理小模型也能跑，只是速度就一言难尽了。
2.2 我的选型理由：牺牲一点聪明，换取免费和隐私
我自己选的模型是8B量级的量化版。有两个原因：第一，OpenClaw日常要处理的任务以文本理解、改写、摘要、简单推理为主，8B模型在这些任务上的表现已经能看；第二，这个体量加载快、推理速度可接受，不像大模型那样动不动就让人等上半分钟。
这里也顺便说一句选型心态。别指望本地8B模型能在所有任务上和最强商用API平起平坐，它做不到。但“省钱计划”的目标本来就不是全面平替，而是覆盖80%的日常轻量需求。真正遇到复杂推理、长文写作，再切回云端API也不迟。OpenClaw这类工具的好处是支持多后端灵活切换，你完全可以让简单任务走本地、困难任务走云端，双轨并行。
还有一个隐藏好处：本地部署意味着数据不出内网。敏感邮件、内部文档、个人笔记，丢给本地模型处理比丢给云端API放心得多。这也是我后来坚持把一部分任务留在本地的原因。
3. Ollama安装与基础配置：从零到第一次对话
模型选型想清楚之后，就可以正式装Ollama了。这部分不难，但有几个细节会影响后面的调用体验。
3.1 安装步骤与版本验证
Ollama的安装方式很友好，官方提供了Windows、macOS、Linux三种平台的安装包。Windows用户直接下载安装包双击下一步即可；Linux用户更简单，一条脚本命令就行。
curl -fsSL https://ollama.com/install.sh | sh装完之后验证一下，终端执行：
ollama --version正常会输出类似“ollama version 0.x.x”的版本号。如果这一步报错，大概率是安装过程中权限或者网络问题，重新装一遍基本能解决。Windows用户记得新开一个终端再执行，否则环境变量可能没刷出来。
3.2 拉取模型与首次对话
验证完安装，接下来拉模型。命令格式是ollama pull加模型名称。以我选的8B模型为例，对应的是qwen2.5:7b这个标签（HuggingFace和Ollama上都有对应的开源权重，Ollama社区已经帮你打包好了）。在终端执行：
ollama pull qwen2.5:7b第一次拉取要看网速，几个GB的量，我这边大概等了十几分钟。拉完之后直接对话测试：
ollama run qwen2.5:7b终端会出现一个互动式对话界面，输入一句“你好，简单介绍一下你自己”，如果模型能正常回复，说明本地推理链路已经通了，Ollama自身的部署到此结束。
这里插一个很多人会忽略的点：模型文件默认存放在用户目录下，比如Windows是C:\Users\用户名\.ollama\models，Linux是/root/.ollama/models。如果你的系统盘空间吃紧，建议提前把模型存储目录改到其他分区。修改方式是设置OLLAMA_MODELS环境变量，指向你的大容量磁盘路径。
3.3 Ollama自带的API服务
装Ollama的人可能没注意到，它其实自带了一个API服务，默认监听127.0.0.1:11434。也就是说，Ollama装好那一刻，你的机器上就已经有一个本地API服务在运行了，只是只能自己访问。检验一下：
curl http://127.0.0.1:11434/api/tags这行命令会返回本机已下载的模型列表。看到类似{"models":[...]}的输出，就说明API服务是活的。这一点对后面OpenClaw对接很关键——我们不需要额外装任何网关程序，OpenClaw直接调用这个接口就行。
4. 局域网API暴露：让OpenClaw从本机调用走向全内网调用
Ollama默认只监听本机回环地址，这一步是出于安全考虑，但我们要让OpenClaw能访问它——不管OpenClaw跑在同一个台机器上还是局域网里另一台机器上，都得先把监听地址放宽。
4.1 修改OLLAMA_HOST环境变量
核心操作就是设置OLLAMA_HOST环境变量，把监听地址从127.0.0.1改成0.0.0.0。这样Ollama服务就会绑定到所有网络接口，局域网内的其他设备就能通过你的机器IP访问了。
Windows下，在环境变量设置里新建一个用户变量：
变量名：OLLAMA_HOST 变量值：0.0.0.0:11434Linux/macOS下，临时生效可以直接在shell里导出：
export OLLAMA_HOST=0.0.0.0:11434但这样只在当前终端有效。更稳妥的做法是写进系统服务配置。用systemd管理的Linux系统，编辑service文件：
sudo systemctl edit ollama加入：
[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"然后重启Ollama服务：
sudo systemctl restart ollama改完之后再确认一下监听状态：
netstat -tlnp | grep 11434正常能看到监听地址从127.0.0.1:11434变成了0.0.0.0:11434。
4.2 防火墙放行11434端口
这一步是新手最容易栽的地方。明明Ollama已经在监听了，局域网其他设备就是连不上。原因基本是防火墙把11434端口拦了。Windows平台，在防火墙入站规则里加一条放行TCP 11434端口；Linux平台，如果开了firewalld或ufw，执行相应放行命令：
sudo ufw allow 11434/tcp放行之后，从另一台设备上验证一下。假设你运行Ollama的机器IP是192.168.1.100，那就在另一台设备的浏览器里直接访问：
http://192.168.1.100:11434/api/tags能返回JSON格式的模型列表，就说明局域网调用链已经通了。这一步是整个方案的分水岭：通了，OpenClaw就能在局域网任意设备上使用这个模型后端；不通，后面对接也无从谈起。
4.3 安全边界与访问控制
把API暴露到局域网，意味着内网里任何一台设备都能调用你的Ollama接口。在内网这种可信环境里问题不大，但有几个边界得说清楚。
第一，如果你所在的网络有公共Wi-Fi或者对外开放的访客网络，建议不要开启0.0.0.0监听，改成固定内网IP监听更稳。第二，Ollama本身没有默认鉴权机制，所以不要把这个端口映射到公网，否则别人扫到你的IP就能白嫖你的显卡。第三，如果一定要跨网络访问，可以套一层反向代理加访问令牌，但这就超出“省钱计划”的范围了，不做展开。
5. OpenClaw对接本地Ollama：配置改写与调用链路验证
OpenClaw的配置方式在不同版本里略有区别，但核心逻辑是一致的：它支持自定义API Base URL，只要目标服务兼容OpenAI接口规范，就能直接对接。Ollama刚好提供了/v1这个OpenAI兼容端点，这让对接难度大幅降低。
5.1 配置文件里的关键字段
打开OpenClaw的配置文件（一般是项目根目录下的settings.json或类似命名），找到模型后端配置段。通常会看到类似这样的结构：
{ "model_provider": "ollama", "model": "qwen2.5:7b", "api_base_url": "http://192.168.1.100:11434/v1", "api_key": "ollama" }各字段的作用我解释一下：
model_provider：声明模型后端类型，填ollama表示走Ollama。model：指定模型名称，必须和ollama list里显示的标签完全一致，填错了会被拒绝。api_base_url：Ollama服务地址，注意后缀必须带/v1，这是OpenAI兼容端点所在路径。如果你的OpenClaw和Ollama在同一台机器上，可以填http://127.0.0.1:11434/v1；如果在局域网另一台机器上，就填那台机器的内网IP。api_key：Ollama不校验API Key，随便填一个非空字符串即可，但别留空，有些客户端会校验这个字段是否存在。
5.2 验证调用链路的三段式测试
改完配置先别急着启动OpenClaw，用三段式测试确认每个环节都是通的。第一段，在OpenClaw所在设备上用curl直接访问Ollama的补全接口，看看模型能不能正常响应：
curl http://192.168.1.100:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好"}] }'如果返回了一段包含回复内容的JSON，说明“OpenClaw所在设备到Ollama服务”这一段是通的。第二段，启动OpenClaw，随便问一个问题，看它是否有响应。第三段，检查OpenClaw日志里有没有报错。如果第一段通、第二段没反应，重点看日志中关于模型名的报错——大概率是配置里的模型标签和实际不符。
这三段式的好处是能快速定位问题发生在哪一段：连不上是地址问题，连上但报错是参数问题，都能在几分钟内锁定方向。我当初第一次对接时，第二段迟迟不出结果，查了半天发现是配置文件里模型名写成了qwen2.5:7b，而实际拉取的标签是qwen2.5:7b-instruct这类的变体，一顿折腾才意识到是名字对不上。
5.3 上下文长度与参数调整
OpenClaw这类工具对上下文窗口有默认值，有时是2048，有时是4096。Ollama这边默认上下文长度也不大，两者如果设置不一致，会出现“对话到一半突然失忆”的现象。
Ollama可以在运行时指定上下文长度。刚才说的ollama run是交互式用法，如果你想让OpenClaw获得更大的上下文窗口，需要在启动时传环境变量或者用配置指定。一个比较稳的做法是在Ollama服务端设置全局默认，Linux下编辑service文件的Environment字段，加一行：
Environment="OLLAMA_CONTEXT_LENGTH=8192"然后在OpenClaw配置里把上下文长度同步设置成8192。两边对齐之后，长对话体验会好很多。注意上下文长度越大，显存占用越高，刚拉好8B模型时你可能能跑2048，改成8192之后可能就溢出了，需要自己按机器配置权衡。
6. 实测记录：日常任务的响应速度、效果与最终省钱账本
配置全部搞定之后，我连续用了一周，把OpenClaw接Ollama当作主力后端来跑日常任务。这里把实测结果和账单情况如实列一下。
6.1 四类日常任务的实测表现
我自己的使用场景比较固定，主要是四点：邮件草拟、周报生成、代码片段补全、资料问答。逐个说效果。
邮件草拟这块，8B模型的表现超出我预期。给它一个简单的指令“帮我回一封邮件，内容是确认下周二下午三点的会议，语气客气一点”，它能生成结构完整的回信，语气也把握得不错。不过偶尔会用词过于书面，需要我自己顺一遍，但工作量已经从“写一封邮件”降到了“改一封邮件”。
周报生成是另外一回事。因为周报需要结合一周的具体事项，信息量比较大，8B模型在提炼要点时偶尔会漏掉细节。我的应对方法是给OpenClaw配置了一个固定提示词模板，让它先列出所有事项再逐条总结，生成质量明显提升。这里要说明，提示词工程在本地模型上比在云端大模型上更敏感——本地模型的指令遵循能力没那么强，你得把要求写得更明确、更结构化。
代码片段补全是最让我惊喜的。写一段Python脚本时让OpenClaw补全函数实现，它给出的代码不仅语法正确，命名风格也和我的代码库保持一致。问了几个有经验的朋友，他们的反馈也类似：8B模型在常见编程任务上确实能搭把手。
资料问答就要区分难度了。基于我提供文档里的信息做摘要、提炼，效果不错；但问“这篇文档和另一篇文档的逻辑差异”这种需要深层推理的问题，它就开始露怯了，答案经常答非所问。这种任务我就会切回云端API处理，不在本地模型上强求。
6.2 响应速度：本地部署的甜蜜点在哪里
速度方面，我的GPU配置下生成速度大约在每秒20~30个token。这是什么概念？OpenClaw回复一段100字的短文，大概5秒以内出完；回复一段500字的详细分析，十几秒也差不多了。对于日常邮件、周报这种短文本任务，体验基本流畅，体感上跟云端API慢一点，但没到让人烦躁的地步。
如果你是纯CPU推理，同样的8B模型速度会掉到每秒2~5个token，那就只适合偶尔用用，不适合当作主力后端。预算允许的话，一块大显存显卡是本地模型体验的分水岭。
6.3 算一笔账：到底省了多少钱
对比我此前用云端API的账单，情况是这样的：原来每月中轻度使用，成本大约在60~100元之间，量大时能冲到150元以上。切到Ollama本地部署之后，这笔费用直接归零。电费当然会涨一点，但GPU满载时的功耗也就一两百瓦，按一度电六毛钱算，每天重度用两小时，一个月电费增加十几块钱到头了。
算下来，每年省一千多块，同时换来的是数据不出内网和不受API限流约束。唯一的代价是模型“聪明程度”有所下降——这就是本地部署模型和云端付费模型之间最本质的trade-off，你得自己判断这值不值。对我来说，值。
7. 踩坑与排查：连接失败、GPU不加载、上下文缩短的完整链路
最后这部分是全文最值得看的地方。我把这一周折腾出来的坑全部列出来，每个都附上排查思路和最终解法。这些坑也不是我一个人遇到的，好几个是某开发者朋友远程帮我排查时一起踩过的。
7.1 局域网设备“连接被拒绝”：先分清是防火墙还是监听地址问题
现象：OpenClaw所在设备通过http://192.168.1.100:11434访问Ollama，报“Connection refused”。排查链路分两步。第一步，在Ollama所在机器上先确认服务是否在监听：netstat -tlnp | grep 11434。如果在监听且地址是0.0.0.0，说明服务本身没问题，往防火墙方向排查。如果监听地址只有127.0.0.1，说明OLLAMA_HOST没有生效，回到环境变量配置那一节重新检查。
第二步，在OpenClaw所在设备上ping一下服务器IP，确认两台设备在同一网段。这一步看似多余，但有一次排查半天发现是两台设备连了不同的Wi-Fi信号，压根不在一个网段里，属于内网但互不相通。
7.2 GPU不加载、模型跑在CPU上：问题出在Ollama服务没读到显卡状态
现象：首次拉完模型后，终端提示“llama runner started”，但生成速度奇慢无比，一看GPU占用率几乎是零。这种情况在Windows上比较常见，通常是显卡驱动版本太旧，或者系统里缺少必要的运行时组件。查看Ollama日志，如果有类似“no NVIDIA GPU found”或“failed to load CUDA”的报错，先去更新显卡驱动，再确认CUDA版本是否在Ollama支持范围之内。
Linux下还有一种可能：Ollama以服务方式启动时，用户和权限设置导致它无法访问显卡设备文件。解决方法是给服务加--gpus all这类参数，或者把服务用户加到video组里。我自己在Linux上就吃过这个亏，服务模式跑了一晚上CPU推理，改完权限瞬间飞起。
7.3 显存溢出OOM：模型能加载但推理一半崩掉
现象：模型刚开始对话正常，聊到第三四轮突然报OOM，然后服务自动重启。原因是上下文长度过长，导致KV缓存撑爆了显存。解决思路有两个：要么减小OLLAMA_CONTEXT_LENGTH，要么换一个更小的量化版本模型。我个人建议先降上下文，再考虑换模型。毕竟8B模型的日常场景大多不需要8192的超长上下文，4096往往已经足够。
7.4 OpenClaw配置正确但一直转圈：模型名不一致是头号嫌疑人
现象：OpenClaw界面能启动，但发消息后一直转圈不出结果。此时查看OpenClaw日志，如果恰好报错model "xxx" not found，那基本就是配置里的模型名和Ollama本地标签不一致。回Ollama那边执行ollama list，把显示的标签原封不动复制到OpenClaw配置里，问题即刻解决。这看起来是个低级错误，实际操作中却是出现频率最高的坑。
8. 扩展到更多设备与后续优化方向
跑通局域网API调用之后，一个自然而然的想法是：既然OpenClaw能从另一台机器调用Ollama，那其他设备呢？答案是当然可以。手机、平板、同事的电脑，只要在同一局域网内，都能通过HTTP请求访问这个API。
你可以用手机上的HTTP客户端工具直接调Ollama接口，也可以在其他开源项目里把模型提供方改成这个局域网地址。一套本地模型，全内网设备通用，这才是局域网API调用最有价值的地方。
8.1 多设备共享时的小优化：base_url设置与负载分配
如果你的OpenClaw跑在A设备上，B设备上的另一个工具也想用同一个Ollama，那么两边的api_base_url都指向运行Ollama那台机器的内网IP即可。要注意的是，Ollama服务天然串行处理请求，如果同一时间多个设备同时发起请求，后面的请求会自动排队。多设备共享时，尽量错峰使用，或者给光看模型的GPU分配更大显存，减少单次推理占用时间。
8.2 下一步的优化方向
跑通之后，我后续计划做三件事。第一，把OpenClaw日常任务按难度分流：简单任务固定走本地Ollama，复杂任务自动切换云端API。第二，试一下更大的14B模型，看看在显存能承受的前提下，推理质量提升多少。第三，研究一下Ollama的多模型并行加载，让不同任务自动路由到不同模型。
这些方向暂时没有完全跑完，先把已经验证过、确定可行的部分写出来，给想走这条路的同学一个参考。说到底，OpenClaw省钱计划的核心逻辑就一句话：能用本地免费模型解决的问题，就不必花云端API那份钱。实际跑了一个多星期，结论是这套方案不仅可行，而且日常体验远没有想象中那么“将就”。
