Qwen-Image-2.1 LoRA: qué adaptadores existen, qué implica entrenar uno y qué dice realmente la licencia

Existe un ecosistema real de adaptadores de adaptación de bajo rango (LoRA) para Qwen-Image-2.1, el modelo de imagen unificado de generación y edición del proveedor, y casi no hay documentación al respecto por parte del proveedor. Esta página es la respuesta permanente a cuatro preguntas que un lector escribe juntas: ¿alguien crea realmente adaptadores para este modelo?, ¿dónde se encuentran?, ¿qué se necesita para entrenar uno? y ¿qué permite hacer la licencia con el resultado? No es un artículo de lanzamiento. Qwen-Image-2.1 se publicó como código abierto el 20 de septiembre de 2026 y su hermano acelerado Qwen-Image-2.1-Turbo llegó el 9 de octubre de 2026; ambas fechas están aquí solo para identificar de qué checkpoints trata esta página, no para informar de nada.

La versión corta: los adaptadores existen en el orden de los cientos bajos, en su mayoría son trabajos de personajes y estilos publicados por profesionales individuales, el entrenamiento de uno está documentado de principio a fin por al menos tres cadenas de herramientas de terceros con mediciones de memoria publicadas, y la licencia —que no es Apache para esta generación de los modelos de imagen— reafirma una restricción de uso no comercial sobre la obra derivada que muchos de los propios adaptadores no logran transmitir.

Dos frases sobre qué es una LoRA, y luego el modelo

Un LoRA es un pequeño conjunto de deltas de pesos de bajo rango que se añade a un checkpoint base congelado en el momento de la carga y que se dirige a módulos específicos por su nombre; no es un modelo, es un parche que cambia cómo se comporta un modelo existente. Dado que los deltas se entrenan con respecto a pesos concretos, un adaptador está vinculado al checkpoint sobre el que se entrenó de una manera que un indicador de configuración no puede corregir.

Esa vinculación es la razón por la que esta página trata específicamente de Qwen-Image-2.1 y no de las LoRA. El checkpoint es un transformer de difusión de flujo único de 32 capas con 7B de parámetros en su componente de generación visual, un codificador de texto Qwen3-VL 8B y un VAE RGBA de 64 canales que trabaja con una compresión espacial de 16×; todas las cifras proceden de la propia tarjeta del modelo y del repositorio del proveedor, consultados el 13 de octubre de 2026. Establece su programa de muestreo en el momento de la llamada, con 40 pasos de inferencia en los propios ejemplos de la tarjeta. Ninguno de esos detalles es incidental para los adaptadores: la arquitectura decide a qué puede dirigirse un archivo, y el programa decide qué se le pide hacer a un adaptador entrenado con una parametrización distinta.

Qué existe para este modelo y cómo contarlo con honestidad

Los recuentos que figuran a continuación proceden de la API de Hugging Face y de la API de Civitai, ambas consultadas el 13 de octubre de 2026, y merece la pena especificar la consulta, porque la misma pregunta arroja respuestas radicalmente distintas según cómo se formule.

• Repositorios en Hugging Face que declaran Qwen-Image-2.1 como su modelo base: 323.

• De esos, los repositorios que también llevan la lora como etiqueta: 115.

• Adaptadores en Civitai que coinciden con un filtro de modelo base de "Qwen 2.1" y el tipo configurado como LoRA: 106. Una pasada anterior del mismo día contó 105; el filtro está activo y el número se mueve, así que tómalo como una lectura y no como un total.

Ambas cifras son mínimos, no censos. La etiqueta de Hugging Face la aplica quien sube el contenido, así que un adaptador cuyo autor no la etiquetó es invisible para esa consulta; el recuento de modelos base es mayor que el de LoRA precisamente porque también captura cuantizaciones, fusiones y reempaquetados. En Civitai, la diferencia entre métodos es contundente: una búsqueda de texto simple de "qwen image 2.1" devuelve 994 modelos únicos, y la mayoría no son adaptadores de este checkpoint en absoluto — el mismo conjunto de resultados está dominado por publicaciones de flujos de trabajo y por archivos cuyo modelo base declarado es una generación de imágenes totalmente distinta. Filtra por el modelo base, no por el cuadro de búsqueda.

