Together 用智能体持续优化推理性能

Together AI 想解决的，是推理服务上线后越来越难保持最优性能的问题：请求长度变了、用户分布变了，原先调好的配置也会过时。它推出的 Together Compiler（TKCC），让 coding agents 持续修改推理代码，再用实际运行结果筛选方案。

原文给出的最好成绩，是相对 InferenceX 最佳公开配置达到最高 2.6 倍 TPS。但更值得程序员关注的，是它如何降低实验成本，以及为什么随机测试数据和专家经验都可能把优化带偏。

为什么推理优化不能只做一次

推理性能不只取决于模型和 GPU，还取决于用户怎么请求。

作者援引 Together AI 团队的数据：某个国家的提示词长度约为 97K tokens，其他地区约为 70K；一个客户的 P90 输入长度，则在 3 天内从 18K 增长到 33K tokens。请求形态变了，原来合适的计算方式和并行布局就未必继续合适。

测试数据也会制造错觉。随机输入激活的 MoE 专家数量，比真实流量多出 13% 至 38%。MoE 会把不同输入分配给不同专家网络，所以输入分布会直接影响实际计算负载。

原文有个极端例子：agent 写出的 top-k kernel，在随机数据上耗时 20 µs，换成 70K 上下文的真实数据后，最高耗时达到 62 ms。原文没有展开这个性能悬崖的具体原因，但足以说明，随机数据上的快，不足以证明线上也快。

TKCC 的输入是服务启动命令、流量画像和硬件配置。agent 据此改写模型的前向计算过程，也就是一次推理真正执行的计算代码；系统测量候选方案，把胜出的代码放进服务引擎，流量变化后再跑一轮。

优化目标需要跟着真实请求变化，测试样本也必须如此。

让 agent 多试几次，先得把实验变便宜

TKCC 的关键工程设计，是让推理引擎常驻。

常见实验循环每次都重启 vLLM、SGLang 或 TensorRT-LLM。团队测得，MiniMax M3.1 Flash 在 TensorRT-LLM 上冷启动需要 761 秒。这样的等待会消耗大量搜索时间。

TKCC 只启动一次引擎。agent 通过 RPC 提交候选前向计算代码，服务端替换函数指针，再重新捕获 CUDA graphs。它还设置了两档测量：快档运行 12 层，先筛掉明显无效的方案；慢档运行 60 层，在真实分布上确认收益。

两档方案共测试了 1,354 个候选，单一慢档只有 168 个，相差 8.1 倍；最终找到的方案还快了 7.2%。团队另外报告，相比重启引擎的基线，agent 实验吞吐提高了 252 倍。

这里有两个不同指标：252 倍描述的是实验速度，最高 2.6 倍描述的是推理 TPS，不能混用。

搜索开始前，成本模型还会给张量、专家、数据和上下文并行布局排序。它结合硬件规格、微基准、实际前向计算结果，以及专家负载不均和请求长度差异。在 Kimi K3 上，这一步找到的生产布局带来了最高 24% 的 TPS 提升。

最高 2.6 倍，实际收益分布很不均匀

在 SemiAnalysis InferenceX 的 AgentX 工作负载上，每种设置运行不足 24 小时，每个模型最多使用 2 个节点。以下是团队自报的 batch size 1、单用户 P90 TPS：

模型与硬件	TKCC	InferenceX 最佳配置
MiniMax M3.1 Flash，B200	1,111	633
DeepSeek v4.1 Flash，GB300	1,205	943
GLM 5.3，B200	417	329
Kimi K3，GB300	450	423
GLM 5.3，MI355X	480	463

MiniMax 这一项约为基线的 1.8 倍；GLM 5.3 在 MI355X 上则只提升约 4%。表中的数据也没有直接出现 2.6 倍，原文没有交代该最高值对应的完整设置。

MiniMax 的收益还有一个具体来源：成本模型选择了 TP8，基线使用 TP4。按原文解释，这让每块 GPU 的权重访存流量减半，有利于受内存带宽限制的解码。因此，收益包含并行配置调整，不能全部归给 agent 写出了更快的 kernel。

其他实验中，Llama 1B 在 batch size 1 下，相对 Hazy Research megakernels、Mirage 和 CUDA-graph 基线最高快 1.7 倍；8 个科学模型获得 1.5 至 6.4 倍加速，输出保持逐位一致。Claude Code 配合 /goal 的结果为 1.2 至 4.4 倍，并在 AIFS-ENS 2.0 上失败。

另一个反直觉结果是，专家整理的知识库在 12 小时后带来的加速收益低了 25% 至 31%；10 次试验的集成得分，无预设专家策略的 agent 为 6.2x，专家策略为 4.9x。自定义日志结构还占用了最多 43% 的工具调用。团队因此选择直接给 agent 引擎源码，而非中间表示。

我的判断

我更认可它对实验基础设施的投入。能快速提交、真实测量、及时淘汰，才有条件让 agent 持续搜索。对于自建推理服务的团队，这比单独追求一个更聪明的提示词更有参考价值。

但这些结果都是团队自报，原文没有给出足够信息来核查全部正确性验证、搜索成本和线上发布机制。科学模型的逐位一致，也不能替代 LLM 优化方案的验证说明。

「朴素 agent 胜过专家知识库」同样有前提：它能读取引擎源码，并拥有高吞吐的执行反馈。这个实验支持减少低效约束，不足以证明专家知识普遍无用。

与其他系统也不能直接排榜。Cursor + NVIDIA 优化独立 CUDA kernels，AMD GEAK 面向单个 Triton kernel，Apple RSI-Inference 用任务评估 coding agents；它们与完整服务引擎优化的范围不同。普通团队若流量稳定、模型固定，先做好离线调优仍然合理，原文没有给出持续优化与维护成本之间的对照数据。

能拿来做什么

• 自建推理服务时，按真实请求长度和流量分布准备回放样本，并定期检查 P90 输入长度变化，避免只用随机张量验收性能。
• 给 coding agent 搭建优化循环时，先记录启动、构建、测试分别耗时多少，再决定是否需要常驻进程和分档测量。
• 比较优化方案时，同时记录硬件、batch size、并行布局和 TPS 口径，尤其检查收益是否来自 TP4 到 TP8 这样的配置变化。
• 如果日常只是通过 Node 调用托管模型 API，可以借鉴请求分布监测的方法；TKCC 目前面向 Together 客户有限测试，原文没有提供可直接接入的公开 API。