为GLM-5.2打造世界最快API

GLM-5.2 是自 DeepSeek-R1 以来开源模型领域最大的新闻。

科技领袖们将 GLM-5.2 视为开源模型前沿智能的新标杆。

原因显而易见。GLM-5.2 以极低的成本提供了与 GPT 5.5 和 Opus 4.8 相当的性能，在纯 Token 计费基础上通常便宜 70-80%（使用我们的计算器估算你工作负载的节省）。

但一个模型不仅需要聪明且廉价。要在生产环境中发挥作用，模型还需要快速、可靠，并且能够大规模部署。实现前沿开源智能的承诺需要卓越的推理能力。

因此，我们为 GLM-5.2 构建了全球最快的 API，根据 Artificial Analysis 的测量，目前每秒可处理超过 280 个 Token。

GLM-5.2 在 Baseten 模型 API 上以 SOTA 速度运行，数据由 Artificial Analysis 于 2026 年 6 月 22 日测量。

我们通过在整个推理过程中运用多种技术实现了这一性能，具体包括：

• 更新我们的自定义推理引擎，为 GLM-5.2 架构实现共享 DSA。
• 从原始 FP8 权重进行内部 NVFP4 量化并校准，在 BFCL 等代理基准测试中展现出等同的质量。
• 通过使用 NVIDIA Dynamo 工具构建的 KV 感知路由确保高 KV 缓存命中率，从而降低预填充负担，并改善具有重复前缀请求的首 Token 生成时间 (TTFT)。
• 通过使用 NVIDIA Dynamo 工具包构建的分离式推理，针对观察到的负载形状实现了 2 倍的 TPS 提升。
• 通过为 GLM-5.2 的多头 Token 预测头添加支持，利用推测解码进一步提升 TPS。

你可以通过 Baseten 模型 API 上的 GLM-5.2 亲身体验这一性能。我们还提供 GLM-5.2 的专用部署，适用于高吞吐量工作负载。

Notion 通过 Baseten 提供 GLM-5.2。

GLM-5.2 概述

Z.ai 的 GLM-5.2 是一个 744B 参数的前沿 LLM，擅长代理任务（尤其是编码），并支持高达 100 万 Token 的上下文窗口。它采用与其前身 GLM-5.1 相似的架构：混合专家（40B 活跃参数）、非思考和思考模式，以及完全开源 MIT 许可证。虽然 GLM-5.2 与 GLM-5.1 有很多共同点，但现在它使用了共享 DSA 权重，我们在自定义运行时引擎中为其提供了支持。

GLM-5.2 在各项任务中展现出前沿性能。图片来自 Z AI。

GLM-5.2 拥有出色的基准测试分数，但如今 AI 构建者都知道，模型的价值不仅取决于其在标准评估中的表现。在实践中，GLM-5.2 达到甚至超越了其基准分数所暗示的能力。对于编写代码、运行代理以及其他前沿语言模型任务来说，它是一个真正优秀的模型。

为 Blackwell GPU 提供的高质量 NVFP4 量化

我们在 NVIDIA Blackwell GPU 上运行模型 API，使用 Baseten 推理堆栈 内的自定义推理引擎。所选的运行时使用 NVFP4 权重以实现最高性能。我们从原始 FP8 权重出发，使用 NVIDIA ModelOpt 在内部量化至 NVFP4。NVFP4 是 NVIDIA 的一种 4 位浮点数据格式，利用双缩放因子保持高动态范围并保留模型质量。

在对量化模型进行校准和测试时，我们专注于确保 GLM-5.2 在常见的代理模式中表现可靠。在 BFCL 函数调用基准测试中，我们观察到原生 FP8 权重与我们的 NVFP4 量化性能大致相当，各次运行得分均在基准测试的误差范围内。

NVFP4 量化通过解锁更快的张量核心并减轻 VRAM 带宽负担，同时提升了首 Token 生成时间 (TTFT) 和每秒 Token 数 (TPS) 的性能。

TTFT 和 TPS 性能均表现优异，数据由 Artificial Analysis 于 2026 年 6 月 22 日测量。

利用 NVIDIA Dynamo 实现缓存感知路由

GLM-5.2 特别适合长上下文请求和复杂的代理任务。这些工作负载通常具有非常长的输入序列。通过在请求之间重用 KV 缓存，我们可以跳过共享序列的昂贵预填充。

我们通常在首 Token 生成时间 (TTFT) 的背景下讨论 KV 缓存重用。然而，像 GLM-5.2 这样的推理模型更关心首个答案 Token 生成时间 (TTFAT)，它结合了 TTFT 和推理序列的 TPS 开销。