Ambos sitios son el lugar donde vive este ecosistema, y esa es la única afirmación que se hace sobre cualquiera de los dos: Hugging Face es donde se publican los registros de entrenamiento y los conjuntos de datos, Civitai es donde se reúnen los adaptadores orientados al consumidor y los flujos de trabajo de ComfyUI en torno a ellos, y ninguno de los dos es una señal de calidad. Un archivo en cualquiera de ellos puede ser una obra original de trabajo entrenado o una copia de la de otra persona.

Distinguir un adaptador original de uno reenvasado

Esto es comprobable, y la comprobación toma alrededor de un minuto. Toma dos repositorios que parecen ser el mismo adaptador.

akhaliq/Qwen-Image-2.1-Next-Scene-LoRA se creó el 7 de octubre de 2026. TechnoBaptist/Qwen-Image-2.1-Next-Scene-LoRA se creó el 9 de octubre de 2026. Sus archivos README son idénticos byte a byte —la misma longitud, el mismo MD5— y las listas de archivos de ambos repositorios coinciden en las 111 entradas. El más reciente es una copia del anterior, incluida la descripción.

El caso menos obvio es la copia parcial. developerjeremylive/Qwen-Image-2.1-Multiple-Angles-LoRA-etheroi contiene 163 archivos. Cada uno de los 160 que también existen en akhaliq/Qwen-Image-2.1-Multiple-Angles-LoRA tiene el mismo tamaño, y el repositorio es un subconjunto estricto de los 344 archivos de aquel. Lo que quedó atrás es todo el directorio benchmarks/, las cuadrículas de muestras por checkpoint bajo samples/, y varias variantes de checkpoint. Los pesos del adaptador están presentes. La evidencia de que el adaptador hace lo que dice no lo está.

Así que la prueba práctica no es «¿tiene una tarjeta bonita?». Es si la tarjeta contiene las cosas que solo pueden provenir de haber hecho la ejecución:

• De dónde provienen los datos de entrenamiento, con un enlace — el adaptador de ángulo indica su fuente de Objaverse y su licencia, y publica por separado los conjuntos de datos de pares derivados.

• El entrenador y los hiperparámetros, a nivel de rango, alfa, tasa de aprendizaje, número de pasos y precisión base — suficiente para que otra persona intente una reproducción.

• Puntos de control intermedios en lugar de solo un archivo final, para que la curva de entrenamiento pueda inspeccionarse en lugar de darse por sentada.

• Una evaluación que no sea el escaparate del autor, y una sección de «alcance y límites» que señale lo que el adaptador hace mal.

Una tarjeta con una palabra de activación, un rango de intensidad y un conjunto de muestras bonitas, y nada más, no es evidencia de nada. Tampoco es prueba de un repack: hay muchos adaptadores únicos honestos documentados con tan poco detalle. Solo significa que no tienes nada en qué basarte, lo cual, para un archivo que estás a punto de poner en un pipeline de producción, es la conclusión útil.

Qué formación se recibe en realidad

El planteamiento honesto, para empezar, porque la brecha aquí es amplia: publicar un adaptador es común, y entrenar uno es una empresa de otro orden. Hay tres costos, y todos son reales.

El checkpoint base. Los tres componentes de Qwen-Image-2.1 suman aproximadamente 33 GB entre el transformer, el codificador de texto y el VAE; esa es la suma de los tamaños de archivo publicados por el propio repositorio, consultados el 13 de octubre de 2026. Eso es lo que se está adaptando, y no se reduce porque solo estés entrenando un pequeño parche sobre él.

Los datos. Una LoRA no aprende un concepto a partir de un puñado de imágenes como lo hace un prompt. Los dos adaptadores mejor documentados de este ecosistema publicaron sus conjuntos de datos como artefactos de primera clase: el adaptador de control de cámara se entrenó con 5.028 pares etiquetados por ángulo en su primera versión y 13.328 en la segunda; el adaptador de continuación de escena se entrenó con 1.144 pares de progresión fotograma a fotograma, con descripciones escritas por un modelo de visión para cada par. Ambos son conjuntos de datos ensamblados, no colecciones de fotografías: los pares tuvieron que generarse, etiquetarse y licenciarse antes de que comenzara el entrenamiento y, en un caso, las imágenes de origen tuvieron que filtrarse hasta dejar solo objetos con licencias permisivas antes de que pudieran usarse siquiera.

