GLM-5是什么？架构、速度与API访问

我是 Dora。最近，GLM-5 不断出现在各种话题讨论和基准测试中，而我当时只是想完成一周正常的起草、规划和一些小型数据处理工作。当第三次看到它与”推理”和”智能体”并列提及时，我停下来认真看了看。不是因为我需要一个新模型，而是因为我现有的工具组合在处理较长任务时有时会拖慢节奏。如果换个模型能稍微减轻一些负担，我想亲自感受一下。

于是，我在 2026 年 2 月初的几个晚上，用GLM-5处理了桌面上实际发生的各种工作：杂乱的提示词、写到一半的大纲，以及那些从来不会保持不变的脚本。以下是我平静观察到的内容，没有任何夸张。

GLM-5 的背景——智谱的第五代模型

智谱 AI 已经发布 GLM 系列模型有一段时间了。如果你用过 GLM-3 或 GLM-4，你已经了解它的风格：扎实的多语言推理能力、良好的编程直觉，以及务实的特点——无需反复雕琢提示词，就能完成工作。

GLM-5 是他们的下一步。我将只讨论我能观察到的内容，以及智谱在公开资料中分享的信息。如果你想了解官方的表述，官方文档是一个很好的参考点：智谱 AI（GLM）文档以及智谱官网。

745B 总参数 / 44B 激活参数（MoE 架构）

最核心的细节在于架构。GLM-5 采用混合专家（MoE）架构：拥有大量”专家”池（据报道总参数约 745B），但每个 token 只激活其中一部分，平均约 44B。在实际使用中，这意味着我每天能感受到两件事：

首 token 延迟更接近 30–70B 的稠密模型，而非 700B 的庞然大物。我的提示词在开头不会像某些超大模型那样卡顿。
长文本的稳定性超出了我的预期。MoE 有时会出现游走现象，但 GLM-5 在多步骤大纲和代码重构中基本保持了连贯性，这一点我并没有视为理所当然。

我关心的不是参数数字本身，而是它能带来什么：激活计算量大到足以承载细微差别，而路由机制又将成本和速度控制在可接受的范围内。根据 Hugging Face 的 MoE 介绍，稀疏激活允许模型”扩展到数十亿甚至数万亿参数”，同时保持合理的推理成本。在一些较长的推理链（跨约 3–5 段的多跳分析）中，与较小的稠密模型相比，我注意到”遗忘性”跳跃明显减少。

核心升级：推理、编程、智能体、创意写作

与之前的 GLM 版本相比，我注意到的变化：

推理：思维链式结构（即使不主动要求）出现得更为频繁。我并不总是需要它逐字展示，但内在逻辑感觉更加稳定。当我要求它批判自己的计划时，它会进行调整，而不是表现出抵触或陷入循环。
编程：它对增量式编辑的处理优于整体重写。当我要求对脚本进行差异式修改时，它保留了上下文，而非重新打印所有内容。这节省了几分钟时间——虽然不多，但确实存在。
智能体行为：工具调用式任务（描述步骤、识别缺失输入、提出重试方案）的输出更加清晰。我不会让它在无人监管的情况下访问关键系统，但作为规划搭档，它表现得相当称职。
创意写作：语气控制有所改善。如果我设定了一种基调（“朴实、舒缓、温和”），它能在几页内保持这种风格。当需求混合了过多约束条件时，它仍然会出现偏差，但偏差程度较轻。

这些都感觉不到任何神奇之处。但它确实减少了我的提示词通常需要的心智负担。这在注意力匮乏的周二下午尤为重要。

推理速度概况——预期表现

我通过共享推理层而非智谱自己的控制台测试了 GLM-5，因此底层硬件可能有所不同。尽管如此，在三次测试（2026 年 2 月 6–9 日）中出现了一个规律：

首 token 延迟：在简短提示词上通常低于 1 秒；在包含多部分指令的较重、工具类请求上约为 1–2 秒。这个范围内，我不会失去思路。
持续吞吐量：在长篇回答中，我看到了稳定的流式输出，感觉在 30–60 tokens/秒的区间。在高负载下，它不会像某些 MoE 模型那样在段落中途停顿。
上下文稳定性：在约 8–16k tokens 时，输出保持连贯。在这些测试中，我没有挑战最大窗口，因为我的实际任务很少需要那么多。关于窗口大小的更多内容见常见问题。

延迟、吞吐量与成本的权衡

MoE 设计意味着你在以稠密模型的简单性换取一个路由层，理想情况下，这个路由层能在相同质量水平下通过速度/成本来回报自身。在实践中：

