Esta tarde decidí tocar algo muy concreto. Sin prisas, sin redes, sin Cursor y sin la sensación de que tenía que salir algo publicable. Simplemente quería probar Qwen Image en local, con el equipo que uso a diario, medir su comportamiento y documentar lo que pasara.

No buscaba una demo ni un tutorial de éxito. Buscaba responder a una pregunta muy simple: si este stack es viable hoy para trabajar en local sin depender de servicios externos.

Mi entorno no tiene nada raro. Trabajo con una AMD RX 7800 XT, Linux sobre Nobara, kernel actualizado y ROCm instalado desde los repositorios del sistema. Es exactamente el tipo de configuración que muchos usamos fuera de entornos controlados o máquinas dedicadas solo a pruebas.

Sobre el papel todo encajaba. En la práctica, no.

El planteamiento inicial era directo. Instalar Qwen Image usando Diffusers y PyTorch, ejecutar inferencia por GPU y observar consumo y estabilidad. En esta primera fase descarté Docker a propósito. Quería ver qué pasaba directamente sobre el sistema, sin capas que pudieran esconder problemas.

Arranqué con un entorno clásico usando Python y venv, junto con las wheels oficiales de PyTorch con soporte ROCm. La instalación fue pesada, pero aparentemente correcta. El problema apareció en el primer import.

ImportError: libamdhip64.so: cannot enable executable stack as shared object requires:
Invalid argument

En ese momento quedó claro que el fallo no estaba en Qwen Image ni en el código. El choque venía de más abajo.

A partir de ahí el trabajo dejó de ser sobre modelos y pasó a ser sobre sistema. Verifiqué que ROCm detectaba la GPU, que rocminfo y clinfo respondían correctamente y que las librerías del sistema estaban donde debían.

La librería libamdhip64.so del sistema estaba correcta. No requería stack ejecutable y no violaba ninguna política de seguridad. El problema era que PyTorch no estaba usando esa librería. Estaba cargando copias embebidas dentro del propio wheel, compiladas con flags incompatibles con un kernel endurecido.

Se intentó forzar el uso de la librería del sistema con variables de entorno como LD_LIBRARY_PATH y LD_PRELOAD. No sirvió. El cargador dinámico seguía priorizando las librerías internas del paquete.

Para confirmar el diagnóstico se renombró la primera librería problemática con la idea de obligar al uso de la versión del sistema. El resultado fue inmediato:

ImportError: libhiprtc.so: cannot enable executable stack

Ahí el patrón ya era evidente. No se trataba de una librería aislada. Era toda la cadena HIP embebida en el wheel. Esto no se arregla con un parche puntual ni con un ajuste menor. Es una incompatibilidad estructural entre cómo se empaqueta PyTorch ROCm y cómo funcionan distribuciones con políticas de seguridad estrictas.

El siguiente paso lógico fue probar Conda, una vía habitual en entornos científicos para evitar este tipo de conflictos. Se instaló Miniforge, se creó un entorno limpio y se evitó mezclarlo con venv, algo que solo añade ruido.

Ahí apareció otra limitación menos conocida. En los canales estándar de Conda no existen paquetes de PyTorch con soporte ROCm para Linux x86_64. No es un problema de versión ni de sintaxis. Simplemente no están publicados.

Llegados a ese punto, la conclusión era clara.

Este experimento no demuestra que Qwen Image no funcione. Tampoco demuestra que AMD no sea válida para cargas de trabajo de IA. Lo que pone sobre la mesa es el estado actual del ecosistema cuando se combinan GPU AMD, ROCm, wheels con librerías embebidas y distribuciones endurecidas.

Hay entornos donde este stack funciona con menos fricción. Otros sistemas son más permisivos. Este no lo es, y eso no es un error. Es una decisión técnica con consecuencias claras.

No todos los experimentos acaban con una imagen bonita. A veces el valor está en documentar dónde se rompe el camino. Este tipo de pruebas ahorran tiempo, frustración y expectativas mal colocadas. Ayudan a separar el ruido del análisis técnico.

Aquí el problema no es el modelo. Tampoco es falta de conocimiento. Es una incompatibilidad concreta, reproducible y bien delimitada.

Cerrar un experimento con esta conclusión no es fallar. Es entender hasta dónde llega el stack que tienes entre manos. Y eso, en ingeniería, también es avanzar.