借助 ProsGrow Managed Inference，让 AMD GPU 上的 GLM-5.2 吞吐量接近 3 倍

对于构建私有 AI 助手的团队，GPU 容量只有转化为完成的工作才有价值。即使模型生成 token 很快，仍可能在处理长上下文、恢复先前对话状态，或等待智能体工作流的不同阶段时花费大量时间。

这一差别决定了我们 GLM-5.2 研究的方向。我们改进推理服务系统对可复用上下文的处理方式，测试同样 8 张 AMD MI325X GPU 能够多交付多少输出。模型检查点和精度保持不变。

接近 3 倍的输出速率

在 10 月 6 日的实验中，测得的输出吞吐量从每 GPU 每秒 3.03 个 token 提升至 9.05 个。整台 8 GPU 服务器的输出速率从每秒 24.22 个 token 提升至 72.43 个，达到本地原始配置的 2.99 倍。

首 token 测量体现了结果的另一面：这一工作负载中的长时间等待明显缩短。token 流式交互速度中位数仅变化了 2.1%，因此应将吞吐量提升理解为完整推理服务工作负载的结果，而不是每个 token 的生成速度都提高了 3 倍。

随着已完成响应组合的变化，完整请求延迟中位数从 6.73 秒增加至 7.92 秒。因此，更高的总体吞吐量并不意味着每项延迟指标都得到了改善。

让有用的上下文保留更久

智能体工作流经常重新访问已经处理过的内容。保留这些工作成果，可以减少再次处理相同上下文的需要，尤其是在多个对话竞争内存时。

我们的方法着重于协调服务器不同内存资源之间的上下文复用。我们结合使用可用的主机内存和 GPU 显存，调整推理服务策略，并检查配置在完整基准工作负载下的表现。服务器计数器显示，总体缓存复用率从 83.4% 提高到 96.6%。

其商业意义很实际：部署评估应在 GPU 计算能力之外，同时检查内存与上下文的行为。在购买更多 GPU 之前，现有服务器中可能还有额外容量可用。具体空间取决于应用的流量与响应要求。

与已发布参考成绩的比较

我们测得的 9.05 tokens/s/GPU，也是 2026 年 9 月 25 日 InferenceX GLM-5.2 参考成绩（第 443210 行）中 4.14 tokens/s/GPU 的 2.19 倍，两者均为 8 张 MI325X GPU、并发数 4。token 流式交互速度中位数比该参考成绩低 3.6%。这是与一个已发布历史数据点的比较；运行时版本身份和测试条件的差异，使我们不能将其称为精确复现。已发布的参考测试

结果能够支持什么结论

性能测试之前，单独开展的真实验证检查在短提示和长提示条件下，数学题均得分为 125/128，且没有出现基线答对而新配置答错的题目。这些检查支持所测试的配置，但客户工作流仍需要独立的质量评估。

性能结果来自 1 组顺序执行、每次计划时长为 1 小时的 AgentX 测试，采用模拟的推测接受行为。部分响应短于请求要求，两次测试完成了不同的响应组合，输入长度也存在细微差异。所有已完成响应均被保留。结果适用于并发数为 4 的 GLM-5.2 FP8，并非生产容量或成本保证。

正在规划私有 GLM 托管，或评估专用 AMD GPU 基础设施？ProsGrow 可以帮助评估您的模型、工作负载和响应目标，在扩容前确定哪些推理服务调整值得测试。讨论试点项目