AI Toolkit LoRA: la preview/samples se ven bien, pero ComfyUI/Diffusers sale diferente

Si entrenaste una LoRA con Ostris AI Toolkit, viste resultados excelentes en Training Samples, y luego obtuviste outputs muy distintos en ComfyUI o Diffusers, es normal sentirse confundido. Quizá buscaste cosas como:

“Los samples de AI Toolkit se ven bien pero ComfyUI se ve mal”
“La LoRA de AI Toolkit no funciona en ComfyUI”
“Mismo prompt/seed, pero Diffusers no coincide con la vista previa de AI Toolkit”
“¿Por qué mi LoRA se ve diferente después de entrenar?”

Aquí va la respuesta directa (y casi siempre tranquilizadora):

En ~99% de los casos, tu LoRA está bien. Tu configuración de inferencia no es la misma que la de la vista previa de entrenamiento.

Los Samples de AI Toolkit no son “corridas aleatorias de Diffusers”. Se producen con una combinación específica de:

la variante exacta del modelo base
cómo se aplica la LoRA (adapter vs merged/fused)
semántica de steps/scheduler/guidance
manejo de resolución (snapping/cropping)
comportamiento de seed/RNG
(a veces) inputs de conditioning extra (edit/control/I2V wiring)

Si cualquiera de esos puntos cambia, el resultado deriva.

Aquí tienes un ejemplo rápido lado a lado de lo que estás viendo: AI Toolkit Training Sample vs tu toolchain actual de inferencia (ComfyUI/Diffusers/etc.).

AI Toolkit training sample	Your inference toolchain

Qué obtendrás de esta guía

Chequeo de 60 segundos: fija estos 6 campos (no toques el entrenamiento todavía)
Checklist de paridad en 10 minutos: 7 causas comunes de “preview ≠ inference” (por prioridad)
¿No quieres debuggear? Consigue paridad de inferencia en RunComfy

Si solo quieres que la inferencia coincida con tus training samples de AI Toolkit (empieza aquí)

Recomendado (workflow de paridad): AI Toolkit LoRA Training‑Inference Parity
Para auditar/self‑host (referencia Diffusers): Open-source AI Toolkit inference code

Chequeo de 60 segundos: fija estos 6 campos (no toques el entrenamiento todavía)

Elige un Training Sample de AI Toolkit que quieras reproducir (el Sample #1 es ideal). Copia o exporta esto exactamente:

1) Base model (variante/revisión exacta — no solo “FLUX”)

2) Prompt (incluye la palabra gatillo, en la misma posición)

3) Negative prompt (si el entrenamiento no usó, déjalo vacío)

4) Width/height

5) Seed

6) Steps + guidance (y todo lo relacionado con sampler/scheduler)

Si igualas esos 6 campos y aun así hay mucha diferencia, estás frente a uno de los problemas de paridad de abajo.

Checklist de paridad en 10 minutos: 7 causas comunes de “preview ≠ inference” (por prioridad)

Regla práctica: cambia una sola variable a la vez. Si cambias cinco cosas, nunca sabrás qué lo arregló.

1) Base model mismatch (la más común y destructiva)

2) Mismatch de manejo de resolución (snapping a múltiplos / resize oculto)

3) Diferencias en semántica de steps/scheduler/guidance (los modelos de pocos steps son ultra sensibles)

4) Diferencias en semántica de seed/RNG (CPU vs GPU generator, seed global)

5) Diferencias en cómo se aplica la LoRA (adapter vs fuse/merge; loader incorrecto)

6) Prompt/negative/trigger no idénticos (un token puede romper la paridad)

7) Familia de pipeline incorrecta / faltan conditioning inputs (edit/control/I2V)

Ahora, cómo diagnosticar cada una rápidamente.

1) Base model mismatch: “se ve suficientemente parecido” no es suficientemente parecido

Síntomas

Deriva el look completo: rostros, textura, estilo, calidad de detalle.
Puede parecer que la LoRA “no se aplica” en absoluto.

Por qué pasa

Las LoRAs son muy específicas del modelo base. Entrenar en una variante exacta e inferir en otra (aunque sea “la misma familia”) suele producir una deriva grande.

Prueba rápida

Abre tu config/YAML de entrenamiento de AI Toolkit.
Encuentra el identificador/ruta exacta del modelo base.
Verifica que ComfyUI/Diffusers cargue el mismo base model (no uno con nombre parecido).

Trampas comunes

Mezclar variantes de FLUX (p.ej., dev vs schnell, 1 vs 2)
Mezclar Qwen Image generation vs Qwen Image Edit
Mezclar Z‑Image Turbo vs DeTurbo
Usar la familia de tarea incorrecta en WAN 2.2 (T2V vs I2V)

Arreglo

Trata el config de entrenamiento como fuente de verdad: elige el base model desde el YAML, no desde la memoria.

2) Mismatch de manejo de resolución: crees que es 1024, pero no lo es

Síntomas

Cambia la composición, cambia la nitidez, los detalles se “embarran”.
La deriva empeora en modelos turbo/de pocos steps.

Por qué pasa

Muchos stacks ajustan width/height a un divisor (a menudo 32). Si la preview de AI Toolkit “snapea” y tu stack no (o viceversa), no estás ejecutando el mismo tamaño de entrada.

Patrón típico:

width  = (width  // divisor) * divisor
height = (height // divisor) * divisor

Prueba rápida

Fuerza una resolución múltiplo de 32 (p.ej., 1024×1024, 1216×832).
En ComfyUI, busca nodos ocultos de resize/crop/latent scaling.

Arreglo

Para paridad, fija width/height a lo que la preview realmente usó (incluyendo reglas de snapping).

3) Diferencias de semántica de steps/scheduler/guidance: los modelos de pocos steps castigan los “hábitos SDXL”

Síntomas

El resultado se vuelve borroso/sucio y pierde la “nitidez de la preview”.
O se pasa de cocido y aparecen artefactos.

Por qué pasa

Los modelos destilados/turbo/de pocos steps suelen esperar pocos steps y guidance bajo (a veces guidance ≈ 1.0). Si usas defaults de SD/SDXL (steps 20–30, CFG 5–8), sales del régimen esperado.

Prueba rápida

Fuerza steps y guidance exactamente como el Training Sample.
No cambies schedulers mientras depuras paridad.

Arreglo

Parte de los settings del Training Sample como ground truth. Cuando puedas reproducir, recién ahí ajusta.

4) Diferencias de semántica de seed/RNG: mismo seed ≠ misma secuencia de ruido entre stacks

Síntomas

Mismo prompt + mismo seed, pero outputs muy distintos.

Por qué pasa

Los stacks implementan el seeding de forma diferente:

seed global vs seed por nodo
generator CPU vs GPU
consumo extra de RNG (random crops, jitter, etc.)

Prueba rápida

Primero asegura reproducibilidad dentro del mismo stack (3 corridas iguales).
Luego compara entre stacks.

Arreglo

Alinea el manejo de seeds lo más posible (seed global + semántica explícita del generator).

5) Diferencias al aplicar la LoRA: adapter vs fuse/merge (y “loader incorrecto”)

Síntomas

El efecto de la LoRA es más débil/más fuerte que en la preview.
O parece que la LoRA no se aplica.

Por qué pasa

Dos diferencias comunes:

Adapter: aplica la LoRA dinámicamente durante la inferencia con un scale.
Fuse/Merge: fusiona pesos en el modelo y descarga los adapters.

Pueden comportarse diferente. Además, usar un loader/pipeline que no corresponde a la familia del modelo puede “aplicar nada” silenciosamente.

Prueba rápida

Igualar el scale de la LoRA al del Training Sample.
Confirmar que el loader es el correcto para la familia del modelo (no mezcles pipelines entre familias).

Arreglo

Usa una implementación de referencia conocida para esa familia, reproduce el sample, y luego porta el método a tu stack.

6) Prompt / negative / trigger mismatch: un token puede romper la paridad

Síntomas

El estilo se siente cercano, pero faltan los “detalles firma”.
O se comporta como un base model genérico.

Errores frecuentes

El entrenamiento usó negative vacío, pero tu UI inyecta un negative por defecto.
Falta la palabra gatillo, está mal escrita o movida.
Diferente parsing de prompt/sintaxis de weights entre herramientas.

Prueba rápida

Deja el negative prompt vacío (como en training).
Copia/pega el prompt exacto del Training Sample.

Arreglo

Para probar paridad, elimina defaults ocultos. Primero corre “limpio”.

7) Familia de pipeline incorrecta / faltan conditioning inputs (edit/control/I2V)

Síntomas

La lógica del output es completamente incorrecta.
O la inferencia falla con error.

Por qué pasa

Algunas familias requieren inputs extra (control images, edit inputs, I2V conditioning). La preview puede estar usando ese wiring y tu run puede ser solo prompt.

Prueba rápida

¿El modelo requiere una imagen de control o input de edición?
¿Estás usando la familia de pipeline correcta para la tarea?

Arreglo

Cambia al pipeline correcto y provee los inputs requeridos.

¿No quieres debuggear? Consigue paridad de inferencia en RunComfy

¿No quieres perseguir la deriva de ComfyUI/Diffusers por tu cuenta? RunComfy ya ofrece pipelines de paridad de training e inference para las familias de modelos de AI Toolkit, así no tienes que reconstruir la pipeline exacta de la preview a mano.

Solo necesitas tu LoRA y el Training config (YAML) de tu run de AI Toolkit. Impórtalos en Trainer → LoRA Assets, y haz clic en Run (Run LoRA) para empezar de inmediato. RunComfy ejecuta el pipeline correcto del modelo base con el comportamiento crítico de paridad para que el resultado coincida con los training samples.

Workflow: AI Toolkit LoRA Training‑Inference Parity.

Así se ve en la práctica (Training Sample de AI Toolkit vs inferencia de RunComfy con el config aplicado):

AI Toolkit training sample	RunComfy inference (Playground/API)

¿Quieres ir más a fondo?

Open-source AI Toolkit inference code (pipelines Diffusers auditables, adapters, schedulers)

FAQ

“Mi LoRA de AI Toolkit funciona en Training Samples, pero no hace nada en ComfyUI.”

Empieza por base model mismatch y loader mismatch. La mayoría de reportes de “no hace nada” son:

variante incorrecta del modelo base
método/loader incorrecto para aplicar LoRA
negative prompt/defaults ocultos

“¿Por qué los Samples de AI Toolkit son más nítidos que mi output en Diffusers?”

Normalmente es una de estas:

mismatch de régimen steps/guidance (especialmente en modelos de pocos steps)
diferencias en snapping de resolución
diferencias de scheduler/timestep

“¿Cómo hago que la inferencia coincida con la preview de training de forma confiable?”

Trata el training config como ground truth y fija:

base model
width/height (incluyendo snapping)
familia de steps/guidance/scheduler
método y scale de aplicación de LoRA
semántica de seed

Si quieres esto como un workflow repetible de Run LoRA (Playground/API), construye la inferencia alrededor de ese mismo config.