🤖 AI

Making Models Unmergeable via Scaling-Sensitive Loss Landscape

Das Papier schlägt \textsc{Trap} $^{2}$ vor, ein architekturunabhängiges Framework, das Modellgewichte durch das Einbetten einer skalierungsempfindlichen Verlustlandschaft während des Fine-Tunings schützt, wodurch sichergestellt wird, dass unbefugtes Modell-Merging die Leistung verschlechtert, während die eigenständige Nützlichkeit erhalten bleibt.

Ursprüngliche Autoren: Minwoo Jang, Hoyoung Kim, Jabin Koo, Jungseul Ok

Veröffentlicht 2026-01-30

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Minwoo Jang, Hoyoung Kim, Jabin Koo, Jungseul Ok

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich die Welt der KI-Modelle wie eine riesige, offene Bibliothek vor, in der Menschen „Rezeptkarten“ (Updates) teilen, um einem Basischef (dem Basismodell) neue Tricks beizubringen. Manchmal möchte man zwei Rezeptkarten kombinieren, um einen Super-Chef zu erschaffen, der beide Tricks beherrscht. Dies wird als Model Merging bezeichnet.

Es gibt jedoch ein Problem: Was, wenn jemand eine Rezeptkarte veröffentlicht, die eigentlich allein verwendet werden sollte, aber andere sie mit ihren eigenen Karten mischen, um ein Monster zu erschaffen, das Sicherheitsregeln verletzt oder Lizenzbestimmungen ignoriert? Das Paper beschreibt dies als eine „Governance-Lücke“.

Die Autoren dieses Papers, Minwoo Jang und Kollegen, schlagen einen neuen Weg vor, um diese Rezeptkarten zu schützen, sodass sie zerbrechen, wenn jemand versucht, sie mit anderen zu mischen. Sie nennen ihre Methode TRAP2.

So funktioniert es, unter Verwendung einfacher Analogien:

Das Problem: Der „zerbrechliche Kuchen“

Betrachten Sie ein Standard-KI-Update (wie einen LoRA-Adapter) als einen perfekt gebackenen Kuchen.

Einzeln: Wenn Sie den Kuchen allein essen, schmeckt er fantastisch (hohe Genauigkeit).
Mischen: Wenn Sie versuchen, diesen Kuchen mit einem anderen Kuchen zu mischen, ist das Ergebnis normalerweise ein ordentliches neues Dessert.

Das Ziel des Papers ist es, einen Kuchen zu kreieren, der für sich allein genommen hervorragend schmeckt, aber zu Matsch wird, sobald jemand versucht, ihn mit einem anderen Kuchen zu mischen.

Der alte Weg (Post-Hoc-Verteidigungen)

Frühere Versuche, dies zu verhindern, bestanden darin, den fertigen Kuchen zu nehmen und eine spezielle „Glasur“ aufzutragen oder die Zutaten nachträglich umzuordnen.

Der Fehler: Dies funktioniert nur bei sehr spezifischen Arten von Kuchen (wie Transformer-Modellen). Wenn Sie versuchen, es bei einem anderen Typ von Kuchen (wie einem ResNet oder ConvNeXt) anzuwenden, haftet die Glasur nicht oder ruiniert den Geschmack des Kuchens. Außerdem, wenn Sie nur das „Topping“ (den Adapter) und nicht den ganzen Kuchen teilen, versagt diese Methode, da sie den gesamten Kuchen sehen muss, um zu funktionieren.

Der neue Weg: TRAP2 (Schutz während des Trainings)

Anstatt den Kuchen nach dem Backen zu glasieren, verändert TRAP2, wie der Kuchen von vornherein gebacken wird.

Stellen Sie sich vor, Sie backen einen Kuchen, aber Sie haben eine geheime Regel: „Dieser Kuchen muss bei Raumtemperatur perfekt sein, aber wenn man ihn auch nur ein wenig erhitzt oder abkühlt, muss er zusammenbrechen.“

In der Welt der KI ist „Temperatur“ wie ein Skalierungsfaktor.

Wenn das Modell allein verwendet wird, ist die „Temperatur“ auf 1,0 eingestellt (perfekt).
Wenn Leute versuchen, Modelle zu mischen, müssen sie oft die „Temperatur“ anpassen (die Gewichte hoch- oder runterskalieren), um die Mathematik passend zu machen.

TRAP2 trainiert das Modell gezielt darauf, unter solchen Anpassungen brüchig zu sein.

