Together Compiler：AI推理的持续编译新范式

AI推理的部署正在从“一次优化、长期使用”转向“持续编译、动态适应”。Together团队推出的Together Compiler正是这一思路的产物：它利用智能体（agents）和持久化引擎（persistent engines），在不到24小时内完成对开源模型的优化，并声称在流量变化时能带来最高3.7倍的吞吐量提升。

为什么AI推理需要“持续编译”

传统推理优化往往是一个离线、一次性的过程：模型上线前进行量化、算子融合、内核调优，部署后便固定下来。但真实世界的流量模式、输入长度分布、并发请求数时刻在变，静态优化策略很容易在流量波动时失效，导致GPU利用率下降或延迟飙升。

Together Compiler的核心主张是，编译不应是部署前的一次性动作，而应成为伴随模型生命周期持续运行的过程。它通过智能体自动探索优化空间，并利用持久化引擎保留和复用编译结果，从而在流量特征变化时快速重新调优，而不是从头再来。

智能体与持久化引擎如何协同

Together Compiler的架构可以拆解为两个关键组件。

智能体驱动的优化搜索

智能体负责在编译过程中自动做出决策，例如选择量化策略、调整内存布局、匹配不同的内核实现。相比人工调参或固定规则，智能体能根据模型结构和目标硬件的反馈信号进行迭代搜索，缩短找到较优配置的时间。官方给出的时间窗口是“不到24小时”，这意味着对于开源模型，从接入到获得优化版本可以在一天内完成。

这里的“智能体”并非单体大模型，而是指一组能感知编译反馈、调用工具并迭代决策的自动化程序。在推理编译语境下，常见决策包括算子融合方式、量化位宽与粒度、KV Cache 布局、批处理调度策略以及为特定 GPU 选择或生成内核实现。智能体通常以编译耗时、显存占用、吞吐和尾延迟为奖励信号，在搜索空间中逐步收敛，而不是穷举所有组合。与传统的自动调优（如基于代价模型的 TVM AutoTVM）相比，智能体式搜索更强调根据运行时反馈动态调整搜索方向，因而更适合模型结构和流量分布频繁变化的场景。

持久化引擎保证连续性

持久化引擎的作用是让编译状态和优化成果得以留存。当流量模式发生变化时，系统不需要从零开始编译，而是基于已有状态进行增量调整。这种设计降低了重新优化的成本，使“持续编译”在工程上可行，而不仅仅是概念上的理想状态。

持久化引擎可以理解为编译产物的状态存储与版本管理系统。它保存的不只是最终生成的二进制内核，还包括中间表示、已尝试的配置、各配置的实测性能数据以及硬件环境指纹。有了这些状态，当输入长度分布或并发水平变化时，系统可以判断哪些优化仍然有效、哪些需要重新搜索，从而只做增量编译而非全量重来。这也带来缓存一致性问题：模型权重、驱动版本或 GPU 型号变化时，必须使失效的编译缓存被正确识别和替换，否则可能加载不匹配的内核导致错误或性能回退。

性能与适用边界

Together Compiler宣称在流量变化场景下可实现最高3.7倍的吞吐量提升。说一下，这一数字来自官方描述，属于理想条件下的峰值表现；实际收益会因模型类型、硬件配置和流量波动幅度而异。

从描述看，该编译器主要面向开源模型的推理优化，这与Together平台以开源模型服务为主的定位一致。对于使用闭源API的团队，其适用性有限；而对于自托管开源模型、且流量特征多变的场景，持续编译的思路具备参考价值。

吞吐量提升倍数在不同基准下含义差别很大。3.7 倍这类数字通常是在特定对比基线（如未针对新流量重新优化的静态编译版本）和特定负载（如输入长度分布发生显著漂移）下测得。评估此类指标时需关注：基线是否经过同等程度的调优、测试的 batch size 与序列长度范围、是否包含编译和重新调优本身的耗时，以及提升是在平均吞吐还是 P99 延迟口径下取得。对于流量平稳、输入分布集中的生产环境，持续编译的边际收益会明显小于波动剧烈的场景。

对推理基础设施的启示

Together Compiler反映了一个更广泛的趋势：推理优化正在从“静态配置”走向“动态服务”。模型部署不再是终点，而是一个需要持续观测、持续调整的过程。智能体在这里扮演的角色，不是替代工程师，而是把重复性的搜索和验证工作自动化，让优化频率能够跟上流量变化的节奏。

另一个值得关注的信号是“24小时”这个时间尺度。它暗示编译优化的门槛正在降低，中小团队也可能以较低的人力投入获得定制化的推理性能，而不必依赖庞大的基础设施团队。当然，实际效果仍需在真实负载中检验，持续编译带来的额外系统复杂度和稳定性风险也不应被忽视。

总结

Together Compiler将智能体搜索与持久化引擎结合，把编译从一次性离线步骤变为持续在线的优化循环，并提出在流量变化下最高3.7倍吞吐提升的目标。它代表了一种务实的工程方向：让推理优化跟上真实流量的节奏，而不是停留在部署那一刻的静态快照。

背景补充

持续编译在工程落地时还需考虑编译与推理的资源争抢问题。重新编译会占用 GPU 或 CPU 资源，若与在线推理共享同一集群，可能推高峰值时段的延迟。常见做法是将编译任务调度到独立节点或利用低峰时段执行，并通过影子流量验证新编译版本后再切流。此外，编译产物的可复现性和回滚机制也很关键：一旦新配置在真实负载下表现不佳，系统需要能快速回退到上一个稳定版本，避免持续优化反而引入稳定性风险。