GLM-5在WaveSpeed上的推理速度：延迟与吞吐量

在起草一封入职邮件时，我想要快速得到回复。GLM-5 感觉很聪明，但第一个 token 出现的时间长到让我盯着光标发呆。不是什么大问题，只是一个不断重复的小停顿。这通常是我深入排查的信号。

在 WaveSpeedAI 上即刻可用 — 按 token 透明计费,OpenAI 兼容端点。 GLM 5.1 API → · 打开 Playground →

我是 Dora。我做了一组简单的测试，看看在不把工作流变成科学实验的前提下，能从 GLM-5 推理速度中榨取多少提升。没什么花哨的东西，只是足以在实际工作中感受到差异，而不是在实验室里。

测试方法（硬件、设置、提示词长度）

我尝试了三条访问路径：

• WaveSpeed：一个轻量级加速层，我一直在测试，它在客户端/网关侧处理请求整形和缓存。
• 直连 Z.ai API：通过服务商直接访问 GLM-5 的路由。
• OpenRouter：一个转发到模型服务商并附带一些额外功能的中间层。

硬件与上下文

• 本地客户端：MacBook Pro（M2 Max，64 GB RAM）。网络使用稳定的光纤（下行约 500 Mbps，到美国常见节点约 30 ms）。
• 服务器侧：没有自定义服务器，只是客户端调用。WaveSpeed 除外，它在本地运行一个小型网关来管理缓存和批处理整形。

保持不变的设置（除非特别说明）

• 模型：GLM-5（chat/completions），temperature 0.2，top_p 0.9，max_tokens 512。
• 流式传输开启，因为这是我实际的工作方式。
• 除网络错误外，重试关闭。

使用的提示词

• 短提示：60–80 个 token（带 2–3 个约束条件的简洁指令）。
• 中等提示：约 350 个 token（带品牌备注和示例的邮件草稿）。
• 长提示：约 1,500 个 token（包含产品背景、语气说明及注意事项的小型简报）。

每个条件下我运行了 25 次迭代，记录了：

• 首 token 时间（TTFT）：从发送请求到第一个流式 token 出现的时间。
• 吞吐量（tokens/s）：token 开始输出后的流式速率。
• “思考模式”开关（服务商的推理链路）。

关键指标

首 token 时间（TTFT）

短提示在良好路由下落在 250–400 ms 之间。中等提示将 TTFT 推近 450–700 ms。长提示超过一秒，除非缓存生效。增幅并非线性：感觉排队和验证开销与提示词长度同样重要。

我的感受：低于 400 ms 感觉流畅；超过一秒就会打断我的工作节奏。在实时编辑文案时，第一个 token 的出现比最终吞吐量更重要。

每秒 token 数（吞吐量）

流式传输开始后，非思考模式下我看到 35–70 tok/s。对于文案写作来说相当快，对于代码差异比较则勉强够用。较长输出的吞吐量有所下降，我怀疑这是服务器侧的整形和安全检查导致的，而非纯粹的模型速度问题。

思考模式 vs 非思考模式

开启”思考”模式后，TTFT 增加了 30–80%，某些情况下吞吐量减半。在复杂提示词上，输出文本更连贯，但对于日常起草工作，我并不需要它。刚开始这并没有节省时间，但跑了几次之后，我发现它减少了处理复杂编辑时的脑力消耗。简单任务上，我会关掉它。

WaveSpeed 加速如何应用于 GLM-5

WaveSpeed 没有触碰模型权重。它在我这侧做了两件简单而实用的事：减少冗余工作，并整形请求以便服务商能更快响应。在 GLM-5 上，这转化为重复提示词上更好的 TTFT，以及中等提示词上的小幅提升。

ParaAttention 与缓存技术

• ParaAttention（我的记录）：WaveSpeed 并非将不相关的请求打包，而是在检测到重复脚手架时，对单个长提示词内的注意力友好块进行并行处理。实际效果是复用了前导部分（系统提示 + 共享示例），只推送增量内容。我无法验证内部实现，但效果看起来像是网关层的部分 KV 复用。
• 缓存：它对提示词前导和短系统模板的嵌入进行了记忆化处理。当我在同一任务上做小改动迭代时，TTFT 下降了约 120–180 ms。冷启动提示词的收益较小（约 40 ms），但依然明显。

遇到的限制

• 第一次冷启动仍受上游约束，没有奇迹。
• 如果我修改了超过约 20% 的提示词，缓存就不起作用了。
• 思考模式基本上抵消了加速收益：推理链路表现得像一个独立的流。

对比：WaveSpeed vs 直连 Z.ai API vs OpenRouter

这就是细微差异体现价值的地方。

• 直连 Z.ai API：稳定。TTFT 方差最低。需要为演示提供可预测的响应时，这是我的首选。长提示词的 TTFT 惩罚真实存在，但很稳定。
• OpenRouter：平均 TTFT 略高，方差略大，但设置简单，路由灵活。在需要切换多个模型时很好用。文档扎实，参见 OpenRouter 指南。

• WaveSpeed 层：热提示词和中等输入上 TTFT 最优，可能源于缓存和请求整形。在真正冷启动的长提示词上，与直连打平。

这些都没有改变 GLM-5 的核心行为。它们改变的是我感受到模型”唤醒”的速度，以及迭代过程的流畅程度。

如果你在做选择：

• 需要稳定性能且减少复杂环节？通过服务商直连。参考：ZhipuAI API 文档。
• 需要多模型路由或跨工具共享密钥？OpenRouter 没问题，接受多花几毫秒。
• 整天在相似提示词上迭代？轻量级加速层带来的心理平静感比纯粹的速度提升更有价值。

生产工作负载的优化技巧

实际有效的做法：

• 预热前导：保持系统提示和共享示例稳定。缓存它们，哪怕只在客户端侧。我的 TTFT 节省：重复请求上约 100–200 ms。
• 裁剪尾部：将 max_tokens 限制在真正需要的值。将 1,000 token 上限削减到 400，我的草稿总时间缩短了 10–20%。
• 优先使用结构化重试：如果必须重试，恢复流式传输，而不是重新开始。盲目重试会拖慢 TTFT。
• 控制可变性：生产环境中 temperature ≤0.3。较低的熵减少了服务器处理次数，使吞吐量更稳定。
• 延迟使用思考模式：仅在历史上容易出错的提示词上启用。我会标记”难提示词”并按路由切换该标志。
• 在上游分块长上下文：一次性对参考资料进行摘要，存储摘要后复用。第二次和第三次运行感觉明显更轻松。
• 注意分词差异：不同 SDK 的分词方式略有不同。锁定客户端并重新测量——仅这一点我就遇到了假性回归。
• 关注 p95，而非仅 p50：毛刺尾延迟才是用户记得的可见卡顿。

原始基准数据（表格）

这是我测试的快照（每行 25 次迭代）。所有数字均为近似值，但能代表我在键盘前的真实感受。

备注

• “热前导”指系统提示和共享示例已被网关缓存。
• 吞吐量从第一个 token 之后开始计算。总时间 = TTFT + 输出 token 数 / 吞吐量。
• 网络状态稳定：当我在酒店 Wi-Fi 上测试时，所有数字都会差 10–20%。

最后一点观察：将 TTFT 缩短 150 ms 对我来说比提升 5 tok/s 更有意义，因为它减少了触发思维切换的那个小等待。这不是普遍规律，只是我的大脑处理流式输出的方式。