ai china

Triton-distributed 正把通信纳入编译器的职责范围

8 条来源 4 条一手来源 已翻译 2026年7月24号

正文
时尚万科中心外立面上的抖音集团与飞书标识。

时尚万科中心上的抖音集团与飞书标识,摄于 2026 年 6 月 20 日。这张真实的公司所在地照片把编译器故事放回字节跳动的运营环境中,也避开了以抽象图形代指分布式系统的做法。[8]

大型 AI 模型运行中代价高昂的停顿,往往源于算术运算以外的等待:一个加速器要等另一个加速器发送激活值、汇集专家输出,或归约局部结果。NCCL 等库让传输更快,内核则加速矩阵乘法。两者之间仍留着一段棘手的空隙——哪些数据块应当移动,哪些应当计算,两类操作怎样重叠——这里依然常见手写 CUDA 和针对特定工作负载的工程优化。

字节跳动 Seed 正尝试把这段空隙交给编译器处理。其开源 Triton-distributed 项目最初为 Triton 内核语言加入分布式通信原语。2026 年 5 月 2 日,同一团队又介绍了更具雄心的 DITRON:它把分布式程序划分为核级、设备级与任务级分块,再将这些分块映射到集群的内存和网络层级上。[1][2][3] DITRON 并非仓库的正式更名,也不是带标签的发布版本;这个名称指向论文提出的新一代编译器设计。

截至 2026 年 7 月 24 日,公开堆栈同时显露出两条脉络。编译器理念正在扩展到更通用的范围,硬件覆盖面也越过最初的 NVIDIA 路径。然而,证据分布很不均衡:最完整的端到端结果来自 H800 系统;AMD 仅有规模较小的公开评测;Ascend 已经有了详细的源码编译和正确性验证路径;构建代码中也能看到 MACA 支持,却缺少同等级别的公开性能记录。[2][4][5] 这处落差构成了重要的 AI-China 信号。可移植性正从政策愿景进入文件、补丁、测试和编译器接口,距离一致的使用体验仍有明显差距。

第一步是把重叠过程暴露出来

常规分布式执行通常把通信与计算作为独立操作启动。AllGather 先把分片搬到位,通用矩阵乘法随后使用这些数据。若两项操作依次串行,网络耗时会完整显现。熟练的工程人员可以把数据切成小块,在一块数据仍在传输时,着手计算另一块。机器由此承担更多有效工作,调度却会与张量形状、拓扑、集合通信协议和加速器行为紧密耦合。

Triton-distributed 让开发人员可以在近似 Python 的 Triton 代码中编排这套调度。当前仓库提供面向对称内存、远程数据访问、信号与异步任务的底层原语。程序员可以把不同线程块分配给通信和计算,再让它们在一个分布式内核内部协同,集合通信库调用也就不再是一堵内部不可见的墙。[1][3]

最初的论文展示了这种做法的价值。在使用 16 块 H800 GPU 的双节点测试中,作者报告,跨节点 AllGather 加 GEMM 内核相对 PyTorch 加 NCCL 基线的平均性能达到 1.33×,GEMM 加 ReduceScatter 则达到 1.42×。两种方案的性能分别达到手工优化 CUDA 库 FLUX 的约 95.6%96.4%,论文将 FLUX 作为专家级对照。[3]

这些提升只对应论文采用的形状、硬件、软件版本和基线。报告还指出,双节点 MoE ReduceScatter 的扩展表现仍然偏弱,需要专用内核。这个说明揭示了一项实际限制:暴露重叠过程之后,拓扑约束依然存在,工程人员只是在一个更清晰的位置上处理它。[3]

第一种方案的局限也写在仓库里。项目仍把公开接口描述为一组底层原语,更高层原语留待后续发布。[1] 编译器能够帮助专家编写通信与计算重叠的内核,尚未代替专家决定每一种分布式调度。

DITRON 加入三级分块

DITRON 扩大了编译器能够推理的工作单元。它越过单块 GPU 内部的分块,提出三个相互嵌套的层级。[2]

核级(core level),小型静态分块把工作映射到寄存器、共享内存、Tensor Core,以及 NVIDIA Tensor Memory Accelerator 等硬件上,这一层仍接近常见的 Triton 内核编程。在设备级(device level),尺寸更大且可动态变化的分块把数据移动映射到 DMA 或 RDMA 引擎。动态形状对于混合专家模型很重要,因为运行开始前无法得知每个专家会接收多少 token。在任务级(task level),完整工作负载成为一张依赖图,其中的内核可以注册、调度,并融合进一个持久化的“MegaKernel”。[2]

