Comment mesurer Llama 4 Scout dans LM Studio en 2026 ?

Le modèle Llama 4 Scout est documenté par Meta avec 17 milliards de paramètres actifs et 109 milliards de paramètres au total, en raison de son architecture MoE — voir la fiche technique officielle du modèle. Cette donnée suffit à invalider une conclusion fréquente : un chargement réussi sur un Mac de base doté de 16 Go de mémoire unifiée ne représente pas la vitesse réelle de Scout. Cette machine sert surtout à mesurer une limite de ressources et à documenter un échec. Pour mesurer Llama 4 Scout dans LM Studio de façon exploitable, utilisez un environnement Apple Silicon disposant de marge mémoire, puis fixez le fichier GGUF, sa quantification, le moteur Metal, le contexte et les réglages d’échantillonnage avant de comparer les résultats.

Qui doit lire ce guide ? Les utilisateurs Mac qui ont téléchargé une version communautaire de Llama 4 Scout GGUF sans savoir si leur mesure est fiable. Les ingénieurs qui comparent un Mac local à un Mac distant pour une application d’IA, une démonstration audio ou vidéo, ou un prototype de service. Les petites équipes qui doivent définir une règle d’acceptation avant un achat, une présentation client ou un déploiement.

Dernière mise à jour : 1er septembre 2026. Les éléments de modèle ont été vérifiés dans les ressources officielles de Meta ; les procédures de chargement et de mesure sont à recouper avec la documentation actuelle de LM Studio et de llama.cpp avant toute publication de résultat.

Une frontière de mesure à établir avant le téléchargement

Le premier résultat utile n’est pas un nombre de tokens par seconde. C’est une description complète de ce qui a réellement été mesuré. « Llama 4 Scout » peut désigner une architecture, un fichier converti par la communauté, une quantification particulière ou un paquet auquel certaines capacités ont été retirées. Il faut donc écrire le nom complet du fichier, le dépôt d’origine, le mainteneur, le format GGUF et l’identifiant précis de quantification.

Il ne faut pas présenter un fichier converti par la communauté comme un GGUF officiel de Meta. Le dépôt officiel décrit le modèle original, son architecture, ses capacités et sa licence ; il ne certifie pas automatiquement la conversion de chaque fichier distribué ailleurs. Une version qui ne conserve pas les composants visuels ou certaines fonctions attendues ne permet qu’une conclusion limitée aux échanges texte.

La distinction entre paramètres actifs et paramètres totaux est également déterminante. Elle explique pourquoi une comparaison avec un modèle dense présenté comme un « petit modèle » peut être trompeuse. Le nombre de paramètres activés sur un token ne transforme pas Scout en modèle officiel de huit milliards de paramètres, et ne permet pas de déduire sa consommation mémoire ou sa vitesse dans une interface graphique.

Comment interpréter correctement « tokens per second » dans LM Studio ? Il faut d’abord vérifier à quelle phase la valeur se rapporte. Le traitement du prompt, souvent appelé prompt processing ou prompt evaluation, mesure l’ingestion du texte d’entrée. La génération mesure ensuite la production des nouveaux tokens. Une interface peut afficher plusieurs indicateurs ; une valeur de génération élevée ne décrit donc pas nécessairement le temps d’attente ressenti lors d’un long prompt.

La chronologie de contrôle du fichier et du moteur

Avant d’ouvrir le modèle, vérifiez les informations du dépôt et conservez une copie de la page de présentation. Relevez le nom du mainteneur, la carte du modèle, la licence, la quantification, les fichiers auxiliaires et toute indication de compatibilité. Lorsque l’empreinte du fichier est fournie, calculez-la localement et comparez-la à celle publiée. Une taille de téléchargement seule n’est pas une preuve d’identité : elle ne permet ni de valider le contenu ni de distinguer deux conversions.

