Merging de modelos: SLERP, TIES, DARE y cuándo tiene sentido

La mayoría de los debates sobre personalización de LLM giran en torno al fine-tuning: recopilar datos, lanzar el entrenamiento, esperar horas o días, evaluar. Sin embargo, existe toda una categoría de técnicas que elude por completo ese ciclo: el model merging, es decir, la fusión de los pesos de varios modelos entrenados directamente en el espacio paramétrico, sin una sola iteración de entrenamiento. Sin entrenamiento en GPU, sin descenso de gradiente. Solo aritmética sobre pesos.

Suena a un atajo que no puede funcionar. En la práctica, funciona sorprendentemente bien — si se sabe cuándo y cómo usarlo. Este artículo explica los tres métodos principales (SLERP, TIES, DARE), en qué se diferencia el merging de la destilación y el ensembling, y cuáles son los beneficios y límites realistas para las empresas que se plantean un trabajo más avanzado con modelos open-weight.

Qué es el merging de modelos y qué no es

Antes de entrar en los métodos, una distinción importante:

El model merging combina los pesos de dos o más modelos con arquitectura y tokenizador compartidos directamente en el espacio paramétrico. El resultado es un único modelo cuyos pesos son, de algún modo, una combinación de los modelos fuente. No requiere datos de entrenamiento, ni GPU durante el merging en sí (solo RAM para cargar los pesos), ni gradiente.

La destilación es otra cosa: un modelo teacher de mayor tamaño genera respuestas sintéticas con las que se entrena un modelo student más pequeño. La destilación requiere entrenamiento — el merging, no. Estos enfoques pueden complementarse, pero no son intercambiables. Si le interesa la destilación, hay un artículo independiente dedicado a ella: Destilación de modelos.

El ensemble es también un enfoque distinto: varios modelos corren en paralelo durante la inferencia y sus salidas se combinan mediante votación o agregación por promedio. El ensemble es más costoso en inferencia (se ejecutan varios modelos), mientras que el merging produce un único modelo con la carga de inferencia habitual.

El merging ocupa por tanto una categoría completamente propia: combina capacidades sin costes de entrenamiento, a cambio de una mayor imprevisibilidad del resultado.

¿Por qué funciona el merging?

La intuición detrás del merging parte de la observación de que los modelos con la misma arquitectura entrenados desde el mismo (o similar) modelo base tienen los pesos en un espacio similar. El fine-tuning en el dominio A desplaza los pesos en una dirección; el fine-tuning en el dominio B, en otra. La combinación lineal de esos desplazamientos captura en principio ambas capacidades — siempre que no se anulen mutuamente.

Ese «siempre que» es el núcleo del problema al que se dedican los métodos más avanzados como TIES y DARE.

Los tres métodos principales

SLERP — interpolación esférica

SLERP (Spherical Linear Interpolation) es el método más sencillo y más antiguo. Se usaba originalmente para interpolar rotaciones en gráficos 3D; en el contexto de modelos se aplica a los vectores paramétricos.

En lugar de promediar de forma lineal ((pesos_A + pesos_B) / 2), SLERP interpola por el arco geodésico sobre la superficie hipersférica del espacio paramétrico. El resultado preserva mejor las diferencias en las direcciones de los pesos que un promedio lineal directo.

En la práctica: - Funciona exclusivamente con dos modelos — no con tres o más. - Un único parámetro t (0.0 = puramente modelo A, 1.0 = puramente modelo B, 0.5 = punto medio) controla la «cercanía» del resultado. - El resultado es sensible a la elección de t — el valor óptimo varía según el par de modelos. - Es adecuado para «suavizar» sutilmente la diferencia entre dos fine-tunes (por ejemplo, un modelo mejor en estilo y otro mejor en hechos).

TIES — tratamiento de la interferencia

TIES (Trim, Elect Sign, Disjoint Merge) aborda el problema que SLERP ignora: cuando se combinan varios fine-tunes de forma naïve, sus cambios en el espacio paramétrico pueden contradecirse — algunos parámetros se desplazan positivamente en el modelo A y negativamente en el modelo B, de modo que al promediar se anulan y la capacidad global se pierde.

TIES lo resuelve en tres pasos:

1. 1.Trim — poda de cambios pequeños: se conservan solo los mayores deltas de parámetros (desviaciones respecto al modelo base). Los cambios pequeños son en su mayoría ruido.
2. 2.Elect Sign — elección de dirección: para cada parámetro se determina por votación la dirección dominante del cambio a lo largo de los modelos. Los modelos que votan en la dirección minoritaria se ignoran para ese parámetro.
3. 3.Disjoint Merge — fusión: cada parámetro recibe contribuciones solo de los modelos que han superado los pasos anteriores.

TIES funciona con tres o más modelos, lo que lo hace adecuado para construir modelos «políglotas» a partir de varios fine-tunes de dominio. A cambio de una mayor complejidad de configuración.

DARE — reducción de redundancia

