Nous avons urgemment besoin d'un modèle 80–160B : Le marché des appareils à mémoire unifiée a besoin de plus de modèles

Le paysage de l'inférence locale en IA a radicalement changé. Il y a quelques années à peine, faire tourner un modèle de 70 milliards de paramètres sur du matériel grand public relevait du rêve lointain. Aujourd'hui, des appareils dotés de 96 Go, 128 Go, voire 192 Go de mémoire unifiée trônent sur nos bureaux — les Mac Studio et MacBook Pro d'Apple avec les puces M‑series Max/Ultra, les plateformes AMD Ryzen AI Max « Strix Halo », le DGX Spark de NVIDIA, et les configurations multi‑GPU avec 4×RTX 3090 ou RTX 6000 Pro. Ces machines réclament un point idéal que l'écosystème actuel de modèles ne comble tout simplement pas. La communauté le crie haut et fort : nous avons urgemment besoin d'un modèle 80–160B. Le marché des appareils à mémoire unifiée a besoin de plus de modèles.

Ces trois derniers mois, nous avons vu un déluge de petits modèles performants comme Qwen 27B et Gemma 31B — optimisés pour la vitesse sur les GPU à faible VRAM et les appareils edge. À l'autre extrême trônent des modèles denses ou à mélange d'experts colossaux (400B, 600B, voire 1 billion de paramètres) qui exigent des serveurs multi‑GPU de qualité entreprise. Mais le segment intermédiaire — les modèles entre 80 et 160 milliards de paramètres — reste un angle mort. Ce sont précisément les architectures qui pourraient saturer les profils à mémoire abondante et bande passante limitée des systèmes à mémoire unifiée, et offrir un mélange inédit d'intelligence locale, de longueur de contexte et de capacité de raisonnement. Cet article explore en profondeur les raisons de cette inadéquation matériel‑modèle, quels appareils sont en manque de ces géants de milieu de gamme, et ce que nous pouvons faire en tant que communauté pour accélérer le changement.

L'essor du matériel grand public à haute mémoire unifiée

Les architectures à mémoire unifiée ont effacé la frontière historique entre la RAM système et la VRAM du GPU. Lorsqu'un seul pool de 96 Go ou 128 Go est accessible à la fois au processeur et au moteur neuronal ou au GPU intégré, l'intégralité des poids du modèle, le cache KV et la fenêtre de contexte peuvent résider dans un seul espace contigu. Cela change la donne pour l'inférence locale de LLM. Passons en revue les principales plateformes.

Apple Silicon : les Mac avec 96 Go ou plus

Les puces M‑series Ultra et Max dans les Mac Studio et les configurations haut de gamme du MacBook Pro sont devenues les favorites des passionnés d'IA locale. Un M2 Ultra avec 192 Go de mémoire unifiée peut théoriquement charger un modèle 180B profondément quantifié entièrement en RAM, avec des bandes passantes atteignant 800 Go/s sur l'Ultra. Même un M3 Max avec 96 Go ou 128 Go est une machine d'inférence productive. Cependant, ces appareils ont besoin de modèles qui exploitent pleinement leur capacité mémoire sans nécessiter la puissance de calcul d'un GPU de datacenter pleine échelle. Un modèle 100B quantifié en 4‑bit tient confortablement dans 50–60 Go, laissant amplement de place pour une fenêtre de contexte de 128K.

AMD Ryzen AI Max et l'ère Strix Halo

Les puces Ryzen AI Max (Strix Halo) d'AMD, avec jusqu'à 128 Go de mémoire unifiée LPDDR5X et un puissant GPU intégré RDNA 3.5, représentent la réponse x86 à l'Apple Silicon. Les premiers benchmarks montrent que ces APU peuvent faire tourner des modèles 70B entièrement en local. Mais avec 128 Go à disposition, elles ont de la marge — elles réclament à grands cris un modèle à mélange d'experts (MoE) de 120B ou 150B qui tiendrait dans moins de 100 Go après quantification 4‑bit. Actuellement, ces gigaoctets restent partiellement inactifs parce que l'écosystème logiciel n'a pas encore livré les modèles correspondant à l'appétit du matériel.

NVIDIA DGX Spark et stations de travail à haute RAM

