Model Merging for Fine-Tuned LLMs: SLERP, TIES and DARE

What model merging actually solves

Say you have fine-tuned the same base model twice: once on a coding dataset, once on a customer-support transcript set. Each fine-tune is good at its own job and mediocre at the other. The obvious fix is to deploy both and route requests between them, but that means two GPUs, two sets of weights to keep patched, and a routing layer to maintain. Model merging offers a third option — combine the two sets of fine-tuned weights into a single checkpoint that inherits capability from both, with no additional training run.

The idea rests on a simple observation: a fine-tune is just its base model plus a delta, usually called a task vector — the difference between the fine-tuned weights and the pre-trained weights they started from. If two fine-tunes share the same base, their task vectors live in the same weight space, and you can add, average or selectively combine those vectors directly, with no forward or backward pass through training data required. That is the entire trick: merging is arithmetic on already-trained weights, not a new training job.

It is worth being precise about what merging is not. It is not ensembling, where you keep every model intact, run them all at inference time and vote or average their outputs — ensembling gets you the best-of-both-worlds ceiling but pays full compute for every model in the ensemble, every request. Merging collapses everything into one set of weights up front, so you pay single-model inference cost forever afterwards, at the price of a training-free but slightly blunter combination. It is also not multi-LoRA serving, where you keep separate lightweight adapters and hot-swap the right one onto a shared base model per request — that keeps each task vector fully intact and lets you add or remove capabilities without re-merging anything, at the cost of routing logic and a model server that supports it. We come back to that trade-off in the final section.

Why bother, then, instead of just shipping whichever single fine-tune scores best on your primary task? Two reasons come up repeatedly in practice. First, a merge can genuinely exceed each of its inputs — when two task vectors point in compatible directions, combining them can reinforce shared structure rather than just splitting the difference, which is why merged models sometimes top leaderboards their source models could not reach individually. Second, and more mundanely, a lot of real teams end up with a small pile of fine-tune checkpoints from different experiments — one tuned for tone, one for a specific tool-calling format, one for a regional dialect or compliance phrasing — and merging is the cheapest way to find out whether those checkpoints compose into something better than any one of them, before you commit to a full retraining run that combines the underlying data.

How SLERP, TIES and DARE actually work

MergeKit — the open-source toolkit from Arcee AI that has become the de facto standard for this work — implements more than a dozen merge methods, but three cover the vast majority of real use cases and are worth understanding properly rather than treating as a dropdown menu.

SLERP — Spherical Linear Interpolation

SLERP interpolates between exactly two models along the surface of a hypersphere rather than along a straight line. The reason this matters: in high-dimensional weight space, straight-line (linear) interpolation between two independently trained vectors tends to shrink the resulting vector's norm, because averaging two vectors that point in only loosely correlated directions pulls the result toward the origin. SLERP instead walks along the arc connecting the two normalised vectors, preserving each layer's weight magnitude and, empirically, producing smoother, better-behaved merges than plain averaging. A single parameter, conventionally called t, controls the interpolation point — t=0 reproduces the first model exactly, t=1 reproduces the second, and t=0.5 sits at the midpoint of the arc. Because it operates on two full weight vectors, SLERP is fundamentally a two-model method; merging a third model means running SLERP again on the output.

TIES — Trim, Elect Sign, Merge

TIES-Merging, introduced by Yadav et al. in TIES-Merging: Resolving Interference When Merging Models (NeurIPS 2023), targets a different failure mode: when you merge three or more task vectors, many individual parameters get pulled in different directions by different tasks, and naive averaging cancels out signal instead of combining it. TIES fixes this in three explicit steps. Trim zeroes out the lowest-magnitude entries in each task vector, keeping only the changes that mattered most during fine-tuning — the paper reports up to 80% of delta parameters can be trimmed this way without a statistically significant drop in performance. Elect sign then resolves disagreements: for each remaining parameter, it takes a majority vote across all task vectors on whether that parameter should move positive or negative, producing one consensus sign per parameter. Merge finally averages together only the task-vector entries that agree with the elected sign, discarding the ones that fought against the consensus. The result keeps the parameters that mattered and removes the ones that were actively cancelling each other out.

DARE — Drop And REscale

DARE comes from Yu et al.'s Language Models are Super Mario paper and takes a different, randomised route to the same interference problem. Rather than trimming by magnitude, DARE randomly sets a proportion p of each task vector's delta parameters to zero, then rescales the surviving parameters by a factor of 1/(1-p) so the delta's expected magnitude is preserved. The paper reports that up to roughly 90% of delta parameters can be dropped this way with minimal impact on task performance, and in some large-model settings the safe drop rate goes higher still. DARE is not a complete merging method on its own — it is a pre-processing step, a "free lunch" denoiser that reduces redundancy in each task vector before another method combines them. In MergeKit this shows up as dare_linear (DARE's pruning, then simple weighted averaging) and dare_ties (DARE's pruning, then TIES's sign-election step on what survives). In practice dare_ties is the more commonly reached-for option, because it inherits TIES's sign-conflict resolution on top of DARE's redundancy reduction.

A worked MergeKit recipe

MergeKit is open source at github.com/arcee-ai/mergekit. As of mid-2026 it installs from a checkout rather than a pinned PyPI release, and every merge is driven by a single YAML config plus one CLI command.

git clone https://github.com/arcee-ai/mergekit.git
cd mergekit
pip install -e .

A two-model SLERP merge needs a merge_method, the two source models, a base_model reference and an interpolation schedule. The example below applies a different t schedule to attention layers versus MLP layers — a common refinement once t=0.5 everywhere has been your starting baseline — and falls back to a flat 0.5 for anything the two filters don't match.

# slerp-config.yml — merge two fine-tunes of the same base model
slices:
  - sources:
      - model: your-org/base-model-ft-a
        layer_range: [0, 32]
      - model: your-org/base-model-ft-b
        layer_range: [0, 32]
merge_method: slerp
base_model: your-org/base-model-ft-a
parameters:
  t:
    - filter: self_attn
      value: [0, 0.5, 0.3, 0.7, 1]
    - filter: mlp
      value: [1, 0.5, 0.7, 0.3, 0]
    - value: 0.5
dtype: bfloat16

For three or more task vectors, switch to TIES. Each non-base model gets its own density (the fraction of parameters TIES's trim step keeps) and weight (its relative contribution once the merge step runs):

# ties-config.yml — merge three task-specific fine-tunes
models:
  - model: your-org/base-model
  - model: your-org/base-model-ft-coding
    parameters:
      density: 0.5
      weight: 0.5
  - model: your-org/base-model-ft-support
    parameters:
      density: 0.5
      weight: 0.3
  - model: your-org/base-model-ft-tone
    parameters:
      density: 0.5
      weight: 0.2
merge_method: ties
base_model: your-org/base-model
parameters:
  normalize: true
dtype: float16

If TIES alone still shows interference — one task's behaviour bleeding into another's outputs — layer DARE's pruning underneath it by switching to dare_ties and adding a density that reflects DARE's more aggressive drop rate:

# dare-ties-config.yml — DARE pruning + TIES sign election, three task vectors
models:
  - model: your-org/base-model
  - model: your-org/base-model-ft-a
    parameters:
      density: 0.53
      weight: 0.4
  - model: your-org/base-model-ft-b
    parameters:
      density: 0.53
      weight: 0.3
  - model: your-org/base-model-ft-c
    parameters:
      density: 0.53
      weight: 0.3
merge_method: dare_ties
base_model: your-org/base-model
parameters:
  int8_mask: true
dtype: bfloat16

Every config runs through the same CLI entry point, mergekit-yaml, which takes the config file and an output directory:

mergekit-yaml ties-config.yml ./merged-model \
  --cuda \
  --lazy-unpickle \
  --allow-crimes

--cuda runs the merge on GPU rather than CPU (useful for larger models but not required — MergeKit's out-of-core design means CPU-only merges are viable for most 7B-13B checkpoints). --lazy-unpickle reduces peak memory by streaming tensors from disk instead of loading every source model fully into RAM at once. --allow-crimes relaxes some of MergeKit's safety checks (for example, merging models with mismatched vocab sizes by padding or truncating embeddings) — useful when you know exactly what you are doing and why, and a footgun otherwise. The output directory is a standard Hugging Face-format checkpoint you can load directly with transformers or push straight to the Hub.

Picking the right algorithm

The choice between SLERP, TIES and DARE comes down to how many task vectors you are combining and how much they overlap or conflict. The table below is the decision most builders actually need.

Algorithm	Model count	Best when	Key parameter	Watch for
SLERP	Exactly 2	Two fine-tunes of one base, low-to-moderate conflict	t (interpolation point, per-layer schedule optional)	Cannot merge 3+ models in a single pass
TIES	3 or more	Several task vectors with visible sign conflicts or bleed-through	density (trim threshold), weight per model	Still averages agreeing parameters — dense, highly overlapping tasks can retain redundancy
DARE (dare_ties)	3 or more	Heavy overlap between task vectors, TIES alone still interferes	density (post-DARE keep rate), weight per model	Randomised — re-running with a different seed changes the result slightly; test more than one seed on anything production-bound

A practical rule of thumb: start at the top of that table and only move down when you have evidence, not intuition, that the simpler method is leaving quality on the table. Two fine-tunes with genuinely different jobs — say, a Bengaluru fintech's compliance-tone adapter and a separate function-calling adapter — often merge cleanly with SLERP alone. It is only once you are stacking four or five task vectors, several of which touch overlapping behaviour, that TIES's sign election and then DARE's extra pruning start earning their added complexity.

Pitfalls that silently wreck a merge

MergeKit will happily produce a checkpoint from almost any inputs you give it — a completed run is not evidence the merge worked. Five failure modes account for most bad merges we have seen reported in the community.

• Different base models or architectures. TIES and DARE assume every task vector was computed against the same base checkpoint. Merge a Llama-based fine-tune with a Mistral-based one and the "delta" each method computes is arithmetic on unrelated weight spaces — the output loads, but its behaviour is unpredictable at best.
• Mismatched tokenizers. Even within the same model family, a fine-tune that extended the vocabulary (added special tokens, a new chat template) will have an embedding matrix a different shape from the base. MergeKit's tokenizer_source field lets you choose which model's tokenizer to keep, or build a union — leaving it unset and hoping is how you get a model that emits garbage for any token added after the base checkpoint.
• Weight-scale mismatches. A fine-tune trained for many epochs at a high learning rate produces a task vector with much larger magnitude than one trained lightly for a single epoch. Feed both into a merge with equal weight values and the aggressively-tuned model will dominate the result regardless of which task actually matters more to you. Tune the weight parameters to compensate, and check per-model output magnitude before you commit to a weighting.
• Assuming it "just works." A merged model that answers a handful of manual test prompts sensibly is not a validated model. Run the same evaluation suite you used to judge each source fine-tune — including the tasks each model was not tuned for — before you trust the merge with anything real.
• Treating the merge as a one-shot operation. Density, weight and drop-rate values that work well for one pair of task vectors rarely transfer unchanged to a different pair, even on the same base model. Budget for a small sweep — two or three values either side of your starting guess — rather than accepting the first config that produces a loadable checkpoint.

None of these are exotic edge cases; they are the default way a first merge attempt goes wrong. The good news is that all five are checkable before you invest in a full evaluation run: confirm base model and tokenizer match, print each task vector's parameter norm to sanity-check relative scale, and only then move on to the eval suite.

Does merging actually work? What the evidence says

The honest answer is: it depends, and the research backs that qualification rather than a clean "yes." What is well established is that naive averaging is a poor baseline — work studying merging at scale has found that plain parameter averaging can degrade a combined model below even the unmerged pretrained checkpoint once several task vectors are involved, while weighted and sparsity-aware methods such as TIES and DARE reliably do better than naive averaging on the same inputs. That is the strongest, most reproducible finding in the literature: whatever else you do, do not just average.

Beyond that baseline comparison, results get domain-dependent. A 2025 study specifically on medical-domain LLMs found Task Arithmetic and plain weighted averaging outperforming DARE-TIES on their benchmark suite, the opposite ranking from what the general merging literature would predict — a reminder that these methods have hyperparameters (density, weight, drop rate) that need re-tuning per domain rather than a single default that travels everywhere. Community-reported results point the other way in other settings: the SLERP-merged Marcoro14-7B-slerp topped the Open LLM Leaderboard for 7B-parameter models in February 2024, ahead of both of its source models individually — a well-documented single case rather than a controlled study, but a useful existence proof that merging can beat its inputs, not just approximate their average.

The pragmatic takeaway for a builder deciding whether to ship a merge: treat it exactly like you would treat a new fine-tune checkpoint. Run your held-out eval set for every source task, not just the one you care about most, compare against both source models individually and against a naive-average baseline, and only promote the merge if it clears the bar on the tasks that matter to you. A merge that quietly regresses on one of its source tasks while improving on another is not a free upgrade — it is a trade-off you need to see in the numbers before you ship it.

The economics still make merging worth trying even with that uncertainty baked in. A merge run over a 7B-13B model typically finishes in minutes on CPU or a single GPU, versus hours to days for a fresh fine-tuning or distillation run against the same data. That asymmetry is the real argument for merging: even a 50-50 chance of a meaningful improvement is worth a shot when the cost of finding out is one YAML file and a coffee break, not a training budget. Keep the naive-average baseline in your evaluation regardless — it costs nothing extra to compute and it is the fastest way to catch a merge config that is actively making things worse before it reaches a staging environment.

When merging is not the right tool

Merging assumes you want one static model that is reasonably good at everything you fed into it. That assumption breaks in two common situations. The first is genuinely low task overlap — if your "coding" and "customer support" adapters share almost no behaviour, a merge tends to average away exactly the specialisation that made each one useful, and you are better off keeping them separate. The second is when you need true per-request routing rather than one blended personality: a multi-tenant product where tenant A's adapter must never leak into tenant B's responses, for instance, is a routing problem, not a merging problem.

The standard alternative is multi-LoRA serving: keep every task's LoRA adapter as a small, separate set of weights and load them all against one shared base model at inference time, selecting the right adapter per request. The research system S-LoRA demonstrated this at extreme scale — serving up to 2,000 concurrent adapters off a single base model with minimal per-adapter overhead — and the same idea, at a more modest scale, is now a built-in feature of production servers like vLLM, which will hot-swap adapters per request when started with LoRA support enabled. If your workload looks like many distinct, occasionally-conflicting tasks rather than a handful of complementary skills, that is usually the better architecture; our guide to self-hosting open LLMs with vLLM covers the throughput and latency trade-offs of running that kind of adapter-serving setup in production.

If you have not yet trained the LoRA adapters you are hoping to merge, start with our eval-driven LoRA and QLoRA fine-tuning recipe — and if you are still deciding whether fine-tuning is the right move at all before you get anywhere near a merge, the 2026 fine-tuning decision ladder is the place to start.