Ensuite, installez ou mettez à jour LM Studio depuis sa source habituelle, puis notez sa version exacte et la date du test. La documentation des exigences système de LM Studio doit servir à vérifier la compatibilité générale, mais elle ne remplace pas la validation du fichier Scout. Dans l’application, relevez aussi le moteur réellement chargé. Sur un Mac, l’accélération Metal peut être disponible sans que toutes les opérations du modèle soient exécutées de la même manière.

Les résultats ne doivent pas mélanger deux moteurs llama.cpp, deux versions de prise en charge de Llama 4 ou deux builds Metal sous une même ligne de tableau. Pour une automatisation, la documentation de chargement de modèles de LM Studio et sa documentation de chargement par API permettent de reproduire la sélection du fichier et les paramètres au lieu de dépendre d’un clic mémorisé.

Si une conversion ne propose pas le même niveau de capacité que le modèle original, réduisez explicitement la portée du compte rendu. Une mesure texte ne doit pas être réutilisée pour promettre une expérience multimodale, une analyse vidéo ou une intégration complète dans un produit.

L’estimation mémoire avant le premier chargement

Le bon ordre consiste à estimer, puis à charger, et non à forcer plusieurs essais jusqu’à obtenir une réponse. LM Studio fournit une estimation des ressources nécessaires ; utilisez-la pour examiner l’effet combiné du fichier, du contexte, de l’accélération et du cache KV. Le résultat ne doit pas être traité comme une mesure de performance, mais comme un filtre préalable qui évite de confondre un manque de mémoire avec un modèle lent.

Un Mac de 16 Go peut être utile pour observer cette frontière. Si le système commence à compresser fortement la mémoire ou à utiliser le stockage comme mémoire virtuelle, la vitesse obtenue n’est plus un indicateur propre de l’exécution du modèle. Elle inclut alors la concurrence entre LM Studio, macOS et les applications ouvertes. Pour cette raison, fermez les logiciels qui consomment beaucoup de mémoire unifiée, notamment les outils de montage audio ou vidéo, les navigateurs avec de nombreuses sessions et les environnements de développement inutilisés.

Avant le test, faites une capture de la configuration effective après chargement. Vérifiez les points suivants :

• fichier GGUF et quantification ;
• longueur de contexte ;
• nombre de couches déportées vers le GPU ;
• activation ou non de Flash Attention ;
• emplacement du cache KV ;
• température et autres paramètres d’échantillonnage ;
• applications fermées ou conservées en arrière-plan ;
• espace disponible et état de la mémoire virtuelle avant le lancement.

Quels réglages faut-il enregistrer avant de mesurer Scout ? Au minimum, la puce et la mémoire unifiée du Mac, la version de macOS, la version de LM Studio, le runtime utilisé, le fichier GGUF et sa quantification, le contexte, le déport GPU, Flash Attention, le cache KV et les réglages d’échantillonnage. Sans cette fiche, la valeur affichée par LM Studio ne constitue pas une comparaison reproductible.

La première passe : séparer attente et génération

Préparez un petit jeu de prompts conservé dans un fichier immuable. Il doit comprendre une demande très courte, une demande nécessitant une réponse structurée et un texte d’entrée suffisamment long pour exercer le traitement du prompt. Le contenu peut représenter le cas d’usage final : description d’une séquence vidéo, analyse d’un script audio, génération d’un composant ou synthèse d’un document technique. L’objectif n’est pas de produire un classement universel, mais de reproduire une charge représentative.

Pour chaque prompt, consignez séparément :

• le temps de chargement à froid ;
• le délai avant le premier token ;
• la vitesse de traitement du prompt ;
• la vitesse de génération continue ;
• la longueur de la réponse effectivement produite ;
• les erreurs ou interruptions ;
• les paramètres de sampling.

Ne retenez pas le meilleur instant affiché à l’écran. Lancez une phase de préchauffage, puis répétez le même scénario avec les mêmes paramètres. Présentez une valeur centrale, par exemple la médiane, seulement si le nombre exact de répétitions est indiqué dans le journal ; sinon, décrivez qualitativement les variations et conservez chaque essai. Toute mesure doit associer le résultat au matériel, au runtime et au contexte, plutôt que d’afficher une vitesse isolée.

