Le déport CPU MoE de llama.cpp ajoute une alternative réglable aux transferts GPU
llama.cpp a fusionné la pull request n°30966 le 7 novembre, ajoutant l’exécution sur CPU pour certaines absences d’experts dans le cache, au lieu de toujours transférer ces experts. Cette mise à jour de déport CPU MoE de llama.cpp, apportée par am17an, introduit également un script permettant de régler l’équilibre sur chaque machine. Son importance réside dans ce choix, et non dans une augmentation de vitesse garantie.
MoE, abréviation de mixture of experts, désigne des modèles qui activent des composants de réseau neuronal sélectionnés pour chaque token, une unité de texte généré. Ces composants sont appelés experts. Conserver les experts fréquemment utilisés dans la mémoire GPU aide, mais un expert absent crée tout de même une charge de travail quelque part. La nouvelle option modifie l’endroit où ce travail est effectué.
Le principal arbitrage oppose le calcul CPU au transfert des poids des experts, les valeurs numériques stockées qu’un modèle utilise, pour une exécution sur GPU. Strata offre une comparaison utile, car sa documentation décrit déjà comment régler cet équilibre. Pour les personnes exécutant des modèles au-delà de la capacité de leur mémoire graphique, la question pratique est de savoir quel chemin s’achève le plus rapidement sur leur configuration réelle.
Ce que change le déport CPU MoE de llama.cpp
La mise à jour transforme une absence dans le cache en choix d’ordonnancement entre calcul et déplacement de données.
Un cache conserve des données réutilisables à proximité du processeur qui en a besoin. Une absence dans le cache survient lorsque les données demandées sont indisponibles. Ici, les données manquantes appartiennent à un expert requis pendant l’inférence, le processus de génération de la réponse d’un modèle.
Le nouveau comportement n’élimine pas le besoin de cet expert. Il crée plutôt une autre façon d’effectuer son calcul. Cette distinction importe, car éviter un transfert et éviter le travail du modèle sont deux affirmations fondamentalement différentes.
La solution de repli CPU fusionnée comprend un exemple fourni par l’auteur qui illustre ce compromis. Avec un cache de 6 464 MiB, la génération est passée de 24,2 à 47,6 tokens par seconde lorsque la part CPU est passée de zéro à 0,95. Avec un cache de 19 392 MiB, ces réglages ont produit respectivement 65,5 et 54,1 tokens par seconde.
MiB signifie mébioctets, une mesure binaire de capacité mémoire. Ces résultats sont des mesures rapportées dans l’exemple de l’auteur, et non des conclusions reproduites indépendamment sur d’autres machines. Ils montrent pourquoi le composant de réglage mérite de l’attention aux côtés du changement d’exécution.
Un lecteur ne regardant que le résultat avec le cache le plus petit constaterait une amélioration substantielle. Un lecteur ne regardant que la comparaison avec le cache plus grand constaterait une régression. Les deux observations font partie de l’histoire, car le réglage interagit avec le reste de la configuration.
La conclusion utile est plus limitée que « le déport CPU est plus rapide ». Différentes allocations de ressources peuvent modifier le chemin d’exécution préférable. Un réglage qui aide une configuration contrainte peut devenir contre-productif lorsqu’une plus grande quantité de données d’experts reste près du GPU.
Cela change la manière dont les passionnés devraient interpréter les affirmations d’optimisation. Un résultat impressionnant peut révéler un mécanisme prometteur sans établir une valeur par défaut pour tout le monde. Les éléments disponibles deviennent plus utiles lorsqu’ils expliquent où l’amélioration apparaît et où elle disparaît.
Cela modifie aussi la responsabilité des interfaces logicielles. Lorsqu’un moteur expose un choix dont la meilleure valeur dépend de la machine, les utilisateurs ont besoin d’aide pour le sélectionner. Sinon, ajouter de la flexibilité peut créer une nouvelle occasion de choisir un réglage inadapté.
Pour les développeurs d’applications, cette évolution doit être comprise comme une variable de déploiement supplémentaire. Elle n’établit pas un niveau de performance universel pour une application utilisant llama.cpp. L’application doit toujours être évaluée selon ses propres schémas de requêtes.
C’est l’importance immédiate de la fusion : un chemin d’exécution supplémentaire existe désormais dans le projet principal. La question de savoir s’il améliore une installation donnée reste empirique.
Une VRAM limitée fait du temps de transfert une part du budget de performance
Les utilisateurs les plus concernés sont ceux qui répartissent un modèle entre mémoire graphique et mémoire système.
La VRAM est la mémoire reliée à un processeur graphique. La RAM système est la mémoire de travail principale de l’ordinateur. Lorsqu’une installation dépend des deux, les discussions sur les performances doivent tenir compte de leur relation.
La capacité à charger un modèle n’est qu’un point de départ. Les lecteurs s’intéressent aussi au délai avant qu’une réponse commence, à la régularité de son arrivée et au fait que l’ordinateur reste utilisable. Un chiffre de capacité seul ne peut répondre à ces questions.
Prenons le cas d’un développeur évaluant un assistant de programmation local. L’assistant doit lire une requête, produire une réponse et gérer les modifications suivantes. Un résultat mesuré pendant une génération ininterrompue ne décrit qu’une partie de cette expérience.
Il s’agit d’un scénario de déploiement illustratif, et non d’un benchmark rapporté. Son objectif est d’identifier les décisions que la nouvelle option met en évidence. La question pertinente est de savoir si modifier l’exécution des experts améliore l’interaction complète du développeur.
Une distinction similaire s’applique à l’analyse de documents. Un utilisateur peut soumettre un volume important de documents source, puis poser plusieurs courtes questions de suivi. La configuration la plus utile devrait prendre en charge ce schéma, plutôt que de simplement maximiser la vitesse lors d’un test différent.
Decode désigne l’étape durant laquelle un modèle génère une sortie progressivement. Prefill désigne l’étape durant laquelle il traite un prompt entrant. Ces étapes méritent d’être mesurées séparément, car une amélioration de l’une ne démontre pas une amélioration de l’autre.
Pour les acheteurs comparant du matériel, cela plaide contre le fait de traiter la capacité de mémoire graphique comme une prévision complète des performances. La capacité reste pertinente, mais le comportement du logiciel fonctionnant dans cette capacité l’est aussi. L’ensemble de la configuration doit être examiné.
Pour les personnes qui maintiennent des services d’IA locale, la pression est plus immédiate. Elles ont besoin d’une explication défendable des réglages qu’elles déploient. Copier une commande depuis un système apparemment plus rapide ne démontre pas que cette commande convient à leur propre environnement.
L’évaluation pratique devrait donc commencer par une charge de travail, et non par un paramètre favori. Une session de programmation, une conversation documentaire ou une requête de service répétée donne un objectif au test. La performance devient alors une mesure de l’accomplissement de cet objectif.
Il existe aussi une différence entre l’expérimentation personnelle et le déploiement partagé. Un passionné peut accepter des réglages occasionnels comme faisant partie de l’usage du logiciel. Une équipe a besoin de réglages que ses collègues peuvent reproduire et examiner lorsque les résultats changent.
Cela rend les enregistrements de configuration précieux. Les équipes construisant une base de connaissances consultable peuvent conserver les conditions de test avec les notes de déploiement. L’enregistrement devrait expliquer la charge de travail et le résultat, plutôt que de stocker une commande sans contexte.
L’implication plus large est simple : un logiciel peut offrir davantage de façons d’utiliser le matériel existant, mais ces choix exigent des preuves. Davantage de contrôles disponibles ne produisent pas automatiquement un meilleur déploiement.
Pourquoi calculer une absence peut être préférable au déplacement d’un expert
La comparaison pertinente est le temps requis par chaque chemin d’exécution complet.
Selon le comportement du cache d’experts du projet, les experts en cache s’exécutent sur le périphérique. Une fois le cache rempli, --moe-cache-cpu-share sélectionne une part des absences à calculer sur CPU. Les autres absences sont transférées vers le périphérique, tandis que les premières absences continuent d’être téléversées pour remplir le cache.
La documentation décrit des conditions favorables au travail CPU, notamment une mémoire système rapide et des transferts plus lents. Elle avertit également que la mémoire épinglée, mémoire hôte maintenue disponible pour les transferts vers le périphérique, peut réduire le bénéfice. Son optimum déclaré dépend de la machine, du modèle et de la taille du cache.
Cette explication appuie une interprétation précise. La fonctionnalité traite le coût d’accès aux données autant que le coût du calcul avec celles-ci. Évaluer un processeur uniquement selon sa capacité arithmétique laisse de côté une partie du chemin d’exécution.
Une analogie consiste à décider où traiter un fichier volumineux. L’envoyer vers une machine plus rapide introduit un transfert avant que le calcul puisse s’achever. La pertinence de cette opération dépend du travail complet, plutôt que de la vitesse de destination seule.
L’analogie a ses limites, mais elle clarifie la décision. Une destination plus rapide ne garantit pas un résultat plus précoce lorsque l’atteindre prend du temps. Inversement, éviter un déplacement ne garantit pas le succès si le traitement local prend plus longtemps.
Le cache ajoute une autre dimension, car la décision concerne des données manquantes, plutôt que l’ensemble du travail de manière égale. Une configuration ayant un comportement de réutilisation différent modifie le travail qui reste en dehors du cache. C’est pourquoi un chiffre de part CPU nécessite son contexte.
C’est aussi pourquoi le taux de succès du cache, la fraction des requêtes servies depuis les données en cache, est un objectif incomplet. Un taux plus élevé semble souhaitable. Ce qui importe en définitive pour l’utilisateur est toutefois le temps nécessaire à la réponse.
Une métrique d’optimisation devrait expliquer le résultat visible par l’utilisateur au lieu de le remplacer. Si une configuration améliore une mesure intermédiaire tout en ralentissant les réponses, cette mesure intermédiaire n’a pas justifié le changement. Le même raisonnement s’applique dans l’autre sens.
L’opposition reste ici le déplacement de données contre l’exécution CPU. Il est inutile d’en faire une affirmation selon laquelle les CPU sont généralement supérieurs aux GPU. La mise à jour concerne une décision d’allocation particulière au sein d’un processus d’inférence plus vaste.
Ce cadrage permet également de distinguer cette histoire des changements apportés à l’intelligence du modèle. Sélectionner un lieu d’exécution ne constitue pas une preuve d’un meilleur raisonnement, de capacités de programmation plus solides ou d’une réponse plus exacte. Ces résultats exigent des évaluations différentes.
Pour les utilisateurs disposant de peu de VRAM, l’attrait du déport CPU MoE de llama.cpp est donc conditionnel et concret. Il offre une autre manière de résoudre le travail lié aux experts manquants. Le temps de réponse qui en résulte détermine si cette option est utile.
La leçon analytique dépasse ce correctif : mesurez le chemin complet qui accomplit la tâche. Les spécifications des composants peuvent orienter les attentes, mais elles ne peuvent se substituer à l’observation du système déployé.
Le script de réglage transforme la configuration en décision mesurée
Le script transforme une option d’exécution en recommandation, tout en distinguant les performances mesurées des performances prédites.
Le script de réglage du cache qui l’accompagne évalue les tailles de cache et les parts CPU au moyen d’exécutions répétées du serveur. Il modélise le comportement de la machine et prédit des combinaisons supplémentaires. Sa règle de sélection privilégie la plus faible part CPU située à moins de 5 % du résultat modélisé le plus rapide.
Le code comprend aussi une vérification de la correspondance entre le modèle de chronométrage et les observations. Si l’écart dépasse son seuil, il s’arrête avec un diagnostic au lieu de présenter une recommandation normale. C’est une limite utile à la confiance accordée à l’outil.
La distinction entre observation et prédiction mérite d’être soulignée. Un résultat mesuré décrit ce qui s’est produit pendant une exécution. Une prédiction estime un résultat non mesuré au moyen d’hypothèses ajustées aux observations.
Aucune de ces catégories n’est intrinsèquement suffisante pour un déploiement. Les mesures peuvent décrire une tâche non représentative. Les prédictions peuvent ne pas saisir le comportement en dehors des conditions ayant servi à les construire. Une évaluation utile relie les deux à l’application que les personnes ont réellement l’intention d’utiliser.
La valeur du script est qu’il fournit un point de départ structuré. Les utilisateurs peuvent examiner une recommandation plutôt que d’assembler une combinaison arbitraire de paramètres. Cela réduit les tâtonnements sans rendre le résultat universel.
Il donne également une meilleure structure aux discussions sur les performances. Au lieu de demander quelle part de CPU chacun devrait utiliser, les utilisateurs peuvent se demander si la recommandation convient à leur charge de travail. Cette dernière question est plus facile à examiner et plus informative lorsqu’elle reçoit une réponse.
Strata apporte un contexte concurrentiel pertinent. Ses contrôles de calibration matérielle incluent une fraction de transfert d’experts et le réglage des workers CPU. Sa documentation décrit la mesure des paramètres sur la machine de l’utilisateur et la conservation des améliorations répondant aux critères.
Cela établit une similitude d’approche, non une égalité d’implémentation ou de performances. Les deux descriptions reconnaissent que les choix dépendants du matériel bénéficient de mesures. Aucune ne fournit de résultat comparatif contrôlé entre les moteurs.
Cette distinction importe car la discussion source compare explicitement l’idée à Strata. Cette comparaison est raisonnable au niveau de la calibration. Elle n’établit pas que llama.cpp a copié une implémentation particulière ni qu’il a atteint la vitesse d’un autre moteur.
Pour les mainteneurs de moteurs, la calibration soulève également une question produit. Quelle part des performances devrait dépendre du fait que l’utilisateur sache quels contrôles existent ? Une capacité qui exige une découverte spécialisée impose une charge pratique, même lorsqu’elle fonctionne comme prévu.
Pour les développeurs d’interfaces, une recommandation nécessite une explication. Les utilisateurs devraient pouvoir distinguer une valeur par défaut, un réglage mesuré et une estimation. Présenter ces catégories de manière identique compliquerait le dépannage ultérieur.
Il n’est pas nécessaire de promettre que le réglage élimine la complexité. Son rôle le plus défendable est de rendre cette complexité inspectable. Une recommandation devient précieuse lorsque les utilisateurs peuvent comprendre ses conditions et vérifier ses conséquences.
C’est l’importance plus forte de l’association entre changements d’exécution et calibration. Le projet propose une manière de sélectionner le nouveau comportement, plutôt que de laisser ce choix entièrement aux essais et erreurs.
L’enthousiasme initial laisse d’importantes lacunes de vérification
La fonctionnalité fusionnée est vérifiée ; une accélération générale sur les systèmes grand public ne l’est pas.
La discussion communautaire initiale sur les performances contient de l’enthousiasme, mais aussi des demandes de consignes plus claires. Un commentateur demande une meilleure visibilité sur la mise en cache des experts et les goulots d’étranglement des transferts. Un autre demande comment interpréter la sortie de l’outil de réglage pour un usage courant.
La réponse du contributeur est à juste titre nuancée. Am17an décrit le script comme fournissant des paramètres potentiellement proches de l’optimum et évoque des travaux vers un mode automatique. Il s’agit d’une orientation de développement, non d’une preuve que la configuration est résolue.
Ces réactions identifient différentes normes de réussite. Un développeur peut valoriser le chemin d’exécution supplémentaire. Un utilisateur expérimenté peut valoriser l’accès aux données de réglage. Une personne installant un assistant local peut simplement vouloir un comportement sensé sans étudier l’un ou l’autre.
Ces attentes sont compatibles, mais elles ne sont pas interchangeables. Un correctif peut satisfaire la première tout en laissant du travail sur les autres. Le compte rendu devrait préserver cette distinction au lieu d’attribuer à chaque amélioration le même niveau de maturité.
Les éléments de référence issus des benchmarks nécessitent également une limite claire. Les exemples fournis par l’auteur sont utiles parce qu’ils révèlent un comportement qui mérite d’être testé. Ils ne remplacent pas une reproduction indépendante, surtout lorsque le point central de l’article est que les configurations se comportent différemment.
Une comparaison équitable maintiendrait constants le modèle et la charge de travail tout en modifiant le paramètre d’exécution étudié. Sinon, une amélioration apparente pourrait refléter une autre différence. Il s’agit d’une exigence méthodologique, non d’une accusation concernant l’exemple publié.
La quantification du modèle, qui réduit la précision numérique utilisée pour stocker les poids, devrait également rester cohérente dans une comparaison. La modifier change l’expérience. La même prudence s’applique à différents fichiers de modèle présentés sous un nom de modèle familier.
L’expérience utilisateur nécessite une évaluation plus large que la seule vitesse de génération. Un court délai au début et des pauses répétées pendant la sortie affectent les personnes différemment. Une moyenne peut masquer l’un ou l’autre ; le compte rendu devrait donc expliquer ce que représente la mesure.
L’activité de la machine mérite également de l’attention. Un assistant local partage souvent un ordinateur avec d’autres applications. Une configuration choisie sur un système par ailleurs inactif doit être vérifiée dans les conditions où l’assistant fonctionnera réellement.
Ces considérations n’invalident pas la fonctionnalité. Elles définissent les éléments nécessaires pour juger son utilité. La position sceptique est qu’un mécanisme prometteur devrait être testé dans des conditions pertinentes avant que ses gains ne deviennent des affirmations générales.
Les rapports communautaires les plus utiles incluront donc aussi des résultats non concluants. Un réglage qui fait perdre des performances aide à identifier les limites de l’optimisation. Sans ces rapports, les lecteurs risquent davantage de prendre un exemple favorable pour une règle.
Pour l’instant, le déchargement CPU MoE de llama.cpp permet une conclusion prudente : les utilisateurs disposent d’une option supplémentaire qui mérite d’être évaluée. Les éléments disponibles ne justifient pas de conseiller à chaque système contraint de maximiser la participation du CPU.
Surveiller la reproductibilité, le réglage intégré et les résultats applicatifs
Les prochaines étapes devraient montrer si cette flexibilité devient une performance fiable dans un usage courant.
Le premier signal est une reproduction indépendante sur des configurations clairement décrites. Les rapports devraient indiquer le fichier de modèle exact, la version du logiciel, la charge de travail et les paramètres. Leur valeur vient de la possibilité offerte à une autre personne de comprendre et répéter la comparaison.
Des gains cohérents dans des configurations limitées par les transferts renforceraient l’argument en faveur du nouveau chemin d’exécution. Des résultats incohérents ne l’invalideraient pas automatiquement. Ils rendraient plus importants un meilleur diagnostic et des recommandations plus ciblées.
Le deuxième signal est le passage d’un script séparé à une assistance de configuration intégrée. Dans une proposition de réglage automatique du 7 novembre, am17an suggère un outil plus large pour sélectionner des paramètres spécifiques au modèle. Le contributeur angt soutient de meilleures bases pour les benchmarks et évoque une possible commande de paramètres de cache.
Il s’agit de propositions et de discussions, non d’une interface universelle de réglage déjà livrée. Ce statut devrait rester explicite. Le développement important serait une implémentation qui rend les mesures pertinentes accessibles et explique ce que couvrent ses recommandations.
Si une assistance intégrée voit le jour, elle renforcerait l’argument d’utilisabilité de la fonctionnalité. Si la configuration continue d’exiger l’interprétation de sorties distinctes, les utilisateurs expérimentés conserveront de la flexibilité. La charge pour les utilisateurs moins techniques restera plus élevée.
Le troisième signal est l’évaluation au sein d’applications complètes. Les assistants de programmation et les outils documentaires devraient indiquer si les paramètres améliorent les interactions réalisées par leurs utilisateurs. Cela implique d’examiner les délais de réponse, l’usage prolongé et le comportement lors de sessions réalistes.
Des gains au niveau applicatif rendraient la mise à jour plus conséquente qu’un résultat de génération isolé. Des gains faibles ou incohérents limiteraient sa pertinence à certaines charges de travail. Dans les deux cas, les développeurs disposeraient de meilleures informations qu’avec un seul chiffre de vitesse en titre.
Ces signaux doivent être lus dans l’ordre. La reproduction établit où le mécanisme apporte une aide. Le réglage intégré détermine avec quelle facilité les utilisateurs peuvent accéder à cet avantage. Les résultats applicatifs établissent s’il améliore l’expérience qui intéresse réellement les personnes.
La comparaison avec Strata appartient à ce cadre. Une comparaison future utile évaluerait les deux moteurs face à une tâche définie dans des conditions divulguées. Elle ne devrait pas commencer par désigner un gagnant à partir de résultats communautaires sans rapport.
Au cours des prochains mois, les preuves les plus solides combineront transparence technique et pertinence pratique. Davantage de paramètres ne sont pas l’objectif. L’objectif est d’aider une personne à choisir une configuration qui sert son travail de manière fiable.
Pour les lecteurs qui envisagent le déchargement CPU MoE de llama.cpp, commencez par la question à laquelle votre déploiement doit répondre. Réduit-il l’attente durant votre session de programmation, votre conversation sur un document ou une autre tâche récurrente ? Conservez une référence, préservez les conditions et comparez l’interaction complète. Considérez la recommandation d’un outil de réglage comme un candidat à valider, surtout lorsque votre charge de travail diffère de son test. Partagez les configurations qui régressent avec autant de soin que celles qui s’améliorent. Ces rapports aident à distinguer une valeur par défaut largement utile d’une option adaptée à certaines machines. Avant d’adopter le réglage de part CPU d’une autre personne, demandez-vous ce que son résultat a réellement mesuré et si cette mesure représente votre propre usage.
