Fusionar LoRAs vs apilar

TL;DR

• Fusión combina varias matrices de pesos de LoRA en un solo adaptador antes de la inferencia: un solo pase adelante, menor huella de VRAM, generación más rápida.
• Apilamiento carga cada LoRA por separado y suma sus contribuciones en cada pase adelante — preserva optimizaciones individuales pero usa más memoria y cómputo.
• Fusión cuando: necesitas simplicidad de despliegue, límites estrictos de VRAM o un único archivo distribuible. Apilamiento cuando: la calidad por adaptador es lo más importante y puedes asumir la sobrecarga.
• Coste de calidad: fusionar puede perder adaptaciones de gran detalle porque cada LoRA se entrenó de forma independiente; no se garantiza un óptimo global.

Qué significan realmente "Fusión" y "Apilamiento"

Un adaptador LoRA es un par de matrices de bajo rango (lora_down y lora_up, o A y B) que representa un cambio en la matriz de pesos de un modelo base: ΔW = B × A. El rango r es mucho menor que las dimensiones originales, manteniendo el adaptador pequeño — una pequeña fracción del tamaño del modelo base.

Enfoque | Qué sucede | Archivos en inferencia | Source

|----------|--------------|------------------------|--------|

Apilamiento | Cada LoRA permanece separada; cada pase adelante aplica la actualización de cada adaptador y las suma | Varios archivos .safetensors | Diffusers merge_loras | Fusión | Todos los adaptadores se combinan en un solo LoRA nuevo (o se hornean en el checkpoint) | Un único .safetensors o checkpoint horneado | kohya-ss merge_lora.py |

La mayoría de las interfaces (Automatic1111, ComfyUI, Forge) usan apilamiento por defecto — cargas varias LoRAs, asignas un peso a cada una y el software las aplica todas en tiempo de ejecución. El fusionador base de AUTOMATIC1111 implementa la fórmula de suma ponderada (1−α)A + αB que muchas herramientas reutilizan AUTOMATIC1111 merger. La fusión es un paso explícito fuera de línea usando herramientas como merge_lora.py de kohya-ss, la extensión Supermerger Civitai #1540, o add_weighted_adapter() de PEFT.

Cómo difiere la matemática de los pesos

Una sola LoRA

Para una matriz de pesos base W₀ ∈ ℝ^(d×k), una LoRA añade:

W = W₀ + (α / r) · B A

donde B ∈ ℝ^(d×r), A ∈ ℝ^(r×k), r ≪ min(d,k), y α es una constante de escalado de entrenamiento. Una fuerza de tiempo de ejecución s modula aún más el efecto:

W = W₀ + s · (α / r) · B A

Esta es una adición lineal — los pesos base nunca cambian en disco. El artículo original de LoRA confirma la formulación de fusión en el despliegue con coste de latencia cero arXiv:2106.09685.

Apilamiento vs Fusión

Apilamiento aplica la actualización de cada adaptador de forma independiente y las suma en tiempo de ejecución. La estructura de rango de cada adaptador se preserva: una LoRA de personaje de rango 16 y una LoRA de estilo de rango 32 mantienen cada una su descomposición original.

Fusión colapsa los adaptadores en un par de matrices antes de la inferencia. Para una suma ponderada de LoRAs con ratios w_i:

W_merged = W₀ + Σᵢ [ w_i · (α_i / r_i) · B_i A_i ]

merge_lora.py de kohya-ss implementa esto concatenando las matrices B a lo largo de la dimensión de salida y las A a lo largo de la dimensión de entrada, escalando cada una por alpha / dim × ratio kohya-ss merge_lora.py. Supermerger añade control por bloque — diferentes ratios de fusión para distintos bloques U-Net — pero la matemática subyacente es la misma suma ponderada Supermerger README.

Incorporación en el checkpoint

Doblar la LoRA fusionada directamente en el modelo base (W_final = W₀ + ΔW_merged) produce un checkpoint estándar con cero sobrecarga de adaptador. Esto es lo que hace "Merge to Checkpoint" de Supermerger y merge_to_sd_model() de kohya-ss — el modelo es el modelo adaptado.

Cuándo la fusión supera al apilamiento

VRAM y memoria. Cada LoRA apilada carga sus matrices en la memoria de la GPU junto al modelo base. Los modelos fusionados o horneados tienen un solo conjunto de matrices de adaptador (o ninguna). Con VRAM limitada y varias LoRAs, la fusión suele evitar errores de memoria insuficiente (OOM).

Latencia de inferencia. Apilar significa n multiplicaciones de matriz adicionales por capa objetivo por paso. Fusionar significa una sola. En muchos pasos, el ahorro se acumula — especialmente con torch.compile.

Despliegue. Un único archivo .safetensors o un checkpoint horneado es trivial de compartir y cargar en producción. No hay lógica de gestión de adaptadores, ni código de programación de pesos.

Compilación y cuantización. torch.compile y la cuantización (bitsandbytes, AWQ, GPTQ) funcionan mejor en gráficos estáticos. Las LoRAs apiladas introducen flujo de control dinámico que puede desencadenar recompilaciones; un modelo fusionado es un nn.Module sencillo.

