Krea 2 Turbo — INT8 TensorWise for ComfyUI / Triton

🎬 Project release video: Watch the Krea 2 AMD ROCm optimization release video on YouTube

[!IMPORTANT]

⚡ Optimal AMD ROCm path: ROCm FlashAttention + GPU-specific environment + Qwen VAE Triton W8A8

For the fastest path measured on the Ubuntu host, use the release checkpoints in this repository with Qwen VAE Triton W8A8 set to Aggressive, install ROCm/flash-attention using the AMD Triton/AITER backend, set FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE, and launch ComfyUI with --use-flash-attention --disable-xformers.

Do not treat --enable-triton-backend as a requirement for this release. It controls the separate comfy-kitchen Triton backend, and the Ubuntu-host A/B showed no meaningful gain when it was added on top of the FlashAttention path.

ROCm/PyTorch/FlashAttention setup is GPU- and version-specific. A copy-paste-ready implementation prompt for ChatGPT or another flagship LLM is included at the bottom of this README to guide a user from a fresh system through hardware discovery, ROCm validation, PyTorch pairing, FlashAttention/AITER installation, environment tuning, and final ComfyUI validation.

⚡ Ubuntu-host benchmarks — all optimizations vs stock ComfyUI paths

The headline result is the complete optimized ROCm path, not any single checkpoint in isolation. On the tested Ubuntu host, the strongest results came from combining:

• the release diffusion and text-encoder checkpoints from this repository;
• Qwen VAE Triton W8A8 with the Aggressive preset;
• ROCm FlashAttention using its AMD Triton/AITER implementation with FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE;
• ComfyUI launched with --use-flash-attention --disable-xformers;
• a small, GPU-specific ROCm/PyTorch environment rather than a generic shell-variable dump.

For the closest stock-style reference-to-image path measured on the same Ubuntu host, the baseline used the official ComfyUI INT8 ConvRot diffusion checkpoint, the runtime Style-Reference LoRA, PyTorch cross-attention, and no VAE patch. Warm averages below use the two repeated 1368×768 / 8-step runs after initialization; the resolution-change run is excluded from the warm average.

Headline gains

• First workflow: 242.4 s → 85.0 s, a 64.9% reduction in end-to-end time.
• Warm workflow: 81.7 s → 75.0 s, 8.2% faster.
• Warm sampling: 71.0 s → 65.0 s, 8.4% faster.
• Warm iteration time: 8.87 s/it → 8.16 s/it, 8.0% lower.

Cold-start measurements include one-time initialization/compilation work, so the warm generation, sampling, and sec/it results are the better steady-state performance indicators.

FlashAttention is the backend optimization that moved the needle

The Ubuntu-host attention A/B used the same fused release checkpoint, project text encoder, and aggressive Qwen VAE patch. Switching only the attention path from PyTorch cross-attention to ROCm FlashAttention reduced:

• warm generation from 82.5 s → 75.0 s (9.1%);
• warm sampling from 71.0 s → 65.0 s (8.5%);
• warm iteration time from 8.915 s/it → 8.160 s/it.

By contrast, adding ComfyUI's separate --enable-triton-backend flag on top of the FlashAttention path was effectively neutral in this test: warm generation remained 75.0 s and warm sampling remained 65.0 s. For this release, --enable-triton-backend is therefore not a required performance instruction; treat it as a separate optional comfy-kitchen backend experiment.

Text-to-image model efficiency on the Ubuntu host

With the attention path and text encoder held constant, the project TensorWise diffusion model averaged 35.16 s warm generation time at 1368×768 / 8 steps:

The Qwen3-VL INT8 text encoder is primarily a memory/storage optimization in this workload: its warm generation timing was effectively tied with the tested BF16 and FP8 text-encoder controls, so this README does not claim a material text-encoder speedup.

Docker diagnostics — the VAE is a cold-start and resolution-change bottleneck

The Docker benchmark isolates a different problem: Qwen Image VAE load/prepare/decode cost can dominate the first workflow after startup and the first workflow after a resolution change.

Warm repeated VAE execution is already small in these Docker runs; the expensive cases are the initialization/reconfiguration paths. Qwen VAE Triton W8A8 helps mitigate those costs, cutting the measured VAE stage by roughly 20–21% in the cold/resolution-change cases above.

Benchmarks are hardware-, software-, and workflow-dependent. Treat first-run results separately from steady-state results. The raw measurements remain under benchmarks/ubuntu_host_system_comfyui/ and benchmarks/docker_comfyui/.

🖼️ Text-to-image examples

🎨 Reference-to-image examples

Technical summary

This release contains three staged safetensors artifacts:

1. Krea 2 Turbo diffusion — full CORE TensorWise INT8

The official Krea 2 Turbo BF16 transformer contains 28 repeated main blocks. The release quantizes all eight large GEMM families in every block:

attn.wq
attn.wk
attn.wv
attn.gate
attn.wo
mlp.gate
mlp.up
mlp.down

That is 28 × 8 = 224 main transformer weights converted to plain ComfyUI int8_tensorwise. Non-CORE tensors are preserved from the official source. ConvRot is not used.

For each quantized 2-D weight:

<layer>.weight        INT8
<layer>.weight_scale  FP32 [out_features, 1]
<layer>.comfy_quant   U8 bytes for {"format":"int8_tensorwise"}

Offline row-wise quantization uses:

scale[row] = max(abs(weight[row])) / 127
q          = round(weight / scale)
q          = clamp(q, -128, 127)

The resulting diffusion checkpoint is 14,135,058,504 bytes (~13.16 GiB), approximately 46.2% smaller than the pinned 26,283,332,608-byte BF16 source.

2. Style-Reference fused diffusion — fuse first, quantize second

The Style-Reference checkpoint is built from the Ostris krea2_turbo_style_reference LoRA at multiplier 1.0. Analysis resolved 256 rank-64 LoRA target pairs with no explicit alpha tensors.

The merge is performed against the official BF16 Krea 2 Turbo weights before any INT8 quantization:

W_fused = W_base + (B @ A)

Then:

• 224 fused main CORE targets → quantized to plain int8_tensorwise.
• 32 fused txtfusion.* targets → retained in BF16.
• 174 untouched source tensors → preserved unchanged.

This avoids a lossy INT8 → dequantize → merge → requantize path. A/B testing against the runtime LoRA path passed, and the runtime Load LoRA step is no longer required.

Important: the fused checkpoint removes the runtime LoRA load, but reference-image conditioning still requires the Krea 2 Ostris Edit model-patch/conditioning path.

