ProsGrow 如何让 AMD 上的 Kimi K3 完整请求吞吐量提升 50%

如果 AI 应用需要先读取大量上下文再返回答案，处理输入的时间可能与生成速度同样重要。因此，优化完整请求会改变哪种推理服务配置能够提供更好的体验。

在 Kimi K3 研究中，ProsGrow 在相同 AMD 硬件上，相比既有 ATOM 配置，将完整请求输出吞吐量提高了 50.1%。结果来自推理服务栈的调整，使用相同的原始模型检查点，并控制请求大小。实验配置改变了运行时部分环节的数值精度，因此仍需要更广泛的质量验证。

结果：更快收到完整响应

9 月 22 日的测量使用 8 张 AMD MI325X GPU 运行 Kimi K3。每个请求恰好包含 8,192 个输入 token，并生成 256 个输出 token；同一时刻只运行 1 个请求。

完整请求吞吐量以输出 token 数除以接收完整响应的时间，包含输入处理和传输。这些是整套系统的测量值，并非每 GPU 的速率。两个百分比从不同角度描述了同一项底层改进，不应相加。

对于私有 AI 团队，这表明推理服务配置值得与硬件规格一起评估。对于大量输入上下文、简短生成输出的应用，更快收到固定长度响应可能很有价值。

4.41 倍的结果说明工作负载为何重要

我们还将实验配置与基于 Microsoft Tutel 运行时构建的本地适配器进行了比较，使用相同主机、原始检查点、固定请求样例和客户端。

在 8K 输入、256 输出 token 工作负载下，Tutel 适配器的完整请求输出速率为 9.10 tokens/s，调优后的 ATOM 为 40.17，即完整请求速率达到 4.41 倍。适配器的请求耗时中位数为 28.13 秒，调优后的 ATOM 为 6.37 秒。

解码开始后，Tutel 的 token 生成仍然更快：78.33 对 47.67 tokens/s。在较短的 512 输入 token 请求中，它也更快完成。所测试适配器的长提示处理时间较长，因此在 8K 输入时改变了结果。

商业启示很具体：应根据应用实际使用的请求长度和响应大小选择推理服务配置。这是一次本地运行时比较，不能泛化为某个运行时在所有工作负载上都更快。

提升来自哪里

ProsGrow 检查了推理服务栈在输入处理和生成阶段如何使用 AMD 硬件，随后测试了一组组合运行时配置。该工作基于 ATOM 和 AMD AITER 生态。

这一方法将优化与完整请求联系起来，同时明确精度与质量之间的权衡：使用相同的原始检查点，不代表不同推理服务配置执行完全相同的数值运算。本次比较的运行时和缓存精度策略不同。

我们验证了什么

每个配置在每种输入长度下先运行 2 个预热请求，再测量 5 个请求。推测解码已关闭。我们审计保存的响应流以核实 token 数和时间，3 个配置均通过了算术与标记回忆检查。

这些功能检查不能证明模型准确率相当。实验配置保持为可选方案，没有替换常规服务。这些测量属于开发阶段结果，未提供置信区间，也不构成生产服务水平保证。

对于考虑私有 Kimi 托管的团队，下一步是使用有代表性的提示词、响应长度、并发数和任务质量标准进行评估。ProsGrow 可以帮助将这些要求落实为经过测量的部署配置。

如需讨论私有推理试点，请发送邮件至 contact@prosgrow.ai。