mergekit : fusionner des modèles de langue sans données d'entraînement

Le problème : combiner des modèles sans les réentraîner

Entraîner un modèle de langue coûte cher. Fusionner deux modèles déjà entraînés coûte beaucoup moins, à condition d'accepter de travailler directement dans l'espace des poids. C'est la proposition de mergekit : combiner les forces de modèles spécialisés sans passer par un ensemble d'inférence ni par une phase d'entraînement supplémentaire. Le README énonce l'argument central ainsi : un modèle fusionné conserve le coût d'inférence d'un modèle unique, là où un ensemble classique fait tourner plusieurs modèles en parallèle. Le public visé est précis : des praticiens qui ont accès aux poids de plusieurs modèles, qui savent lire une configuration YAML, et qui veulent tester des combinaisons. Le README mentionne aussi la création de nouvelles capacités par combinaisons, ce qui relève de l'expérimentation plutôt que de l'ingénierie reproductible. mergekit est distribué sous LGPL-3.0, une licence de bibliothèque qui impose des obligations dès qu'on redistribue le logiciel modifié, point à examiner avec un juriste si vous en faites un composant embarqué.

Une exécution hors mémoire centrale

Le mécanisme revendiqué par le README tient en une expression : approche out-of-core. mergekit ne charge pas l'intégralité des tenseurs en mémoire. Il les lit à la demande, ce qui autorise des fusions élaborées sur une machine modeste. Le README précise que les fusions peuvent tourner entièrement sur CPU, ou être accélérées avec aussi peu que 8 Go de VRAM. Cette contrainte de 8 Go est une donnée du projet, pas une mesure que j'aurais faite. Elle suppose que le chargement paresseux des tenseurs soit activé, ce que suggère l'option --lazy-unpickle de la ligne de commande. La contrepartie de cette approche est le temps : lire des tenseurs depuis le disque un par un est plus lent qu'un chargement massif en RAM. Le README vante le faible usage mémoire, jamais la vitesse. Si votre machine dispose de beaucoup de RAM et que vous fusionnez souvent, l'approche paresseuse peut devenir un handicap plutôt qu'un avantage.

mergekit-yaml : le point d'entrée

L'installation se fait depuis les sources, ce qui indique que le projet n'est pas pensé comme une simple dépendance pip. Le README donne ces commandes : git clone https://github.com/arcee-ai/mergekit.git, puis cd mergekit, puis pip install -e . pour installer le paquet et rendre les scripts disponibles. Le README signale un cas d'échec connu : si pip se plaint de l'absence de setup.py ou setup.cfg en mode éditable, il faut mettre pip à jour au-delà de la version 21.3 avec python3 -m pip install --upgrade pip. Une fois installé, le script mergekit-yaml est le point d'entrée principal. Il prend un fichier de configuration YAML et un chemin de sortie : mergekit-yaml path/to/your/config.yml ./output-model-directory, avec des options comme --cuda, --lazy-unpickle et --allow-crimes. Le README renvoie à mergekit-yaml --help pour la liste complète des arguments. La sortie est un répertoire de modèle, et mergekit génère un README.md de carte de modèle que vous pouvez éditer avant publication. La mise en ligne passe par huggingface-cli login puis huggingface-cli upload votre_nom/mon-modele ./output-model-directory ., selon l'exemple du README.

La recette YAML et ses clés

Une configuration de fusion est un document YAML. Le README en liste les éléments principaux. merge_method désigne la méthode de fusion. slices décrit des tranches de couches issues de modèles différents, et ce champ est mutuellement exclusif avec models, qui décrit des modèles entiers. base_model intervient dans certaines méthodes. parameters regroupe les poids et densités, et peut être défini à plusieurs niveaux du document, ce qui permet de surcharger des valeurs localement plutôt que de tout réécrire. dtype fixe le type de données utilisé pour l'opération. Le README mentionne également les clés tokenizer et tokenizer_ pour la configuration du tokenizer, ainsi qu'une section dédiée aux gabarits de conversation. Cette structure à plusieurs niveaux est le vrai centre de gravité du projet : la difficulté n'est pas de lancer la commande, mais d'écrire une recette qui produise autre chose qu'un modèle dégradé. Le README ne donne aucune garantie sur ce point, et c'est cohérent avec la nature expérimentale de l'outil.

Éventail des méthodes et extraction LoRA