El cómputo. Esta es la parte con mediciones publicadas en lugar de intuiciones. La propia guía de inicio rápido de SimpleTuner para el modelo ofrece preajustes de VRAM y, por separado, las pruebas de humo de memoria que hay detrás de ellos: una receta de 512px con checkpointing de gradientes en cada paso pasó una prueba con límite de asignación de 24 GiB, alcanzando un pico de 20,06 GiB asignados y 21,10 GiB reservados por PyTorch. Una receta multirresolución de 32,49 / 41,21 GiB pasó en una L40S, pero se quedó sin memoria bajo un límite de 32 GiB. Los autores son explícitos en que esas son comprobaciones de memoria de subconjunto acotado, no mediciones de rendimiento ni de convergencia, y en que los presupuestos más bajos se simularon en una L40S en lugar de ejecutarse en sus tarjetas nominales. Si se leen tal como se publicaron, dicen algo simple: el mínimo para este modelo es una tarjeta de 24 GB que solo funciona a 512px, y 48 GB o más es donde las recetas multirresolución que el framework realmente recomienda pasan a estar disponibles.

El tiempo es el costo más silencioso, y casi nadie lo publica. Lo que sí es público son los recuentos de pasos: 2000 actualizaciones en el preset de 24 GB, 4000 en los más grandes, con validación y checkpointing cada 250, y recuentos de checkpoints en los miles más bajos según los propios registros de entrenamiento de los adaptadores. La tabla de presets de SimpleTuner ofrece presupuestos de actualizaciones para cada nivel de VRAM y dice claramente que son puntos de partida que solo deben ampliarse tras inspeccionar las imágenes de los checkpoints. Nadie ha publicado las horas de reloj para una ejecución reproducible, así que cualquier cifra que veas citada sobre cuánto tarda esto es la tarjeta de alguien y el dataset de alguien, no una especificación.

Frente a eso, las herramientas son genuinamente buenas, y esta es la parte que cambió lo suficientemente recientemente como para merecer que se le ponga fecha. El proveedor señala DiffSynth-Studio de ModelScope, cuyo repositorio incluye un script de entrenamiento LoRA funcional para este checkpoint y, por separado, para la variante Turbo: un solo accelerate launch con rango 32, AdamW a 1e-4, cinco épocas, un presupuesto máximo de píxeles de 1.048.576 y checkpointing de gradientes. La guía de inicio rápido de SimpleTuner es la receta pública más detallada, y es inusualmente honesta sobre sus propios límites. ai-toolkit incluye tanto Qwen-Image-2.1 como Qwen-Image-2.1-Turbo entre sus arquitecturas compatibles, y dos de los adaptadores descritos anteriormente registran haber sido entrenados con él. Y el 12 de octubre de 2026, musubi-tuner fusionó una pull request que añadía compatibilidad con Qwen-Image 2.1, abarcando entrenamiento LoRA, ajuste fino completo, vistas previas de entrenamiento y conversión entre Diffusers y su propio formato LoRA; la solicitud de función que la pedía, abierta el 24 de septiembre, sigue abierta. Esa fusión se produjo tres días antes de la fecha de esta página y es un cambio en las herramientas más que un lanzamiento de modelo; significa que un cuarto entrenador pasó a estar disponible, no que algo del modelo haya cambiado.

Hay una restricción más que sorprende a quienes han entrenado LoRAs para otras arquitecturas. La salida de este modelo no tiene conmutador alfa. El VAE opera en un espacio de píxeles RGBA de cuatro canales y el cuarto canal se decodifica como el alfa, así que la transparencia la produce el prompt y nada más — la propia documentación del proveedor afirma que no hay ningún control relacionado con el alfa en ninguna parte del pipeline. Un adaptador entrenado con imágenes opacas cambia la distribución que el prompt está guiando; no tiene un control de transparencia independiente al que recurrir. Si tu pipeline depende de recortes, eso es una propiedad del modelo base que estás tomando prestado, y vale la pena probarlo antes de asignarle una ejecución de entrenamiento.

Lo que dice la licencia sobre el adaptador que fabricas.

Lee el archivo, porque la respuesta no es lo que sugeriría un lanzamiento que suena permisivo. Qwen-Image-2.1 se distribuye bajo el Qwen Research License Agreement con fecha del 20 de septiembre de 2026 — un documento de 7.831 bytes trasladado sin cambios al repositorio Turbo, cuya copia es idéntica byte por byte. No es Apache 2.0, y la línea anterior de Qwen-Image sí lo era.

