企业官网建设流程全解析

Triton 2026 年 1 月社区例会纪要解析：triton-shared 交接、插件系统路线图与 triton-ext 生态

【免费下载链接】tritonDevelopment repository for the Triton language and compiler项目地址: https://gitcode.com/GitHub_Trending/tri/triton

导读

本文围绕 docs/meetups/01-06-2026/notes.md 记录的 Triton 社区例会内容展开，整理三个核心议题：MTIA 团队接手 triton-shared 编译器组件、Triton 插件系统（plugins）的基础设施现状与路线图，以及 kernelize.ai 发起的 triton-ext 共享插件仓库。读者读完后将理解 Triton 官方如何在保持主仓库收敛的同时，通过"可覆盖的编译流水线（overrideable pipeline）"让社区以 out-of-tree 方式实验自定义 pass、方言与自定义算子，并掌握与之一一对应的仓库内源码、示例与测试证据（如 examples/plugins/README.md、include/triton/Tools/PluginUtils.h）。

会议概览：三方议题

2026 年 1 月 6 日的 Triton 社区例会由三个议程构成：

1. triton-shared 进展：Haishan Zhu 与 Nhat Nguyen（Meta）汇报 MTIA 编译器团队对 triton-shared 的维护计划与过去一年的增强。
2. 插件系统基础设施：Corbin Robeck、Puyan Lotfi（Meta）、Thomas Raoux（OpenAI）与 Simon Waters（kernelize.ai）介绍已上游化的插件系统能力与路线图。
3. triton-ext 仓库：Simon Waters 介绍面向社区共享 out-of-tree 插件（pass、方言、后端、语言扩展）的公开仓库，并演示 LoopSplit pass。

以下逐项展开，并辅以当前仓库中的源码与测试佐证。

一、triton-shared：架构无关低化的社区组件迎来新东家

1.1 它是什么

按会议记录，triton-shared 是"Triton 方言的一个子集编译器 pass 集合，用于执行架构无关（architecture agnostic）的低化"。它解决的是 Triton 编译器里大量分析并不适用于 GPU 的问题——例如对非 GPU 架构更有价值的 memory/arithmetic 类低化——为这类逻辑提供一个不属于 GPU 导向主仓库的落点。

1.2 维护权交接：Microsoft Maya 团队 → Meta MTIA 团队

• 该组件此前由Microsoft 的 Maya 团队维护，现已停止维护。
• 正在将维护权移交给Meta MTIA（Meta Training and Inference Accelerator）Triton 编译器团队（Haishan 与 Nhat 即该团队成员）。
• 会议记录特别澄清：社区贡献者曾被 Microsoft 的相关公告弄糊涂，但 triton-shared依然活跃，将在 Meta 的维护与托管下继续发展（更新公告将发布在 triton-language Slack 频道）。

1.3 过去一年落地的增强（会议原话）

1.4 会上 Q&A 要点

• 为什么需要一个独立仓库？大量分析不适用于 GPU（如惠及非 GPU 架构的 memory/arithmetic 低化），需要独立落点。
• 是否考虑贡献回 MLIR 主仓库（如 linalg）？将线下讨论。

二、Triton 插件系统：无需 fork、无需重编译的编译器扩展路径

这是本次例会的核心技术议题。背景是：OSS Triton 的优先级与 OpenAI 内部用例对齐，"该功能的效用是否值得上游维护成本"始终是取舍问题。会议总结了典型痛点与解决方案。

2.1 背景与动机：为什么需要插件系统

• 前沿特性：部分功能只对少数用户有用，却是前沿模型所必需的。
• 实验性功能：部分特性在 fork 上开发维护。
• 两种情况都迫使开发者长期 fork 并保持与主干同步，负担极大；生产环境固定版本外部 fork 的用户，上游没有义务修复其 fork 的故障。
• 模型/内核/硬件特定 pass（例如 warp specialization）需要能在不重编译 Triton 的前提下实验，并最终回流上游。
• 希望让 LLM/autotuner 在不重编译 Triton的情况下访问 pass 与 knobs。

2.2 现有 pass 流水线回顾

• Transformation passes：在同一 IR 内变换。
• Conversion passes：从一种 IR 重写到另一种（例如 TTGIR→LLVM）。
• 现状：新增 pass 需要重编译 Triton 编译器，迭代慢且繁琐。

2.3 新插件框架的设计目标

• 新 API，强制分层（enforces layerings）。
• 功能完整：支持方言（dialects）与自定义操作（custom operations）。
• 核心收益：不需要维护 fork，不需要重编译编译器即可实验。会议给出的示例入口为 plugins 目录。

