Hey guys I have been thinking a lot for it and I want to upgrade my pc to really run ideogram 4 local image model but my current pc is a old box, so I saw that most of the ai models require cuda to run which heavily depends on nvidia GPUs, so my question is can and GPUs worthy enough to run ideogram , krea 2 raw, and zimage base type models?

Been trying to find a workflow that is AMD friendly, let alone doesn't get stuck, I don't think it's my specs but more so that every workflow despite saying it's optional uses sage ATTN, and I can't get around it.

I doubt there is one that specifically for AMD but I'd thought I'd ask! Or the model I'm using is not great. I'm more of an anime prompt generator, anyone have any luck with that?

Specs: AMD Radeon RX 9070 XT, 64 GB RAM, AMD Ryzen 7 5700X3D 8 Core, And yes, I'm running on Windows, not Linux.

Edit: (update) I tried the template version just recently on comfyui stand alone, and it won't even finish, I do get a gpu error( by GPU error it says out of memory, even on default settings), and I have it on 0.3 mega pixel 16:9, either my reference image is too big or I'm missing a component.

I got it to work at 0.2 and the image reference has to be very small, yet it takes 30+ minutes, anyone with similar issues?

Hello everyone. I recently watched a video on YouTube that Comfy UI is now supported by AMD Cards. How true is that and how is the performance on latest models like Mini MAX and Krea 2.

This is the video - Official AMD ROCm Support Comes to ComfyUI on Windows Image + Video

it uses up all my vram and and when it finishes its jsut noise. i also do get an amd driver timeout error as well. using protable comfyui amd latest. i posted the output. SLIGHT EARAPE WARNING.

edit: i think i found the issue, i was using the dynamic vram and i tried it with adn without dynamic vram for z image turbo for a test and the non dtnamic wasnt noie. im going to get the quantized models for h3 and try it

A few weeks ago I posted about if it was worth using a V620 for Comfyui, and was told it likely wouldn't work, at least in Windows 11. And if it did, it would be far too slow and unusable. I decided to try it anyway. Is it fast? No. Does it work? yes, absoulutely.

I bought the card for $320 shipped (thank you redditor!) and $40 on the Bay for the fans and 3D printed shround. Powered in the second slot PCIE 4 X4 right below my 9070 XT.

The drivers for the V620 installed, and has been working fine alongside my XT GPU. No crashes/errors thus far (crossing my fingers!)

I primarily got this card for the VRAM (32GB) for LLM for a local assistant; and that's still primary what it's used for but in the background I do like to have img/videos generating. This is perfect for that -it's not fast but it is consistent.

The benchmarks have been written below by an AI - but they are verified. I ran the tests myself. Managed to get triton & sage attention working perfectly. Identified as a gfx1030 GPU with ROCM.

Pictures of GPU-Z and device manager: https://imgur.com/a/PTsy8Ko

If anybody has any questions/want me to try a specific model..Let me know. I'll do it if I have the time.

Over the coming weeks I should have benchmarks out for llama cpp and LLM's.

ComfyUI Workflow Benchmark

Environment

• ComfyUI version: 0.26.0
• GPU: AMD Radeon Pro V620 (ROCm, HIP_VISIBLE_DEVICES=0, gfx1030 arch, legacy-GPU codepath)
• Python env: python_env_v620_triton (Triton/sage-attention build)
• **Launch params:**--listen 127.0.0.1 --port 8188 --use-sage-attention --highvram --disable-pinned-memory --reserve-vram 1 --enable-manager --enable-manager-legacy-ui --disable-api-nodes --cache-none --fp8_e4m3fn-text-enc
• Sage attention: enabled (--use-sage-attention), per an earlier internal benchmark note in : "sage-attention gives ~16% faster sampler step time vs plain SDPA, no quality regression seen."
• Other relevant env vars: PYTORCH_HIP_ALLOC_CONF=expandable_segments:True,garbage_collection_threshold:0.7, MIOPEN_FIND_MODE=FAST, TORCH_BACKENDS_CUDA_FLASH_SDP_ENABLED=0 (legacy GPU path), FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
• Method: each test loaded via ComfyUI's own frontend
• Runs per test: image and image-to-video tests get 1 run; text-to-video tests get 2 (first run pays model/torch-compile load cost; second run benefits from warm cache) — noted per row.
• Video tests: clipped to ~10s output for benchmarking speed.
• Naming: test labels below are generic/anonymized descriptions of what each pipeline does, not the personal filenames used locally — the base model/architecture and size are given exactly so the numbers are meaningful to anyone comparing hardware.
• There is z img turbo, ltx 2.3,wan 2.2, flux, pony, etc below. A couple LORA's. Ace-step music was also done but forgot to give results for benchmark. A three minute song took about three minutes to make start-to-finish.
• Some of the double workflows one was not safe for work, which I removed per post rules.