Das Training: Die KI lernt, perfekt zu funktionieren, wenn die Skalierung genau 1,0 beträgt.
Die Falle: Während des Trainings wird der KI auch gezeigt, was passiert, wenn die Skalierung 0,5 oder 2,0 beträgt. Sie wird schwer bestraft, wenn sie in diesen Szenarien gut abschneidet. Sie lernt, dass jede Änderung der Skalierung gefährlich ist.
Das Ergebnis: Wenn das Modell veröffentlicht wird, funktioniert es großartig für sich allein. Aber in dem Moment, in dem ein Nutzer versucht, es zu mischen (was eine Änderung der Skalierung erzwingt), bricht die Leistung des Modells zusammen.

Warum ist das besonders?

Es ist universell: Im Gegensatz zu den alten Methoden, die nur für spezifische „Kuchenarten“ (Transformer) funktionierten, arbeitet TRAP2 mit jeder Architektur. Es ist egal, wie das Modell aussieht; es zählt nur, wie die Zahlen skaliert werden.
Es funktioniert bei „Toppings“: Es funktioniert selbst dann, wenn Sie nur einen kleinen Adapter (wie einen LoRA) ohne das vollständige Modell veröffentlichen.
Der „Beifang“ (Collateral Damage): Das Paper stellt fest, dass, wenn man ein durch TRAP2 geschütztes Modell mit einem normalen Modell mischt, auch das normale Modell ruiniert wird. Es ist wie das Mischen einer zerbrechlichen Glasvase mit einer Holzschüssel; das Glas zersplittert und die Schüssel bekommt Macken. Dies stellt sicher, dass unbefugtes Mischen für alle Beteiligten eine schlechte Idee ist.

Die Ergebnisse

Die Autoren testeten dies bei vielen verschiedenen Bilderkennungsaufgaben (wie der Identifizierung von Autos, Flugzeugen oder handgeschriebenen Ziffern).

Einzeln: Die geschützten Modelle funktionierten genauso gut wie die ungeschützten Modelle.
Gemischt: Als sie versuchten, diese geschützten Modelle mit anderen zu mischen, sank die Genauigkeit drastisch und fiel oft unter das Niveau eines Modells, das überhaupt nicht trainiert worden war.

Zusammenfassend

TRAP2 ist wie eine mit einer Falle versehene Rezeptkarte. Sie funktioniert perfekt, wenn man die Anweisungen exakt befolgt (Einzelanwendung), aber wenn jemand versucht, sie mit anderen Rezepten zu remixen (Mischen), fällt das Ganze in sich zusammen. Dies schützt das Werk des Erstellers vor Missbrauch in unbefugten Kombinationen, ohne dass die spezifischen Details der internen Struktur des Modells bekannt sein müssen.

Technisches Resümee: Modelle durch skalierungssensitive Verlustlandschaften unmergable machen

1. Problemstellung

Die Verbreitung öffentlicher Modell-Hubs (z. B. Hugging Face, GitHub) hat das weit verbreitete Teilen von feingetunten Updates erleichtert, die von vollständigen Checkpoints bis hin zu leichtgewichtigen Adaptern wie Low-Rank Adaptation (LoRA) reichen. Während diese Modularität eine effiziente Modellzusammenführung (Merging) ermöglicht – also das Kombinieren mehrerer aufgabenspezifischer Updates zu einem einzigen Modell ohne zusätzliches Training –, schafft dies eine erhebliche Governance-Lücke. Einmal veröffentlicht, können diese Gewichte zu nicht autorisierten Mischungen kombiniert werden, die Sicherheits-Alignments, Lizenzbedingungen oder aufgabenspezifische Einschränkungen umgehen.

Bestehende Abwehrmechanismen gegen unbefugtes Merging sind weitgehend post-hoc und architekturspezifisch. Methoden wie PaRaMS und MergeLock nutzen die in Transformern inhärenten architektonischen Symmetrien (z. B. gekoppelte Reparametrisierungen von Attention-Projektionen), um die eigenständige Nützlichkeit zu bewahren, während sie direktes Merging im Gewichtsraum stören. Diese Ansätze stehen jedoch vor zwei kritischen Einschränkungen:

Inkompatibilität mit Adapter-only-Releases: Sie erfordern oft Zugriff auf die vollständigen Modellgewichte, um gepaarte Transformationen anzuwenden, was sie für LoRA-Adapter unwirksam macht, bei denen nur das Update $\Delta W$ geteilt wird und die Basisgewichte $W_0$ eingefroren oder nicht verfügbar sind.
Mangelnde architektonische Generalität: Ihre Abhängigkeit von Transformer-spezifischen Symmetrien verhindert die Anwendung auf Nicht-Transformer-Backbones (z. B. ResNet, ConvNeXt).

