llama.cpp expérimente l'expansion des experts MoE à l'exécution sans réentraînement

Le 6 septembre 2026, une nouvelle fonctionnalité expérimentale est apparue dans un fork communautaire de llama.cpp. Elle permet aux modèles épars Mixture of Experts (MoE) d'activer davantage d'experts lors de l'inférence, sans aucun réentraînement ni modification des poids. Développée par le contributeur vagrillo et testée sur Qwen 3.6 35B A4B+, cette modification transforme la limite fixe de routage en un budget ajustable à l'exécution, offrant aux ingénieurs IA locaux une nouvelle façon d'équilibrer le coût computationnel et la qualité du résultat.

Ce qui s'est passé

L'innovation principale réside dans le passage d'un routage statique Top-K à une expansion dynamique des experts. Dans les architectures MoE standard, un routeur sélectionne un nombre fixe d'experts, par exemple huit sur trente-deux, pour traiter chaque token. Cette expérience permet au système de sélectionner des candidats supplémentaires au-delà de cette limite native, élargissant ainsi le réseau de voies neuronales consultées à chaque étape de la génération. L'implémentation ne modifie pas les poids du modèle stockés dans les fichiers GGUF, mais change la manière dont ces poids sont accédés et agrégés lors de la passe avant.

Cette approche est actuellement confinée à une branche communautaire et n'a pas été fusionnée dans le dépôt principal ggml-org/llama.cpp. Elle prend en charge divers backends de calcul, visant une compatibilité large plutôt qu'une optimisation exclusive pour les GPU CUDA. Bien qu'elle ait été validée sur des modèles Qwen spécifiques, la fonctionnalité reste à un stade expérimental précoce, ce qui signifie que les paramètres et les comportements peuvent évoluer à mesure que les développeurs affinent la logique de seuillage et de contrôle par couche.

Comment cela fonctionne

L'inférence MoE standard repose sur un routeur qui attribue des scores à tous les experts disponibles et sélectionne les K meilleurs. Cette expérience conserve cette sélection primaire mais ajoute une phase secondaire où les experts ayant obtenu des scores inférieurs sont également invités à contribuer. Pour empêcher ces experts moins confiants de dominer la sortie, leurs contributions sont atténuées via une stratégie d'atténuation. L'influence de ces experts ajoutés peut varier d'un poids quasi complet jusqu'à cinquante pour cent, selon leurs scores initiaux et la courbe de décroissance configurée.

Crucialement, le système prend en charge la configuration par couche. Toutes les couches de transformateur ne bénéficient pas équitablement d'un accès étendu aux experts ; certaines présentent des distributions de routage tranchées où les meilleurs choix sont évidents, tandis que d'autres ont des profils de score plus plats où un contexte supplémentaire est utile. En permettant aux utilisateurs de spécifier quelles couches doivent augmenter leur nombre d'experts actifs, l'outil offre une allocation plus granulaire des ressources de calcul. Cela signifie que vous pouvez cibler les couches « goulot d'étranglement » où l'ambiguïté est maximale sans payer la pénalité de performance sur l'ensemble du réseau.

Détails clés

• Aucun réentraînement requis : La méthode fonctionne entièrement à l'inférence, laissant les poids du modèle et l'architecture intacts.
• Contributions atténuées : Les experts supplémentaires sont inclus avec un poids réduit pour maintenir la stabilité et prioriser les chemins à haute confiance.
• Contrôle spécifique par couche : Les utilisateurs peuvent définir différentes stratégies d'expansion pour différentes couches de transformateur, évitant ainsi une augmentation uniforme des coûts.
• Indépendant du backend : L'implémentation vise à prendre en charge tous les backends de llama.cpp, pas seulement les environnements accélérés par GPU.
• Testé sur Qwen 3.6 : La validation initiale a été effectuée sur le modèle Qwen 3.6 35B A4B+, bien que les résultats puissent varier selon les autres architectures MoE.
• Statut expérimental : La fonctionnalité n'est pas encore présente dans la branche principale de llama.cpp, donc la stabilité de l'API et les noms des paramètres sont sujets à changement.

Pourquoi c'est important

Pour les développeurs créant des applications IA locales, cette expérience découple la capacité du modèle du budget d'inférence. Traditionnellement, on accepte soit la sparsité fixe d'un modèle MoE entraîné, soit on bascule vers une alternative plus dense et plus lente. Cette approche introduit un spectre continu où l'on peut échanger la latence contre la couverture. Si une tâche spécifique, comme la génération de code complexe ou le raisonnement multi-sauts, nécessite une récupération de connaissances plus large, vous pouvez temporairement augmenter le nombre d'experts actifs pour améliorer la robustesse sans déployer un modèle complètement différent.

Cependant, cette flexibilité s'accompagne de compromis d'ingénierie significatifs. Activer davantage d'experts augmente la pression sur la bande passante mémoire et les opérations de multiplication matricielle, ce qui peut affecter sévèrement les taux de tokens par seconde et la latence du premier token. Pour les applications interactives en temps réel, ce délai pourrait être inacceptable. Pourtant, pour le traitement par lots hors ligne, les pipelines d'évaluation ou les scénarios où la précision prime sur la vitesse, ce bouton réglable fournit un levier puissant pour extraire des gains marginaux des modèles existants.

Ce que vous pouvez faire

• Clonez la branche expérimentale depuis le dépôt de vagrillo et compilez-la avec vos flags de backend préférés activés.
• Inspectez la sortie d'aide en ligne de commande pour identifier les noms de paramètres actuels pour l'expansion des experts, car ils ne sont pas encore normalisés.
• Commencez avec des paramètres conservateurs, tels qu'une augmentation du nombre d'experts actifs de seulement vingt-cinq à cinquante pour cent au-dessus du Top-K natif.
• Appliquez l'expansion sélectivement aux couches intermédiaires du transformateur plutôt qu'à l'ensemble du réseau pour minimiser la surcharge de performance.
• Exécutez des benchmarks contrôlés comparant les configurations natives et étendues sur des tâches telles que la génération de code, le raisonnement mathématique et la synthèse de longs contextes.
• Surveillez à la fois les métriques de qualité et les ressources système, en suivant spécifiquement l'utilisation de la bande passante mémoire et la vitesse de génération parallèlement à la précision de la sortie.