Together AI 推出 Polymorphic Inference，持续编译优化生产推理

Together AI 于 2026 年 11 月 4 日宣布推出 Polymorphic Inference，并引入 Together Compiler 作为其首个实现。这一由智能体驱动的系统会针对不断变化的模型、流量和硬件持续重新调优推理，目前已在公司许多顶级生产推理工作负载以及一些热门无服务器端点上运行。

Together AI 报告称，在涉及 Kimi K3、GLM 5.3、MiniMax M3.1-Flash 和 DeepSeek v4.1-Flash 的测试中，该编译器在不到 24 小时内实现了高度优化的开源基线 1.3 倍至 3 倍的每秒 token 数。这些结果构成了此次发布核心主张的框架：优化可以是一个与部署绑定的持续搜索过程，而不是在发布时冻结的一轮手动调优。

变化的模型、流量和硬件

Polymorphic Inference 是 Together AI 对一种服务基础设施的称呼，该基础设施能够适应更快的模型发布、多样化的架构、不断演变的流量形态和服务级别要求，以及更频繁的硬件变化。与之相对的静态方法则从固定的引擎配置出发。为一种场景调优的配置未必适合另一种场景，尤其是当模型行为和请求分布发生变化时。

公司的生产观察提供了具体例子。Together AI 报告称，某个国家工作时间的提示词达到约 97,000 个 token，而其他地方为 70,000 个；在某次模型发布后的两周内，随着使用转向智能体工作负载，提示词长度上升了 80%。客户突发流量还可能使提示词长度翻倍并降低缓存命中率，从而改变现有配置调优时所处的条件。

该公告还修正了 Together AI 早先对 megakernel（将操作融合进单个内核）的强调。在将早期版本投入生产后，公司得出结论：仅靠融合并非普遍的设计目标：混合专家架构和动态工作负载可能需要不同的技术。围绕固定或随机流量开发的内核同样可能对生产流量校准不当，因为生产流量的数据依赖路由会影响哪些优化胜出。

持续编译如何工作

Together Compiler 将流量形态、模型和硬件作为输入，然后使用智能体为推理引擎生成并测量候选优化。一个持久化引擎只加载模型一次，并热重载候选前向传递，而无需重启整个引擎。并行智能体生成候选并通过消息板通信，在其他智能体推理或使用工具时保持实验排队。

两个测量层级在实验量与真实性之间取得平衡。快速引擎加载部分层以进行快速迭代和低方差计时；较慢的引擎加载更多层，以测试候选在真实数据分布上是否站得住脚。一个独立的成本模型结合硬件规格、微基准测试和实测前向传递，在智能体花时间优化候选之前剪枝并行配置搜索。

技术论文称，胜出的候选在可被服务之前要经过 KV 缓存污染和输出质量的验证测试。这些检查在优化预算耗尽后运行，此时最终源代码已准备好集成到服务引擎中。

发布帖中的启动对比报告称，其现状序列达到可服务状态需要 467 秒，而使用 Together Compiler 的设置只需 9.0 秒。这些数字涵盖的是优化期间的引擎启动，而非单个请求延迟，并有助于解释为何热重载是该系统实验吞吐量的核心。

评估范围与客户访问

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

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

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

终端客户可通过限量 beta 申请早期访问。Together AI 计划为专用端点提供一键优化，其研究路线图包括按领域、请求、token 和流量负载自适应的推测解码，以及针对异构无服务器流量的跨工作节点和部署配置的动态路由。

此次发布使针对部署的测量——而非普遍最优的内核——成为 Together AI 推理栈的组织原则。对客户而言，眼前的问题是限量 beta 能否在他们自己的模型、流量和硬件上复现所报告的收益，同时通过相同的质量检查——这正是持续编译旨在应对的差异。