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