Le DGX Spark de NVIDIA (anciennement Project Digits) met l'architecture Grace‑Hopper sur le bureau, avec 128 Go de mémoire unifiée LPDDR5X. Il est conçu pour le développement en IA. Simultanément, les utilisateurs de cartes RTX 6000 Pro (48 Go chacune) ou de configurations avec quatre RTX 3090 (totalisant 96 Go de GDDR6X) agrègent la VRAM via le parallélisme de modèle. De tels systèmes peuvent héberger un modèle massif, mais ils ne veulent pas d'un mastodonte 400B qui avance à un rythme d'un token à la fois. Ils veulent un modèle dense 130B ou un MoE 160B qui tourne à une vitesse interactive de 5–10 tokens par seconde.

Configurations multi‑GPU et systèmes avec 128 Go DDR4/DDR5

Une révolution silencieuse est également en cours chez les utilisateurs disposant de RAM système haute capacité (128 Go DDR4/DDR5) et de GPU dédiés pouvant décharger une partie du modèle. Grâce à l'inférence en mode fractionné de llama.cpp, ils peuvent exécuter de grands modèles répartis entre la RAM système et la VRAM du GPU. Pourtant, les options de modèles se raréfient considérablement au‑delà de 70B. La remarque de la communauté sonne juste : « Il y a tellement de gens qui ont beaucoup, mais pas assez, de RAM "lente". » Le matériel attend.

Le paysage actuel des modèles : deux extrêmes

Le zoo de modèles open‑source et ajustés par la communauté s'est récemment divisé en deux camps distincts, laissant un cratère au milieu.

Petits modèles optimisés pour la vitesse (27B–32B)

Au cours du dernier trimestre, les sorties les plus saluées ont ciblé les machines rapides à faible capacité. Qwen 27B et Gemma 31B sont exceptionnels pour leur taille, tournant sans effort sur des GPU de 24 Go de VRAM et même sur des smartphones une fois quantifiés. Ils offrent un suivi d'instructions rapide, l'utilisation d'outils et un raisonnement acceptable. Mais leurs connaissances du monde, leur compréhension nuancée des instructions et leur stabilité en contexte long restent bien en deçà de ce qu'un modèle 100B+ peut offrir. Ils sont conçus pour le public le plus large possible, pas pour ceux qui ont déjà investi dans des pools de mémoire de 96 Go et plus.

Modèles colossaux (400B+)

Sur la rive opposée trônent des géants comme DeepSeek‑V3 (671B MoE), Llama 3.1 405B, et les diverses fusions communautaires à l'échelle 600B. Ces modèles sont d'une intelligence stupéfiante mais nécessitent généralement plusieurs nœuds A100 80 Go ou H100 pour être servis à un rythme acceptable. Même un DGX Spark ne peut faire tourner un modèle 405B agressivement quantifié qu'à 1–2 tokens par seconde, ce qui le rend impraticable pour un usage interactif. Le fossé de ressources entre 32B et 400B est abyssal.

Le chaînon manquant : 80–160 milliards de paramètres

Entre 80 et 160 milliards de paramètres se trouve un espace de conception parfaitement aligné avec les appareils à mémoire unifiée disposant de 96 Go à 192 Go de capacité. Considérez ceci :

• Un modèle dense 100B en quantification Q4_K_M nécessite environ 56 Go de mémoire. Il laisse 40–70 Go libres pour le cache KV, permettant jusqu'à 100K tokens de contexte sur un système 128 Go.
• Un modèle MoE 140B (avec environ 20B de paramètres actifs par token) pourrait tourner à des vitesses impressionnantes sur un M3 Max, en n'utilisant qu'une fraction de la bande passante mémoire d'un modèle dense comparable, tout en offrant un raisonnement sophistiqué.
• Un modèle 160B quantifié en 3‑bit tient dans 65 Go, laissant une marge généreuse pour le multitâche sur un MacBook 96 Go.

La demande est criante. Le post communautaire qui a suscité cette discussion n'était pas qu'un simple souhait — c'était le reflet de milliers d'utilisateurs avec des appareils Apple >96 Go, des systèmes Ryzen AI 395, des unités DGX Spark et des stations de travail multi‑GPU qui sont collectivement lassés de faire tourner de « petits » modèles 70B qui ne saturent pas leur matériel, ou des modèles 400B+ qui font hurler leurs ventilateurs pour un filet de 0,3 token/seconde.

