大规模推理基准测试：编码代理

摘要

在生产级编码代理工作负载下，Together Inference Engine 在相同硬件上比次快的开源 OSS 引擎多提供 31% 的 TPS，并且在饱和状态下保持 2× 更好的 TTFT。这些收益来自于全栈优化：ThunderMLA、自定义内核重写以及基于真实流量的端到端性能分析。

大多数推理基准测试衡量的是单个用户访问专用端点的性能。这些数字看起来很棒，但对于推理生产环境来说却毫无用处。

在生产环境中，您正在运行数十个甚至数百个并发请求。它们竞争相同的 KV 缓存、相同的内存带宽和相同的 GPU 周期。重要的是当系统负载时，每个用户的体验如何。

我们构建了这个基准测试来回答编码代理的这个问题。这是一个对推理能力要求很高的工作负载：长输入、高并发性，并且在负载下无法容忍延迟下降。

这是第一个版本。随着我们的构建，我们将更新它。

编码代理工作负载是什么样的

编码代理请求携带大量上下文：正在编辑的文件、周围代码、对话历史、检索到的代码片段。输入很长。输出有意义但有限制；您正在生成一个函数，而不是一篇文章。

更具挑战性的是并发性。许多用户同时访问端点，这些请求的交互方式是单用户基准测试从未捕捉到的。随着流量增加，KV 缓存被填满。调度压力增大。每个用户的吞吐量下降。首令牌时间 (TTFT) 上升。在某些时候，系统变得不再有用。不同的引擎在不同的流量水平上达到那个临界点。

我们设计了一个高流量基准测试来对此进行压力测试，基于我们大规模服务生产编码代理流量时看到的请求分布。提示长度从约 45k 到 200k 个令牌不等，模拟真实的编码会话增长，生成长度平均约为 450 个令牌。关键指标是 TPM（每分钟输入令牌数）、每个用户的 TPS（每秒令牌数）和 p50 TTFT。

推理需要做对什么

对于编码代理，TTFT 是决定工具感觉快速还是卡顿的指标。提交请求的开发者在第一个令牌到达前什么也看不到。这个间隙——从提交到流式传输——是赢得或失去信任的地方。输出速度很重要，但它是次要的：一旦令牌开始流式传输，即使在适中的生成速率下，体验也会感觉流畅。

第二个约束是长上下文下的并发性。编码代理请求不仅长——它们还同时发生。数十名开发者同时访问同一个端点，每个都携带 80k+ 个令牌的上下文，这创造了单用户基准测试从未体现的 KV 缓存压力。随着缓存填满，调度器的机动空间变小。预填充延迟增加。TTFT 下降。在足够高的流量下，系统在正式故障之前就变得不再有用。

第三个约束是输出形状。您正在生成一个函数，而不是一篇文章。生成长度是有限的——平均约 450 个令牌——这意味着在饱和状态下的吞吐量在这里与摘要或文档生成工作负载中看起来不同。系统不是持续处于解码压力下；它持续处于 _预填充_ 压力下，并伴有频繁的短时解码爆发。为长解码运行优化的引擎不一定在这里获胜。

这三个约束——TTFT 敏感性、并发长上下文负载和预填充密集型输出形状——正是该基准测试旨在强调的。

方法论

硬件： 每个引擎 4× NVIDIA B200（SGLang：8× B200 — 请参阅下面的注释）。

工作负载： 长提示、高并发性、真实的波动。提示长度从约 45k 到 200k 个令牌不等，模拟真实的编码会话增长。生成长度平均为 450 个令牌（p50：293，p99：2,230）。难度随流量增加而增加：在更高的 QPS 下，更长的提示和不断增长的 KV 缓存创造更多的预填充压力，需要维护更多的上下文，并且随着会话波动的增加，会出现更多的 KV 缓存抖动。

EAGLE 推测解码： 3 个草稿令牌。接受率（约 70%）从真实的合成提示数据中自然产生——我们没有强制它。

引擎配置： TensorRT-LLM 针对此工作负载进行了很好的调优，并代表了强大的基线。SGLang 在可能的情况下进行了配置匹配；我们没有运行详尽的调优实验，因此可能还有边际改进空间。所有引擎都配置为低延迟。这与吞吐量优化的配置不同，后者会增加最大解码批处理大小，并使用预填充-解码分离来以更高的输出 TPS 交换更高的输入 TPM。

