大规模推理基准测试：编码智能体

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

大多数推理基准测试衡量的是单个用户访问专用端点的情况。数据看起来很好。但对于推理生产环境来说，它们毫无用处。

在生产环境中，你运行的是数十或数百个并发请求。它们竞争相同的 KV 缓存、相同的内存带宽、相同的 GPU 周期。关键在于系统负载下每个用户会发生什么。

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

这是第一版。随着我们的构建，我们会持续更新。

编码代理工作负载的样子

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

更难的挑战是并发性。许多用户同时访问端点，这些请求以单用户基准测试从未捕捉到的方式相互影响。随着流量增加，KV 缓存被填满。调度压力增大。每个用户的吞吐量下降。首个 token 生成时间（TTFT）上升。在某个时刻，系统变得不再可用。不同的引擎在截然不同的流量水平达到这个点。

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

推理必须做对什么

对于编码代理，TTFT 是决定工具感觉快速还是故障的指标。提交请求的开发者直到第一个 token 到达才能看到任何东西。那个间隙——提交和流式传输之间——是赢得或失去信任的地方。输出速度很重要，但它是次要的：一旦 token 开始流式传输，即使生成速率中等，体验也会感觉流畅。

第二个约束是长上下文下的并发性。编码代理请求不仅长——而且长且同时发生。数十名开发者同时访问同一个端点，每个都携带 80k+ token 的上下文，这造成了单用户基准测试从未暴露的 KV 缓存压力。随着缓存被填满，调度器的操作空间变小。预填充延迟上升。TTFT 恶化。在足够高的流量下，系统在正式失败之前就已经变得不可用。

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

这三个约束——TTFT 敏感性、并发长上下文负载和预填充为主的输出形状——正是这个基准测试旨在施加压力的地方。

方法

硬件： 每个引擎 4× NVIDIA B200（SGLang：8× B200——见下方说明）。

工作负载： 长提示、高并发、真实的会话更替。提示长度范围约为 45k 到 200k token，模拟真实的编码会话增长。生成长度平均为 450 token（p50：293，p99：2,230）。难度随流量增加：在更高的 QPS 下，更长的提示和增长的 KV 缓存会带来更多的预填充压力、需要维护的更多上下文，以及随着会话更替增加而导致的更多 KV 缓存抖动。

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

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

我们优化了什么

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

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

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

以下是这如何转化为负载下的完整系统。

结果

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

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

关于 SGLang 的说明： 在 SGLang 上以 TP4 运行带有 EAGLE 的 Kimi K2.5 会耗尽内存——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，并且是唯一一个 TTFT 仍低于 1s 的引擎。

退化曲线

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

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

引擎	GPU	p50 TTFT
Together IE	4	0.71s
TensorRT-LLM	4	1.1s
SGLang	8	5.1s

在 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 输入 token，约 450 输出 token：

模型	每次请求成本
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 今天在此工作负载、此硬件配置下的状态。我们发布它们是因为我们认为基准测试应该有意义：基于真实的工作负载形状，方法透明，并诚实地说明事情开始崩溃的地方。

每次更新都将是增量式的。目标是建立一个运行记录，展示优化在一个你可以推理的工作负载上实际能带来什么。当下一版发布时，我们会向你展示具体发生了什么变化以及数字为何变动。

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