Generación de imágenes por IA local en AMD (ROCm): ComfyUI + Z-Image Turbo
- Categoría
- IA y LLM Local
- Publicado
- 11 julio 2026
- Actualizado
- 16 septiembre 2026
- Por
- Jacob Lloyd — escrito con ayuda de IA, después del proyecto
- Tiempo de lectura
- 10 min de lectura
En palabras simples: Cómo configuré mi pequeña computadora AMD para crear imágenes generadas por IA en casa: aproximadamente 27 segundos por imagen, sin necesidad de suscripción ni costo adicional por cada imagen. La guía explica paso a paso cómo hacer la configuración para que todo funcione de forma automática. Esto demuestra que no se necesita un servicio en la nube costoso ni una marca específica de tarjeta gráfica para crear arte mediante IA.
Actualización del 16/09/2026: Ya no ejecuto esta configuración de ComfyUI en mi propia máquina; ahora, la generación de imágenes la hago mediante un equipo remoto con GPU. Las instrucciones a continuación permanecen igual y siguen siendo válidas si deseas ejecutar esto en tu propia máquina AMD.
Mi máquina AMD convierte un prompt de texto en una imagen de 1024×1024 lista para usar en unos 27 segundos: sin necesidad de cuenta en la nube, sin cargos por cada imagen generada y sin colas de espera con miles de prompts de otros usuarios. Y todo esto se logra con un chip AMD que la mayoría de la gente cree que no es capaz de hacerlo.
Resumen rápido
- ¿Qué es?: ComfyUI + Z-Image Turbo; generan imágenes íntegramente en hardware local. OpenAI y Midjourney no intervienen en absoluto.
- ¿Cuánto cuesta?: $0 por imagen, sin límite de cantidad. Ni siquiera es necesario registrarse.
- ¿Qué se necesita?: una APU o GPU AMD con VRAM suficiente (la mía cuenta con 64 GB), un equipo con Linux y un único proceso de configuración de ROCm. Solo una vez.
- ¿Qué obtienes?: un tiempo de generación de ~27 segundos por imagen de 1024×1024, un servicio systemd siempre activo y un comando de una sola línea para generar imágenes en modo headless.
¿Qué se obtiene al final?
La parte de configuración puede esperar. En el día a día, abro una pestaña en el navegador o lo ejecuto desde el terminal. En cualquier caso:
| Métrica | Valor |
|---|---|
| Resolución | 1024×1024 |
| Pasos / CFG | 8 pasos, CFG 1.0 |
| Tiempo de generación (en caliente) | ~27 s (rango medido: 26,5–30,4 s) |
| Inicio en frío (primera imagen tras el arranque) | ~43,5 s; durante ese tiempo se cargan unos 20 GB de pesos del modelo |
El caso de uso real en esta máquina no es la creación artística por sí misma. Se trata de un script que genera de forma masiva variaciones de avatares para una aplicación de chat autoalojada: ya se han generado 222 archivos PNG en la carpeta de salida, y el número sigue aumentando. Es una infraestructura aburrida pero fiable; exactamente lo que uno desea de algo que construyó por diversión y del cual ahora depende.
El hardware
Se trata de una máquina con 128 GB de memoria unificada: un AMD Ryzen AI Max+ 395 (“Strix Halo”) que incluye una iGPU Radeon 8060S en el mismo paquete que la CPU. Es el ASUS ROG Flow Z13 del artículo sobre mi laboratorio doméstico; dejó de funcionar tras un fallo eléctrico. No cuenta con ninguna GPU dedicada.
Ahora viene lo importante: el firmware reserva 64 GB de esos 128 GB y los asigna a la iGPU como “VRAM” dedicada. El propio registro de inicio de ComfyUI indica: Total VRAM 65536 MB, total RAM 63920 MB. Esa cantidad de VRAM supera la de cualquier tarjeta gráfica de consumo de NVIDIA, y no se trata de costosas memorias GDDR soldadas en una tarjeta gráfica. Simplemente es memoria del sistema asignada por el firmware a la GPU; además, hay aproximadamente 31 GB más de memoria GTT accesible para la GPU si fuera necesario.
| Componente | Especificaciones |
|---|---|
| CPU | AMD Ryzen AI Max+ 395, 16 núcleos / 32 hilos |
| iGPU | Radeon 8060S, arquitectura ROCm gfx1151 |
| Memoria | 128 GB de memoria unificada LPDDR5X: 64 GB asignados como VRAM; unos 62 GB quedan para Linux |
| Sistema operativo | Bazzite (basado en Fedora Silverblue, sistema inmutable) |
| GPU dedicada | Ninguna |
El tamaño total de los pesos de los modelos que utilizo en esta configuración es de unos 20,7 GB. Esa cantidad cabe holgadamente dentro de los 64 GB de VRAM disponibles; sin embargo, sería imposible ejecutarlo en una tarjeta gráfica típica de consumo con 8–16 GB de VRAM, a menos que se descarguen algunas capas a la RAM del sistema, lo cual reduciría drásticamente el rendimiento.
Pila de software
Las versiones que hacen posible todo esto, tal como están instaladas actualmente:
| Componente | Versión |
|---|---|
| ComfyUI | v0.27.0 (git checkout) |
| Python | 3.12.13, en un entorno virtual creado 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, con soporte nativo para gfx1151 |
El detalle curioso: la versión de PyTorch compilada para ROCm se hace pasar por CUDA. El registro de inicio indica literalmente Device: cuda:0 AMD Radeon 8060S : native. El código Python diseñado para tarjetas NVIDIA simplemente funciona, ya que cree que está comunicándose con una tarjeta de esa marca. ComfyUI también desactiva automáticamente cuDNN en este hardware y recurre al mecanismo de atención estándar de PyTorch (sin xformers ni flash-attn); no obstante, todo funciona perfectamente sin ellos.
Haciendo que ROCm funcione correctamente
Los problemas de configuración se deben a unas pocas variables de entorno en el script de inicio:
HSA_OVERRIDE_GFX_VERSION=11.5.1
PYTORCH_HIP_ALLOC_CONF=expandable_segments:True
HIP_VISIBLE_DEVICES=0
HSA_OVERRIDE_GFX_VERSIONle indica a ROCm que la GPU es gfx1151. En ROCm 7.2 esto resulta redundante (el registro ya indica “native”), pero lo mantengo como medida de seguridad; en versiones anteriores de ROCm este ajuste era obligatorio para que iGPUs como esta pudieran funcionar.PYTORCH_HIP_ALLOC_CONF=expandable_segments:Trueevita que el asignador fragmente la VRAM en la memoria unificada. Sin esta configuración, se pueden producir errores de “memoria insuficiente” aunque técnicamente haya mucha memoria disponible.HIP_VISIBLE_DEVICES=0limita el uso a una sola GPU. No es nada especial, pero está ahí por si alguna vez agregas más hardware.
Un detalle más: la dirección de escucha del servidor queda fijada en 127.0.0.1 dentro del script de inicio; no es un parámetro configurable, sino un valor hardcodeado. El comentario correspondiente lo denomina “todo el modelo de seguridad”, y así es. ¿Quieres que el servidor sea accesible desde otro dispositivo? Para eso necesitas un proxy inverso o una VPN; intencionadamente no existe ninguna opción que puedas activar fácilmente.
Cómo un prompt se convierte en una imagen
La gente imagina que esta parte es algo misterioso, pero no lo es. Se trata de un proceso corto y fijo que ComfyUI configura a partir de su plantilla oficial:
Configuración de Z-Image Turbo
Z-Image Turbo es la versión optimizada y rápida del modelo Z-Image de Alibaba (según tengo entendido, proviene de su laboratorio Tongyi; cuenta con aproximadamente 6 mil millones de parámetros y se distribuye bajo la licencia Apache-2.0). “Optimizado” aquí significa algo concreto: con 8 pasos y un valor de CFG de 1.0 se genera una imagen completa, en lugar de los 20–30 pasos que requieren los modelos anteriores. Estas son las configuraciones de mi flujo de trabajo guardado; simplemente son los valores predeterminados oficiales. No hay ninguna combinación mágica que haya que buscar.
| Configuración | Valor |
|---|---|
| Pasos | 8 |
| CFG | 1.0 |
| Muestreador | res_multistep |
| Programador | simple |
| ModelSamplingAuraFlow shift | 3 |
| Resolución | 1024×1024 |
| Tipo de CLIPLoader | lumina2 |
| Prompt negativo | puesto a cero (ConditioningZeroOut) |
Merece la pena explicar esa última fila: con un valor de CFG de 1.0, no hay nada contra lo que actúe un prompt negativo; por eso el flujo de trabajo lo pone a cero mediante un nodo ConditioningZeroOut, en lugar de codificar un texto que no tendría efecto alguno. Puede escribir un prompt negativo si así se siente más controlado; no cambiará la imagen resultante.
Los tres archivos que realizan el trabajo propiamente dicho:
| Archivo | Tamaño | Función |
|---|---|---|
| z_image_turbo_bf16.safetensors | 12,3 GB | transformador de difusión (bf16) |
| qwen_3_4b.safetensors | 8,0 GB | codificador de texto |
| ae.safetensors | 0,34 GB | VAE |
Rendimiento medido
Estas no son cifras extraídas de una publicación del blog de lanzamiento; provienen del registro de actividad de esta máquina. En una ejecución con 20 prompts consecutivos, los tiempos registrados oscilaron entre 26,62 segundos y 30,41 segundos; por lo tanto, “~27 segundos” es un promedio constante y predecible, no el mejor caso posible seleccionado al azar. Eso equivale a aproximadamente 2,5–3 segundos por paso de muestreo, una vez incluidos el codificado de texto y el decodificado VAE.
La primera imagen generada tras un reinicio del servicio tardó 43,54 segundos, ya que en ese momento se cargan unos 20 GB de pesos desde el disco. Todo lo que viene después se genera con mayor rapidez. Si la primera imagen del día tarda más de lo normal, esa es la razón; no es señal de que algo vaya mal.
Ejecución como servicio
No quiero tener que estar controlando un proceso de Python en la terminal cada vez que necesito una imagen; por eso se ejecuta como una unidad de usuario de systemd, que se inicia junto con la sesión de inicio de sesión:
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 adicionales de lanzamiento en un único lugar editable. Además, existe un pequeño wrapper llamado comfyctl, por lo que el uso diario es muy sencillo:
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 se detiene, Restart=on-failure lo reinicia después de 5 segundos; esto ocurre hasta 5 veces por minuto antes de que systemd abandone el intento (para evitar bucles infinitos en caso de fallos reales). Un temporizador semanal realiza actualizaciones mediante git pull --ff-only, reinicia el servicio y verifica el contenido de /system_stats para considerar la operación como exitosa. El icono de escritorio correspondiente fue generado por el propio modelo; me gusta más de lo que probablemente debería.
Ejecución sin interfaz gráfica
La interfaz web está bien para usos puntuales, pero en nuestro caso el uso diario se realiza mediante scripts. Un script de Python que utiliza únicamente la biblioteca estándar construye el grafo en formato JSON, lo envía, espera el resultado y luego muestra la ruta del archivo PNG generado:
python3 ~/comfy/comfy-generate.py "a foggy harbor at dawn, cinematic" \
--steps 8 --width 1024 --height 1024 --out ~/Pictures/harbor.png
El API HTTP, el script de control y el acceso remoto seguro desde otros dispositivos tendrán cada uno su propia explicación detallada: Headless ComfyUI: Ejecútelo como servicio y úselo desde cualquier lugar.
Posibles problemas
- Que aparezca “cuda:0” en los registros es normal. PyTorch con ROCm identifica la GPU de AMD como un dispositivo CUDA. No se trata de una configuración errónea, ni de que esté utilizando en secreto una tarjeta NVIDIA.
- La primera imagen generada tras un reinicio tarda más en crearse. Aproximadamente 43 segundos durante la carga de los pesos; luego el tiempo se reduce a unos 27 segundos. No reinicie la sesión y luego entre en pánico pensando que algo falló.
- Los prompts negativos no tienen efecto aquí. Con un valor de CFG de 1.0, dichos prompts se anulan por diseño. Si está intentando solucionar un problema con una imagen mal generada, el problema no radica en los prompts negativos.
- No puede simplemente acceder a este servicio desde su teléfono. La dirección de escucha está fijada intencionadamente en 127.0.0.1. Para acceder de forma remota, deberá configurar su propio proxy inverso o una VPN; no basta con modificar un archivo de configuración.
- El sistema se actualiza semanalmente. Esto resulta útil... hasta la semana en que deje de serlo. El mecanismo de actualización evita fusiones automáticas, pero aun así pueden aparecer cambios importantes en el código base sin previo aviso.
- 64 GB parecen muchos hasta que empieza a cargar modelos. Este flujo de trabajo utiliza alrededor de 20,7 GB de pesos. Si carga varios modelos grandes a la vez, o ejecuta otra aplicación que requiera mucho uso de la GPU, ese margen de memoria se agota rápidamente.
Relacionado: ComfyUI sin interfaz gráfica: ejecútelo como servicio y úselo desde cualquier lugar · ASUS ROG Flow Z13: mi laboratorio doméstico portátil que se negó a seguir siéndolo · DisPatch: una aplicación de chat autohospedada para agentes de IA locales · StudioForge: un servidor LLM exclusivo para GPU que reemplazó a LM Studio