2.4 核心概念：可覆盖的流水线（overrideable pipeline）

流水线覆盖分为两层：

1. Hooks（钩子）：嵌入后端compiler.py，允许 Python 将插件插入编译器，覆盖add_stages表中的 pass。
2. Native code（原生代码）：由 hook 调用。

内核或库通过设置 hook 提供"调用某 pass"的提示；inspect_stageshook 会覆盖 stages 表中 TTIR 的入口，在其余 TTIR pass 设置前先调用包装器。

典型能力：覆盖既有 pass、运行自定义 out-of-tree pass、运行自定义算子/方言/低化 pass，乃至在运行时导入整个 out-of-tree 后端。

2.5 插件接口与 API

• 使用 PyBind 名称。
• 演示了如何用 API 注册插件、创建 transformation pass（例如在循环 unroll 之后调用某 pass）。
• 自定义方言：新增操作，注册方式与 pass 类似。
• 自定义 out-of-tree 目标（进行中）：后端（如 AMD、Nvidia）目前通过宏静态链接进 Triton；新方案改为从外部共享对象加载，编译期无需静态链接。
• 自定义 DSL 算子（进行中）：更高层、位于 Python 层的顶层 DSL 算子，由 Triton 重写为自身方言后低化执行；proton 插桩 pass 可能改用它（未最终决定），可用于构建补充现有性能工具链的 sanitizer。

2.6 仓库内的落地证据

A. 插件 C++ 接口（include/triton/Tools/PluginUtils.h）

• 定义TRITON_PLUGIN_API_VERSION = 2，加载时校验 ABI 版本；
• TRITON_PLUGIN_API宏用于导出插件公共入口；
• 回调类型：AddPassCallback、RegisterPassCallback、RegisterDialectCallback、AddOpCallback；
• PluginInfo结构体统一描述插件名、版本、pass 列表、方言列表、自定义算子列表与 Triton 版本；
• 插件库必须实现的弱符号入口tritonGetPluginInfo()；
• loadPlugins()从TRITON_PLUGIN_PATHS（冒号分隔的共享库路径列表）加载全部插件。

B. 参考实现（examples/plugins/TritonPlugin.cpp）

展示了一个完整插件骨架：定义TritonGPUMLIRPluginpass（把模块内所有函数重命名，可通过参数指定num_warps），并实现tritonGetPluginInfo()返回静态PluginInfo。

C. 全功能方言插件示例（examples/plugins/DialectPlugins/DialectPlugin）

包含完整的 out-of-tree 方言工程：.td定义（Dialect/Ops/Types/Passes）与.cpp实现，说明插件可携带全新方言。

D. 编译流水线中的 hook 调用（python/triton/compiler/compiler.py）

if knobs.runtime.add_stages_inspection_hook is not None: inspect_stages_key, inspect_stages_hash = knobs.runtime.add_stages_inspection_hook() key += inspect_stages_key

hook 返回的 key/hash 会混入编译缓存 key，保证不同插件配置得到不同缓存条目；stages表由backend.add_stages(stages, options, src.language)填充（compiler.py），随后逐 stage 执行。

E. hook 的运行时开关（python/triton/knobs.py）

class PipelineStagesHook(Protocol): def __call__(self, stages, options, language, capability): ... # Hook for inspecting compiler pipeline stages add_stages_inspection_hook: Optional[PipelineStagesHook] = None

PipelineStagesHook协议规定了(stages, options, language, capability)签名，运行时可整体替换，无需任何核心编译器改动。

F. 端到端示例（examples/plugins/README.md）

• Example 1：用triton-opt -tritongpu-plugin在编译期直接测试插件 pass 对 IR 的修改（tt.func @foo→@bar）。
• Example 2：Python 中通过inspect_stages_hook包装make_ttir，在 TTIR stage 末尾插入插件 pass；并展示了TRITON_PLUGIN_PATHS加载、hook 设置与解除的完整流程。
• Example 3：动态加载make_ttir源码并在add_loop_unroll之后插入插件 pass，实现任意位置插入。
• Example 4：先用dump_stages_hook导出完整compiler_override.py，再以override_stageshook 整体替换 TTIR/TTGIR stage，实现"完全自定义编译流水线"。

G. 测试用例（test/Plugins/test-plugin.mlir）

