モデルマージとは？複数LLMを訓練なしで合成して性能を上げる技術

モデルマージとは、複数のファインチューニング済み LLM（大規模言語モデル）の重みパラメータを数学的に合成し、追加学習なしに単一モデルの能力を引き上げる技術です。

GPU コストをほぼかけずに異なるスキルを一つのモデルへ統合できる点が最大の特徴で、LLM カスタマイズの新たな選択肢として研究・実務の両面で注目されています。2022 年末に発表された Task Arithmetic などの手法を皮切りに、TIES・DARE といったアルゴリズムが相次いで登場し、オープンウェイトモデルのコミュニティを中心に急速に普及しています。

本記事では、モデルマージの基本概念から理論的な背景、代表的な手法の比較、実践ツールである MergeKit の使い方、そして活用シーンと注意点まで体系的に解説します。エンジニアや機械学習担当者が読み終えた後すぐに試行できる内容を目指しています。

結論: モデルマージとは、複数の LLM の重みを数学的に合成して単一モデルを生成する技術であり、追加学習を必要としない点が最大の特徴である。

モデルマージの基本概念、ファインチューニングとの違い、そして注目される背景を順に整理します。

モデルマージを初めて聞いたとき、「モデル同士を足し合わせる」と聞くと、出力テキストを混ぜるような処理を想像しがちです。しかし実際に行われているのは、モデルのパラメータ（重み）そのものを数値として合算・補間する操作です。

LLM（大規模言語モデル）は、数十億〜数百億個の浮動小数点数からなる重み行列の集合体です。ファインチューニングを経たモデルは、特定タスクに関する知識をこれらの数値に埋め込んでいます。モデルマージとは、複数モデルの重み行列を要素ごとに演算し、一つの新しい重み行列として統合する技術です。

具体的なイメージとして、最も基本的な手法である重み付き平均（Weighted Average）を例に挙げます。

• モデル A の重み行列: W_A
• モデル B の重み行列: W_B
• マージ後の重み: α × W_A + (1−α) × W_B

この演算だけで、モデル A が持つ日本語能力とモデル B が持つコーディング能力を一つのモデルに統合できる可能性があります。

重要な前提条件が一つあります。合成できるのは、同一のベースモデル（Foundation Model）から派生したモデル同士に限られます。アーキテクチャが異なるモデルは重み行列の次元が一致しないため、直接の演算ができません。同じベースから出発しているからこそ、重みの「意味的な位置」が揃っており、合算しても破綻しにくい構造になっています。

モデルマージは、よく似た目的を持つ他の手法と混同されがちですが、アプローチは根本的に異なります。

主な違いを整理すると、以下のとおりです。

• ファインチューニング: 追加データを用いてモデルの重みを再学習する。GPU 計算コストがかかり、新しいデータセットの準備が必要
• 知識蒸留（Knowledge Distillation）: 大きな教師モデルの出力分布を使い、小さな生徒モデルを訓練する。推論コストの削減が主目的で、やはり学習プロセスが発生する
• モデルマージ: 既存の重みを数学的に合成するだけで、追加学習を一切行わない。データセットも GPU 再学習も不要

判断の軸としては、新しいタスクへの適応や特定ドメインへの精度向上が目的であればファインチューニングが適しており、モデルの軽量化や展開コストの削減が優先事項であれば知識蒸留が有効です。一方、すでにファインチューニング済みの複数モデルが手元にあり、それらの能力を一つに統合したい場合は、モデルマージが最も低コストな選択肢になります。

具体的なイメージとして、「コード生成に強いモデル」と「多言語対応に強いモデル」を別々にファインチューニングした後、両者の重みをマージすることで、どちらの能力も持つ単一モデルを作れます。これは再学習では実現しにくいアプローチです。

ただし、モデルマージはベースモデルが共通である場合に効果を発揮しやすく、アーキテクチャが異なるモデル同士では適用できません。

「GPU コストを抑えながら複数の能力を持つモデルを作りたいが、再学習は現実的ではない」——そう感じたエンジニアは少なくないはずです。モデルマージはまさにその課題に応える形で台頭してきました。

注目を集めた背景には、主に三つの潮流があります。

