Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Triton] `is_triton_supported()` semantics for non-CUDA Triton backends

Open
  • Is something wrong?
#8,789 8 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python, pytorch
Domain
machine-learning

Research direction

Start with the hardcoded False in accelerator/xpu_accelerator.py and the three call sites listed in the issue: deepspeed/ops/fp_quantizer/fp8_gemm.py, deepspeed/ops/transformer/inference/triton/attention.py, and deepspeed/sequence/cross_entropy.py. The open question is whether the flag means a generic Triton backend or CUDA-tuned kernel safety, so get a maintainer decision before editing. Done means the agreed semantics are implemented and the Liger CE test in tests/unit/v1/sequence_parallelism/test_liger_vocab_parallel_cross_entropy.py passes on XPU.

Written by the indexing model from the issue text.

Description

Background

is_triton_supported() gates every Triton kernel in DeepSpeed, but today it is effectively a
CUDA check: XPU_Accelerator returns False unconditionally (a stub from #4547), and other
accelerators were hard-coded the same way. Triton now has working non-CUDA backends
(pytorch-triton-xpu for Intel GPUs, triton-ascend for NPU), so the question is no longer
"XPU yes/no" but what the flag should mean for any accelerator.

Motivating example (XPU): tensor_parallel.vocab_parallel_ce_backend: "liger" (#8540, #8173)
silently falls back to the PyTorch CE on XPU. With the gate forced on, on 8x Intel Arc Pro B70
(PyTorch 2.14 XPU, Triton 3.8.0, liger-kernel 0.8.4), loss and gradients match the PyTorch
reference and peak memory of LM-head + CE fwd/bwd (vs gather_output=True, hidden 4096, BF16) is:

TP backend="torch" (XPU today) backend="liger"
2 0.58x 0.25x
4 0.29x 0.125x
8 0.15x 0.063x

Proposal

  1. Return True when an XPU device is available and a Triton XPU backend is importable,
    instead of a hardcoded False.
  2. Audit the other call sites, because the flag currently carries CUDA-specific meaning
    (the inference attention comment says "compute capability >= 8.0"):
    • run the FP8 GEMM and Triton inference attention unit tests on XPU, or
    • narrow those call sites to CUDA if their kernels are not device-ready.

Questions for maintainers

  • Should is_triton_supported() mean "a Triton backend exists for this device" (generic), or
    continue to mean "DeepSpeed's CUDA-tuned Triton kernels are safe here"? If the latter, a
    separate capability flag may be cleaner for portable Triton kernels such as Liger's.
Dominant language
Python
Stars
43.3k
Forks
5.1k
Avg merge
4d 20h
Merged PRs (30d)
69

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from deepspeedai/DeepSpeed

All issues in deepspeedai/DeepSpeed

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.