Hermes 接进 Ollama：本地跑 Gemma4:26B，Token 自由这件事
用 Hermes 跑了这么久，一直有一个遗憾：每次让它帮我处理复杂任务，都要走 API，都要烧 Token。尤其是让它帮我做一些需要反复对话才能完成的事情时，看着 Token 消耗曲线往上走，心里总是有点不踏实。
这个问题在本地模型工具成熟之后，开始出现转机。Ollama 就是这个转机里最值得关注的一个选项——它可以把大模型跑在本地，不需要任何外部 API，不需要注册任何 key，直接在局域网内就能调用。
所以我花了一点时间，把 Hermes 和 Ollama 之间的通路打通。跑通之后，Token 消耗变成了零，但模型能力没有打折。这篇文章，就是把整个过程完整记录下来。以 Gemma4:26B 为例，从零开始讲清楚怎么配、怎么验证、以及这件事为什么值得做。
一、为什么选 Ollama，而不是自己起模型服务
在真正动手之前，其实我对比过几种本地推理方案：
自己起 vLLM / llama.cpp：能力很强，但需要自己管理模型文件、量化参数、端口、API 路由，学习成本不低。
Ollama：一条命令拉起模型，一条命令调用推理，API 风格和 OpenAI 完全兼容。Hermes 只需要换一个 base_url，就能直接接入。
也就是说，Ollama 等于是一个零配置版的本地 OpenAI 兼容 API。这对 Hermes 这类已经按 OpenAI 风格封装好的 Agent 来说，是最自然的接入方式。
二、最小链路只有三步
把 Hermes 接入 Ollama，实际跑下来，最核心的链路只需要三步：
第一步：安装并启动 Ollama
# 安装（Linux/macOS）
curl -fsSL https://ollama.com/install.sh | sh
# 拉取 Gemma4:26B
ollama pull gemma4:26b
# 启动服务（默认 11434 端口）
ollama serve第二步：在 Hermes 配置里添加 provider
Hermes 的配置文件在 ~/.hermes/config.yaml，只需要在 model_aliases 下加一段：
model_aliases:
# 已有配置...
gemma26:
model: gemma4:26b
provider: custom
base_url: http://192.168.11.8:11434/v1这里 192.168.11.8 是我局域网内跑了 Ollama 的机器 IP。如果你在同一台机器上跑，替换成 localhost 或 127.0.0.1 即可。
第三步：验证连通性
在 Hermes 里直接发起一次对话测试：
/ask gemma26 请用三句话解释量子纠缠如果正常返回结果，说明链路已经打通。
三、用 gemma4:26B 能做什么
Gemma4:26B 是 Google 放出来的开源大模型，26B 参数量在本地算力条件下是可以跑起来的规模。接入 Hermes 之后，可以让它：
-
帮我分析长文档：直接把 PDF 或文本丢给它，不用上传到任何第三方
-
做代码审查：本地跑编程模型，代码不离开本机
-
复杂任务推理：需要多轮思考的问题，本地模型随便问，不烧 Token
-
充当知识库后端：配合向量数据库，本地做一个完全私有的问答系统
关键是，这些操作全程不需要访问任何外部 API，Token 成本为零。
四、实测：同一段对话，本地 vs API 差距有多大
我做了一个简单的对比测试：让同一个问题经过两条不同的推理链路，看输出质量是否有明显差异。
测试问题：一家 SaaS 公司想通过 AI 提升客服效率，但不放心把客户对话数据交给第三方服务商。有哪些本地化方案可以推荐？
API 模式（MiniMax-M2.7）：响应流畅，推理速度快。
本地模式（gemma4:26B via Ollama）：推理耗时更长（约 3–5 秒），但回答的深度和细节明显更丰富，对本地场景的适配性更强。
两条链路的结论方向一致，但本地模型的回答更偏向"可落地执行"，这跟模型本身的训练和规模有关，也跟本地推理没有延迟压力、不会为了"快速返回"而压缩输出有关。
五、最容易踩的三个坑
坑一：IP 写错了
Ollama 默认只监听本地（127.0.0.1），如果你从另一台机器访问，需要修改 Ollama 的绑定地址：
OLLAMA_HOST=0.0.0.0 ollama serve坑二：模型没拉下来就急着测试
ollama serve 启动成功不代表模型已经就绪。需要先 ollama pull gemma4:26b，等它把模型文件下载完，再开始调用。
坑三：Hermes 没有重启
修改 config.yaml 之后，需要重启 Hermes 的 gateway 让配置生效。
六、这条路打通之后，工作流发生了哪些变化
接入 Ollama 之前，Hermes 帮我做事情，每次都有"这个会不会又多烧了我几个 Token"的顾虑。
接入之后，这个顾虑消失了。本地模型随便用，不花钱，不审查，不限速。
这带来的实际变化是：我更愿意让它帮我做那些需要反复尝试、多次对话才能完成的任务了。以前会想说"算了，这个问题不麻烦它了，自己想一下"，现在直接丢给本地模型，答案不满意就再问一轮，完全没有心理负担。
另一个实际变化是数据安全。有些内容我不想经过任何第三方 API，本地模型可以完全在防火墙内完成推理，这对于处理内部文档、商业数据等敏感内容尤为重要。
七、这条路还能继续往哪里延伸
接入 Ollama 只是第一步。顺着这条路，有几个方向其实已经可以继续往前推：
方向一：多模型切换
在 config.yaml 里配置多个 model_alias，Ollama 上可以同时跑好几个模型。不同任务用不同的本地模型，不需要每次都切换 API Key。
方向二：量化版降门槛
如果你的机器显存不够跑 FP16 的 Gemma4:26B，可以拉量化版（如 Q4_K_M），显存需求可以从 26GB 降到 16GB 左右，效果损失在可接受范围内。
方向三：本地向量数据库 + 本地大模型
把 Ollama 和向量数据库（如 Qdrant、Chroma）结合起来，就可以在本地搭建一个完全私有的 RAG 系统，文档不用上传，问答不经过任何第三方。
结语
接入 Ollama 这件事，技术上并不复杂，核心价值也不在于"省了多少 Token"。
真正的价值在于：它让 Hermes 的能力边界，变得更宽了。
以前会因为成本顾虑而犹豫让它做的事，现在可以毫无负担地交给本地模型。以前不敢让它碰的敏感内容，现在可以放在本地处理。这些变化加在一起，才是真正值得折腾这条链路的理由。
Token 自由只是结果，不是目的。目的是让你在用 AI 帮你做事的时候，少一层顾虑，多一层底气。
配图说明：封面、图1~图5均为原创配图，版权所有：虾米AI派，禁止转载。