• オープンウェイトモデルの普及: LLaMA 系をはじめとするオープンウェイトモデルが広く公開され、ファインチューニング済みの派生モデルが大量に生まれた。異なるタスクに特化したモデルを組み合わせるニーズが自然に高まりました。
• 再学習コストの壁: 大規模モデルのフルファインチューニングには高価な GPU リソースと長い学習時間が必要です。追加学習なしに能力を統合できる手法への需要が高まりました。
• 理論的裏付けの蓄積: 2022 年末から 2023 年にかけて、Task Arithmetic（arXiv:2212.04089、ICLR 2023）や TIES-Merging（arXiv:2306.01708、NeurIPS 2023）など、重みの数学的操作に関する査読付き論文が相次いで発表されました。

特に Task Arithmetic の研究は「ファインチューニング後の重みからベースモデルの重みを引いた差分（タスクベクトル）を加減算するだけでスキルを付け外しできる」という直感的な枠組みを示し、実務者の関心を集めました。

その後、DARE（arXiv:2311.03099、ICML 2024）のようにデルタパラメータの冗長性を活用する手法も加わり、複数の能力を低コストで統合するアプローチとして研究コミュニティから実務へと急速に広がっていきました。

結論: モデルマージで性能が向上する背景には、重みの線形補間が有効に機能する損失ランドスケープの特性と、タスク固有の知識が重みに分散して埋め込まれる仕組みがある。

ただし、手法の選択を誤ると干渉問題が生じ、性能が低下するケースもある。

「重みを単純に平均すれば性能が落ちるはず」と直感的に思いがちですが、実際には同じベースモデルから派生したモデル同士であれば、線形補間でも性能が維持・向上するケースが報告されています。この逆説を理解する鍵が「損失ランドスケープ」の構造です。

損失ランドスケープとは、モデルの重みパラメータ空間における損失関数の地形を指します。深層学習の研究では、十分に学習されたモデルの重みは「広く平坦な谷」に収束する傾向があることが知られています。

• 平坦な谷（flat minima）: 重みが多少ずれても損失がほとんど増加しない領域
• 鋭い谷（sharp minima）: わずかな重みの変化で損失が急増する不安定な領域

同一ベースモデルからファインチューニングされた複数モデルは、同じ損失ランドスケープ上の近傍に位置する平坦な谷に収束しやすいとされています。そのため、2 つのモデルの重みを線形補間した中間点も、依然として低損失の領域に留まりやすくなります。

数式で表すと、補間後の重みは以下のように表せます。

• θ_merged = (1 − α) × θ_A + α × θ_B（α は 0〜1 の補間係数）

この補間が有効に機能する前提条件は次のとおりです。

ファインチューニングを行うと、モデルの重みはベースモデルからどのように変化するのでしょうか。

LLM（大規模言語モデル）は事前学習によって汎用的な言語パターンを重みに格納していますが、特定タスクのデータでファインチューニングすると、その差分がタスク固有の知識として重みに蓄積されます。この差分こそが、Task Arithmetic 論文で定義された「タスクベクトル」の正体です。

• タスクベクトル = ファインチューニング後の重み − ベースモデルの重み
• ベースモデルが持つ汎用知識はそのままに、タスク固有の調整だけが差分として分離される
• 複数タスクのタスクベクトルを足し合わせると、それぞれの能力を一つのモデルに統合できる

ここで条件分岐が重要になります。タスク間の関連性が高い場合（例: 英語翻訳と日本語翻訳）はタスクベクトルの干渉が小さく、加算後も両スキルが保たれやすい傾向があります。一方、全く異なるドメイン（例: コード生成と感情分析）では、同一パラメータへの競合する更新が生じやすく、単純加算だけでは品質が低下するケースも報告されています。

DARE の研究では、SFT（教師あり微調整）後の delta パラメータの大部分は冗長であり、90〜99% を除去してもモデルの能力が維持されると報告されています。これは、タスク固有の知識がごく一部の重みに集中して埋め込まれていることを示唆しています。

この性質があるからこそ、重みの差分を数学的に操作するモデルマージが成立します。

「マージさえすれば性能が上がるはずなのに、なぜか精度が落ちた」という経験は、モデルマージを試みたエンジニアが最初にぶつかる壁のひとつです。

