Faire tourner un modèle de 177 milliards de paramètres sur un Mac

NNoor

Alors, la nouveauté, c’est qu’Atomic Chat propose ce modèle au format GGUF, avec une quantification de 85 Go qui, d’après AlphaSignal, a généré 36 tokens par seconde sur un MacBook M5 Max doté de 64 Go de mémoire unifiée. Les composants de vision étaient activés pour cet essai, mais ce chiffre décrit bien une configuration précise et non une promesse pour tous les ordinateurs. Qwen3.8-Flash-Next est un modèle de type MoE, c’est-à-dire un modèle à experts, et sa structure est présentée comme un aperçu de celle de Qwen4. Le point remarquable est l’écart entre la taille du fichier et la mémoire disponible : le fichier est plus gros, sans que toutes ses données aient à être chargées ensemble. Pour comprendre comment cela devient possible, il faut regarder la répartition des paramètres et la manière dont le modèle y accède pendant la génération.

NNoor

Le mécanisme repose notamment sur une table d’embeddings n-grammes de 51 milliards de paramètres, conservée sur le disque à semi-conducteurs plutôt que chargée intégralement en mémoire. À chaque étape, le modèle prend les 3 tokens précédents, les transforme en une clé de recherche, puis récupère 16 lignes contenant chacune 160 valeurs. La quantité de données demandée logiquement pour cette recherche est d’environ 2,7 kilo-octets par token, même si le disque lit des blocs plus grands que cette demande. Le projet estime le trafic réel de lecture aléatoire à environ 3 mégaoctets par seconde et indique un accès au stockage inférieur à 100 microsecondes. À 36 tokens par seconde, la génération laisse environ 28 millisecondes pour chaque token : ces lectures ciblées peuvent donc s’insérer dans le calcul sans faire entrer toute la table dans la mémoire unifiée.

NNoor

Le résultat annoncé concerne un MacBook M5 Max avec 64 Go de mémoire unifiée et la quantification de 85 Go, avec les composants de vision activés. Il ne suffit donc pas de prendre un fichier quelconque et de lancer une version quelconque du logiciel : le dépôt recommande une compilation de llama.cpp qui intègre la modification PR numéro 27742. Il recommande aussi la quantification AD-4.27bpw-Q4_K_M-M64, parmi les versions mises à disposition. Cette méthode s’adresse plutôt aux personnes capables de suivre ces indications et de préserver l’organisation des fichiers du modèle. C’est important parce que la table n’est que la partie qui peut rester sur le stockage ; le cœur actif du modèle doit toujours être en mémoire unifiée pour effectuer les calculs.

NNoor

D’abord, le mécanisme ne rend pas tout le modèle indépendant de la mémoire : les couches actives sollicitent environ 6 milliards de paramètres et déplacent beaucoup de données, ce qui exige une mémoire à haut débit. Seule la table de recherche n-grammes, consultée de façon éparse, est adaptée à une présence sur le disque. Ensuite, sur les puces Apple, la disposition des fragments du fichier compte : si la table est rangée dans le même fragment que des poids destinés au processeur graphique, llama.cpp peut exposer à la mémoire graphique toute la zone mappée et provoquer une erreur de mémoire dès le premier décodage. Le dépôt place donc la table dans le fragment 2 pour les quantifications proposées et recommande de conserver cet agencement. La compilation particulière de llama.cpp et la quantification recommandée font également partie des conditions décrites pour reproduire l’essai, plutôt que de garantir le même résultat avec une installation différente.

NNoor

Bon, il faut retenir que la taille totale d’un modèle et la quantité de données qu’il doit lire à chaque étape ne sont pas la même chose. Ici, une table de 51 milliards de paramètres reste sur le disque et le modèle n’en demande qu’une petite partie pour chaque token, tandis que les calculs actifs mobilisent la mémoire unifiée. Cette organisation permet au dépôt d’annoncer 36 tokens par seconde pour une quantification de 85 Go sur un MacBook M5 Max de 64 Go, avec la vision activée. Mais ce chiffre ne décrit pas n’importe quel ordinateur, ni une configuration logicielle générique : le projet recommande une version précise de llama.cpp, une quantification donnée et le maintien de la disposition des fragments. Atomic Chat montre ainsi une façon particulière de traiter une table de recherche volumineuse, sans faire disparaître les exigences de mémoire du reste du modèle. C’est une démonstration technique à reproduire dans les conditions indiquées, et non une solution universelle en quelques clics.