Tester un modèle MoE avec une mémoire GPU limitée

L'essentiel à retenir

Une mémoire GPU limitée ne répond pas seule à la question matérielle. Elle fixe une contrainte de départ. L'essai doit ensuite montrer comment un modèle MoE se comporte sur la machine réellement envisagée, avec plusieurs répartitions entre GPU et CPU.

llama.cpp est un outil d'inférence LLM et VLM en C/C++. Il prend en charge une exécution hybride CPU+GPU. La PR #30966 ajoute un cache d'experts MoE sur le GPU, une part configurable de calcul sur le CPU quand un expert demandé manque dans ce cache, ainsi qu'un script de calibration. Le CPU ne crée pas de VRAM. Il prend en charge une partie configurable du travail lorsque les conditions du test le prévoient.

Le lecteur non technique peut confier cet essai à son équipe ou à un prestataire. Il demande un protocole écrit, plusieurs réglages comparables, les mesures de chaque passage et une conclusion limitée à la machine testée. La décision suivante porte alors sur un nouvel essai : modifier le cache, modifier la part CPU, changer de machine candidate ou arrêter l'évaluation. Le résultat attendu n'est pas une promesse générale. C'est un relevé traçable reliant une configuration, une charge d'essai et des observations.

Le problème que ça résout

Si vous envisagez une configuration matérielle à partir de sa mémoire GPU, ajoutez un essai sur la machine candidate. N'inscrivez pas d'emblée « convient » ou « ne convient pas ». Inscrivez la machine, le modèle et les réglages qui seront effectivement essayés.

Pour un essai MoE avec llama.cpp, cette lecture laisse de côté l'inférence hybride CPU+GPU et le comportement du cache d'experts. La question ne se limite donc pas à savoir si tous les experts tiennent dans la mémoire GPU. Elle devient plus précise : que se passe-t-il, sur cette machine, lorsque l'expert demandé n'est pas présent dans le cache GPU et qu'une part de ces absences est calculée sur le CPU ?

La PR #30966 transforme cette question en réglages observables. --moe-cache-mib fixe la mémoire réservée au cache d'experts. --moe-cache-cpu-share fixe la part configurable des experts absents du cache GPU qui peut être calculée sur le CPU. Un script de calibration permet d'essayer plusieurs configurations. Ces éléments ne donnent pas un réglage universel. Les résultats dépendent de la machine.

Formulez la décision comme une question de test avant de retenir une configuration matérielle. Demandez à l'équipe technique ou au prestataire d'inscrire les hypothèses, les paramètres et les mesures. Donnez un identifiant distinct à chaque combinaison de réglages.

Dans le protocole, séparez quatre objets : la machine candidate, le modèle essayé, les réglages de cache et de partage CPU, puis les mesures recueillies. Rattachez chaque conclusion à cet ensemble. Si l'un de ces objets change, ouvrez une nouvelle ligne d'essai.

L'option CPU n'ajoute aucune mémoire vidéo. Elle déplace une part configurable du calcul lorsque l'expert demandé manque dans le cache GPU. Reprenez ces termes dans le compte rendu. Ne présentez pas le processeur comme une extension physique de la VRAM.

Ce que c'est concrètement

llama.cpp est un moteur d'inférence LLM et VLM écrit en C/C++. Dans le cadre décrit ici, son rôle est d'exécuter le modèle sur une combinaison de ressources CPU et GPU, puis d'exposer des réglages liés au cache des experts MoE.

Le premier réglage, --moe-cache-mib, correspond à la taille du cache GPU consacrée aux experts. L'équipe technique choisit plusieurs valeurs compatibles avec la machine testée et les inscrit dans le protocole. Le relevé doit reprendre la valeur exacte utilisée à chaque passage.

Le second réglage, --moe-cache-cpu-share, indique la part configurable des experts absents du cache GPU qui peut être calculée sur le CPU. Lorsque le modèle demande un expert qui n'est pas dans ce cache, ce paramètre intervient dans la répartition. Là encore, le compte rendu doit reprendre la valeur exacte et ne pas la remplacer par une appréciation vague comme « beaucoup de CPU » ou « surtout le GPU ».

Le script de calibration ajouté par la PR #30966 sert à parcourir plusieurs configurations. Il ne remplace pas la définition du test. L'équipe doit encore choisir la machine, le modèle, la charge d'essai, les mesures à relever et les conditions communes aux passages comparés. Le script organise l'exploration des paramètres. La décision reste fondée sur le relevé produit autour de cette exploration.

Concrètement, le lecteur peut demander un tableau avec une ligne par configuration. Chaque ligne contient au minimum l'identification de la machine, le modèle, la valeur du cache, la part CPU, la charge utilisée et les mesures retenues par l'équipe. Une colonne séparée reçoit les incidents ou écarts observés pendant le passage. Une dernière colonne indique si la configuration doit être retestée, comparée à une autre machine ou écartée du cycle suivant.