マージが失敗する主な原因は、パラメータ干渉にあります。異なるタスクでファインチューニングされたモデルは、同一パラメータに対して互いに矛盾する方向への更新を持つことがあります。これらを単純に平均化すると、どちらのタスクにも最適化されない中間状態が生まれ、両方の性能が低下するケースが報告されています。

失敗しやすい代表的なシナリオは以下のとおりです。

• ベースモデルが異なる: アーキテクチャや事前学習データが異なるモデル同士をマージしても、重み空間の意味が対応していないため、結果は無意味になりやすい
• タスクが意味的に遠い: コード生成特化モデルと感情分析特化モデルのように、学習分布が大きく異なる場合、タスクベクトルの向きが衝突しやすい
• マージ係数の設定ミス: 重み付け係数を適切に調整しないと、一方のモデルの特性が支配的になり、もう一方の能力が埋没する

TIES-Merging（arXiv:2306.01708、NeurIPS 2023）はこの干渉問題に正面から取り組んだ手法です。変化量の小さい冗長なパラメータを刈り込み（Trim）、多数決で符号を選択し（Elect Sign）、合意した符号のみをマージする（Merge）という三段階で干渉を抑制します。

結論: モデルマージには複数のアルゴリズムが存在し、目的や条件に応じて使い分けが必要です。

重み付き平均から Task Arithmetic、TIES、DARE、SLERP まで、アプローチは多岐にわたります。各手法の特性を把握することが、マージ品質を左右します。

最もシンプルなモデルマージの手法が、線形補間（Weighted Average）です。2 つのモデルの重みパラメータを、指定した比率で足し合わせるだけという直感的な方法です。

数式で表すと次のようになります。

• merged = α × model_A + (1 − α) × model_B
• α は 0〜1 の間で設定するブレンド係数

たとえば α = 0.5 なら 2 つのモデルを均等に混ぜ、α = 0.7 なら model_A の特性を強めに反映させる、という調整が可能です。

最初は「単純な平均では、どちらのモデルの強みも薄れてしまうだけでは」と考えがちです。しかし実際には、同じベースモデルから派生したファインチューニング済みモデル同士であれば、重みの線形補間でも双方のスキルを程よく保持できるケースが多く報告されています。これは、同一の損失ランドスケープの近傍に両モデルが存在するためと考えられています。

一方で、線形補間には明確な制約もあります。

• 前提条件: 同一アーキテクチャ・同一ベースモデルから派生していること
• α の調整: 最適な比率はタスクによって異なり、試行錯誤が必要
• 干渉リスク: 異なるドメインを強化したモデル同士では、性能が中途半端になる場合がある

α の探索には、検証セットのスコアを見ながらグリッドサーチを行う方法が一般的です。

Task Arithmetic（タスク算術）は、2022年に発表された論文「Editing Models with Task Arithmetic」で提唱された手法です。その中核にあるのがタスクベクトルという概念で、次の式で定義されます。

タスクベクトル = ファインチューニング後の重み − ベースモデルの重み

つまり、特定タスクへの適応によってベースモデルから「どれだけ変化したか」をベクトルとして取り出す操作です。

このベクトルを使うと、重みの操作が直感的な算術演算に置き換わります。

• 足し算（加算マージ）: 複数タスクのタスクベクトルを足し合わせてベースモデルに加算すると、各タスクの能力を同時に持つモデルを生成できます
• 引き算（能力の除去）: タスクベクトルをベースモデルから引くと、特定タスクへの応答傾向を意図的に弱めることができます
• スケーリング: ベクトルにスカラー係数をかけることで、各タスクの影響度を調整できます

条件分岐の観点で言えば、統合したいタスクが互いに独立している場合は単純な加算で十分なケースが多い一方、タスク間に意味的な重複や干渉がある場合はスケーリング係数を慎重に調整する必要があります。

ただし、Task Arithmetic にはパラメータ干渉という課題が残ります。複数のタスクベクトルを単純に加算すると、重みの符号が衝突して性能が低下することがあります。

「重み付き平均だけでは精度が伸び悩む。もっと賢いマージ手法はないか」と感じたとき、選択肢になるのが TIES・DARE・SLERP の三手法です。

TIES（TRIM, ELECT SIGN & MERGE） は、NeurIPS 2023 で発表されたアルゴリズムです。複数モデルの重み差分（デルタ）が互いに干渉し合う問題を三段階で解消します。

