我们如何为GLM-5.2构建了全球最快的API

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

科技领袖们正将GLM-5.2视为开源模型前沿智能的新里程碑

科技领袖们正将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在Baseten模型API上以SOTA速度运行，由Artificial Analysis于2026年6月22日测量

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

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

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

Notion通过Baseten提供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提供跨任务的前沿性能。图片来自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时间和每秒token数这两项性能。

在TTFT和TPS方面均表现卓越，由Artificial Analysis于2026年6月22日测量

在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日测量

GLM-5.2的首答案token时间，由Artificial Analysis于2026年6月22日测量

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

不过，将TTFT降至800毫秒对于系统的整体响应性和吞吐量仍然很重要。在大规模生产部署中，KV缓存在各个独立的副本之间进行分配。我们使用NVIDIA Dynamo中的工具来路由传入请求。

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

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数提高了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其他出色的工程团队成员。我仅仅是那个有幸记录他们辛勤工作的人。