Together Compiler TKCC 24 小时提速 2.6 倍:常驻引擎拆解

一句话结论:Together Compiler(TKCC)用一组常驻引擎加多智能体循环,把推理优化的实验吞吐量抬高到基线系统的 252 倍,24 小时内在 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。

2026 年 11 月 4 日,Together AI 发布 Together Compiler,一套面向 AI 推理的持续编译系统。它的目标不是再快一点点,而是把推理优化这件事从人工调参变成可循环的自动化搜索。Together AI 称这套系统目前每天在服务数万亿 token。

这篇值得单独写一篇深度稿,原因不在 2.6 倍这个数字本身,而在它揭示的一件事:推理优化真正的瓶颈已经不在算子写法,而在实验迭代速度。

推理优化的瓶颈:模型、负载、硬件三重变量同时在漂

Together AI 先把问题摊开。按照他们的观察,当前推理场景里有三类变量同时在快速变化,任何一环靠人工经验都追不上。

架构在变。Transformer 架构已经过去约 11 年,但 OpenRouter 上排名前十的开源大模型没有两个用同一套架构。MoE 专家分布、稀疏注意力、不同的 KV 布局,每换一个模型就意味着一批优化策略要重新验证。

负载在变。Together AI 服务数千家客户,每天处理数万亿 token,不同客户的流量形状差异很大:批量大小、序列长度、专家不均衡程度、注意力稀疏度、会话时长、领域分布各不相同。

硬件也在变。H100、B200、B300、NVL72、Groq 以及自研硬件各需要不同策略,同一套并行配置换个平台就未必最优。

Together AI 观察到几个可量化的漂移特征:一个国家工作时段的提示词长度可以达到另一个国家的 1.4 倍(97k 对 70k);新模型发布后,提示词长度在两周内会上涨 80%,因为用户从聊天评测转向智能体工作流;突发流量会让提示词长度瞬间翻倍,缓存命中率随之下降。

换句话说,推理服务不是一次调优完就静止的产品,而是一条持续漂移的曲线。

常驻引擎:把 467 秒的启动成本压到 9 秒

已有的智能体推理优化系统有个共同毛病:每次试一个新方案,都要重新拉起再销毁一遍 vLLM、SGLang 或 TRT-LLM 这类引擎。引擎启动动辄几十分钟,智能体大部分时间在等,而不是在搜。

TKCC 的核心设计是把引擎改成常驻。引擎启动一次,之后可以热加载任意候选前向传播,不需要重启。为了让常驻引擎一直有新方案可测,系统会派生多个智能体并行产生想法,通过一块消息板互相通信。

启动成本对比非常直观。

阶段 现状做法(秒) TKCC(秒)
进程与 worker 初始化 93 不需要单独启动
权重加载 50 常驻复用
KV Cache 尺寸计算 21 常驻复用
JIT kernel 预热 93 常驻复用
自动调优 193 常驻复用
API 服务就绪 10 常驻复用
RPC 调用与 TKCC 初始化 无 1.7
CUDA Graph 捕获 7 7.3
到可服务的总时间 467 9.0

从 467 秒到 9 秒,量级上的差别。TKCC 报告称相对基线智能体性能优化系统实验吞吐量提升 252 倍,这个数字主要就来自这里。智能体每试错一次不必付一次重启的代价,GPU 空闲时间被压到很低,搜索空间才有可能被真正铺开。

两层引擎:吞吐量与保真度的取舍

第二层设计解决的是测量本身的矛盾。现有系统要么每次重启引擎,吞吐量低;要么把算子拿出来单独优化,测量保真度低。后者的问题尤其隐蔽:单独优化的算子常用随机输入做评测,而 MoE 和稀疏注意力这类数据相关原语,对输入分布极为敏感,同一个算子在随机输入上领先,在真实流量分布上可能落后。

TKCC 用两级常驻引擎来平衡这件事。快引擎只加载少数几层,适合快速迭代、时序方差小;慢引擎加载更多层,适合验证某个优化在真实数据分布上是否站得住。快引擎负责广撒网,慢引擎负责定生死。

第三层是一套自定义成本模型,用来挑选并行策略,比如张量并行、专家并行、上下文并行。Together AI 认为按硬件规格或微基准直接选配置是不够的,因为 MoE 专家不均衡、提示词长度不均这类数据相关的流量特征根本不在硬件参数表里。成本模型把硬件规格、微基准和真实前向传播测量混在一起,先剪掉大部分搜索空间,再逐步提高保真度。