• TRIM: 絶対値が小さいデルタパラメータを刈り取る
• ELECT SIGN: パラメータごとに「正・負どちらの方向へ動かすか」を多数決で決定する
• MERGE: 符号が一致するデルタのみを平均して統合する

符号の衝突を明示的に除去するため、単純平均より干渉が少なく抑えられる傾向があります。

DARE（Drop And REscale） は、ICML 2024 採録の研究で報告された手法です。ファインチューニング後のデルタパラメータには大量の冗長性があるという観察に基づいており、デルタの 90〜99% をランダムに脱落させたあと残存分をスケールアップして補正します。大幅に削減しても能力が維持されると報告されており、TIES と組み合わせて使われるケースも多く見られます。

SLERP（球面線形補間） は、二つのモデルを球面上の弧に沿って補間する手法です。通常の線形補間が「直線」で混合するのに対し、SLERP は重みベクトルの「角度」を保ちながら滑らかに遷移させます。

結論: 理論を理解したら、次は実装ツールの選択とマージ手順の把握が重要です。

モデルマージの実践では、ツール選定・ベースモデルの組み合わせ・評価の3ステップが鍵となります。以降の H3 では、代表的な実装ツールである MergeKit の使い方から、品質確認の方法まで順に解説します。

MergeKit は、arcee-ai が公開しているオープンソースのモデルマージ専用ライブラリです。Task Arithmetic、TIES、DARE、SLERP など主要なアルゴリズムをすべてサポートしており、YAML 形式の設定ファイル一つでマージを実行できます。

最初は「Python スクリプトを一から書けばいい」と考えがちですが、実際には MergeKit の設定ファイルを使うほうが再現性が高く、手順のミスも起きにくいです。

基本的な手順は以下のとおりです。

1. インストール: pip install mergekit でライブラリを導入する
2. YAML 設定ファイルの作成: マージ手法（例: task_arithmetic）、ベースモデルのパス、統合したい各モデルのパスと重み係数を記述する
3. マージ実行: mergekit-yaml config.yaml output_dir/ コマンドを実行する
4. 出力の確認: 指定した出力ディレクトリに Hugging Face 互換形式でマージ済みモデルが生成される

YAML の記述例として、Task Arithmetic を用いる場合は merge_method: task_arithmetic を指定し、各モデルに scaling_coefficient（スケーリング係数）を設定します。係数は通常 0.3〜0.7 の範囲で調整するケースが多く、合計を厳密に 1 へ揃える必要はありません。値を大きくしすぎると元のモデルが持っていた能力が崩れやすいため、検証セットのスコアを確認しながら段階的に調整するのが安全です。

マージ結果の品質は、ベースモデルと統合対象モデルの選択段階でほぼ決まります。適切な組み合わせを選ばないと、重みの干渉が深刻化し、どちらの能力も損なわれる結果になりかねません。

ベースモデル選択の基本条件

まず、マージするすべてのモデルが同一アーキテクチャ・同一パラメータ数であることが前提です。異なるアーキテクチャ間のマージは現状の手法では対応できません。

次に、統合したいモデル群が同じベースモデルからファインチューニングされているかを確認します。例えば、Llama 系のベースモデルから派生した複数のファインチューニング済みモデルは、重みの座標系が共有されているため干渉が起きにくい傾向があります。

統合モデルの選び方：条件分岐の判断軸

目的によって選ぶべき統合モデルの性格が変わります。

• 汎用性を高めたい場合：異なるドメイン（コーディング特化・多言語対応・対話品質向上など）に特化した複数モデルを組み合わせると、単一モデルにない幅広い能力を獲得しやすいです。
• 特定タスクの精度を維持しつつ副次能力を加えたい場合：主軸となるモデルを「強いほう」に設定し、補助モデルの重みを低い係数でブレンドする weighted averaging が適しています。

避けるべき組み合わせ

以下のパターンはマージ品質を著しく下げる可能性があります。

マージが完了した直後、「どの指標を見れば品質を判断できるのか」と迷うケースは少なくありません。評価を体系化しておくと、マージ設定の改善サイクルを素早く回せます。

