Generación local de imágenes con IA en una mini PC AMD: ComfyUI + Z-Image Turbo

Mi mini PC convierte un prompt de texto en una imagen terminada de 1024×1024 en unos 27 segundos: sin cuenta en la nube, sin cobro por imagen, sin cola detrás de los prompts de otras mil personas. Y lo hace un chip AMD que la mayoría asume que no puede hacer esto en absoluto.

Lo que obtienes

La charla sobre la configuración puede esperar. En el día a día, abro una pestaña del navegador o lo lanzo desde una terminal. De cualquier forma:

Métrica	Valor
Resolución	1024×1024
Pasos / CFG	8 pasos, CFG 1.0
Tiempo de generación en caliente	~27s (rango medido: 26.5–30.4s)
Arranque en frío (primera imagen tras iniciar)	~43.5s mientras cargan ~20GB de pesos

El uso real de este equipo no es arte por el arte mismo. Es un script que genera por lotes variaciones de avatares para un proyecto de chatbot: 222 PNG en la carpeta de salida y contando. Infraestructura aburrida y confiable, que es exactamente lo que quieres de algo que construiste por diversión y que después empezaste a necesitar.

El hardware

Este es un equipo de memoria unificada de 128GB: un AMD Ryzen AI Max+ 395 ("Strix Halo") con una iGPU Radeon 8060S en el mismo paquete que la CPU. No hay ninguna GPU discreta.

Aquí está la parte que importa. El firmware reserva 64 GiB de esos 128GB y se los entrega a la iGPU como "VRAM" dedicada — el propio log de arranque de ComfyUI dice Total VRAM 65536 MB, total RAM 63920 MB. Eso es más VRAM que la que vende cualquier tarjeta NVIDIA de consumo, porque no es GDDR cara soldada a una tarjeta gráfica. Es simplemente memoria del sistema que el firmware le asignó a la GPU, con otros ~31GB de GTT accesible por la GPU detrás, por si hace falta.

Componente	Especificación
CPU	AMD Ryzen AI Max+ 395, 16 núcleos / 32 hilos
iGPU	Radeon 8060S, arquitectura ROCm gfx1151
Memoria	128GB LPDDR5X unificados — 64GiB reservados como VRAM, ~62GiB para Linux
Sistema operativo	Bazzite (inmutable, basado en Fedora Silverblue)
GPU discreta	Ninguna

Los pesos del modelo para toda esta configuración suman unos 20.7GB. Cómodo dentro de 64GB; imposible en una tarjeta típica de consumo de 8–16GB, a menos que descargues capas a la RAM del sistema y aceptes la penalización de velocidad.

Pila de software

Las versiones que hacen que esto funcione, tal como está instalado ahora mismo:

Componente	Versión
ComfyUI	v0.27.0 (checkout de git)
Python	3.12.13, en un venv construido con uv
PyTorch	2.12.1+rocm7.2
torchvision	0.27.1+rocm7.2
torchaudio	2.11.0+rocm7.2
pytorch-triton-rocm	3.5.1
ROCm	7.2, soporte nativo de gfx1151

El detalle divertido: la versión de PyTorch para ROCm se disfraza de CUDA. El log de arranque literalmente dice Device: cuda:0 AMD Radeon 8060S : native. El código Python escrito para una tarjeta NVIDIA simplemente corre, porque cree que está hablando con una. ComfyUI también desactiva automáticamente cuDNN en este hardware y recurre a la atención plana de PyTorch (sin xformers, sin flash-attn), y funciona bien sin ellos.

Domando a ROCm

El dolor de la configuración se concentra en un puñado de variables de entorno en el script de arranque:

HSA_OVERRIDE_GFX_VERSION=11.5.1
PYTORCH_HIP_ALLOC_CONF=expandable_segments:True
HIP_VISIBLE_DEVICES=0

• HSA_OVERRIDE_GFX_VERSION le dice a ROCm que la GPU es gfx1151. En ROCm 7.2 es redundante (el log ya dice "native") pero la mantengo como salvaguarda, porque en builds más antiguos de ROCm este mismo override era obligatorio para que iGPU como esta funcionara siquiera.
• PYTORCH_HIP_ALLOC_CONF=expandable_segments:True evita que el asignador fragmente la VRAM en memoria unificada. Sin esto puedes toparte con errores de memoria agotada aunque técnicamente sobre memoria libre de sobra.
• HIP_VISIBLE_DEVICES=0 fija a la única GPU. No es emocionante, pero está ahí por si algún día agregas más hardware.

Una cosa más: la dirección de escucha del servidor está fijada a 127.0.0.1 directamente en el script de arranque — no es un ajuste de configuración, es un valor codificado. El comentario ahí lo llama "todo el modelo de seguridad", y es exacto. ¿Quieres que se pueda alcanzar desde otro dispositivo? Eso es cosa de tu propio proxy inverso o VPN, deliberadamente no una bandera que puedas simplemente activar.

Cómo un prompt se convierte en imagen

La gente se imagina esta parte como algo misterioso y no lo es. Es un pipeline corto y fijo que ComfyUI arma a partir de su plantilla oficial:

Ajustes de Z-Image Turbo