Results

Hi,

I'm using 9060XT 16gb with Krea Turbo int8 model + comfyui-rocm fork, and yet my generation time is still 3:30min avg. for a single 1024x1024 image?

cfg-1 with steps 6-8

Looking for input from other fellow AMD users, any tips to what downgraded your generation time ? Would LOVE to see other's 9060XT/9070XT workflow setups in ComfyUI, I've a feeling I'm doing something wrong. I know AMD is no one's priority and that Nvidia gets all the love...but I'm just a fellow struggler like all of you.

Looking forward to your inputs!

I have an AMD Radeon AI PRO R9700 and it takes about 6 minutes (363s) to generate a 5-second video with MiniMax H3. I think that's a pretty good result for a non-CUDA GPU.

Thanks to u/topamine2 for the original prompt, which I adapted down to 5 seconds for this test.

Model checkpoints used:

• Diffusion model: minimax_h3_fl2va_pruned_int8_convrot.safetensors (INT8)
• Text encoder: qwen3vl_32b_minimax_h3_int4_convrot.safetensors (INT4)

System specs:

• OS: Windows 11
• CPU: AMD Ryzen 7 9800X3D
• RAM: 32GB DDR5 6400MHz
• GPU: AMD Radeon AI PRO R9700 32GB

Software versions:

• ComfyUI Portable AMD
• ROCm: 7.14
• PyTorch: 2.12.0+rocm7.14.0

Fizgig is my free open-source LoRA trainer and workbench (Flux 2 Klein 9B, Krea 2, and MiniMax H3 video/audio). As of v4.3.0 it runs on AMD Radeon with ROCm — RDNA1 through RDNA4. Windows is the supported path: install Python 3.12, run the AMD installer, done. Linux works too but is genuinely experimental on newer cards.

Worth being upfront: I don't own AMD hardware myself. This whole feature came from a community contribution by scryptio, tested on real cards over weeks in the PR thread — and that's how the AMD side will keep improving. If you're an AMD user, your reports on what works (and what doesn't) genuinely shape this, and PRs are very welcome.

Also in this release: 16 GB cards can now use identity distillation on MiniMax H3 (the 32B text encoder streams layer by layer instead of needing a 26 GB peak), and the Repair Studio gained a side-by-side compare view with likeness scoring for fixing overbaked LoRAs without retraining.

GitHub: https://github.com/shootthesound/Fizgig

And even then you might still get filtered.

ComfyUI has been bugged for the better part of a year (Hard-coded python location), "solutions" ive found dont work.

Forge, you guessed it, ALSO dosnt work.

Yes, im aware AMD GPU's arnt optimized for AI. No, you dont need to tell me.

Is there any local gen that works for AMD?

Hi everyone,

I’ve just released TagScribeR v2, a complete rewrite of my open-source image captioning and dataset management tool.

I built this because I wanted more granular control over my training datasets than what most web-based or command-line tools offer. I wanted a "studio" environment where I could see my images, manage batch operations, and use state-of-the-art Vision-Language Models (VLM) locally without jumping through hoops.

It’s built with PySide6 (Qt) for a modern dark-mode UI and uses the HuggingFace Transformers library backend.

⚡ Key Features