La cláusula que decide la mayor parte de esto es la concesión. La Sección 2(a) le otorga licencia para "usar, reproducir, distribuir, copiar, crear obras derivadas de, y hacer modificaciones a" los materiales, y luego limita todo ello: "ÚNICAMENTE PARA FINES NO COMERCIALES". La Sección 1(i) define no comercial como "únicamente para fines de investigación o evaluación", lo cual es más restrictivo que "sin fines de lucro": no excluye el uso empresarial interno. La Sección 2(b) dice que el uso comercial requiere una licencia separada, solicitada en la dirección que indica el acuerdo. Un adaptador entrenado con este checkpoint es una obra derivada de él, por lo que la restricción viaja con el adaptador; no se vuelve comercialmente utilizable porque usted mismo lo entrenó.

Dos cosas que vale la pena señalar, porque ambas contradicen las suposiciones habituales.

En primer lugar, la licencia no guarda silencio sobre el entrenamiento — lo contempla directamente. La sección 4(b) dice que, si utilizas los materiales o sus resultados para "crear, entrenar, afinar o mejorar un modelo de IA que se distribuya o se ponga a disposición", debes mostrar de forma destacada "Built with Qwen" o "Improved using Qwen" en la documentación del producto correspondiente. Así que el ajuste fino se aborda por su nombre, y conlleva una obligación de etiquetado en lugar de una cuestión de permiso.

Segundo, la redistribución está expresamente permitida, con condiciones. La sección 3 le permite distribuir obras derivadas, en forma de código fuente o de objeto, siempre que entregue a los destinatarios una copia del acuerdo, marque los archivos modificados y conserve un archivo de aviso que diga: "Qwen está licenciado bajo el Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. Todos los derechos reservados." La sección 4(c) prohíbe usar "Qwen" como nombre principal o identificador de su obra derivada; el uso descriptivo está expresamente permitido. La sección 5(a) confirma que usted es propietario de sus modificaciones, condicionado al cumplimiento. Las disputas se rigen por la ley china, en los tribunales de Hangzhou.

Son obligaciones coherentes y legibles. El hallazgo incómodo es con qué frecuencia el ecosistema no las cumple. De los adaptadores muestreados durante la investigación para esta página, uno —un adaptador de destilación de pasos para el checkpoint base— incluye el texto de la licencia y un archivo de aviso que lleva la cadena de atribución requerida textualmente, además de una sección de licencia en su tarjeta que reitera el límite no comercial y el contacto comercial. Varios otros, incluidos dos de los adaptadores de control de cámara y continuación de escena más descargados, declaran apache-2.0 en sus metadatos, no incluyen ningún archivo de licencia en absoluto y no contienen ningún aviso de atribución. Sus tarjetas no reclaman derechos de Apache sobre los pesos base; el campo de metadatos simplemente está mal, y es el campo que leerá una herramienta posterior. Si eres quien va a construir sobre un adaptador, lee tú mismo la licencia del modelo base en lugar de confiar en la etiqueta de la tarjeta del adaptador; y si eres quien publica, el empaquetado correcto no es complicado, solo tiene que hacerse a propósito.

Compatibilidad, y lo único sobre «turbo»

Un adaptador se ejecuta sobre el checkpoint que indica su registro de entrenamiento. Para la mayoría de los adaptadores que hay aquí, ese es el propio Qwen-Image-2.1, y ahí es donde deben cargarse. El checkpoint Turbo es un ajuste fino de la misma arquitectura, no un modelo distinto —los dos comparten su árbol de módulos, por lo que es muy probable que un adaptador entrenado sobre la base se cargue en Turbo—, pero almacena su propio programa de muestreo de ocho pasos dentro del checkpoint y sigue una trayectoria de eliminación de ruido en la que el adaptador no se entrenó. Que esa combinación se comporte correctamente no está documentado por nadie, ni siquiera por el proveedor.

También hay una trampa de nomenclatura: la frase «turbo LoRA» abarca dos artefactos opuestos, un adaptador entrenado con el checkpoint Turbo y un adaptador de destilación que convierte el checkpoint estándar en uno de pocos pasos. Son archivos diferentes que hacen trabajos diferentes. La cuestión del checkpoint base frente a Turbo, y los dos significados del adaptador turbo, tienen su propia página en este stem — Qwen-Image-2.1-Turbo LoRA — y esta página no va a convertirse en una segunda copia de ella. Si tienes Turbo y un adaptador que hace referencia al checkpoint estándar, lee esa página antes de cargar nada.