GLM-5.2 的首个答案 Token 生成时间，由 Artificial Analysis 于 2026 年 6 月 22 日测量。

此图表显示，生成首个答案 Token 的平均 7.9 秒中，有 7.1 秒用于生成推理 Token，而仅 0.8 秒用于处理输入序列。

尽管如此，将 TTFT 降低到 800 毫秒对于系统的整体响应速度和吞吐量仍然很重要。在大规模生产部署中，KV 缓存在各个独立副本之间共享。我们使用 NVIDIA Dynamo 中的工具来路由传入请求。

KV 感知路由将请求发送到已缓存相关上下文的副本，从而避免冗余的预填充计算，节省时间。

多租户 API 上的精确缓存命中率取决于任何给定时间的确切流量模式。到目前为止，我们在相当异构的流量中观察到了高命中率，这减轻了预填充的负载，并提升了端到端性能。

利用 NVIDIA Dynamo 实现预填充-解码分离

我们对 GLM-5.2 性能进行的最具影响力的优化之一是分离预填充和解码。

LLM 推理有两个不同的阶段：

• 预填充：处理输入序列、构建 KV 缓存并生成第一个输出 Token 的计算密集型过程。预填充性能决定了 TTFT。
• 解码：生成后续输出 Token 的内存密集型过程。解码性能决定了 TPS。

传统上，单个 GPU 节点同时处理预填充和解码。通过分离，这些工作负载在独立的引擎上运行。这带来了几个好处：

• 预填充和解码独立运行，无需争夺资源。
• 我们可以根据需要为预填充和解码分配不同的资源（通常，我们配置的预填充引擎多于解码引擎）。
• 运行预填充和解码的推理引擎可以采用针对推理管道特定部分需求优化的不同配置。
• 只要可能，KV 缓存仍会被重用，这意味着预填充工作节点仅用于处理新的输入序列。

分离式推理使用独立的预填充和解码工作节点。

实现 PD 分离的主要挑战在于预填充引擎和解码引擎之间可靠、低开销的通信和编排。NVIDIA Dynamo 提供了一个开发者工具包，用于实现分离式推理的关键组件：

• 一个预填充队列，用于在所有预填充引擎饱和时暂存请求。
• 对条件分离的稳健支持，考虑前缀缓存和预填充队列大小之后，基于可配置的输入序列长度阈值进行预填充路由。
• 基于 NIXL 的高效 KV 传输，从预填充引擎传输到解码引擎，并包含一个内核，当引擎具有不同 TP 配置时，在布局之间转置 KV 块。

在对 GLM-5.2 的聚合部署和分离部署进行的直接基准测试中，我们观察到分离式推理的每秒 Token 数 (TPS) 提高了 2 倍。

通过多头 Token 预测实现更高 TPS

GLM-5.2 配备了改进的多头 Token 预测（MTP）层，降低了生成草稿 Token 的成本，并提高了这些 Token 的接受率。

回顾一下，MTP 是几种推测解码方法之一。推测解码是在模型单次前向传播中生成多于一个 Token 的过程，旨在提高 TPS。得益于所有算法中的验证步骤，推测方法是无损的性能优化。

使用这些 MTP 层生成草稿 Token，我们测试了各种序列长度，以在生成长序列和保持高接受率之间找到适当平衡。过去几个月，我们在 MTP 方面做了大量工作，对于我们在 GLM-5.2 中使用的推测解码，仍有继续优化的空间。

在生产环境中运行 GLM-5.2

看到此类基准测试结果时，自然会问是否能在生产环境中保持同样的性能。

事实上，我们不仅能在生产中提供这种性能，还能为 GLM-5.2 的大规模专用部署实现更佳的特定工作负载性能。可用的手段包括：

• 使用根据代表性生产数据的输入和输出序列训练的任务特定推测器。
• 从单租户流量中实现更一致的缓存命中。
• 调整分离配置，使预填充和解码引擎的比例与流量模式匹配。
• 配置并行度和批处理设置，以实现延迟和吞吐量之间的所需权衡。

如需 GLM-5.2 的专用部署，请联系我们的团队，或立即通过我们的模型 API 开始测试该模型。

此项工作的所有功劳归功于 Alex Korte、Magdy Saleh、Tri Dao、Anant Desai、Bryce Dubayah、Abu Qader 以及 Baseten 出色的工程团队的其他成员。我只是有幸记录他们辛勤工作的人。

• 原文链接： x.com/philipkiely/status...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～