编译器中层随后把 AllGather、ReduceScatter、AllToAll 和 AllReduce 等集合通信操作拆成数据块,将它们与计算分块配对,并插入同步操作。后端再把不依赖硬件的地址、数据访问和信号原语,下层转换为 NVIDIA 的 NVSHMEM、AMD 的 rocSHMEM 等厂商专用方案。论文描述的代码规模约为 59,000 行 Python7,000 行 C++。[2]

它的目标已经超出一套速度更快的集合通信库。库提供的是一组选定的完整操作,DITRON 则试图表达连接这些操作的调度。当新模型架构改变路由、序列并行方式、张量形状,或通信引擎与计算单元之间的理想分工时,这一区别就会显现。原则上,编译器可以重新分块、重新调度程序;固定库则要等待专家再写一个内核。

这也是一项供应链主张。字节跳动 Seed 的基础设施团队明确负责分布式训练、高性能推理、强化学习框架和异构硬件编译。[7] DITRON 正处于这些工作汇合的位置。若中间表示确实可以跨硬件移植,模型团队更换底层硬件专用转换层时,便可以保留更多分布式程序。

性能论证有一条狭窄而实用的边界

DITRON 论文中最清楚的端到端测试,是在 8 块 H800 GPU 上把编译器接入 vLLM,并运行 Qwen3-32B 与 Llama 3-70B。论文称,批大小低于 128 时,未经修改的 vLLM 略快;批大小高于 128 后,DITRON 的吞吐量提升为 5% 至 30%,其中最大增益出现在批量和 token 负载都较高的测试中。任务级 MegaKernel 测试处理了相反的负载区间,也就是单批推理;相对 vLLM,报告的增益较小,为 1.10×。[2]

这种变化规律比单个醒目的平均值更有信息量。工作量充足时,通信与计算重叠才能排成流水线;批量较小时,持久化任务级调度则能收回一部分内核启动与同步开销。合适的策略会随工作负载改变。

AMD 结果带来了积极信号,公开证据仍相对单薄。论文报告,在 8 块 AMD GPU 上,若干融合内核相对 rocBLAS 加 RCCL 达到 1.02× 至 1.38×。在 Qwen3-32B 模块层面,预填充注意力、解码注意力和前馈网络的报告增益分别约为 1.03×1.03×1.07×。[2] 这些数字能够证明后端已经实际运行,却不足以说明所有硬件都能得到相同的优化收益。

作者还报告了生产部署数据:训练中的模型 FLOP 利用率提升超过 10%,每月节省约 500,000 GPU-hours,部分推理服务的端到端增益超过 20%。[2] 这些主张影响重大,同时也属于团队自行报告的汇总数字。论文没有公开工作负载组合、集群拓扑、利用率基线,也没有提供可供独立复现的执行路径,因此这些数字还不能转化为可移植的容量预测。它们适合视作内部应用的证据,无法构成对外部运营者的承诺。

Ascend 展示了可移植性的成本

当前构建指南把中国供应链特有的现实写得十分具体。NVIDIA 安装从 CUDA 与 PyTorch 容器开始。AMD 使用 ROCm、另一套 PyTorch 构建版本及专用启动脚本。Ascend 路径更长:开发人员要从 GitCode 获取 triton-ascend 和一种 SHMEM 实现,使用 Ascend 补丁编译固定版本的 LLVM,编译 AscendNPU-IR,载入 Ascend 工具包环境,最后运行双 rank 的 AllGather 加 GEMM 正确性测试。[4]

这已经是实质性进展。Ascend 越过了路线图上的名称阶段;仓库已经公开依赖项、命令、后端路径与通过条件。各条路径仍未达到同等成熟度。公开的 DITRON 评测没有给出 Ascend 吞吐量、扩展表现、跨模型家族数值覆盖情况,也没有提供可与经过更多检验的 NVIDIA 和 AMD 路径相比的持续集成结果。[2][4]

6 月和 7 月的两次提交把这条边界展示得格外清楚。6 月 29 日的修改修复了 Ascend 类型转换路径,并为用于修补 Triton 的 MACA 代码增加保护条件;MACA 是沐曦的加速器软件栈。[5] 7 月 6 日的修改则要求默认 GitHub 作业跳过 Ascend SHMEM 与 triton-ascend 子模块,因为托管在 GitCode 上的依赖项会让 GitHub runner 超时;Ascend 开发人员需要明确获取这些依赖项。[6]