Dos preguntas adyacentes también pertenecen a otro lugar. Los checkpoints cuantizados —GGUF, FP8, INT4 y el resto— son un tema diferente con una página diferente; una LoRA usada dentro de un pipeline cuantizado es una nota de compatibilidad en esa página, no una sección en esta. Y el modelo ejecutándose en una herramienta específica vuelve a ser una cuestión propia, con sus propias listas de archivos y sus propios modos de fallo.

Qué se rompe, y qué no está resuelto

Los informes de fallos se agrupan en tres causas, y cada una de ellas ha sido documentada por alguien que hizo el trabajo en lugar de inferida.

Un adaptador que se carga y no hace nada. El caso más concreto es un desajuste en la nomenclatura de claves: la propia tarjeta de un adaptador indica que sus archivos sin procesar en formato del entrenador utilizan la nomenclatura de claves MLP fusionadas de ese entrenador, que Diffusers "omite silenciosamente" — la carga se realiza correctamente, no se genera ningún error y el adaptador no tiene efecto. El archivo funciona con su propio cargador y no con el convencional. Eso es una diferencia en la estructura del archivo, no en el checkpoint base, y vale la pena descartarlo antes de culpar a cualquier otra cosa.

Un adaptador que arruina prompts no relacionados. Este es un problema de tasa de aprendizaje y duración, y hay una medición: en una ablación publicada, una ejecución con 3e-4 «degradó gravemente los cuatro prompts de validación para la actualización 500», con sujetos no relacionados —un zorro, un retrato— transformándose en el concepto entrenado. El estudio del mismo autor sobre entrenamiento más prolongado reporta la trampa opuesta: en una ejecución, un prompt mejoró hasta la actualización 3.500, retrocedió en la 4.000 y se recuperó hasta la 10.000, así que un punto de control intermedio malo no es prueba de que la ejecución haya fracasado. Ese segundo hallazgo se etiqueta explícitamente como una progresión cualitativa a partir de una sola ejecución y una sola semilla de validación, sin que se midiera ninguna curva de error de prueba y con la recuperación descrita como dependiente del prompt. Tómalo como una razón para conservar cada punto de control de 250 pasos, no como una receta.

Un adaptador que se comporta bien y luego se acumula. El adaptador de continuación de escena documenta una degradación medida en el uso encadenado: el encadenamiento ingenuo a fuerza 0.9 acumula el grano de película hasta convertirlo en ruido de color visible para el tercer o cuarto salto, y la solución verificada del autor es una fuerza de 0.7 o inferior más un desenfoque gaussiano de medio píxel en cada entrada encadenada. La misma ficha es franca en que las transformaciones de saltos tardíos se mantienen conservadoras, y lo señala como una limitación de los datos de entrenamiento en lugar de un problema de configuración.

Por debajo de todo esto subyace un conjunto de cuestiones que realmente no están establecidas, y merece la pena enunciarlas en lugar de rellenar los huecos. Nadie ha publicado una comparación de calidad entre Qwen-Image-2.1 y Qwen-Image-2.1-Turbo, así que no hay una línea base con la que juzgar qué efecto tiene cualquier adaptador sobre cualquiera de los dos. Nadie ha publicado si un adaptador de checkpoint estándar se comporta correctamente en Turbo. El proveedor documenta el entrenamiento de LoRA una sola vez, en la sección de ModelScope del repositorio del proyecto, remitiendo a un framework de terceros; la propia model card no contiene ninguna orientación sobre adaptadores, y el codificador de texto del checkpoint es un componente que la comunidad ya ha empezado a republicar por separado, lo cual es una cuestión de compatibilidad en sí misma. Y cada recuento de esta página es una instantánea de un ecosistema de dos o tres semanas de antigüedad leído en un solo día; el filtro de Civitai y la consulta de modelo base de Hugging Face estarán ambos equivocados para el mes que viene, en la dirección de más.

Si estás decidiendo qué hacer hoy, la secuencia que sobrevive a todas esas lagunas es corta. Empieza por leer el registro de entrenamiento del adaptador, no sus muestras; si no hay registro, trata el archivo como no atribuido y pruébalo con tu propio prompt antes de construir sobre él. Haz coincidir el adaptador con el checkpoint que indique su registro y, si estás en Turbo, lee primero la página de Turbo. Comprueba en qué formato de cargador está el archivo antes de concluir que está roto. Y lee la licencia base una vez, porque gobierna el adaptador sin importar lo que la tarjeta del adaptador afirme sobre sí misma. Luego elige tu entrenador, empieza por el preset de VRAM más pequeño que admita tu tarjeta y juzga la cuadrícula de checkpoints en lugar del archivo final.