3. Qwen3-VL-4B text encoder — architecture-aware TensorWise INT8

The text encoder was verified against the official Krea 2 Turbo text-encoder component and the upstream Qwen/Qwen3-VL-4B-Instruct tensors before conversion. 356 2-D projection weights are quantized to plain int8_tensorwise across these families:

• language attention: 144
• language MLP: 108
• vision attention: 48
• vision MLP: 48
• vision merger: 2
• vision deep-stack merger: 6

The output uses the upstream Qwen3-VL wrapper namespace required by native ComfyUI Krea 2 detection. The final file is 4,836,873,752 bytes (~4.50 GiB), approximately 45.5% smaller than the verified 8,875,715,136-byte BF16 source.

Full tensor maps, hashes, source identities, and validation evidence are retained under docs/.

Implementation

1. Build the optimized ROCm attention environment

The benchmarked performance path uses ROCm FlashAttention with its AMD Triton/AITER backend, not ComfyUI's separate comfy-kitchen Triton flag.

Current ComfyUI exposes these as independent controls:

--use-flash-attention     Use FlashAttention for attention
--enable-triton-backend   Enable the comfy-kitchen Triton backend for model operations

For the tested optimized path, the relevant launch shape is:

export FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE

python main.py \
  --use-flash-attention \
  --disable-xformers

Add normal server/UI flags such as --listen or --enable-manager only when you need them.

Build/install ROCm/flash-attention for your actual ROCm, PyTorch, Triton, AITER, and GPU architecture. Do not copy another machine's ROCm/PyTorch/Triton versions or HSA_OVERRIDE_GFX_VERSION blindly.

The tested Ubuntu-host benchmark environment retained only runtime variables relevant to the GPU/ComfyUI execution path:

FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
HIP_VISIBLE_DEVICES=0
PYTORCH_ALLOC_CONF=expandable_segments:True,garbage_collection_threshold:0.9,max_split_size_mb:512
PYTORCH_TUNABLEOP_ENABLED=0
PYTORCH_TUNABLEOP_TUNING=0
PYTORCH_TUNABLEOP_VERBOSE=0
TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1
TORCHINDUCTOR_CACHE_DIR=/tmp/torchinductor_al

The tested host also had HSA-level settings recorded, but those are architecture-specific and should only be set when your GPU/ROCm combination actually requires them.

TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL relates to PyTorch's ROCm SDPA/cross-attention path; it is not what enables external FlashAttention. The external FlashAttention AMD Triton/AITER selector is:

FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE

For the complete from-scratch setup process, use the copy-paste LLM implementation prompt at the bottom of this README.

2. Install Qwen VAE Triton W8A8

Registry: Qwen VAE Triton W8A8

With comfy-cli:

comfy node install qwen-vae-triton

Or search ComfyUI Manager for:

Qwen VAE Triton W8A8

Then restart ComfyUI and connect the node between your normal VAE loader and VAEDecode:

VAELoader
   │
   ▼
Patch Qwen VAE Triton W8A8
   │
   ▼
VAEDecode

Set:

Preset: Aggressive

The Aggressive preset keeps the two quality-sensitive U14 layers in native precision and applies W8A8 acceleration to the remaining validated eligible decoder layers.

3. Tune only variables that are relevant to your GPU and backend

GPU tuning is architecture-specific. Before setting persistent environment variables:

1. identify the actual GPU and native LLVM/GFX architecture;
2. verify that your ROCm release supports that GPU;
3. validate the PyTorch + TorchVision + ROCm pairing;
4. validate FlashAttention/AITER independently before launching ComfyUI;
5. change one group of settings at a time and benchmark cold and warm runs separately.

Useful discovery commands include:

rocminfo | grep -m1 -E 'Name:.*gfx'

and:

python - <<'PYGPU'
import torch
print(torch.cuda.get_device_name(0))
print("HIP:", torch.version.hip)
PYGPU

Do not set HSA_OVERRIDE_GFX_VERSION merely because another AMD system used it. If ROCm/PyTorch natively identifies the correct GFX architecture, leave the override unset.

4. Tested Strix Halo / gfx1151 notes

The Ubuntu-host benchmark data came from the project's validated Strix Halo / gfx1151 environment. The benchmark CSVs retain only variables relevant to ComfyUI, ROCm/HIP, PyTorch, Triton, FlashAttention, and PyTorch cross-attention.

That environment is evidence of what was tested, not a universal AMD configuration. The implementation prompt at the bottom of this README instructs an LLM to discover the user's actual hardware and current supported software stack before recommending values.

5. Install the release models

Place the files as follows:

ComfyUI/models/diffusion_models/krea2_turbo_int8_tensorwise_v1.safetensors
ComfyUI/models/diffusion_models/krea2_turbo_style_ref_fused_int8_tensorwise_v1.safetensors
ComfyUI/models/text_encoders/krea2_qwen3vl_4b_int8_tensorwise_v1.safetensors

Load the text encoder with native ComfyUI CLIPLoader using type:

krea2

Use the standard Qwen Image VAE (qwen_image_vae.safetensors) together with Qwen VAE Triton W8A8 / Aggressive for the benchmarked VAE path.

6. Reference-to-image workflow

For krea2_turbo_style_ref_fused_int8_tensorwise_v1.safetensors, do not add the Style-Reference LoRA again. It is already fused into the checkpoint.

Reference conditioning still requires the Ostris Krea 2 edit/model-patch path:

• ComfyUI-Krea2-Ostris-Edit
• Original Style-Reference LoRA

The release creates a top-level workflows/ directory for the validated ComfyUI workflow JSON files.

License and attribution

This repository contains modified derivative models. It is an independent community release and is not an official Krea, Qwen/Alibaba, Ostris, ComfyUI, AMD, or OpenAI product, and is not endorsed by those parties.

Krea 2 Turbo and Style-Reference derivative

Krea 2 Turbo and derivatives are governed by the Krea 2 Community License Agreement. The required license copy is distributed in LICENSES/KREA-2-COMMUNITY-LICENSE.pdf. The required attribution and modification notice is in NOTICE.md.

The Krea license includes specific distribution, acceptable-use, and commercial-use requirements. Review the license before redistribution or commercial deployment:

• https://www.krea.ai/krea-2-licensing
• https://huggingface.co/krea/Krea-2-Turbo

The fused Style-Reference checkpoint incorporates the Ostris Style-Reference LoRA, which is also published under the Krea 2 Community License Agreement.

Qwen3-VL-4B text encoder

The Qwen3-VL-4B-Instruct upstream model is published under Apache License 2.0. A copy is included at LICENSES/APACHE-2.0.txt.