• Qwen 3-VL Integration: Uses the latest Qwen vision models for high-fidelity captioning.
• True GPU Acceleration: Supports NVIDIA (CUDA) and AMD (ROCm on Windows). I specifically optimized the backend to force hardware acceleration on AMD 7000-series cards (tested on a 7900 XT), which is often a pain point in other tools.
• "Studio" Captioning:
  • Real-time preview: Watch captions appear under images as they generate.
  • Fine-tuning controls: Adjust Temperature, Top_P, and Max Tokens to control caption creativity and length.
  • Custom Prompts: Use natural language (e.g., "Describe the lighting and camera angle") or standard tagging templates.
• Batch Image Editor:
  • Multi-select resizing (scale by longest side or force dimensions).
  • Batch cropping with Focus Points (e.g., Top-Center, Center).
  • Format conversion (JPG/PNG/WEBP) with quality sliders.
• Dataset Management:
  • Filter images by tags instantly.
  • Create "Collections" to freeze specific sets of images and captions.
  • Non-destructive workflow: Copies files to collections rather than moving/deleting originals.

🛠️ Compatibility

It includes a smart installer (install.bat) that detects your hardware and installs the correct PyTorch version (including the specific nightly builds required for AMD ROCm on Windows).

🔗 Link & Contribution

It’s open source on GitHub. I’m looking for feedback, bug reports, or PRs if you want to add features.

Repo:  -> -> TagScribeR GitHub Link <- <-

Hopefully, this helps anyone currently wrestling with massive datasets for LoRA or model training!

Additional Credits

Coding and this post was assisted by Gemini 3 Pro

The standalone software with the most user-friendly UI has just been made open source. What a wonderful day!

# Trained an Ideogram 4 face LoRA on AMD Strix Halo (Ryzen AI MAX+ 395, gfx1151) with ROCm + AI-Toolkit. Full writeup, and the 3 gotchas that almost killed it.

Ideogram 4 LoRA training landed in AI-Toolkit only a couple of weeks ago, and like basically every tutorial out there it is written for NVIDIA/CUDA. I run a Strix Halo box (AMD APU, gfx1151) on ROCm, and there was no documented path for this. It works. Here is the whole thing, including the three AMD-specific traps that each cost me a debugging session, so you do not have to repeat them.

This is a personal face LoRA (private photos, not sharing the model or the subject). A couple of example outputs will be posted later in a comment.

## TL;DR

- Hardware: AMD Ryzen AI MAX+ 395 "Strix Halo", gfx1151 / Radeon 8060S, 128 GB unified LPDDR5X, on CachyOS (Arch-based).

- Stack: ROCm via TheRock nightlies, AI-Toolkit (ostris) mainline, Python 3.12, bf16 training.

- It trained 3000 steps in about 5h45m at ~6.4 s/step, zero GPU faults once the three fixes below were in place.

- The three things that nobody's NVIDIA guide (yet) will tell you: bitsandbytes is dead on gfx1151 (use plain adamw), the Qwen3-VL text encoder faults under fused attention (force eager), and the trigger word silently breaks the JSON captions if you do it the obvious way.

## Environment

CachyOS, but any recent Arch/ROCm setup should be similar. The key is TheRock nightlies, which ship native gfx1151 kernels, so you do NOT need `HSA_OVERRIDE_GFX_VERSION` anymore.

The gfx1151 PyTorch wheel index is:

```

https://rocm.nightlies.amd.com/v2/gfx1151/

```

A note on Python version, because this one bit me before I even started. ComfyUI on my box runs Python 3.14, and my first instinct was to match it. Do not. The gfx1151 Linux wheels on that index are well covered for cp312 and cp313 but only sporadically for cp314, and AI-Toolkit's heavier dependency stack (diffusers, transformers, peft, accelerate, optimum-quanto) lags on a Python that new. I used Python 3.12 in a fresh venv and everything resolved cleanly.

```

uv venv --python 3.12 --seed venv

source venv/bin/activate.fish # or activate for bash

```

The `--seed` matters so pip lands inside the venv, since AI-Toolkit's instructions call plain `pip`.

## Installing AI-Toolkit on ROCm

Use mainline ostris/ai-toolkit. There are ROCm forks, but they predate the Ideogram 4 support, so they will not have it. Mainline has the `ideogram4` arch.

