“真无限 tokens”这句话我第一次看到时的反应其实是有点怀疑的。毕竟接触过云端大模型 API 的人都知道上下文窗口有硬上限按量计费的账单也从来不会骗人。直到自己动手把 Ollama 装到本地拉下一个 7B 的开源模型再让 OpenClaw 这个 AI 助理框架接上本地接口连续跑了一下午的对话和自动任务账单数字纹丝不动我才真正理解这个标题说的“无限”是什么意思它不是上下文无限而是使用自由无限。模型住在你的显卡里不按 token 计费没有每分钟请求数限制想调多少次就调多少次。这篇文章写给两类人。一类是刚开始玩本地大模型想摆脱云端 API 配额和费用、把数据握在自己手里的玩家另一类是已经听过 OpenClaw 这类 AI 助理框架但不想把对话记录送出去想把它接到本地模型上用的人。不需要太深的深度学习背景跟着下面的操作一步步来从安装 Ollama、拉取模型到配置 OpenClaw 并跑通工具调用一个下午基本能完成。1. 项目拆解什么叫“真无限 tokens”OpenClaw 又是干什么的1.1 “真无限 tokens”不是上下文无限而是使用自由无限很多人一看到“无限 tokens”就会往“上下文窗口无限大”上联想这个理解是错的。大模型在生成每个 token 时都要把之前对话的中间状态存在显存里的 KV Cache 中上下文越长KV Cache 越大显存占用越高。这是物理限制不管模型多大都逃不掉。所以任何宣称“无限上下文”的营销说法实际都只是在某种硬件前提下的相对结论。但本地部署确实换了一种玩法。云端 API 的“有限”体现在几个地方按 token 计费意味着每次对话都在花钱TPM每分钟 token 数和 RPM每分钟请求数限制要求你做限流管理服务维护期还会直接中断你的调用。本地模型没有这些概念它只受你硬件性能的约束。你跑一次完整工具调用可能要烧掉几千个 token在云端 API 上这就是几轮对话的钱在本地只是显卡多转了几下。这个体验上的差异用“无限”来形容并不夸张。再往深一层说本地部署解决的不只是成本问题。OpenClaw 这类助理框架在跑任务的时候会反复调用模型模型提出工具调用意图、框架执行命令、结果回传、模型继续推理一个完整任务可能来回十几轮。这些中间过程的 token 消耗往往比最终回答还要多。如果走云端 API每轮的输入输出都要计费一轮操作下来成本非常可观接上本地 Ollama中间过程随便烧完全不心疼。所以“真无限 tokens”这个标题重点不在上下文而在“试错自由”。1.2 OpenClaw一个把模型“用起来”的开源 AI 助理框架OpenClaw 和我平时接触的模型问答客户端最大的不同在于它不是一个聊天框而是一个能调用工具的 AI 助理框架。它把大模型当作“大脑”然后给大脑接上“手和脚”。所谓手和脚就是工具调用tool calling / function calling你让它整理某个目录下的文件、查询系统日志、执行脚本、生成周报OpenClaw 会让模型先判断需要调用哪些工具再在你的机器上实际执行把结果回传给模型继续推理。这套机制的底层逻辑是 chain-of-thought 加上 tool use。模型不直接输出“我可以帮你列出大文件”而是输出一个结构化的函数调用指令比如list_large_files({count: 5, path: /home/user})框架解析这个指令执行后把文件列表作为新的上下文消息喂回模型模型再根据真实结果生成最终回答。没有这层调度你只能进行“口语问答”接上这层调度模型才真正开始“干活”。OpenClaw 本身不提供模型它只负责编排和调度。这意味着你可以把任何符合接口规范的模型接进去既能接云端也能接本地。这也正好对应了标题里的“跑通”二字如果只装 Ollama你只是在终端里跟模型聊天把 OpenClaw 接上去之后你拥有的是一套可以自动执行任务的个人助理系统。1.3 为什么选 Ollama模型管理、接口兼容、跨平台接入本地模型的方式不止一种有人用 llama.cpp 源码编译有人用 LM Studio 的图形界面有人直接用 vLLM 跑服务但我在这个项目里选择 Ollama核心是它把三个关键问题解决得比较省心。第一是模型仓库和标签体系成熟。一条ollama pull命令就能拉取已经量化好的模型不需要自己下载原始权重再手工转格式。模型标签写得很清楚比如qwen2.5:7b-instruct-q4_K_M后面那个后缀就是量化精度。第二是内置推理引擎自动做显存分配它会优先把模型尽可能加载到显卡显存不够再溢出到内存新手完全不用管 CUDA 手动的显存管理。第三是它暴露了 OpenAI 兼容的 HTTP 接口默认跑在 11434 端口。这个兼容接口非常关键因为 OpenClaw 这类第三方框架基本都认 OpenAI 的接口格式只要把 Base URL 指过去就能用省掉写自定义适配层的麻烦。选型时我也考虑过一些坑。Ollama 自动管理显存确实方便但它只做“能不能跑”的判断不做“够不够快”的优化。如果你的显卡只有 4GB 显存硬拉一个 7B 模型下来虽然能跑但模型大部分权重会被挤到内存里推理速度会跌到每秒几个 token体验非常差。所以后面第 2 章会先讲硬件账怎么算再讲怎么拉模型顺序不要反。2. 硬件评估与本地环境准备2.1 先算一笔硬件账再决定拉哪个模型这一步很多人会跳过直接装完 Ollama 就拉最大号的模型结果等半天发现显存不够白白浪费时间。其实一个简单公式就能把账算清楚显存占用大致等于参数量乘量化位数除以 8。比如一个 7B 参数量的模型也就是 70 亿参数用 Q4 量化4 bit来存模型权重大约占 70 亿 × 4 bit ÷ 8 3.5GB。如果是 F16 全精度就是 70 亿 × 16 bit ÷ 8 14GB直接翻了四倍。这还只是权重上下文窗口的 KV Cache 还要额外吃显存7B 模型配 4096 上下文大概再吃几百 MB 到 1GB。基于这个公式我给的入门建议是8GB 显存先用 7B 或 8B 模型的 Q4 量化版16GB 显存可以上 13B/14B 的 Q4 版或者 7B 的高精度版24GB 以上再考虑 32B 的 Q4 量化。如果你是纯 CPU 环境没有独立显卡那也能跑7B 量化模型在内存足够的情况下大约每秒能吐几个 token适合验证流程不适合日常高频使用。我自己的经验是第一次跑通链路千万别追求大模型。先用 qwen2.5:7b-instruct 这种消费级友好的模型把 Ollama、OpenClaw、工具调用整个链路跑通确认没问题了再根据硬件升级。在没跑通之前换大模型只会让问题排查变得复杂你分不清到底是模型能力问题还是配置问题还是显存不足问题。2.2 Ollama 安装三种系统各有各的坑Ollama 的安装本身不复杂但不同平台有一些细节值得提前知道。Linux 是最顺的官方提供一键安装脚本终端执行curl -fsSL https://ollama.com/install.sh | sh装完会自动注册系统服务ollama serve默认就在后台跑着。macOS 直接下安装包拖进 Application 就行菜单栏会有小图标。Windows 目前是下载安装包新版本安装完会注册成后台服务运行ollama命令就能看到版本信息。装完之后先做一件事打开终端跑ollama --version再跑ollama list确认服务和命令都正常。如果在 Windows 上遇到命令找不到多半是安装时没勾选加入 PATH或者需要重开终端让它重新加载环境变量。另外Windows 上如果之前装过 WSL2 里的旧版 Ollama再装 Windows 原生版两边可能会抢同一个端口这是非常典型的踩坑点后面第 5 章排查部分会细说。2.3 拉取第一个开源模型用 qwen2.5:7b-instruct 起步模型选择上我强烈推荐中文环境先从qwen2.5:7b-instruct开始。原因很直接它对中文的理解和指令遵循能力在同等量级模型里属于第一梯队而且原生支持工具调用正好满足 OpenClaw 的硬需求。如果你主要是英文场景换成llama3.1:8b也很不错。拉取命令就一条ollama pull qwen2.5:7b-instruct下载完成后用ollama list确认模型已经就位直接在终端试一句ollama run qwen2.5:7b-instruct输入“你好介绍一下你自己”看回答是否正常。这一步非常关键等于提前验证了模型本身没有问题后面 OpenClaw 出了问题才不用怀疑模型。我遇到过很多人一上来就跳过这一步结果 OpenClaw 跑不通最后排查半天发现是模型压根没下载完整。关于模型标签简单解释一下。Ollama 模型仓库里同一个模型会有不同量化后缀常见的有q4_0、q4_K_M、q8_0等。Q 后面的数字代表每个权重占多少 bit数字越小占用越小精度损失越大。默认不带后缀的标签一般是官方推荐的量化版本通常是 Q4_K_M这是质量和体积之间比较平衡的选择。新手不用纠结直接用默认标签就行。3. 服务调优与 API 对接把 Ollama 变成标准接口服务3.1 用环境变量控制服务行为Ollama 默认配置可以跑但要接入 OpenClaw我建议花几分钟把几个环境变量设置好。这些变量决定了服务监听地址、模型存放位置、上下文长度和模型驻留时间每一项都直接影响 OpenClaw 的体验。四个关键变量分别是OLLAMA_HOST服务监听地址默认127.0.0.1:11434本机访问足够了。如果是配了远程机器不想把服务暴露到公网但又要局域网内访问可以改成0.0.0.0:11434但要注意接入设备都在可信网络里毕竟这个接口没有任何认证。OLLAMA_MODELS模型存放路径默认在用户目录下。如果系统盘空间紧张可以指到其他大容量磁盘。OLLAMA_CONTEXT_LENGTH默认上下文长度。Ollama 的默认值偏低OpenClaw 的多轮任务很容易触发上下文超限建议直接设成8192。OLLAMA_KEEP_ALIVE模型在显存里的驻留时间默认 5 分钟会被卸载。OpenClaw 这类工具调用场景每次间隔可能稍长模型反复加载会非常影响体验可以设成-1让模型永久驻留。Linux 和 macOS 在终端export OLLAMA_CONTEXT_LENGTH8192后重启服务即可。Windows 需要在系统环境变量里设置然后重启 Ollama 服务。我实测下来比较舒服的起步组合是OLLAMA_CONTEXT_LENGTH8192加OLLAMA_KEEP_ALIVE-1既保住多轮对话上下文又避免模型频繁从磁盘重新加载。如果你显存不太够KEEP_ALIVE-1反而会占着显存不释放那时候就不要设成永久驻留。3.2 用一个 curl 请求验证本地接口通不通设置完环境变量并重启 Ollama 后先用一个简单请求验证接口是否正常。Ollama 默认同时提供两种 API一种是自己的/api/chat另一种是 OpenAI 兼容的/v1/chat/completions。OpenClaw 这类框架只认/v1所以我们要测的也是这个接口。curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b-instruct, messages: [{role: user, content: 你好}], stream: false }返回的 JSON 里会有一个choices数组里面的message.content就是模型的回复。看到这个结构说明本地 OpenAI 兼容接口已经通了OpenClaw 接进来就有了基础。这里强调一点很多人习惯按 Ollama 官方文档用/api/chat但那个接口的请求体格式是{model: ..., messages: [...]}虽然看起来差不多但第三方框架默认不认。统一走/v1/chat/completions的好处是未来你想从 Ollama 换到其他兼容本地方案OpenClaw 这边的配置一行都不用改。3.3 把 OpenClaw 的模型提供者指向本地接口OpenClaw 这类框架通常会有一个模型提供者provider配置核心字段就四个provider类型、base_url接口地址、model模型名、api_key密钥。指向本地模型时配置大概是这样的思路base_url填http://127.0.0.1:11434/v1注意一定要带/v1后缀model填ollama list里看到的完整模型名比如qwen2.5:7b-instructapi_key填任意占位字符串比如ollama-local因为本地服务不校验其他参数如temperature按自己习惯留默认之所以说“大概是这样的思路”是因为 OpenClaw 的版本迭代比较快不同版本的配置文件格式和字段名可能略有差异。但无论界面怎么变后端它需要的就是一个 base URL 加模型名。你只要确保 OpenClaw 的程序能访问到http://127.0.0.1:11434/v1这个链路就通了。还有一点容易被忽略OpenClaw 的工具调用能力高度依赖模型本身是否支持 function calling。7B 级别的模型里qwen2.5系列和llama3.1系列都是支持得不错的。如果你拉了一个很老的模型或者纯基座模型OpenClaw 可能能聊天但无法执行工具任务这不是 OpenClaw 坏了而是模型能力不够。4. 跑通全链路从安装 OpenClaw 到完成真实对话4.1 安装 OpenClaw 依赖环境与本体OpenClaw 的基础环境通常是 Node.js建议先确认本机版本满足要求至少 18 以上。装完之后用包管理器或者直接拉取项目仓库的方式拿到 OpenClaw 本体具体命令以你拿到的官方仓库说明为准因为这类项目更新快我这边写死的命令过几个月可能就变了。大致的安装步骤是先把项目克隆下来进入项目目录执行依赖安装然后启动 CLI。首次启动它会生成一个配置文件目录里面包含模型提供者配置、工具启停配置、日志级别等内容。这一步做完之后最直接的表现是你可以在终端里跟 OpenClaw 对话了但此时它还在用默认模型配置也就是可能指向云端。下一步就是把它改成本地 Ollama。安装过程中常见的坑有两个。一个是 Node.js 版本太低某些依赖装不上报错信息里通常会提示 engines 版本要求另一个是依赖安装时网络不稳定导致装到一半失败这种问题一般换个时间重跑安装命令就能解决。另外如果你之前装过其他 AI 工具它们可能会共用同一个配置目录注意区分不要改错配置文件。4.2 在配置里让 OpenClaw 认到 Ollama打开 OpenClaw 的配置文件找到模型提供者相关的段落。这里我习惯直接用文本编辑器改 JSON 片段大致长这样{ provider: ollama, model: qwen2.5:7b-instruct, base_url: http://127.0.0.1:11434/v1, api_key: ollama-local, temperature: 0.7 }如果你手里的 OpenClaw 版本没有provider这种叫法那就找model相关的配置块核心逻辑是一样的把原本指向云端服务的地址改成你本地 Ollama 的/v1接口。model字段一定要跟ollama list输出完全一致带冒号和标签比如qwen2.5:7b-instruct写错一个字符都会导致 404。改完配置记得重启 OpenClaw。这一步有个自我验证的小技巧先不重启直接把配置里的 base_url 复制到浏览器或者 curl 里访问如果返回 404说明 Ollama 没在跑或者地址写错如果能通再重启 OpenClaw 去加载配置。这样能最大程度把问题隔离在“配置”和“环境”两层之间。4.3 实际跑一个任务看模型怎么被调用配置就绪后进入 OpenClaw 对话界面我建议先不要聊太开放的话题直接试一个带工具调用的任务。比如输入“帮我列出当前目录下最大的 5 个文件”。正常情况下你会看到 OpenClaw 的日志里先出现一次工具调用意图比如模型输出一个类似list_files的指令然后框架在本地执行目录扫描接着日志里出现工具结果最后模型基于真实结果生成总结回答。这就是一个完整的工具调用闭环也说明全链路真正跑通了。链路的时序是这样的用户输入 → OpenClaw 把对话历史发给 Ollama → Ollama 返回工具调用结构化结果 → OpenClaw 解析并执行本地命令 → 执行结果作为新消息回传给 Ollama → Ollama 生成最终回答。每一步都有日志可查所以排查时非常方便。前面在第 3.2 节让你先用 curl 验证就是因为如果 curl 都通不过OpenClaw 这层完全是白搭。这里有一个值得留意的经验工具调用会消耗大量 token尤其是多步骤任务。本地模型没有成本顾虑但也不能完全放开因为上下文长度终究有限。OpenClaw 如果连续执行工具任务每轮都要把历史结果塞进上下文很容易触及 8192 的上限。所以我建议在 5.2 节把OLLAMA_CONTEXT_LENGTH调大之前先别跑太复杂的任务链。5. 常见问题与排查技巧实录5.1 显存不足导致模型加载失败跑本地模型最常遇到的错误就是进程异常退出典型报错类似Error: llama runner process has terminated: exit code 137或者直接提示无法分配显存。这个 exit code 137 通常就是被系统杀掉罪魁祸首基本都是模型权重加上 KV Cache 超过了显卡可用显存。排查顺序我建议这样先跑nvidia-smi看显卡占用排除是其他程序占了显存。然后跑ollama ps看当前模型到底加载在 GPU 还是 CPU。如果模型确实溢出到了 CPU可以尝试换一个量化更低的版本比如从q4_K_M降到q2_K或者把上下文长度调低因为上下文 KV Cache 吃掉的显存比你想象的大。如果你执意要跑某个模型且显存刚好差一点可以不开OLLAMA_KEEP_ALIVE-1让模型按需加载这样至少不会把显存占满。5.2 上下文长度参数与报错OpenClaw 做多轮工具调用时常见的报错是上下文溢出比如context length exceeded或者slot context相关提示。原因是 Ollama 的默认上下文长度通常只有几千 token多轮对话加上工具结果很容易超。解决办法就是设置OLLAMA_CONTEXT_LENGTH。我在第 3.1 节建议的 8192 是一个起步值如果你跑的是复杂任务可以进一步调到 16384。但千万记住上下文长度与显存占用是正比关系调太大会把显存吃爆反而触发 5.1 的不稳定问题。实际使用中要摸一下自己机器的平衡点如果 8192 够用就没必要盲目拉高。5.3 本地接口连接失败端口、地址、密钥OpenClaw 报connection refused或者连接超时排查思路要从外到内。先用ollama list确认 Ollama 服务还活着如果服务没起手动执行ollama serve启动。再看端口lsof -i :11434或 Windows 下的netstat -ano | findstr 11434确认端口是谁在监听。如果是 WSL2 和 Windows 原生版两个 Ollama 在抢端口就要统一停掉一个。接口地址方面最容易漏的就是/v1后缀。http://127.0.0.1:11434能访问到 Ollama 的根路径但 OpenClaw 需要的 chat completions 接口在/v1/chat/completions所以配置里一定要写http://127.0.0.1:11434/v1。至于api_key本地 Ollama 根本不校验填什么都能过但如果 OpenClaw 报 401 认证失败大概率是框架还在拿配置里的密钥去请求某个云端服务说明你的配置没真正切到本地。5.4 推理慢到没法用先分清瓶颈很多人把“慢”归结为模型太大其实慢也有不同类型。先观察现象如果模型加载就要几十秒后面生成还行那问题在OLLAMA_KEEP_ALIVE太短模型总在卸载重载如果是每生成一个 token 都要等一下那基本是生成速度慢也就是模型没跑在 GPU 上或者量化不够激进。用ollama ps看PROCESSOR列如果显示100% CPU说明模型根本没进显卡。这时候检查驱动、CUDA 版本、Ollama 版本以及是否有其他程序把显存占满。CPU 模式也不是不能跑但要调整预期7B Q4 模型在纯 CPU 上大概每秒几个 token用来验证流程可以日常高频使用很难受。这种情况下要么换更小的模型比如 3B 甚至 1.5B要么升级硬件。5.5 常见问题速查表症状可能原因解决方法模型加载时报 exit code 137显存不足进程被杀换更小量化模型或降低上下文长度推理速度只有每秒几个 token模型跑在 CPU 上用ollama ps检查优化显存占用报 context length exceeded上下文长度不够调大OLLAMA_CONTEXT_LENGTH并重启服务OpenClaw 报 connection refusedOllama 服务未启动或端口不对手动启动ollama serve检查端口监听OpenClaw 报 404 model not found模型名写错用ollama list对一下完整名称每次对话前都要等很长时间模型被频繁卸载重载设置OLLAMA_KEEP_ALIVE-1工具调用不执行只聊天模型不支持 function calling换 qwen2.5 或 llama3.1 系列的指令模型这个项目跑通之后我最大的感受是“真无限 tokens”改变最大的其实是试错成本。用云端 API 时每改一次 prompt、每调一次工具都下意识地算着 token本地模型则可以随便折腾反复烧几十轮对话就为了测试一个配置心态完全不一样。我的建议是先让qwen2.5:7b-instruct这种 7B 量化模型把完整链路跑通验证 OpenClaw 的对话和工具调用都没问题再根据硬件去换更大的模型。另外一个小经验尽量统一用 Ollama 的/v1接口以后哪怕换到别的兼容服务OpenClaw 这边配置都不用动。最后跑 OpenClaw 报错时别急着怀疑框架先在 Ollama 命令行里直接问同一个问题——命令行能回答说明问题在配置命令行都不对那就是模型或环境的问题。这样一分层排查速度会快很多。