mergekit：把多個語言模型拆開重組的開放工具，值得一試嗎？
Tools for merging pretrained large language models.
秒懂
- 它是什麼？
- mergekit 是一套以 YAML 描述、在 CPU 或低 VRAM 環境下合併預訓練語言模型的 Python 工具。本文拆解它的運作機制、設定語法、限制與替代方案。
- 適合誰用？
- 若你手上有多個互補的開放模型，想在不重新訓練的前提下組合能力，且能接受合併結果的不可預測性，mergekit 是少數把這類流程工具化的選擇。你不需要高階 GPU，8 GB VRAM 就能跑，甚至純 CPU 也可運作。
- 可以商用嗎？
- 可以，但有條件。LGPL-3.0 是弱 copyleft 授權：可以用在商業與閉源軟體中，但如果你散布了對它本身檔案的修改，這些修改必須以同一授權公開。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 4 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
為什麼有人要合併語言模型
訓練一個語言模型要花大量資料與算力。合併不同模型，是想在權重空間直接組合能力，例如把擅長寫程式的模型和擅長對話的模型結合成一個。這種做法不需要原始訓練資料，也不需要梯度更新。比起同時跑多個模型的 ensemble，合併後的模型推論成本與單一模型相同。mergekit 就是為此設計的工具箱，目標使用者是那些想快速實驗模型組合、卻沒有大規模 GPU 叢集的開發者。它宣稱可以在 8 GB VRAM 的條件下加速執行，甚至完全用 CPU。這點對一般開發者很實際，因為多數合併實驗不需要即時回應。
合併的實際機制：從張量到層級拼裝
mergekit 的運作核心是 out-of-core 方式，也就是不把整個模型一次載入記憶體，而是懶載入張量。這樣一來，即使模型總體積超過記憶體，也能逐塊處理。合併方法分成兩大類。一類是整模型合併，例如 weighted sum 或 SLERP，這類方法對所有參數做插值。另一類是切層組合，也就是所謂的 Frankenmerging，從不同模型挑選不同的層拼成一個新模型。設定檔裡用 slices 指定每個區段來自哪個模型、哪些層。這種做法可以做出很奇怪的結構，README 裡甚至有個參數叫 allow-crimes，暗示某些組合超出常規。參數的插值還支援漸變，靈感來自 Gryphe 的 BlockMerge_Gradient 腳本。也就是說，不同區段之間的權重可以平滑過渡，而不是硬切。
動手跑一次：安裝與基本指令
安裝方式是從 GitHub 複製倉庫，然後用 pip 以可編輯模式安裝。指令是 git clone 與 pip install -e .。如果 pip 版本太舊，會碰到 setuptools 的錯誤，README 建議升級到 21.3 以上。主要入口是 mergekit-yaml 這個命令列工具。它接受一個 YAML 設定檔和輸出目錄，例如 mergekit-yaml config.yml ./output-model-directory。可加 --cuda 使用 GPU，加 --lazy-unpickle 減少記憶體，還有 --allow-crimes 放寬限制。設定檔的基本欄位有 merge_method、slices 或 models、base_model、parameters、dtype。slices 與 models 互斥，前者用於層級拼裝，後者用於整模型合併。parameters 可以放在不同層級，例如全域或單一模型，控制權重與密度。合併後 mergekit 會自動產生一個 README.md，方便上傳到 Hugging Face。上傳方式是用 huggingface-cli login 後再 upload。
進階功能：LoRA、MoE 與多階段流程
除了基本合併，mergekit 還提供幾個進階工具。LoRA extraction 可以從合併後的模型萃取出 LoRA 適配器，這對只想散佈小型更新檔的人有用。Mixture of Experts merging 則是把多個密集模型轉成 MoE 結構，這在近年很受關注，因為 MoE 可以在不增加推論成本的情況下擴大參數量。另有 mergekit-multi 支援多階段合併，適合複雜的工作流程，例如先合併幾個模型，再拿結果去跟另一個模型合併。還有一個 mergekit-pytorch，可以直接合併原始的 PyTorch 模型，不需要先轉成 Hugging Face 格式。最後是 tokenizer transplantation，工具名稱叫 mergekit-tokensurgeon，可以把一個模型的 tokenizer 移植到另一個模型。這功能很重要，因為合併模型時若詞表不一致，輸出會出問題。
真正的限制：合併不是訓練，結果難以預測
mergekit 的文件對優點著墨較多，但合併本身有本質限制。合併是在權重空間做算術，不是學習新的對應關係。兩個模型即使各有專長，合併後可能互相干擾，例如知識衝突或能力衰減。README 提到可以轉移能力而不用訓練資料，但沒有保證效果。另外，合併方法很多，每種適用的模型架構不同。mergekit 支援 Llama、Mistral、GPT-NeoX、StableLM 等，但並不支援所有架構。如果你的模型不在清單內，可能需要自己實作或改用其他工具。還有一個實際問題：合併後的模型沒有對應的訓練歷程，除錯困難。當輸出品質下降時，你很難判斷是哪一層、哪個權重出了問題。allow-crimes 這個參數的存在也說明，某些組合可能產生無效模型，只是工具不會阻止你。
替代方案：ensemble 與直接訓練的差異
mergekit 的定位是合併，最直接的替代方案是傳統的 ensemble 方法。ensemble 在推論時同時跑多個模型，然後對輸出做投票或平均。這種做法不需要修改權重，每個模型都保持原樣，因此能力不會互相干擾。但代價是推論成本隨模型數量線性增加，而且需要更多記憶體。另一個替代方案是直接對模型做額外訓練或微調，例如用 LoRA 調整特定能力。這需要訓練資料與 GPU，但結果更可控，因為有明確的損失函數。mergekit 的價值在於它完全不需訓練，門檻低很多。但如果你追求的是可預期的能力提升，而不是碰運氣的組合，ensemble 或微調可能更適合。還有一類工具是做模型蒸餾，但那需要教師模型與大量資料，與合併的假設完全不同。
維護成本與授權注意事項
從倉庫活動來看，最後一次推送是 2026 年 6 月，代表專案仍在維護。授權是 LGPL-3.0，這對 Python 專案來說相對少見。LGPL 要求修改後的程式碼以相同授權釋出，但若只是動態連結使用，則有較多彈性。不過 mergekit 是命令列工具，多數使用者只是執行它，不會修改原始碼，這部分影響較小。真正的授權問題在於輸入的模型。合併後的模型內含多個原始模型的權重，每個原始模型都有自己的授權條款。例如某些模型禁止商用或要求衍生作品沿用相同授權。mergekit 本身不會檢查這些，它產生的 README.md 只包含基本資訊，不會自動附加授權聲明。使用者在發布合併模型前，必須自行確認所有輸入模型的授權相容性。升級成本方面，mergekit 有定期釋出，v0.1.4 在 2025 年 10 月。每次升級可能改變 YAML 格式或方法行為，但由於設定檔是純文字，版本控制相對容易。
編輯結論
若你手上有多個互補的開放模型，想在不重新訓練的前提下組合能力，且能接受合併結果的不可預測性，mergekit 是少數把這類流程工具化的選擇。你不需要高階 GPU，8 GB VRAM 就能跑，甚至純 CPU 也可運作。但若你的目標是要可重現、可解釋的模型行為，或需要官方等級的支援，這套工具可能不適合。它本質上是實驗性拼裝，README 自己都用 allow-crimes 這類參數暗示界線模糊。採用前應先確認：你的模型架構是否在支援清單內，合併方法是否與模型類型匹配，以及輸出模型的授權是否仍符合原始模型的條款。最後，務必用一套自己的評估集跑過合併前後，不要只看 perplexity 或幾個樣本。合併的價值在於省下訓練成本，但驗證成本不會消失。
社群筆記