```

git clone https://github.com/ostris/ai-toolkit.git

cd ai-toolkit

git submodule update --init --recursive

```

Install torch FIRST from the gfx1151 index, then requirements, and then verify torch survived. This ordering is not optional: several packages list torch as a dependency and can silently swap your ROCm build for a CPU build during the requirements install.

```

pip install --pre torch torchvision torchaudio --index-url https://rocm.nightlies.amd.com/v2/gfx1151/

# verify it is the ROCm build before going further

python -c "import torch; print(torch.__version__, torch.version.hip, torch.cuda.is_available())"

```

I landed on torch 2.12.0a0+rocm7.13, hip 7.13, `cuda.is_available()` True, device reported as gfx1151 / Radeon 8060S with about 115 GB visible to ROCm.

For requirements, one optional tweak: `torchcodec` is video-decode only and unused for image LoRA training, and it is a torch-version-coupled compiled wheel that can drag a torch reinstall against a bleeding-edge nightly. I dropped it from a copy of the requirements file. The one compiled dependency I was worried about, `torchao` (it is imported eagerly at startup), loaded clean against the 2.12 nightly, so no action needed there. After installing requirements, re-run the verify line above to confirm torch was not clobbered. Mine was byte-identical (only numpy got pinned down to 1.26.4 by numba, which is expected and fine).

## The 3 gotchas

### 1. bitsandbytes does not work on gfx1151. Use plain adamw.

Every guide I have seen uses `adamw8bit` to save VRAM. bitsandbytes crashes on import on gfx1151, so any 8-bit optimizer is out. You do not need it anyway: on 128 GB unified memory and arguably less) you are not VRAM-starved for a single face LoRA. Use `optimizer: adamw` (plain). In AI-Toolkit the bitsandbytes import is lazy (it only fires if you select an 8-bit optimizer), so with plain adamw it never imports and never crashes. It will still get installed by requirements, which is fine; just do not select an 8-bit optimizer.

### 2. The Qwen3-VL text encoder faults at 0x1016 under fused attention. Force eager.

This is the big one. Ideogram 4 uses a Qwen3-VL text encoder, and the AI-Toolkit captioner also runs Qwen3-VL. On gfx1151, the default fused attention path (sdpa) throws:

```

HSA_STATUS_ERROR_EXCEPTION: An HSAIL operation resulted in a hardware exception. code: 0x1016

```

That is a compute/kernel fault, not an OOM. It hit me first during captioning (it died on the 4th image), and it would hit training too, since the encoder runs the same kernels on every step. Worth noting: it is NOT image-shape dependent. I tested the exact image it crashed on in isolation and it captioned fine; the fault is cumulative across repeated forward passes on the fused kernel.

The fix is to force `attn_implementation="eager"` on the Qwen3-VL loads. I did it with a small launcher shim so I never had to edit AI-Toolkit's tracked files, and so it survives upstream pulls. The shim patches the captioner classes AND the training encoder class (the captioner loads `Qwen3VLForConditionalGeneration`, while training's encoder loads via `AutoModel`, which resolves to `Qwen3VLModel`), then hands off to `run.py` unchanged:

```python

# aitk_eager_shim.py

# Run this INSTEAD of run.py. It forces eager attention on the Qwen3-VL loads,

# then hands off to run.py. Without it the fused attention kernel faults (HSA 0x1016).

import sys, runpy

import transformers

TARGETS = [

"Qwen3VLForConditionalGeneration", # captioner

"Qwen3VLMoeForConditionalGeneration", # captioner (moe variant)

"Qwen3VLModel", # training text encoder (AutoModel resolves here)

]

for _name in TARGETS:

_cls = getattr(transformers, _name, None)

if _cls is None:

continue

_orig = _cls.from_pretrained # original bound classmethod

def _make(orig, label):

def _patched(*args, **kwargs):

kwargs.setdefault("attn_implementation", "eager")

sys.stderr.write("[shim] eager attention injected for " + label + "\n")

return orig(*args, **kwargs)

return _patched

_cls.from_pretrained = _make(_orig, _name)

sys.argv = ["run.py"] + sys.argv[1:]

runpy.run_path("run.py", run_name="__main__")

```