Ne mélangez pas mesure et interprétation dans le tableau. Placez « valeur relevée » et « conclusion de l'équipe » dans deux colonnes différentes.

Comment s'en servir

Étape 1 : formuler la décision attendue

Écrivez la question avant le premier passage. Par exemple : « Quelle configuration devons-nous tester ensuite pour ce modèle et cette charge ? » Limitez la réponse à la machine, au modèle et à la charge inscrits dans le relevé.

Précisez aussi les sorties attendues : un tableau des réglages, les mesures définies par l'équipe, les écarts observés et une recommandation de prochain test. Le lecteur non technique peut valider ce format sans intervenir dans les commandes.

Étape 2 : figer le périmètre du premier cycle

Demandez à l'équipe de nommer la machine candidate et le modèle. Faites inscrire la charge d'essai qui sera répétée sur chaque configuration. Conservez ce périmètre pendant le cycle de comparaison.

Si l'équipe modifie le modèle, la machine ou la charge en cours de route, demandez une nouvelle série clairement identifiée. Ne rassemblez pas ces résultats dans une même ligne de synthèse. Les résultats dépendent de la machine, et une conclusion doit rester attachée aux conditions qui l'ont produite.

Étape 3 : préparer la grille de réglages

Faites lister les valeurs de --moe-cache-mib que l'équipe souhaite essayer. Faites également lister les valeurs de --moe-cache-cpu-share. Chaque combinaison reçoit un identifiant avant l'exécution.

La grille peut commencer avec un nombre limité de combinaisons choisi par l'équipe technique. Après ce premier cycle, le relevé indique quelles zones méritent un passage supplémentaire. Le script de calibration de la PR #30966 peut prendre en charge l'exploration de plusieurs réglages. Le dossier remis au décideur doit néanmoins conserver la correspondance entre chaque identifiant et les paramètres exacts.

Étape 4 : choisir les mesures avant l'exécution

Demandez quelles mesures seront relevées pour chaque passage. Gardez la même liste sur l'ensemble du cycle. L'équipe peut y inclure les mesures d'exécution qu'elle juge pertinentes sur la machine, l'état du passage, les erreurs rencontrées et les observations liées à la répartition CPU+GPU.

Ajoutez aussi des éléments de suivi du test : heure de début, heure de fin, personne ou prestataire responsable, version de la configuration et emplacement du relevé. Classez ces champs comme éléments de suivi, pas comme mesures de performance du modèle.

Étape 5 : exécuter la calibration et conserver les sorties

L'équipe lance le script de calibration avec la grille préparée. Elle conserve les sorties de chaque configuration sous l'identifiant prévu. Si un passage échoue ou s'interrompt, le relevé garde cette ligne et décrit son état. Une ligne manquante ne doit pas être transformée en résultat implicite.

Pendant cette étape, rappelez la limite du mécanisme : un expert demandé qui manque dans le cache GPU peut être calculé sur le CPU selon la part configurée. Le CPU n'ajoute pas de VRAM. Le compte rendu décrit une répartition de calcul, pas une augmentation de la mémoire vidéo disponible.

Étape 6 : comparer les configurations sur la même base

Regroupez les lignes qui partagent la même machine, le même modèle et la même charge. Comparez les réglages et les mesures sans ajouter de résultat provenant d'un autre périmètre. Relevez les configurations complètes, les passages interrompus et les données absentes.

Demandez à l'équipe de distinguer les constats des hypothèses. Dans la colonne « constat », recopiez une mesure ou un état observé. Dans la colonne « hypothèse », inscrivez une explication proposée ou un prochain réglage à tester.

Étape 7 : décider du prochain essai

À la fin du cycle, inscrivez une décision bornée. Demandez un nouveau passage avec un cache différent, une autre part CPU, une autre machine candidate ou le même réglage répété. Vous pouvez aussi arrêter l'évaluation selon vos critères internes.

Inscrivez la décision à côté des éléments qui l'appuient. Notez ce qui reste non testé. Si une autre machine entre dans la comparaison, ouvrez une nouvelle série et reprenez le même format de relevé. Ne présentez pas les résultats de deux machines comme interchangeables.

Ce que ça coûte vraiment

Aucun montant général ne figure dans l'outil ou dans la PR. Relevez le coût de l'essai à partir de la machine mobilisée, du temps inscrit par l'équipe et du nombre de configurations exécutées.

Commencez par le temps consacré au cadrage. Quelqu'un doit identifier la machine, le modèle, la charge, les réglages et les mesures. Inscrivez ce temps dans le dossier si votre décision matérielle l'intègre.