Pourquoi nous avons urgemment besoin de modèles 80–160B pour les appareils à mémoire unifiée

Ajustement parfait pour les buffers VRAM/RAM de 96–192 Go

Un modèle 80B quantifié en 4‑bit occupe environ 45 Go ; un modèle 160B environ 85 Go. Ces tailles sont la « zone de Boucle d'or » pour les configurations 96 Go, 128 Go et 192 Go qui inondent le marché des prosommateurs. Les utilisateurs peuvent allouer les poids du modèle, une fenêtre de contexte massive, et même un second modèle pour le décodage spéculatif ou un encodeur visuel — le tout dans le même pool de mémoire unifiée, sans recourir au swap sur SSD.

Équilibrer intelligence et vitesse d'inférence

La qualité d'un modèle évolue avec le nombre de paramètres. Le saut de 70B à 130B apporte souvent un bond quantique en raisonnement logique, génération de code, planification multi‑étapes et rappel factuel. En parallèle, un modèle 130B sur un APU Strix Halo peut encore atteindre 8–12 tokens/seconde avec des backends de frameworks ML optimisés comme MLC‑LLM ou llama.cpp avec accélération Metal/CUDA/ROCm. C'est assez rapide pour le chat en temps réel, les boucles agentiques et les assistants copilotes locaux — sans la latence prohibitive d'un monstre 405B.

Permettre des workflows agentiques sophistiqués en local

L'avenir de l'IA locale est agentique : des modèles capables de naviguer de manière autonome, d'écrire du code, de gérer des fichiers et d'exécuter des tâches multi‑étapes. De tels agents exigent une grande mémoire de travail (cache KV) et la capacité de gérer des schémas d'utilisation d'outils complexes. Un modèle 70B peine souvent à maintenir des plans cohérents sur de longs horizons ; un modèle 400B est trop lent. Un modèle 80–160B pourrait être le cerveau d'agent autonome parfait pour un assistant privé toujours actif sur l'appareil.

Pistes d'action : comment la communauté peut promouvoir plus de modèles

Les sorties de modèles sont motivées par les signaux du marché et le bruit de la communauté. Voici comment nous pouvons rendre le milieu de gamme manquant impossible à ignorer :

• Exprimer la demande sur les plateformes open‑source – Ouvrir des issues et des discussions GitHub sur les grands projets (llama.cpp, MLC‑LLM, vLLM) en mettant en avant la capacité matérielle et le manque de modèles.
• Benchmarker et démontrer la disponibilité du matériel – Publier des benchmarks d'inférence pour les grands modèles existants sur les appareils 96 Go+, en soulignant explicitement la marge restante.
• Encourager les laboratoires à publier des checkpoints intermédiaires – Demander aux grandes entreprises d'IA (Meta, Qwen, DeepSeek, Mistral) de publier non seulement les variantes 7B–30B et 400B+, mais aussi des checkpoints d'entraînement 80B–160B que la communauté peut fine‑tuner.
• Financer et sponsoriser les fine‑tunes communautaires – Mutualiser les ressources via le financement participatif pour prendre un modèle de base open‑source 80B et créer des versions instruct, code et agentiques optimisées pour l'inférence 4‑bit sur mémoire unifiée.
• Créer un classement unifié – Classer les modèles spécifiquement sur le benchmark de performance « inférence locale 96–192 Go », donnant de la visibilité aux modèles qui correspondent à ce profil matériel.

Considérations techniques pour l'exécution de modèles 80–160B sur mémoire unifiée

Quantification, Q4_K_M et besoins en mémoire

Pour un déploiement local pratique, la quantification est non négociable. Voici une référence rapide pour l'utilisation mémoire (approximative) avec un pool de mémoire unifiée de 128 Go :

• Modèle 80B, Q4_K_M : ~45 Go. Laisse 83 Go libres — idéal pour des fenêtres de contexte de 100K+ tokens.
• Modèle 120B, Q4_K_M : ~67 Go. Permet 60 Go pour le cache KV et la surcharge système, suffisant pour un contexte de 64K.
• Modèle 160B, IQ3_XXS : ~65 Go avec une bonne rétention de qualité. Permet d'exécuter un modèle 160B même sur des Mac 96 Go avec un contexte modéré.