我们做了哪些优化

我们的性能提升来自于将推理视为一个全栈问题：进行端到端性能分析，确定最昂贵的操作，然后逐一消除它们。

ThunderMLA。 Kimi K2.5 使用 DeepSeek 的多头潜在注意力 (MLA) 架构。标准实现在每个解码步骤运行两个单独的内核启动。我们的 ThunderMLA —— 我们 ThunderKittens 内核库的一部分 —— 将这些融合为单个巨型内核，消除了启动开销和它们之间的尾部效应。在代表性的解码工作负载上，ThunderMLA 比 DeepSeek 自己的 FlashMLA 快 20-35%。

除了 ThunderMLA，我们还对整个堆栈进行了性能分析——驱动程序行为、内存布局、内核执行——并消除了我们发现的所有瓶颈。一些需要配置更改。其他需要从头编写内核。我们编写的内核在此工作负载上优于 TensorRT-LLM 的开源等效实现。

以下是这些优化在负载下的完整系统中的体现。

结果

我们在 Kimi K2.5 上使用 EAGLE 推测解码，将 Together Inference Engine 与两个基线进行了比较：

• TensorRT-LLM — 4 x NVIDIA B200 GPU
• SGLang — 8 x NVIDIA B200 GPU

关于 SGLang 的说明： 在 TP4 模式下使用 EAGLE 运行 Kimi K2.5 时，SGLang 内存不足 — 在此模型上，SGLang 的 EAGLE 实现比 TensorRT-LLM 需要更多内存。我们使用 TP8（8 个 GPU）来运行它。TensorRT-LLM 和 Together Inference Engine 在 4 个 GPU 上运行。

在每 GPU 625 TPM（总计 2.5M TPM）的情况下，Together Inference Engine 比 TensorRT-LLM 多提供 31% 的 TPS，并且是唯一仍保持 1 秒以下 TTFT 的引擎。

`性能` 下降曲线

曲线的形状比任何单个数据点都更重要。每个推理引擎最终都会达到饱和：KV 缓存填满，调度压力增加，TTFT 上升。引擎之间的区别在于何时发生以及速度如何。

在 2.5M TPM 时，每个引擎都超出了其舒适范围：

| 引擎 | GPU 数量 | p50 TTFT | | --- | --- | --- | | Together IE | 4 | 0.71秒 | | TensorRT-LLM | 4 | 1.1秒 | | SGLang | 8 | 5.1秒 |

在 2.5M TPM 下测量。

在所有引擎都在降级的流量水平上，Together IE 的 TTFT 比 TensorRT-LLM 好 2 倍，比 SGLang 好 3 倍。系统有更多余量：在其他引擎无法处理的负载下仍能正常运行。

成本和质量

本文中的性能基准测试是基于 Kimi K2.5。Kimi K2.6 现已在 Together 上推出，在编码基准测试中全面匹配或超越 Claude Opus 4.6。

| 基准测试 | Kimi K2.6 | Claude Opus 4.6 | | --- | --- | --- | | SWE-Bench Verified | 80.2 | 80.8 | | SWE-Bench Pro | 58.6 | 53.4 | | LiveCodeBench v6 | 89.6 | 88.8 | | Terminal-Bench 2.0 | 66.7 | 65.4 |

在该质量水平下，成本差异显著。对于此工作负载的典型请求 — 约 80k-100k 输入标记，约 450 输出标记：

| 模型 | 每次请求成本 | | --- | --- | | Together 上的 Kimi K2.6 | $0.108 | | Claude Opus 4.6 | $0.451 |

每次请求便宜 76%。 一个 30 人的工程团队每天以 1.5M TPM 的速度运行编码代理 5 小时（250 个工作日），与 Claude Opus 4.6 相比，每年可节省约 440K 美元的推理成本。

这是第一版

这些结果反映了 Together Inference Engine 在当前工作负载和硬件配置下的现状。我们发布这些结果是因为我们认为基准测试应该有意义：基于真实的工作负载形状，对方法保持透明，诚实地说明系统开始崩溃的地方。

每次更新都会是累加的。目标是建立一个可理解的工作负载上优化实际带来好处的记录。当下一版发布时，我们会向您展示具体的变化以及数字变化的原因。

如果您正在大规模运行编码代理，并希望了解这对您的工作负载意味着什么，请联系我们。