haylanandClaude-Bot
ac3f730f83
Closes issue #39 — with llama-server stopped and the full ~32GB R9700 available, Qwen-Image (Apache-2.0, 20B MMDiT) at FP8 precision (~25GB) is the recommended upgrade from FLUX.1-schnell: it has the cleanest license of the candidates and is the only one with a ComfyUI workflow pre-validated specifically on this GPU architecture (gfx1201/R9700), per kyuz0/amd-r9700-comfy. HunyuanImage-3.0 is ruled out (CUDA-only, multi-GPU datacenter VRAM floor); Krea-2 flagged as promising but too new for R9700-specific field evidence. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015zCwaWJQuKgXDUfRPBqDS7
221 lines
16 KiB
Markdown
221 lines
16 KiB
Markdown
# Research: which diffusion model to target with the full ~32GB R9700
|
||
|
||
**Question:** With Qwen/llama-server fully stopped (per issue #39's premise — see
|
||
map #38), ComfyUI has the whole ~32GB R9700 (ROCm/gfx1201) to itself instead
|
||
of the ~6GB left over during concurrent operation
|
||
(per [`image-generation-options.md`](image-generation-options.md)). Given that
|
||
headroom, should the build stay on FLUX.1-schnell, or move up to
|
||
FLUX.1-dev, SD3.5-large, Qwen-Image, HunyuanImage-3.0, or Krea-2?
|
||
|
||
**Answer, short version:** move up to **Qwen-Image at FP8 precision**
|
||
(`qwen_image_fp8_e4m3fn.safetensors` diffusion weights +
|
||
`qwen_2.5_vl_7b_fp8_scaled.safetensors` text encoder, ~25GB combined). It's
|
||
the only one of the five upgrade candidates with **direct, hardware-specific
|
||
evidence of running on this exact GPU architecture** (gfx1201/R9700) rather
|
||
than a generic "ComfyUI supports ROCm" inference, it carries the cleanest
|
||
license of the group (Apache-2.0, no revenue threshold, no non-commercial
|
||
clause), and its 20B MMDiT is a real capability step up from schnell's
|
||
distilled 12B (notably for text rendering and prompt adherence), while still
|
||
fitting with real margin inside 32GB.
|
||
|
||
## Why not just re-derive the schnell/dev/SDXL/SD3.5 findings
|
||
|
||
`docs/research/image-generation-options.md` already covers, with primary
|
||
sources: ComfyUI's ROCm/gfx1201 story (official AMD docs + RDNA4 blog post +
|
||
community gfx1201 Docker images), FLUX.1-schnell vs FLUX.1-dev vs SDXL vs
|
||
SD3.5 licenses, and FLUX GGUF VRAM figures at the ~6GB-headroom scale. None
|
||
of that is repeated here except where the ~32GB ceiling changes the
|
||
conclusion. This doc adds: FLUX.1-dev/SD3.5 at the *larger* headroom, plus
|
||
three models the prior doc didn't cover at all (Qwen-Image, HunyuanImage-3.0,
|
||
Krea-2).
|
||
|
||
## Candidate comparison
|
||
|
||
| Model | License (primary source) | Params | Stated/typical VRAM | ROCm/gfx1201 evidence |
|
||
|---|---|---|---|---|
|
||
| FLUX.1-schnell (current) | Apache-2.0 | 12B | GGUF Q4_K_S ~7GB (per prior doc) | Confirmed on gfx1201 (prior doc) |
|
||
| **Qwen-Image** | **Apache-2.0** | 20B (20.4B DiT + 8.3B Qwen2.5-VL text encoder) | fp8 ~16GB (diffusion) + ~9.4GB (fp8 text encoder) ≈ 25GB total; bf16 needs 24GB+ and "48GB+" per some quant write-ups | **Direct**: [kyuz0/amd-r9700-comfy](https://github.com/kyuz0/amd-r9700-comfy) ships a pre-validated "Qwen Image 2512 (FP8) & Lightning LoRA (4 steps)" ComfyUI workflow specifically for the R9700 AI Pro (gfx1201), on a ROCm 7 (TheRock nightlies) toolbox |
|
||
| FLUX.1-dev | [FLUX.1-dev Non-Commercial License](https://huggingface.co/black-forest-labs/FLUX.1-dev/blob/main/LICENSE.md) — non-commercial weights, outputs usable commercially | 12B | bf16 ~24GB; GGUF Q8 ~12-13GB | Same *family* evidence as schnell (gfx1201 Docker images target FLUX generally), but no R9700-specific FLUX.1-dev report found |
|
||
| SD3.5-large | [Stability Community License](https://huggingface.co/stabilityai/stable-diffusion-3.5-large/blob/main/LICENSE.md) — free under $1M annual revenue | 8B | bf16 ~16GB; 4-bit NF4 fits small GPUs | AMD's own ComfyUI-ROCm doc lists an "SD3.5 Simple" template workflow (per prior doc) — vendor-blessed but not R9700-specific |
|
||
| HunyuanImage-3.0 | [tencent-hunyuan-community license](https://github.com/Tencent-Hunyuan/HunyuanImage-3.0) | 80B total / 13B active (MoE, 64 experts) | Official repo: "≥ 3 × 80GB" VRAM for the base model, "≥ 8 × 80GB" for -Instruct; ~177GB at fp16 | **None, and actively contraindicated**: setup requires CUDA 12.8 + FlashAttention2/FlashInfer, no AMD/ROCm mention anywhere in the official repo |
|
||
| Krea-2 (Turbo) | [Krea 2 Community License](https://www.krea.ai/krea-2-licensing) — free under $1M annual revenue, homelab/personal explicitly covered | 12-13B DiT | No official VRAM figure; community reports (RTX hardware only) cite fp8 ~16GB, GGUF ~12GB | **None found** — released [June 22, 2026 per the HF model card](https://huggingface.co/krea/Krea-2-Turbo); ComfyUI added native support per [blog.comfy.org](https://blog.comfy.org/p/krea-2-open-source-models-are-now), and GGUF quants exist ([molbal/krea2-gguf](https://huggingface.co/molbal/krea2-gguf)), but no R9700/gfx1201-specific report exists yet — too new for that evidence to have accumulated |
|
||
|
||
## Per-model detail
|
||
|
||
### Qwen-Image — recommended
|
||
|
||
- **License**: Apache-2.0, stated directly on the model card, no revenue
|
||
threshold, no non-commercial clause, no attribution/naming requirement.
|
||
The cleanest license of every model considered in this doc or the prior
|
||
one. Source: [Qwen/Qwen-Image on Hugging Face](https://huggingface.co/Qwen/Qwen-Image).
|
||
- **Architecture**: 20B-parameter MMDiT (Multimodal Diffusion Transformer)
|
||
combined with an 8.3B Qwen2.5-VL text encoder — notably larger and more
|
||
capable than FLUX.1-schnell's 12B distilled model, particularly for
|
||
multilingual text rendering and instruction-following, per the official
|
||
[QwenLM/Qwen-Image GitHub repo](https://github.com/QwenLM/Qwen-Image).
|
||
- **ComfyUI support**: native, not a wrapper/custom-node integration —
|
||
landed August 2025 per [ComfyUI Wiki's native-support announcement](https://comfyui-wiki.com/en/news/2025-08-05-qwen-image),
|
||
with an official FP8 checkpoint (`qwen_image_fp8_e4m3fn.safetensors`) and
|
||
FP8-scaled text encoder (`qwen_2.5_vl_7b_fp8_scaled.safetensors`, 9.38GB)
|
||
published under [Comfy-Org/Qwen-Image_ComfyUI](https://huggingface.co/Comfy-Org/Qwen-Image_ComfyUI/tree/main/split_files/text_encoders).
|
||
- **VRAM at FP8**: the official Comfy-Org FP8 diffusion checkpoint plus FP8
|
||
text encoder land around ~25GB combined — comfortably inside the 32GB
|
||
ceiling with headroom for ComfyUI runtime/VAE overhead, versus 24GB+ (some
|
||
sources say 48GB+) for the unquantized bf16 model. Sources: community
|
||
VRAM write-ups aggregated via [Comfy-Org/ComfyUI issue #10852 ("Qwen-image in 24GB VRAM and 32GB RAM")](https://github.com/Comfy-Org/ComfyUI/issues/10852)
|
||
and the [official ComfyUI Qwen-Image example](https://comfyanonymous.github.io/ComfyUI_examples/qwen_image/) —
|
||
treat exact GB figures as secondary/community-sourced, consistent with how
|
||
the prior doc flagged FLUX's GGUF VRAM table.
|
||
- **Direct R9700/gfx1201 evidence (the deciding factor)**:
|
||
[kyuz0/amd-r9700-comfy](https://github.com/kyuz0/amd-r9700-comfy) is a
|
||
Fedora-toolbox ROCm 7 (TheRock nightlies) environment built specifically
|
||
for the "AMD Radeon 9700 AI PRO (32GB)" and ships a pre-validated
|
||
"Qwen Image 2512 (FP8) & Lightning LoRA (4 steps)" ComfyUI workflow
|
||
(plus a Qwen-Image-Edit 2511 FP8 workflow) as one of only four workflows
|
||
in the whole repo. This is the only model in this comparison with
|
||
card-architecture-specific (not just "ComfyUI supports ROCm generically")
|
||
validation — everything else relies on family-level or vendor-generic
|
||
ROCm claims. A related community discussion
|
||
([pollockjj/ComfyUI-MultiGPU #133](https://github.com/pollockjj/ComfyUI-MultiGPU/discussions/133))
|
||
does flag that "Qwen image edit doesn't always work on AMD HIP/ROCm" in
|
||
some configurations — worth testing the specific workflow before assuming
|
||
zero friction, but this is a known-quantity, actively-discussed rough edge
|
||
rather than a documented hard blocker.
|
||
- **4-step Lightning LoRA**: the R9700-validated workflow pairs Qwen-Image
|
||
with a "Lightning" LoRA for 4-step inference — the same fast-inference
|
||
pattern FLUX.1-schnell uses, so switching models doesn't have to mean
|
||
giving up the short GPU-resident-time-per-image property the prior doc
|
||
called out as valuable for time-sliced use alongside llama-server (even
|
||
though this ticket's premise is llama-server being stopped, that pattern
|
||
still helps if the two services are ever run in an overlapping window).
|
||
|
||
### FLUX.1-dev — solid alternative, not the pick
|
||
|
||
- License permits non-commercial use of the weights; BFL's own license page
|
||
states generated outputs are separately usable commercially (already
|
||
covered in the prior doc; unchanged here). Source:
|
||
[FLUX.1-dev LICENSE.md](https://huggingface.co/black-forest-labs/FLUX.1-dev/blob/main/LICENSE.md).
|
||
- At bf16 (~24GB) or GGUF Q8 (~12-13GB), it fits the 32GB ceiling with room
|
||
to spare — a legitimate move up from schnell's distilled quality.
|
||
Source: [city96/FLUX.1-dev-gguf](https://huggingface.co/city96/FLUX.1-dev-gguf)
|
||
and community Q8 VRAM reports.
|
||
- Loses to Qwen-Image on two counts: license (non-commercial-weights clause
|
||
vs. Apache-2.0 — not a hard blocker for this homelab per the prior doc's
|
||
own reasoning, but strictly worse) and hardware evidence (FLUX's gfx1201
|
||
validation is at the *family* level — the prior doc's `yurisasc/comfyui-rocm-rdna4`
|
||
and `charlie12345/R9700AIProComfyUIPatch` sources are about running FLUX
|
||
models on this card generally, not a FLUX.1-dev-specific report the way
|
||
kyuz0's repo is Qwen-Image-specific).
|
||
|
||
### SD3.5-large — no longer the best use of the freed headroom
|
||
|
||
- License unchanged from the prior doc: Stability Community License, free
|
||
under $1M annual revenue (irrelevant threshold for this homelab). Source:
|
||
[stabilityai/stable-diffusion-3.5-large LICENSE.md](https://huggingface.co/stabilityai/stable-diffusion-3.5-large/blob/main/LICENSE.md).
|
||
- At 8B params (bf16 ~16GB), it's the smallest of the upgrade candidates —
|
||
which mattered when 6GB was the ceiling, but with 32GB available there's
|
||
no VRAM reason to pick the model the prior doc already flagged as "lower
|
||
fidelity than FLUX/SD3.5 by current standards" over Qwen-Image or
|
||
FLUX.1-dev. AMD's own ComfyUI-ROCm docs do list it as a first-party
|
||
example template ("SD3.5 Simple", per the prior doc), so it remains a fine
|
||
fallback if Qwen-Image's FP8 path hits the ROCm rough edge noted above.
|
||
|
||
### HunyuanImage-3.0 — ruled out
|
||
|
||
- Official repo states VRAM requirements of "≥ 3 × 80GB" for the base model
|
||
and "≥ 8 × 80GB" for HunyuanImage-3.0-Instruct — i.e. multi-GPU
|
||
datacenter-class NVIDIA clusters, not a single 32GB consumer/workstation
|
||
card at any precision. Source:
|
||
[Tencent-Hunyuan/HunyuanImage-3.0 GitHub repo](https://github.com/Tencent-Hunyuan/HunyuanImage-3.0).
|
||
- Setup instructions require CUDA 12.8, PyTorch 2.8.0 built for CUDA, and
|
||
optionally FlashAttention2/FlashInfer for MoE routing speed — no AMD or
|
||
ROCm path is mentioned anywhere in the official repo. Even the
|
||
MoE-efficient "13B active" framing doesn't help here: the tooling itself
|
||
assumes an NVIDIA multi-GPU cluster, and the 80B total parameter set still
|
||
has to be resident somewhere.
|
||
- 32GB of headroom on one AMD card doesn't move this model into reach at
|
||
any precision considered here; it's excluded regardless of how much VRAM
|
||
frees up on this specific box.
|
||
|
||
### Krea-2 (Turbo) — promising, but unverified on this hardware
|
||
|
||
- Verified directly against primary sources per the ticket's instruction
|
||
(this is a June 2026 release, past most training cutoffs): the
|
||
[Hugging Face model card](https://huggingface.co/krea/Krea-2-Turbo) states
|
||
a release date of **June 22, 2026**, a 12-billion-parameter single-stream
|
||
diffusion transformer, `torch.bfloat16` as the reference precision, and
|
||
the **Krea 2 Community License**.
|
||
- License, per [krea.ai/krea-2-licensing](https://www.krea.ai/krea-2-licensing):
|
||
non-commercial (including explicitly personal/homelab) use is free;
|
||
commercial use is permitted royalty-free for entities under $1M
|
||
trailing-12-month revenue (same shape as SD3.5's and matching this
|
||
homelab's use case); content-filter and AI-disclosure obligations apply if
|
||
deployed publicly; derivative model names must start with "Krea".
|
||
- ComfyUI added native support for both open-weight checkpoints (Krea 2 Raw
|
||
and Krea 2 Turbo) per [blog.comfy.org's announcement](https://blog.comfy.org/p/krea-2-open-source-models-are-now),
|
||
and community GGUF quants already exist
|
||
([molbal/krea2-gguf](https://huggingface.co/molbal/krea2-gguf)), with
|
||
reports (RTX hardware only) of fp8 fitting 16GB and GGUF fitting 12GB.
|
||
- **No AMD/ROCm mention anywhere** in the model card, and no gfx1201/R9700
|
||
community report was found — unsurprising given the model is roughly
|
||
2.5 months old at the time of this research. Its architecture (a
|
||
standard-shaped DiT that ComfyUI loads through its normal diffusion-model
|
||
nodes, per the ComfyUI blog post) gives reasonable expectation it will run
|
||
on the same ROCm/PyTorch backend already proven for FLUX and Qwen-Image on
|
||
this card, but that's an inference, not a verified fact the way
|
||
kyuz0's Qwen-Image workflow is.
|
||
- **Not the pick today**, precisely because Qwen-Image already offers a
|
||
hardware-verified path at a comparable parameter count and VRAM budget.
|
||
Worth a follow-up research ticket once R9700/gfx1201-specific Krea-2
|
||
reports exist — the license and ComfyUI support are both already in
|
||
place, so the only open question is real-world ROCm behavior.
|
||
|
||
## Recommendation
|
||
|
||
**Qwen-Image, FP8 precision** (`qwen_image_fp8_e4m3fn.safetensors` +
|
||
`qwen_2.5_vl_7b_fp8_scaled.safetensors`, ~25GB combined), optionally paired
|
||
with the 4-step Lightning LoRA the R9700-specific validated workflow uses.
|
||
It wins on all three axes the ticket asked about:
|
||
|
||
1. **License**: Apache-2.0 — no restriction at all, strictly better than
|
||
every other candidate including the current FLUX.1-schnell pick.
|
||
2. **ROCm/gfx1201 compatibility**: the only candidate with a workflow
|
||
pre-validated specifically on this GPU architecture
|
||
([kyuz0/amd-r9700-comfy](https://github.com/kyuz0/amd-r9700-comfy)),
|
||
not just "ComfyUI supports ROCm in general."
|
||
3. **VRAM at the ~32GB ceiling**: ~25GB at FP8 leaves real margin for
|
||
ComfyUI runtime/VAE overhead, without needing the multi-step,
|
||
non-distilled FLUX.1-dev's full 24GB bf16 footprint or accepting
|
||
SD3.5's lower fidelity ceiling — and it's a genuine capability upgrade
|
||
over schnell (20B vs. 12B, non-distilled-quality text rendering) rather
|
||
than just a bigger file.
|
||
|
||
If the known Qwen-Image/ROCm edit-mode rough edge
|
||
([pollockjj/ComfyUI-MultiGPU #133](https://github.com/pollockjj/ComfyUI-MultiGPU/discussions/133))
|
||
turns out to affect plain text-to-image generation too, SD3.5-large (AMD's
|
||
own first-party "SD3.5 Simple" ComfyUI-ROCm template workflow) is the
|
||
fallback, with FLUX.1-dev as a second option. HunyuanImage-3.0 is excluded
|
||
outright regardless of available VRAM (CUDA-only tooling, multi-GPU
|
||
datacenter VRAM floor). Krea-2 is worth revisiting once R9700-specific
|
||
field reports exist.
|
||
|
||
## Sources consulted
|
||
|
||
- [docs/research/image-generation-options.md](image-generation-options.md) (this repo — prior findings, not re-derived)
|
||
- [Qwen/Qwen-Image (Hugging Face)](https://huggingface.co/Qwen/Qwen-Image)
|
||
- [QwenLM/Qwen-Image (GitHub)](https://github.com/QwenLM/Qwen-Image)
|
||
- [ComfyUI Wiki — Qwen-Image native support announcement](https://comfyui-wiki.com/en/news/2025-08-05-qwen-image)
|
||
- [Comfy-Org/Qwen-Image_ComfyUI (Hugging Face, FP8 checkpoints)](https://huggingface.co/Comfy-Org/Qwen-Image_ComfyUI/tree/main/split_files/text_encoders)
|
||
- [Comfy-Org/ComfyUI issue #10852 — Qwen-Image VRAM](https://github.com/Comfy-Org/ComfyUI/issues/10852)
|
||
- [ComfyUI official Qwen-Image example](https://comfyanonymous.github.io/ComfyUI_examples/qwen_image/)
|
||
- [kyuz0/amd-r9700-comfy (R9700-specific ROCm ComfyUI toolbox)](https://github.com/kyuz0/amd-r9700-comfy)
|
||
- [pollockjj/ComfyUI-MultiGPU discussion #133 (Qwen-Image-Edit ROCm rough edge)](https://github.com/pollockjj/ComfyUI-MultiGPU/discussions/133)
|
||
- [black-forest-labs/FLUX.1-dev (Hugging Face) + LICENSE.md](https://huggingface.co/black-forest-labs/FLUX.1-dev)
|
||
- [city96/FLUX.1-dev-gguf](https://huggingface.co/city96/FLUX.1-dev-gguf)
|
||
- [stabilityai/stable-diffusion-3.5-large (Hugging Face) + LICENSE.md](https://huggingface.co/stabilityai/stable-diffusion-3.5-large)
|
||
- [Tencent-Hunyuan/HunyuanImage-3.0 (GitHub)](https://github.com/Tencent-Hunyuan/HunyuanImage-3.0)
|
||
- [krea/Krea-2-Turbo (Hugging Face)](https://huggingface.co/krea/Krea-2-Turbo)
|
||
- [Krea 2 Community License Agreement (krea.ai)](https://www.krea.ai/krea-2-licensing)
|
||
- [blog.comfy.org — Krea 2 open-source models in ComfyUI](https://blog.comfy.org/p/krea-2-open-source-models-are-now)
|
||
- [molbal/krea2-gguf (Hugging Face)](https://huggingface.co/molbal/krea2-gguf)
|