Die Kernherausforderung besteht darin, Unmergeability (Unmergbarkeit) direkt in das veröffentlichte Update einzubetten, sodass das Modell in seinem eigenständigen Setting ( $s=1$ ) die volle Nützlichkeit behält, aber bei den Re-Skalierungs- und Aggregationsoperationen, die typisch für Downstream-Merging-Pipelines sind, signifikant degradiert ( $s \neq 1$ ).

2. Methodik: TRAP2

Die Autoren schlagen TRAP2 (Training-time Protection via Task-Robust Adversarial Perturbation) vor, ein architekturoffensives Schutzframework, das Unmergeability direkt in den Prozess des Fine-Tunings integriert.

Kernintuition

Merging-Pipelines beinhalten oft die Re-Skalierung von Bestandteilen (z. B. skaliert das Mitteln von $N$ Adaptern jeden um $1/N$ ). TRAP2 nutzt dies aus, indem es die Verlustlandschaft so gestaltet, dass sie sensitiv gegenüber Off-Nominal-Skalierungen ist. Es optimiert ein adversarielles Ziel, das die Performance bei der nominalen Skalierung aufrechterhält, während es unter Off-Nominal-Skalierung eine katastrophale Degradierung induziert.

Die Zielfunktion

Gegeben sei ein Basismodell $W_0$ und ein trainierbares Update $\Delta W$ . Die Methode definiert den Verlust bei einem Skalierungsfaktor $s$ als:
$L_{scaled}(\Delta W; s) = \mathbb{E}_{\xi \sim D}[\ell(W_0 + s \cdot \Delta W; \xi)]$

Das Trainingsziel $J(\Delta W)$ minimiert den nominalen Verlust und maximiert gleichzeitig den Verlust unter Off-Nominal-Skalierung:
$J(\Delta W) = L_{nominal}(\Delta W) - \lambda \cdot L_{off}(\Delta W)$

Wobei:

$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$ ist eine Verteilung über Off-Nominal-Skalen (unter Ausschluss eines Margins $\delta$ um $s=1$ ).
$w(s)$ ist eine Gewichtungsfunktion (standardmäßig $1/s$ ), um die Gradienten für herunterskalierte Updates zu stabilisieren.
$\lambda$ tauscht die eigenständige Nützlichkeit gegen die Sensitivität gegenüber Re-Skalierung aus.

Optimierung

Die Methode verwendet stochastische First-Order-Optimierung (z. B. SGD). In jeder Iteration wird ein einzelnes Sample $s$ aus der Off-Nominal-Verteilung $S$ gezogen, um die Erwartung zu approximieren, was einen unverzerrten Gradientenschätzer liefert. Dieses Verfahren findet Anwendung auf sowohl:

Adapter-only-Releases: Optimierung der LoRA-Matrizen $A$ und $B$ .
Full Fine-Tuning: Optimierung der vollständigen Parameterdifferenz $\Delta W_t = W_t - W_0$ bei jedem Trainingsschritt.

3. Wichtigste Beiträge

Problemformalisierung: Die Autoren formalisieren ein Post-Release-Schutzsetting, das diverse Architekturen und Release-Formate (Adapter und vollständige Checkpoints) berücksichtigt und ein einheitliches Evaluationsprotokoll für eigenständige Nützlichkeit und Merging-Degradierung etabliert.
Architektur-agnostischer Schutz: Im Gegensatz zu vorherigen Arbeiten setzt TRAP2 nicht auf architektonische Symmetrien oder Zugriff auf die vollen Gewichte. Es bettet den Schutz direkt in das Update ein, wodurch es für LoRA, vollständige Checkpoints und Nicht-Transformer-Backbones anwendbar ist.
Theoretische und empirische Analyse: Die Arbeit liefert theoretische Garantien bezüglich der Konvergenz unter stochastischer Optimierung und charakterisiert die Degradierung unter Herunterskalierung. Empirisch zeigt sie, dass TRAP2 eine zuverlässige Performance-Kollaps unter Merging induziert, während die eigenständige Genauigkeit bewahrt wird.

4. Experimentelle Ergebnisse

Die Autoren evaluierten TRAP2 über acht Vision-Klassifikations-Benchmarks (Cars, DTD, EuroSAT, GTSRB, MNIST, RESISC, Aircraft, SVHN) unter Verwendung von CLIP-Modellen mit ViT-B/32, ViT-L/14 und ConvNeXt-Backbones.