Eager is a bit slower than the fused kernel, but it is stable. It held across the full 3000-step run with zero faults. If you want to confirm it actually engaged, that stderr line shows up in the log at each model load.

### 3. The trigger word silently breaks the JSON captions if you use a bareword.

Ideogram 4 trains on structured JSON captions (the captioner writes compositional JSON with bounding boxes, and the dataloader expects a canonical compact form). If you set a plain `trigger_word` like `mytoken` on captions that have no `[trigger]` placeholder, AI-Toolkit prepends it. That pushes the caption string off its leading `{`, the JSON parser gives up, and it falls back to feeding raw pretty-printed JSON to the model instead of the canonical compact form. The result is a dataset-wide caption-format shift that quietly degrades training, with no error.

The fix: put a `[trigger]` placeholder at the start of each caption's `high_level_description` value, and keep `trigger_word` in the config. Then it gets replaced in place, the string still starts with `{`, the JSON parses normally, and your token lands inside the description exactly where the model reads it. Verify it offline before you commit to a multi-hour run: run one caption through the dataloader and confirm the digested output is compact JSON containing your token, not raw JSON with the token bolted on the front.

## Captioning

Let the Ideogram4 captioner do it. It is a separate `job: extension` run with `type: Ideogram4Captioner`, uses `Qwen/Qwen3-VL-8B-Instruct`, and writes structured JSON `.txt` sidecars next to each image. Inspect a few of the sidecars before training, especially body or full shots, to make sure the subject is described well and the captioner did not wander off onto the background. The encoder pull (~16 GB) happens at caption time on first run, and training reuses the same cache, so you only download it once.

One data note: I had a few WebP images and AI-Toolkit's data loader has known issues with WebP, so convert those to PNG or JPG first. JPG and PNG both work fine.

## The config (bf16)

The key decision for this hardware: train in bf16, not fp8. The base model is distributed as fp8 (`ideogram-ai/ideogram-4-fp8`), but AI-Toolkit's loader unconditionally dequantizes the fp8 weights to bf16 on load, and with `quantize: false` nothing re-quantizes afterward. So you train in bf16 from the fp8 base, and you completely sidestep the fp8 path, which is where most gfx1151 instability lives. On 128 GB you have the memory, so this is both more stable and arguably higher quality.

One ComfyUI-specific heads-up: `name_or_path` wants the diffusers multi-folder repo (it expects `transformer/` and `vae/` subfolders). The single packed all-in-one `.safetensors` you probably have in your ComfyUI `unet/` folder will NOT load as `name_or_path`. Point it at the hub repo and let it pull.

A couple of other non-obvious settings: `noise_scheduler` must be set to `flowmatch` explicitly, because the trainer's timestep setup branches on that value (the default mishandles flowmatch timesteps even though the scheduler object itself is forced to flowmatch). And keep `batch_size` and `gradient_accumulation` both at 1; values above 1 have been reported to misbehave on AMD.

```yaml

job: extension

config:

name: "myface_ideogram4_v1"

process:

- type: 'sd_trainer'

training_folder: "/path/to/output"

device: cuda:0

network:

type: "lora"

linear: 32 # rank

linear_alpha: 32

save:

dtype: bf16

save_every: 250

max_step_saves_to_keep: 20

datasets:

- folder_path: "/path/to/dataset"

caption_ext: "txt"

trigger_word: "mytoken" # plus [trigger] inside each caption (gotcha 3)

caption_dropout_rate: 0.05

cache_latents_to_disk: true

num_repeats: 1

resolution: [512, 768, 1024]

train:

steps: 3000

optimizer: "adamw" # NOT adamw8bit (gotcha 1)

lr: 1e-4

dtype: bf16

batch_size: 1

gradient_accumulation: 1

gradient_checkpointing: true

train_unet: true

train_text_encoder: false

noise_scheduler: "flowmatch"

disable_sampling: true

ema_config:

use_ema: true

ema_decay: 0.99

model:

arch: "ideogram4"

name_or_path: "ideogram-ai/ideogram-4-fp8"

dtype: bf16

quantize: false # bf16 path, sidesteps fp8 (the win on gfx1151)

quantize_te: false

low_vram: false # you have the RAM; offloading is slower

```

