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

大多数推理基准测试测量的是单个用户访问专用端点的性能，这些数字看起来不错，但对于生产环境毫无用处。在生产中，系统同时运行数十或数百个并发请求，它们竞争相同的 KV 缓存、内存带宽和 GPU 周期。真正重要的是系统在负载下每个用户的体验。

Together AI 团队构建了针对编码智能体工作负载的基准测试，该工作负载对推理提出了严峻挑战：长输入、高并发，并且不能容忍负载下的延迟退化。编码智能体请求携带大量上下文：正在编辑的文件、周围代码、对话历史、检索到的片段。输入很长，输出有意义但有限——你是在生成一个函数，而不是一篇文章。更难的挑战是并发性。许多用户同时访问端点，这些请求以单用户基准测试永远无法捕捉的方式相互作用。

为了测试这一点，他们设计了一个高流量基准测试，模拟生产环境中编码智能体流量的请求分布。提示长度范围从约 45k 到 200k 令牌，模拟真实的编码会话增长，生成长度平均约 450 令牌。关键指标是每分钟输入令牌数 (TPM)、每用户每秒令牌数 (TPS) 和 p50 首令牌延迟 (TTFT)。

对于编码智能体，TTFT 是决定工具感觉快速还是糟糕的指标。开发者提交请求后，直到第一个令牌到达之前什么都看不到。这个间隙——从提交到流式输出——是信任赢得或失去的地方。输出速度很重要，但次之：一旦令牌开始流式传输，即使生成速率适中，体验也会感觉流畅。第二个约束是长上下文下的并发性。编程智能体请求不仅长，而且同时发生。数十名开发者同时访问同一端点，每人携带 80k+ 令牌的上下文，会产生单用户基准测试从未暴露的 KV 缓存压力。随着缓存填满，调度器的回旋余地减少，预填充延迟增加，TTFT 恶化。第三个约束是输出形状。你生成的是一个函数，而不是一篇文章。生成长度有限——平均约 450 令牌——这意味着饱和时的吞吐量在这里看起来不同于摘要或文档生成工作负载。系统不是处于持续的解码压力下，而是处于持续的预填充压力下，伴随着频繁的短解码突发。专门针对长解码运行优化的引擎在这里不一定胜出。

基准测试方法：硬件为每个引擎使用 4 块 NVIDIA B200（SGLang 使用 8 块 B200，因为其 EAGLE 实现需要更多内存）。工作负载包括长提示、高并发和真实的会话轮换。EAGLE 推测解码使用 3 个草稿令牌，接受率约 70%。引擎配置针对低延迟优化，不同于吞吐量优化配置。

Together Inference Engine 的性能提升来自全栈优化：端到端性能分析，识别最昂贵的操作，并逐一消除。ThunderMLA 是 ThunderKittens 内核库的一部分，将两个独立内核启动融合为单个超级内核，消除了启动开销和尾效应。在代表性解码工作负载上，ThunderMLA 比 DeepSeek 的 FlashMLA 快 20-35%。此外，他们还分析了整个栈——驱动程序行为、内存布局、内核执行——并消除了所有瓶颈。

结果：在 625 TPM/GPU（总计 2.5M TPM）下，Together Inference Engine 比 TensorRT-LLM 提供 31% 更多的 TPS，并且是唯一在 1 秒 TTFT 以下的引擎。在 2.5M TPM 时，所有引擎都超过其舒适范围：Together IE 的 p50 TTFT 为 0.71 秒，TensorRT-LLM 为 1.1 秒，SGLang（使用 8 GPU）为 5.1 秒。在流量水平下，Together IE 的 TTFT 是 TensorRT-LLM 的 2 倍好，是 SGLang 的 3 倍好。系统有更多余量：在其他引擎无法工作的负载下仍能正常运行。

成本和质量方面：Kimi K2.6 在编码基准上匹配或超越 Claude Opus 4.6。对于典型请求（约 80k-100k 输入令牌，450 输出令牌），Kimi K2.6 在 Together 上的成本为每个请求 $0.108，而 Claude Opus 4.6 为 $0.451，便宜 76%。一个 30 人的工程团队每天运行 5 小时，每年可节省约 44 万美元的推理成本。

这是版本一，团队计划在更新时展示优化带来的实际变化和数字变化原因。