まず確認すべきは、タスク別のベンチマークスコアです。マージ前の各モデルが得意としていたタスクで、マージ後のスコアが大きく下がっていないかを個別に検証します。具体的には以下の観点で確認します。

• 能力保持の確認: マージ元モデルが高スコアだったベンチマーク（例: 数学推論、コード生成、多言語理解）で、マージ後のスコアが許容範囲内に収まっているか
• 干渉の検出: 一方のタスクを強化したことで、もう一方のタスク性能が著しく低下していないか
• ハルシネーション率: 事実確認が必要な出力において、誤情報の混入が増えていないか

次に、定性的な出力サンプルの目視確認も欠かせません。ベンチマークだけでは捉えきれない文体の乱れや、指示追従性の低下を検出できます。代表的なプロンプトセットを用意し、マージ前後の出力を並べて比較する方法が現場では広く使われています。

最後に、マージ係数（補間比率）の感度分析を行います。係数を 0.1 刻みで変化させながらベンチマークスコアの推移を記録することで、最適なバランス点を特定しやすくなります。

評価結果はスプレッドシートなどで一元管理し、係数・手法・スコアをセットで記録しておくと、後から再現・比較が容易になります。

結論: モデルマージは「複数の能力を低コストで一つのモデルに統合したい」場面で特に効果を発揮する。

多言語化、ドメイン特化、ローカル環境での運用など、用途ごとの代表的な活用シーンを以下の H3 で解説します。

多言語対応と専門ドメイン知識を同時に手に入れようとすると、最初は「一つのモデルを多言語コーパスと専門文書で同時にファインチューニングすればいい」と考えがちです。しかし実際には、二つの学習目標が干渉し合い、どちらの性能も中途半端になるケースが報告されています。モデルマージはこの問題を回避する有力な手段です。

具体的なアプローチは次のとおりです。

• 多言語特化モデル（例: 日英中など複数言語でファインチューニング済み）とドメイン特化モデル（例: 医療・法律・製造など専門コーパスで調整済み）を別々に用意する
• Task Arithmetic などのマージ手法でタスクベクトルを合成し、両方の能力を単一モデルへ統合する
• 追加の GPU 学習コストをほぼかけずに、多言語×専門ドメインの組み合わせを実現できる

この手法が有効な理由は、各モデルがすでに独立したタスクベクトルとして能力を重みに「記録」しているためです。干渉が少ない領域では線形補間でも十分な性能が得られる傾向があります。

一方、注意すべき点もあります。

LoRA（Low-Rank Adaptation）アダプターは、ベースモデルの重みを固定したまま少数のパラメータだけを学習させる手法です。モデルマージと組み合わせることで、両者の長所を引き出すハイブリッド構成が実現できます。

マージとLoRAの使い分け

タスクへの適応幅が広く汎用性を重視する場合はモデルマージ、特定ドメインへの精密な適応が必要な場合はLoRAアダプターの追加学習が向いています。この二段構えを組み合わせると、次のような流れが一般的です。

1. 複数のファインチューニング済みモデルをマージし、多スキルを持つベースを作成する
2. 作成したマージ済みモデルに対して、さらにLoRAで軽量な追加学習を施す
3. 推論時はマージ済み重みにLoRAアダプターを動的に結合して利用する

実践上のメリット

• マージ段階で汎用的な能力（多言語対応・コード生成など）を統合しておくと、その後のLoRAの学習データ量を抑えられる傾向がある
• LoRAアダプターはモデル本体と分離して管理できるため、複数のアダプターを差し替えながら異なるタスクに対応しやすい
• MergeKit はLoRAアダプターをマージ前にベース重みへ吸収（マージ）する機能も持つため、ワークフローをシンプルに保てる

注意点

マージ済みモデルにLoRAを重ねる場合、マージ時に生じた重みの干渉がLoRAの学習に影響することがあります。マージ後の評価で品質が安定していることを確認してからLoRA学習に進むことが望ましいです。

「クラウド API に依存せず、社内データを外部に出さずに LLM を運用したい」という現場のニーズは、オープンウェイトモデルの普及とともに急速に高まっています。モデルマージはこうしたローカル LLM 構築の場面でも、実用的な選択肢として機能します。

オープンウェイトモデルは重みが公開されているため、複数のモデルをマージして一つの推論エンドポイントに集約できます。これにより、以下のような構成が実現しやすくなります。