• https://huggingface.co/Qwen/Qwen3-VL-4B-Instruct

Optional runtime software

qwen-vae-triton, ComfyUI, and ComfyUI-Krea2-Ostris-Edit are not bundled model weights in this repository. They remain subject to their respective upstream licenses and terms.

🚀 Work with me / More projects

If this release saved you VRAM, benchmark time, or the debugging involved in making a demanding Krea 2 workflow practical, there is more where this came from.

I’m actively looking for full-time AI Systems Engineer opportunities focused on model optimization, inference systems, GPU acceleration, quantization, generative-AI infrastructure, and the engineering required to make large models reliable in real-world environments.

Hiring for this kind of work? The best place to reach me is LinkedIn.

For practical AI systems work, model optimization experiments, and project demonstrations, see PuppetVisionAI on YouTube or visit puppetvision.nl.

Liability disclaimer

This repository and its derivative model files are provided “AS IS”, without warranties or guarantees of any kind, express or implied. Quantized models, custom GPU kernels, Triton, ROCm/CUDA components, third-party custom nodes, allocator/environment tuning, and model patches may behave differently across hardware and software versions and may cause crashes, incorrect output, instability, corrupted workflows, excessive resource use, or data loss.

You are responsible for validating suitability, quality, safety, license compliance, acceptable use, security, and performance for your own environment and use case. Benchmark results are measurements from specific tested workflows and are not guarantees of equivalent performance on other systems.

Nothing in this repository modifies, replaces, or limits the warranty, liability, acceptable-use, redistribution, or other terms imposed by the applicable upstream licenses. Where an upstream license imposes stronger protections or restrictions, those terms control.

Copy and paste implementation instructions for ChatGPT or other flagship LLM

Copy the complete prompt below into a new conversation with ChatGPT or another capable flagship LLM. It is designed to walk through a fresh AMD ROCm + ComfyUI + FlashAttention setup one validated phase at a time, using the user's actual machine evidence instead of assuming versions or GPU settings.

# Copy/Paste LLM Prompt: Build ComfyUI + AMD ROCm + FlashAttention Triton/AITER from Scratch

> **Purpose:** Copy this entire Markdown prompt into ChatGPT, Nemotron-3 Ultra, Claude, Gemini, or another flagship LLM with web access.
>
> The LLM must guide the user interactively from a fresh machine to a validated ComfyUI installation using AMD ROCm and the AMD Triton/AITER FlashAttention path selected with:
>
> ```bash
> export FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
> ```
>
> This prompt is deliberately hardware-adaptive. It must **not** assume the user's GPU, OS, driver status, ROCm version, PyTorch version, TorchVision version, Triton version, or FlashAttention revision.

---

## ROLE

You are an expert installation and troubleshooting engineer for:

- AMD GPUs
- AMDGPU drivers
- AMD ROCm / HIP / HSA
- TheRock ROCm packages
- PyTorch ROCm
- TorchVision
- Python 3.12
- Triton
- AMD AITER
- FlashAttention
- ComfyUI
- ComfyUI model loading and memory management
- ComfyUI/comfy-kitchen HIP and Triton backends
- Linux and Windows GPU software stacks

Your job is to guide me **interactively and evidence-first** through building a clean, reproducible local ComfyUI environment that uses AMD ROCm and `ROCm/flash-attention` with the AMD Triton/AITER implementation enabled by:

```bash
export FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
```

Do not assume anything about my machine at the beginning.

---

# 1. FINAL TARGET

At the end of the guided process I should have:

- a supported Windows or Linux installation, or a clearly justified move to Linux if the exact requested FlashAttention/AITER stack is not supported on my Windows configuration;
- a validated AMD GPU driver;
- a GPU confirmed usable by ROCm/HIP;
- the GPU's actual GFX architecture identified, such as `gfx1100`, `gfx1151`, `gfx1201`, etc.;
- Python **3.12.x** in an isolated environment;
- a known-compatible PyTorch + TorchVision pair;
- ROCm-enabled PyTorch matched to the selected ROCm release and GPU;
- a successful real GPU PyTorch computation;
- BF16 and/or FP16 GPU computation validated where the GPU supports it;
- ComfyUI installed from the official GitHub repository;
- ComfyUI dependencies installed without silently replacing the validated PyTorch/TorchVision stack with an incompatible one;
- the official AMD `ROCm/flash-attention` repository cloned and its exact Git revision recorded;
- FlashAttention installed with the AMD Triton/AITER backend;
- `FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE` used where required during build/install and runtime;
- AITER validated;
- Triton validated;
- FlashAttention validated independently before using it inside ComfyUI;
- ComfyUI launched using `--use-flash-attention`;
- at least one complete ComfyUI generation completed successfully;
- a minimal persistent environment-variable file;
- a reproducible launch script;
- a final environment/version report suitable for benchmarking.

Do not declare success merely because ComfyUI starts.

The following must each be independently validated:

1. GPU driver
2. ROCm/HIP
3. PyTorch GPU execution
4. Torch/TorchVision compatibility
5. Triton import/runtime
6. AITER import/runtime
7. FlashAttention AMD Triton/AITER implementation
8. ComfyUI startup
9. complete ComfyUI generation

---

# 2. CRITICAL KNOWLEDGE-CUTOFF RULE

Your internal knowledge may be stale.

The user may be using an LLM with a **February 2026 knowledge cutoff**, while AMD's ROCm distribution, driver support, Windows support, GPU support, TheRock packaging, PyTorch wheels, AITER, and FlashAttention changed significantly later in 2026.

Therefore:

- do not trust remembered ROCm compatibility tables;
- do not trust remembered Windows limitations without checking current sources;
- do not trust remembered PyTorch/TorchVision version mappings without checking current sources;
- do not assume a GPU is unsupported because it was unsupported in early 2026;
- do not assume old nightly repositories are still preferred;
- do not assume `gfx1151`, `gfx1200`, `gfx1201`, or later architectures require old workarounds;
- do not automatically use `HSA_OVERRIDE_GFX_VERSION`;
- do not automatically use an old PyTorch nightly.

If web access is available, **consult current authoritative sources before choosing any versions or installation method**.

If web access is unavailable, explicitly state which compatibility decisions cannot be verified and do not invent current package versions.

---

# 3. MANDATORY AUTHORITATIVE SOURCES

Use these sources as the primary source of truth.

## 3.1 AMD ROCm documentation

Main ROCm documentation:

https://rocm.docs.amd.com/

Linux installation documentation:

https://rocm.docs.amd.com/projects/install-on-linux/en/latest/

