先看证据
把机制串起来
大模型推理本质上是在 GPU 上执行大量矩阵运算，而现有的推理引擎（如 vLLM）通常使用固定的算子模板。Together Compiler 的核心在于它不再将引擎视为“黑盒”，而是通过 AI Agent 实时改写并热更新推理代码，使其能随着用户真实流量特征（如 prompt 长度、MoE 专家激活规律）的变化动态适配。
TKCC 抛弃了重启动引擎的笨重范式，通过 RPC 机制将 Agent 生成的候选算子动态注入到存活的 serving 引擎中。它构建了一套“两级评估体系”：先由轻量级层快速筛选，再在完整模型层验证性能。为了实现这一跨度，系统实时热替换前向传播函数指针并重捕获 CUDA Graph。其本质是利用 Agent 的代码生成能力，将静态图优化转化为由真实流量驱动的持续进化策略。
['适用于流量形态复杂且长期运行的生产级部署场景。', '不适用于负载极度稳定、无需额外维护成本的简单推理任务。', '应确保 Agent 具备引擎源码访问权，而非仅基于中间表示操作。']
静态优化为何在推理服务中失效
在大型语言模型推理中，算子性能往往极度依赖于输入数据的分布。Together AI 指出，传统的算子调优通常基于预设的随机数据集或固定长度的提示词，但这与生产环境中的动态流量存在严重偏差。在某些生产场景中，不同区域的请求长度分布可能从 70K 到 97K 剧烈波动，而某些客户在短时间内将 P90 输入长度从 18K 提升至 33K。当 kernel 针对静态数据进行预编译后，这些突发的长文本负载会导致算子执行效率急剧下降，例如在一个 MoE 模型的实验中，随机数据下的优化方案在 70K 上下文场景中不仅失去了预期的加速效果，甚至可能因分支预测和内存存取模式的改变而拖慢推理速度。
更严重的问题在于，“启动成本”导致了性能优化的僵局。现有的高性能推理引擎如 vLLM 或 SGLang，每当需要切换 kernel 或重测并行布局时，往往需要重新冷启动引擎。对于动辄数 GB 的权重载入，这种启动时间往往以百秒计，使得工程师难以在实时流量下进行高频次的实验与迭代。Together Compiler（TKCC）试图通过将优化循环解耦，让“实验”与“服务”在同一运行实例中并行，以此解决模型上线后性能随流量“漂移”的问题。
算子热重写与分层测量机制
Together Compiler 的核心逻辑是构建一个持续的编译循环：通过 Coding Agent 自动生成改进的算子方案，并将其通过 RPC 注入到正在运行的 serving 引擎中。与传统做法不同，TKCC 不重启动引擎，而是利用引擎内部的钩子（hooks）来实时替换算子的函数指针，并触发 CUDA グラフ的重新捕获。这种设计极大地提高了实验的吞吐量，根据 Together 的数据，其在相同时间内能够进行的实验尝试次数比传统的引擎重启方案高出 252 倍，将实验反馈循环从小时级压缩到分钟级。
为了平衡实验的准确性与速度，系统采用了“两级筛选”策略。快速筛选层（Fast Tier）仅在 12 层的小型模型片段上测试候选代码，迅速过滤掉效果不佳的方案。通过筛选的候选方案随后进入慢速确认层（Slow Tier），该层在完整 60 层模型和真实生产分布的数据流下运行，验证性能增益是否具有全局性。通过这种策略，TKCC 在测试了比单层方案多 8.1 倍的候选项后，成功捕捉到了比基线快 7.2% 的方案。这种机制确保了 Agent 生成的代码不仅在理论上更快，且能适应复杂的真实推理环境。
并行布局与成本模型的搜索空间管理
除了算子重写，TKCC 还引入了成本模型（Cost Model）来自动化处理并行布局的决策。在推理扩展中，专家并行（EP）、张量并行（TP）和数据并行（DP）的组合配置直接决定了显存和通信开销。该模型并非简单基于显卡的理论算力，而是融合了微基准测试、MoE 专家负载的不均衡分布以及实际请求长度的统计数据。在测试 Kimi K3 模型时，该模型自动选择了不同于传统基线的并行布局，实现了最高 24% 的 TPS 提升。
值得注意的是，在 MiniMax M3.1 Flash 的测试中，TKCC 将并行策略从 TP4 切换到了 TP8。这种切换虽然提升了吞吐，但也意味着对比基准时，TKCC 并非仅仅优化了代码，还调整了集群资源的使用方式。这揭示了一个重要的工程判断：Agent 的优化边界不应局限于“算子优化”，而应涵盖推理集群的系统级参数。通过将“模型架构”与“计算资源分布”视为共同优化的搜索空间，TKCC 在处理不同底层硬件（如 NVIDIA B200 与 AWS Trainium2）时展示了更强的适应性，能够针对不同硬件特性自动寻找最佳的并行维度。
边界、代价与工程判断
尽管 TKCC 取得了引人注目的性能增益（最高 2.6 倍 TPS），但其带来的运维复杂度也不容忽视。将 Agent 深度嵌入到生产循环中，意味着算子的生成过程成了核心基础设施的一部分。在 Together 的实验中，完全交由 Agent 的 naive 方案在某些场景下比人类专家 curated 的知识库方案表现更好，这证明了在高度自动化场景下，人工经验可能成为限制搜索空间创新的阻碍。然而，这也要求团队具备极高的回归测试能力，因为 Agent 生成的算子在理论上存在产生非确定性行为的风险。
当前的评估表明，TKCC 更适合那些流量波动大、且对吞吐量极其敏感的模型服务。对于稳定性要求压倒一切、且流量模式相对平稳的场景，持续编译带来的额外计算开销和潜在的不稳定性可能得不偿失。从系统设计的角度看，TKCC 展示了未来推理引擎的一种演进路径：将编译层从“离线静态工具”变为“实时感知服务”。对于技术负责人而言，未来的挑战在于如何建立一套验证框架，在 Agent 自动优化与服务稳定性之间找到平衡，确保这种持续编译循环不会演变成难以溯源的性能陷阱。