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

一个月前，GLM-5.2 发布了。作为我们的首发支持，我们为 GLM-5.2 构建了全球最快的 API，峰值速度达到 280 tokens/秒，平均速度约为 100 tokens/秒。今天，我们的 GLM-5.2 API 在 Artificial Analysis 的基准测试中 显示性能比发布当天的 API 提升了一倍以上。我们发现，改进后的 API 性能在基准测试和实际使用中都得到了体现。

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

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

部分性能优化工作对两个 API 都有益。在过去一个月里，我们优化了调度器，略微提高了吞吐量，同时推出了改进的 NVFP4 权重和更新的推测解码方案。我们还在推理引擎和整个技术栈中修复了质量和性能方面的多个 bug。

对于快速 API，我们重点降低了编码和 Agent 的延迟。推理工程提供了多种在延迟和吞吐量之间的帕累托前沿上进行权衡的机会。基于市场对更高性能愿意付费的强烈信号，Baseten 的性能团队重新审视了并行度、批处理和缓存等配置选项，尽可能将系统推向更低的延迟。其中有两个变化影响最大：

• 通用 API 使用注意力数据并行（ADP）来提高吞吐量，而快速 API 仅使用针对延迟优化的张量和专家并行。
• 最大批处理量的显著减少意味着更少的请求在竞争资源。

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

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

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

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

LLM 的性能会因系统流量、流量模式以及输入和输出序列长度而有很大差异。Artificial Analysis 的基准测试发送约 10,000 个输入 token 的提示，生成约 1,000 个输出 token 的响应。我们从市场获得了积极的反馈，认为我们的 API 在实际使用中（而不仅仅是基准测试中）表现出领先的性能。

我们还没有结束对 GLM-5.2 性能的优化。我们计划很快推出另一个改进，应用于我们的推测解码算法。同时，我们在为 Kimi K3 构建 API 的过程中学到了很多，并期待将这些经验反过来应用到其他开源模型（如 GLM-5.2）上。

GLM-5.2 的新快速 API 已在 Baseten 上公开发布。立即尝试：https://www.baseten.co/library/glm-52-fast/。