• 日本語特化モデル × 専門ドメインモデルの統合: 汎用の日本語ベースモデルに、法律・医療・製造などの専門知識でファインチューニングされたモデルをマージし、単一のローカルモデルとして運用する
• パラメータ規模の抑制: 複数のモデルを別々に起動するより、マージ済みの一つのモデルを動かすほうが GPU メモリの消費を抑えられる傾向がある
• LoRA アダプターとの組み合わせ: ベースモデルをマージで強化したうえで、さらに LoRA で軽量な追加調整を行うという二段構えの構成も取れる

MergeKit はローカル環境での実行を前提とした設計になっており、Hugging Face 形式のオープンウェイトモデルであればそのまま利用できます。推論サーバーには Ollama や vLLM などが選択肢として挙げられ、マージ済みモデルをそのままロードして使えます。

注意点として、マージ対象のモデルは同一アーキテクチャかつ同一ベースモデルから派生している必要があります。

結論: モデルマージは万能ではなく、手法の選択ミスやライセンス違反が実運用上の大きなリスクになる。

「混ぜれば性能が上がる」という期待は必ずしも正しくなく、モデル間の干渉や互換性の問題が生じることがあります。また再配布ライセンスへの注意も欠かせません。

モデルマージを始めたばかりの段階では「とにかく複数モデルを合成すれば性能が上がる」と考えがちです。しかし実際には、マージは万能ではなく、条件を満たさない組み合わせでは性能が低下するケースも報告されています。

マージが失敗しやすい主な原因は次の通りです。

• アーキテクチャの不一致: 層数・隠れ次元・アテンションヘッド数が異なるモデル同士は、そもそも重みを対応付けられない
• ベースモデルの差異: 同じアーキテクチャでも、異なるベースモデルからファインチューニングされた場合、重みの意味空間がずれており干渉が生じやすい
• タスク間の競合: 一方のモデルが持つタスクベクトルが他方のタスクベクトルと符号や大きさで衝突すると、どちらの能力も中途半端になる

TIES-Merging の研究では、単純な重み付き平均では符号の衝突によってパラメータが相互に打ち消し合う「干渉問題」が発生すると報告されています。これが「混ぜるほど良くなる」という直感が崩れる主な理由です。

品質を保つための判断基準として押さえておきたい点は以下の通りです。

• 同一ベースモデルから派生したモデル同士を選ぶ
• マージ後は必ずベンチマークや実タスクで評価し、ベースモデルとの比較を行う
• マージ係数（補間比率）を小さく始め、段階的に調整する

モデルマージは「試行錯誤を前提とした技術」です。合成前の仮説設計と合成後の評価をセットで行うことが、期待した性能向上を得るための現実的なアプローチといえます。

マージ元のモデルが異なるライセンスを持つ場合、生成したマージモデルの再配布は法的なグレーゾーンに入ります。

注意すべきポイントは以下の通りです。

• 商用利用の可否: Llama 系モデルは独自の利用規約を持ち、商用利用や再配布に条件が付く場合があります。マージ元に 1 つでも商用禁止モデルが含まれる場合、マージ後のモデル全体が商用利用不可になるリスクがあります
• ライセンスの伝播: Apache 2.0 や MIT などのオープンライセンスは比較的再配布しやすい一方、独自の非商用ライセンスや「研究目的限定」の条件は、マージ後も引き継がれると解釈されるケースがあります
• ウェイトの公開制限: 一部のモデルはウェイトそのものの再配布を明示的に禁止しています。マージ後のモデルもウェイトを含む以上、この制限の対象になる可能性があります

ライセンス条件の確認は、マージ元モデルごとに個別に行うのが原則です。社内利用のみを目的とする場合はリスクが低い一方、Hugging Face などのプラットフォームで公開・配布する場合は、すべてのマージ元ライセンスを精査し、必要に応じて法務担当者への確認を行うことが推奨されます。

また、モデルカードへの記載も重要です。マージ元モデルの名称・バージョン・ライセンスを明記することで、利用者が適切に判断できる環境を整えることが、責任あるAI（Responsible AI）の観点からも求められます。公式の最新ライセンス条件は各モデルの公式ページで必ず確認してください。