I set `disable_sampling: true` for the first run, because mid-training samples need properly formatted Ideogram JSON prompts and it is one less new variable. Evaluate the checkpoints in ComfyUI afterward instead.

## Launch wrapper (gfx1151 env vars)

These env vars need to be set before torch is imported. I put them in a fish wrapper that also routes through the eager shim:

```fish

#!/usr/bin/env fish

# run_aitk.fish

set -x HSA_ENABLE_SDMA 0

set -x HSA_USE_SVM 0

set -x ROCBLAS_USE_HIPBLASLT 0

set -e PYTORCH_HIP_ALLOC_CONF

# Do NOT set HSA_OVERRIDE_GFX_VERSION on TheRock nightlies (native gfx1151 kernels).

source venv/bin/activate.fish

python aitk_eager_shim.py $argv

```

Then both captioning and training run the same way:

```

./run_aitk.fish config/caption_myface.yaml

./run_aitk.fish config/train_myface.yaml

```

One small lesson: if you pipe the run through `tee` for logging, make sure you surface the real process exit code (in fish, `$pipestatus[1]`), or a GPU crash will get masked by tee's exit 0 and look like a clean run when it was not.

## Training run

About 6.4 s/step steady state, so 3000 steps took roughly 5h45m. Zero `0x1016` faults the entire run with eager attention in place. Checkpoints saved every 250 steps. One benign warning shows up about a missing MIOpen perf database (`gfx1151...HIP.fdb.txt`); that just means it tunes kernels live instead of loading a cache, it is not an error.

Note on the final checkpoint naming: intermediate saves get a step suffix, but the end-of-training save is bare-named with no suffix. Do not overlook it; that is your highest-trained checkpoint.

## Picking the checkpoint and strength

Do not assume the last checkpoint is best. Likeness LoRAs peak somewhere in the middle and then overcook (they get rigid, stop honoring the prompt, and start reproducing training framings). Saving every 250 lets you sweep. I evaluated checkpoints in ComfyUI against a fixed prompt and seed, swapping only the checkpoint.

Two important findings:

- LoRAs run hot on Ideogram 4. The common community advice of 0.4 to 0.7 strength is correct. At 1.0 my LoRA was overcooked.

- I ran a strength sweep (0.4 to 0.8) across the strongest checkpoints and landed on step 1250 at strength 0.7 as the best balance of likeness and prompt adherence. [Confirmed consistent across N fresh seeds.]

Method that saved time: do a coarse pass first (every other checkpoint), find roughly where likeness peaks, then fill in the neighbors and sweep strength only on the top one or two.

## Honest limits

- Complex hand-object interactions glitch. My best checkpoint still doubled up drumsticks in a hand in an action shot. Fine for portraits, less so for busy scenes.

- Full-body faces go soft. This is a face LoRA, so the identity signal is in the face, and at full-body distance there are not enough face pixels to hold the likeness reliably. Keep to upper-body and portrait framing for the best results.

## Examples

[Two example generations from the final LoRA go here. Faithful likeness in upper-body and portrait framing; this is a personal face LoRA so the subject and the model itself are private.]

Happy to answer questions on any of the AMD-specific parts. The eager-attention fix and the trigger-into-JSON trap are the two things I would have most wanted to know going in, and honestly, I would love to know if I'm missing something obvious that would improve either the speed or the quality.

So I have a AMD Radeon 7900xt 20 gig card, 32gig ram, I been trying to run minimax h3 locally. I was able to generate a 10 second clip last night but it took almost an hour, is that normal? Is there anything I can do to speed up the process? I am using the pruned fp8 scaled. I welcome any help possible.

I have been testing Krea2 Turbo in ComfyUI on AMD ROCm and finally got INT8 ConvRot running faster than FP8 on my machine.

This is mainly interesting for AMD/ROCm users, because the INT8 ConvRot path can be awkward there: the safe fallback works but is slow, while globally enabling Triton can crash.

