One challenge organizations face when customizing
large language models (LLMs)
is the need to run multiple experiments, which produces only one useful model. While the cost of experimentation is typically low, and the results well worth the effort, this experimentation process does involve “wasted” resources, such as compute assets spent without their product being utilized, dedicated developer time, and more.
Model merging combines the weights of multiple customized LLMs, increasing resource utilization and adding value to successful models. This approach provides two key solutions:
Reduces experimentation waste by repurposing “failed experiments”
Offers a cost-effective alternative to join training
This post explores how models are customized, how model merging works, different types of model merging, and how model merging is iterating and evolving.
Revisiting model customization
This section provides a brief overview of how models are customized and how this process can be leveraged to help build an intuitive understanding of model merging.
Note that some of the concepts discussed are oversimplified for the purpose of building this intuitive understanding of model merging. It is suggested that you familiarize yourself with customization techniques, transformer architecture, and training separately before diving into model merging. See, for example,
Mastering LLM Techniques: Customization
.
The role of weight matrices in models
Weight matrices are essential components in many popular model architectures, serving as large grids of numbers (weights, or parameters) that store the information necessary for the model to make predictions.
As data flows through a model, it passes through multiple layers, each containing its own weight matrix. These matrices transform the input data through mathematical operations, enabling the model to learn from and adapt to the data.
To modify a model’s behavior, the weights within these matrices must be updated. Although the specifics of weight modification are not essential, it’s crucial to understand that each customization of a base model results in a unique set of updated weights.
Task customization
When fine-tuning an LLM for a specific task, such as summarization or math, the updates made to the weight matrices are targeted towards improving performance on that particular task. This implies that the modifications to the weight matrices are localized to specific regions, rather than being uniformly distributed.
To illustrate this concept, consider a simple analogy where the weight matrices are represented as a sports field that is 100 yards in length. When customizing the model for summarization, the updates to the weight matrices might concentrate on specific areas, such as the 10-to-30 yard lines. In contrast, customizing the model for math might focus updates on a different region, like the 70-to-80 yard lines.
Interestingly, when customizing the model for a related task, such as summarization in the French language, the updates might overlap with the original summarization task, affecting the same regions of the weight matrices (the 25-to-35 yard lines, for example). This overlap suggests an important insight: different task customizations can significantly impact the same areas of the weight matrices.
While the previous example is purposefully oversimplified, the intuition is accurate. Different task customizations will lead to different parts of the weight matrices being updated, and customization for similar tasks might lead to changing the same parts of their respective weight matrices.
This understanding can inform strategies for customizing LLMs and leveraging knowledge across tasks.
Model merging
Model merging is a loose grouping of strategies that relates to combining two or more models, or model updates, into a single model for the purpose of saving resources or improving task-specific performance.
This discussion focuses primarily on the implementation of these techniques through an open-source library developed by
Arcee AI
called
mergekit
. This library simplifies the implementation of various merging strategies.
Many methods are used to merge models, in various levels of complexity. Here, we’ll focus on four main merging methods:
Model Soup
Spherical Linear Interpolation (SLERP)
Task Arithmetic (using Task Vectors)
TIES leveraging DARE
Model Soup
The Model Soup method involves averaging the resultant model weights created by hyperparameter optimization experiments, as explained in
Model Soups: Averaging Weights of Multiple Fine-Tuned Models Improves Accuracy Without Increasing Inference Time
.
Originally tested and verified through computer vision models, this method has shown promising results for LLMs as well. In addition to generating some additional value out of the experiments, this process is simple and not compute intensive.
There are two ways to create Model Soup: naive and greedy. The naive approach involves merging all models sequentially, regardless of their individual performance. In contrast, the greedy implementation follows a simple algorithm:
Rank models by performance on the desired task
Merge the best performing model with the second best performing model
Evaluate the merged model’s performance on the desired task
If the merged model performs better, continue with the next model; otherwise, skip the current model and try again with the next best model
This greedy approach ensures that the resulting Model Soup is at least as good as the best individual model.
Figure 1. The Model Soup method outperforms the constituent models using the greedy model Soup Model merging technique
Each step of creating a Model Soup is implemented by simple weighted and normalized linear averaging of two or more model weights. Both the weighting and normalization are optional, though recommended. The implementation of this from the
mergekit
library is as follows:
res = (weights * tensors).sum(dim=0)
if self.normalize:
	res = res / weights.sum(dim=0)
