深度学习AI 应用【免费下载链接】triton-windowsFork of the Triton language and compiler for Windows support and easy installation项目地址https://gitcode.com/gh_mirrors/tr/triton-windows点击查看免费下载Triton 社区在 2024-01-24 的开发者例会对应本仓库 docs/meetups/01-24-2024/notes.md中围绕第三方后端3rd party backend重构这一核心议题展开讨论目标是通过共享 IR 与 Pass、统一后端接口、out-of-tree 插件化加载的方式让 AMD、Intel XPU 等第三方后端在不改动 Triton 主源码的前提下接入编译流程。本文以该例会纪要为主线结合当前仓库中 setup.py、python/triton/backends/、CMakeLists.txt 与 third_party/ 的实际实现系统梳理后端重构的设计目标、落地机制、AMD/Intel 进展与遗留工作帮助读者理解并动手接入自己的 Triton 后端。例会背景与议程总览本次例会2024-01-24的议程共四项前两项聚焦后端生态第三方后端重构进展更新介绍以后端共享 IR/Pass为核心的重构方案目标是让第三方后端无需复制 NVIDIA 代码、也无需改动 Triton 主源码即可并行演进AMD 后端经验分享原计划由 AMD 团队介绍其在重构后后端上的实践与新的协作流程但因时间原因跳过顺延至 2024-02-20 例会Intel XPU 后端恢复为第三方模块的计划讨论将 Intel XPU 后端重新以第三方模块形态纳入仓库的前提条件、维护成本评估与上游upstream沟通安排开放讨论。因此本文的核心事实基线即为会议纪要的这三条主线下文将逐条展开并用当前仓库代码逐一印证其最终落地形态。第三方后端重构的核心设计共享 IR、共享 Pass、零源码侵入会议纪要首先给出重构方案的四条关键设计原则这四条原则在当前仓库中均有直接对应的实现证据原则一后端共享 Pass 与 IR避免分叉和重复Backends are passes and IRs are shared by the backends to avoid divergence and duplications so that developers do not have to change the Triton source code即所有后端共享同一套 MLIR 层级的中间表示与 Pass 基础设施TTIR / TTGIR后端只需要关注自己特有的方言、转换与代码生成部分。当前仓库中核心 IR/Pass 位于 include/triton/Dialect/Triton/、include/triton/Dialect/TritonGPU/ 与 lib/Dialect/、lib/Conversion/而 NVIDIA、AMD 后端仅保留各自的 third_party/nvidia/ 与 third_party/amd/ 子树其中只含后端特有的方言、转换和驱动代码这正是共享主干 后端增量结构的直接体现。原则二通过 setup.py 中的环境变量发现后端目录To discover backend forks in directories, put environment vars in setup.py.这一原则在 setup.py 中被实现为BackendInstaller机制树内in-tree后端通过BackendInstaller.prepare()扫描 third_party/ 目录并要求后端目录下必须存在backend/compiler.py与backend/driver.py见 setup.py 的断言树外out-of-tree后端通过环境变量TRITON_PLUGIN_DIRS发现该变量是一个以分号分隔的插件目录列表每个插件目录下需要存在backend/name.conf文件来声明后端名称见 setup.py 的copy_externals()在编译期setup.py 会把这些后端分别以-DTRITON_CODEGEN_BACKENDS树内和-DTRITON_PLUGIN_DIRS树外传给 CMake。以当前仓库默认配置为例setup.py末尾会执行backends [*BackendInstaller.copy([nvidia, amd]), *BackendInstaller.copy_externals()]即默认构建 NVIDIA 与 AMD 两个树内后端同时额外接入用户通过TRITON_PLUGIN_DIRS提供的任何树外后端。原则三后端可自由链接任意库无需复制 NVIDIA 代码Backends can link whatever library they want, they dont need to copy paste Nvidia code.CMake 层面对此的支撑是 CMakeLists.txt 中的插件化构建流程对每个TRITON_CODEGEN_BACKENDS中的后端执行add_subdirectory(third_party/${CODEGEN_BACKEND})对TRITON_PLUGIN_DIRS中每个插件目录则读取backend/name.conf中的插件名并把构建输出放到${TRITON_BINARY_DIR}/third_party/${PLUGIN_NAME}下。每个后端/插件拥有独立的CMakeLists.txt可以自由链接自己需要的库。例如third_party/nvidia/CMakeLists.txt 负责构建 NVIDIA 方言库lib/Dialect与转换库lib/TritonNVIDIAGPUToLLVMthird_party/amd/CMakeLists.txt 同样只声明 AMD 侧特有的TritonAMDGPUDialect、TritonAMDGPUToLLVM等库。两端后端的backend/目录third_party/nvidia/backend/ 与 third_party/amd/backend/均只包含__init__.py、compiler.py、driver.py等 Python 层文件没有互相复制对方代码。原则四NVIDIA 与其他后端使用同一套 API不做特殊化Nvidia uses the same API as other backends ... No special casing for Nvidia code.这一原则在 Python 层通过 python/triton/backends/compiler.py 定义的抽象基类BaseBackend落实任何后端包括 NVIDIA都必须实现supports_target()、hash()、parse_options()、add_stages()、load_dialects()、get_module_map()等抽象方法。NVIDIA 后端的实现即 third_party/nvidia/backend/compiler.py 中的CUDA类它从triton.backends.compiler导入BaseBackend, GPUTarget, Language与 AMD 后端同构。后端发现与注册流程由 python/triton/backends/init.py 完成默认路径通过 Pythonentry_points()中grouptriton.backends的入口点发现后端对应 setup.py 注册的triton.backendsentry point快速路径设置环境变量TRITON_BACKENDS_IN_TREE1时直接扫描triton.backends命名空间下的目录只加载树内后端跳过可能较慢的 entry point 发现。此外examples/plugins/README.md 还展示了更深一层的 out-of-tree 扩展方式通过TRITON_PASS_PLUGIN_PATH加载编译期插件.so配合knobs.runtime.add_stages_inspection_hook在 kernel 代码中动态插入/覆盖 Pass全程无需修改或重新编译 Triton 核心——这与例会纪要开发者不需要改动 Triton 源码的目标一脉相承。接口契约BaseBackend抽象基类要让一个新后端被 Triton 正确发现与调度其compiler.py必须遵循 python/triton/backends/compiler.py 定义的抽象接口其中关键方法含义如下抽象方法职责实现示例supports_target(target: GPUTarget)静态判定该后端是否支持给定GPUTargetbackend名、arch、warp_sizethird_party/nvidia/backend/compiler.py 中CUDA.supports_target判定backend cudahash()返回后端唯一标识参与编译缓存 key各后端基于自身版本/选项计算parse_options(options)将运行时传入的 options 字典解析为后端自定义对象可做合法性检查与目标相关启发式NVIDIA 后端对 num_warps、num_stages 等选项的解析add_stages(stages, options)按顺序向stages字典填充编译阶段如ttir、ttgir、llir、ptx每个阶段是(src, metadata) - str/bytes的函数见make_ttir/make_ttgir/make_llir/make_ptxload_dialects(context)向 MLIR context 加载后端特有的方言如 AMD 的TritonAMDGPUDialectget_module_map()返回接口模块 - 设备特有实现的映射如triton.language.extra下的设备语言扩展与此同时驱动层需继承 python/triton/backends/driver.py 中的DriverBase负责设备发现、launch 与运行时交互。python/triton/backends/init.py 中的_find_concrete_subclasses()会要求compiler/driver模块中恰好存在一个抽象基类的具体子类否则抛出运行时错误这保证了接口的一致性。运行时安装布局安装期注入在安装阶段setup.py 的get_package_dirs()/get_packages()会把每个后端目录注入为triton.backends.name包把后端的language/目录注入为triton.language.extra.*把tools/目录注入为triton.tools.extra.*而add_link_to_backends()setup.py则对外部插件创建符号链接使develop/editable_wheel等命令能在不重新打包的情况下即时生效。因此运行期看到的triton.backends.name包本质上是在构建/安装时从third_party/name/backend注入的——这与当前仓库中 python/triton/backends/ 目录只保留基础骨架文件的现象完全吻合。AMD 后端重构经验从跳过到模块化设计例会纪要第二条议题原为 AMD 团队分享重构后后端的使用体验与新的协作流程但因时间不足被跳过明确说明将在 2 月例会上覆盖。对照 docs/meetups/02-20-2024/notes.md可以确认该议题在 2024-02-20 例会上的实际落地结论AMD 团队分享了重构后的 AMD 后端设计新设计是模块化的减少了上游 Triton 中的杂糅clutter与重复duplication后续仍需推进回归测试与安全 runner 的搭建工作。当前仓库中 AMD 后端的模块化结构清晰可见third_party/amd/ 下分为backend/third_party/amd/backend/compiler.py、driver.py与driver.c实现 HIP 后端编译与启动include/TritonAMDGPUDialect、include/TritonAMDGPUToLLVM、include/TritonAMDGPUTransforms与对应的 third_party/amd/lib/ 实现language/hip/HIP 语言扩展注入为triton.language.extra.hip。此外测试与回归方面test/Conversion/amd/ 下集中了tritongpu_to_llvm.mlir、async_ops_to_llvm.mlir、amdgpu_membar.mlir等大量 AMD 专属 lit 测试test/TritonGPU/amd/ 则覆盖accelerate-amd-matmul-mfma.mlir、amd-warp-pipeline.mlir等变换测试——这正是例会纪要中需要继续推进回归测试的仓库侧印证。Intel XPU 后端恢复为第三方模块的路线图例会纪要第三条议题记录了 Intel XPU 后端重新以第三方模块形式回归的计划并明确了三项关键决策上游前提条件Prereqs to upstream需要综合评估系统硬件与软件栈性能目标约为 NVIDIA 的~80%达到后才允许上游合入upstreaming。这里80% 性能是例会纪要中 Intel 团队自述的目标门槛属于社区讨论内容仅供参考不代表本仓库的实测数据AI 研究价值评估需要评估该后端对 AI 研究的有用程度因为它直接影响后端维护成本范围界定没有将移动端mobile后端上游化的计划Intel 将与 OpenAI 进行线下讨论以决定后端是否作为 in-tree仓库内模块长期维护。从当前仓库状态看Intel XPU 后端尚未作为树内模块出现在 third_party/中目前只有nvidia、amd、proton、f2reduce这与其第三方/外部模块的定位一致。若要以 out-of-tree 方式接入可遵循前文所述流程将后端目录组织为backend/name.confbackend/compiler.pybackend/driver.py并通过环境变量TRITON_PLUGIN_DIRS提供给 setup.py 与 CMakeLists.txt 的插件构建流程。遗留工作与后续演进会议纪要同时点名了两项尚未完成的重构工作它们在后端重构蓝图中属于共享主干部分LLVM IR 转换的可复用模式重写reusable pattern rewriters即把 lib/Conversion/TritonGPUToLLVM/ 中的各 Op 到 LLVM 的转换逻辑进一步抽象为可被多个后端复用的 rewrite pattern降低 TritonGPU 中的状态性statefulness复杂度计划通过从基类 pattern 继承inherit from base pattern来简化 lib/Dialect/TritonGPU/ 与 lib/Dialect/TritonNvidiaGPU/、third_party/nvidia/lib/Dialect/、third_party/amd/lib/Dialect/ 中相关 Pass 的公共逻辑减少重复实现。这两项工作与共享 IR/Pass、避免重复的总体原则完全一致也与后续 2 月例会中 AMD减少杂糅与重复的结论相互印证属于后端生态长期演进的关键路径。小结从例会纪要到可落地的后端接入路径2024-01-24 例会纪要虽然篇幅简短却勾勒出 Triton 后端生态的完整蓝图本仓库当前代码正是这份蓝图的落地实现共享主干TTIR/TTGIR 与 Pass 基础设施集中在 include/triton/ 与 lib/所有后端共用统一接口python/triton/backends/compiler.py 的BaseBackend与 python/triton/backends/driver.py 的DriverBase定义契约NVIDIA、AMD 一视同仁插件化构建setup.py 的BackendInstallerTRITON_PLUGIN_DIRS、CMakeLists.txt 的TRITON_CODEGEN_BACKENDS/TRITON_PLUGIN_DIRS支持树内与树外后端并行演进生态现状NVIDIA、AMD 已作为树内后端third_party/nvidia/、third_party/amd/Intel XPU 按纪要规划以第三方模块形态推进移动端后端明确不上游化。对于希望接入自有硬件后端的开发者最小可行路径是在独立目录中创建backend/name.conf、backend/compiler.py继承BaseBackend、backend/driver.py继承DriverBase设置TRITON_PLUGIN_DIRS指向该目录然后通过 setup.py 的 editable 安装add_link_to_backends会自动建立符号链接完成接入——整个过程无需改动 Triton 主源码这正是例会纪要所确立的零源码侵入后端生态的直接收益。赞分享深度学习AI 应用【免费下载链接】triton-windowsFork of the Triton language and compiler for Windows support and easy installation项目地址https://gitcode.com/gh_mirrors/tr/triton-windows点击查看免费下载相关推荐Triton 2026-01-06 社区会议纪要解读triton-shared 架构无关 Lowering 演进与插件系统基础设施Triton 2026 01 06 社区会议纪要解读triton shared 架构无关 Lowering 演进与插件系统基础设施 本篇技术指南基于 Trit深度学习AI 应用Node.js 后端架构指南基于TypeScript的实践教程Node.js 后端架构指南基于TypeScript的实践教程 本教程将引导您深入了解由Janishar维护的 nodejs backend architec后端API网关示例工程从零构建Meetily实时会议纪要系统RESTful API与后端架构全解析从零构建Meetily实时会议纪要系统RESTful API与后端架构全解析 Meetily作为一款开源本地会议纪要生成工具其核心价值在于完全本地化运行的A人工智能AI 应用桌面应用语音本地部署上一篇2025终极指南IDM激活脚本免费解锁完整教程下一篇猫抓cat-catch浏览器资源嗅探的终极解决方案三步搞定网页资源下载创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考