ollama 在 Ubuntu 装不上OpenClaw 报的却是另一类错。TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿 Key模型出口从本机 11434 换到统一 API 通道。很多人第一次搭 OpenClaw 是这么走的装 ollama拉一个 llama3.1:8b在~/.openclaw/openclaw.json里把baseUrl指向http://localhost:11434/v1然后启动服务网关监听 18789。这四件事里任何一件断了最后看到的提示都差不多——OpenClaw 用不了。于是很容易把锅扣在 OpenClaw 头上反复重装它。实际拆开看ollama 是模型供给方OpenClaw 是调用方两者之间只靠一个 HTTP 地址连着。地址还在只是对面没人应答那就换一个对面不必非得把本机那套模型环境先修好。如果你的 Ubuntu 上 ollama 官方渠道下不动只能去 GitHub 拖ollama-linux-amd64.tar.zst再用 vmhgfs-fuse 挂 VMware 共享目录拷进/opt/ollama改权限这条路本身就不稳解压完整性、目录权限、共享挂载点任何一处出错都会让ollama serve起不来。跟它死磕之前先把 OpenClaw 的模型通道单独拎出来能省下大量时间。1. ollama 装不上和 OpenClaw 用不了是两段链路1.1 ollama-linux-amd64.tar.zst 这条手工路线卡在哪官方安装脚本走的是下载 解压 装服务三步。Ubuntu 上最常见的是第一步就断脚本卡在下载阶段没有输出或者提示连接超时几十兆的压缩包下到一半失败。这时候换成从 GitHub release 手动拖ollama-linux-amd64.tar.zst是常规操作但拖下来之后才是麻烦的开始。.tar.zst需要 zstd 支持Ubuntu 上tar --zstd未必可用得先确认zstd装没装。解压出来是一堆二进制扔进/opt/ollama之后要chmod x还要考虑是不是用 systemd 托管。如果这个包是从 VMware 共享目录里拷出来的权限位本身就带着宿主机的属性vmhgfs-fuse默认挂载时权限映射常常是 777 或者干脆不可执行chmod之后仍然启动失败的情况并不少见。还有一个不容易发现的点压缩包在共享目录和虚拟机之间来回复制很容易只拷了一半。zstd -t校验一下再解压比解压到一半报错再来回查更省事。1.2 ~/.openclaw/openclaw.json 里的 baseUrl 才是真正的开关排障时先问一句OpenClaw 到底从哪里拿模型答案在~/.openclaw/openclaw.json。这个文件里 provider 段有一个baseUrl默认写成http://localhost:11434/v1也就是本机 ollama 的 OpenAI 兼容端口。这意味着ollama 有没有装成功只影响本机模型供给这一件事OpenClaw 能不能对话取决于这个baseUrl指向的地址是否有服务在响应。两者是解耦的。你把 ollama 折腾到凌晨三点baseUrl还是指向一个没起来的 11434OpenClaw 当然一直是同一个错。把这个判断做出来之后路就分岔了一条是继续修本机模型环境另一条是把baseUrl换成云端的兼容通道。前者要处理驱动、显存、zstd、权限后者只需要一个 Key 加一个地址。2. Ubuntu 上 ollama 官方下载失败的几个典型现场2.1 安装脚本卡在下载阶段的判断方法跑官方安装脚本时如果终端停在某一步长时间不动先用curl -I单独测一下下载域名通不通把网络慢和通不了区分开。前者多等一会儿可能就过了后者再等也没用。另一个判断依据是磁盘。ollama 的包加上解压后的二进制占的空间比想象中大df -h看一下根分区如果/已经用到九成以上脚本会在写文件那步失败报错信息却往往指向别的地方。还有一种情况是脚本跑完了但systemctl status ollama显示 inactive。这时候看日志里有没有 address already in use——11434 被别的进程占了。这种情况不需要重装换个端口或者把占用的进程处理掉即可但 OpenClaw 那边的baseUrl也要跟着改。2.2 vmhgfs-fuse 挂载共享目录后的 /opt/ollama 权限坑用 VMware 共享目录传文件的同学对这段应该不陌生。vmhgfs-fuse挂上之后拷过去的文件默认挂载参数决定了权限常见是uid0,gid0但执行位丢失。表现就是ls看得见文件执行时报 Permission denied 或者 cannot execute binary file。处理顺序建议这样先ls -l看执行位缺了就chmod xchmod之后还不行检查文件系统是不是noexec挂载再不行就把文件从共享目录复制到本地磁盘比如/usr/local/bin再操作而不是直接在共享目录里执行。这一步能排掉一大半明明有文件却跑不起来的怪现象。2.3 ollama pull llama3.1:8b 之前的自检清单走到ollama pull llama3.1:8b这一步说明二进制已经能跑了。拉模型之前值得确认三件事ollama serve是否在跑、curl http://localhost:11434/api/tags有没有返回、磁盘剩余空间够不够8B 级别的模型加上量化几个 GB 是常态。这三项都过了pull还是卡住那就是下载环节的问题跟前面装二进制是两码事。很多人在这一步把整条链路推倒重来其实完全没必要。3. 决定绕开本机模型之前先想清楚谁提供模型3.1 去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 建一把 Key换云通道这件事第一步不是改配置文件而是先把凭证拿到手。打开 TaoToken注册账号之后进控制台创建一把 API Key。这把 Key 就是后面apiKey字段要填的值复制出来先放好别贴在聊天窗口里。这里要说清楚边界TaoToken 提供的是 Key 和 Base URL 两样东西它不负责让你的 Ubuntu 把 ollama 装上。本机模型环境那摊事该修还得修换上云通道之后OpenClaw 走的是另一条路跟 11434 没关系了。3.2 模型 ID 以模型广场当时列表为准拿到 Key 之后别忘了确认模型 ID。不同时间点上架的模型不一样写死在配置里的 ID 过一阵可能就下架了。正确做法是打开模型广场看当时列表里有哪些可用项挑一个复制它的 ID。不要凭记忆写gpt-4、claude-3这类通用名字也别自己加日期后缀。模型 ID 填错返回的往往是模型不存在跟 Key 无关但排查时特别容易误判成鉴权问题。4. 改 openclaw.jsonbaseUrl 从 localhost:11434 换成 https://taotoken.net/api4.1 动手前先备份只动两个值改之前先复制一份cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak。这个文件一旦改坏OpenClaw 启动阶段就会报解析错误界面上只给一句含糊的提示回滚成本远高于备份成本。这次需要动的只有两个值baseUrl从http://localhost:11434/v1改成https://taotoken.net/apiapiKey填上刚才创建的那把。其余字段——provider 名称、超时、代理设置、模型参数——原样保留。这里有个高频错误值得单独提Base URL 末尾不要带/v1。本机 ollama 的地址习惯性带/v1但换成统一通道之后https://taotoken.net/api就是完整前缀多写一段路径请求会打到不存在的路由上返回 404。4.2 一份可对照的 provider 片段下面这段只保留了这次要改的三个字段方便你对着自己文件里的位置改。不要整段覆盖你本地的配置。{ providers: { local: { baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY, model: YOUR_MODEL_ID } } }YOUR_API_KEY换成控制台里创建的那把 KeyYOUR_MODEL_ID换成模型广场上当时可用的那个 ID。改完保存重启 OpenClaw 的进程让配置生效。如果你的配置文件里 provider 是一个数组或者字段嵌套更深找到baseUrl那一行改值即可逻辑是一样的把指向本机 11434 的地址换成https://taotoken.net/api。4.3 18789 网关和 token 认证不需要改很多人改到一半会顺手把网关配置也动了这是多余动作。18789 是 OpenClaw 自己的服务端口跟模型从哪来没有关系。网关的 token 认证是保护你这个本地服务不被别人调用的也不受baseUrl影响。换句话说这次改动的影响半径很小只改了OpenClaw 往哪里要模型。你本地的访问方式、端口、鉴权规则全部照旧。如果你恰好也在用 Claude Code 这一类工具那边的接入方式是环境变量跟 OpenClaw 的 JSON 完全不是一回事别把两套配置混在一个文件里改。真要对照去看官方的接入文档更稳妥。5. 验证OpenClaw 是不是真把请求发出去了5.1 先用 curl 打一次 https://taotoken.net/api改完配置别急着开界面先用命令行确认通道本身是通的这样能把Key 或地址的问题和OpenClaw 的问题分开。curl -sS https://taotoken.net/api/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d {model:YOUR_MODEL_ID,messages:[{role:user,content:ping}]}返回里有正常内容说明 Key、模型 ID、地址三样都对上了。返回 401 是 Key 的问题返回 404 大概率是路径不对先检查https://taotoken.net/api后面有没有被多拼了/v1。注意 curl 里的地址就是接口地址不要带任何查询参数也不要加 UTM 之类的东西——那是给网页用的不是给接口用的。5.2 再看 OpenClaw 侧的日志回显curl 通了之后再启动 OpenClaw 发一条消息。如果界面正常出结果这次替换就完成了。如果界面还是报错但 curl 是通的那问题就在 OpenClaw 这一侧重点看三处配置有没有保存成功、进程有没有真正重启、日志里打出来的请求地址是不是https://taotoken.net/api。日志里如果还能看到localhost:11434说明配置没生效——多半是改错了文件或者环境变量把配置文件里的值覆盖了。OpenClaw 的配置优先级如果搞不清就先把环境变量里相关的项清掉再试。6. 排障对照401、404、连接被拒分别意味着什么6.1 401 多半是 Key 本身的问题401 说明请求打到了服务端但凭证没通过。按顺序检查Key 是不是完整复制的前后别带空格、是不是复制了别的项目的 Key、Key 在控制台里是否已被删除。还有一种隐蔽情况Key 是对的但请求头格式写错了。OpenClaw 的配置文件里通常只管apiKey字段请求头由它自己拼如果你是手写 curl 测试记得是Authorization: Bearer YOUR_API_KEY中间的 Bearer 和空格都不能少。6.2 404 往往是路径上多了 /v1从本机 ollama 迁过来的人最容易在这一步翻车。http://localhost:11434/v1里那个/v1是 ollama 的路径习惯换到统一通道之后不该带。配置里写成https://taotoken.net/api/v1或者让工具自动拼上/v1都可能得到 404。判断方法很直接把配置里的地址原样贴进 curl 试一次能不能通。通不了就是地址问题先把这个改对再谈别的。6.3 连接被拒说明请求根本没出本机如果报的是连接被拒绝或者超时而配置里明明写的是域名那先怀疑配置没生效。检查一下有没有其他地方还写着127.0.0.1:11434——比如环境变量、启动脚本、或者另一个配置文件的副本。还有一种可能是本机的出网策略限制这类问题跟 Key 和模型都无关需要在本机网络层面处理。7. 通道打通之后顺手把使用情况对一遍配置改完、消息能正常返回这件事就算收尾了。剩下两件小事值得顺手做掉。第一件用同一把 Key 在 TaoToken 模型对话 里发一条测试消息。网页端能通、OpenClaw 端也能通说明这把 Key 在两条路径上都正常以后再出问题就能快速定位是哪一侧。第二件回 控制台 API Keys 看一眼这次的调用有没有记上账。如果你打算长期让 OpenClaw 挂着跑Coding Plan 里能看清楚用量规模比等到超额才发现要划算。顺带提一句如果你同时还在用 Claude Code它的环境变量写法跟 OpenClaw 的 JSON 是两套东西对照 Claude Code 接入文档 单独配别混在一个文件里。最后回到 ollama。那条 GitHub 拖包、vmhgfs-fuse 挂载、chmod 改权限的路你什么时候想接着走都行它和 OpenClaw 现在这条通道互不干扰。真要继续修把zstd -t校验、noexec挂载、11434 端口占用这三项按顺序过一遍比反复重装有效得多。而 OpenClaw 这边baseUrl已经是https://taotoken.net/api只要 Key 在、模型 ID 对网关和认证就不用再动。
ollama 在 Ubuntu 装不上OpenClaw 报的却是另一类错。TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿 Key模型出口从本机 11434 换到统一 API 通道。很多人第一次搭 OpenClaw 是这么走的装 ollama拉一个 llama3.1:8b在~/.openclaw/openclaw.json里把baseUrl指向http://localhost:11434/v1然后启动服务网关监听 18789。这四件事里任何一件断了最后看到的提示都差不多——OpenClaw 用不了。于是很容易把锅扣在 OpenClaw 头上反复重装它。实际拆开看ollama 是模型供给方OpenClaw 是调用方两者之间只靠一个 HTTP 地址连着。地址还在只是对面没人应答那就换一个对面不必非得把本机那套模型环境先修好。如果你的 Ubuntu 上 ollama 官方渠道下不动只能去 GitHub 拖ollama-linux-amd64.tar.zst再用 vmhgfs-fuse 挂 VMware 共享目录拷进/opt/ollama改权限这条路本身就不稳解压完整性、目录权限、共享挂载点任何一处出错都会让ollama serve起不来。跟它死磕之前先把 OpenClaw 的模型通道单独拎出来能省下大量时间。1. ollama 装不上和 OpenClaw 用不了是两段链路1.1 ollama-linux-amd64.tar.zst 这条手工路线卡在哪官方安装脚本走的是下载 解压 装服务三步。Ubuntu 上最常见的是第一步就断脚本卡在下载阶段没有输出或者提示连接超时几十兆的压缩包下到一半失败。这时候换成从 GitHub release 手动拖ollama-linux-amd64.tar.zst是常规操作但拖下来之后才是麻烦的开始。.tar.zst需要 zstd 支持Ubuntu 上tar --zstd未必可用得先确认zstd装没装。解压出来是一堆二进制扔进/opt/ollama之后要chmod x还要考虑是不是用 systemd 托管。如果这个包是从 VMware 共享目录里拷出来的权限位本身就带着宿主机的属性vmhgfs-fuse默认挂载时权限映射常常是 777 或者干脆不可执行chmod之后仍然启动失败的情况并不少见。还有一个不容易发现的点压缩包在共享目录和虚拟机之间来回复制很容易只拷了一半。zstd -t校验一下再解压比解压到一半报错再来回查更省事。1.2 ~/.openclaw/openclaw.json 里的 baseUrl 才是真正的开关排障时先问一句OpenClaw 到底从哪里拿模型答案在~/.openclaw/openclaw.json。这个文件里 provider 段有一个baseUrl默认写成http://localhost:11434/v1也就是本机 ollama 的 OpenAI 兼容端口。这意味着ollama 有没有装成功只影响本机模型供给这一件事OpenClaw 能不能对话取决于这个baseUrl指向的地址是否有服务在响应。两者是解耦的。你把 ollama 折腾到凌晨三点baseUrl还是指向一个没起来的 11434OpenClaw 当然一直是同一个错。把这个判断做出来之后路就分岔了一条是继续修本机模型环境另一条是把baseUrl换成云端的兼容通道。前者要处理驱动、显存、zstd、权限后者只需要一个 Key 加一个地址。2. Ubuntu 上 ollama 官方下载失败的几个典型现场2.1 安装脚本卡在下载阶段的判断方法跑官方安装脚本时如果终端停在某一步长时间不动先用curl -I单独测一下下载域名通不通把网络慢和通不了区分开。前者多等一会儿可能就过了后者再等也没用。另一个判断依据是磁盘。ollama 的包加上解压后的二进制占的空间比想象中大df -h看一下根分区如果/已经用到九成以上脚本会在写文件那步失败报错信息却往往指向别的地方。还有一种情况是脚本跑完了但systemctl status ollama显示 inactive。这时候看日志里有没有 address already in use——11434 被别的进程占了。这种情况不需要重装换个端口或者把占用的进程处理掉即可但 OpenClaw 那边的baseUrl也要跟着改。2.2 vmhgfs-fuse 挂载共享目录后的 /opt/ollama 权限坑用 VMware 共享目录传文件的同学对这段应该不陌生。vmhgfs-fuse挂上之后拷过去的文件默认挂载参数决定了权限常见是uid0,gid0但执行位丢失。表现就是ls看得见文件执行时报 Permission denied 或者 cannot execute binary file。处理顺序建议这样先ls -l看执行位缺了就chmod xchmod之后还不行检查文件系统是不是noexec挂载再不行就把文件从共享目录复制到本地磁盘比如/usr/local/bin再操作而不是直接在共享目录里执行。这一步能排掉一大半明明有文件却跑不起来的怪现象。2.3 ollama pull llama3.1:8b 之前的自检清单走到ollama pull llama3.1:8b这一步说明二进制已经能跑了。拉模型之前值得确认三件事ollama serve是否在跑、curl http://localhost:11434/api/tags有没有返回、磁盘剩余空间够不够8B 级别的模型加上量化几个 GB 是常态。这三项都过了pull还是卡住那就是下载环节的问题跟前面装二进制是两码事。很多人在这一步把整条链路推倒重来其实完全没必要。3. 决定绕开本机模型之前先想清楚谁提供模型3.1 去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 建一把 Key换云通道这件事第一步不是改配置文件而是先把凭证拿到手。打开 TaoToken注册账号之后进控制台创建一把 API Key。这把 Key 就是后面apiKey字段要填的值复制出来先放好别贴在聊天窗口里。这里要说清楚边界TaoToken 提供的是 Key 和 Base URL 两样东西它不负责让你的 Ubuntu 把 ollama 装上。本机模型环境那摊事该修还得修换上云通道之后OpenClaw 走的是另一条路跟 11434 没关系了。3.2 模型 ID 以模型广场当时列表为准拿到 Key 之后别忘了确认模型 ID。不同时间点上架的模型不一样写死在配置里的 ID 过一阵可能就下架了。正确做法是打开模型广场看当时列表里有哪些可用项挑一个复制它的 ID。不要凭记忆写gpt-4、claude-3这类通用名字也别自己加日期后缀。模型 ID 填错返回的往往是模型不存在跟 Key 无关但排查时特别容易误判成鉴权问题。4. 改 openclaw.jsonbaseUrl 从 localhost:11434 换成 https://taotoken.net/api4.1 动手前先备份只动两个值改之前先复制一份cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak。这个文件一旦改坏OpenClaw 启动阶段就会报解析错误界面上只给一句含糊的提示回滚成本远高于备份成本。这次需要动的只有两个值baseUrl从http://localhost:11434/v1改成https://taotoken.net/apiapiKey填上刚才创建的那把。其余字段——provider 名称、超时、代理设置、模型参数——原样保留。这里有个高频错误值得单独提Base URL 末尾不要带/v1。本机 ollama 的地址习惯性带/v1但换成统一通道之后https://taotoken.net/api就是完整前缀多写一段路径请求会打到不存在的路由上返回 404。4.2 一份可对照的 provider 片段下面这段只保留了这次要改的三个字段方便你对着自己文件里的位置改。不要整段覆盖你本地的配置。{ providers: { local: { baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY, model: YOUR_MODEL_ID } } }YOUR_API_KEY换成控制台里创建的那把 KeyYOUR_MODEL_ID换成模型广场上当时可用的那个 ID。改完保存重启 OpenClaw 的进程让配置生效。如果你的配置文件里 provider 是一个数组或者字段嵌套更深找到baseUrl那一行改值即可逻辑是一样的把指向本机 11434 的地址换成https://taotoken.net/api。4.3 18789 网关和 token 认证不需要改很多人改到一半会顺手把网关配置也动了这是多余动作。18789 是 OpenClaw 自己的服务端口跟模型从哪来没有关系。网关的 token 认证是保护你这个本地服务不被别人调用的也不受baseUrl影响。换句话说这次改动的影响半径很小只改了OpenClaw 往哪里要模型。你本地的访问方式、端口、鉴权规则全部照旧。如果你恰好也在用 Claude Code 这一类工具那边的接入方式是环境变量跟 OpenClaw 的 JSON 完全不是一回事别把两套配置混在一个文件里改。真要对照去看官方的接入文档更稳妥。5. 验证OpenClaw 是不是真把请求发出去了5.1 先用 curl 打一次 https://taotoken.net/api改完配置别急着开界面先用命令行确认通道本身是通的这样能把Key 或地址的问题和OpenClaw 的问题分开。curl -sS https://taotoken.net/api/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d {model:YOUR_MODEL_ID,messages:[{role:user,content:ping}]}返回里有正常内容说明 Key、模型 ID、地址三样都对上了。返回 401 是 Key 的问题返回 404 大概率是路径不对先检查https://taotoken.net/api后面有没有被多拼了/v1。注意 curl 里的地址就是接口地址不要带任何查询参数也不要加 UTM 之类的东西——那是给网页用的不是给接口用的。5.2 再看 OpenClaw 侧的日志回显curl 通了之后再启动 OpenClaw 发一条消息。如果界面正常出结果这次替换就完成了。如果界面还是报错但 curl 是通的那问题就在 OpenClaw 这一侧重点看三处配置有没有保存成功、进程有没有真正重启、日志里打出来的请求地址是不是https://taotoken.net/api。日志里如果还能看到localhost:11434说明配置没生效——多半是改错了文件或者环境变量把配置文件里的值覆盖了。OpenClaw 的配置优先级如果搞不清就先把环境变量里相关的项清掉再试。6. 排障对照401、404、连接被拒分别意味着什么6.1 401 多半是 Key 本身的问题401 说明请求打到了服务端但凭证没通过。按顺序检查Key 是不是完整复制的前后别带空格、是不是复制了别的项目的 Key、Key 在控制台里是否已被删除。还有一种隐蔽情况Key 是对的但请求头格式写错了。OpenClaw 的配置文件里通常只管apiKey字段请求头由它自己拼如果你是手写 curl 测试记得是Authorization: Bearer YOUR_API_KEY中间的 Bearer 和空格都不能少。6.2 404 往往是路径上多了 /v1从本机 ollama 迁过来的人最容易在这一步翻车。http://localhost:11434/v1里那个/v1是 ollama 的路径习惯换到统一通道之后不该带。配置里写成https://taotoken.net/api/v1或者让工具自动拼上/v1都可能得到 404。判断方法很直接把配置里的地址原样贴进 curl 试一次能不能通。通不了就是地址问题先把这个改对再谈别的。6.3 连接被拒说明请求根本没出本机如果报的是连接被拒绝或者超时而配置里明明写的是域名那先怀疑配置没生效。检查一下有没有其他地方还写着127.0.0.1:11434——比如环境变量、启动脚本、或者另一个配置文件的副本。还有一种可能是本机的出网策略限制这类问题跟 Key 和模型都无关需要在本机网络层面处理。7. 通道打通之后顺手把使用情况对一遍配置改完、消息能正常返回这件事就算收尾了。剩下两件小事值得顺手做掉。第一件用同一把 Key 在 TaoToken 模型对话 里发一条测试消息。网页端能通、OpenClaw 端也能通说明这把 Key 在两条路径上都正常以后再出问题就能快速定位是哪一侧。第二件回 控制台 API Keys 看一眼这次的调用有没有记上账。如果你打算长期让 OpenClaw 挂着跑Coding Plan 里能看清楚用量规模比等到超额才发现要划算。顺带提一句如果你同时还在用 Claude Code它的环境变量写法跟 OpenClaw 的 JSON 是两套东西对照 Claude Code 接入文档 单独配别混在一个文件里。最后回到 ollama。那条 GitHub 拖包、vmhgfs-fuse 挂载、chmod 改权限的路你什么时候想接着走都行它和 OpenClaw 现在这条通道互不干扰。真要继续修把zstd -t校验、noexec挂载、11434 端口占用这三项按顺序过一遍比反复重装有效得多。而 OpenClaw 这边baseUrl已经是https://taotoken.net/api只要 Key 在、模型 ID 对网关和认证就不用再动。
实践)