Windows installation documentation:

https://rocm.docs.amd.com/projects/install-on-windows/en/latest/

Current ROCm compatibility documentation:

https://rocm.docs.amd.com/en/latest/compatibility/compatibility-matrix.html

Use these to determine:

- supported operating systems;
- supported AMD GPUs;
- supported GFX architectures;
- current driver requirements;
- current ROCm installation method;
- Windows vs Linux support;
- framework compatibility.

---

## 3.2 AMD TheRock

TheRock repository:

https://github.com/ROCm/TheRock

Release/install documentation:

https://github.com/ROCm/TheRock/blob/main/RELEASES.md

Supported GPU tracking:

https://github.com/ROCm/TheRock/blob/main/SUPPORTED_GPUS.md

GitHub releases:

https://github.com/ROCm/TheRock/releases

TheRock is important because newer ROCm releases use its modern multi-architecture packaging and release infrastructure.

Current TheRock documentation should be consulted for:

- stable ROCm Python packages;
- nightly ROCm Python packages;
- PyTorch ROCm packages;
- supported GPU architecture extras;
- native Linux packages;
- Windows packages;
- release status.

---

## 3.3 AMD stable ROCm Python wheel repository

For current stable ROCm/TheRock Python packages:

https://stable.repo.amd.com/rocm/whl-next/

Current stable ROCm core tarballs:

https://stable.repo.amd.com/rocm/core/tarball/

Current stable ROCm native packages:

https://stable.repo.amd.com/rocm/core/packages/

For modern TheRock releases, the aggregate Python index contains ROCm and framework packages.

Prefer stable packages when the user's exact GPU and OS are supported.

---

## 3.4 AMD nightly ROCm Python wheel repository

Only use nightly packages when stable does not satisfy the actual hardware or feature requirement.

Nightly aggregate Python index:

https://nightly.repo.amd.com/rocm/whl-next/

Nightly ROCm core tarballs:

https://nightly.repo.amd.com/rocm/core/tarball/

Nightly native packages:

https://nightly.repo.amd.com/rocm/core/packages/

Nightly builds may be unstable.

Do not choose nightly merely because the version number is newer.

---

## 3.5 AMD release-candidate and other streams

Release candidate:

https://rc.repo.amd.com/rocm/whl-next/

Best-known configuration stream:

https://bkc.repo.amd.com/rocm/whl-next/

Development stream:

https://dev.repo.amd.com/rocm/whl-next/

Only use these when there is a concrete reason.

---

## 3.6 Official PyTorch install source

PyTorch installation selector:

https://pytorch.org/get-started/locally/

Official PyTorch wheel root:

https://download.pytorch.org/whl/

Official PyTorch nightly wheel root:

https://download.pytorch.org/whl/nightly/

TorchVision repository and compatibility information:

https://github.com/pytorch/vision

Do not mix unrelated PyTorch and TorchVision lines.

Always select a documented compatible pair.

Example historical pairing:

```text
PyTorch 2.12
TorchVision 0.27
```

This is only an example.

Determine the **current** appropriate pair.

---

## 3.7 AMD ROCm FlashAttention

Requested repository:

https://github.com/ROCm/flash-attention

This repository is the requested AMD source.

Clone it recursively when the current repository requires submodules.

Record the exact revision:

```bash
git rev-parse HEAD
```

Before installing, read its current README and setup requirements.

---

## 3.8 Upstream FlashAttention reference

Upstream repository:

https://github.com/Dao-AILab/flash-attention

Use upstream to understand shared/current FlashAttention behavior when necessary.

Do not silently replace the requested `ROCm/flash-attention` source with another fork unless current AMD documentation explicitly requires it and you explain why.

---

## 3.9 AMD AITER

Official AITER repository:

https://github.com/ROCm/aiter

Read the current AITER documentation before installation.

Verify:

- supported architectures;
- supported ROCm releases;
- Python support;
- Triton requirements;
- wheel availability;
- source-build requirements;
- `AITER_USE_SYSTEM_TRITON`;
- any architecture-specific limitations.

---

## 3.10 Triton

Official Triton repository:

https://github.com/triton-lang/triton

Do **not** blindly run:

```bash
pip install -U triton
```

The Triton version bundled with or selected for ROCm PyTorch may be specifically matched to that PyTorch/ROCm stack.

AITER/FlashAttention instructions take precedence for the Triton version used by the requested FlashAttention implementation.

---

## 3.11 ComfyUI

Official repository:

https://github.com/Comfy-Org/ComfyUI

Official documentation:

https://docs.comfy.org/

Use an official Git checkout for this custom environment.

Record:

```bash
git rev-parse HEAD
```

---

# 4. PACKAGE SOURCE PRIORITY

Use this preference order unless hardware support forces another choice:

```text
current AMD stable release that explicitly supports the user's GPU/OS
    ↓
official stable PyTorch/TorchVision pair
    ↓
official stable AITER / FlashAttention-compatible dependency
    ↓
official tagged source release
    ↓
official AMD release candidate if needed
    ↓
official nightly only when stable lacks required hardware/feature support
    ↓
development/main branch only when no released option works
```

Never default to nightly or source-main simply because they are newer.

---

# 5. INTERACTION METHOD

Guide me through one validated phase at a time.

Do not dump a giant install script at the beginning.

For every phase:

1. explain briefly what is being checked;
2. provide exact copy/paste-ready commands;
3. explain what successful output should look like;
4. ask me to paste the complete output;
5. analyze my real output;
6. only then proceed.

Do not repeat questions for facts already established.

Do not assume commands succeeded.

Do not silently skip validation steps.

When troubleshooting:

- change one variable at a time;
- identify the subsystem that actually failed;
- distinguish observation from hypothesis;
- preserve known-good environments;
- do not replace working packages speculatively.

---

# 6. PHASE 1 — DISCOVER THE MACHINE

Start with discovery only.

Do not install anything yet.

Determine:

```text
Operating system
OS release
kernel version
CPU
AMD GPU model
PCI GPU identity
loaded GPU driver
/dev/kfd state on Linux
/dev/dri render devices on Linux
user groups / GPU permissions
installed ROCm components
rocminfo status
amd-smi or rocm-smi status
Python installations
Conda/Mamba availability
existing virtual environments
```

## Linux discovery examples

Use commands such as:

```bash
cat /etc/os-release
uname -a
lspci -nnk | grep -EA3 'VGA|Display|3D'
lsmod | grep amdgpu || true
ls -l /dev/kfd 2>/dev/null || true
ls -l /dev/dri/ 2>/dev/null || true
groups
which rocminfo || true
which amd-smi || true
which rocm-smi || true
which python || true
python --version || true
which conda || true
conda --version || true
```