通过TRITON_PLUGIN_PATHS指定测试插件库，分别验证：加载插件并加-tritongpu-plugin时@bar被改名@foo；仅加载插件不加 flag 时不变；不加载插件时不变。REQUIRES: triton-ext-enabled表明该测试依赖编译时开启扩展支持。

启用插件扩展的编译开关：按 examples/plugins/README.md 中的说明，需设置TRITON_EXT_ENABLED=1（如TRITON_EXT_ENABLED=1; make dev-install-llvm）。

三、triton-ext 仓库：社区共享的 out-of-tree 插件集散地

3.1 定位与目标

Simon Waters（kernelize.ai）提出的 triton-ext 是一个公开存放 out-of-tree pass 的位置，涵盖后端、方言、语言扩展、pass 等，预期大量开发者需要共享的常见 pass 与基础设施；triton-distributed 等项目也有意加入。

3.2 示例：LoopSplit pass

• 动机：FlashAttention 在 causal 场景下会把内层循环调用两次；如果用户写的是带 causal 分支的单一循环，自动拆分会更高效——作者通过自动拆分获得约5% 性能提升。
• 定义：根据某个条件把循环拆成两个循环，并可在后续优化中把两个循环里的条件消除。
• 实现状态：目前仅含 pass，实现仍在演进中。
• 接入方式：triton-ext 提供 pass 数据库，链接libTritonExtPassInfra.so；简化样板代码只需设置 2 个值（扩展名 extension name 与类 class）即可完成注册。
• 注：Simon 的 LoopSplit 写于约一年前，早于 CUDA tileIR 的同类实现。

3.3 会上关于插件生态的 Q&A

• Intel（Ettiore）：已有通用 TTIR pass 修改 X，是否可加进插件基础设施？——可把这里当作 pass 上游化前的"试验场"，LoopSplit 就是原型；也完全可以先落在常规 triton 仓库，插件是更轻量的试验路径（如并发 sanitizer）。
• Meta（Corbin）：许多依赖的 pass 仅对 autotuner 有用、不具备普适性（约 5% 概率有效，非常内核特定），但他人也可能受益；"没有先存在就很难积累足够数据证明其效用"。
• 插件分类：应区分通用插件与（可能针对特定架构的）专用插件，不要混用；仓库已有 backend 目录存放架构特定 pass。
• 动态调参：暴露 pass 启发式策略以便无需重编译地动态调优，可显著提升开发迭代速度。
• 自定义 layout：若 transform pass 依赖不同 layout（如自定义 systolic array vs MMA），可通过 LinearLayout 机制——新增一个 linear layout来满足自定义 layout；目前无现成示例，但已有实验尝试组合两个 linear layout，且至少有一个已构想的用例。

四、总结与可操作建议

本次例会传达的社区方向可以归纳为三条主线：

1. triton-shared 易主不熄火：由 Meta MTIA 团队继续维护架构无关低化组件，Triton 生态"GPU 主仓库 + 架构无关组件"的格局保持稳定。
2. 插件系统是官方推荐的扩展路径：通过 hook 覆盖 stages 表、以共享库承载 pass/方言/自定义算子，做到不 fork、不重编译即可实验，并将成熟成果回流上游。
3. triton-ext 是社区共享层：提供公共插件库与libTritonExtPassInfra.so基建，降低写一个可注册 pass 的样板成本。

对开发者而言，若想在不改动 Triton 核心的前提下做内核特定优化、插桩分析或新硬件支持，可以按以下路径实践：

1. 阅读 examples/plugins/README.md 的四个示例，从triton-opt单测起步；
2. 参照 examples/plugins/TritonPlugin.cpp 与 include/triton/Tools/PluginUtils.h 编写共享库插件；
3. 通过TRITON_PLUGIN_PATHS加载，用knobs.runtime.add_stages_inspection_hook（python/triton/knobs.py）在任意 stage 前后注入；
4. 利用 test/Plugins/test-plugin.mlir 的 FileCheck 模式为自己的插件补充回归测试；
5. 成熟的 pass 再考虑提交上游或加入 triton-ext 供社区复用。

说明：本文基于 docs/meetups/01-06-2026/notes.md 的会议记录整理；会议完整录像链接见原文档末尾（Recording link）。文中性能数字（LoopSplit 约 5%）为会上陈述，属单次实验结论而非普遍承诺。插件系统与自定义后端/DSL 算子能力部分仍处于演进中，具体以当前仓库代码为准。

【免费下载链接】tritonDevelopment repository for the Triton language and compiler项目地址: https://gitcode.com/GitHub_Trending/tri/triton