[FEATURE] Add AMD ROCm platform support with validated Wan2.1 example

.gitignore

@@ -116,6 +116,7 @@ uv.lock
 /benchmarks/aiperf/
 /models
 /data
+model_zoo/
 .vscode
 .idea
 *.pkl

docs/en/attention.md

@@ -246,6 +246,10 @@ pipe_config.dit_config.attention_config = config
 
 **Note on Flash Attention 4**: Flash Attention 4 is optimized for **Hopper (SM90, H100)** and **Blackwell (SM100+, B100/B200)** GPUs. It provides significant performance improvements on these architectures. For older GPUs (Ampere, Ada Lovelace), use Flash Attention 2 or 3 instead.
 
+**Note on AMD ROCm**: only `TORCH_SDPA` is natively available on ROCm hosts (`tf-kernel`, SageAttention, and
+`flash_attn` are CUDA-only), so ROCm examples default to SDPA explicitly. The per-platform backend matrix lives in
+[Hardware Platforms](platforms.md).
+
 ### Sparse Attention Backends
 
 | Backend | Description | Requirements |

docs/en/installation.md

@@ -11,6 +11,7 @@ distribution are installed separately.
 | Python | 3.10 through 3.13 |
 | PyTorch | 2.6 or newer |
 | CUDA toolkit | 12.8 or newer for the maintained CUDA development path |
+| ROCm | 7.x with a PyTorch `+rocm` build for AMD GPUs; see the ROCm note under verification |
 | GPU | Depends on the selected model; check its Cookbook guide |
 
 An example may impose stricter versions or GPU architecture requirements. In particular, locally built `tf-kernel`
@@ -55,6 +56,12 @@ telefuser --help
 Model execution expects `torch.cuda.is_available()` to print `True`. If it does not, verify the installed PyTorch
 build and visible NVIDIA driver before diagnosing TeleFuser.
 
+On AMD ROCm hosts, install a PyTorch `+rocm` build instead of the CUDA toolkit path. A HIP build also prints `True`
+for `torch.cuda.is_available()` (check `torch.version.hip` to distinguish it), and TeleFuser's platform layer detects
+ROCm before CUDA. Examples ending in `_rocm.py` (for example `examples/wan_video/wan21_1_3b_text_to_video_rocm.py`)
+are the validated entry points; see [Hardware Platforms](platforms.md) for per-platform capabilities and backend
+availability.
+
 ## Model Checkpoints
 
 TeleFuser does not bundle model weights. The [Supported Models](supported_models.md) page links to each Cookbook

docs/en/ops.md

@@ -62,6 +62,9 @@ TeleFuser follows a strict layered architecture for operations:
 - **Performance**: ops layer uses optimized Triton kernels in eager mode
 - **Separation of concerns**: kernel layer focuses on pure kernel implementation, ops layer handles dispatch logic
 
+On AMD ROCm, dispatch reuses the `forward_cuda` Triton path when no `forward_rocm` kernel is defined. See
+[Hardware Platforms](platforms.md) for the full per-platform dispatch behavior and `tf-kernel` gating.
+
 ### torch.compile Strategy by Operator Type
 
 TeleFuser uses a **mixed strategy** for torch.compile compatibility, optimizing based on operator characteristics:

docs/en/platforms.md

