Together AI 发布 Together Compiler，用智能体持续编译优化 AI 推理

AI 推理工作负载是动态的。存在成千上万种情形，涵盖新模型、硬件平台、客户、用例和流量形态。对其中每一种情形都进行手动优化已不再具备可扩展性。

架构高度多样：距离 Transformer 问世已约 11 年。我们或许以为会出现更多整合，但 OpenRouter 上排名前 10 的开源 LLM 没有一个使用相同的架构！
工作负载高度多样：Together 每天为数千名客户处理数万亿个 token，每个客户的流量形态各不相同（批大小、序列长度、MoE 专家不均衡、注意力稀疏性、会话时长、领域）。
硬件高度多样：H100、B200、B300、NVL72、VR、Groq 等各自需要不同的策略。

理论上，智能体非常适合解决这个问题。它们能够适应新的工作负载，并在可能的优化空间中进行搜索，而不依赖那些困扰人类专家和传统机器学习编译器的固定规则或启发式方法。然而，当今的智能体系统受限于实验速度。

我们推出 Together Compiler（TKCC），这是首个真正持续的优化循环，利用高吞吐智能体针对多样化的推理工作负载进行优化

在不到 24 小时内，TKCC 在前沿开源模型（Kimi K3、GLM 5.3、MiniMax M3.1-Flash、DeepSeek v4.1-Flash）上实现了最高 2.6 倍的 TPS 提升，在 SemiAnalysis 的 InferenceX 低延迟基准测试中创下最先进水平——MiniMax M3.1-Flash 达到 1111 TPS，DeepSeek v4.1-Flash 达到 1205 TPS，并在其主力 Llama 1B 批大小为 1 的设置下，性能超过现有开源 megakernel 1.7 倍。此外，TKCC 还能泛化到语言模型推理之外的领域（天气建模、PDE、时间序列和生物学）。这一性能提升得益于 TKCC 相比基线智能体性能优化系统高出 252 倍的实验吞吐量。Together Compiler 目前每天服务数万亿个 token。

流量在不断变化

作为推理服务提供商，我们观察到基于区域模式、新模型发布和突发性的各种用户行为。

区域模式：世界各地的用户可能有不同的模型偏好。我们观察到，某个国家工作时间的流量，其提示长度比另一个国家长 1.4 倍（97k 对 70k）。
模型发布：用户需要时间来弄清楚如何将新发布的模型集成到他们的工作流中。起初，他们倾向于选择基于聊天的交互和评估。仅仅在发布两周后，随着用户转向智能体工作负载，提示长度迅速增加了 80%。
突发性：客户可能在一天中的随机时间发送突发请求。如果不谨慎处理，提示长度可能突然翻倍，缓存命中率也可能下降。

很明显，我们必须通过针对每个新部署的专门优化来适应不断变化的用户行为。

Together Compiler 概览

TKCC 以流量形态、模型和硬件作为输入。TKCC 使用智能体为推理引擎生成一系列优化。

图 1：Together Compiler 在流量漂移时重新编译，智能体、持久化引擎和集成机制在循环中协同工作。

TKCC 的核心洞见如下：

1. TKCC 在 agent 优化过程中最大化实验吞吐量并最小化 GPU 空闲时间

‍大多数现有的 agentic 推理优化系统要求 agent 启动并拆除 VLLM、SGLang 或 TRT-LLM 等引擎，以测试每个新实验。然而，引擎启动时间长达数十分钟，严重阻碍了实验吞吐量（见下表）。为此，TKCC 提出了一种“持久化引擎”的新范式：引擎只启动一次，即可热重载任何候选前向计算，无需任何重启。为确保持久化引擎始终有新的优化可供测试，TKCC 会生成多个 agent，持续产生想法，并通过留言板进行通信，以并行推进各自的工作。

阶段	现状（秒）	Together Compiler（秒）
进程 + worker 初始化	93	–
权重加载	50	–
KV-cache 大小设定	21	–
JIT kernel 预热	93	–
自动调优	193	–
API 服务器就绪	10	–
RPC 调用 + Together Compiler 设置	–	1.7
CUDA-graph 捕获	7	7.3
服务就绪总时间	467	9.0

表 1：引擎启动开销高昂

2. TKCC 在测量吞吐量与测量保真度之间取得平衡

