AI 芯片的可移植性，起点小得出人意料。一个模型若要跨云、跨集群、跨加速器品牌运行，底层的矩阵乘法、归一化、激活函数、注意力内核，以及数百种不那么受瞩目的张量运算，首先都要在实际硬件上给出可接受的结果。
FlagGems 是中国让这一层走向共享的最清晰尝试。FlagOS 社区的开源库位于常用的 PyTorch 调用与多种加速器后端之间，以 Triton 编写的内核替换其支持的 ATen 操作。这项承诺颇具吸引力：模型代码保留熟悉的形态，硬件专属工作交由下层处理，各家厂商在自身技术栈内从头重写同一算子的重复工程也随之减少。[1]
到 2026 年，真正的变化在于项目把检验这项承诺所需的工作展示得更加完整，这项承诺离完成仍有距离。FlagGems 5.3.0 于 6 月 24 日发布，为选定的矩阵乘法算子新增调优界面，公布更多基准数据，并继续整合后端代码。[2] 将这个版本与要求说明、测试表格和部署文档合在一起看，“随处运行”便从口号变成一组可以逐项检查的契约，契约仍会失效的环节也清晰可见。
共享层位于模型之下、硬件之上
PyTorch 模型通常以矩阵乘法、softmax 或层归一化等操作表达计算。FlagGems 在 PyTorch 的分派系统中注册替代实现，应用仍可调用同一套高层 API，再由该库根据检测到的后端选择相应实现。eager 模式可以直接运行，torch.compile 属于可选项；逐元素代码生成与手工调优的内核分别覆盖算子目录的不同部分。[1][6]
这一层的位置安排带来了明确分工。模型厂商可以在整套应用维持统一代码的前提下，换入不同的受支持实现。内核贡献者可以依照通用的算子语义开发，芯片团队则专注于编译器和后端。2025 年 6 月，FlagGems 加入 PyTorch 生态系统；PyTorch 基金会的项目页面当时称，项目拥有 180 多个 PyTorch 兼容算子，并覆盖十多个硬件平台。[6] 到 2026 年 3 月的 5.0.1-rc0 发布说明，项目列出的官方算子为 255 个，实验性算子为 152 个。[2]
这些数字衡量的是算子目录的广度；等效支持需要另行验证。当前代码仓库称已集成十多个后端，稳定版要求表则列出九个厂商系列，并将 AIPU 和华为昇腾标为仅部分支持。[1][3] 这处差异提醒读者，“后端已接入”“算子已实现”“dtype 已支持”“数值正确”和“在这一工作负载上足够快”是五个不同命题。
依赖链仍带有硬件专属性。在非 Nvidia 平台上，FlagGems 需要厂商提供兼容的 PyTorch 与 Triton 构建，或通过 FlagTree 编译器项目组装相应构建。文档明确说明，FlagTree 只提供 Triton，不包含与之匹配的 PyTorch 构建，部分平台还要补充补丁或配置。[3] 通用内核语言减少了编译器之上的碎片化；编译器、运行时、驱动和设备语义依然存在于它的下方。
测试表格比性能提升的标题更重要
北京智源人工智能研究院（BAAI）2025 年的发布纪要称，FlagGems 相较 PyTorch 的 ATen CUDA 算子平均提升 30% 性能，并已在 Qwen 与 DeepSeek 上完成验证。[7] 这项项目方结果具有参考价值，跨平台预测仍要逐项验证。内核结果受到加速器、编译器版本、张量形状、dtype、内存布局、预热过程、参考实现和测量范围的共同影响，测量范围还要区分单个操作与整个模型。
FlagGems 自己公开的结果将这一范围展示得格外清楚。文档按平台划分标签页，并在算子层面记录准确性、性能、通过、失败、跳过、缺失实现、dtype、编译器和时间戳。[5] 以公布的 Ascend 测试为例，表中把通过、失败、跳过与未找到四种结果分别列出，完整保留了一个耀眼的平均值会掩盖的差异。其他标签页使用的编译器后端和测试日期也各不相同。[5]
证据应当细到这一层。速度更快的算子一旦数值误差超出容差，性能收益也就失去意义。准确的内核如果没有覆盖模型的热点路径，对端到端延迟的影响也微乎其微。在单一固定形状上表现出色的结果，未必能延续到 batch size 或 sequence length 变化之后。5.3 版针对部分矩阵乘法开展的 FlagTune 工作，正面回应了最后一个问题：性能要在真实部署中发挥作用，往往要针对实际服务的张量形状搜索并缓存配置。[2][4]
算子列表还划出第二条范围。条目带有 Stable、Beta、Alpha 等成熟度标签，其中既有标准 ATen 操作，也有融合内核或框架专用内核。[5] 目录总数之外，团队还需要工作负载追踪。需要查清的是：这个模型在这些形状和 dtype、这一并发度下调用了哪些操作，以及每次调用由哪个实现处理。
“启用”的实质是一项部署操作
基本使用方式几乎不费力：导入软件包后全局启用，或使用限定范围的上下文管理器。操作控制项解释了限定范围为何通常更加安全。用户可以包含或排除指定算子，记录实际运行的 FlagGems 函数，查看选中的厂商，也可以通过 GEMS_VENDOR 环境变量强制指定后端。指南警告，强制指定错误的厂商会引发运行时错误。[4]
这些控制手段的用途超出了对早期项目的调试。选择性启用划出回滚范围。若某个算子在目标技术栈上速度较慢或数值结果存疑，工程师可以让库的其余部分继续生效，同时让该操作回到参考实现路径。使用日志由此记录实际替换了什么，比安装包理论上能够替换什么更有证据价值。[4]
进程拓扑还会带来另一处陷阱。在分布式 vLLM 推理中，只在启动进程启用 FlagGems 仍然不够，因为每个工作进程都要初始化该库；否则会出现远端工作进程悄然继续使用默认实现的情况。项目对 Megatron 的指南同样直白：过早启用该库会影响数据加载，因此建议把加速限定在前向与反向计算范围内，并指出更大范围的启用测试相对不足。[4]
这些细节改变了可移植性的评估方式。在一块开发 GPU 上成功导入，只能证明软件包安装无误。至于每个生产工作进程是否加载了相同内核、回退是否留有记录、目标模型在替换实现后是否保持精度，都要单独核验。可信的验收运行需要逐工作进程启用日志、以参考实现为基准的算子级正确性检查、代表性形状扫描、热态与冷态延迟、并发下的吞吐量，以及端到端质量检查。
中国加速器的主线正转向软件协作
中国加速器离彼此可互换仍有距离，FlagGems 的作用更窄，也具有更持久的潜力：它为加速器厂商、框架工程师和模型部署团队提供一个共享空间，让各方围绕算子语义展开讨论，并发布能够直接运行检验的证据。项目贡献者已来自 BAAI 及多家芯片、编译器和基础设施团队；在 FlagOS 中，这个库与编译、通信、训练与推理、迁移、评估等独立组件并列。[7]
这种分工是一种坦诚的架构选择。集合通信、调度、内存容量、网络拓扑、模型转换和供应情况仍由其他层处理。不过，如果每种新加速器都要维护一套私有内核库，即使共享层只覆盖一部分，也能减少重复工程，并把缺失支持明确呈现出来。战略价值主要来自一个共同维护面，覆盖率、回归和厂商特例可以在这里相互比较；单次基准胜利居于次要位置。
因此，后续证据应落在几项朴素指标上。关注公开平台表格能否纳入更新、更易复现的结果，并减少原因不明的失败；Alpha 和 Beta 算子能否在模型级测试中走向成熟；PyTorch、Triton 或 FlagTree、驱动和框架的版本矩阵能否更容易复现；下游运行时能否保持源码原样并完成初始化与回退。来自多个后端生产工作负载的证据，比又一个汇总加速数字更有分量。[3][4][5]
FlagGems 最有力的贡献，是让“可移植性”成为可证伪的命题。同一项 PyTorch 调用如今可以进入共用分派层，但每个后端仍须按算子、dtype、形状和版本逐一证明等效性。这个过程少了“编写一次，随处运行”的魔法色彩，却正是异构计算体系走向现实的方式。
来源
- FlagOS 贡献者，《FlagGems》——官方代码仓库，涵盖架构、功能、后端范围与 Apache-2.0 许可证。
- FlagOS 贡献者，《FlagGems releases》——官方版本历史，包括 2026 年 3 月的算子数量，以及 2026 年 6 月 24 日 5.3.0 版的变更。
- FlagOS 社区，《Requirements》——官方支持平台表，以及 PyTorch、Triton、FlagTree 和厂商构建之间的依赖边界。
- FlagOS 社区，《Use FlagGems》——关于算子选择、日志记录、厂商检测、调优和分布式框架集成的官方控制说明。
- FlagOS 社区，《Benchmark Results》——按平台、编译器和时间戳整理的公开算子级准确性与性能表。
- PyTorch 基金会，《FlagGems 加入 PyTorch 生态系统：由 Triton 驱动、面向通用 AI 加速的算子库》（2025 年 6 月 25 日）。
- 北京智源人工智能研究院，《跨芯片 AI 算子库 FlagGems 正式加入 PyTorch 基金会生态》（2025 年 6 月 28 日；中文一手资料及封面照片来源）。