Together AI 将持续编译引入生产环境推理

Together AI 于 2026 年 11 月 4 日宣布推出多态推理，并将Together Compiler作为首个实现。这个由智能体驱动的系统会针对不断变化的模型、流量和硬件持续重新调优，目前已用于该公司许多主要的生产推理工作负载，以及部分热门无服务器端点。

Together AI 表示，在涉及 Kimi K3、GLM 5.3、MiniMax M3.1-Flash 和 DeepSeek v4.1-Flash 的测试中，编译器在不到 24 小时内实现的每秒令牌数达到高度优化开源基线的 1.3 倍至 3 倍。这些结果凸显了此次发布的核心主张：优化可以成为与具体部署相结合、持续进行的搜索过程，而不是在产品上线时完成一轮手动调优后便固定不变。

不断变化的模型、流量和硬件

多态推理是 Together AI 对一种服务基础设施的称呼，这种基础设施能够适应更快的模型发布节奏、多样化的架构、不断变化的流量形态和服务级别要求，以及更加频繁的硬件变更。与之相对的静态方案则以固定的引擎配置为基础。针对一种场景调优的配置未必适用于另一种场景，尤其是在模型行为和请求分布发生变化时。

该公司在生产环境中的观察提供了具体例证。Together AI 表示，某个国家工作时间内的提示词长度达到约 97,000 个令牌，而其他地区为 70,000 个；在某个模型发布后的两周内，随着使用逐渐转向智能体工作负载，提示词长度增加了 80%。客户流量突增也可能使提示词长度翻倍并降低缓存命中率，从而改变现有配置所针对的调优条件。

此次公告也修正了 Together AI 早先对巨型内核的侧重。巨型内核会将多个操作融合到单个内核中。将早期版本投入生产后，该公司得出的结论是，单靠融合并非放之四海而皆准的设计目标：混合专家架构和动态工作负载可能需要采用不同技术。同样，围绕固定或随机流量开发的内核，也可能无法适配生产流量；在生产环境中，依赖数据的路由方式会影响哪些优化方案能够胜出。

持续编译的工作原理

Together Compiler 将流量形态、模型和硬件作为输入，然后利用智能体为推理引擎生成并测量候选优化方案。常驻引擎只需加载一次模型，便可热重载候选前向传播，无须重启整个引擎。多个智能体并行生成候选方案，并通过消息板相互沟通；当其他智能体正在推理或使用工具时，实验也会继续排队等待。

两级测量机制在实验规模与真实性之间取得平衡。快速引擎只加载部分层，以便快速迭代并获得低方差计时结果；较慢的引擎则加载更多层，用于测试候选方案在真实数据分布下是否仍然有效。另有一个独立的成本模型会结合硬件规格、微基准测试和实测前向传播结果，在智能体花时间优化候选方案之前，先缩小并行度配置的搜索范围。

技术论文称，候选方案胜出后，还须通过 KV 缓存污染和输出质量验证测试，才能用于提供服务。这些检查会在优化预算耗尽后进行；届时最终源代码将准备好集成到服务引擎中。

发布文章中的启动时间对比显示，按现行方案的流程，从启动到提供服务需要 467 秒，而使用 Together Compiler 的配置只需 9.0 秒。这些数字反映的是优化期间的引擎启动时间，而非单个请求的延迟；它们也有助于说明热重载为何是提高系统实验吞吐量的关键。

评估范围与客户使用权限

在引擎对比中，论文采用了截至 2026 年 10 月 30 日领先的开放配置，并在隔离智能体优化效果时，将基线并行策略保持不变。Trainium2 是标准评估工作负载中披露的例外：由于当时的实现尚不支持在可用 HBM 容量下运行更高并发，它使用了合成的多轮数据集。

Together AI 将这些优化结果部分归因于实验吞吐量比基线智能体递归自我改进优化系统高出 252 倍。

除语言模型推理外，论文还报告称，在经过测试的天气、生物学、时间序列和偏微分方程模型上，速度提升达到 1.5 倍至 6.4 倍，同时在所述评估中保持输出逐位精确。

终端客户可通过有限测试版申请提前体验。Together AI 计划为专用端点提供一键优化；其研究路线图还包括能够根据领域、请求、令牌和流量负载进行适配的推测解码，以及针对异构无服务器流量，在工作器和部署配置之间进行动态路由。

此次发布表明，Together AI 推理技术栈的核心原则是针对具体部署进行测量，而不是追求放之四海而皆准的最优内核。对客户而言，当下最重要的问题是：有限开放的测试版能否在自有模型、流量和硬件上重现已报告的性能提升，同时通过相同的质量检查——Continuous Compilation 正是为应对这种差异而设计的。