@@ -0,0 +1,71 @@
+# Hardware Platforms
+
+TeleFuser abstracts execution hardware behind the platform layer in `telefuser/platforms/`. Each process resolves a
+single `current_platform` object at import time, and the [Ops](ops.md) dispatch layer uses it to select operator
+implementations. Pipelines and examples configure a `torch.device`-style device and do not branch on the vendor.
+
+## Platform selection
+
+`_resolve_current_platform()` in `telefuser/platforms/__init__.py` probes the environment in a fixed order and
+instantiates the first match:
+
+1. **ROCm** — a PyTorch `+rocm` (HIP) build with at least one visible AMD GPU
+2. **CUDA** — a CUDA build with at least one visible NVIDIA GPU
+3. **NPU** — a `torch_npu` installation with a visible Ascend device
+4. **CPU** — the fallback when no accelerator is detected
+
+HIP builds expose the `torch.cuda` API, so the ROCm platform reuses it (`device_type` stays `cuda`); check
+`torch.version.hip` to distinguish a ROCm host from an NVIDIA one. A HIP or CUDA build without a visible GPU falls
+back to CPU. `CUDA_VISIBLE_DEVICES` controls device visibility on both GPU platforms, and
+`ASCEND_RT_VISIBLE_DEVICES` on NPU.
+
+## Platform matrix
+
+| Platform | `device_type` | Distributed backend | Operator dispatch | `tf-kernel` | torch.compile |
+|----------|---------------|---------------------|-------------------|-------------|---------------|
+| CUDA (NVIDIA) | `cuda` | NCCL | Optimized `forward_cuda` paths | Supported | Experimental ([details](torch_compile_compatibility.md)) |
+| ROCm (AMD) | `cuda` | RCCL (`nccl`) | Triton `forward_cuda` paths and native fallbacks | Not available | Not validated |
+| NPU (Ascend) | `npu` | HCCL | Native fallbacks | Not available | Not validated |
+| CPU | `cpu` | Gloo | Native fallbacks | Not available | Native path |
+
+## Attention backends by platform
+
+Attention backend availability is resolved at import time (see [Attention](attention.md)). A backend whose
+dependencies are missing falls back to `TORCH_SDPA` with a one-time warning.
+
+- **CUDA**: all dense backends — `TORCH_SDPA`, FlashAttention 2/3/4, SageAttention through `tf-kernel` or
+  `sageattention`, and cuDNN — subject to GPU architecture; sparse backends likewise.
+- **ROCm**: `TORCH_SDPA` only. `flash_attn` has no official ROCm wheels for consumer RDNA GPUs, and `tf-kernel`,
+  SageAttention, and SpargeAttn are CUDA-only. The AOTriton-backed SDPA path is the fast attention kernel on
+  RDNA4.
+- **NPU / CPU**: `TORCH_SDPA` through the native fallback paths; no vendor attention kernels are integrated.
+
+## CUDA
+
+CUDA is the primary validated path: Python 3.10–3.13, PyTorch 2.6 or newer, CUDA toolkit 12.8 or newer, with H100
+as the validated target for optimized kernels. Optional `tf-kernel` provides fused elementwise operations,
+quantized GEMM, SageAttention, and block-sparse attention — see [tf-kernel](tf_kernel.md) for build and artifact
+compatibility. Multi-GPU inference uses NCCL; see [Parallel Inference](parallel.md).
+
+## ROCm
+
+ROCm support targets AMD GPUs with ROCm 7.x and a PyTorch `+rocm` build; see [Installation](installation.md) for the
+setup path.
+
+- Attention uses `TORCH_SDPA`; no `tf-kernel`, `flash_attn`, or `sageattention` installation is required.
+- The ops layer selects `forward_rocm` where a kernel defines one and otherwise reuses the CUDA Triton path (Triton
+  supports ROCm), falling back to native PyTorch.
+- `tf-kernel` imports are gated to `CudaPlatform`, so no CUDA-only extension is loaded on ROCm hosts.
+- Multi-GPU inference uses RCCL, AMD's NCCL-compatible collectives library. PyTorch's ROCm build exposes it through
+  the `nccl` backend string, so the platform layer requires no special configuration.
+- `torch.compile` is not validated on ROCm; ROCm examples run eager.
+- Validated entry points are the `*_rocm.py` examples, for example
+  [Wan2.1 1.3B text-to-video](https://github.com/Tele-AI/TeleFuser/tree/main/examples/wan_video) on a Radeon RX 9070
+  (gfx1201, ROCm 7.2). Multi-GPU branches reuse the `_h100.py` parallel configuration but are not yet validated.
+
+## NPU and CPU
+
+The NPU platform targets Huawei Ascend devices through `torch_npu` with the HCCL distributed backend. It is wired
+into the platform and ops dispatch layers, but the maintained examples are validated on CUDA and, for select
+examples, ROCm — validate on your target NPU before production use. The CPU platform is the fallback when no
+accelerator is detected; it is intended for tests and for pipelines that explicitly request CPU execution.

docs/zh/attention.md

@@ -244,6 +244,9 @@ pipe_config.dit_config.attention_config = config
 
 **Flash Attention 4 说明**: Flash Attention 4 针对 **Hopper (SM90, H100)** 和 **Blackwell (SM100+, B100/B200)** GPU 架构进行了优化，在这些架构上提供显著的性能提升。对于旧版 GPU（Ampere、Ada Lovelace），请使用 Flash Attention 2 或 3。
 
+**AMD ROCm 说明**：ROCm 主机上仅 `TORCH_SDPA` 原生可用（`tf-kernel`、SageAttention 与 `flash_attn` 仅支持
+CUDA），因此 ROCm 示例显式默认 SDPA。各平台后端矩阵见[硬件平台](platforms.md)。
+
 ### 稀疏注意力后端
 
 | 后端 | 描述 | 依赖 |

docs/zh/installation.md

@@ -10,6 +10,7 @@
 | Python | 3.10 至 3.13 |
 | PyTorch | 2.6 或更高版本 |
 | CUDA Toolkit | 当前 CUDA 开发路径要求 12.8 或更高版本 |
+| ROCm | AMD GPU 使用 ROCm 7.x 与 PyTorch `+rocm` 构建，详见验证安装一节的说明 |
 | GPU | 取决于所选模型，以对应 Cookbook 为准 |
 
 具体示例可能要求更严格的软件版本或 GPU 架构。特别是本地构建的 `tf-kernel` 产物与其记录的 PyTorch、
@@ -54,6 +55,12 @@ telefuser --help
 模型执行要求 `torch.cuda.is_available()` 输出 `True`。否则应先检查 PyTorch CUDA 构建和 NVIDIA 驱动，
 再排查 TeleFuser。
 
+AMD ROCm 主机应安装 PyTorch `+rocm` 构建，而非 CUDA Toolkit 路径。HIP 构建下
+`torch.cuda.is_available()` 同样输出 `True`（可通过 `torch.version.hip` 区分），TeleFuser 平台层会先
+检测 ROCm 再检测 CUDA。以 `_rocm.py` 结尾的示例（例如
+`examples/wan_video/wan21_1_3b_text_to_video_rocm.py`）是已验证的入口；各平台能力与后端可用性见
+[硬件平台](platforms.md)。
+
 ## 模型权重
 
 TeleFuser 不随软件包分发模型权重。[支持的模型](supported_models.md)页面会链接到各模型的 Cookbook，

docs/zh/ops.md

@@ -62,6 +62,9 @@ TeleFuser 遵循严格的分层架构：
 - **性能优化**：ops 层在 eager 模式下使用优化的 Triton 内核
 - **关注点分离**：kernel 层专注纯内核实现，ops 层处理分发逻辑
 
+AMD ROCm 上，未定义 `forward_rocm` 内核时分发会复用 `forward_cuda` 的 Triton 路径。各平台的完整分发行为与
+`tf-kernel` 门控见[硬件平台](platforms.md)。
+
 ### 不同算子类型的 torch.compile 策略
 
 TeleFuser 采用**混合策略**处理 torch.compile 兼容性，根据算子特性优化：

docs/zh/platforms.md

@@ -0,0 +1,66 @@
+# 硬件平台
+
+TeleFuser 通过 `telefuser/platforms/` 中的平台层屏蔽底层硬件差异。每个进程在导入时解析出唯一的
+`current_platform` 对象，[算子](ops.md)分发层根据它选择具体实现。Pipeline 与示例只需配置
+`torch.device` 风格的设备，无需针对厂商编写分支。
+
+## 平台选择
+
+`telefuser/platforms/__init__.py` 中的 `_resolve_current_platform()` 按固定顺序探测环境，并实例化第一个
+命中的平台：
+
+1. **ROCm** — PyTorch `+rocm`（HIP）构建且至少有一块可见的 AMD GPU
+2. **CUDA** — CUDA 构建且至少有一块可见的 NVIDIA GPU
+3. **NPU** — 安装了 `torch_npu` 且有可见的昇腾设备
+4. **CPU** — 未检测到加速器时的回退
+
+HIP 构建同样暴露 `torch.cuda` API，因此 ROCm 平台复用它（`device_type` 仍为 `cuda`）；可通过
+`torch.version.hip` 区分 ROCm 主机与 NVIDIA 主机。HIP 或 CUDA 构建在没有可见 GPU 时同样回退到 CPU。
+两块 GPU 平台通过 `CUDA_VISIBLE_DEVICES` 控制设备可见性，NPU 使用 `ASCEND_RT_VISIBLE_DEVICES`。
+
+## 平台矩阵
+
+| 平台 | `device_type` | 分布式后端 | 算子分发 | `tf-kernel` | torch.compile |
+|------|---------------|------------|----------|-------------|---------------|
+| CUDA（NVIDIA） | `cuda` | NCCL | 优化的 `forward_cuda` 路径 | 支持 | 实验性（[详情](torch_compile_compatibility.md)） |
+| ROCm（AMD） | `cuda` | RCCL（`nccl`） | Triton `forward_cuda` 路径与原生回退 | 不支持 | 未验证 |
+| NPU（昇腾） | `npu` | HCCL | 原生回退 | 不支持 | 未验证 |
+| CPU | `cpu` | Gloo | 原生回退 | 不支持 | 原生路径 |
+
+## 各平台的注意力后端
+
+注意力后端可用性在导入时解析（见[注意力机制](attention.md)）。依赖缺失的后端会带一次性警告回退到
+`TORCH_SDPA`。
+
+- **CUDA**：全部稠密后端 —— `TORCH_SDPA`、FlashAttention 2/3/4、经 `tf-kernel` 或 `sageattention` 提供的
+  SageAttention，以及 cuDNN —— 取决于 GPU 架构；稀疏后端同理。
+- **ROCm**：仅 `TORCH_SDPA`。`flash_attn` 没有面向消费级 RDNA GPU 的官方 ROCm 轮子，`tf-kernel`、
+  SageAttention 与 SpargeAttn 仅支持 CUDA。AOTriton 支持的 SDPA 路径是 RDNA4 上的快速注意力内核。
+- **NPU / CPU**：通过原生回退路径使用 `TORCH_SDPA`；未集成厂商注意力内核。
+
+## CUDA
+
+CUDA 是主要的已验证路径：Python 3.10–3.13、PyTorch 2.6 及以上、CUDA Toolkit 12.8 及以上，优化内核以
+H100 为验证目标。可选的 `tf-kernel` 提供融合逐元素算子、量化 GEMM、SageAttention 与块稀疏注意力 ——
+构建与制品兼容性见 [tf-kernel](tf_kernel.md)。多卡推理使用 NCCL，参见[并行推理](parallel.md)。
+
+## ROCm
+
+ROCm 支持面向使用 ROCm 7.x 与 PyTorch `+rocm` 构建的 AMD GPU；安装路径见[安装指南](installation.md)。
+
+- 注意力使用 `TORCH_SDPA`；无需安装 `tf-kernel`、`flash_attn` 或 `sageattention`。
+- 算子层在内核定义了 `forward_rocm` 时优先选择，否则复用 CUDA Triton 路径（Triton 支持 ROCm），并回退到
+  PyTorch 原生实现。
+- `tf-kernel` 导入被限定在 `CudaPlatform`，ROCm 主机不会加载任何 CUDA-only 扩展。
+- 多卡推理使用 RCCL（AMD 与 NCCL 兼容的集合通信库）。PyTorch 的 ROCm 构建通过 `nccl` 后端字符串暴露它，
+  平台层无需特殊配置。
+- `torch.compile` 在 ROCm 上未验证；ROCm 示例以 eager 模式运行。
+- 已验证入口为 `*_rocm.py` 示例，例如在 Radeon RX 9070（gfx1201，ROCm 7.2）上运行的
+  [Wan2.1 1.3B 文生视频](https://github.com/Tele-AI/TeleFuser/tree/main/examples/wan_video)。多卡分支复用
+  `_h100.py` 的并行配置，但尚未在 ROCm 上验证。
+
+## NPU 与 CPU
+
+NPU 平台通过 `torch_npu` 与 HCCL 分布式后端支持华为昇腾设备。平台层与算子分发层均已接入 NPU，但现有
+示例在 CUDA 上验证、部分示例在 ROCm 上验证 —— 生产使用前请先在目标 NPU 上完成验证。CPU 平台是未检测到
+加速器时的回退，面向测试以及显式请求 CPU 执行的 Pipeline。

examples/wan_video/README.md

@@ -32,6 +32,9 @@ Video generation using Wan2.1 and Wan2.2 models for Text-to-Video and Image-to-V
 
 - GPU: CUDA GPUs with enough memory for the selected 1.3B, 5B, or 14B checkpoint; H100 is the validated target for
   scripts ending in `_h100.py`
+- GPU: AMD ROCm GPUs for scripts ending in `_rocm.py`; validated on a Radeon RX 9070 (ROCm 7.2, `torch` built with
+  `+rocm`). These examples use the PyTorch SDPA attention backend and need no tf-kernel, flash-attn, or SageAttention
+  installation
 - Software: the standard TeleFuser installation; optional attention, FP8, Ray, and RIFE paths require their respective
   dependencies
 - Input assets: a readable image for I2V/FL2V and optional LoRA, distillation, cache, or RIFE weights for those variants
@@ -120,6 +123,44 @@ python examples/wan_video/wan21_1_3b_text_to_video_h100.py --resolution 480p --a
 **Features:**
 - Video Frame Interpolation (VFI) with RIFE model for 30fps output
 - CFG parallel when cfg_scale > 1
+
+#### `wan21_1_3b_text_to_video_rocm.py`
+
+T2V on AMD ROCm GPUs.
+
+**Purpose:** Wan2.1 1.3B text-to-video for ROCm hosts, loading the official (non-Diffusers) checkpoint layout.
+
+**Usage:**
+```bash
+TELEAI_EXAMPLE_OUTPUT_DIR=work_dirs \
+python examples/wan_video/wan21_1_3b_text_to_video_rocm.py \
+  --model_root "$TF_MODEL_ZOO_PATH/Wan2.1-T2V-1.3B" \
+  --prompt "A sailboat crosses a calm lake at sunrise"
+```
+
+**Features:**
+- PyTorch SDPA attention backend (natively available on ROCm; no flash-attn, SageAttention, or tf-kernel needed)
+- Eager execution (`torch.compile` disabled by default; not validated on ROCm)
+- 2-tile VAE decode geometry (`tile_size=(60, 62)`, `tile_stride=(30, 54)`): covers the 480p 16:9 latent with
+  ~1.4x redundant compute instead of the default 12-tile layout's ~2.9x, cutting VAE decode from ~61s to ~34s on a
+  Radeon RX 9070 at ~7.7GiB peak VRAM
+- Text encoder CPU offloading with pageable (non-pinned) host copies: the ~10.6GB bf16 T5 encoder is only
+  moved to the GPU during text encoding, and page-locked copies are avoided because they exceed a 16GB
+  host RAM budget together with the DiT/VAE weights
+- Validated single-GPU on Radeon RX 9070 (gfx1201) with ROCm 7.2
+- Multi-GPU branches follow the `_h100.py` parallel configuration and are not yet validated on ROCm
+- VFI (RIFE) is disabled by default; enable it in `PPL_CONFIG` to add the interpolation model
+
+**ROCm performance notes (Radeon RX 9070, gfx1201, ROCm 7.2, 832x480, 81 frames):**
+
+- The DiT denoiser is at the operator-level hardware limit in eager mode: hipBLASLt serves the MLP GEMMs at
+  ~99 TFLOPS (RDNA4 bf16 peak) and the AOTriton-backed flash SDPA is the only fast attention kernel on this GPU,
+  so there is no faster ROCm operator to switch to. Measured alternatives are slower: `torch.compile` warm steps
+  (~14.6s vs ~14.0s), TunableOp autotuned GEMMs (~15.2s plus a ~400s autotune pass), and MIOpen's fused
+  attention has no gfx1201 kernel ("No available kernel" error)
+- The first MIOpen conv run per shape pays one-time JIT compilation, cached cross-process under
+  `~/.cache/miopen`; subsequent runs (including in new processes) reuse it
+
 #### `wan21_1_3b_text_to_video_hf.py`
 
 T2V with HuggingFace format loading.