While this method has shown promising results in the computer vision and language domains, it faces some serious limitations. Specifically, there is no guarantee that the model will be more performant. The linear averaging can lead to degraded performance or loss of generalizability.
The next method, SLERP, addresses some of those specific concerns.
SLERP
Spherical Linear Interpolation, or SLERP, is a method introduced in a 1985 paper titled
Animating Rotation with Quaternion Curves
. It’s a “smarter” way of computing the average between two vectors. In a technical sense, it helps compute the shortest path between two points on a curved surface.
This method excels at combining two models. The classic example is imagining the shortest path between two points on the Earth. Technically, the shortest path would be a straight line that goes through the Earth, but in reality it’s a curved path on the surface of the Earth. SLERP computes this smooth path to use for averaging two models together while maintaining their unique model weight “surfaces.”
The following code snippet is the core of the SLERP algorithm, and is what provides such a good interpolation between the two models:
# Calculate initial angle between v0 and v1
theta_0 = np.arccos(dot)
sin_theta_0 = np.sin(theta_0)

# Angle at timestep t
theta_t = theta_0 * t
sin_theta_t = np.sin(theta_t)

# Finish the slerp algorithm
s0 = np.sin(theta_0 - theta_t) / sin_theta_0
s1 = sin_theta_t / sin_theta_0
res = s0 * v0_copy + s1 * v1_copy