## Windows discovery examples

Use PowerShell and official AMD tools appropriate to the current ROCm release.

Determine at minimum:

```text
Windows edition/build
AMD GPU model
AMD driver version
Adrenalin/PRO driver version
ROCm package state
Python
Conda
```

Do not assume Windows is unsupported.

Check the current ROCm and FlashAttention/AITER sources first.

If Windows supports ROCm/PyTorch/ComfyUI but **not the exact requested `ROCm/flash-attention` Triton/AITER build path**, explain that distinction clearly.

If the exact target stack still requires Linux, recommend native Linux rather than pretending Windows is equivalent.

Do not recommend WSL as a workaround unless current AMD documentation explicitly supports the exact required GPU + ROCm + FlashAttention/AITER configuration.

### STOP

After Phase 1, stop and ask me to paste the complete output.

---

# 7. PHASE 2 — IDENTIFY THE REAL GPU ARCHITECTURE

Determine the native AMD GFX architecture.

Examples:

```text
gfx1030
gfx1100
gfx1101
gfx1102
gfx1150
gfx1151
gfx1200
gfx1201
gfx942
gfx950
```

Use current ROCm/TheRock documentation to determine whether it is:

- stable-supported;
- release-candidate supported;
- nightly-supported;
- experimental;
- unsupported.

Do not infer this from memory.

---

# 8. HSA_OVERRIDE_GFX_VERSION RULE

Do not automatically set:

```bash
HSA_OVERRIDE_GFX_VERSION=...
```

If ROCm and PyTorch correctly detect the GPU's native architecture, leave it unset.

Only consider an override when:

- native detection/support is absent;
- current authoritative documentation recommends it;
- you explain exactly why;
- we validate the consequences.

A working native `gfx1151` detection should not be replaced with an unnecessary spoof.

---

# 9. PHASE 3 — DRIVER AND ROCm VALIDATION

Install or repair the GPU driver and ROCm runtime appropriate for the exact OS and GPU.

Use the current official AMD installation method.

On Linux, verify:

```bash
rocminfo
```

and where applicable:

```bash
amd-smi
```

or:

```bash
rocm-smi
```

Also verify:

```bash
ls -l /dev/kfd
ls -l /dev/dri/renderD*
groups
```

Confirm the user has the correct GPU access permissions.

If group membership changes require logout or reboot, say so explicitly.

On Windows, use the current official AMD validation tools for the selected ROCm release.

Do not proceed to PyTorch until the GPU runtime is validated.

---

# 10. PHASE 4 — CREATE A CLEAN PYTHON 3.12 ENVIRONMENT

Use Python **3.12.x**.

Prefer Conda/Mamba when available.

Do not install into the Conda `base` environment.

Use a descriptive name based on the GPU, for example:

```text
comfy-gfx1151
```

or later:

```text
comfy-gfx1151-fa-triton
```

Validate:

```bash
which python
python --version
python -m pip --version
```

The Python executable must point inside the new environment.

On Windows, use the equivalent:

```powershell
where python
python --version
python -m pip --version
```

---

# 11. PHASE 5 — SELECT A MATCHED PYTORCH + TORCHVISION PAIR

Before installation, state the proposed:

```text
GPU:
GFX:
OS:
Python:
ROCm:
torch:
torchvision:
wheel/index source:
```

Then explain why the pair is compatible.

Requirements:

- Python 3.12 must be supported;
- Torch and TorchVision must be a documented compatible pair;
- ROCm build/channel must match the selected runtime;
- use stable builds when supported;
- use nightly only when stable lacks required GPU support;
- do not combine unrelated dated nightlies;
- do not accidentally install CPU-only PyTorch.

For modern TheRock packages, inspect:

https://github.com/ROCm/TheRock/blob/main/RELEASES.md

and use the correct device extra when applicable, such as:

```text
device-gfx1151
```

Do not copy that exact device extra unless it matches my actual GPU.

TheRock modern stable aggregate index:

```text
https://stable.repo.amd.com/rocm/whl-next/
```

TheRock nightly aggregate index:

```text
https://nightly.repo.amd.com/rocm/whl-next/
```

If using official PyTorch-hosted wheels instead, use the current ROCm index recommended by:

https://pytorch.org/get-started/locally/

Do not invent a wheel URL.

---

# 12. PHASE 6 — VALIDATE PYTORCH BEFORE COMFYUI

Run:

```python
import sys
import torch
import torchvision

print("Python:", sys.executable)
print("torch:", torch.__version__)
print("torchvision:", torchvision.__version__)
print("HIP:", torch.version.hip)
print("CUDA API available:", torch.cuda.is_available())

if torch.cuda.is_available():
    print("GPU:", torch.cuda.get_device_name(0))
```

Remember: ROCm PyTorch intentionally exposes GPU APIs through `torch.cuda`.

Then perform a real GPU operation:

```python
import torch

device = "cuda"
a = torch.randn((4096, 4096), device=device, dtype=torch.float16)
b = torch.randn((4096, 4096), device=device, dtype=torch.float16)
c = a @ b
torch.cuda.synchronize()

print(c.shape)
print(c.dtype)
print(c.device)
```

If BF16 is supported, test it too:

```python
import torch

a = torch.randn((2048, 2048), device="cuda", dtype=torch.bfloat16)
b = torch.randn((2048, 2048), device="cuda", dtype=torch.bfloat16)
c = a @ b
torch.cuda.synchronize()

print(c.shape, c.dtype, c.device)
```

Then run:

```bash
python -m pip check
```

Do not proceed until any failure is understood.

---

# 13. PHASE 7 — INSTALL COMFYUI

Clone the official repository:

```text
https://github.com/Comfy-Org/ComfyUI
```

Use a normal Git checkout.

Record:

```bash
git rev-parse HEAD
```

Install ComfyUI dependencies into the validated Python environment.

Before running a requirements install, inspect whether the operation might replace:

```text
torch
torchvision
triton
```

After installing ComfyUI dependencies, repeat:

```text
Python executable
torch version
torchvision version
HIP version
GPU identity
pip check
```

Then start ComfyUI **without custom FlashAttention first**.

Validate base startup and GPU recognition before changing the attention implementation.

---

# 14. PHASE 8 — TEACH THE THREE DIFFERENT TRITON PATHS

You must explicitly explain that these are independent.

## A. FlashAttention AMD Triton/AITER

Selected with:

```bash
export FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
```

This is the target of this project.

---

## B. PyTorch AOTriton / SDPA

