[Triton] Declare triton>=3.6.0 dependency

[micmelesse]

Motivation

This PR declares aiter's dependency on triton in setup.py. This is standard practice for python libraries. We declare a minimum version of 3.6.0. We remove a lot of ad-hoc code that was branching on triton versions.

Technical Details

Test Plan

Test Result

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

[github-actions]

🏷️ CI Guide

Runs automatically on every PR:

• ✅ Pre-checks (submodule verification, code formatting)
• ✅ Aiter op tests (gfx942 + gfx950)
• ✅ Triton tests (only when aiter/ops/triton/** or related paths are changed)

Extended tests (opt-in via labels):

Label	Tests
ci:triton-355	Run Triton tests on MI355 in addition to MI325
ci:sglang	SGLang integration tests
ci:atom	ATOM benchmark (DeepSeek-R1 + GPT-OSS)
ci:vllm	vLLM benchmark
ci:all	All of the above

Add labels via the sidebar or gh pr edit 2695 --add-label <label>

[Copilot]

Pull request overview

This PR formalizes Triton as an explicit runtime dependency (minimum 3.6.0) and simplifies the Triton/Gluon codepaths by removing legacy version-branching and compatibility shims across kernels and tests.

Changes:

• Add triton>=3.6.0 to install_requires in setup.py.
• Remove Triton version-detection helpers and conditional branches targeting older Triton versions across Gluon/Triton kernels.
• Update Triton op tests to drop Triton 3.5-specific logic/skips and disable AOT usage where incompatible.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
setup.py	Declares Triton (>=3.6.0) as a required dependency for non-Windows installs.
op_tests/triton_tests/gemm/basic/test_gemm_afp4wfp4.py	Removes Triton-3.5 AOT gating; forces use_aot=False for preshuffle path.
op_tests/triton_tests/gemm/basic/test_gemm_a8w8.py	Removes Triton-3.5-specific skip for FP8 split-K lowering.
aiter/ops/triton/gluon/triton_version.py	Deletes version parsing/constants module now made obsolete by the min-version requirement.
aiter/ops/triton/gluon/pa_decode_gluon.py	Removes version-dependent MFMA/logits layout branching; standardizes on >=3.6 layout/shape.
aiter/ops/triton/gluon/gemm_afp4wfp4.py	Removes version-dependent MFMA instruction shape selection.
aiter/ops/triton/gluon/gemm_a8w8.py	Removes version-dependent MFMA shape/width branching; assumes >=3.6 MFMA shapes.
aiter/ops/triton/attention/pa_mqa_logits.py	Drops legacy Triton version branching and unconditionally uses Gluon ASTSource path consistent with min-version.
aiter/ops/triton/_triton_kernels/gated_delta_rule/gated_delta_rule_utils.py	Removes outdated “recommended Triton>=3.2” warning logic.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Dewei-Wang-sh]

some of our customers are still using triton 3.4/3.5 in their production environment.
the branch condition code is needed for now.

[brunomazzottiamd]

some of our customers are still using triton 3.4/3.5 in their production environment. the branch condition code is needed for now.

Hello @Dewei-Wang-sh. Do you happen to know if the customers have plans to update Triton, and what would be a reasonable timeframe for the update? Our team is proposing this PR to reduce maintenance burden. Thanks!

FYI: @azaidy

[brunomazzottiamd]

This PR proposes three sets of changes:

1. Drop support of Triton < 3.6 in Gluon kernels + drop afp4wfp4 AOT:

• aiter/ops/triton/gemm/basic/gemm_afp4wfp4.py
• aiter/ops/triton/gluon/gemm_a8w8.py
• aiter/ops/triton/gluon/pa_decode_gluon.py
• aiter/ops/triton/gluon/triton_version.py
• op_tests/triton_tests/gemm/basic/test_gemm_a8w8.py
• op_tests/triton_tests/gemm/basic/test_gemm_afp4wfp4.py

2. Fix Flash Attention integration:

• .github/workflows/flash_attention_integration.yaml
• aiter/ops/triton/_triton_kernels/flash_attn_triton_amd/bwd.py
• aiter/ops/triton/_triton_kernels/flash_attn_triton_amd/interface_v2.py

3. Improve CI stability with software version pinning (Docker base image, public PyPI packages, AMD Triton package):

• .github/dockerfiles/triton-test.Dockerfile
• .github/requirements/triton-test.txt
• .github/scripts/build_aiter_triton.sh (there's a conflict in this file)
• .github/scripts/install_triton.sh
• .github/scripts/verify_triton_pin.py
• .github/workflows/triton-test.yaml
• setup.py

I'm totally fine with (1) and (2). I did (1) by myself in another branch and it works. I somehow collaborated with parts of (2), it LGTM.

However, there's a comment by @Dewei-Wang-sh stating that we have customers using Triton 3.4 and 3.5 in production environments and that we should keep the version related conditions. This basically invalidates (1) as currently implemented. I'm not sure on how to proceed, personally speaking I'd like to drop Triton < 3.6 to easy maintenance burden.

With respect to (3), I agree with the proposed changes. However, I'd like to have a thumbs up from AITER CI team (CC: @gyohuangxin).

[micmelesse]

@Dewei-Wang-sh We need to standardize on a minimum Triton version. Maintaining version-conditional branches across Gluon kernels adds complexity and makes it harder to reason about correctness. For customers that cannot upgrade to Triton 3.6 yet, they can pin aiter to the commit before this PR. That gives them a stable baseline while they plan their upgrade.

[brunomazzottiamd]

LGTM!

[Dewei-Wang-sh]

lgtm