速度优化

觉得 GLM 响应慢？先区分两种「慢」：

• 首 Token 慢（发出请求到收到第一个字）——多半和缓存命中率、输入量、上下文长度、客户端、高峰算力有关，这部分你能优化。
• 生成速度慢（吐字速度）——取决于模型本身的生成速率与思考强度，优化空间在「换模型 / 调强度」。

本文分两部分：前半讲如何优化首 Token（一六），后半讲生成速度相关（七九，含模型选择）。

#一、提高缓存命中率（最关键）

#原因

GLM 系列对前缀复用做了强缓存：当本次请求的前缀（系统提示、历史消息、工具定义等）与之前某次请求完全一致时，智谱侧会直接命中缓存、跳过重新计算这部分上下文，首 Token 因此大幅缩短。

反之，一旦前缀有任何一个 token 不同，缓存就无法命中，模型需要重新计算全部上下文，首 Token 会明显变长——这正是「同一会话里有时快有时慢」「新会话慢」的根因。

#排查步骤

1. 看控制台的缓存读取量：在 LINDE AI 的请求日志里查看 Cache Read（缓存读取）的 Token 数。命中率高时，输入 Token 里很大一部分会落在 Cache Read 列；命中率低时该列接近 0。
2. 对比「同会话续聊」与「新会话首句」：同一会话里连续多轮通常稳定命中缓存（快）；新开会话的第一句话由于无历史前缀可复用，必然 miss（慢），这是正常现象。
3. 确认前缀是否被破坏：排查系统提示、工具定义、历史消息是否在每轮请求里被客户端整体改写（顺序变动、字段增删、重新序列化）。

#检查

• 命中率高：首 Token 通常在 几百毫秒 ~ 5 秒。
• 命中率低 / 新会话首句：首 Token 可能达到 10 ~ 20+ 秒。

如果你的常态是后者，请重点排查下面三节：输入量、上下文长度、客户端选择与插件篡改。

#二、减少输入 Token 量

首 Token 的等待时间，和输入的 Token 数量直接相关——模型要先读完你的全部上下文才能开始产出，输入越长，首 Token 越慢。除了靠缓存命中复用前缀，主动减少每次请求的输入量同样有效。

输入端的 Token 越精简，留给缓存复用与推理的空间就越大，首 Token 与整体响应都会更轻快。这和缓存命中率是相辅相成的两件事：一个管「复用」，一个管「减量」。

#三、控制上下文长度（编码场景的关键）

「减少输入 Token」讲的是每一轮请求的瞬时输入量，而「上下文长度」讲的是整段会话累计的上下文规模——两者都会直接抬升首 Token。会话越长，模型每次回复前都要重新处理整段历史，首 Token 随之拉长。因此，除了压缩单次输入，还要主动控制会话的整体上下文长度。

GLM-5.3 / GLM-5.2 支持最高 1M（100 万）Token 的上下文窗口，这对编码场景听起来很诱人，但实际并非越大越好：

把上下文控制在「够用就好」的区间，是编码场景里性价比最高的一项提速手段——既压低首 Token，又抑制幻觉，还能省下可观的 Token 消耗。

#四、选对客户端

不同客户端对缓存上下文的管理能力差异巨大，直接影响你的缓存命中率：

• 缓存管理出色：Claude Code、Codex。它们的上下文组织稳定，前缀复用率高，缓存命中表现最好。
• 缓存管理一般：ZCode、OpenCode。这两者的缓存策略相对固定，命中率不如上述两者。
• 缓存率很低：Hermes、OpenClaw。它们的上下文经常在客户端侧被重新组织或更换，前缀难以稳定复用，导致缓存命中率低、首 Token 偏长。

#五、排查插件篡改上下文（重点：记忆类插件）

除了客户端本身，你为客户端安装的个别插件也可能在请求发出前修改、注入或重排上下文，破坏前缀一致性、降低缓存命中率，间接拉长首 Token。

#排查方法

1. 优先禁用记忆类插件：逐个临时关闭 memory / 记忆 / 自动摘要类插件，观察首 Token 与缓存读取量是否回升。
2. 再查其他改写类插件：任何会自动改写系统提示、注入规则、整理或重排历史消息的插件，同样会破坏前缀。
3. 对比命中前后：找到可疑插件后停用或调整其行为，在控制台对比禁用前后的 Cache Read 数值变化。

#六、Claude Code 缓存优化代理（可选）

claude-code-cache-fix 是一个第三方开源代理工具，通过优化请求结构和缓存标记，帮 Claude Code 提高缓存命中率、减少额度消耗。

#安装并启动代理

npm install -g claude-code-cache-fix
CACHE_FIX_PROXY_UPSTREAM=https://ai.lindecdn.com cache-fix-proxy server

#配置

编辑 ~/.claude/settings.json，将 ANTHROPIC_BASE_URL 指向本地代理：

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://127.0.0.1:9801",
    "ANTHROPIC_AUTH_TOKEN": "placeholder",
    "CLAUDE_CODE_ATTRIBUTION_HEADER": "0",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
    "CLAUDE_CODE_DISABLE_TERMINAL_TITLE": "1"
  }
}

#验证

另开终端检查代理状态：

curl http://127.0.0.1:9801/health

返回 {"status":"ok"} 后，运行 claude 能正常对话即配置成功。

#后台常驻

手动启动只适合临时验证。长期使用建议配置为系统服务（Linux 用 systemd，macOS 用 launchd），避免每次手动启动。具体配置方式可以参考 项目 README 或让 AI 根据你的系统生成。

#七、高峰期与算力上限

LINDE AI 使用的是智谱的高等级账户，请求会被优先处理。但即便如此，仍然受制于智谱侧的算力上限与高峰期速度压制——这部分是上游因素，任何中转都无法绕过。

• 每日高峰：北京时间 14:00 - 18:00（实际感知可能持续到 20:00 左右）。
• 高峰期表现：容易出现 429（限流），且首 Token 的实际等待时间会明显增加。

#八、生成速度是流式透传

前六节都在优化首 Token。如果你觉得慢的是「吐字速度」（首 Token 已到，但后续字蹦得很慢），那是另一回事——从这节起聊聊生成速度。

真正会拉开差距的是首 Token（受缓存与算力影响），而非生成速率。把缓存命中率提上去、避开高峰，是优化首 Token 体验最有效的两件事。

#九、合理控制思考强度

思考（thinking）会显著影响首 Token 与生成速度：模型在产出答案前先进行内部推理，思考越深，等待越久。对 GLM-5.3 / GLM-5.2 而言，思考不只是开/关，还能调强度。

LINDE AI 在 OpenAI 兼容接口默认开启了思考。若需调整强度或关闭思考，可在支持自定义参数的客户端里设置 reasoning_effort 或 thinking.type = disabled。

#十、GLM-5.3 / GLM-5.2 的生成速度与模型选择

即使缓存命中、避开高峰、生成速度流式透传，模型本身的生成速率仍是一个硬上限——而 GLM-5.3 / GLM-5.2 的生成速度本身并不快。

• 智谱官方 GLM-5.3 / GLM-5.2 的吐字速度并不稳定：有时约 100 token/s，有时只有 40 ~ 60 token/s，随上游负载波动。
• 这是旗舰推理模型的固有取舍——它把算力倾注在推理质量上，吐字速度不是它的强项。