把 GLM4.7 接入 Hermes Agent 的踩坑全记录：NVIDIA NIM 免费层的隐藏限制
起因
在 Reddit 的 r/ZaiGLM 社区看到一个帖子：GLM-5.1 已经上线 NVIDIA NIM API，开发阶段免费可用。
GLM-5.1 是智谱（Z.ai）的旗舰大模型，参数量 754B，专为 agentic engineering 设计，强调编码和长程规划能力。NVIDIA NIM 提供 OpenAI 兼容的 API 接口，意味着原则上可以无缝接入任何支持 OpenAI 格式的工具链。
我日常用 Hermes Agent 作为主力 AI 助手，它支持自定义base_url和provider，理论上能接入任意 OpenAI 兼容端点。于是产生了一个想法：把 GLM4.7 配置为 Hermes 的主模型，免费跑一个本地 AI 工作流。
结果踩了一路坑，最终失败——但过程中发现的每个问题都很有参考价值。
第一步：验证 API Key 和模型可用性
首先确认 NVIDIA NIM 上线了哪些 GLM 模型：
curl-s"https://integrate.api.nvidia.com/v1/models"\-H"Authorization: Bearer$NVIDIA_API_KEY"|python3-c" import json, sys d = json.load(sys.stdin) for m in d['data']: if 'glm' in m['id'].lower() or 'z-ai' in m['id'].lower(): print(m['id']) "输出：
z-ai/glm-5.1 z-ai/glm5 z-ai/glm4.7三个 GLM 模型都已上架。接下来逐个测试连通性：
GLM-5.1（754B）：请求发出后持续挂起，30 秒超时，无任何响应。
GLM5：同样超时，无响应。
GLM4.7：
curl-s-m30-XPOST"https://integrate.api.nvidia.com/v1/chat/completions"\-H"Authorization: Bearer$NVIDIA_API_KEY"\-H"Content-Type: application/json"\-d'{"model":"z-ai/glm4.7","messages":[{"role":"user","content":"你好"}],"max_tokens":200}'返回了完整响应，finish_reason: stop，completion_tokens: 229。
结论：GLM-5.1 和 GLM5 在 NVIDIA NIM 上属于"上架但未激活"状态，实例没有运行。GLM4.7 完全可用，响应时间约 2 秒。
第二步：配置 Hermes Agent
Hermes 支持通过config.yaml配置自定义推理端点。理论上只需要三个参数：
model:default:z-ai/glm4.7provider:custombase_url:https://integrate.api.nvidia.com/v1加上 API Key，应该就能跑起来。
坑 1：api_key_env字段在 custom provider 下不生效
Hermes 的model.api_key_env配置项实际上属于smart_model_routing模块，不是custom provider 的标准认证字段。
hermes configsetmodel.api_key_env"NVIDIA_API_KEY"# 看似写进去了，实际上 custom provider 根本不读这个字段表现：启动时报 HTTP 401 Unauthorized。
坑 2：z-aiprovider 有复杂的端点探测逻辑
尝试把 provider 改成z-ai（Hermes 内置的 GLM 原生 provider），然后通过GLM_BASE_URL环境变量覆盖端点：
exportGLM_BASE_URL=https://integrate.api.nvidia.com/v1exportGLM_API_KEY=$NVIDIA_API_KEY但z-aiprovider 内置了端点探测（detect_zai_endpoint）和 API key hash 缓存机制，会忽略GLM_BASE_URL进行自动探测，探测结果写回auth.json，覆盖了手动配置。
结果：仍然 401，或者请求发到了 Z.ai 官方端点而不是 NVIDIA。
坑 3：写明文 api_key 到 config.yaml（安全问题）
为了绕过 env var 读取问题，临时测试用hermes config set model.api_key "nvapi-xxx"直接写入。
这个方式技术上有效，但：
- 明文 key 会出现在
config.yaml中，存在泄露风险 - key 会在 verbose 日志中被打印出来
发现后立即清除：
hermes configsetmodel.api_key""正确做法：把 NVIDIA key 写入~/.hermes/.env并命名为OPENAI_API_KEY，因为 custom provider fallback 读的是这个变量：
# hermes_cli/config.py"api_key":"",# API key for base_url (falls back to OPENAI_API_KEY)坑 4：401 终于解决，但出现"Response remained truncated"
设置OPENAI_API_KEY=<nvidia_key>后，401 消失了。但每次调用都报：
↻ Requesting continuation (1/3)... ↻ Requesting continuation (2/3)... Error: Response remained truncated after 3 continuation attempts第三步：找到根本原因
开启 verbose 模式，看实际的 token 使用情况：
hermes chat-q"hi"-v2>&1|grep"token\|completion\|finish"输出：
📊 Request size: 2 messages, ~4,429 tokens (~17,716 chars) API Response - completion_tokens=32, prompt_tokens=13469, total_tokens=13501 ⚠️ Response truncated (finish_reason='length') - model hit max output tokens关键数字：completion_tokens=32。
不管model.max_tokens设成多少（试过 4096、8192、16000），每次响应都只有 32 个 completion token，然后触发finish_reason=length，Hermes 反复重试，最终失败。
对比直接 curl：
curl...-d'{"model":"z-ai/glm4.7","messages":[{"role":"user","content":"hi"}],"max_tokens":500}'# completion_tokens=229, finish_reason=stop ✅ 正常直接调用完全正常，通过 Hermes 就只有 32 tokens。
差异在哪？prompt_tokens: 13469——Hermes 系统 Prompt 本身就有 13,469 个 token。
Hermes 系统 Prompt 的构成
Hermes Agent 在每次对话时，会把以下内容打包进系统 Prompt：
- 所有已安装 skill 的名称 + 描述（~50 个 skills）
- 所有可用工具的 schema（~30 个工具，每个带参数描述）
- 用户记忆（memory）
- 用户画像（user profile）
- 时间、平台等上下文信息
这些加在一起，在我的配置下达到了13,469 tokens。
NVIDIA NIM 免费层的实际限制
NVIDIA NIM 的文档标注了"免费用于开发和原型"，但没有明确说 per-request 的 token 上限。
实测发现：GLM4.7 免费层的总 context 上限约13,500 tokens。
| 分配 | Token 数量 |
|---|---|
| Hermes 系统 Prompt | 13,469 |
| 实际可用 completion | ~32 |
Hermes 的系统 Prompt 把窗口塞满，模型只剩 32 个 token 用来回答——这就是为什么不管问什么，都只能挤出几个字就被截断。
对比：为什么直接 curl 没问题？
直接调用时，Prompt 只有一句"hi"，约 13 tokens，completion 有完整的 ~500 tokens 可用。
Hermes 调用时，系统 Prompt 13K+，model 只剩 32 tokens 喘息空间。
不是 GLM4.7 的问题，不是 API Key 的问题，不是 Hermes 的 bug——是 NVIDIA NIM 免费层的 context 窗口太小，装不下一个全功能 AI agent 的系统 Prompt。
尝试的解法与结果
方案 1：调小model.context_length
hermes configsetmodel.context_length16000结果：Hermes 拒绝启动，要求最低 64K context。
方案 2：调大model.max_tokens
从 4096 → 8192 → 16000，completion tokens 始终是 32，受服务端限制，客户端无法突破。
方案 3：禁用部分 toolsets 减小系统 Prompt
理论上可行，但 Hermes 系统 Prompt 的大头是工具 schema，即使只保留最基础的工具，也难以把 prompt 压到 13K 以下。
最终结论
| 场景 | 可用性 |
|---|---|
| 直接用 Python/curl 调 GLM4.7 | ✅ 完全可用，响应正常 |
| 接入轻量脚本或自写工具链 | ✅ 完全可用 |
| 作为 Hermes Agent 主模型 | ❌ 系统 Prompt 超出 NIM 免费层 context 限制 |
| GLM-5.1 / GLM5 | ❌ 上架但实例未激活，请求超时 |
GLM4.7 本身能力没问题，NVIDIA NIM 的免费额度也是真实有效的。但对于像 Hermes 这样系统 Prompt 较重的 Agent 框架，NVIDIA NIM 免费层约 13,500 tokens 的 context 窗口根本不够用。
实用建议
如果你只是想用 GLM4.7 写脚本、做测试：
fromopenaiimportOpenAI client=OpenAI(api_key="nvapi-xxx",base_url="https://integrate.api.nvidia.com/v1")resp=client.chat.completions.create(model="z-ai/glm4.7",messages=[{"role":"user","content":"你的问题"}],max_tokens=800# 推理模型需要多一些，thinking 会占用部分 token)# GLM4.7 是推理模型，回答在 content 字段，思维链在 reasoning_contentprint(resp.choices[0].message.content)如果你想把 GLM 系列接入 Agent 框架：
- 确认框架的系统 Prompt 大小，NVIDIA NIM 免费层约 13K context，大型 Agent 框架基本都会超
- 考虑使用 Z.ai 官方 API（
api.z.ai），context 限制更宽松 - 或者等 NVIDIA NIM 提升免费层限制，GLM-5.1 正式激活后重新测试
这次集成虽然没有成功，但把 NVIDIA NIM 的隐藏限制挖了出来。对于想用免费 GPU 云跑 GLM 系列的开发者，希望这篇踩坑记录能节省你几个小时的调试时间。