如果你关注快速来回（产品规格、邮件草稿、代码重构），GLM-5 的响应速度足以保持流畅状态。
如果你批量处理大型任务，吞吐量也能保持。对于非常长的文档，我仍然建议分块处理以避免重试。
成本取决于服务提供商。44B 的激活参数建议定价处于”大型但非超大型”区间。如果你当前的架构使用小型稠密模型处理快速任务，以及单一昂贵模型处理困难任务，GLM-5 或许能以更少的模型切换覆盖更多中间地带。

一条来自实战的笔记：我没有在”推理密集型”和”创意型”提示词之间看到明显的速度差异。某些模型在决定展开思考时会变慢，但 GLM-5 在两种情况下都保持了稳定的节奏。

如何通过 WaveSpeed API 访问 GLM-5

我通过 WaveSpeed 使用 GLM-5，该平台将多个提供商封装在一个与 OpenAI 兼容的接口后面。这里没有代码，只是我用通俗语言描述的操作步骤。

模型 ID、端点、认证设置

模型 ID：我在 WaveSpeed 模型目录中选择了标注为”glm-5”的模型。有些提供商会附加尺寸或路由标签，我选择了默认选项。
端点风格：该接口沿用了熟悉的 chat.completions 模式。如果你已经集成了任何类 OpenAI 的接口，替换通常只需修改 base URL 和模型字符串。
认证：在标准 Authorization 请求头中使用单个 API 密钥即可。我为每个项目设置了独立的密钥以保持日志整洁。速率限制会出现在响应头中，在调整并发时非常方便。

我的设置过程中有两条实用笔记：

Temperature 和 top_p 的表现符合预期，但在处理复杂提示词时，我通过适当降低 temperature（0.5–0.7）获得了更好的稳定性。这减少了游离现象，同时不会压平语气。
最大输出 token 数：默认上限较为保守。如果你的回答被截断，请尽早调高该值。这能节省重新运行的次数。

GLM-5 在行业格局中的位置（GPT-5、Claude 4.5、DeepSeek）

比较很容易变得嘈杂，所以我只讨论实际感受，而不是排行榜上的数字。

与 GPT 系列对比：GPT 家族在生态系统引力、插件、示例和社区代码片段方面仍然占优。在专注写作和逐步推理方面，GLM-5 表现相当。与我近期使用的某些 GPT 变体相比，它在长篇大纲中出现的格式怪异问题更少，处理增量代码编辑时也较少越界。
与 Claude 系列对比：Claude 模型往往更谨慎，擅长克制和摘要。GLM-5 在事实性改写上展现了同等的克制力，并且在未被要求的情况下，更愿意主动提出下一步建议。如果你喜爱 Claude 的语气和安全支架，在处理敏感内容时你可能仍然会偏好它。
与 DeepSeek 对比：我用过的 DeepSeek 模型感觉灵活且性价比高，非常适合高吞吐量任务。GLM-5 每次调用感觉更”重”，但在多跳分析上更稳定。如果你用大量小型查询轰炸一个模型，DeepSeek 在性价比上可能更胜一筹；对于更少但更深度的调用，GLM-5 对我来说更合适。

这些都没有对错之分，只是不同的默认选项。如果你已经深度绑定在某个生态系统中，切换的理由就比较薄弱。如果你在按任务混合使用模型，GLM-5 是”思考性工作”这个位置的有力候选者。

常见问题——可用性、定价、上下文窗口

可用性：GLM-5 可通过智谱平台及部分聚合商访问。如果你在中国境外，延迟和访问情况可能因提供商而异。我在 2026 年 2 月 6–9 日那周使用的是 WaveSpeed。
定价：因提供商而异。聚合商有自己的定价，供应商也会随时间调整。我避免引用容易过时的数字。在将任何东西部署到生产环境之前，请查看你的服务提供商的定价页面。
上下文窗口：在我的测试中，我没有触及上限。8–16k token 的工作区间是稳定的。如果你的工作流程依赖非常长的上下文（完整 PDF、转录文本），请在文档中确认硬性限制，并注意截断问题。
安全与内容审核：我看到了标准的护栏机制。在我澄清用途之前，它拒绝了一些模糊的请求。如果你的领域有严格的合规要求，请先进行小规模的策略审计。
适合谁：如果你需要更少的模型切换，并且在规划、分析和修订密集型写作上需要更稳定的输出，GLM-5 很适合。如果你追求超低成本、超快速度的微型任务，较小的稠密模型或 DeepSeek 风格的选项可能更适合你。

最后，来自我桌面的一点小感悟：我欣赏的并不是原始能力，而是不需要时刻盯着它。这不是什么大标题，但这种悄然的改进，在一周内会慢慢积累起来。