La technologie pour une quantification efficace existe aujourd'hui. Ce qui manque, c'est la base de modèle qui maximise le rapport qualité‑par‑Go dans cette tranche de paramètres.

Bande passante mémoire vs calcul : le goulot d'étranglement

Les systèmes à mémoire unifiée sont souvent limités par la bande passante, pas par le calcul. Un M2 Ultra offre 800 Go/s, et un APU Strix Halo offre environ 500 Go/s. Un modèle dense 100B en 4‑bit lit 50 Go par étape de génération de token. À 800 Go/s, la production théorique de tokens est d'environ 16 tokens/s — parfaitement interactive. Les architectures MoE peuvent encore améliorer cela en maintenant les paramètres actifs à un niveau bas (par ex., 20B sur 140B), réduisant ainsi la lecture mémoire par token. L'industrie a besoin de modèles MoE ou épars dans la gamme 80–160B conçus avec cette caractéristique de bande passante à l'esprit.

Foire aux questions

Pourquoi ne pas simplement exécuter un modèle 70B avec une immense fenêtre de contexte ?

Bien que les modèles 70B puissent être étirés vers de longs contextes, leur capacité de raisonnement fondamentale atteint un plafond. Un modèle 100B–130B possède intrinsèquement plus de profondeur factuelle, une meilleure chaîne de pensée et une utilisation d'outils plus fiable, avant même toute extension de contexte. C'est la différence entre un modèle capable de résumer un document de 200 pages et un modèle capable également de le référencer et de raisonner profondément à travers lui sans halluciner.

Puis-je actuellement exécuter un modèle 120B sur un Mac avec 128 Go de RAM ?

Techniquement oui — vous pouvez télécharger Goliath 120B ou une fusion quantifiée basée sur Llama‑2. Mais le fossé qualitatif par rapport aux architectures modernes est frappant, car ces anciens modèles n'ont pas bénéficié des dernières données de préentraînement et techniques d'alignement. L'objectif est d'avoir des modèles 80–160B modernes avec des recettes d'entraînement de classe Qwen‑2, DeepSeek ou Gemma.

Quel framework est le meilleur pour l'inférence de modèles 80–160B sur mémoire unifiée ?

llama.cpp (avec les backends Metal, CUDA ou ROCm) est le favori de la communauté pour son efficacité mémoire. MLC‑LLM offre d'excellentes performances sur Metal et Vulkan. Pour les workflows agentiques, LM Studio et Ollama fournissent des interfaces conviviales. Le goulot d'étranglement n'est pas le runtime — c'est la disponibilité de fichiers de modèles bien quantifiés.

Y a-t-il des modèles 80–160B annoncés pour bientôt ?

Bien que des rumeurs circulent occasionnellement sur le Twitter de l'IA et dans les blogs des laboratoires de recherche, aucune sortie open‑source majeure dans cette tranche exacte n'a été confirmée au moment de la rédaction. Ce silence souligne l'urgence. Plus la communauté signale que le marché existe, plus vite le cycle de sorties s'orientera dans cette direction.

Conclusion : La révolution de la mémoire unifiée a besoin de ses modèles héros

Nous nous trouvons à un point d'inflexion matériel. Pour la première fois, de puissants appareils à mémoire unifiée capables d'IA ne sont pas confinés aux baies de serveurs — ils sont sur les bureaux, dans les ordinateurs portables et dans les mini‑clusters de niveau développeur. Mais toute cette capacité reste à moitié inutilisée sans les bons cerveaux logiciels. L'appel est clair : Nous avons urgemment besoin d'un modèle 80–160B. Le marché des appareils à mémoire unifiée a besoin de plus de modèles. C'est un appel aux laboratoires d'IA, aux contributeurs open‑source et aux communautés de passionnés de matériel à collaborer, financer et développer le milieu de gamme manquant. C'est seulement ainsi que nous libérerons le véritable potentiel de nos machines à haute RAM — transformant des gigaoctets inactifs en agents d'IA locaux intelligents, réactifs et profondément capables.

Si vous êtes développeur de modèles, fournisseur de matériel, ou simplement quelqu'un qui dispose de 128 Go de RAM avec l'envie de faire avancer l'IA locale — il est temps de combler le fossé. Construisons ensemble l'avenir de la classe 100B.