这项小型 CI 修复正是整个供应链的缩影。硬件可移植性既取决于编译器抽象,也取决于可访问的源码托管站点、固定工具链、厂商库、后端补丁、测试机器,以及能够诊断不同组件接缝问题的维护人员。DITRON 可以减少分布式逻辑的重写量,却无法让这些依赖项消失。

MACA 代表着更早期的信号。当前构建代码会检测平台,也包含带保护条件的 MACA 专用设置;主公开指南仍未提供对应的 MACA 安装、正确性验证或基准测试章节。[4][5] 公开证据只足以支持“后端工作已经出现”,尚不足以支持“四类加速器已达到生产级同等水平”。

怎样证明编译器层具备可移植性

下一项里程碑应当是一张可复现矩阵,另一项孤立的内核纪录还不够。NVIDIA、AMD、Ascend 以及今后的 MACA 需要运行相同的模型形状、并行策略、数值检查和端到端测试系统,同时披露编译器修订版、厂商软件栈、互连、内存用量与尾延迟。Ascend 需要提供超越双 rank 正确性示例的扩展结果,MACA 需要形成有文档记录的用户路径,所有后端都需要由 CI 区分依赖项无法访问与编译器故障。

第二项检验来自维护工作。Triton-distributed 目前带有硬件专用子模块、补丁和构建逻辑。若每加入一种加速器,都要维护一个不断扩张的 Triton 私有分支,并为每个重要模型手工调优内核,编译器只是把碎片化问题向下移动。若共享的中间表示、调度模型与测试套件能够逐渐吸收更多差异,这套堆栈才会成为真正的可移植层。

Triton-distributed 与 DITRON 的意义由此超出了字节跳动自身的 GPU 账单。谈到中国 AI 的硬件限制,人们经常把它描述为芯片供应问题。公开仓库还显示了另一半:每一种可用加速器都需要一条贯通编译器、通信、框架、模型与运维的可靠路径。DITRON 的押注在于,通信调度可以从反复依靠手工技艺的工作转化为共享软件。NVIDIA 结果显示这项押注能够兑现,AMD、Ascend 和 MACA 参差不齐的公开支持情况,则清楚标出了仍待补足的证据。

来源

  1. ByteDance Seed,Triton-distributed 官方 GitHub 仓库及双语 README——项目范围、MIT 许可源码、底层分布式原语、支持目标、安装范围与发布历史。
  2. Size Zheng 等,“DITRON: Distributed Multi-level Tiling Compiler for Parallel Tensor Programs”,arXiv:2605.02953(2026 年 5 月 2 日)——三级分块设计、编译器实现、NVIDIA 与 AMD 评测、vLLM 集成和生产应用主张。
  3. Size Zheng 等,“Triton-distributed: Programming Overlapping Kernels on Distributed AI Systems with the Triton Compiler”,arXiv:2504.19442——最初的编程模型、8–64 个加速器评测、内核对比与论文说明的扩展限制。
  4. ByteDance Seed,官方 Triton-distributed 仓库中的 docs/build.md——截至 2026 年 7 月 24 日,NVIDIA、AMD 与 Ascend 各自的依赖、构建和正确性测试路径。
  5. ByteDance Seed,Triton-distributed 提交 7e1c62c(2026 年 6 月 29 日)——Ascend 转换修复及带保护条件的 MACA 专用 Triton 补丁设置。
  6. ByteDance Seed,Triton-distributed 提交 651a649(2026 年 7 月 6 日)——托管于 GitCode 的 Ascend 依赖项、GitHub CI 可访问性问题与明确的 Ascend 子模块检出说明。
  7. ByteDance Seed,“Infrastructures”——对团队职责的官方说明,涵盖分布式训练、高性能推理、强化学习框架与异构硬件编译。
  8. Wikimedia Commons,“File: Douyin Group and Feishu logos on Fashion Vanke Center 20260620143040.jpg”——TurnOnTheNight 于 2026 年 6 月 20 日拍摄的纪实照片,本文以此作为文章配图。
Previous “风和”开放 1060 亿参数气象服务模型,预警体系仍在模型权重之外

Recommended In ai china

Matched by subject and format