Together Compiler用持续智能体编译提升推理吞吐最高2.6倍

摘要：Together AI 提出面向大模型推理的持续编译系统 TKCC，通过分层持久引擎、并行配置成本模型及智能体爬山循环，持续为模型与流量变化重新生成优化执行路径。论文称其在 Llama 1B 上较手写 Megakernel 最高提速 1.7 倍，并在多款前沿模型上较开源引擎实现最高 2.6 倍 TPS 提升。不过，结果主要来自项目方评测，完整基准配置、搜索成本与跨硬件复现情况仍待验证。

---

TKCC 把推理编译从一次性任务改造成持续优化闭环

Together AI 发布的论文提出 Together Compiler（TKCC），目标是让推理执行引擎持续适应模型版本、架构和流量分布的变化。系统不把编译结果视为固定产物，而是让智能体在保留的运行时环境中反复测量、生成候选配置并执行爬山搜索。

这项工作针对的是推理系统中一个现实矛盾：针对单个算子做离线优化，启动快且容易自动化，但无法完整反映 MoE 路由、动态批处理等数据依赖行为；直接优化端到端引擎能够获得较真实的性能反馈，却要反复承担编译、构建和进程启动成本。

分层持久引擎如何拆解启动与执行成本

TKCC 的关键机制是 Tiered Persistent Engine。它将引擎启动开销与 forward pass 计算解耦，使运行时环境可以跨候选配置持续存在，智能体无需为每次试探重新拉起完整引擎。

这种设计提高了测量吞吐量：优化器能够在同一进程中加载模型状态、切换内核或并行方案，并更快比较实际执行路径。其代价是持久进程会引入状态隔离、内存驻留、配置回滚和资源泄漏问题。若底层编译缓存不能正确失效，旧版本内核、算子或模型权重也可能造成错误复用，因此工程实现必须把配置版本、模型标识和设备状态纳入缓存键。

成本模型负责筛选并行搜索空间

TKCC 引入另一套成本模型，用于选择优化过程的初始并行配置。模型结构、算子依赖和硬件拓扑共同决定 Tensor Parallel、Pipeline Parallel、专家并行及内存布局的可行组合，直接展开所有组合会造成搜索空间爆炸。

成本模型先估算候选配置的预期收益、编译时间和运行成本，再决定从哪些配置开始爬山。这使搜索更接近预算约束下的 Best-First 或分阶段优化，而不是对每个候选方案一视同仁。其局限也很明确：成本估计若偏离真实硬件表现，搜索可能过早收缩到局部最优；数据依赖算子的实际性能又难以仅靠静态模型准确预测。

Agent 闭环的核心是持续获得高保真反馈

TKCC 将智能体置于优化闭环中：智能体读取目标模型与当前引擎状态，提出配置或内核变更，在持久运行时中测量真实 forward pass，再依据结果继续搜索。

与离线 kernel benchmark 相比，这种方法能覆盖 MoE 专家选择、变长序列、动态批处理以及 KV Cache 状态变化带来的实际影响。论文对智能体上下文管理进行了消融，说明让智能体持续携带哪些观察、失败记录和代码状态，会直接影响搜索效率。

不过，Agent 并不天然等同于更好的优化器。历史上下文过长会增加推理成本，还可能让模型受到偶然噪声或错误测量的误导；若缺乏可靠的指标回退和配置回滚，错误候选可能持续污染后续搜索。TKCC 的工程价值在于建立高性能反馈接口，而非证明通用智能体能够自主发现所有最优内核。

性能结果与评测边界

论文报告 TKCC 在 Llama 1B workload 上较高度优化的手写 Megakernel 实现最高 1.7 倍加速，并在 Kimi K3、GLM 5.3、MiniMax M3.1 Flash 和 DeepSeek v4.1 Flash 上，对最佳开源引擎取得最高 2.6 倍 TPS 提升。作者还报告 batch size 1 下的 1111 TPS（M3.1 Flash）和 1205 TPS（DeepSeek v4.1 Flash）。

这些结果说明自动编译不必永远输给专家手写内核，尤其适合模型与流量快速变化的场景。但 TPS 不能脱离 token 长度、输入输出比例、batch size、序列长度和硬件配置解释。高并发吞吐、低并发延迟、首 token 延迟、尾延迟及编译搜索时间属于不同目标，可能出现优化一个指标却恶化另一个指标的情况。

此外，评测由项目方完成，摘要未披露完整硬件矩阵、基线版本、搜索预算、是否预热以及重复实验方差。由于比较对象同时包含手写 Megakernel 和多个开源引擎，独立复现还需要确认编译器版本、算子融合边界、量化设置及端到端数据处理开销。

开发者如何评估这类持续编译系统

对于推理平台团队，TKCC 最有吸引力的部分不是某个孤立内核，而是把编译从发布前步骤变成可持续运行的优化服务。落地时需要重点验证：

1. 持续收益：模型、硬件或流量分布改变后，持久引擎能否快速失效旧方案并重新收敛。
2. 搜索成本：Agent 探索消耗的 GPU 时间、编译时间和额外显存能否被线上吞吐收益覆盖。
3. 回滚能力：错误配置、异常请求或数值不稳定结果是否能够被立即隔离。
4. 可观测性：应分别记录 kernel、engine、batch、sequence length 和硬件条件，避免用单一 TPS 判断优化效果。
5. 隔离与安全：持久状态必须避免跨租户数据泄漏，并防止缓存键遗漏模型版本、量化配置或驱动版本。

TKCC 已用于 Together AI 的生产环境并服务数万亿 token，这说明该方案超越了概念原型。不过，生产规模本身不能替代公开复现；开发者仍应以自身 SLA、硬件和流量分布进行端到端 A/B 测试。

---

消息来源：ArXiv AI (cs.AI) (2026-11-13)

—— 完 ——

主题标签： #Together AI 关注 #持续编译 关注 #LLM推理 关注 #智能体优化 关注 #推理引擎 关注