Variables may include:

```bash
TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1
```

This relates to PyTorch SDPA / PyTorch cross-attention.

It is **not the same backend** as the external `flash-attn` package.

Do not claim it is required merely because ComfyUI is launched with:

```text
--use-flash-attention
```

---

## C. comfy-kitchen Triton

ComfyUI/comfy-kitchen can independently use Triton for model operations such as quantized linear kernels.

The option:

```text
--enable-triton-backend
```

controls a different subsystem.

It does not mean:

```text
enable FlashAttention Triton
```

Do not automatically enable it.

On some AMD GPUs the native comfy-kitchen HIP path is faster.

Benchmark it separately only after the FlashAttention baseline works.

---

# 15. PHASE 9 — PREPARE FLASHATTENTION BUILD DEPENDENCIES

Before installation, inspect the current `ROCm/flash-attention` README.

Likely dependencies include:

```text
git
git submodules
ninja
packaging
psutil
compiler toolchain
ROCm development libraries
PyTorch
Triton
AITER
```

Use current repository requirements.

Do not install arbitrary Triton versions over a PyTorch-matched Triton unless the current AITER/FlashAttention documentation specifically requires it.

---

# 16. PHASE 10 — CLONE ROCm/FLASH-ATTENTION

Clone:

```text
https://github.com/ROCm/flash-attention
```

Prefer:

```bash
git clone --recursive https://github.com/ROCm/flash-attention.git
```

Then inspect:

```bash
cd flash-attention
git status
git rev-parse HEAD
git submodule status
```

Record the revision.

Read the current README before installing.

---

# 17. PHASE 11 — BUILD THE AMD TRITON/AITER FLASHATTENTION PATH

The required implementation is selected using:

```bash
export FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
```

Current upstream FlashAttention behavior uses AITER-provided Triton kernels for the AMD Triton backend.

Where current documentation supports it, preserve a Triton installation already matched to the ROCm/PyTorch environment using:

```bash
export AITER_USE_SYSTEM_TRITON=1
```

Understand the distinction:

```text
AITER_USE_SYSTEM_TRITON=1
```

means approximately:

```text
use the Triton already installed in this environment
rather than replacing it while installing AITER
```

It is primarily an installation/build dependency choice.

It does **not** enable FlashAttention Triton at runtime.

The runtime/backend selector is:

```bash
FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
```

Current builds may use a command similar to:

```bash
FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE \
AITER_USE_SYSTEM_TRITON=1 \
python -m pip install --no-build-isolation .
```

But verify the command against the **current** requested repository before executing it.

If the current repository supports using an already-installed AITER, evaluate:

```bash
FLASH_ATTENTION_USE_SYSTEM_AITER=TRUE
```

only when appropriate.

Do not set it blindly.

---

# 18. AITER ENVIRONMENT VARIABLE LESSONS

Do not blindly restore internal variables seen in another machine's shell.

Variables such as:

```text
AITER_GPU_ARCHS
AITER_ASM_DIR
OPUS_GEN_CO_DIR
```

may be derived by AITER or build/JIT tooling.

Only set them manually when current AITER instructions explicitly require them.

For example:

```bash
export AITER_GPU_ARCHS=gfx1151
```

should not be copied just because another machine used `gfx1151`.

First determine my actual architecture.

Likewise:

```bash
export AITER_USE_SYSTEM_TRITON=1
```

is mainly relevant while installing/building AITER/FlashAttention.

It is not the runtime backend selector.

---

# 19. PHASE 12 — VALIDATE FLASHATTENTION OUTSIDE COMFYUI

Do not use ComfyUI as the first FlashAttention test.

Validate imports and runtime first.

Check:

```python
import os
import sys
import torch
import torchvision
import triton
import aiter
import flash_attn

print("Python:", sys.executable)
print("Torch:", torch.__version__)
print("TorchVision:", torchvision.__version__)
print("HIP:", torch.version.hip)
print("GPU:", torch.cuda.get_device_name(0))
print("Triton:", triton.__version__)
print("FlashAttention:", flash_attn.__version__)
print(
    "FLASH_ATTENTION_TRITON_AMD_ENABLE:",
    os.environ.get("FLASH_ATTENTION_TRITON_AMD_ENABLE")
)
print("AITER import: OK")
```

Where the current API exposes backend state, inspect it.

For example, some revisions expose information through:

```python
import flash_attn.flash_attn_interface as fai
print(getattr(fai, "USE_TRITON_ROCM", "not exposed by this revision"))
```

Do not assume that exact symbol exists in every revision.

Then perform a real FlashAttention GPU forward operation using a supported dtype and dimensions.

After the operation call:

```python
torch.cuda.synchronize()
```

so asynchronous HIP failures surface at the correct point.

Do not consider FlashAttention validated merely because:

```python
import flash_attn
```

works.

---

# 20. PHASE 13 — CREATE A MINIMAL RUNTIME ENVIRONMENT FILE

Create a persistent runtime file only after the working configuration is established.

Do not copy the entire shell environment.

Categorize every candidate variable as:

```text
required runtime selector
GPU selection
performance tuning
benchmark reproducibility
installation-only
debug-only
unnecessary/default
```

The core FlashAttention selector is:

```bash
export FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
```

Other variables must be justified.

Potential variables to evaluate:

```text
HIP_VISIBLE_DEVICES
PYTORCH_ALLOC_CONF
PYTORCH_TUNABLEOP_ENABLED
PYTORCH_TUNABLEOP_TUNING
TORCHINDUCTOR_CACHE_DIR
FLASH_ATTENTION_TRITON_AMD_AUTOTUNE
TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL
HSA_OVERRIDE_GFX_VERSION
HSA_ENABLE_SDMA
HSA_DISABLE_FRAGMENT_ALLOCATOR
COMFY_KITCHEN_DISABLE_HIP
```

Rules:

### `HIP_VISIBLE_DEVICES`

Useful for explicit GPU selection.

On a single-GPU system:

```bash
export HIP_VISIBLE_DEVICES=0
```

is optional but can improve reproducibility.

### `PYTORCH_ALLOC_CONF`

This changes PyTorch GPU allocator behavior.

Only preserve a value when intentionally part of the benchmark baseline.

Example from a previously tested machine:

```bash
export PYTORCH_ALLOC_CONF='expandable_segments:True,garbage_collection_threshold:0.9,max_split_size_mb:512'
```

Do not assume it is optimal for every machine.

### PyTorch TunableOp

Variables may include:

```bash
PYTORCH_TUNABLEOP_ENABLED
PYTORCH_TUNABLEOP_TUNING
PYTORCH_TUNABLEOP_VERBOSE
```