return maybe_torch(res, is_torch)
Task Arithmetic (using Task Vectors)
This group of model merging methods utilizes Task Vectors to combine models in various ways, increasing in complexity.
Task Vectors: Capturing customization updates
Recalling how models are customized, updates are made to the model’s weights, and those updates are captured in the base model matrices. Instead of considering the final matrices as a brand new model, they can be viewed as the difference (or delta) between the base weights and the customized weights. This introduces the concept of a task vector,a structure containing the delta between the base and customized weights.
This is the same intuition behind Low Rank Adaptation (LoRA), but without the further step of factoring the matrices representing the weight updates.
Task Vectors can be simply obtained from customization weights by subtracting out the base model weights.
Task Interference: Conflicting updates
Recalling the sports field example, there is a potential for overlap in the updated weights between different customizations. There is some intuitive understanding that customization done for the same task would lead to a higher rate of conflicting updates than customization done for two, or more, separate tasks.
This “conflicting update” idea is more formally defined as Task Interference and it relates to the potential collision of important updates between two, or more, Task Vectors.
Task Arithmetic
As introduced in the paper
Editing Models with Task Arithmetic
, Task Arithmetic represents the simplest implementation of a task vector approach. The process is as follows:
Obtain two or more task vectors and merge them linearly as seen in Model Soup.
After the resultant merged task vector is obtained, it is added into the base model.
This process is simple and effective, but has a key weakness: no attention is paid to the potential interference between the task vectors intended to be merged.
TIES-Merging
As introduced in the paper
TIES-Merging: Resolving Interference When Merging Models
, TIES (TrIm Elect Sign and Merge) is a method that takes the core ideas of Task Arithmetic and combines it with heuristics for resolving potential interference between the Task Vectors.
The general procedure is to consider, for each weight in the Task Vectors being merged, the magnitude of each incoming weight, then the sign of each incoming weight, and then averaging the remaining weights.
Figure 2. A visual representation of the TIES process
This method seeks to resolve interference by enabling the models that had the most significant weight updates for any given weight update take precedence during the merging process. In essence, the models that “cared” more about that weight would be prioritized over the models that did not.
DARE
Introduced in the paper
Language Models are Super Mario: Absorbing Abilities from Homologous Models as a Free Lunch
, DARE isn’t directly a model merging technique. Rather, it’s an augment that can be considered alongside other approaches. DARE derives from the following:
D
rops delta parameters with a ratio p
A
nd
RE
scales the remaining ones by 1/(1 – p) to approximate the original embeddings.
Instead of trying to address the problem of interference through heuristics, DARE approaches it from a different perspective. In essence, it randomly drops a large number of the updates found in a specific task vector by setting them to 0, and then rescales the remaining weight proportional to the ratio of the dropped weights.
DARE has been shown to be effective even when dropping upwards of 90%, or even 99% of the task vector weights.
Increase model utility with model merging
The concept of model merging offers a practical way to maximize the utility of multiple LLMs, including task-specific fine-tuning done by a larger community. Through techniques like Model Soup, SLERP, Task Arithmetic, TIES-Merging, and DARE, organizations can effectively merge multiple models in the same family in order to reuse experimentation and cross-organizational efforts.
As the techniques behind model merging are better understood and further developed, they are poised to become a cornerstone of the development of performant LLMs. While this post has only scratched the surface, more techniques are constantly under development, including some
evolution-based methods
. Model merging is a budding field in the generative AI landscape, as more applications are being tested and proven.
Reading Time:
2
minutes
大規模言語モデル (LLM)
をカスタマイズする際に、組織が直面する課題の 1 つは、複数の実験を実行する必要があるのに、その結果得られるのは 1 つの有用なモデルのみということです。 実験にかかるコストは通常低く、労力に見合う成果が得られるものの、この実験プロセスには、実験に割り当てされてるけど使用率の低いまたは、全く稼働していない計算機や専任の開発者が費やす時間など、「無駄な」リソースが含まれます。
モデル マージは、複数のカスタマイズされた LLM の重みを組み合わせることで、リソースの利用率を高め、成功したモデルに付加価値を加えます。 このアプローチは、2 つの重要なソリューションを提供します。
「失敗した実験」を別の目的に使用することで、実験の無駄を削減する
トレーニングに参加するためのコスト効率の高い代替手段を提供する
本投稿では、モデルがどのようにカスタマイズされるのか、モデル マージがどのように機能するのか、さまざまな種類のモデル マージ、およびモデル マージがどのように繰り返され、進化しているのかについて探ります。
モデル カスタマイズ再訪
このセクションでは、モデルがどのようにカスタマイズされるか、またこのプロセスをどのように活用することで、モデル マージを直感的に理解できるのかについて簡単に説明します。
ここで説明されている概念の一部は、モデル マージに対する直感的な理解をを深めるために、過度に単純化されていることがあります。 モデル マージを始める前に、カスタマイズ技術、Transformer アーキテクチャおよびトレーニングについては、個別に理解しておくことをお勧めします。 たとえば、
大規模言語モデルのカスタマイズ手法を選択する
などを参考にしてください。
モデルにおける重み行列の役割
重み行列は、多くの一般的なモデル アーキテクチャにおいて必須のコンポーネントであり、モデルが予測を行うのに必要な情報を格納する大きなグリッド (重み、またはパラメーター) として機能します。
データはモデルを流れる際には複数のレイヤーを通過しますが、その各レイヤーには独自の重み行列が含まれています。 これらの行列は、数学演算を通じて入力データを変換し、モデルがデータから学び、それらに適応できるようにします。
モデルの動作を変更するには、これらの行列内の重みを更新する必要があります。 重みを変更する際の詳細は重要ではありませんが、ベースのモデルをカスタマイズする度に、更新された重みの一意なセットが生成されることを理解することが重要です。
タスクのカスタマイズ
要約や数学などの特定のタスクのために LLM をファインチューニングする場合、重み行列に行われた更新は、その特定のタスクのパフォーマンスを向上させるために行われます。 これは、重み行列への変更は均等に分布されるのではなく、特定の領域に限定されることを意味します。
この概念を説明するために、重み行列を 100 ヤードのスポーツフィールドに見立てた単純な例について考えてみましょう。要約するためにモデルをカスタマイズする場合、重み行列への更新は、10～30 ヤードのラインなどの特定の領域に集中する可能性があります。 対照的に、モデルを数学向けにカスタマイズする場合、70～80 ヤードのラインなど、別の領域に更新が集中する可能性があります。
興味深いことに、フランス語の要約など、関連するタスクのモデルをカスタマイズする場合、更新が元々の要約タスクと重複し、重み行列 (例えば、25～35 ヤード）の同じ領域に影響を及ぼす可能性があります。 この重複部分は、重要な洞察を示しています。異なるタスクのカスタマイズが、重み行列内の同じ領域に大きな影響を与える可能性があるのです。
前述の例は意図的に単純化されたものですが、直感は正確です。 異なるタスクのカスタマイズにより、重み行列の異なる部分が更新されることにつながります。また、類似したタスクをカスタマイズすると、それぞれの重み行列の同じ部分が変更される可能性があります。
このことを理解することは、LLM をカスタマイズしたり、タスク全体で知識を活用する際の戦略に役立ちます。
モデル マージ
モデル マージとは、リソースの節約やタスク固有のパフォーマンス向上を目的として、2 つ以上のモデルまたはモデルの更新を 1 つのモデルにまとめることに関連した戦略を大まかにグループ化することです。
ここでは、
Arcee AI
が開発した
mergekit
と呼ばれるオープンソース ライブラリを通じて、これらの技術を実装することに主に焦点を当てます。 このライブラリは、さまざまなマージ戦略の実装を簡素化します。
モデルのマージに使用される方法は数多くあり、その複雑さも様々です。 ここでは、主な 4 つのマージ方法を取り上げます。
Model Soup
球面線型補間 (SLERP: Spherical Linear Interpolation)
Task Arithmetic (Task Vector を使用)
DARE を活用した TIES
Model Soup
Model Soup メソッドでは、ハイパー パラメーター最適化実験によって得られたモデルの重みを平均化します。これについては、
Model Soups: Averaging Weights of Multiple Fine-Tuned Models Improves Accuracy Without Increasing Inference Time
に説明されています。
当初、コンピューター ビジョン モデルを通じてテストと検証が行われたこの方法は、LLM でも有望な結果を示しています。 実験から何らかの付加価値を生み出すだけでなく、このプロセスは単純で、計算量も多くありません。
Model Soup を作成する方法には、Naive と Greedy の 2 つの方法があります。 Naive アプローチでは、個々のパフォーマンスに関係なく、すべてのモデルを順次マージします。 これとは対照的に、Greedy 実装は以下の単純なアルゴリズムに従ったものになります。
目的のタスクのパフォーマンスに基づいてモデルをランク付けする
最も良いパフォーマンス モデルと、2 番目に良いパフォーマンス モデルをマージする
マージされたモデルのパフォーマンスを、目的のタスクで評価する
マージされたモデルがより良いパフォーマンスを発揮する場合は、次のモデルで続行する。そうでない場合は、現在のモデルをスキップし、次の最も良いモデルで再試行する
この Greedy アプローチでは、結果として得られる Model Soup が、少なくとも最良の個々のモデルと同等の品質になることを保証します。
図 1. Model Soup メソッドは、Greedy モデル マージ技術を使用することで、個々のモデルよりも優れた性能を発揮します
Model Soup を作成する各手順は、2 つ以上のモデルの重みを単純に重み付けし、正規化した線形平均を取ることで実装されます。重み付けと正規化はどちらもオプションですが、推奨されます。
mergekit
ライブラリから実装する場合は、以下のようになります。
res = (weights * tensors).sum(dim=0)
if self.normalize:
    res = res / weights.sum(dim=0)
この方法は、コンピューター ビジョンや言語の領域で有望な結果を示していますが、いくつかの深刻な限界に直面しています。 具体的には、モデルがより優れた性能を発揮できるという保証はありません。 線形平均化は、性能の低下や、汎化性能の喪失につながることがあります。
次のメソッドとなる SLERP は、これらの特定の懸念の一部に対処します。
SLERP
球面線型補間 (SLERP: Spherical Linear Interpolation) は、1985 年に
Animating Rotation with Quaternion Curves
と題された論文で紹介された方法です。 これは、2 つのベクトル間の平均を計算する「よりスマート」な方法です。 技術的な意味では、曲面上の 2 つの点間の最短経路を計算するのに役立ちます。
この方法では、2 つのモデルを組み合わせることに優れています。 典型的な例としては、地球上の 2 つの地点間の最短経路を想像してみてください。技術的には、最短経路は地球を貫く直線になりますが、実際には地球表面に沿った曲線になります。 SLERP は、2 つのモデルの独自の重み「表面」を維持しながら平均化し、この滑らかな経路を計算します。
以下のコードの抜粋は、SLERP アルゴリズムの中核部分であり、2 つのモデル間の補間をうまく行います。
# Calculate initial angle between v0 and v1
theta_0 = np.arccos(dot)
sin_theta_0 = np.sin(theta_0)
 
# Angle at timestep t
theta_t = theta_0 * t
sin_theta_t = np.sin(theta_t)
 
# Finish the slerp algorithm
s0 = np.sin(theta_0 - theta_t) / sin_theta_0
s1 = sin_theta_t / sin_theta_0
res = s0 * v0_copy + s1 * v1_copy
 
return maybe_torch(res, is_torch)
Task Arithmetic (Task Vector を使用)
このモデル マージ法では、Task Vector を使用してさまざまな方法でモデルを組み合わせることで、複雑さを高めていきます。
Task Vector: カスタマイズの更新をキャプチャ
モデルがどのようにカスタマイズされるのかを思い出してください。モデルの重みが更新され、それらの更新がベース モデルの行列にキャプチャされます。 最終的な行列を真新しいモデルとみなす代わりに、ベースの重みとカスタマイズした重みの差 (またはデルタ) として見ることができます。 これにより、ベースの重みとカスタマイズした重みとの間のデルタが含まれる構造である Task Vector の概念が導入されます。
これは、LoRA (Low Rank Adaptation) と同じ考え方ですが、重みの更新を表す行列を因数分解する追加のステップはありません。
Task Vector は、ベース モデルの重みを減算することで、カスタマイズの重みから簡単に取得できます。
Task Interference: 更新の競合
スポーツ フィールドの例を思い出してください。異なるカスタマイズ間で更新された重みが重なり合う可能性がありました。 同じタスクに対してカスタマイズすると、2 つ以上の別々のタスクに対してカスタマイズを行う場合よりも、高い割合で更新の競合を引き起こすことは直感的に理解できます。
この「更新の競合」という考え方は、より正式には Task Interference (タスクの干渉) として定義されており、2 つ以上の タスク ベクトル間の重要なアップデートが衝突する可能性に関連しています。
Task Arithmetic
Editing Models with Task Arithmetic
の論文で紹介されたように、Task Arithmetic は Task Vector アプローチの最も単純な実装です。 プロセスは以下のとおりです。
2 つ以上のタスク ベクトルを取得し、Model Soup で見られるように線形なマージをする。
結果としてマージされた Task Vector が得られたら、ベース モデルに追加する。
このプロセスは単純で効果的ですが、マージされる予定の Task Vector 間の潜在的な干渉には注意が払われないという、重大な弱点があります。
TIES-Merging
TIES-Merging: Resolving Interference When Merging Models
の論文に紹介されているように、TIES (TrIm Elect Sign and Merge) は、Task Arithmetic の中核となるアイデアを取り入れ、それを Task Vector 間の潜在的な干渉を解決するためのヒューリスティックと組み合わせる方法です。
一般的な手順では、マージされる Task Vector 内の重みごとに、各入力される重みの大きさ、次に各入力される重みの符号を考慮し、その後残りの重みを平均化します。
図 2. TIES プロセスの図による解説
この方法は、任意の重み更新において最も大きな重みに対する更新を行ったモデルを、マージ プロセスにおいて優先されるようにすることで、干渉を解決しようとするものです。要するに、その重みをより「考慮する」モデルが、そうでないモデルよりも優先されます。
DARE
Language Models are Super Mario: Absorbing Abilities from Homologous Models as a Free Lunch
の論文に紹介されている通り、DARE は直接的なモデル マージの技術ではありません。 むしろ、他のアプローチと並行して検討することができる補強です。 DARE は、以下から由来しています。
D
rops delta parameters with a ratio p
A
nd
RE
scales the remaining ones by 1/(1 – p) to approximate the original embeddings (デルタ パラメーターを p の比率でドロップし、残りのパラメーターを 1/ (1 – p) で再スケールして元の埋め込みに近似する)。
ヒューリスティックによって干渉の問題に対処しようとするのではなく、DARE は別の観点からアプローチします。 具体的には、特定の Task Vector で見つかった多数の更新を、0 に設定することでランダムにドロップし、ドロップされた重みの比率に比例して残りの重みを再スケールします。
DARE は、Task Vector の重みが 90% 以上、あるいは 99% 以上ドロップされた場合でも、有効であることが示されています。
モデル マージでモデルの有用性を向上させる
モデル マージの概念は、より大規模なコミュニティによって行われるタスク固有のファインチューニングをはじめとする、複数の LLM の有用性を最大限に高める実用的な方法を提供します。Model Soup、SLERP、Task Arithmetic、TIES-Merging、DARE などの技術を通じて、実験と組織をまたがる取り組みを再利用するために、同系統の複数のモデルを効果的にマージすることができます。
モデル マージの背景にある技術がより深く理解され、さらに発展するにつれて、高性能な LLM 開発の礎石となるでしょう。この投稿は、ほんの表面をなぞったに過ぎませんが、
進化に基づく手法
なども含め、さらに多くの技術が絶え間なく開発されています。モデル マージは、より多くの応用がテストされ、実証されており、生成 AI の新たな分野となっているのです。
関連情報
GTC セッション:
LLM インフラの構築、学習速度の高速化、生成 AI イノベーションの促進のためのエンドツーエンドのソリューションの設計 (Aivres 提供)
NGC コンテナー:
genai-llm-playground
NGC コンテナー:
rag-application-query-decomposition-agent
ウェビナー:
AI で医療ワークフローを変革: CLLM について深く理解する