La méthode de référence de llama-bench expliquée dans le dépôt officiel de llama.cpp rappelle l’importance de distinguer les phases de calcul. Pour un test réalisé dans LM Studio, nous ne devons pas prétendre reproduire exactement un benchmark en ligne de commande si l’application, son interface ou ses réglages ajoutent une différence. Nous pouvons en revanche reprendre cette discipline de séparation et documenter l’écart.

Pourquoi le même GGUF peut-il sembler beaucoup plus rapide sur deux Mac ? La différence peut venir de la puce, de la mémoire disponible, du niveau d’offload GPU, du contexte, du cache KV, du runtime, de la version de Metal, de la pression mémoire ou du comportement thermique. Deux ordinateurs portant seulement la même quantité de mémoire ne forment donc pas une paire de comparaison suffisante. Le fichier et le protocole doivent rester identiques avant d’attribuer l’écart au matériel.

La première heure en charge continue

Une réponse correcte après le premier chargement ne suffit pas pour déclarer un environnement prêt pour une démonstration ou un service. Organisez la première heure comme une séquence de contrôles : prompt court, prompt long, conversation à plusieurs tours, puis répétition d’un cas représentatif de l’application. Ne changez pas la quantification ou le contexte entre les étapes, car cela ferait disparaître la cause d’une dégradation.

Surveillez la mémoire utilisée par l’application, la compression mémoire et l’espace d’échange. Si une commande ou un outil de monitoring consigne la température ou la puissance, conservez le nom de l’outil et son journal ; ne déduisez pas une température à partir du boîtier chaud ou du bruit du ventilateur. Les données thermiques et énergétiques non enregistrées ne doivent pas figurer dans le compte rendu.

La stabilité doit être évaluée avec la qualité de sortie. Recherchez notamment :

• une réponse qui s’interrompt sans raison ;
• des répétitions de phrases ou de tokens ;
• une perte du contexte au tour suivant ;
• une erreur lors du changement de prompt ;
• une fermeture inattendue de LM Studio ;
• une chute progressive de la vitesse ;
• un système qui devient difficile à utiliser à cause de la mémoire virtuelle.

Pour un scénario de serveur local, consultez aussi les principes de mesure du serveur llama.cpp. Une expérience interactive et une charge de requêtes concurrentes ne mesurent pas la même chose : la première privilégie le délai perçu, tandis que la seconde exige d’observer la file d’attente, la régularité et la saturation.

La comparaison entre Mac local et Mac distant

Une comparaison équitable ne consiste pas à lancer le même texte sur deux écrans. Il faut transférer le même GGUF, conserver le même contexte, la même graine lorsque l’outil la permet, les mêmes réglages d’échantillonnage et le même script de prompts. Notez séparément le temps de transfert, le temps de démarrage de la session distante et le temps de génération. Pour une utilisation interactive, ajoutez la latence réseau ; pour un service, mesurez la disponibilité et la répétabilité de l’API.

Comment comparer localement et à distance sans fausser la vitesse ? Répétez d’abord le même test de génération sur le même fichier et le même runtime, sans inclure le réseau dans le nombre de tokens par seconde. Publiez ensuite deux résultats distincts : la performance du moteur et le délai complet vécu par l’utilisateur. Cette séparation permet de savoir si un Mac distant est réellement plus rapide ou si son avantage apparent vient seulement d’un protocole différent.

Pour une équipe qui prépare une présentation audio, vidéo ou design, ajoutez un essai avec le prompt réellement utilisé devant le public. Une mesure abstraite peut être acceptable pour le développement, mais une réponse irrégulière, une latence initiale longue ou une perte de contexte peut rendre la démonstration inutilisable. Nous recommandons de valider le parcours complet, y compris l’import du fichier, l’affichage, l’export et la reprise après erreur.