TunableOp can cause large first-run tuning overhead.

Benchmark it separately.

Do not silently enable it.

### `TORCHINDUCTOR_CACHE_DIR`

This controls where TorchInductor/Triton compiled artifacts are cached.

It does **not** control ComfyUI's diffusion-model cache.

Example:

```bash
export TORCHINDUCTOR_CACHE_DIR=/tmp/torchinductor_$USER
```

### `FLASH_ATTENTION_TRITON_AMD_AUTOTUNE`

Potentially enables better FlashAttention throughput:

```bash
export FLASH_ATTENTION_TRITON_AMD_AUTOTUNE=TRUE
```

but introduces one-time autotuning/warmup overhead.

Establish a baseline first.

### `TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL`

This belongs to PyTorch AOTriton/SDPA.

Do not enable it merely because external FlashAttention uses Triton.

### `HSA_OVERRIDE_GFX_VERSION`

Leave unset when the GPU is natively supported and correctly identified.

### `HSA_ENABLE_SDMA`

Normal enabled behavior is usually the default.

Do not explicitly set it unless required for reproducibility or debugging.

### `HSA_DISABLE_FRAGMENT_ALLOCATOR`

Do not use debugging allocator settings as permanent benchmark optimization.

### `COMFY_KITCHEN_DISABLE_HIP`

Do **not** disable HIP by default.

For the initial baseline, keep comfy-kitchen HIP eligible:

```bash
unset COMFY_KITCHEN_DISABLE_HIP
```

---

# 21. PHASE 14 — INITIAL COMFYUI FLASHATTENTION LAUNCH

After independent validation succeeds, launch ComfyUI with FlashAttention.

Typical Linux launch:

```bash
export FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE

cd /path/to/ComfyUI

python main.py \
  --use-flash-attention \
  --disable-xformers
```

Add:

```text
--listen
--enable-manager
```

only if desired.

Do not add:

```text
--enable-triton-backend
```

merely because FlashAttention is using Triton.

That controls comfy-kitchen, not FlashAttention.

---

# 22. INTERPRETING COMFYUI LOGS CORRECTLY

A log line:

```text
Using Flash Attention
```

proves that ComfyUI selected its external FlashAttention feature.

By itself it does **not** prove the exact internal ROCm implementation.

Use multiple pieces of evidence:

```text
FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
AITER import success
Triton import success
FlashAttention build provenance
backend/interface inspection where available
successful real GPU FlashAttention test
ComfyUI "Using Flash Attention"
```

Similarly, a comfy-kitchen line such as:

```text
Found comfy_kitchen backend triton:
available=True
```

does **not** prove that Triton was selected for model operations.

Distinguish:

```text
available
enabled
selected
executed
```

---

# 23. PHASE 15 — COMPLETE A REAL COMFYUI GENERATION

Start with a simple known-working workflow.

Do not immediately add:

- custom VAE Triton nodes;
- experimental quantization;
- multiple attention implementations;
- Torch compile experiments;
- several environment changes at once.

Capture logs from:

```text
got prompt
```

through completion.

If execution stalls, identify the last confirmed operation.

Do not assume the issue is FlashAttention simply because it is enabled.

Example lesson:

If a workflow loads the VAE and stalls **before the diffusion model is requested**, the problem may be VAE/reference-image preprocessing rather than diffusion attention.

---

# 24. PHASE 16 — OPTIONAL comfy-kitchen TRITON BENCHMARK

Only after the baseline works should we evaluate:

```text
--enable-triton-backend
```

This enables the independent comfy-kitchen Triton backend.

Do not confuse it with FlashAttention Triton/AITER.

On AMD, comfy-kitchen may prefer HIP over Triton when HIP supports the operation.

If we want a forced Triton A/B, first verify the current comfy-kitchen backend priority and then explicitly control HIP eligibility.

Do not alter the FlashAttention implementation during the same test.

The comparison should be:

```text
Test A:
FlashAttention Triton/AITER
+
comfy-kitchen HIP

Test B:
FlashAttention Triton/AITER
+
comfy-kitchen Triton
```

Keep everything else identical.

---

# 25. BENCHMARKING LESSONS

Cold-run total time and warm sampler speed are different measurements.

For each configuration record:

```text
first workflow total
second workflow total
third workflow total
sampling time
average seconds/iteration
resolution
steps
seed
model
text encoder
VAE
attention backend
comfy-kitchen backend
environment variables
PyTorch/TorchVision versions
FlashAttention revision
AITER version/revision
Triton version
```

Use at minimum:

```text
Run 1 = cold
Run 2 = warm
Run 3 = warm
```

Prefer more warm runs for stable averages.

Do not conclude that BF16 compute is intrinsically faster than INT8 because BF16 wins a cold first run.

Custom quantized kernels can have:

- initialization overhead;
- kernel preparation;
- JIT compilation;
- rotation/activation preparation;
- autotuning;
- cache warmup.

For performance conclusions, prioritize:

```text
warm sampling time
warm seconds/iteration
```

over first-run total time.

---

# 26. FLASHATTENTION AUTOTUNING

After the default AMD Triton/AITER configuration is stable, optionally test:

```bash
export FLASH_ATTENTION_TRITON_AMD_AUTOTUNE=TRUE
```

Explain that the first run may be much slower while kernels are tuned.

Do not compare:

```text
cold autotuned run
```

against:

```text
already-warm non-autotuned run
```

Compare warmed configurations.

---

# 27. MODEL LOADING AND CACHE LESSON

Do not confuse compiler/kernel caches with ComfyUI model caching.

For example:

```bash
TORCHINDUCTOR_CACHE_DIR=/tmp/torchinductor_user
```

controls compiler/generated-kernel caching.

It does not configure whether ComfyUI keeps diffusion models, text encoders, or VAEs resident.

Likewise:

```bash
PYTORCH_ALLOC_CONF=...
```

changes PyTorch allocator behavior.

It can indirectly influence memory pressure but does not itself select ComfyUI's model caching policy.

If model-loading behavior changes, inspect:

- ComfyUI launch arguments;
- ComfyUI version;
- model-management configuration;
- available RAM/VRAM;
- current cache mode;
- weight-offload state.

---

# 28. DO NOT CONFLATE THESE SUBSYSTEMS

Always distinguish:

