Un mini PC à mémoire unifiée coûtant environ 2 000 à 3 000 $ peut charger certains modèles de la classe 235B fortement quantifiés qui ne tiennent pas sur un seule GPU de la classe H100.
Ça semble à l'envers, alors précisons la comparaison. La carte coûteuse est bien plus rapide, mais sa mémoire GPU locale est plus petite. La petite boîte posée sur le bureau peut disposer d'un pool partagé plus grand, si bien que le modèle peut se charger, même si la génération est lente.
La réponse en un mot à la question du comment est « mémoire unifiée ». C'est un chiffre phare imprimé sur la fiche technique de nombreux nouveaux mini PC IA et Mac (« 128 Go de mémoire unifiée »), et presque personne n'explique ce que cela fait réellement. C'est justement l'objet de cet article. À la fin, vous saurez ce qu'est la mémoire unifiée, pourquoi elle permet à une petite machine démarrer de faire tourner un modèle qui exigeait auparavant une baie de serveurs, et le piège que personne ne mentionne dans le titre : elle fait tourner ce modèle lentement.
En bref
- La mémoire unifiée est un seul pool physique de mémoire que le CPU et le GPU intégré d'une puce partagent, au lieu du petit VRAM séparé d'une carte graphique dédiée, posé à côté de votre RAM système, elle aussi séparée.
- Ce pool partagé est vaste, et le GPU peut généralement accéder à bien plus de mémoire que la limite de VRAM fixe d'une carte dédiée, même si la quantité réellement utilisable dépend de la plateforme, des réglages du firmware, de l'OS et du runtime. La première question devient donc : cette version quantifiée tient-elle dans la mémoire utilisable ? Un pool de 128 Go peut contenir des modèles qu'une carte graphique de 24 Go ou 32 Go ne pourrait jamais loger.
- Le hic, c'est la vitesse, pas la taille. La mémoire unifiée déplace les données bien plus lentement que le VRAM d'une carte dédiée. Le gros modèle fonctionne. Il génère simplement les tokens lentement. La mémoire unifiée vous permet de faire tourner le gros modèle, pas de le faire tourner vite.
- « Unifiée » ne désigne pas une seule chose. La version d'Apple est presque invisible pour l'utilisateur ; celle d'AMD expose davantage de réglages, car les paramètres du firmware et des pilotes peuvent influencer la quantité de mémoire réservée au GPU, ou pratiquement utilisable par lui. Et plus de mémoire ne veut pas dire plus rapide.
Qu'est-ce que la mémoire unifiée ?
Imaginez deux configurations. Une carte graphique dédiée possède sa propre mémoire (VRAM) directement collée à son processeur, rapide mais réduite. Votre RAM système est un second pool, séparé, utilisé par le CPU. Pour faire tourner un modèle sur le GPU, les données doivent d'abord être copiées de la RAM système vers le VRAM, via le bus PCIe. Deux pools, une étape de copie.
La mémoire unifiée élimine cette scission. C'est un seul pool physique de mémoire que le CPU et le GPU intégré de la puce partagent tous deux, ce qui permet au GPU de travailler directement à partir du pool partagé plutôt que de dépendre d'un petit bloc de VRAM séparé. Sur des plateformes comme Apple Silicon, cela évite en plus l'ancienne étape de copie via PCIe. la propre présentation technique d'Apple sur son architecture la décrit comme le CPU et le GPU « travaillant sur la même mémoire », sans besoin de copier les données via un bus PCIe. Un pool. Zéro copie.
Le pool partagé est généralement de la mémoire LPDDR5X soudée sur le module, ce qui lui permet d'être à la fois vaste et proche du processeur. Les exemples phares actuels sont les Mac Apple Silicon, les systèmes Strix Halo d'AMD bâtis autour de puces comme le Ryzen AI Max+ 395, et le DGX Spark de Nvidia. la plateforme de développement Ryzen AI Halo d'AMD annonce 128 Go de mémoire LPDDR5x à 256 Go/s, tandis que le DGX Spark de Nvidia annonce 128 Go de mémoire système unifiée LPDDR5x à 273 Go/s.
Le partage de mémoire entre un CPU et un GPU intégré n'a rien de nouveau. Les ordinateurs portables le font depuis des années, et c'était généralement un compromis : mémoire lente, et pas beaucoup. Ce qui a changé, c'est la capacité à bande passante utilisable. Une fois qu'un pool partagé est devenu assez grand, autour de la classe des 128 Go, tout en restant assez rapide pour valoir le coup, il a franchi le seuil où de très grands modèles à poids ouverts pouvaient tenir localement. C'est toute l'histoire. L'architecture est ancienne ; la taille est nouvelle.
Une précision sur « vs VRAM » : on demande souvent si la mémoire unifiée est du VRAM. Pas exactement. Le VRAM est une mémoire graphique dédiée sur une carte séparée, rapide et distincte. La mémoire unifiée est un pool unique et partagé qui fait le travail à la fois du VRAM et de la RAM système. Elle échange la vitesse brute d'une carte dédiée contre la taille et la possibilité de sauter l'étape de copie.
Pourquoi un modèle doit-il tenir dans la mémoire ?
Pour une inférence normale en mémoire, les poids du modèle doivent résider dans une mémoire adressable par le processeur. Si la mémoire utilisable est trop petite, le modèle ne se chargera pas correctement sur cet appareil. Certains outils peuvent décharger une partie du modèle vers la mémoire du CPU ou le stockage, mais cela modifie fortement le profil de performance et ce n'est pas la même chose qu'un modèle tenant confortablement dans une mémoire adressable par le GPU. La capacité est un verrou incontournable, avant même toute question de vitesse.
C'est le levier qu'actionne la mémoire unifiée. De nombreuses cartes graphiques grand public disposent de 24 Go de VRAM ou moins, et même les cartes grand public haut de gamme plafonnent autour de 32 Go. Un modèle de 70 ou 235 milliards de paramètres est bien trop grand pour cela. Le calcul brut en 4 bits pour 235 milliards de paramètres démarre autour de 118 Go, avant même le surcoût du format, les tampons du runtime et la mémoire de contexte. En pratique, les versions réellement téléchargeables varient beaucoup : par exemple, la version Q4_K_M de Qwen3-235B-A22B proposée par Ollama affiche 142 Go, tandis que des quantifications plus agressives, à moins de bits, peuvent se rapprocher de ce qu'une machine à mémoire unifiée de 128 Go peut gérer. La carte conçue pour la tâche manque donc de place avant même de commencer. (La façon dont ces chiffres de mémoire sont calculés, paramètres multipliés par les octets par poids, plus le surcoût que la taille du fichier dissimule, est un sujet à part entière, et le article compagnon sur les calculs de quantification fait le calcul.)
Un pool unifié de 128 Go change la réponse à une question précise : cette version quantifiée particulière tient-elle une fois que l'OS, le runtime, le cache KV et les limites d'allocation du GPU ont pris leur part ? Pour certaines quantifications agressives de classe 235B, la réponse est oui. C'est pourquoi une petite machine à mémoire unifiée peut parfois charger un modèle qu'un GPU avec moins de VRAM ne peut pas. Elle n'est pas plus puissante. Elle a simplement une pièce plus grande où loger le modèle.
C'est la première chose que les titres présentent correctement sans jamais l'expliquer. C'est la taille du pool, pas la puissance brute, qui décide si le modèle fonctionne, tout court.
Pourquoi la mémoire unifiée est-elle plus lente qu'une carte graphique ?
Générer du texte token par token est limité par la mémoire bande passante, et non par la vitesse à laquelle le processeur peut calculer. Chaque token produit exige de faire transiter les poids actifs du modèle à travers le processeur, si bien que le plafond de vitesse dépend de la rapidité avec laquelle la mémoire peut alimenter la puce. C'est le comportement bien documenté nature « limitée par la mémoire » du décodage à flux unique, la puce passe la majeure partie de son temps à attendre la mémoire, pas à calculer.
Et c'est précisément sur la bande passante que la mémoire unifiée cède du terrain. Le pool Strix Halo d'AMD tourne sur le papier à 256 Go/s, et des tests indépendants sur llm-tracker.info le mesurent à environ 212 Go/s en pratique. Le DGX Spark se situe à 273 Go/s. Une carte graphique dédiée haut de gamme, en revanche, déplace les données plusieurs fois plus vite, son VRAM dédié est conçu pour ça. Donc, lorsqu'un modèle tient sur les deux à la fois sur une machine unifiée et sur une carte dédiée, la carte dédiée génère les tokens nettement plus vite. Même modèle, même résultat, vitesse très différente.
Pour les modèles denses, une règle empirique utile est :
tokens par seconde ≈ bande passante mémoire ÷ taille du modèle en mémoire.
C'est une indication de tendance, pas un benchmark, mais cela explique le compromis : des poids résidents plus légers ou une bande passante plus élevée signifient généralement un décodage plus rapide. Pour les modèles MoE, n'appliquez pas cette règle directement au nombre total de paramètres. La capacité dépend toujours du total des poids stockés, mais la vitesse par token dépend davantage du chemin activé, du surcoût de routage, du comportement du cache et de l'implémentation.
Une nuance, puis j'arrête là : une requête comporte deux phases. Lire votre prompt (le préremplissage) sollicite le calcul. Générer la réponse (le décodage) sollicite la bande passante. La partie lente que vous ressentez, les mots qui apparaissent un par un, c'est la partie limitée par la bande passante.
Voici donc ce que la fiche technique omet : la mémoire unifiée vous permet de faire tourner le gros modèle, pas de le faire tourner vite. Elle gagne le débat de la capacité et perd celui de la bande passante. La question de savoir si ce compromis en vaut la peine dépend entièrement de ce que vous faites, et c'est un compromis parfaitement acceptable à faire délibérément, pas une surprise à découvrir après l'achat.
Toute mémoire unifiée est-elle identique ?
Non. « Unifiée » désigne une catégorie, pas une implémentation unique, et les versions diffèrent de manière significative. La version d'Apple est presque invisible pour l'utilisateur : la mémoire est partagée par défaut. Le Strix Halo d'AMD demande davantage d'implication : les paramètres du firmware et des pilotes peuvent influencer la quantité de mémoire réservée au GPU, ou pratiquement utilisable par lui. Les deux sont de la mémoire unifiée. Ce n'est pas la même expérience.
Laissez-moi nommer le malentendu que tout ce sujet engendre, car c'est le plus courant : plus de mémoire ne veut pas dire une inférence plus rapide. Ça veut dire qu'un plus grand modèle peut tourner. Quelqu'un achète une machine de 128 Go en espérant de la vitesse, charge un modèle qui tiendrait aussi sur une carte dédiée de 24 Go, et est déçu qu'elle tourne plus lentement que ne le faisait cette petite carte. Les deux affirmations sont vraies à la fois : le gros pool contient plus, et la petite carte rapide tourne plus vite sur ce qu'elles partagent. Taille et vitesse sont deux axes différents. La mémoire unifiée vous offre le premier.
Une subtilité pratique côté AMD : la quantité du pool réellement utilisable pour un modèle dépend du réglage du firmware et du système d'exploitation. la FAQ d'AMD sur Variable Graphics Memory explique comment fonctionne cette allocation ; en version courte, une machine de 128 Go ne remet pas la totalité des 128 Go au GPU, et la quantité utilisable dépend du réglage VGM, de la mémoire système réservée, de l'OS et du runtime. Planifiez en fonction de la mémoire réellement utilisable, pas du chiffre affiché sur l'étiquette.
Astuce : lorsque vous dimensionnez une machine pour des modèles locaux, lisez la fiche technique comme deux chiffres, pas un seul. La capacité vous dit quels modèles tiennent. La bande passante vous dit à quelle vitesse ils tourneront une fois chargés. Une machine avec un immense pool et une bande passante modeste est une machine qui fait tourner de gros modèles lentement, ce qui peut être exactement ce que vous voulez, à condition de le savoir avant l'achat.
Il reste un cas à signaler, car il piège souvent les gens sur ces machines à gros pool : les modèles Mixture-of-Experts. Un modèle comme Qwen3-235B-A22B possède 235 milliards de paramètres au total mais n'en active qu'environ 22 milliards par token. On est tenté de penser que cela signifie qu'il ne lui faut de la mémoire que pour cette tranche active. Pour une inférence normale en mémoire, ce n'est pas le cas. Les 235 milliards de poids doivent tous rester résidents quelque part où le runtime peut les utiliser, car n'importe quel token peut être routé vers n'importe quel expert : seul le calcul par token est réduit, pas l'exigence de capacité. C'est précisément là que le gros pool de la mémoire unifiée justifie son utilité, et le article compagnon sur les calculs de quantification en détaille le résultat chiffré.
Foire aux questions
La mémoire unifiée est-elle la même chose que le VRAM ?
Non. Le VRAM est une mémoire dédiée, à haute vitesse, intégrée à une carte graphique dédiée, gardée séparée de votre RAM système. La mémoire unifiée est un pool unique et partagé qu'utilisent à la fois le CPU et le GPU, remplissant le rôle du VRAM et de la RAM système en même temps. La mémoire unifiée est généralement plus grande mais plus lente que le VRAM d'une carte dédiée, et elle évite l'étape de copie de données entre deux pools.
Pourquoi mon modèle local est-il lent alors qu'il tient dans la mémoire ?
Parce que tenir dans la mémoire et tourner vite sont deux choses différentes. Le chargement d'un modèle dépend de la capacité mémoire ; sa vitesse de génération de texte dépend de la bande passante mémoire. La mémoire unifiée a une capacité généreuse mais une bande passante bien plus faible qu'une carte graphique dédiée, si bien qu'un modèle qui tient confortablement peut quand même générer les tokens lentement. Pour les modèles denses, la relation approximative est tokens par seconde ≈ bande passante ÷ taille du modèle. Pour les modèles MoE, la capacité dépend toujours du total des poids stockés, mais la vitesse dépend davantage du chemin activé et de l'implémentation du runtime.
Avez-vous encore besoin d'un GPU si vous disposez de mémoire unifiée ?
Le GPU intégré fait déjà partie d'une puce à mémoire unifiée, c'est lui qui fait tourner le modèle. La vraie question est de savoir si vous voulez aussi un GPU dédié. De nombreuses cartes dédiées offrent une bande passante bien plus élevée, ce qui signifie une génération plus rapide, mais moins de mémoire locale qu'un grand système à mémoire unifiée, si bien qu'elles ne peuvent pas forcément contenir seules les plus gros modèles. La mémoire unifiée vous offre un grand pool qui contient les gros modèles à vitesse réduite. Ce que vous voulez dépend de l'arbitrage entre taille du modèle et vitesse.
Pourquoi un mini PC peut-il faire tourner un modèle qui exige un GPU de datacenter ?
Parce que le goulot d'étranglement pour charger un modèle, c'est la capacité mémoire, et un mini PC doté d'un grand pool unifié peut disposer de plus de mémoire utilisable pour un modèle que de nombreuses configurations à GPU unique. Un GPU grand public peut avoir de 24 à 32 Go de VRAM, et un seul GPU de datacenter de classe H100 en a entre 80 et 94 Go, tandis que certains systèmes à mémoire unifiée annoncent des pools partagés de 128 Go. Les poids du modèle doivent tous tenir quelque part que le processeur peut atteindre ; le grand pool partagé les contient, le petit VRAM rapide non. Le mini PC n'est pas plus puissant. Il a simplement de la place.
Tenir dans la mémoire, c'est déjà gagné : combien il en faut est la question suivante
La contribution de la mémoire unifiée tient en une chose claire : un pool vaste, partagé et adressable qui permet à une petite machine de faire tenir des modèles qui exigeaient autrefois un serveur. C'est la victoire de la capacité. Le piège de la bande passante en est le prix, et vous pouvez désormais lire une fiche technique en sachant quel chiffre gouverne quel comportement.
La question suivante, naturelle, est celle que cet article a sans cesse repoussée : combien de mémoire un modèle donné exige-t-il réellement ? C'est une affaire d'arithmétique : les paramètres, les octets par poids, le niveau de compression choisi, et la taxe de contexte que la taille du fichier dissimule. L' article compagnon sur la quantification GGUF, GPTQ, AWQ et EXL2 détaille exactement ce calcul, et cela vaut la peine de le faire avant de dimensionner une machine ou de choisir un modèle.
