Baseten 为 GLM-5.2 提供的 API 峰值速度达到每秒 280 个 token，平均速度约为每秒 100 个 token。其性能是发布当天 API 的两倍以上。该公司还构建了一个专注于降低编码和代理延迟的 Fast 版本 API，并计划很快推出另一项对其推测解码算法的改进，以进一步优化 GLM-5.2 的性能。

我们如何为 GLM-5.2 构建新的最快 API

一个月前，GLM-5.2 发布。作为我们零日支持的一部分，我们为 GLM-5.2 构建了全球最快的 API，峰值速度达到每秒 280 个 token，平均速度约为每秒 100 个 token。今天，根据 Artificial Analysis 的基准测试，我们的 GLM-5.2 API 性能是发布当天 API 的两倍以上。我们发现，无论是基准测试还是实际使用中，改进后的 API 性能都得到了体现。

Baseten 的 GLM-5.2 API 在 TTFT 和 TPS 两项指标上均处于领先水平

Baseten 的 GLM-5.2 API 在 TTFT 和 TPS 两项指标上均处于领先水平

随着像 GLM-5.2 这样的模型在市场上持续受到欢迎，我们加大了对模型特定优化工作的投入，以解锁更低的延迟和更高的吞吐量。除了改进我们的 GLM-5.2 API 外，我们还为该模型构建了另一个 API：GLM-5.2-Fast。

部分性能优化同时惠及两个 API。在过去的一个月里，我们优化了调度器，略微提高了吞吐量，并推出了改进的 NVFP4 权重和更新的推测解码配置文件。我们还修复了推理引擎及整个技术栈中的质量和性能相关 bug。

对于 Fast API，我们专注于降低编码和代理应用的延迟。推理工程提供了多种在延迟与吞吐量之间的帕累托前沿进行权衡的机会。基于市场强烈信号表明用户愿意为更高性能付费，Baseten 的模型性能团队重新审视了并行度、批处理、缓存等配置选项，力求将系统尽可能推向低延迟方向。以下两项改动带来了最大影响：

• 通用 API 使用注意力数据并行（ADP）来提高吞吐量，而 Fast API 仅使用张量并行和专家并行，并选择针对延迟的配置。
• 最大批量大小大幅减少，意味着更少的请求在竞争资源。

这个 Fast API 与通用 API 运行在相同的 NVIDIA B200 GPU 上。然而，由于性能优化通过牺牲吞吐量来降低延迟，输入和输出 token 价格比通用 API 高出 50%。

这些性能优化体现在 Artificial Analysis 最新的基准测试中（测试于太平洋时间 2026 年 7 月 25 日星期六晚上 7:00 左右）。

端到端响应时间是对用户体验至关重要的指标

端到端响应时间是对用户体验至关重要的指标

纯输出速度（以 TPS 衡量）对于在回答查询之前需要思考的推理模型尤其重要

纯输出速度（以 TPS 衡量）对于在回答查询之前需要思考的推理模型尤其重要

LLM 性能因系统流量大小、流量模式以及输入和输出序列长度的不同而有显著差异。Artificial Analysis 的基准测试发送约 10,000 个输入 token 的提示，生成约 1,000 个输出 token 的响应。我们收到了市场的积极反馈，表明我们的 API 在实际使用中也表现出色，而不仅仅是在基准测试中。

我们对 GLM-5.2 的性能优化并未止步。我们计划很快推出另一项对推测解码算法的改进。同时，我们从为 Kimi K3 构建 API 的过程中学到了很多，并期待将这些经验应用到其他开放模型（如 GLM-5.2）上。

全新的 GLM-5.2 Fast API 已在 Baseten 上公开可用。立即体验：https://www.baseten.co/library/glm-52-fast/。