Ajoutez le temps d'exécution et de suivi. Le script de calibration parcourt plusieurs configurations, mais l'équipe doit encore préparer les entrées, surveiller les passages selon son protocole, conserver les sorties et qualifier les interruptions. Relevez séparément le temps de la machine et le temps humain. Ils ne décrivent pas la même ressource.

Comptez ensuite l'accès au matériel testé. Si la machine appartient déjà à l'organisation, notez la période pendant laquelle elle est mobilisée par l'essai. Si elle est fournie par un prestataire, demandez que son mode de facturation apparaisse séparément dans le relevé. L'article ne fixe aucun tarif ni aucune durée type.

Chaque combinaison de cache et de part CPU correspond à un passage dans le relevé. Avant d'ajouter une combinaison, écrivez la question précise à laquelle ce passage doit répondre.

Enfin, distinguez le coût de l'essai du coût de la configuration matérielle envisagée. Le premier couvre la préparation, l'exécution, le relevé et l'analyse. Le second ne peut être étudié qu'à partir des options matérielles effectivement comparées. Ne fusionnez pas ces deux lignes dans une estimation unique.

Le rapport final peut donc présenter quatre rubriques : cadrage, exécution machine, intervention technique et accès au matériel. Ajoutez les dépenses spécifiques documentées par votre équipe ou votre prestataire. Si une rubrique n'est pas mesurée, marquez-la comme non relevée. Ne la remplacez pas par une estimation non attribuée.

Pour qui ce n'est pas

Cette démarche ne correspond pas à un lecteur qui cherche une réponse matérielle sans essai. Les résultats dépendent de la machine. Un réglage relevé ailleurs ne devient pas automatiquement une recommandation pour votre configuration.

Écartez cette démarche si personne ne peut prendre en charge l'exécution technique. Le lecteur n'a pas besoin de coder, mais l'essai comprend l'installation et l'exécution de llama.cpp, la préparation du modèle, le lancement de la calibration, la conservation des sorties et l'explication des mesures.

N'utilisez pas ce protocole comme garantie sur un usage futur. Il décrit un essai d'inférence sur un périmètre donné. Après une modification de la machine, du modèle, de la charge ou des paramètres, ouvrez un autre périmètre dans le relevé.

Il ne convient pas si la décision suppose que le CPU ajoute de la VRAM. Le mécanisme décrit ne change pas la quantité de mémoire vidéo. Il permet qu'une part configurable du calcul des experts absents du cache GPU soit prise en charge par le CPU.

Il ne remplace pas les critères internes de sélection matérielle. Indiquez les critères retenus, leur mode de lecture et le prochain test autorisé à côté du comportement observé et du coût relevé pendant le cycle.

Enfin, ne fusionnez pas des passages qui ne partagent pas une base commune. Si chaque configuration utilise une charge différente ou si les paramètres exacts ne sont pas conservés, demandez un nouveau cycle documenté plutôt qu'une synthèse reconstruite après coup.

Source : https://github.com/ggml-org/llama.cpp/pull/30966

FAQ

Un lecteur non technique peut-il piloter cet essai ?

Oui. Il peut fixer la question de décision, demander le format du relevé et confier l'exécution à son équipe technique ou à un prestataire. Il reçoit ensuite les réglages, les mesures, les écarts et la proposition de prochain test.

Le CPU augmente-t-il la mémoire GPU disponible ?

Non. Le CPU ne crée pas de VRAM. Avec les réglages ajoutés par la PR #30966, une part configurable du calcul peut être réalisée sur le CPU lorsqu'un expert demandé manque dans le cache GPU.

À quoi sert --moe-cache-mib ?

Ce paramètre fixe la mémoire réservée au cache d'experts MoE sur le GPU. L'équipe technique peut essayer plusieurs valeurs et inscrire chaque valeur exacte dans le relevé de calibration.

À quoi sert --moe-cache-cpu-share ?

Ce paramètre règle la part des experts absents du cache GPU qui peut être calculée sur le CPU. Son effet doit être observé sur la machine testée, dans les mêmes conditions que les autres configurations comparées.

Le script de calibration choisit-il le matériel à la place de l'équipe ?

Non. Il aide à essayer plusieurs configurations de cache et de partage CPU. L'équipe définit le périmètre, choisit les mesures, interprète le relevé et propose le prochain essai. Le décideur conserve la décision matérielle.

Peut-on reprendre le réglage obtenu sur une autre machine ?

On peut le reprendre comme hypothèse de test, pas comme résultat acquis. Les résultats dépendent de la machine. Une autre configuration matérielle doit faire l'objet de sa propre série documentée.

---

Publié le 8 novembre 2026. Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.