他们的实测结论挺有意思:按实测布局排出来的最优解,跟硬件规格直接推断出来的选择并不一致,而且最优布局会随并发度变化。

成绩单:2.6 倍、1111 TPS 与 1.7 倍 megakernel

TKCC 对三类基线做了对比:人工调优的 megakernel、SemiAnalysis InferenceX 上已公开的最优引擎配置,以及天气建模、偏微分方程、时序、生物等领域的开源代码库。

评测场景 对比基线 TKCC 表现
前沿开源模型整体吞吐 InferenceX 最优开源配置 最高 2.6 倍 TPS
InferenceX 低延迟 batch size 1 同上 MiniMax M3.1-Flash 1111 TPS
InferenceX 低延迟 batch size 1 同上 DeepSeek v4.1-Flash 1205 TPS
MegaKernel 经典负载 Llama 1B batch size 1 人工调优 megakernel 1.7 倍 TPS,且序列变长后仍保持
实验吞吐量 基线智能体优化系统 252 倍

覆盖的模型包括 Kimi K3、GLM 5.3、MiniMax M3.1-Flash、DeepSeek v4.1-Flash 四个前沿开源模型,硬件上覆盖 H100 与 B200。官方给出的结论是,在全部六组模型与芯片组合上,TKCC 的单用户速度都快过 InferenceX 的最优配置;在多数模型上,同等单用户体验下每张 GPU 服务 token 更多。

低延迟场景那两行数字需要单独看。1111 TPS 和 1205 TPS 的成绩并不是用 InferenceX 配置跑出来的,而是让成本模型重新选了并行配置后得到的。这说明人工与公开基准里沉淀下来的最优配置,在新的优化器面前未必还是最优。

跨领域泛化:天气、PDE、生物模型上的加速

TKCC 的设计并不依赖语言模型特有的结构。Together AI 选取了天气建模、偏微分方程求解、时间序列和生物领域的热门开源代码库,用几何平均加速比对比直接用 Claude Code 加 /goal 命令这一做法。在四类模型中有三类,TKCC 找到的加速幅度更大。

这说明常驻引擎加双层保真度加成本模型这套组合,抽出来的并不是某个垂直领域的技巧,而是把搜索空间铺开、把测量做准这一类通用工程方法。Together AI 也表示已经把 TKCC 当作通用 AI 编译器在用,超出了大语言模型推理的范围。

多态推理:下一阶段的题目

Together AI 把更大的问题叫作 Polymorphic Inference(多态推理)。传统做法是针对固定的模型、固定的硬件、固定的流量形状调出一次最优配置,然后希望这个配置能一直扛住。但流量持续漂移这件事本身已经不可回避,最优解的半衰期在缩短。

TKCC 的定位相当于把编译器从一次性工具变成常驻的编译守护进程,流量变了就重编一次,重编的成本被压到 9 秒级的初始化加上搜索时间,而不是几十分钟的重启。相关论文已随博客发布。

需要说明的是,这套系统的价值高度依赖使用者手上有没有可靠的推理引擎可优化、有没有真实的流量形状可建模。对只有单一模型单一硬件的团队,它带来的收益接近于零。对同时服务多模型、多客户、多种硬件的推理平台,思路才真正成立。

相关阅读

常见问题

TKCC 和传统 AI 编译器到底差在哪?

传统编译器面对的是固定输入固定硬件,追求一次编译最优。TKCC 面对的是持续漂移的流量与多种硬件组合,追求的是持续重编译的速度。它的护城河不在单个算子写得更好,而在 252 倍的实验吞吐量让搜索空间能被真正遍历。

2.6 倍 TPS 是所有模型都能拿到吗?

不是。官方表述是最高 2.6 倍,四个前沿开源模型各自的提升幅度不同,低延迟场景的最优成绩由 MiniMax M3.1-Flash 和 DeepSeek v4.1-Flash 拿到。Llama 1B 这种被人工优化透了的经典负载上提升是 1.7 倍,基准已经很高的模型反而空间更小。

普通团队能用上 TKCC 吗?

目前是 Together AI 自家的推理服务在用,没有开放下载。方法论层面可以借鉴的是两点:把引擎做成常驻并支持热加载,以及用快慢两层引擎分开处理迭代速度与测量保真度这两件冲突的事。

小结

Together Compiler 把推理优化从手工作业改写成持续编译循环,467 秒到 9 秒的启动差距是 252 倍实验吞吐量的直接来源,2.6 倍 TPS、1111 与 1205 TPS 则是这套循环跑出来的结果。它更值得关注的不是快了多少,而是把什么时候重新编译一次这件事的成本压到了可以随时做的水平。