Comparación de Checkpoint y LoRA con Seed Fijo
Metodología práctica para comparar modelos Stable Diffusion con justicia — controle las variables y lea los grids con honestidad.
On this page
Comparación de Checkpoint y LoRA con Seed Fijo
TL;DR
- El card de prueba izolight exige parámetros fijos en todas las evaluaciones — seed, sampler, steps, CFG, resolución y VAE deben ser idénticos para cada prueba de checkpoint/LoRA. Para más contexto sobre extracción de trigger words de LoRA, el node de ComfyUI es la fuente autoritativa.
- v3 usa LoRA Auto Trigger — las tags canónicas se extraen automáticamente de la API de Civitai o de los metadatos del modelo.
- v2 cambia a conditionings promedio — para las categorías Portrait y Close-up, el node
ConditioningAveragede ComfyUI mezcla embeddings de texto en lugar de concatenar prompts. - 30 LoRAs probadas — cubriendo Lava Style, Liquid Flow, Chrome Style, Bubblegum y otras categorías de estilo. Vea también nuestra guía de workflow ComfyUI.
El artículo de izolight abre con una referencia directa: "A few days ago I stumbled upon a reddit post with a model testing card" enlazando a r/StableDiffusion [[1]](https://civitai.com/articles/4474). Ese post (r/StableDiffusion/comments/1b39b07) es la semilla de toda la metodología.
El autor construyó una implementación en ComfyUI con dos mejoras explícitas sobre el concepto de Reddit:
- Parámetros controlados centralmente — "I decided to improve this a bit with centrally controlled parameters for the generation" [[1]](https://civitai.com/articles/4474)
- Soporte para LoRA y Lightning LoRA — "...and support for LoRA and Lightning LoRA" [[1]](https://civitai.com/articles/4474)
El workflow resultante coloca "all the input parameters on the left side with the final output (as a preview that can be saved) there too" [[1]](https://civitai.com/articles/4474). Este layout mantiene visible la superficie de control mientras el grid de comparación renderiza.
Núcleo Metodológico: Un Conjunto de Parámetros, Muchos Modelos
El principio central: toda variable que pueda afectar la salida debe bloquearse de forma idéntica en todas las celdas de prueba. Para un tratamiento más profundo, vea evaluación de checkpoint SDXL.
Lo que el Card Realmente Probó
El workflow evaluó tres checkpoints SDXL, todos usando los mismos parámetros de generación:
| Checkpoint | Base | Versión | Parámetros Principales | Source |
|---|---|---|---|---|
| Realities Edge XL | SDXL Lightning | V7 (BakedVAE) | CFG 7, steps 25, DPM++ 2M SDE, seed 1 | https://civitai.com/images/7804518 |
| Juggernaut XL | SDXL | V9 + RunDiffusionPhoto 2 | CFG 7, steps 25, DPM++ 2M SDE, seed 1 | https://civitai.com/images/7804589 |
| Albedo Base XL | SDXL | V2.1 | CFG 7, steps 25, DPM++ 2M SDE, seed 1 | https://civitai.com/images/7805074 |
Los metadatos de generación de cada modelo confirman valores idénticos: cfgScale:7, steps:25, sampler:DPM++ 2M SDE, seed:1 [[2]](https://civitai.com/images/7804518) [[3]](https://civitai.com/images/7804589) [[4]](https://civitai.com/images/7805074). Los tres usan la arquitectura SDXL-base — confirmado por sus parámetros consistentes en todas las muestras publicadas.
Suite de Pruebas de LoRA
Las 30 LoRAs abarcan categorías de estilo desde Lava Style hasta Chrome Style, cubriendo:
- Estilos artísticos: Lava Style, Liquid Flow Style, Chocolate Wet Style, Midas Magic Grimoire, Tempest Magic Grimoire, Hedgerow Style, Wooden Blocks Style, Cardboard, Dataviz, Dippers Style
- Estilos técnicos/efectos: Clockwork/Steampunk, Wisp Elementals, Gaelic/Celtic Patterns, Eldritch Palette Knife Painting, GlowNeon, KaleidoShatter, Lelo, Line Art, Mechanarion
- Estilos avanzados/compuestos: Neo Futuristic Tech, Animal Exoskeleton Style, Ember Glut Style, Bling Style, Extinction/fading, Bubblegum Style, Carbon Fiber Style, Chrome Style
Cada una se probó con inyección automática de trigger words vía el node LoRA Auto Trigger [[1]](https://civitai.com/articles/4474).
Detalle Técnico: Arquitectura del LoRA Auto Trigger
El proyecto LoRA Auto Trigger es un fork de Extraltodeus/LoadLoraWithTags y agrega soporte para LoRAs apiladas de jags111/efficiency-nodes-comfyui [[5]](https://github.com/idrirap/ComfyUI-Lora-Auto-Trigger-Words). Extrae trigger words de dos fuentes:
- API de Civitai — para modelos alojados en Civitai
- Metadatos de entrenamiento del modelo — incrustados en archivos
.safetensorscuando están disponibles
Este enfoque de doble fuente garantiza cobertura incluso para LoRAs distribuidas fuera de Civitai. El node retorna tanto civitai_tags_list como meta_tags_list como listas de Python, que pueden filtrarse y ponderarse vía el node TagsSelector [[5]](https://github.com/idrirap/ComfyUI-Lora-Auto-Trigger-Words). Esto da flexibilidad en la selección de trigger words para cada tipo de LoRA.
Evolución de Versión: Tres Iteraciones
v1 — Línea Base con Parámetros Controlados Centralmente
El lanzamiento inicial estableció la arquitectura central: un solo workflow ComfyUI donde todos los parámetros de generación se definen una vez y se propagan a cada celda. Esto eliminó la fuente más común de artefactos de comparación — el drift de parámetros entre celdas.
v2 — De Concatenación a Conditionings Promedio
El manejo original de prompts concatenaba strings de texto: "portrait of a woman" + "soft window light". Esto creaba una única secuencia de tokens donde la atención podía diluirse entre conceptos no relacionados.
La v2 introdujo conditionings promedio para las categorías Portrait y Close-up [[1]](https://civitai.com/articles/4474). El node ConditioningAverage de ComfyUI computa embeddings de texto separados para cada componente del prompt, luego los mezcla en un único vector antes de alimentar el U-Net. Esto preserva la dirección semántica de cada prompt mientras evita penalidades de longitud de token.
Nota: El artículo menciona el cambio pero no explica el mecanismo. Lo descrito arriba es el comportamiento estándar del ConditioningAverage de ComfyUI.
v3 — Inyección Automatizada de Trigger Words
La v3 implementó LoRA Auto Trigger [[1]](https://civitai.com/articles/4474) [[5]](https://github.com/idrirap/ComfyUI-Lora-Auto-Trigger-Words). En lugar de trigger words manuales, el node extrae tags canónicas de dos fuentes: API de Civitai y metadatos de entrenamiento .safetensors.
Por qué esto importa: Al comparar LoRAs lado a lado, la inconsistencia manual de trigger words introduce sesgo. Una LoRA recibe su trigger canónico exacto; otra recibe un trigger con error o omitido. Auto-trigger estandariza lo que activa cada LoRA, aislando el modelo en sí como única variable.
Errores comunes y soluciones
| Error | Causa | Corrección |
|---|---|---|
| Las celdas producen composiciones totalmente diferentes | La seed varía entre celdas | Bloquee una única seed en todas las celdas; el card izolight usa seed 1 [[2]](https://civitai.com/images/7804518) |
| Una LoRA no muestra efecto visible | Trigger word ausente o con error | Use LoRA Auto Trigger (v3) para inyectar tags canónicas de la API Civitai o metadatos [[5]](https://github.com/idrirap/ComfyUI-Lora-Auto-Trigger-Words) |
| Prompts de portrait diluyen detalles del sujeto | La concatenación de prompts crea penalidades de longitud de token | Cambie a ConditioningAverage para mezclar prompts (comportamiento v2) [[1]](https://civitai.com/articles/4474) |
| Los resultados varían entre corridas de prueba | Sampler, steps o CFG difieren por modelo | Defina los parámetros centralmente una vez; propague a todas las celdas |
| VAE distinto altera los colores | VAE diferente por checkpoint | Use el VAE baked de cada checkpoint; mantenga todos los demás parámetros idénticos |
FAQ
¿Cómo comparar dos checkpoints Stable Diffusion con justicia?
Bloquee toda variable que pueda afectar la salida: seed, sampler, steps, CFG, resolución y VAE. Use el mismo conjunto de prompts en ambos modelos. El card de prueba izolight impone esto vía parámetros controlados centralmente [[1]](https://civitai.com/articles/4474).
¿Qué parámetros deben mantenerse constantes al comparar LoRAs?
Seed, sampler, steps, CFG, resolución, VAE y checkpoint base. Las trigger words también deben estandarizarse vía LoRA Auto Trigger (v3) para evitar el sesgo de inconsistencia manual [[5]](https://github.com/idrirap/ComfyUI-Lora-Auto-Trigger-Words).
¿Por qué usar una seed fija para grids de comparación de modelos?
Una seed fija elimina la varianza estocástica entre celdas, entonces las diferencias visuales pueden atribuirse al modelo en lugar de ruido aleatorio. El card izolight usa seed 1 en todas las muestras publicadas [[2]](https://civitai.com/images/7804518).
¿Qué es average conditioning vs concatenación en ComfyUI?
La concatenación une strings de prompt en una secuencia de tokens; average conditioning (el node ConditioningAverage) computa embeddings separados para cada componente del prompt, luego los mezcla en un único vector. La v2 del card usa promedio para las categorías Portrait y Close-up [[1]](https://civitai.com/articles/4474).
¿Cómo funciona LoRA Auto Trigger?
El node extrae trigger words canónicas de la API de Civitai (para LoRAs alojadas en Civitai) y de los metadatos de entrenamiento .safetensors. Retorna civitai_tags_list y meta_tags_list como listas de Python filtrables. Un fork de Extraltodeus/LoadLoraWithTags con soporte para LoRAs apiladas de jags111/efficiency-nodes-comfyui [[5]](https://github.com/idrirap/ComfyUI-Lora-Auto-Trigger-Words).
Lo que la Fuente No Revela
Incluso con un card de prueba detallado, quedan brechas metodológicas:
- Contenido de los prompts — los prompts están incrustados en el adjunto SVG/JSON (no accesible públicamente). El artículo nota que "better prompts for photo/anime comparison" podrían mejorar la variedad [[1]](https://civitai.com/articles/4474).
- Layout del grid — el adjunto codifica el mapeo de celdas, pero el artículo no describe la cantidad de filas/columnas ni la asignación de checkpoint/LoRA.
- Cantidad de seeds — solo seed 1 aparece en los metadatos publicados. Seeds adicionales pueden o no haber sido probadas por celda.
- Detalles de Lightning LoRA — el artículo menciona el soporte pero no explica cómo la evaluación de Lightning LoRA difiere de LoRA estándar.
- Racional de selección de modelos — los tres son modelos SDXL fotorrealistas; los criterios de selección no están especificados.
- Post original de Reddit — el post r/StableDiffusion retornó solo un SVG de verificación al accederlo; el contenido del post no pudo leerse.
Trampas Comunes de Evaluación vs. Diseño del Card
Estas trampas son ampliamente reconocidas en la comunidad Stable Diffusion. El card aborda varias mediante su diseño:
| Trampa | Corrección del Card |
|---|---|
| Seeds diferentes por celda | Seed única fija propagada a todas las celdas |
| Samplers/steps/CFG diferentes por modelo | Parámetros controlados centralmente |
| Inconsistencia manual de trigger words | LoRA Auto Trigger (v3) |
| Veredicto de prompt único | Múltiples categorías de prueba (Portrait, Close-up, etc.) |
| VAE distinto | Cada checkpoint usa su VAE baked; parámetros idénticos en lo demás |