编码智能体推理基准：单用户跑分没用，高并发下 TTFT 才是生死线

一句话结论

大多数推理基准测的是”单用户打专享端点”——数字好看，但对生产毫无参考价值。Together 按真实编码智能体流量形态（45k–200k token 长提示、高并发、平均 450 token 生成）建了一套高压基准：同硬件下 Together 推理引擎比次快的开源引擎高 31% 单用户 TPS，全引擎饱和区保持 2 倍更好的 TTFT；配合 Kimi K2.7 Code 单请求 0.029 美元的成本，150 人工程团队一年可省约 42.1 万美元推理费。对选型推理引擎和编码模型的团队，这套基准方法论和六项跑分对照表都能直接复用。

单用户跑分为什么没用

生产环境是几十上百个并发请求打同一个端点：它们抢同一份 KV cache、同一条内存带宽、同一块 GPU 周期。真正重要的，是系统带载时每个用户经历什么。编码智能体恰恰是打推理最狠的负载：长输入、高并发、对带载延迟劣化零容忍。

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

更难的挑战是并发。很多用户同时打端点，请求间的相互作用是单用户基准永远捕捉不到的：流量一上来 KV cache 填满、调度压力上升、单用户吞吐下降、首 token 时间（TTFT）爬升；到某个点系统”先失去可用性、后正式失败”。不同引擎到达这个点的流量水平天差地别。

Together 按生产编码智能体流量的请求分布设计了高压基准：提示长度 45k–200k token 模拟真实编码会话增长，生成长度平均 450 token，关键指标是 TPM（每分钟输入 token）、单用户 TPS（每秒 token）和 p50 TTFT。

推理引擎必须做对的三件事

TTFT 决定工具”快”还是”坏”。 开发者提交请求后，在第一个 token 到来前什么都看不到。提交到出流之间的间隙，就是信任建立或崩塌的地方。输出速度其次——token 一旦开始流，中等生成速率下体验也是流畅的。

长上下文并发是第二约束。 编码智能体请求不只是长，是又长又同时：几十个开发者同时上端点、每人带 80k+ token 上下文，KV cache 压力是单用户基准永远照不出来的。cache 填满时调度器腾挪空间变小、prefill 延迟爬升、TTFT 劣化。

输出形状是第三约束。 生成的是函数不是散文：生成长度有界（平均约 450 token），饱和吞吐的样子和总结类、文档生成类负载完全不同——系统不承受持续解码压力，承受的是持续 prefill 压力加频繁短促解码。为长解码优化的引擎在这种负载下未必赢。

方法论

• 硬件：每个引擎 4× NVIDIA B200（SGLang 用 8×，见下注）。
• 负载：长提示、高并发、真实会话流失。提示 45k–200k token，生成长度平均 450 token（p50: 293，p99: 2230）。难度随流量缩放：QPS 越高提示越长、KV cache 越大、prefill 压力和 cache 抖动越强。
• EAGLE 投机解码：3 个草稿 token，接受率（约 70%）从真实合成提示数据中自然涌现，不人为干预。
• 引擎配置：TensorRT-LLM 对该负载调优充分、是强基线；SGLang 尽可能对齐配置，未做穷举调参。所有引擎按低延迟配置，与吞吐优先配置（加大解码批、prefill-解码分离换 TPS）不同。

他们优化了什么

性能收益来自把推理当全栈问题：端到端 profiling、找出最贵的操作、逐个消灭。

ThunderMLA。 Kimi K2.5 用 DeepSeek 的多头潜注意力（MLA）架构。标准实现每个解码步要跑两次独立内核启动；Together 的 ThunderMLA（ThunderKittens 内核库的一部分）把两者融合成单个 megakernel，消除启动开销和尾效应。在代表性解码负载上，ThunderMLA 比 DeepSeek 自家的 FlashMLA 快 20–35%。

ThunderMLA 之外，团队对全栈做了 profiling——驱动行为、内存布局、内核执行——把找到的瓶颈逐个清除：有的改配置就行，有的要从零写内核。自写内核在该负载上跑赢 TensorRT-LLM 的开源等价物。

结果：退化曲线比单点重要

在 Kimi K2.5 + EAGLE 投机解码下对比三个引擎（TensorRT-LLM 4× B200、SGLang 8× B200）。注：SGLang 在 TP4 跑 Kimi K2.5+EAGLE 会 OOM——SGLang 的 EAGLE 实现在这个模型上比 TensorRT-LLM 更吃内存，因此用 TP8（8 卡）跑；TensorRT-LLM 和 Together 引擎都是 4 卡。

在每 GPU 625 TPM（总量 250 万 TPM）时，Together 推理引擎比 TensorRT-LLM 高 31% 单用户 TPS，且是唯一 TTFT 仍在 1 秒内的引擎。

曲线形状比任何单点都重要。所有推理引擎最终都会饱和：KV cache 填满、调度压力增大、TTFT 爬升；区别在于何时饱和、退化多快。在 250 万 TPM——所有引擎都过了舒适区——的实测 p50 TTFT：

引擎	GPU	p50 TTFT
Together 推理引擎	4× B200	0.71s
TensorRT-LLM	4× B200	1.1s
SGLang	8× B200	5.1s

在所有引擎都在退化的流量水平上，Together 引擎的 TTFT 比 TensorRT-LLM 好 2 倍、比 SGLang 好 3 倍——系统余量更大：在别的引擎已经不可用的负载下仍然可用。

成本与质量

性能基准基于 Kimi K2.5。Kimi K2.6 已在 Together 上线，编码基准全面追平或超过 Claude Opus 4.6。更值得关注的是 K2.7 Code 与各家的对照（加粗为该行最优）：

基准	Kimi K2.6	Kimi K2.7 Code	GPT-5.5	Claude Opus 4.8
Kimi Code Bench v2	50.9	62.0	69.0	67.4
Program Bench	48.3	53.6	69.1	63.8
MLS Bench Lite	26.7	35.1	35.5	42.8
Kimi Claw 24/7 Bench	42.9	46.9	52.8	50.4
MCP Atlas	69.4	76.0	79.4	81.3
MCP Mark Verified	72.8	81.1	92.9	76.4

在智能体维度（Kimi Claw 24/7、MCP Atlas、MCP Mark Verified）Kimi K2.7 Code 已与 GPT-5.5、Claude Opus 4.8 处于同一档。而该负载典型请求（约 80k–100k 输入 token、约 450 输出 token）的成本：

模型	单请求成本
Kimi K2.7 Code（Together）	0.029 美元
Claude Opus 4.8	0.097 美元

每请求便宜 70%。一个 150 人工程团队，按 750 万 TPM、每天 5 小时、250 个工作日跑编码智能体，相比 Claude Opus 4.8 一年省约 42.1 万美元推理成本。

这是第一版

这些结果反映 Together 推理引擎今天在该负载、该硬件配置下的位置。发布它是因为基准应该有意义：基于真实负载形状、方法论透明、诚实标注哪里开始崩。后续每次更新都是增量追加——下一版会说明改了什么、数字为什么动。

原文信息

• 作者：Alex Angus、Will Van Eaton、Dan Fu（Together AI）
• 发布时间：2026-05-19 原文地址：