La grille d’acceptation et les trois sorties

Le compte rendu final doit comporter une ligne par machine et une colonne par étape : chargement, premier token, traitement du prompt, génération, pression mémoire, stabilité et qualité de sortie. Les valeurs de vitesse doivent toujours être accompagnées de l’unité affichée, de la phase concernée et de la configuration complète. Il faut également conserver les valeurs atypiques au lieu de les supprimer parce qu’elles rendent le tableau moins flatteur.

Une décision peut alors être prise selon trois objectifs :

Un seul chargement réussi ne justifie pas un déploiement. Si le Mac ne fonctionne qu’après une forte réduction du contexte, une utilisation fréquente de la mémoire virtuelle ou une dégradation visible de la qualité, il faut conserver sur place un modèle plus léger pour les tâches quotidiennes et déplacer la validation de Scout vers un environnement disposant de davantage de mémoire. Le coût pertinent n’est pas uniquement celui de la machine : il comprend le temps de diagnostic, les échecs pendant une démonstration, la reprise des tests et la maintenance du poste.

Dans votre fiche, utilisez au moins les champs suivants : date, machine, mémoire unifiée, version de macOS, version de LM Studio, runtime, GGUF, quantification, contexte, Metal, offload GPU, cache KV, paramètres de sampling, prompts, nombre de répétitions, délai du premier token, traitement du prompt, génération, mémoire, échange, erreurs, qualité et décision. Cette structure est suffisamment précise pour refaire le test après une mise à jour de LM Studio, de Metal, de llama.cpp ou du fichier communautaire.

Le choix de l’environnement après validation

Trois issues sont rationnelles. Premièrement, si Scout se charge avec une marge suffisante, produit des sorties complètes et reste stable pour l’objectif retenu, poursuivez avec des essais de contexte plus long ou de concurrence, toujours dans un protocole séparé. Deuxièmement, si la machine permet seulement une exploration ponctuelle, conservez-la pour le développement léger et utilisez un Mac distant pour les démonstrations ou la recette. Troisièmement, si le fichier reste incompatible ou si la qualité demandée n’est pas atteinte, changez de quantification ou de modèle au lieu de multiplier les réglages non documentés.

Pour un test isolé, un poste déjà disponible peut rester le choix le moins coûteux, même si la vitesse est modeste. Pour une équipe qui doit répéter une recette, accueillir plusieurs utilisateurs ou présenter un outil créatif à heure fixe, un environnement distant peut éviter de monopoliser le poste principal et de mélanger les charges du montage, du design et de l’inférence. Nous présentons d’autres critères de sélection sur la page française de JexMac ; la décision doit toutefois partir du protocole et non d’une promesse de vitesse générique.

Le Mac de 16 Go conserve donc une utilité précise : il permet de vérifier jusqu’où le chargement peut aller, d’identifier les réglages qui déclenchent une pression mémoire et de détecter rapidement un fichier mal adapté. Il ne doit pas être utilisé pour généraliser la performance de Llama 4 Scout. Pour publier une mesure crédible, nous devons fournir l’identité du GGUF, séparer traitement et génération, montrer les conditions de l’essai et signaler les sorties anormales.

Si la solution actuelle repose sur un Mac personnel peu doté, elle cumule généralement trois défauts : la mémoire disponible varie avec les autres applications, les échanges système peuvent rendre les mesures irrégulières et une démonstration peut interrompre le travail audio, vidéo ou de conception en cours. Elle oblige aussi l’équipe à refaire la préparation à chaque changement de fichier ou de runtime. Dans ce cas, louer un Mac auprès de JexMac peut offrir un environnement réservé pour la validation, une configuration plus facile à reproduire et une séparation nette entre poste de production et banc d’essai ; les modalités sont à examiner sur la page de location Mac de JexMac. Si la charge devient permanente ou exige un accès physique à des périphériques, l’achat d’un Mac dédié reste cependant plus cohérent qu’une location ponctuelle.