目录
XDYuanzhuLee

[KernelGen][Nvidia] Add special_round operator with Triton kernel (#3969)

  • repair: rebase special_round onto origin/master, resolve registration conflicts

  • fix: correct import/registration alphabetical order for special_round

  • fix: apply isort+black formatting for special_round registrations

  • chore: retrigger CI for special_round

  • fix: apply black+isort formatting to test_special_round

  • fix: replace nearbyint with rint for CI compatibility

  • fix: use manual round-half-to-even without tl_extra_shim externs

  • fix: apply black formatting to manual round-half-to-even implementation

  • fix: preserve signed zero in round-half-to-even and fix device assertion in midpoint test

  • fix: add decimals support and remove unsupported special_round_ in-place variant

  • Add decimals parameter to special_round kernel, following the same scaling approach used by the existing round operator
  • Remove special_round_ in-place variant: PyTorch does not provide torch.special.round_ as a native function
  • Remove unavailable special_round_ from operators.yaml and registrations
  • Fix duplicate special.round.out in operators.yaml: separate special_round (only special.round) and special_round_out (only special.round.out) entries, following the special_i1 pattern
  • Add decimals test coverage (positive, negative, zero, out variant)
  • Remove benchmark for nonexistent special_round_

Co-Authored-By: Claude Opus 4.7 noreply@anthropic.com

  • fix: reorder special_round entries alphabetically in operators.yaml

  • Update operators.yaml to modify special.log_softmax

Removed KernelGen label and stages from special.log_softmax.

Signed-off-by: Dongxu-H dxhan@baai.ac.cn

  • Add nn.functional label to special.log_softmax

Signed-off-by: Dongxu-H dxhan@baai.ac.cn

  • Remove special_round_out operator

Removed special_round_out operator definition from YAML.

Signed-off-by: Dongxu-H dxhan@baai.ac.cn

  • Add special_round_out operator definition

Added a new operator ‘special_round_out’ with its details.

Signed-off-by: Dongxu-H dxhan@baai.ac.cn

  • Apply suggestion from @Caeruleann

Co-authored-by: wanghairui wanghairui0927@gmail.com Signed-off-by: Dongxu-H dxhan@baai.ac.cn

  • fix: inline _round_half_to_even logic in special_round kernel

The helper function pattern (_round_half_to_even called from @triton.jit) is unique in this codebase and may cause Triton compilation failures. Inline the banker’s rounding logic directly into special_round_func, and remove the incorrect -0.0 preservation (torch.special.round(-0.0) returns 0.0, not -0.0).

Co-Authored-By: Claude noreply@anthropic.com

  • fix: cast to fp32 before multiply in special_round kernel

The original (x * scale).to(tl.float32) performs multiplication in the input dtype (e.g. fp16), causing potential overflow for large scale values. PyTorch’s torch.special.round does all computation in fp32 internally. Cast to fp32 first to match PyTorch behavior: x.to(tl.float32) * scale.

Co-Authored-By: Claude noreply@anthropic.com

  • fix: rewrite special_round kernel with libentry, use fp32 mul + fp64 div
  • Replace pointwise_dynamic with manual @libentry kernel to avoid segfault caused by pointwise_dynamic tensor+scalar out variant bug
  • Use fp32 for multiplication to match PyTorch’s truncation behavior (1.2345 * 1000 = 1234.5 exactly in fp32)
  • Use fp64 for division to avoid 1-ULP errors from fp32 reciprocal approximation (26.0 / 10.0 should be 0x40266666, not 0x40266667)
  • Fix out variant signature: (self, out, *, decimals=0)

All 49 unit tests + 2 benchmark tests pass on NVIDIA H20.

Co-Authored-By: Claude noreply@anthropic.com

  • Update init.py

Signed-off-by: Dongxu-H dxhan@baai.ac.cn

  • Fix tengqm review comments for special_round PR
  • benchmark/test_special_round.py: Use torch.ops.aten.special_round as torch_op for the out variant test, instead of torch.special.round, matching the pattern used by special_i0e benchmark.

  • conf/operators.yaml: Restore accidentally removed kind, stages, and KernelGen label from special_log_softmax entry.

Co-Authored-By: Claude noreply@anthropic.com


Signed-off-by: Dongxu-H dxhan@baai.ac.cn Co-authored-by: Claude Opus 4.7 noreply@anthropic.com Co-authored-by: chx7514 hxchen7514@gmail.com Co-authored-by: Dongxu-H dxhan@baai.ac.cn Co-authored-by: wanghairui wanghairui0927@gmail.com Co-authored-by: yzw1128 2508161484@qq.com Co-authored-by: yzw1128 yzw1128@users.noreply.github.com

2小时前3012次提交

github+banner-20260130

中文版 | English

介绍

FlagGems 是 FlagOS 的一部分。 FlagOS 是一个面向多元AI芯片的开源、统一系统软件栈,旨在打通模型、系统与芯片层, 培育开放协作的生态系统。它支持“一次开发,多芯运行”的工作流,兼容多样化的 AI 加速芯片, 释放硬件性能潜力,消除各类 AI 芯片专用软件栈之间的碎片化问题, 并大幅降低大模型在多种 AI 硬件移植与维护的成本。

FlagGems 是一个使用 OpenAI 推出的Triton 编程语言实现的高性能通用算子库, 旨在为大语言模型提供一系列可应用于 PyTorch 框架的算子,加速模型面向多种后端平台的推理与训练。

FlagGems 通过对 PyTorch 的后端 ATen 算子进行覆盖重写,实现算子库的无缝替换, 一方面使得模型开发者能够在无需修改底层 API 的情况下平稳地切换到 Triton 算子库, 使用其熟悉的 PyTorch API 同时享受新硬件带来的加速能力, 另一方面对 kernel 开发者而言,Triton 语言提供了更好的可读性和易用性,可媲美 CUDA 的性能, 因此开发者只需付出较低的学习成本,即可参与 FlagGems 的算子开发与算子库建设。

特性

  • 支持的算子数量规模较大
  • 部分算子已经过深度性能调优
  • 可直接在 Eager 模式下使用, 无需通过 torch.compile
  • Pointwise 自动代码生成,灵活支持多种输入类型和内存排布
  • Triton kernel 调用优化
  • 灵活的多后端支持机制
  • 代码库已集成十余种后端
  • C++ Triton 函数派发 (开发中)

更多特性细节可参阅特性介绍 文档。

快速入门

供测试的模型

  • Bert-base-uncased
  • Llama-2-7b
  • Llava-1.5-7b

贡献代码

  • 欢迎大家参与 FlagGems 的算子开发并贡献代码, 详情请参考参与项目

  • 欢迎提交问题报告(Issue)或者特性请求(Feature Request)

  • 关于项目的疑问或建议,可发送邮件至contact@flagos.io

  • 我们为 FlagGems 创建了微信群。扫描二维码即可加入群聊!第一时间了解我们的动态和信息和新版本发布, 或者有任何问题或想法,请立即加入我们!

    开源小助手

引用

欢迎引用我们的项目:

@misc{flaggems2024,
    title={FlagOpen/FlagGems: FlagGems is an operator library for large language models implemented in the Triton language.},
    url={https://github.com/FlagOpen/FlagGems},
    journal={GitHub},
    author={BAAI FlagOpen team},
    year={2024}
}

许可证

本项目采用 Apache License (version 2.0) 授权许可。

邀请码
    Gitlink(确实开源)
  • 加入我们
  • 官网邮箱:gitlink@ccf.org.cn
  • QQ群
  • QQ群
  • 公众号
  • 公众号

版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9 京公网安备 11010802047560号