‍现有的 agent 优化系统要么迭代式地重新启动推理引擎，导致实验吞吐量低下；要么在推理引擎之外孤立地优化独立 kernel，导致测量保真度差。优化独立 kernel 的系统通常使用随机输入数据对其进行评估。然而，在现代架构使用 MoE 和稀疏 k 注意力等数据相关原语的情况下，输入数据分布会直接影响哪些优化策略可能胜出（见下图）。高保真输入对于有效优化至关重要。TKCC 使用分层持久化引擎来平衡吞吐量与保真度之间的权衡：“快速引擎”加载少量层，适合快速迭代和低方差计时；而“较慢引擎”加载大量层，适合测试优化在真实数据分布下是否依然有效。

图 3：Together Compiler 的两层架构优于其他方案。

3. TKCC 利用自定义成本模型为 agent 选择并行策略（例如 TP、EP、DCP 等），以实现最高性能

现有系统拥有在 SLA 要求下选择推理配置的复杂方法。然而，选择理想配置面临同样的吞吐量与保真度权衡：测量每种并行配置是难以处理的，尤其是因为软件实现尚不成熟。一种朴素的做法是根据原始硬件规格或微基准测试来选择并行策略。然而，这不足以捕捉数据相关的流量特性，例如 MoE 专家不均衡或提示长度分布不均。我们设计了一个成本模型，采用分层测量策略，结合硬件规格、微基准测试和实测前向计算，构建高保真表示，同时快速剪枝配置搜索空间，以支持持续的流量漂移。

图 4：实测布局优于硬件规格的选择，且最佳布局会随并发度变化。

结果

我们从三类不同的基线对 TKCC 进行评估：手工调优的 megakernel、InferenceX 引擎配置，以及来自天气建模、PDE、时间序列和生物模型等不同领域的流行 AI 代码库。

MegaKernel 工作负载

我们首先评估经典的 MegaKernel 工作负载：批大小为 1 的 Llama 1B。该模型架构已被人类专家和传统机器学习编译器充分优化。TKCC 生成的 TPS 高出 1.7 倍，并且随着序列长度增加仍保持这一表现。

图 5：Together Compiler 在 H100 和 B200 上均优于 megakernel 和 CUDA graph 基线

InferenceX AgentX 工作负载

我们在 SemiAnalysis 的 AgentX 基准上评估 TKCC。我们从各推理引擎和硬件平台上前沿模型的最佳已报告开源引擎配置出发。TKCC 在所有设置下都持续刷新性能前沿，相比高度优化的基线最高可实现 2.6 倍的 TPS 提升。¹

我们还专门评估了批大小为 1 的低延迟用例，并在 MiniMax M3.1-Flash 上以 1111 TPS、在 DeepSeek v4.1-Flash 上以 1205 TPS 创下最先进性能。对于这些结果，我们使用成本模型来选择并行配置，而不是使用 InferenceX 配置。我们观察到这种方法带来了加速。

图 6：在大多数模型上，Together Compiler 在每用户速度相同的情况下，每 GPU 可服务更多 token。

‍

图 7：在全部六组模型与芯片组合上，Together Compiler 的每用户速度都快于最佳 InferenceX 配置

跨 AI 工作负载

我们选取了天气建模、PDE、时间序列和生物学领域的流行开源代码库。我们展示了 TKCC 相较于仅使用 Claude Code 配合 /goal 命令的几何平均加速比，说明 TKCC 的原理可跨领域泛化。我们一直将 TKCC 作为超越 LLM 推理的通用 AI 编译器使用。

图 8：在四个模型中的三个上，Together Compiler 取得的加速比大于 Claude Code

多态 AI 系统是下一个前沿

对 Together AI 而言，最令人兴奋的系统挑战是多态推理。推理不再是为单一硬件平台和模型的单一流量形态做优化，流量像金融市场一样持续动态演变，这种动态性开辟了一系列全新的研究问题。

查看我们的论文以了解更多。

如果这些 AI 系统前沿方向令你兴奋，欢迎联系我们！

‍

¹ Trainium2 是在合成的多轮数据集（70k ISL、3.5k 新 ISL 且 95% 命中缓存、700 OSL）上运行的，而非 AgentX，因为我们的实现尚不支持在有限的 HBM 容量上实现更高的并发数。