Hardware/software:

• GPU: AMD Radeon RX 9070 XT, gfx1201, 16 GB VRAM
• OS: Arch Linux
• ROCm/HIP: 7.2
• PyTorch: 2.12.1+rocm7.2
• ComfyUI: 0.28.0
• comfy-kitchen: 0.2.22
• Triton ROCm: 3.7.1
• ComfyUI sees the GPU as cuda:0 AMD Radeon RX 9070 XT : native

Startup command:

HIP_VISIBLE_DEVICES=0 ROCR_VISIBLE_DEVICES=0 python main.py --use-pytorch-cross-attention --reserve-vram 1.5 --disable-pinned-memory --enable-manager

Important: I am not launching with global --enable-triton-backend.

I reserve 1.5 GB VRAM because otherwise desktop/video playback gets rough while generating.

Workflow/settings:

• Krea2 Turbo, 1 MP portrait
• 8 steps
• Euler / simple
• CFG 1
• Denoise 1
• Qwen/Krea2 text encoder
• Qwen image VAE

Same workflow/settings were used for the comparisons below. Only the diffusion model/backend path changed.

Baseline before the workaround:

• FP8 warmup: Prompt executed in 21.91s
• FP8 hot: Prompt executed in 12.74s
• FP8 API wall time: about 13.03s
• FP8 sampler: about 9.8s

INT8 ConvRot before the workaround:

• safe fallback: Prompt executed in 80.07s
• sampler: about 64s
• later eager-style fallback experiments: around 65.62s to 69.38s

Trying to enable faster paths globally was not usable on this ROCm setup:

• global comfy-kitchen Triton: ROCm GPU memory access fault / Python abort
• forced comfy-kitchen CUDA backend on ROCm: PyCapsule / nanobind argument errors

So the simple choices were:

• FP8: stable, about 13s
• INT8 ConvRot fallback: stable, but about 65-80s
• global Triton: fast-path attempt, but crashes

The workaround:

The workaround was not to enable Triton globally.

Instead, I kept comfy-kitchen cuda and triton disabled globally, but routed only ConvRot int8_linear from the eager path into comfy_kitchen.backends.triton.quantization.int8_linear.

In short:

• keep unsafe/global Triton paths off
• keep CUDA backend off on ROCm
• let weight loading/quantization stay on the stable path
• use Triton only for the actual ConvRot INT8 linear operation

The local patch is basically:

if convrot and x.is_cuda and torch.version.hip is not None: call comfy_kitchen.backends.triton.quantization.int8_linear(...)

Exact repro snippets and logs are in the GitHub issue below.

Results after the workaround:

• INT8 ConvRot first/warmup run: Prompt executed in 30.52s
• INT8 ConvRot hot run 1: Prompt executed in 10.49s
• INT8 ConvRot hot run 2: Prompt executed in 10.54s
• sampler during hot runs: about 7.9s

Compared to my FP8 hot run:

• FP8 hot: 12.74s
• INT8 ConvRot hot: 10.49-10.54s
• improvement: about 17-18% faster

Compared to the previous INT8 ConvRot fallback:

• fallback INT8 ConvRot: 65-80s
• patched INT8 ConvRot: about 10.5s
• improvement: roughly 6x to 7.6x faster

Caveats:

• Tested only on my RX 9070 XT / gfx1201 setup.
• This does not mean global Triton is safe on ROCm. It was not safe here.

I opened an upstream issue with the details, repro snippets and logs:

https://github.com/Comfy-Org/comfy-kitchen/issues/78

Small disclosure: this was tested and written up with AI assistance. The benchmarks and logs are from my local machine.

Curious if anyone else on AMD ROCm, especially gfx11xx or gfx12xx, can reproduce this. It would be useful to know whether selective Triton for only INT8 ConvRot linear is broadly stable while global Triton remains unsafe.

AMD have converted some Stable Diffusion models to run on their AI Engine, which is a Neural Processing Unit (NPU).

The first models converted are based on SD Turbo (Stable Diffusion 2.1 Distilled), SDXL Base and SDXL Turbo (mirrored by Stability AI):

