mergekit を採用する前に読む: 重み空間マージの実際と制約

mergekit が埋めるのは「アンサンブルの推論コスト」という穴

複数のモデルを組み合わせて精度を上げる方法としてアンサンブルがあるが、これは推論時に複数モデルを動かす必要があり、レイテンシとメモリがその分だけ増える。mergekit はこれを重み空間で解決する。README には「Unlike traditional ensembling which requires running multiple models, merged models maintain the same inference cost as a single model」とあり、合成後のモデルは単体モデルと同じ推論コストで動く。対象読者は、学習データを持たない、あるいは再学習の計算予算がない状態で、複数のファインチューニング済みモデルの得意分野を1つに寄せたいエンジニアだ。README が挙げる用途には、専門特化モデルの統合、学習データなしでの能力転移、モデル挙動間のトレードオフ探索が含まれる。

out-of-core と遅延ロードが支える実行モデル

README によれば mergekit は out-of-core アプローチを採用しており、テンソルを遅延ロードすることで低メモリでマージを実行する。マージは完全に CPU で実行でき、GPU を使う場合も 8GB の VRAM から加速できると記載されている。ここで重要なのは、マージ対象のモデル全体をメモリに載せる必要がない点だ。複数の巨大モデルを同時に展開する従来のスクリプトとは前提が異なる。実行時のデータフローは、YAML 設定を読み、merge_method に従って対象テンソルを順に読み出し、計算し、出力ディレクトリへ書き出す流れになる。README が示す設定の主要素は merge_method、slices、models、base_model、parameters、dtype、tokenizer で、slices と models は排他指定である。

導入は pip install -e . から、実行は mergekit-yaml

インストール手順は README に明記されている。git clone https://github.com/arcee-ai/mergekit.git で取得し、cd mergekit の後、pip install -e . を実行する。editable インストールが setuptools 関連のエラーで失敗する場合、README は python3 -m pip install --upgrade pip による pip 21.3 以降への更新を案内している。実行の入口は mergekit-yaml で、引数は設定ファイルと出力先ディレクトリだ。README の例は mergekit-yaml path/to/your/config.yml ./output-model-directory [--cuda] [--lazy-unpickle] [--allow-crimes] [...] となっている。--cuda は GPU 加速、--lazy-unpickle は遅延展開に関わるオプションで、受け付けられる引数の全体は mergekit-yaml --help で確認する。出力先にはモデル本体と、マージ情報を記した README.md が生成される。

マージ手法の選択が結果を決める

mergekit は複数のマージアルゴリズムをサポートし、README には「Many merging algorithms are supported, with more coming as they catch my attention」とある。手法の追加ペースが著者の関心に依存するという記述は、手法の網羅性を前提にした設計をしないほうがよいというシグナルだ。README が列挙する機能には、Llama、Mistral、GPT-NeoX、StableLM などの対応、レイヤー単位でモデルを組み立てる Frankenmerging、Mixture of Experts マージ、LoRA 抽出、進化的マージ手法、mergekit-multi による多段マージ、mergekit-pytorch による生の PyTorch モデルのマージが含まれる。設定側では parameters に重みや密度を指定し、階層ごとに与えることもできる。どの手法を選ぶかで得られるモデルの性格が変わるため、config.yml の merge_method は最初に固定すべき判断点になる。

CPU でも動くが、すべてが軽いわけではない

8GB の VRAM で加速できるという記述は、あくまでマージ処理の話であり、マージ後のモデルを推論するための要件ではない。また、out-of-core と遅延ロードはメモリを節約する代わりにディスク I/O を増やす設計であり、ストレージが遅い環境では所要時間が伸びる。README はマージ処理の所要時間やスループットの数値を示していないため、どの程度の時間で終わるかは手元で確かめる以外にない。もう一点、README の Usage 節は FrankensteinAI というホスト型プラットフォームに触れており、ローカル環境を構築せずブラウザで試す経路も存在する。ローカル構築の手間を避けたいだけなら、そちらを先に評価するほうが早い場合がある。

LGPL-3.0 という配布条件をどう扱うか

mergekit 本体のライセンスは LGPL-3.0 である。ツールとしてマージ処理を実行し、生成物を配布する場合にこのライセンスがどこまで及ぶかは、法務判断が必要な領域であり、ここで断定はしない。実務上押さえておくべき点は、生成されたモデルの重みそのものの扱いと、mergekit を組み込んだ形で再配布する場合の扱いが別問題になりうるということだ。README は生成物に README.md を付けて Hugging Face Hub へアップロードする流れを案内しており、huggingface-cli login と huggingface-cli upload your_hf_username/my-cool-model ./output-model-directory . の2コマンドを示している。配布を前提にするなら、このアップロード手順を踏む前にライセンス条件を確認しておくべきである。

代替手段との違いは「重みを触るか、推論を並べるか」

同じ目的を達成する手段として、推論時に複数モデルを並べて出力を統合するアンサンブルがある。README 自身がこの対比を行っており、アンサンブルは複数モデルの実行を必要とするのに対し、マージ済みモデルは単体モデルと同じ推論コストで済むと説明している。違いは計算の発生地点だ。アンサンブルは推論のたびにコストを払うが、マージは一度重みを合成してしまえば以後のコストは単体モデルと同じになる。一方で、マージは重み空間の操作であるため、モデル間でトークナイザやアーキテクチャが揃っていないと成立しない。README が tokenizer と chat template の設定項目を用意しているのはこの制約の表れであり、アンサンブルなら吸収できる差異がマージでは設定作業として表面化する。

採用を決める前に確認しておくこと

最初に確認すべきは、マージ対象モデルのアーキテクチャとトークナイザが揃っているかだ。次に、config.yml で slices と models のどちらを使う構成にするかを決める。両者は排他であり、レイヤー単位で組み替える Frankenmerging を狙うのか、モデル全体を混ぜるのかで設定の形が変わる。実行環境については、CPU 実行か --cuda かを選び、必要なら --lazy-unpickle を付けて試す。受け付けられる引数の一覧は mergekit-yaml --help で確認できる。マージ結果の評価は mergekit の守備範囲外であり、生成された README.md を編集してモデルカードを整える作業も利用者側に残る。

編集部の結論

学習データを持たずに複数のファインチューニング済みモデルの能力を1つにまとめたい、かつ推論コストを増やしたくないチームには向いている。逆に、マージ後のモデルをクローズドに配布したい、あるいはモデルカードを自前で管理したくない場合は LGPL-3.0 の条件を先に確認すべきだ。導入前に mergekit-yaml --help で自分の環境の引数を確認し、config.yml の merge_method と slices のどちらを使う構成かを決めてから最初のマージを走らせるのが安全である。

公式情報源

1. arcee-ai/mergekit on GitHub
2. Issues
3. License: LGPL-3.0
4. README
5. Releases