摘要
在生产级编码代理工作负载上，Together推理引擎在相同硬件上比次快的开源推理引擎多提供31%的TPS，并在饱和状态下保持2倍更好的TTFT。这些收益来自全栈优化：ThunderMLA、自定义内核重写以及基于真实流量的端到端性能分析。
大多数推理基准测试衡量的是单个用户访问专用端点的情况。数据看起来很棒，但对于分析生产环境毫无用处。
在生产环境中，你运行着数十或数百个并发请求。它们竞争相同的KV缓存、相同的内存带宽、相同的GPU周期。重要的是系统负载下每个用户会发生什么。
我们构建这个基准测试就是为了回答编码代理的这个问题。这是一个对推理要求很高的工作负载：长输入、高并发，并且在负载下对延迟退化零容忍。
这是第一版。随着我们的构建，我们会更新它。
编码代理工作负载的样子
编码代理请求携带大量上下文。正在编辑的文件、周围代码、对话历史、检索到的片段。输入很长。输出有意义但有限；你生成的是一个函数，而不是一篇文章。
更大的挑战是并发性。许多用户同时访问端点，这些请求以单用户基准测试从未捕捉到的方式相互作用。随着流量增加，KV缓存填满。调度压力增大。每个用户的吞吐量下降。首令牌时间（TTFT）上升。在某个点，系统变得不再有用。不同的引擎在非常不同的流量水平达到这个点。
我们设计了一个高流量基准测试来对此进行压力测试，其模型基于我们在大规模服务生产级编码代理流量时看到的请求分布。提示长度范围约为45k到200k个令牌，模拟真实的编码会话增长，生成长度平均约为450个令牌。关键指标是TPM（每分钟输入令牌数）、每个用户的TPS（每秒令牌数）和p50 TTFT。
推理必须做对什么
对于编码代理，TTFT是决定工具感觉快速还是崩溃的指标。提交请求的开发者在第一个令牌到达之前什么也看不到。这个间隙——提交和流式传输之间——是信任赢得或失去的地方。输出速度很重要，但它是次要的：一旦令牌开始流式传输，即使生成速率中等，体验也会感觉流畅。
第二个约束是长上下文下的并发性。编码代理请求不仅长，而且长且同时发生。数十名开发者同时访问同一个端点，每个携带80k+令牌的上下文，这会产生单用户基准测试从未暴露的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内核库——将这两个内核融合为一个单一的大内核，消除了启动开销以及它们之间的尾部效应。在代表性的解码工作负载上，ThunderMLA比DeepSeek自己的FlashMLA快20–35%。
除了ThunderMLA，我们还分析了整个堆栈——驱动程序行为、内存布局、内核执行——并消除了我们发现的每一个瓶颈。有些需要配置更改。其他的则需要从头编写内核。我们编写的内核在此工作负载上优于TensorRT-LLM的开源等效内核。
以下是这在负载下的完整系统中的体现。
结果
我们将Together推理引擎与两个基线在Kimi K2.5上使用EAGLE推测解码进行了比较：
TensorRT-LLM——4× NVIDIA B200 GPUSGLang——8× NVIDIA B200 GPU
关于SGLang的说明： 在SGLang上以TP4运行Kimi K2.5和EAGLE时内存不足——SGLang的EAGLE实现在此模型上比TensorRT-LLM需要更多内存。我们使用TP8（8个GPU）来运行它。TensorRT-LLM和Together推理引擎在4个GPU上运行。
在每 GPU 625 TPM（总计 2.5M TPM）下，Together Inference Engine 的 TPS 比 TensorRT-LLM 高 31%，并且是唯一 TTFT 仍低于 1 秒的引擎。
The
退化曲线
曲线的形状比任何单个数据点都更重要。每个推理引擎最终都会饱和：KV 缓存填满，调度压力增加，TTFT 攀升。不同引擎之间的区别在于这种情况何时发生以及速度有多快。
在 2.5M TPM 时，每个引擎都超出了其舒适范围：
在所有引擎都退化的流量水平下，Together IE 的 TTFT 比 TensorRT-LLM 好 2 倍，比 SGLang 好 3 倍。该系统具有更大的余量：在其他引擎无法工作的负载下仍能正常运行。
成本与质量
本文中的性能基准测试基于 Kimi K2.5。Kimi K2.6 现已在 Together 上可用，在编码基准测试中，它全面匹配或超越 Claude Opus 4.6。
在该质量水平下，成本差异显著。对于此工作负载上的典型请求——约 80k-100k 输入 token，约 450 输出 token：
每个请求便宜 70%。一个 150 人的工程团队，以 7.5M TPM 运行编码代理，每天 5 小时（250 个工作日），与 Claude Opus 4.8 相比，每年可节省约 421,000 美元的推理成本。
这是第一版
这些结果反映了 Together Inference Engine 当前在此工作负载、此硬件配置下的表现。我们发布这些结果是因为我们认为基准测试应该有意义：基于真实的工作负载形态，方法论透明，并诚实地说明问题开始出现的地方。
每次更新都将具有增量性。目标是提供一个持续记录，展示优化在你可以推理的工作负载上实际带来的收益。当下一版本发布时，我们将准确展示发生了什么变化以及数字为何变动。
如果你正在大规模运行编码代理，并想了解这对你的工作负载意味着什么，请联系我们。