记一次AI集群从零到全栈调通的血泪实录

wmjok

一、背景与初衷

近期在PVE环境下搭建一套AI自动化集群，核心架构是：

· Ollama 加载千问Qwen3-VL-4B视觉模型做本地推理（RTX 3060 12G显卡直通）
· OpenClaw（小龙虾） 负责实时战术响应和执行
· Hermes（黑莓） 负责离线战略分析和知识库生成
· 聊天室面板 作为多用户远程交互前端，支持与小龙虾和黑莓实时对话
· Tailscale虚拟组网 实现外网安全接入
· iStoreOS软路由 做端口转发和网络中转

核心设计要求：纯内网运行、关闭所有认证、服务按顺序启动、聊天室能同时对接两个AI。

这篇文章完整记录了从显卡驱动到服务调通每一步踩过的坑、判断思路和最终解决方案。这是一部血泪史，也是一份避坑手册。

二、基础环境：虚拟机与显卡直通

宿主机是PVE 9.1.1，E5-2680V4，32GB内存。虚拟机跑Ubuntu 22.04 LTS，分配12核24线程，20GB内存。

显卡直通配置本身算顺利。PVE宿主机关闭了nouveau开源驱动并加入黑名单，把NVIDIA 3060通过vfio-pci驱动绑定给虚拟机使用。几个关键操作：BIOS选OVMF（UEFI）、机型选q35、PCI设备直通时不勾选“主GPU”（因为这台虚拟机还要靠虚拟显卡显示，3060只做纯计算）、不勾选“全部功能”（避免把HDMI音频也直通过去）。

三、第一关：UEFI Secure Boot与NVIDIA驱动

Ubuntu系统下用 apt install nvidia-driver-535 安装驱动。过程本身没什么波折，但安装到一半弹出了UEFI Secure Boot的MOK密钥配置界面。

Ubuntu 22.04开启安全启动后，第三方驱动需要签个名才能加载。按照提示设了一个8位密码（系统要求最少8位），装完驱动重启后，虚拟机控制台出现蓝色背景的“Perform MOK management”界面。选择“Enroll MOK”→输入刚才的密码→确认→Reboot，驱动才真正生效。

四、第二关：Ollama与显卡的安装顺序——一个关键教训

驱动装好后，我兴冲冲地装了Ollama，拉取了模型 qwen3-vl:4b-thinking-q4_K_M。一切看起来正常，直到实际对话测试时发现模型响应奇慢。

排查：ollama ps 查看当前运行状态，PROCESSOR列显示 100% CPU。模型根本没用到显卡。执行 nvidia-smi 显卡信息正常，但Ollama就是不走GPU。

根因：Ollama在安装时会检测当前系统中的GPU环境。我先装了Ollama、后装显卡驱动，Ollama安装时没检测到GPU，就把自己配置成了纯CPU推理模式。这个配置一旦写定，即使后来装了驱动、重启了服务，它也不会自动切回GPU。网上不少人建议重装Ollama来解决问题，我就是这么干的。

最终方案：先装显卡驱动→重启→确认 nvidia-smi 正常→再装Ollama→再拉模型。重装之后立刻生效，模型推理从三十秒缩减到三到五秒。

教训：安装顺序决定最终效果。任何依赖GPU的服务，都必须先确认显卡驱动环境就绪，再安装服务本身。搞反了顺序，就得像我一样重装一遍。

五、第三关：服务启动冲突——改个配置文件引发的连锁崩溃

这是整个调试过程中最漫长、最痛苦的一关。

一切都始于一个简单需求：让小龙虾开启HTTP聊天接口，以便聊天室能调用。根据官方文档，在 openclaw.json 的 gateway 段里加了 httpEndpoints 配置。改完重启——两个服务开始互相冲突。

现象：要么只开一个，要么两个全关。Hermes反复崩溃重启，systemctl status 反复横跳于 active (running) 和 failed 之间。端口18789间歇性监听，curl 有时返回 Connection refused，有时返回 Empty reply。

排查过程：

第一步看日志，journalctl -u openclaw --no-pager -n 30 发现关键错误：

```
Config invalid
gateway: Unrecognized key: "httpEndpoints"
gateway.auth.mode: Invalid input
```

文档推荐 httpEndpoints 路径，但当前版本根本不认识这个字段。我把 auth.mode 设为了 "off"，而合法值是 "none"。两个错同时踩中。

第二步，用 sed 改配置，把 off 改成 none，把 endpoints 改成 httpEndpoints。重启后仍然失败。再次看日志，发现连 httpEndpoints 都不认了——说明这个版本可能根本就不支持通过配置文件开启HTTP API。但Gateway子进程已经起来了，端口18789已监听。

第三步，回滚备份。用 .bak 文件恢复原始配置。小龙虾恢复正常，但Hermes依然崩溃。新日志显示：

```
Error: connect ECONNREFUSED 127.0.0.1:18789
```

根因：启动时序问题。小龙虾的Gateway子进程需要几秒钟才能启动并监听端口，Hermes在这几秒内去连接就被拒绝。之前设的 sleep 20 固定等待不够灵活。

最终修复：放弃固定等待，改用端口检测循环。while true + curl 检测18789端口什么时候真正可用了，再启动Hermes。从此彻底告别时序冲突。

六、成果与心得

三个核心服务全部调通：Ollama（11434）、小龙虾（18789）、Hermes稳定在线。聊天室多频道对话正常，Tailscale外网访问畅通，NTFY图片推送实时显示。

核心经验：备份是第一生产力，改配置前先 .bak；日志是最好的医生，出问题先 journalctl；别全信官方文档，不同版本支持的配置字段可能完全不同；固定等待不如主动检测，while true + curl 替代盲目等待；安装顺序决定最终效果，依赖GPU的服务必须先确认驱动环境就绪。

调试AI集群，就是跟日志和配置文件死磕的过程。只要保持耐心，逐行排查，没有调不通的服务。