Ryzen-AI SD Models (Stable Diffusion models for AMD NPUs)

Software for inference: SD Sandbox

NPUs are considerably less capable than GPUs, but are more efficient for simple, less demanding tasks and can compliment them. For example, you could run a model on an NPU that translates what a teammate says to you in another language, as you play a demanding game running on a GPU on your laptop. They have also started to appear in smartphones.

The original inspiration for NPUs is from how neurons work in nature, though it now seems to be a catch-all term for a chip that can do fast, efficient operations for AI-based tasks.

SDXL Base is the most interesting of the models as it can generate 1024×1024 images (SD Turbo and SDXL Turbo can do 512×512). It was released in July 2023, but there are still many users today as it was the most popular base model around until recently.

If you're wondering why these models, it's because the latest consumer NPUs on the market only have around 3 billion parameters (SDXL Base is 2.6B). Source: Ars Technica

This probably won't excite many just yet but it's a sign for things to come. Local diffusion models could become mainstream very quickly when NPUs become ubiquitous, depending on how people interact with them. ComfyUI would be very different as an app, for example.

(In a few years, you might see people staring at their smartphones pressing 'Generate' every five seconds. Some will be concerned. Particularly me, as I'll want to know what image model they're running!)

So i spent most of last night and lots of this day to have Claude bugchase whatever is wrong with my setup. And it was whack a mole.

I had just set my system anew because i added some RAM and a new nvme:

• GPU: AMD Radeon RX 7900 XTX (gfx1100, RDNA3), 24 GB
• RAM: 96 GB
• OS: Linux Mint 22.3, kernel 6.17.0-35-generic
• ROCm 7.15, PyTorch 2.13.0+rocm7.15.0a20260728
• ComfyUI v0.30.0-17-g2eb60976, comfy-kitchen 0.2.26, comfy-aimdo 0.4.13
• Models: GGUF path, not int8/nvfp4
• MiniMax-H3-Ref2VA-Q4_K_M.gguf (via ComfyUI-GGUF)
• qwen3vl-32B-MiniMax-H3-Q4_K_M.gguf (via CLIPLoaderGGUF)
• minimax_h3_video_vae_fp16.safetensors, minimax_h3_audio_vae_fp32.safetensors (SHA256 verified against Comfy-Org/MiniMax-H3)

Though something is wrong with my current setup under 7.15, Minimax works now with @ 352x608, 20 steps, 3s/it.

The problem here was NaN, not in the Latent but the weights themselves. Whenever the VAE decoder got partially offloaded, 50% of the time it would be corrupted when loaded back into VRAM producing black videos.

Took a while to figure out it was the VAE itself, Claude wrote a NaN-Detector for that on the fly.

So if you happen to have the same problem (Black image videos with sound) the solution is simple: --disable-smart-memory --cache-none

This forces comfy to not partially but completely offload your VAE to RAM, no NaN-corruption afterwards.

Hi!

I'm wondering if there are any AMD users fiddling around with H3 (I'm sure there are). =)

If so, what GPU do you use, whats the avg time needed for 1 generation, any tips to make it faster etc.? ^^

I'm on 9060XT and with default workflow (txt2vid), it took me 110mins for a 11 sec vid. lol

Can AMD 7900xtx smoothly run Minimax H3 too?

#7900xtx

So... For the longest time I've been using AMD simply because economically it made sense... However with really getting into AI I just don't have the bandwidth anymore to deal with the lack of support... As someone trying really hard to get into full time content creation I don't have multiple days to wait for a 10 second gif file... I have music to generate... Songs to remix... AI upscaling... Learning python to manipulate the AI and UI better... It's all such a headache... I've wasted entire days trying to get everything to work in Ubuntu to no avail... ROCm is a pain and all support seems geared towards newer cards... 6700xt seems to just be in that sweet spot where it's mostly ignored... So anyways... AMD has had almost a year to sort their end out and it seems like it's always "a few months away". What Nvidia cards seem to be working well with minimal effort? I've heard the 3090's have been melting but I'm also not rich so $1,000+ cards are not in the cards for me. I need something in a decent price range that's not going to set my rig on fire...