El coste de calidad al colapsar adaptadores

Por qué la fusión puede degradar los resultados

Cada LoRA se entrena de forma independiente. Al fusionar con una suma ponderada simple, asumes que la adaptación combinada óptima es una combinación lineal de los óptimos individuales. Ni esto ni la no interferencia de los subespacios de rango está garantizada. Empíricamente, las LoRAs fusionadas a veces diluyen conceptos distintos — una LoRA de personaje y una LoRA de estilo fusionadas pueden producir un personaje que casi se ve bien pero le faltan las firmas nítidas del estilo.

La documentación de Supermerger reconoce que la opción "SAME TO STRENGTH" (tomar √ratio durante la fusión) es necesaria para que el resultado fusionado coincida con el comportamiento en tiempo de ejecución — la suma ponderada ingenua no preserva la semántica de escalado por adaptador Supermerger README.

Cuándo el apilamiento preserva mejor la calidad

El apilamiento aplica cada adaptador a su fuerza nativa, entrenada, modulada solo por el peso de tiempo de ejecución del usuario. La geometría interna de cada adaptador permanece intacta, por lo que los subespacios limpios para diferentes conceptos pueden coexistir sin el promedio que impone la fusión.

Guía práctica

Escenario | Recomendado

|----------|-------------|

1–2 LoRAs, VRAM abundante, calidad crítica | Apilar | 3+ LoRAs, VRAM ajustada, o despliegue en producción | Fusionar o hornear | LoRAs que tienen como objetivo regiones distintas del modelo | Apilar — baja interferencia | LoRAs que tienen como objetivo las mismas capas (p. ej., dos LoRAs de personaje) | Probar ambos; la fusión suele diluir la identidad | Se necesita control por bloque | Fusión de Supermerger con pesos por bloque |

Comparativa de herramientas

Herramienta | Tipo de fusión | Pesos por bloque | Hornear en checkpoint | Source

|----------|--------------|-------------------|----------------------|--------|

merge_lora.py de kohya-ss | Suma ponderada, concat | No | Sí | kohya-ss merge_lora.py | Supermerger (A1111) | Suma ponderada, Sum Twice, Add Diff, Cosine | Sí (20 SDXL) | Sí | Supermerger README | add_weighted_adapter() de PEFT | Suma ponderada, TIES, DARE | No | Vía merge_and_unload() | PEFT LoRA guide | set_adapters() de Diffusers | Solo apilamiento en tiempo de ejecución | No | Vía fuse_lora() | Diffusers merge_loras |

TIES y DARE (PEFT) podan pesos pequeños y resuelven conflictos de signo antes de promediar. Pueden aplicarse a matrices LoRA, pero la evidencia específica de adaptadores es escasa — trátalas como experimentales.

Errores comunes y soluciones

Síntoma | Causa probable | Solución

|---------|--------------|-----|

Imágenes rotas o grises tras fusionar LoRA | Modelos base incompatibles (SD1.5 en SDXL) | Verifica que todas las LoRAs compartan la misma arquitectura base | Caída de calidad tras fusionar dos LoRAs de personaje | Colisión de rango — los adaptadores compiten por el mismo subespacio | Apila en su lugar, o entrena una única LoRA multipersonaje | merge_lora.py "weights shape mismatch" | Diferentes rangos sin modo concat | Usa el flag --concat o asegura dim/alpha idénticos | Checkpoint horneado pierde adaptaciones del codificador de texto | LoRAs del codificador de texto omitidas de la fusión | Asegura que las LoRAs del codificador de texto estén en la lista de entrada | "SAME TO STRENGTH" difiere de la fuerza en tiempo de ejecución | √ratio en la fusión vs escalado lineal en tiempo de ejecución | Elige un flujo de trabajo y mantente consistente |

Preguntas frecuentes (FAQ)

¿Cuándo produce mejores resultados la fusión que el apilamiento? La fusión no produce inherentemente mejor calidad — intercambia calidad por eficiencia. Gana cuando las limitaciones de VRAM, velocidad o despliegue importan más que la fidelidad por adaptador.

¿Cómo afecta la fusión a la calidad en comparación con el apilamiento? La fusión promedia las actualizaciones de bajo rango, lo que puede diluir los límites de concepto. El apilamiento preserva la geometría de cada adaptador pero añade sobrecarga de inferencia. La brecha es mayor cuando los adaptadores tienen como objetivo las mismas capas.

¿Cómo elijo entre fusionar LoRAs o apilarlas? Empieza con apilamiento. Si llegas a OOM, límites de latencia o restricciones de despliegue, fusiona con kohya-ss o Supermerger. Prueba ambos lado a lado — la diferencia depende del caso.

Lectura adicional

• Cómo funcionan las LoRAs — mecanismo, fuerza, apilamiento y emparejamiento con modelos base
• Herramientas de fusión de modelos — comparación completa de herramientas de fusión incluyendo DARE, TIES y pesos por bloque
• Gestión de la librería de LoRAs — organización, versionado y uso compartido de adaptadores