Skip to content

Enable the comfy-kitchen Triton backend by default on ROCm/AMD #14861

Description

@liminfei-amd

Problem

On AMD/ROCm the CUDA backend is unavailable (torch.version.cuda is None), so Triton is the only
accelerated comfy-kitchen backend
— but it is disabled by default (--enable-triton-backend
is opt-in, added in #12730). As a result, quantized (INT8/FP8/…) models on AMD fall back to the
eager path, which is much slower and on some RDNA setups even crashes (e.g. comfy-kitchen #61).

It already works — it's just off by default

  • The Triton INT8 path runs correctly on AMD with current ROCm PyTorch (Triton 3.7+), verified
    on gfx1100 (RDNA3), gfx1201 (RDNA4), gfx1151 (RDNA3.5 APU).
  • It's roughly 2× faster end-to-end than the eager fallback (DiT-512: ~2.3s vs ~5.4s on gfx1201),
    and larger at the GEMM level.
  • AMD users currently rely on a third-party node (patientx/ComfyUI-INT8-Fast-ROCM); first-party
    support only needs the default flipped.

Proposal

Enable the Triton backend by default when torch.version.hip is not None (and Triton imports).
NVIDIA is unchanged — CUDA stays the fast path, Triton stays opt-in there. One line in
comfy/quant_ops.py:

if args.enable_triton_backend or (torch.version.hip is not None):

If Triton fails to import it's disabled with a log (existing behavior), so there's no regression.
Users on older Triton (3.5/3.6) should upgrade to 3.7+ (fixes the earlier libdevice.rint issue
upstream). PR ready to open.

cc @0xDELUXA — this is the proposal I mentioned on #14413. Could you validate it on your AMD hardware?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions