🤖 AI

Making Models Unmergeable via Scaling-Sensitive Loss Landscape

The paper proposes \textsc{Trap} $^{2}$ , an architecture-agnostic framework that protects model weights by embedding a scaling-sensitive loss landscape during fine-tuning, ensuring that unauthorized model merging degrades performance while preserving standalone utility.

Original authors: Minwoo Jang, Hoyoung Kim, Jabin Koo, Jungseul Ok

Published 2026-01-30

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Minwoo Jang, Hoyoung Kim, Jabin Koo, Jungseul Ok

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the world of AI models like a giant, open library where people share "recipe cards" (updates) to teach a basic chef (the base model) new tricks. Sometimes, you want to combine two recipe cards to make a super-chef who can do both tricks. This is called model merging.

However, there's a problem: What if someone releases a recipe card that is supposed to be used alone, but others mix it with their own cards to create a monster that breaks safety rules or ignores licensing? The paper calls this a "governance gap."

The authors of this paper, Minwoo Jang and colleagues, propose a new way to protect these recipe cards so they break if someone tries to mix them with others. They call their method TRAP2.

Here is how it works, using simple analogies:

The Problem: The "Fragile Cake"

Think of a standard AI update (like a LoRA adapter) as a perfectly baked cake.

Standalone: If you eat the cake by itself, it tastes amazing (high accuracy).
Merging: If you try to mix this cake with another cake, the result is usually a decent new dessert.

The goal of the paper is to make a cake that tastes amazing on its own, but turns into mush the moment someone tries to mix it with another cake.

The Old Way (Post-Hoc Defenses)

Previous attempts to stop this involved taking the finished cake and applying a special "glaze" or rearranging the ingredients after it was baked.

The Flaw: This only works on very specific types of cakes (like Transformer models). If you try it on a different type of cake (like a ResNet or ConvNeXt), the glaze doesn't stick, or it ruins the cake's taste. Also, if you only share the "topping" (the adapter) and not the whole cake, this method fails because it needs to see the whole cake to work.

The New Way: TRAP2 (Training-Time Protection)

Instead of glazing the cake after it's baked, TRAP2 changes how the cake is baked in the first place.

Imagine you are baking a cake, but you have a secret rule: "This cake must be perfect at room temperature, but if you heat it up or cool it down even a little bit, it must collapse."

In the AI world, "temperature" is like a scaling factor.

When the model is used alone, the "temperature" is set to 1.0 (perfect).
When people try to merge models, they often have to adjust the "temperature" (scaling the weights up or down) to make the math work.

TRAP2 trains the model specifically to be brittle under these adjustments.

The Training: The AI learns to perform perfectly when the scaling is exactly 1.0.
The Trap: During training, the AI is also shown what happens if the scaling is 0.5 or 2.0. It is punished heavily for performing well in those scenarios. It learns that any change in scale is dangerous.
The Result: When the model is released, it works great on its own. But the moment a user tries to merge it (which forces a scale change), the model's performance crashes.

Why is this special?

It's Universal: Unlike the old methods that only worked on specific "cake types" (Transformers), TRAP2 works on any architecture. It doesn't care what the model looks like; it only cares about how the numbers are scaled.
It Works on "Toppings": It works even if you only release a small adapter (like a LoRA) without the full model.
The "Collateral Damage": The paper notes that if you mix a TRAP2-protected model with a normal one, the normal one also gets ruined. It's like mixing a fragile glass vase with a wooden bowl; the glass shatters, and the bowl gets chipped. This ensures that unauthorized merging is a bad idea for everyone involved.

The Results

The authors tested this on many different image recognition tasks (like identifying cars, aircraft, or handwritten digits).

Standalone: The protected models worked just as well as unprotected ones.
Merged: When they tried to merge these protected models with others, the accuracy dropped drastically, often falling below the level of a model that had never been trained at all.

In Summary

TRAP2 is like baking a booby-trapped recipe card. It works perfectly if you follow the instructions exactly (standalone use), but if anyone tries to remix it with other recipes (merging), the whole thing falls apart. This protects the creator's work from being misused in unauthorized combinations without needing to know the specific details of the model's internal structure.

Technical Summary: Making Models Unmergeable via Scaling-Sensitive Loss Landscape

1. Problem Statement

The proliferation of public model hubs (e.g., Hugging Face, GitHub) has facilitated the widespread sharing of fine-tuned updates, ranging from full checkpoints to lightweight adapters like Low-Rank Adaptation (LoRA). While this modularity enables efficient model merging—combining multiple task-specific updates into a single model without additional training—it creates a significant governance gap. Once released, these weights can be recombined into unauthorized mixtures that bypass safety alignments, licensing terms, or task-specific constraints.

Existing defenses against unauthorized merging are largely post-hoc and architecture-specific. Methods such as PaRaMS and MergeLock rely on architectural symmetries inherent to Transformers (e.g., coupled re-parameterizations of attention projections) to preserve standalone utility while disrupting direct weight-space merging. However, these approaches face two critical limitations:

Incompatibility with Adapter-Only Releases: They often require access to full model weights to apply paired transformations, rendering them ineffective for LoRA adapters where only the update $\Delta W$ is shared and the base weights $W_0$ are frozen/unavailable.
Lack of Architectural Generality: Their reliance on Transformer-specific symmetries prevents application to non-Transformer backbones (e.g., ResNet, ConvNeXt).

The core challenge is to embed unmergeability directly into the released update such that the model retains full utility in its standalone setting ( $s=1$ ) but degrades significantly when subjected to the re-scaling and aggregation operations typical of downstream merging pipelines ( $s \neq 1$ ).

2. Methodology: TRAP2

The authors propose TRAP2 (Training-time Protection via Task-Robust Adversarial Perturbation), an architecture-agnostic protection framework that integrates unmergeability into the fine-tuning process itself.

Core Intuition

Merging pipelines often involve re-scaling constituent updates (e.g., averaging $N$ adapters scales each by $1/N$ ). TRAP2 exploits this by shaping the loss landscape to be sensitive to off-nominal scaling. It optimizes an adversarial objective that maintains performance at the nominal scale while inducing catastrophic degradation under off-nominal scaling.

The Objective Function

Given a base model $W_0$ and a trainable update $\Delta W$ , the method defines the loss at a scaling factor $s$ as:
$L_{scaled}(\Delta W; s) = \mathbb{E}_{\xi \sim D}[\ell(W_0 + s \cdot \Delta W; \xi)]$

The training objective $J(\Delta W)$ minimizes the nominal loss while maximizing the loss under off-nominal scaling:
$J(\Delta W) = L_{nominal}(\Delta W) - \lambda \cdot L_{off}(\Delta W)$

Where:

$L_{nominal}(\Delta W) = L_{scaled}(\Delta W; 1)$ .
$L_{off}(\Delta W) = \mathbb{E}_{s \sim S}[w(s) \cdot L_{scaled}(\Delta W; s)]$ .
$S$ is a distribution over off-nominal scales (excluding a margin $\delta$ around $s=1$ ).
$w(s)$ is a weighting function (default $1/s$ ) to stabilize gradients for down-scaled updates.
$\lambda$ trades off standalone utility against sensitivity to re-scaling.

Optimization

The method employs stochastic first-order optimization (e.g., SGD). In each iteration, a single sample $s$ is drawn from the off-nominal distribution $S$ to approximate the expectation, providing an unbiased gradient estimator. This procedure applies to both:

Adapter-only releases: Optimizing the LoRA matrices $A$ and $B$ .
Full fine-tuning: Optimizing the full parameter difference $\Delta W_t = W_t - W_0$ at each training step.

3. Key Contributions

Problem Formalization: The authors formalize a post-release protection setting that accommodates diverse architectures and release formats (adapters and full checkpoints), establishing a unified evaluation protocol for standalone utility and merging degradation.
Architecture-Agnostic Protection: Unlike prior work, TRAP2 does not rely on architectural symmetries or full-weight access. It embeds protection directly into the update, making it applicable to LoRA, full checkpoints, and non-Transformer backbones.
Theoretical and Empirical Analysis: The paper provides theoretical guarantees regarding convergence under stochastic optimization and characterizes the degradation under down-scaling. Empirically, it demonstrates that TRAP2 induces reliable performance collapse under merging while preserving standalone accuracy.

4. Experimental Results

The authors evaluated TRAP2 across eight vision classification benchmarks (Cars, DTD, EuroSAT, GTSRB, MNIST, RESISC, Aircraft, SVHN) using CLIP models with ViT-B/32, ViT-L/14, and ConvNeXt backbones.

Standalone Utility

Performance Preservation: TRAP2 maintains standalone accuracy comparable to unprotected fine-tuning across all architectures and datasets.
Comparison with Baselines: Post-hoc defenses like MergeLock failed to preserve standalone utility in adapter-only settings (often collapsing to chance levels). PaRaMS retained utility but failed to prevent merging. TRAP2 succeeded in both.

Unmergeability (Merging Degradation)

Linear Merging: When merged with other adapters using standard operators (Task Arithmetic, TIES, DARE, TSV, CART) in Full, KnOTS, or Core spaces, TRAP2-protected models suffered substantial accuracy drops, often falling below zero-shot baselines.
Robustness to Merging Strategies: The degradation persisted even when merging coefficients were optimized via grid search to find the best possible performance for the merger.
Data-Dependent Merging: TRAP2 remained effective against data-dependent merging operators like RegMean and Chain-of-Merges (CoM), which attempt to recover utility by leveraging additional data signals.
Pairwise and N-way Merging: The method caused "self-collapse" in pairwise merges and consistent degradation in N-way uniform averaging (where $N \ge 2$ ).
Collateral Damage: Merging a TRAP2 adapter with an unprotected adapter often degraded the performance of the unprotected task as well, demonstrating the disruptive nature of the protection.

Generalization

Architecture: TRAP2 worked effectively on ConvNeXt, where Transformer-specific defenses are inapplicable.
Scale: Results were consistent across ViT-B/32 and ViT-L/14 backbones.
Full Fine-Tuning: The method extended successfully to full-model merging, not just adapter merging.

5. Significance and Claims

The paper claims that TRAP2 offers a practical solution to the governance gap in open model ecosystems by shifting the protection paradigm from post-hoc to training-time.

Shift in Defense Strategy: By embedding unmergeability into the update itself, TRAP2 bypasses the limitations of post-hoc methods that require full model access or specific architectural symmetries.
Reliability: The method ensures that unauthorized recomposition is unreliable, effectively discouraging the creation of unauthorized mixtures that bypass safety or licensing constraints.
Modesty on Limitations: The authors acknowledge that their evaluation focuses on coefficient-based merging common in plug-and-play reuse. They note that extending protection against data-driven recovery (where a merger uses additional task-relevant data to re-train or fine-tune the merged model to restore utility) remains an open direction for future work.

The authors emphasize that while the method uses adversarial perturbations during training, it is intended as a defensive tool to protect uploader rights and model integrity, not to enable attacks. They advocate for responsible release practices, such as clear labeling, to inform downstream users that protected models may not behave reliably under merging.