```text
AMDGPU kernel driver
Windows AMD driver
ROCm/HIP
HSA
PyTorch ROCm
TorchVision
PyTorch SDPA
PyTorch AOTriton
external flash-attn
FlashAttention ROCm CK
FlashAttention AMD Triton/AITER
Triton compiler/runtime
AITER
comfy-kitchen HIP
comfy-kitchen Triton
ComfyUI model cache
ComfyUI VAE attention
third-party custom-node Triton kernels
```

A failure in one does not prove a failure in another.

---

# 29. PRESERVE WORKING ENVIRONMENTS

Once a working environment exists, do not destroy it merely to test another backend.

Prefer cloning.

Example:

```bash
conda create \
  --name comfy-gfx1151-fa-triton-test \
  --clone comfy-gfx1151
```

Use the actual environment names from my machine.

Record:

```bash
conda env list
python -m pip freeze
python -m pip check
```

before significant experimentation.

---

# 30. FINAL REPRODUCIBILITY PACKAGE

At the end, help me create:

```text
comfy-rocm.env
start-comfyui.sh
environment-report.txt
pip-freeze.txt
git-revisions.txt
validation-report.txt
```

## `environment-report.txt`

Include:

```text
date
OS
OS version
kernel
GPU
GFX architecture
driver version
ROCm version
HIP version
Python version
Python executable
Conda environment
torch version
torchvision version
Triton version
AITER version/revision
FlashAttention version
FlashAttention Git commit
ComfyUI Git commit
pip check result
relevant runtime environment variables
launch command
```

## `git-revisions.txt`

Record at minimum:

```text
ComfyUI repository URL + commit
ROCm/flash-attention repository URL + commit
AITER commit if source-installed
Triton commit if source-installed
```

## `comfy-rocm.env`

Only include meaningful runtime variables.

Do not copy unrelated shell/session variables such as:

```text
DBUS_*
GNOME_*
XDG_*
COLORTERM
DISPLAY
CONDA_BACKUP_*
LS_COLORS
GPG_AGENT_INFO
SSH_AUTH_SOCK
```

unless there is an unusual demonstrated requirement.

---

# 31. FINAL VALIDATION GATE

Do not declare the build complete until all applicable items pass:

```text
[ ] OS support verified against current AMD documentation
[ ] exact GPU identified
[ ] exact native GFX architecture identified
[ ] driver installed and functioning
[ ] ROCm/HIP runtime functioning
[ ] GPU permissions correct
[ ] Python 3.12.x environment active
[ ] Torch/TorchVision compatibility verified
[ ] correct ROCm-enabled Torch installed
[ ] PyTorch sees the correct AMD GPU
[ ] real GPU tensor operation succeeds
[ ] FP16 operation succeeds
[ ] BF16 operation succeeds where supported
[ ] pip check passes
[ ] ComfyUI official repository installed
[ ] ComfyUI base startup works
[ ] ROCm/flash-attention repository cloned
[ ] exact FlashAttention Git revision recorded
[ ] FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE used for target build/runtime
[ ] Triton imports successfully
[ ] AITER imports successfully
[ ] FlashAttention imports successfully
[ ] real FlashAttention GPU forward test succeeds
[ ] AMD Triton/AITER backend evidence collected
[ ] ComfyUI starts with --use-flash-attention
[ ] complete ComfyUI generation succeeds
[ ] minimal runtime environment file created
[ ] reproducible launch script created
[ ] version/environment report created
```

---

# 32. TROUBLESHOOTING DISCIPLINE

Whenever something fails:

1. quote the exact failing command;
2. quote the relevant output;
3. identify the subsystem;
4. state what the evidence proves;
5. state what it does **not** prove;
6. list the smallest number of plausible causes;
7. run the smallest diagnostic that separates those causes;
8. do not replace working packages until evidence requires it.

Avoid statements like:

```text
"ROCm is broken"
"FlashAttention is broken"
"Triton is broken"
"PyTorch is incompatible"
```

unless evidence actually supports that conclusion.

---

# 33. VERSION-SELECTION REPORT BEFORE INSTALLATION

Before installing the framework stack, explicitly show me this resolved plan:

```text
Operating system:
GPU:
GFX architecture:
Driver:
ROCm release:
ROCm source/repository:
Python:
Environment name:
PyTorch:
TorchVision:
PyTorch/TorchVision source:
Triton:
AITER:
FlashAttention repository:
FlashAttention revision/tag:
ComfyUI repository:
ComfyUI revision/tag:
```

Explain why those choices are mutually compatible.

If any compatibility point is uncertain, resolve it before installation.

---

# 34. WINDOWS VS LINUX DECISION RULE

Do not assume Linux automatically.

First identify my OS.

If I am on Windows:

1. verify my exact GPU against current AMD Windows ROCm compatibility;
2. verify PyTorch ROCm support;
3. verify current AITER support;
4. verify current `ROCm/flash-attention` source-build/runtime support;
5. verify the AMD Triton/AITER path selected by:
   ```bash
   FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
   ```
6. only proceed natively if the exact target stack is currently supported.

If Windows supports ROCm PyTorch and ComfyUI but not the exact requested FlashAttention/AITER stack, explain that clearly.

In that case, recommend a supported native Linux configuration for the exact target rather than silently downgrading the objective.

Do not claim "ROCm is Linux only" without current verification.

---

# 35. REFERENCE LESSON FROM A PREVIOUS WORKING MACHINE

A previously successful AMD machine used:

```text
GPU:
Radeon 8060S

GFX:
gfx1151

Python:
3.12.x

PyTorch:
2.12.0a0+rocm7.13.0a20260411

TorchVision:
0.27.0a0+rocm7.13.0a20260411

FlashAttention:
AMD Triton/AITER path

Runtime selector:
FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
```

This is **not a prescription** for a new installation.

The lessons are:

- Torch and TorchVision must be compatible;
- same-line/same-date nightlies are preferable to unrelated nightlies when a nightly is actually required;
- current stable packages should be preferred if they now support the hardware;
- `gfx1151` should be detected natively when current ROCm supports it;
- do not use `HSA_OVERRIDE_GFX_VERSION` unnecessarily;
- external FlashAttention Triton/AITER and comfy-kitchen Triton are separate;
- first-run timing is not the same as warm inference performance;
- preserve known-good environments before testing alternatives.

---

# 36. BEGIN NOW

Begin with **Phase 1 only**.

Assume nothing.

Give me a compact set of discovery commands appropriate for my current OS that establish:

```text
OS
OS version
kernel/build
GPU model
GPU driver
GFX architecture if currently discoverable
ROCm presence
ROCm/HIP device visibility
GPU permissions
Python state
Conda/Mamba state
```

Do not recommend installing or changing anything yet.

After giving the discovery commands, stop and ask me to paste the complete output.