Eigenständige Nützlichkeit (Standalone Utility)

Bewahrung der Performance: TRAP2 hält eine eigenständige Genauigkeit aufrecht, die mit ungeschütztem Fine-Tuning über alle Architekturen und Datensätze hinweg vergleichbar ist.
Vergleich mit Baselines: Post-hoc-Abwehrmechanismen wie MergeLock scheiterten daran, die eigenständige Nützlichkeit in Adapter-only-Settings zu bewahren (oft kollabierten sie auf Zufallsniveau). PaRaMS bewahrte die Nützlichkeit, verhinderte jedoch das Merging nicht. TRAP2 war in beiden Fällen erfolgreich.

Unmergeability (Merging-Degradierung)

Lineares Merging: Beim Merging mit anderen Adaptern unter Verwendung von Standard-Operatoren (Task Arithmetic, TIES, DARE, TSV, CART) in Full-, KnOTS- oder Core-Räumen erlitten TRAP2-geschützte Modelle erhebliche Genauigkeitseinbußen, die oft unter die Zero-Shot-Baselines fielen.
Robustheit gegenüber Merging-Strategien: Die Degradierung blieb bestehen, selbst wenn die Merging-Koeffizienten mittels Grid Search optimiert wurden, um die bestmögliche Performance für den Merger zu finden.
Datenabhängiges Merging: TRAP2 blieb effektiv gegen datenabhängige Merging-Operatoren wie RegMean und Chain-of-Merges (CoM), die versuchen, die Nützlichkeit durch Nutzung zusätzlicher Datensignale wiederherzustellen.
Paarweises und N-way Merging: Die Methode verursachte einen "Selbst-Kollaps" bei paarweisen Merges und eine konsistente Degradierung beim N-way Uniform Averaging (wobei $N \ge 2$ ).
Kollateralschaden: Das Merging eines TRAP2-Adapters mit einem ungeschützten Adapter degradierte oft auch die Performance der ungeschützten Aufgabe, was die disruptive Natur des Schutzes verdeutlicht.

Generalisierung

Architektur: TRAP2 funktionierte effektiv auf ConvNeXt, wo Transformer-spezifische Abwehrmechanismen nicht anwendbar sind.
Skalierung: Die Ergebnisse waren konsistent über ViT-B/32 und ViT-L/14 Backbones hinweg.
Full Fine-Tuning: Die Methode ließ sich erfolgreich auf Full-Model-Merging erweitern, nicht nur auf Adapter-Merging.

5. Bedeutung und Ansprüche

Die Arbeit behauptet, dass TRAP2 eine praktische Lösung für die Governance-Lücke in offenen Modell-Ökosystemen bietet, indem sie das Schutzparadigma von post-hoc zu Training-time verschiebt.

Verschiebung der Abwehrstrategie: Durch die Einbettung der Unmergeability direkt in das Update umgeht TRAP2 die Einschränkungen von Post-hoc-Methoden, die Zugriff auf das vollständige Modell oder spezifische architektonische Symmetrien erfordern.
Zuverlässigkeit: Die Methode stellt sicher, dass die unbefugte Rekombination unzuverlässig ist, was die Erstellung nicht autorisierter Mischungen, die Sicherheits- oder Lizenzbeschränkungen umgehen, effektiv abschreckt.
Bescheidenheit hinsichtlich der Limitationen: Die Autoren räumen ein, dass sich ihre Evaluierung auf koeffizientenbasiertes Merging konzentriert, das beim Plug-and-Play-Reuse üblich ist. Sie merken an, dass die Erweiterung des Schutzes gegen datengetriebene Wiederherstellung (bei der ein Merger zusätzliche aufgabenrelevante Daten nutzt, um das gemergte Modell neu zu trainieren oder feinzutunen, um die Nützlichkeit wiederherzustellen) ein offener Bereich für zukünftige Arbeiten bleibt.

Die Autoren betonen, dass die Methode zwar adversarielle Perturbationen während des Trainings verwendet, aber als defensives Werkzeug gedacht ist, um die Rechte der Uploader und die Integrität der Modelle zu schützen, und nicht, um Angriffe zu ermöglichen. Sie plädieren für verantwortungsvolle Release-Praktiken, wie z. B. eine klare Kennzeichnung, um Downstream-Nutzer darüber zu informieren, dass geschützte Modelle unter Merging möglicherweise nicht zuverlässig funktionieren.