Comment le routage du modèle Mixture-of-Experts modifie-t-il le calcul local ?
Le routage Mixture-of-Experts modifie le calcul des modèles locaux en faisant passer chaque token uniquement par un petit sous-ensemble de réseaux feed-forward experts, au lieu d’activer tous les experts.
Cela donne un aspect inhabituel aux grands modèles MoE sur un serveur domestique : leur checkpoint total peut être immense, tandis que le calcul effectué par les experts pour un token peut ressembler à celui d’un modèle actif bien plus petit. L’avantage vient de l’arithmétique parcimonieuse, et non d’une mémoire disponible gratuitement. Les poids des experts doivent toujours être stockés, et le routage entre plusieurs appareils peut transformer une partie du calcul économisé en communications.
Un Transformer dense active les mêmes paramètres feed-forward pour chaque token
Dans une couche Transformer dense classique, chaque token passe par le même réseau feed-forward. Augmenter le nombre de paramètres feed-forward accroît donc à la fois la taille du modèle et la quantité de calcul effectuée pour chaque token.
Le Switch Transformer oppose à cela des couches Mixture-of-Experts à activation parcimonieuse, dans lesquelles différents tokens peuvent sélectionner différents sous-ensembles de paramètres.
Pour l’inférence locale, cela crée la première distinction propre aux MoE : le nombre total de paramètres détermine la quantité d’état du modèle à stocker, tandis que le nombre de paramètres activés détermine en grande partie le calcul effectué par les experts pour chaque token.
Un routeur évalue chaque token par rapport aux experts disponibles
Dans une couche MoE, un petit routeur examine la représentation du token et produit des scores ou des probabilités pour les experts candidats. Le moteur d’exécution en sélectionne ensuite un nombre limité, généralement top-1 ou top-k selon l’architecture.
Megatron Core de NVIDIA fournit un routeur qui détermine vers quels experts chaque token est envoyé. La décision de routage modifie les matrices d’experts qui traiteront ce token.
Deux tokens d’un même prompt peuvent donc activer des poids d’experts différents, même s’ils partagent les mécanismes d’attention et les autres parties denses du modèle.
L’activation parcimonieuse réduit le calcul des experts, mais pas le stockage total des poids
Si une couche contient huit experts, mais que chaque token est routé vers deux d’entre eux, seuls les calculs de ces experts sélectionnés sont exécutés pour ce token. Les autres matrices d’experts restent inactives pendant cette étape.
Les travaux sur Expert Choice décrivent les MoE comme un moyen d’augmenter le nombre de paramètres tout en maintenant un calcul par token relativement limité. C’est pourquoi un checkpoint MoE peut afficher un très grand nombre total de paramètres, mais un nombre de paramètres actifs bien inférieur.
Un serveur domestique doit tout de même avoir l’ensemble des poids d’experts disponible quelque part, sauf si le moteur les diffuse ou les déporte. Un calcul parcimonieux n’est pas synonyme de stockage parcimonieux.
Le placement des experts peut transformer le routage en communications entre appareils
Sur un seul GPU, la sélection d’un expert modifie principalement les blocs de poids locaux qui sont lus. Sur plusieurs GPU, les experts peuvent être répartis de sorte que la représentation d’un token doive être transférée vers l’appareil qui possède l’expert sélectionné, puis renvoyée dans le flux principal de la couche.
La conception de l’inférence MoE de DeepSpeed répartit les groupes d’experts grâce au parallélisme d’experts entre les GPU. Le routage inclut alors des communications en plus des multiplications matricielles.
Un petit serveur domestique multi-GPU peut donc être limité par l’interconnexion, même lorsque le calcul de chaque token est parcimonieux. La topologie PCIe et la prise en charge du pair-à-pair comptent davantage que ne le laisse penser le seul nombre de paramètres actifs.
Un routage déséquilibré crée des experts surchargés et une capacité inutilisée
Les prompts réels ne répartissent pas nécessairement les tokens de manière uniforme. Si de nombreux tokens choisissent le même expert, l’appareil ou le noyau correspondant devient un point chaud tandis que les autres experts attendent.
MoETuner identifie le routage déséquilibré des tokens et l’activation des experts comme des goulots d’étranglement pratiques du service, car certains appareils peuvent accumuler davantage de calcul routé et de communications que d’autres.
Pour l’inférence locale, un routage inégal peut se manifester par une latence variable entre les tokens selon les prompts, même lorsque la longueur du contexte et la taille du modèle sont similaires. Le modèle sélectionne dynamiquement un chemin de calcul différent.
Évaluez la capacité MoE locale séparément selon les poids totaux et le chemin actif
Une estimation matérielle utile consigne la taille totale des poids du modèle, le nombre d’experts actifs par token, le coût des couches denses, le cache KV, la quantification, ainsi que l’emplacement des experts : un seul accélérateur, plusieurs GPU, la mémoire vive du CPU ou le stockage.
La présentation de ZimaSpace sur la mémoire et la planification des accélérateurs pour l’IA locale fournit le contexte général de capacité d’un serveur domestique. Les MoE ajoutent une séparation entre la capacité résidente et le calcul actif.
Évaluez des prompts issus de tâches différentes, car les schémas de routage peuvent varier. Mesurez le nombre de tokens par seconde, l’utilisation de chaque appareil, la charge des experts, le trafic de communication et la présence des données en mémoire, au lieu de supposer que le nombre annoncé de paramètres actifs prédit les performances de l’ensemble du système.
Pour les checkpoints locaux particulièrement volumineux, l’analyse du déploiement des grands modèles de ZimaSpace aborde la question connexe de la capacité. Le routage modifie le calcul actif, mais la présence en mémoire de tous les poids et leur répartition entre les appareils déterminent toujours si le modèle est exploitable.
Produits recommandés
Centre Tech & IA
Plus à lire
Les caméras domestiques peuvent-elles synchroniser les événements sans services horaires cloud ?
Une explication axée sur les mécanismes de l’heure de la caméra sans cloud, ses compromis liés aux ressources partagées, trois FAQ sur la diffusion...
Un service d’IA local peut-il détecter les couches de modèle corrompues avant l’inférence ?
Une explication axée sur les mécanismes de la détection des couches de modèle corrompues, de ses compromis en matière de ressources partagées, de trois...
Un système RAG peut-il être restauré sans régénérer chaque embedding ?
Une explication de la restauration RAG sans réencodage, axée sur le mécanisme, de ses compromis en matière de ressources partagées, trois FAQ sur la...