Z-Image Turbo es la variante destilada y rápida del modelo Z-Image de Alibaba (según entiendo, sale de su Tongyi Lab, con unos 6 mil millones de parámetros, Apache-2.0). "Destilado" aquí significa algo concreto: 8 pasos y CFG 1.0 producen una imagen terminada, en lugar de los 20–30+ pasos que piden los modelos más viejos. Estos son los ajustes de mi workflow guardado, y son simplemente los valores por defecto de la plantilla oficial. No hay una combinación mágica que andar buscando.

Ajuste	Valor
Pasos	8
CFG	1.0
Sampler	res_multistep
Scheduler	simple
Shift de ModelSamplingAuraFlow	3
Resolución	1024×1024
Tipo de CLIPLoader	lumina2
Prompt negativo	anulado a cero (ConditioningZeroOut)

Esa última fila vale la pena explicarla: con CFG 1.0, un prompt negativo no tiene contra qué empujar, así que el workflow lo anula a cero con un nodo ConditioningZeroOut en lugar de codificar un texto que no hace nada. Escribe un prompt negativo si te hace sentir más en control. No va a cambiar la imagen.

Los tres archivos que hacen el trabajo de verdad:

Archivo	Tamaño	Rol
z_image_turbo_bf16.safetensors	12.3GB	transformador de difusión (bf16)
qwen_3_4b.safetensors	8.0GB	codificador de texto
ae.safetensors	0.34GB	VAE

Rendimiento medido

Estos no son números de una entrada de blog de lanzamiento; salen del journal de esta máquina. Una tanda de 20 prompts consecutivos registró tiempos entre 26.62s y 30.41s, así que "~27 segundos" es un promedio aburrido y repetible, no el mejor caso escogido a dedo. Eso da aproximadamente 2.5–3 segundos por paso de muestreo una vez que se suma la codificación de texto y la decodificación VAE.

La primera imagen tras un arranque en frío del servicio tardó 43.54 segundos, porque esa es la corrida en la que cargan ~20GB de pesos desde el disco. Todo lo demás va en caliente. Si tu primera imagen del día se siente lenta, esa es la razón, no una señal de que algo esté mal.

Corriéndolo como servicio

No quiero estar cuidando un proceso de Python en una terminal cada vez que quiero una imagen, así que esto corre como una unidad de usuario de systemd, iniciada junto con la sesión de login:

ExecStart=%h/comfy/start-comfyui.sh
WorkingDirectory=%h/comfy/ComfyUI
EnvironmentFile=-%h/comfy/comfy.env
Restart=on-failure
RestartSec=5
TimeoutStartSec=120

El archivo de entorno mantiene el puerto y los argumentos extra de arranque en un solo lugar editable. Encima de eso hay un pequeño envoltorio, comfyctl, así que el uso del día a día queda así:

comfyctl start      # starts the service, waits for it to answer, opens the workflow
comfyctl status     # server health + unit state + newest output file
comfyctl generate "a foggy harbor at dawn, cinematic"
comfyctl stop
comfyctl logs

Si el proceso muere, Restart=on-failure lo levanta de nuevo tras 5 segundos, hasta 5 veces por minuto antes de que systemd se dé por vencido (así un bucle de caídas real no gira eternamente). Un timer semanal trae actualizaciones con git pull --ff-only, reinicia el servicio y verifica /system_stats antes de darlo por exitoso. El ícono de escritorio de esta cosa lo generó el propio modelo, algo que me gusta más de lo que probablemente debería.

Haciéndolo sin interfaz

La interfaz web está bien para casos puntuales, pero el uso diario aquí es con script. Un script de Python que solo usa la librería estándar arma el grafo como JSON, lo envía, sondea el resultado, e imprime la ruta del PNG terminado:

python3 ~/comfy/comfy-generate.py "a foggy harbor at dawn, cinematic" \
  --steps 8 --width 1024 --height 1024 --out ~/Pictures/harbor.png

La API HTTP, el script de control y el acceso remoto seguro desde otros dispositivos tienen su propio artículo completo: ComfyUI sin interfaz: córrelo como servicio, úsalo desde cualquier lugar.

Tropiezos

• El "cuda:0" en los logs es normal. La versión de PyTorch para ROCm reporta la GPU de AMD como un dispositivo CUDA. No es un error de configuración, y no está usando en secreto una tarjeta NVIDIA.
• La primera imagen tras un reinicio es lenta. ~43 segundos mientras cargan los pesos, y luego se estabiliza en ~27. No reinicies a mitad de sesión y luego entres en pánico pensando que algo se rompió.
• Los prompts negativos aquí no hacen nada. CFG 1.0 los anula a cero por diseño. Si estás depurando una imagen mala, el prompt negativo no es donde está el problema.
• No puedes simplemente abrir esto desde tu teléfono. La dirección de escucha está codificada a 127.0.0.1 a propósito. El acceso remoto significa montar tu propio proxy inverso o VPN, no editar un archivo de configuración.
• Se actualiza solo cada semana. Cómodo, hasta la semana en que no lo es. El pull de solo fast-forward evita fusiones silenciosas, pero un cambio que rompa algo puede llegar de arriba mientras no estabas mirando.
• 64GB suena a mucho hasta que cargas más. Este workflow usa unos 20.7GB de pesos. Carga varios modelos grandes a la vez, o corre algo más que consuma GPU al mismo tiempo, y el margen desaparece rápido.