Together Research 在 AI Native Conf 上宣布了 FlashAttention-4、强化学习 API、ThunderAgent、ATLAS-2 等多项成果。
AI Native Cloud 不仅仅是一个定位声明。它是一个全栈 AI 云，由那些交付了基础 AI 工作（如 FlashAttention 和 ThunderKittens）的研究人员和工程师为 AI 原生用户量身打造。发表这些研究的同一批人，正是运行着我们的客户（如 Cursor 和 Decagon）所依赖的生产系统的人。这种紧密关系难以复制。当一项技术从我们的研究项目中诞生时，我们可以迅速将其从研究转化为生产，并交付这些技术，让客户立即受益。
今天，在首届 AI Native Conf 上，我们宣布了七个研究和产品发布，涵盖三个领域：内核、强化学习和算法推理优化。每一项都代表了从研究到生产管线的巨大进步，可供客户使用。
内核
FlashAttention-4
FlashAttention 是驱动当今许多大规模前沿语言模型的注意力引擎。由首席科学家 Tri Dao 领导的研究项目持续突破注意力运行速度的极限。FlashAttention-4 将新算法与针对 NVIDIA Blackwell GPU 优化的内核协同设计相结合，消除了新的瓶颈，使张量核心保持忙碌。
它比 Triton 快 2.7 倍，比 cuDNN 9.13 快 1.3 倍。对于长上下文工作负载（如视频理解、编码智能体和测试时计算扩展），这能够在最新的 NVIDIA GPU 上以更低的每 token 成本实现更智能的功能。
Together Megakernel
一家领先的实时语音智能体公司向 Together 提出了一个硬性约束：前 64 个 token 的响应时间超过约 100ms 就会破坏对话体验。在他们之前的部署中（使用 NVIDIA B200 GPU），响应时间为 281ms。对于大多数工作负载来说已经很快，但对他们来说还不够快。
Together 的内核团队与他们合作选择了模型架构，然后手工优化了一个 Megakernel 实现，该实现在单个内核中运行整个模型，目标是达到 NVIDIA H100 的 HBM 带宽上限。
最终部署实现了 77ms 的响应时间——性能提升了 3.6 倍，单位经济效益比之前的部署提高了 7.2 倍。Together Megakernel 是开源研究的生产实现，最初与斯坦福大学的合作者共同开发。它拥有与 FlashAttention 相同的研究血统，是硬件-软件协同设计，缩小了理论可能性和实际部署系统之间的差距。
together.compile
产生类似 Together Megakernel 结果的核优化历来需要专家——那些深入理解 GPU 线程块映射、内存带宽限制和硬件特定调优的工程师，而大多数团队并不具备这类人才。together.compile 将这一过程的大部分自动化。
作为 ThunderKittens 的扩展，together.compile 在启动时通过单个函数调用生成优化的核栈——无需修改模型代码。当应用于 Hedra 的 Omnia 视频模型时，together.compile 将 200 帧的生成速度提升了 25%。
在生产环境的 Flux Kontext 基准测试中，使用 together.compile 完成服务器启动并在 17 个分辨率下生成 51 张图像需要 329 秒，而使用 torch.compile 则需要 558 秒：性能提升 41%。启动时间也显著缩短，这对于大规模运行自动扩缩图像和视频生成的团队至关重要。
together.compile 即将在 Together Dedicated Container Inference 中推出。如果您想加入测试版，请联系我们。
强化学习
强化学习 API
Together 的强化学习 API 将完整的 Together 技术栈应用于强化学习训练。为 Together 生产推理提供动力的核、推理优化和研究进展现在直接应用于以 rollout 为主的工作负载——这是主导强化学习挂钟时间的瓶颈。
该 API 为团队提供控制权，而非黑盒。推理和训练作为独立、可配置的层暴露——团队决定 rollout 配置、权重推送频率以及计算运行位置。Together 处理同步和调度；如何运行强化学习的决策仍由您掌控。这种抽象级别让团队能够真正优化其训练循环，而不是围绕他人对强化学习运作方式的假设进行工作。
超过 70% 的强化学习挂钟时间用于 rollout（推理），而这正是 Together 研究计划直接应用的领域。分布式感知推测解码 和 ThunderAgent 都针对提升 rollout 速度的吞吐量和延迟特性，将每项研究进展转化为更快的强化学习训练周期。
剩余的瓶颈是权重分发：在每次训练步骤后将更新后的权重发送到推理节点。在数据中心内，Together 在数秒内将新权重推送到所有推理节点。在全局分布式规模下——跨区域的节点、不同的 GPU 类型——同步在一分钟内完成。
ThunderAgent
强化学习 API 处理基础设施层。ThunderAgent 则解决当被训练和服务的负载本身是智能体时的问题——编码智能体、科学发现智能体、大规模运行的多步推理流水线。
现有的推理系统将智能体工作流视为独立的、无状态请求的序列。这产生了三个叠加问题：
- KV 缓存抖动（工具调用中断执行时重复的上下文重计算）
- 跨节点内存不平衡（某些 GPU 节点过载而其他节点空闲）
- 工具生命周期忽视（Docker 沙箱和网络端口累积而未回收）
ThunderAgent 通过引入一种程序感知的抽象——将每个智能体工作流视为一个具有全局执行视图的一等调度单元——解决了所有三个问题。结果：在分布式 GPU 集群上，智能体服务的吞吐量提升 1.5–3.6 倍，强化学习 rollout 提升 1.8–3.9 倍，磁盘内存节省相比先前最先进系统达到 4.2 倍。ThunderAgent 今日开源，是高吞吐量智能体训练构建的研究基础。
算法推理优化
ATLAS-2
推测解码——使用小型草稿模型提出令牌，由大型目标模型验证——是减少推理延迟最有效的技术之一。当前部署方式的问题：推测器离线训练，作为固定工件发布，随着目标模型更新或流量模式变化而性能下降。重新训练需要数周的流水线工作和大量目标模型激活值。
ATLAS-2 引入了在线训练飞轮，使用接受和拒绝的令牌作为信号，从实时流量中持续更新推测器。新版本的推测器可在不中断服务的情况下热替换到生产环境中。
在已有静态推测器的成熟模型上，ATLAS-2 进一步提升了 1.2 倍的性能。这一差距会累积：静态推测器只训练一次，随着流量分布变化，其接受率会下降。ATLAS-2 持续适应，因此性能随分布变化而提升，而非下降。
阅读关于 Aurora，ATLAS-2 背后的开源框架。
缓存感知的预填充-解码分离（CPD）
长上下文推理的可持续吞吐量提升高达 40%。
标准的预填充-解码分离将计算密集的预填充与延迟敏感的解码分开。但所有预填充——热和冷——仍然竞争相同的容量。在实际流量中，包含 100K+ 令牌新上下文的大型冷提示与包含大部分可重用上下文的多轮请求一起排队。TTFT 下降不是因为热请求需要大量计算，而是因为它们被卡在需要大量计算的请求后面。
CPD 在服务栈中增加了第三层。缓存感知路由器根据缓存命中率对每个传入请求进行分类并相应路由：
冷请求 进入专用的预预填充节点，计算新上下文并填充分布式 KV 缓存
热请求 进入预填充节点，通过 RDMA 获取 KV 块而非重新计算
- 解码节点保持隔离并专注于延迟。
三级 KV 缓存层次结构——GPU 内存、主机 DRAM 和通过 RDMA 连接的集群范围分布式缓存——使得频繁访问的上下文随时间迁移到 GPU。同样的 100K 令牌上下文，首次请求需要数秒计算，预热后只需几百毫秒即可服务。
在 NVIDIA B200 GPU 上，使用混合热和冷长上下文请求的编码智能体工作负载进行评估，CPD 相比标准分离设计将可持续 QPS 提高了 35–40%。
下一步计划
这些公告中的每一项都将有各自的深度解读。但它们有一个值得指出的共同主线。
FA4 中的内核改进直接为未来的 Megakernel 实现提供了依据。ThunderAgent 中的程序感知调度塑造了强化学习 API 处理智能体训练工作负载的方式。ATLAS-2 中的在线学习循环是我们思考任何应在实时流量下改进的系统的模板，而不仅仅是推测性解码器。我们发布的每一部分都成为解决下一个问题的基础设施。
这就是“AI 原生”真正所指的飞轮效应。研究推动平台发展。平台吸引工作负载，这些工作负载暴露出下一个难题。这些问题驱动下一轮研究循环。这种复合效应是真实的，这也是为什么 Together 上可能实现与可用之间的差距往往比其他任何地方都要小。纯基础设施公司可以部署该领域产生的东西。纯研究实验室可以推进该领域的认知。而两者的结合——在生产中运行的研究，以及为研究提供信息的生产——正是我们从第一天起就在构建的，也是上述公告所代表的。
当今正在构建的最苛刻的 AI 应用将需要能够扩展可能性边界的基础设施。这就是我们在 Together 正在构建的。