DARE (Drop And REscale) aborda el problema de otra forma: antes de la fusión, «descarta» aleatoriamente (pone a cero) una gran proporción de los deltas de parámetros de cada modelo — típicamente el 80–90 % de ellos — y reescala los restantes proporcionalmente. La intuición: la mayoría de los deltas son redundantes o perturbadores; conservar solo una pequeña proporción con reescalado produce un resultado comparable o mejor.

DARE se combina en la práctica con TIES (DARE+TIES): DARE reduce el ruido en cada modelo fuente antes de que TIES aplique su lógica de reducción de interferencias. Esta combinación está disponible en mergekit como una de las estrategias preconfiguradas.

Task Arithmetic y otras variantes

mergekit y la comunidad investigadora implementan también otros métodos:

• Task Arithmetic: suma de «task vectors» (delta desde el modelo base) con ponderación — base simple de la que parten TIES y DARE.
• Passthrough: algunas capas se toman directamente de un modelo y otras del segundo — método no objetivo, pero a veces sorprendentemente eficaz cuando los modelos tienen partes de diferente fortaleza.

mergekit — la herramienta que lo une todo

Para el uso práctico, `mergekit` es el estándar de facto. Se configura mediante archivos YAML, lo que facilita la reproducibilidad y el versionado de recetas. Ejemplo de configuración mínima para SLERP:

merge_method: slerp
base_model: meta-llama/Llama-3-8B
models:
  - model: ./my-finetune-A
  - model: ./my-finetune-B
parameters:
  t: 0.5
dtype: bfloat16

mergekit es capaz de realizar la mayoría de los merges en CPU con RAM suficiente (para modelos de 7B en BF16, del orden de 30–40 GB de RAM, sin necesidad de VRAM). El merge en sí se completa en minutos.

La función relativamente nueva tokensurgeon permite el transplante de pesos entre tokenizadores distintos — lo que abre la posibilidad de fusionar modelos de familias diferentes (por ejemplo, Qwen y Llama), aunque con una previsibilidad del resultado notablemente menor y la necesidad de una evaluación exhaustiva.

Para quienes no quieren ajustar parámetros manualmente: existe también el merging evolutivo (Mergenetic y herramientas similares), donde la receta óptima se busca automáticamente mediante algoritmos evolutivos — el merging se ejecuta decenas de iteraciones con diferentes combinaciones de parámetros, y cada iteración se evalúa sobre un pequeño conjunto de benchmarks. Este método es más lento (horas en lugar de minutos), pero reduce la dependencia de la intuición experta.

Cuándo tiene sentido el merging

En la práctica, el merging está justificado en varias situaciones concretas:

Combinación de capacidades de varios fine-tunes. Tiene un modelo fine-tuneado en comunicación con clientes y otro en documentación técnica. Quiere un único modelo que domine ambas. En lugar de reentrenar con datos mezclados, pruebe el merge — si las capacidades no están en conflicto, el resultado puede ser comparable.

Exploración acelerada en fase temprana. Antes de invertir horas de entrenamiento en cada combinación de hiperparámetros y mezclas de datos, el merging le permite explorar rápidamente el espacio de posibilidades. Unos cuantos merges desde checkpoints existentes cuestan menos que varios ciclos de entrenamiento.

Alternativa con recursos de entrenamiento limitados. Si no dispone de capacidad GPU para más entrenamiento, pero tiene varios modelos parcialmente especializados, el merging es una alternativa legítima.

Ajuste fino de estilo. SLERP con un valor t más cercano a uno de los lados le da un modelo que «presta un poco más de atención» a las características de uno de los fine-tunes — que puede ser todo lo que necesita para lograr el tono deseado.

Cuándo el merging no tiene sentido

Igual de importante es saber cuándo no intentarlo:

Distribuciones de entrenamiento muy diferentes. Cuanto más difieren las distribuciones de datos y los objetivos de los modelos fuente, mayor es la probabilidad de interferencia. Un merge entre un modelo entrenado en contratos jurídicos y otro entrenado en poesía probablemente no tendrá sentido — ambos fine-tunes tiran de los pesos en direcciones muy distintas.

Arquitecturas o tokenizadores diferentes (sin tokensurgeon). El merging asume una arquitectura idéntica y el mismo tokenizador — de lo contrario no existe un espacio paramétrico consistente en el que interpolar.

Cuando se necesita una mejora predecible. El merging es experimental. No siempre funciona. El resultado debe evaluarse siempre sobre sus benchmarks concretos — sin evaluación no se sabe si el modelo ha empeorado. Si su proyecto exige garantías, recurra al fine-tuning estándar, cuyo resultado es replicable y controlable. La cuestión de medir la calidad de los cambios de fine-tuning se aborda en el artículo Cómo medir si el fine-tuning ha ayudado.

Entornos regulados. En contextos de medicina, derecho o finanzas, el merging sobre un modelo de producción es más arriesgado que el fine-tuning, por la menor auditabilidad. No puede demostrar con qué datos fue entrenado el modelo resultante. Para sectores regulados, recomendamos el merging únicamente como herramienta para experimentos internos, no como vía hacia un modelo de producción.