mergekit ne se limite pas à une moyenne pondérée. Le README liste la fusion de mélange d'experts, les méthodes évolutionnaires, la fusion multi-étapes via mergekit-multi, la fusion de modèles PyTorch bruts via mergekit-pytorch, et la transplantation de tokenizer via mergekit-tokensurgeon. Il mentionne aussi l'extraction LoRA, qui inverse en quelque sorte la logique : au lieu de fusionner des modèles, on extrait la différence entre deux modèles sous forme d'adaptateur. La section sur les gradients interpolés renvoie à un script tiers, BlockMerge_Gradient de Gryphe, ce qui situe une partie des idées en amont du projet. L'assemblage par morceaux de couches, appelé Frankenmerging dans le README, consiste à construire un modèle à partir de couches provenant de sources différentes. Ces méthodes n'ont pas le même coût ni le même risque. Une extraction LoRA et une fusion évolutionnaire ne se valident pas de la même façon, et le README ne fournit pas de protocole d'évaluation. C'est à l'utilisateur de construire le sien.

Ce que mergekit ne fait pas

Le README annonce la prise en charge de Llama, Mistral, GPT-NeoX, StableLM et d'autres architectures, sans donner de liste exhaustive. Si votre modèle n'est pas dans cette famille, il faut vérifier avant de bâtir un pipeline dessus. L'absence de page d'accueil dédiée et le fait que l'installation passe par un clone Git suggèrent un projet piloté par ses contributeurs plutôt qu'un produit avec support. Le README renvoie vers GitHub Issues et un Discord Arcee pour l'aide, ce qui est le signe d'un support communautaire, pas contractuel. Autre point : l'option --allow-crimes existe, et son nom indique assez qu'elle autorise des opérations que l'auteur considère comme douteuses. Le README ne détaille pas ce qu'elle permet, et je ne peux pas le deviner à partir du matériel fourni. Enfin, la fusion de poids ne crée pas de connaissances : elle réorganise ce que les modèles sources contiennent déjà. Attendre d'un merge qu'il apprenne une compétence absente des deux parents est une erreur de raisonnement, pas une limite d'implémentation.

Face à l'ensembling classique

L'alternative directe est l'ensemble d'inférence : faire tourner plusieurs modèles et agréger leurs sorties. La différence d'approche est nette. Un ensemble exige de charger tous les modèles en mémoire au moment de servir, et son coût croît avec le nombre de membres. Un modèle fusionné est un seul jeu de poids, donc un seul chargement. Le README formule la comparaison ainsi : le coût d'inférence reste celui d'un modèle unique, avec des performances parfois comparables ou supérieures. Cette affirmation est celle du projet, pas un résultat que j'aurais reproduit. L'ensembling garde un avantage : il préserve chaque modèle intact, donc on peut revenir en arrière ou changer les poids d'agrégation à chaud. Une fusion est destructive dans le sens où le résultat est un nouveau modèle, et il faut conserver les sources pour recommencer. Si vous avez besoin de tracer précisément la contribution de chaque modèle à une décision, l'ensemble reste plus lisible qu'une fusion de poids.

Coût de maintenance et licence

Le dépôt n'est pas archivé, et la dernière version publiée est v0.1.4, datée du 31 octobre 2025, avec une version legacy remontant à octobre 2023. Un numéro de version en 0.x indique que l'API et les formats de configuration peuvent encore bouger. Concrètement, une recette YAML écrite aujourd'hui peut demander des ajustements après une mise à jour, et les clés de parameters ou de tokenizer sont les endroits les plus susceptibles d'évoluer. Le coût de mise à jour se concentre donc sur la revalidation des recettes, pas sur la réinstallation. La licence LGPL-3.0 implique que si vous distribuez une version modifiée de mergekit, vous devez fournir le code source correspondant sous la même licence. L'utiliser comme outil en ligne de commande pour produire des poids de modèles n'est pas la même situation que l'intégrer dans un produit distribué. Le README ne traite pas ce point, et je ne peux pas trancher à sa place : faites lire la licence par un juriste avant toute redistribution intégrée.

Conclusion éditoriale

mergekit convient à qui veut explorer la fusion de poids sur des modèles Llama, Mistral, GPT-NeoX ou StableLM, en CPU ou avec peu de VRAM, et accepter d'ajuster ses recettes à la main. Il ne convient pas à qui cherche un pipeline de production stable, des garanties de qualité ou un support commercial. Avant d'adopter, vérifiez deux points : que votre architecture figure parmi celles listées dans le README, et que vos poids tiennent dans le disque et la RAM dont vous disposez, puisque mergekit charge les tenseurs en flux plutôt qu'en bloc.

Sources officielles

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