Riesgos y limitaciones

Degradación en la cola larga. El merging suele evaluarse sobre benchmarks populares. En casos extremos específicos de su dominio, el modelo resultante puede fallar de formas que los benchmarks simples no capturan.

Dispersión de calidad. El mismo método con diferentes pares de modelos produce resultados dramáticamente distintos. Una receta que funcionó para un par de fine-tunes puede no funcionar para otro.

Resultado no controlado desde el punto de vista de seguridad. Los modelos fusionados pueden heredar comportamientos inadecuados de uno de los modelos fuente si este no estaba suficientemente alineado (aligned). Esto es especialmente importante cuando se fusionan modelos de diferentes entrenadores.

El merging SLERP/TIES no es «siempre seguro» — en el sentido de que el modelo resultante puede no conservar todas las propiedades deseables de los fuente. El resultado debe evaluarse siempre. Si quiere evitar las trampas más frecuentes al experimentar con fine-tuning en general, lea 7 razones por las que el fine-tuning falla en la práctica.

Merging vs. fine-tuning: cuándo qué

Un marco de decisión sencillo:

• ¿Tiene al menos dos fine-tunes existentes del mismo modelo base y quiere explorar la combinación? → Pruebe el merge primero.
• ¿Necesita un modelo con conocimiento de dominio concreto que ninguno de sus fine-tunes tiene? → Fine-tuning sobre nuevos datos.
• ¿Necesita garantía de calidad y auditabilidad en un entorno regulado? → Fine-tuning con datos documentados.
• ¿Quiere una exploración rápida antes de invertir en entrenamiento? → El merge es una sonda de entrada legítima.
• ¿Trabaja con arquitectura MoE (Llama 4, Qwen3 MoE)? → El merging es mucho más complejo, el soporte de herramientas es menos maduro — verifique antes de invertir.

El merging no es un sustituto del fine-tuning. Es una herramienta complementaria en el toolbox del ingeniero de ML avanzado — valiosa exactamente allí donde el entrenamiento sería innecesariamente costoso para preguntas exploratorias. La relación entre fine-tuning y merging es similar a la que existe entre LLM locales y cloud: ambos tienen su lugar, todo depende del contexto.

Procedimiento práctico para el primer intento

Si quiere probar el merging:

1. 1.Empiece con dos fine-tunes del mismo modelo base, ambos con calidad documentada en sus benchmarks.
2. 2.Instale mergekit, escriba la configuración YAML para SLERP con t=0.5.
3. 3.Ejecute el merge (corre en CPU, requiere decenas de GB de RAM, sin GPU).
4. 4.Evalúe el resultado sobre los mismos benchmarks que los modelos fuente — sin evaluación no sabe nada.
5. 5.Si el resultado es prometedor, experimente con diferentes valores de t o pase a TIES para más modelos.
6. 6.Solo si la evaluación confirma la calidad → use en producción.

Preguntas frecuentes

¿Es el merging un sustituto del fine-tuning?

No. El merging asume que dispone de al menos un fine-tune de calidad — trabaja sobre los resultados del entrenamiento existente, no lo reemplaza. Si no existe ningún fine-tune, el merging no tiene nada con lo que trabajar.

¿Cuánta RAM necesito para hacer merge de modelos de 7B?

Para modelos de 7B en BF16, aproximadamente 30–40 GB de RAM en CPU. No se necesita VRAM — el merge se realiza en CPU en unos pocos minutos. Para modelos de 13B, cuente aproximadamente el doble.

¿En qué se diferencia DARE del pruning aleatorio de pesos?

El pruning elimina parámetros de forma permanente con el objetivo de reducir el tamaño del modelo. DARE elimina parámetros delta (desviaciones respecto al modelo base) antes del merging con el objetivo de reducir el ruido de interferencia — el modelo resultante tiene el mismo número de parámetros que los modelos fuente. Son motivaciones fundamentalmente distintas.

¿Funciona el merging para modelos MoE (Llama 4, Qwen3 MoE)?

Técnicamente de forma parcial — mergekit está añadiendo soporte, pero las arquitecturas MoE son notablemente más complejas: además de los pesos de los expertos hay que gestionar también los parámetros del router. Los resultados son más imprevisibles que con modelos densos y el soporte de herramientas aún está evolucionando. Recomendamos verificar primero el estado actual de la documentación de mergekit para la arquitectura concreta.

¿Puedo resolver el problema del olvido catastrófico con un merge?

Parcialmente — si dispone de un checkpoint antes del olvido y otro tras el fine-tuning, el merge entre ellos puede mitigar la regresión de las capacidades generales. Esta es una técnica legítima, pero no un sustituto fiable de los datos de replay o los enfoques de regularización durante el propio fine-tuning.

*Si está considerando trabajar con sus propios modelos fine-tuneados y no sabe por dónde empezar — ya sea la elección del método, la preparación de datos o el merging — nos encantará revisar su caso concreto. En MP Industrial Solutions hemos recorrido este proceso con varios clientes de fabricación e ingeniería y sabemos dónde están los escollos reales.*