DGX Spark vs Strix Halo vs Gorgon Halo : quel matériel pour l’IA locale ?

DGX Spark vs Strix Halo vs Gorgon Halo : quelle plateforme pour vos charges LLM locales ?

Un système doté de 192 Go n’est pas automatiquement plus rapide qu’un système doté de 128 Go. Une fiche technique annonçant 1 PFLOP ne dit pas à quelle vitesse un LLM génère des tokens. Et un benchmark sans résultats séparés de prefill et de decode peut donner une image trompeuse des performances réelles.

Ces nuances comptent lorsque vous comparez la plateforme NVIDIA DGX Spark, la solution AMD dotée de 128 Go et les configurations plus récentes équipées de 192 Go pour l’IA locale et les LLM exécutés localement.

Ces trois plateformes couvrent des usages qui nécessitaient autrefois de grandes tours équipées de GPU dédiés : inférence privée, agents de code, RAG, contexte long et pipelines multi-modèles. Elles abordent simplement ces besoins de manière différente.

La façon utile de les comparer :

1. Le modèle et les données nécessaires à son exécution tiennent-ils en mémoire ?
2. À quelle vitesse le système traite-t-il un prompt long (prefill) ?
3. À quelle vitesse génère-t-il des tokens (decode) ?
4. Votre logiciel dépend-il de CUDA ?
5. Que se passe-t-il lorsque votre charge de travail dépasse 128 Go ?

La distinction la plus importante reste :

Question centrale de ce guide : comment choisir entre l’appareil NVIDIA à 128 Go, la solution Strix AMD dotée de 128 Go et les systèmes de bureau Gorgon équipés de 192 Go pour l’inférence LLM locale — surtout la bifurcation de capacité 128 Go vs 192 Go — sans traiter une capture isolée de tokens/s comme un classement.

Comparatif rapide

Ce tableau oriente les plateformes. Il ne signifie pas qu’une colonne est universellement plus rapide — cela dépend du scénario.

AMD liste Gorgon Halo comme ancien nom de code sur la page du Ryzen AI Max+ PRO 495 (jusqu’à 192 Go, Radeon 8065S). Dans cet article, Gorgon Halo désigne donc l’ancien nom de code associé au Ryzen AI Max+ PRO 495 et sert de raccourci pour désigner cette catégorie de systèmes de bureau dotés de 192 Go de mémoire — pas une marque d’architecture grand public distincte.

Planification rapide : ce que 128GB vs 192GB achètent en pratique

Si 128GB tiennent déjà avec de la marge, traitez 192GB comme une assurance de capacité.

Carte des goulots d’étranglement matériels pour LLM

Cette carte est le vrai point de départ pour acheter ces plateformes en 2026 — pas une capture isolée de tokens/s.

Pourquoi comparer précisément ces trois plateformes

Du PC « AI » à la station de travail locale

Le marketing « AI PC » s’appuie encore sur les TOPS de NPU. Les acheteurs sérieux de LLM locaux regardent davantage la mémoire unifiée, les chemins d’inférence GPU/APU et la capacité du système à héberger des agents privés, du RAG et du travail à contexte long sur le bureau — c’est pourquoi on retrouve aujourd’hui NVIDIA DGX Spark, AMD Strix Halo (128 Go) et des configurations équipées de 192 Go lorsqu’on cherche un mini PC IA / une station compacte.

Pourquoi la capacité mémoire est devenue une spécification clé

Dès que l’on a commencé à charger localement des poids de modèles 70B et 120B+, 128GB et 192GB ont cessé de sonner comme un luxe pour devenir « est-ce que ça charge seulement ? ». La mémoire unifiée explique pourquoi ces trois options de bureau partagent l’attention : elles promettent un espace mémoire unique assez grand pour du matériel LLM local qui exigeait autrefois des tours multi-GPU.

(Les écarts puces 128GB vs 192GB sont détaillés dans notre guide Ryzen AI Max+ 395 vs PRO 495. Sur la fiche AMD, le Ryzen AI Max+ PRO 495 liste l’ancien nom de code Gorgon Halo, la Radeon 8065S (40 unités de calcul graphique (CU)) et jusqu’à 192GB de LPDDR5X-8533 — c’est le silicium orienté 192 Go que ce guide projette sur les SKU de bureau.)

Qu’est-ce qu’AMD Strix Halo ?

Plateforme et Ryzen AI Max

Strix Halo est la plateforme APU haut de gamme d’AMD qui réunit un CPU Zen 5 solide, une iGPU Radeon large et un bus large de mémoire unifiée LPDDR5X dans des systèmes compacts. Les acheteurs tapent souvent AMD Strix Halo ; le Ryzen AI Max+ 395 (souvent aussi recherché comme Ryzen AI Max 395) est l’une des puces les plus connues qui reposent sur cette plateforme dans des SKU mini PC Strix Halo et des stations de travail (profil Ryzen AI Max+ 395 128GB compris).

Si vous comparez un PC Strix Halo à des appareils de type appliance NVIDIA, partez de la capacité mémoire, de la pile logicielle (ROCm / llama.cpp) et du format — pas seulement du nom de puce.

Pourquoi Strix intéresse l’IA locale

La plateforme compte pour l’IA locale parce qu’elle combine :

• Une mémoire unifiée large (souvent jusqu’à 128GB sur les configurations phares type Strix Halo 128GB)
• Du vrai calcul GPU pour l’inférence LLM (pas seulement du marketing NPU)
• Des châssis compacts — des designs mini PC AMD aux boîtiers de bureau plus denses
• Assez de marge pour le logiciel x86 du quotidien en plus du modèle

Ce n’est pas « une RTX 4090 dédiée dans un tout petit boîtier ». C’est une approche APU AMD (AMD APU) d’abord : charger de gros poids dans une seule mémoire unifiée, accepter que le décodage soit souvent limité par la bande passante, et optimiser la pile logicielle (ROCm, Vulkan, llama.cpp, Ollama).

Qu’est-ce qu’AMD Gorgon Halo ?

C’est l’angle d’information que la plupart des articles Spark vs Strix passent encore sous silence.

Capacité : AMD 128GB vs 192GB

La fiche produit AMD liste Gorgon Halo comme ancien nom de code du Ryzen AI Max+ PRO 495 (Radeon 8065S, 40 CU, jusqu’à 192GB LPDDR5X-8533). Dans cet article, Gorgon Halo désigne donc l’ancien nom de code associé au Ryzen AI Max+ PRO 495 et sert de raccourci pour désigner cette catégorie de systèmes de bureau dotés de 192 Go de mémoire — pas une marque d’architecture à chercher en rayon.

Pour l’acheteur, la distinction utile est plus simple :

• Solution AMD dotée de 128 Go → souvent suffisante pour de nombreuses piles LLM locales chargées en permanence
• Configuration 192GB → plus de marge lorsque poids, cache KV et piles multi-services ne tiennent plus

Face à Strix, c’est donc surtout une question de capacité (avec horloges et découpages dépendants de la configuration), visant les charges de travail qui butaient déjà sur la limite des 128 Go — RAG multi-services, contexte plus long, fichiers de poids MoE plus lourds, quants plus élevés.

Face à l’appareil NVIDIA à 128 Go, la question change encore : l’appareil NVIDIA reste centré sur CUDA et une mémoire unifiée cohérente de 128 Go ; les systèmes AMD à plus grande mémoire répondent à « et si 128 Go de mémoire réellement disponible sont la vraie limite ? ».

Pourquoi une capacité mémoire plus élevée compte pour les LLM locaux

La capacité apparaît pour des poids plus lourds, des caches KV plus longs, des piles multi-services, ou une quantification moins agressive.

Plus de mémoire, est-ce toujours mieux ?

Non. La capacité fixe ce que vous pouvez charger ; la vitesse suit encore la bande passante, le calcul et le logiciel.

Qu’est-ce que NVIDIA DGX Spark ?

Les specs qui comptent pour l’IA

D’après la page produit NVIDIA, les specs du DGX Spark qui comptent pour l’IA locale / l’inférence LLM (et pour lire les annonces de perf avec prudence) sont, en gros :

• Superpuce GB10 Grace Blackwell (NVIDIA GB10)
• 128GB de mémoire unifiée cohérente @ 273 GB/s annoncés
• Perf Tensor marketing FP4 (jusqu’à ~1 PFLOP FP4 sparse — théorique)
• Pile logicielle CUDA, DGX OS, playbooks / outillage orienté NIM
• Stockage local rapide (configurations Founders avec gros NVMe)
• Réseau ConnectX-7 pour les scénarios multi-machines

Le prix catalogue de la Founders Edition est actuellement de 4 699 $ (contexte de prix seulement — ce guide n’est pas un comparatif tarifaire).

Pourquoi CUDA fait partie de l’histoire Spark

Pour beaucoup d’acheteurs, la plateforme NVIDIA DGX Spark n’est pas « un autre système à 128 Go ». C’est l’accès à l’écosystème CUDA : frameworks, kernels, recettes de fine-tuning et piles de serving qui présupposent déjà NVIDIA. Cette couche logicielle fait partie des performances des LLM mesurées, ce n’est pas un accessoire.

Différences matérielles clés (détail)

Le comparatif rapide ci-dessus suffit à la plupart des acheteurs. Ce tableau ajoute la couche de specs plus dense.

Les specs qui comptent vraiment pour les LLM

Pour l’inférence LLM, trois chiffres ne sont pas interchangeables :

1. Capacité mémoire — poids + KV + runtime tiennent-ils ?
2. Bande passante mémoire — à quelle vitesse le decode peut-il faire défiler les poids ?
3. Calcul + logiciel — à quelle vitesse le prefill et quels kernels existent ?

Les TOPS / PFLOPS seuls ne répondent pas à ces questions.

Capacité mémoire vs bande passante pour les LLM locaux

Pourquoi 128GB peut compter plus que les FLOPS GPU

Si le modèle ne tient pas, les FLOPS ne servent à rien. C’est pourquoi les discussions sur le matériel LLM local fixent Strix Halo 128 GB et la mémoire unifiée à 128 GB du Spark — et pourquoi Gorgon 192 GB représente un véritable avantage produit pour les usages limités par la capacité.

Pourquoi plus de mémoire n’accélère pas automatiquement l’inférence

Une fois que le modèle est en mémoire, ajouter de la RAM n’augmente rarement pas les tokens/s à elle seule. Sur les APU à mémoire unifiée, le décode est souvent borné par la bande passante. La capacité supplémentaire réduit surtout le recours au swap, les déchargements de modèles et la nécessité d’utiliser une quantification plus agressive.

Ce que change la bande passante mémoire

La bande passante se voit surtout dans :

• Le décode (génération token par token)
• Le streaming des poids pour de gros modèles denses
• Les performances LLM bornées par la mémoire lorsque le GPU attend le bus

Les 273 GB/s annoncés du Spark et le pic de 256 GB/s de Strix aident à comprendre pourquoi, dans certains runs publics appariés, les écarts de génération restent modestes — même lorsque les écarts de prefill sont larges. Les configurations 192GB du Max+ PRO 495 atteignent aussi un pic théorique de 273 GB/s via 256 bits × LPDDR5X-8533 (le débit soutenu OEM peut différer).

Que se passe-t-il lorsque vous allongez le contexte ?

Un contexte plus long fait grossir le cache KV. Les agents de code et le RAG qui renvoient d’énormes prompts punissent le prefill et l’empreinte cachée. C’est une autre carte de goulots que des tours de chatbot courts.

Pourquoi la taille de modèle ne suffit plus pour choisir le matériel d’IA locale

« Combien de Go pour un modèle 70B ? » est la mauvaise question isolée.

Un budget mémoire pratique pour les LLM locaux :

1. Poids du modèle (dépend de la quantification)
2. Cache KV (dépend de la longueur de contexte)
3. Surcoût runtime (framework, graphes CUDA/ROCm, OS)
4. Contexte/outils (tampon agent, tampons de retrieval)
5. Plusieurs modèles/services (embedder, reranker, second LLM)

Donc le même label « 70B » peut être confortable sur 128GB dans une pile et douloureux dans une autre. La planification de capacité est une somme, pas un compteur de paramètres.

(Voir le tableau de planification rapide plus haut pour les plages 64 / 128 / 192GB.)

Inférence LLM par classe de modèle

Petits et moyens LLM

Pour du chat 7B–32B, le calcul, la maturité logicielle, le coût et la consommation comptent souvent plus que la chasse aux 192GB. Un mini PC IA sur la solution AMD dotée de 128 Go peut être l’achat rationnel si vos modèles tiennent déjà.

Modèles 70B

Ici, la capacité de mémoire, la quantification et la bande passante codominent. Les deux plateformes 128GB jouent dans le même club ; le différenciateur devient CUDA vs ROCm et la façon dont votre charge de travail se partage entre prefill et decode.

Modèles 120B+

La capacité devient la première contrainte. La quantification et la politique de contexte décident si le système est utilisable. La configuration 192GB vise cette bande plus qu’un « chat 14B plus rapide ».

Grands modèles MoE

Paramètres totaux ≠ paramètres actifs. Un MoE 200B+ peut paraître terrifiant sur une slide tout en n’activant qu’une fraction d’experts par token. Il faut toujours de la capacité pour stocker les poids, mais le coût de décodage suit le travail actif plus le routage. La qualité du runtime compte autant que le chiffre marketing — d’où la place du MoE dans tout guide d’inférence de bureau sérieux.

Pourquoi les modèles à 200B+ paramètres ne sont pas toujours aussi lourds qu’ils en ont l’air

Les modèles denses gardent la plupart des paramètres chauds à chaque token. Les MoE n’activent que certains experts, donc le calcul par token peut paraître plus léger que le compteur de paramètres.

L’activation sparse réduit le calcul par token, mais n’élimine pas le besoin de stocker les poids. C’est pourquoi un grand MoE peut encore exiger une capacité de 192 Go même lorsque le décode reste gérable — et pourquoi les paramètres totaux, l’encombrement des poids, les paramètres actifs, le cache KV et les tokens/s mesurés doivent rester séparés dans toute lecture de benchmark LLM.

Pourquoi les benchmarks LLM peuvent tromper

Prefill vs decode

Le prefill traite le prompt d’entrée (souvent lourd en calcul, parallèle).

Le décodeur émet les tokens un par un (souvent sensible à la bande passante / latence).

Cette scission explique aussi pourquoi les chiffres de performance de DGX Spark peuvent paraître inégaux d’un test à l’autre : le prefill peut creuser un grand écart dans une configuration tandis que le decode reste proche. Un système peut sembler rapide sur un chatbot court et lent sur « analyse ce dépôt de 20k tokens ».

Les tokens par seconde ne disent pas tout

Les résultats bougent avec la longueur du prompt, le contexte, la taille du batch, la quantification, le backend, le modèle et le runtime. Un seul chiffre étiqueté « benchmark DGX Spark » ou « benchmark LLM » sans ces labels est incomplet.

Pourquoi deux benchmarks montrent des résultats différents

Les runs publics appariés sont utiles comme indices directionnels — pas comme un classement toutes plateformes.

Quellen: HardwareCorner, IntuitionLabs, Memeburn.

Dans cette comparaison publiée, Spark a montré un avantage substantiel de prefill, tandis que les résultats de decode étaient beaucoup plus proches — utile pour les flux lourds en prompt, pas un vainqueur universel pour chaque tâche LLM locale.

CUDA vs ROCm : la différence logicielle

CUDA sur Spark

Dans les débats DGX Spark vs AMD, CUDA est souvent la vraie décision : support des frameworks, chemins TensorRT-LLM / vLLM, recettes de fine-tune, et moins de temps à chasser les forks — même lorsque des systèmes AMD 128 GB existent. Côté AMD, l’iGPU Radeon et ROCm/Vulkan portent l’essentiel de l’inférence.

ROCm et le matériel AMD

Sur les systèmes Strix / Gorgon, l’inférence IA et LLM réelle passe souvent par ROCm, Vulkan, Llama.cpp, Ollama, LM Studio et consorts. La pile fonctionne ; elle peut demander plus de soins à l’opérateur.

Pourquoi le logiciel peut changer les performances matérielles

Même silicium, backend différent → prefill/decode différents. La perf d’inférence est une pile, pas une puce.

         Application IA
               ↓
     Modèle / Quantification
               ↓
      Runtime d’inférence
     ↙                  ↘
  CUDA                  ROCm/Vulkan
     ↘                  ↙
        GPU / APU
             ↓
     Architecture mémoire
             ↓
      Refroidissement / Alimentation

Capacité matérielle vs friction de déploiement

Les specs brutes ne sont que la moitié de l’achat. L’autre moitié, c’est à quel point il est pénible de servir un modèle de façon fiable :

• Côté NVIDIA : outillage natif CUDA, plus de recettes « ça tourne » pour les piles courantes (vLLM / TensorRT-LLM / playbooks). Vous payez souvent une prime pour moins de friction lors de mise en service — pas seulement pour une capture de tokens/s.
• Côté AMD : beaucoup d’installations de bureaux réelles passent par Llama.cpp, Vulkan, Ollama, LM Studio et ROCm là où c’est supporté. Ça marche ; le soin opérateur varie davantage selon le modèle/runtime.

Donc « Spark vaut-il le coup face à un système AMD 128GB ? » se résume souvent à : écosystème CUDA + moins de friction + l’écart de prefill publié dans certains tests appariés — contre le prix, le confort Windows/x86, et un decode qui peut être proche.

Expériences de scénarios (issues de vraies questions utilisateurs)

Au lieu de déverser des tokens/s Reddit, traduisez les débats LocalLLM récurrents en tests :

Scénario 1 — « Je veux faire tourner un modèle 70B en local. » Vérifiez capacité → quantification → bande passante → runtime.

Scénario 2 — « Je veux un agent de code local. » Vérifiez contexte + cache KV → sensation de decode → outillage agents (CUDA peut compter).

Scénario 3 — « Je veux du 120B+. » Vérifiez d’abord la capacité → quant → si le système à plus de mémoire aide davantage que le prefill NVIDIA pour vos prompts.

Scénario 4 — « Je veux plusieurs modèles chargés en permanence. » Vérifiez la mémoire libre après OS/runtime → concurrence → thermique sur les longs runs.

Mini PC vs station de travail IA compacte pour LLM locaux

Lorsque vous choisissez un mini PC basé sur Strix pour l’IA locale, regardez au-delà du nom du processeur. Pour le parcours format et assemblage, voir aussi notre guide pour monter une station de travail IA locale. Capacité mémoire, refroidissement, expansion, stockage et puissance soutenue comptent davantage pour les charges d’inférence longues que l’étiquette brochure.

Aucun format ne gagne universellement — adaptez au cycle d’usage. Et pour l’inférence LLM de bureau, TOPS NPU ≠ perf LLM : calcul GPU/APU, mémoire unifiée et runtime dominent.

Où se place ACEMAGIC ?

Quelle configuration ACEMAGIC pour quelle charge ?

Matériel IA local vs GPU cloud

Quand le matériel local a du sens

Confidentialité, inférence répétée, travail hors ligne, agents quotidiens prévisibles, boucles de développement que vous lancez chaque heure.

Quand les GPU cloud ont plus de sens

Jobs énormes occasionnels, entraînement en rafales, modèles qui ne tiennent toujours pas, expériences distribuées.

Comment penser le coût total

Calculez le coût des heures que vous exécutez réellement, pas une affirmation virale « rentabilisé en N mois » sans vos logs de tokens. Le local gagne sur la confidentialité et le coût marginal ; le cloud gagne sur l’élasticité.

Comment choisir le matériel LLM local en 2026

1. Partez de la classe de taille de modèle — 7B / 14B / 32B / 70B / 120B+ — puis ajoutez aussitôt contexte et besoins multi-services.
2. Vérifiez la capacité mémoire — la charge mémoire complète tient-elle ?
3. Vérifiez la bande passante de la mémoire et le calcul — le décode sera-t-il acceptable ?
4. Vérifiez la longueur de contexte — cache KV et phase de prefill.
5. Vérifiez le logiciel — CUDA requis ou ROCm/llama.cpp suffisent ?
6. Vérifiez la thermique/le format — cycle d’usage du mini-PC vs de la station de travail.

Matrice de décision matériel IA locale

Les TOPS deNPU restent utiles pour le marketing AI PC, mais cette matrice privilégie la mémoire, la bande passante et la pile logicielle.Il n’existe pas de tableau gagnant unique. Sur les piles à 128 Go, choisissez selon le logiciel, le comportement prefill/decode et la conception du système. Franchissez le plafond de capacité, et 192 GB devient un autre type d’avantage — pas un chiffre de benchmark plus élevé.

Résumé

Choisir parmi ces trois options de bureau se ramène à l’adéquation à votre charge de travail, pas à un vainqueur unique :

1. La capacité mémoire détermine les modèles que vous pouvez charger ; les performances d’inférence dépendent aussi de la bande passante, du calcul et de la pile logicielle. 192 Go aident lorsque le poids, la cache KV ou les piles multi-services ne tiennent pas en 128 Go — cela n’augmente pas automatiquement les tokens/s.
2. Prefill ≠ decode. Dans le test apparié publié, GPT-OSS 120B MXFP4 avec Llama.cpp, le prefill de Spark était très en avance tandis que le decode restait proche — à lire comme indicatif, pas comme un classement universel.
3. Sur 128 Go : voie CUDA / moins de friction NVIDIA contre l’approche AMD x86 basée sur Strix Halo (ex. AI 395 ou F9A-395), selon la pile logicielle et le format.
4. Sur 192 Go : lorsque la capacité mémoire est la première contrainte, le F9A-PRO495 correspond au Max+ PRO 495 / 192GB LPDDR5X-8533 (Radeon 8065S). « Gorgon » reste ici l’ancien nom de code / raccourci de l’acheteur pour ce niveau. Ryzen AI Max PRO 495 apparaît parfois sans le « + » dans les recherches ; le nom du produit conserve le « + ».
5. Achetez le goulot que vous avez vraiment : capacité mémoire d’abord, puis bande passante/calcul, puis friction CUDA vs ROCm/llama.cpp, puis thermique et expansion.

FAQ

L’appareil NVIDIA 128GB vaut-il le coup face à la solution AMD 128GB pour l’inférence LLM locale ?

Cela dépend de ce que vous achetez. Dans le test apparié GPT-OSS 120B MXFP4 publié plus haut, le prefill de Spark était très en avance tandis que le décode était proche. Le surcoût s’explique surtout par l’écosystème CUDA, moins de friction de déploiement et l’outillage orienté DGX — pas une affirmation universelle de génération 5× plus rapide. La solution AMD dotée de 128 Go reste compétitive pour de nombreuses configurations mini PC IA Windows/x86 lourdes en décode.

De combien de RAM ai-je besoin pour faire tourner un LLM 70B en local ?

Planifiez poids + cache KV + runtime + extras, pas seulement l’étiquette de paramètres. Beaucoup de configurations 70B sont à l’aise avec 128 Go de mémoire unifiée aux quants courants ; contexte long, quants plus élevés ou piles multi-services augmentent le budget. Utilisez le tableau de planification ci-dessus — c’est une orientation, pas une limite stricte.

Puis-je faire tourner des modèles 120B sur 128GB de mémoire unifiée ?

Oui, avec une quantification agressive et une longueur de contexte limitée, mais vous perdez de la marge pour le cache KV, les modèles d’embedding et les rerankers. C’est là que le matériel Gorgon à 192 Go apporte de la valeur. La capacité reste le premier critère ; la vitesse utilisable, le second.

Le F9A-PRO495 « supporte-t-il » du 120B Q4 ou jusqu’à 300B MoE ?

Ces chiffres sont des objectifs de capacité de production (quantification + contexte + runtime), pas une promesse de tokens/s. Un MoE 300B n’équivaut pas à un dense 300B : le fait que le modèle tienne en mémoire n’implique pas de générer vite. Exigez des mesures reproductibles avant de les prendre pour des performances.

192GB est-il mieux que 128GB pour les LLM locaux ?

192GB offre plus de marge de modèle et de cache KV, mais n’augmente pas automatiquement les tokens/s lorsque la charge de travail tient déjà en 128GB. Choisissez-le pour les piles limitées par la capacité de mémoire (quantités plus élevées, multi-modèles, contexte long, poids MoE plus lourds) — pas comme une hausse de vitesse gratuite.

Quand la configuration 192GB compte-t-elle plus que l’un ou l’autre système 128GB ?

Lorsque la charge de travail ne tient plus en mémoire : RAG multi-modèles, fichiers de poids MoE plus lourds, quants plus élevés ou caches KV longs. Voir aussi la FAQ 192GB vs 128GB ci-dessus.

Plus de mémoire unifiée signifie-t-il des tokens/s plus rapides ?

Non. Loger les poids en mémoire n’est pas la même chose que générer vite des tokens — bande passante, calcul, quantification et runtime fixent toujours le rythme.

Les TOPS NPU sont-ils un bon critère pour choisir du matériel LLM embarqué ?

En général non. Pour l’inférence LLM de bureau, GPU/APU + mémoire + logiciel dominent les résultats d’inférence IA davantage que les slides de TOPS NPU.

Mini PC ou station de travail de bureau ?

Chat et agents légers tiennent souvent dans un mini PC. Grands modèles, RAG multi-services et inférence de longue durée penchent pour une station — y compris une station compacte de type F9A lorsque vous avez besoin de 192 Go de mémoire.

Sources

• AMD Ryzen AI Max+ PRO 495 (ancien nom de code Gorgon ; max 192GB ; Radeon 8065S)
• AMD Ryzen AI Max+ 395 / Strix Halo (max 128GB LPDDR5X-8000)
• NVIDIA DGX Spark spécifications produit
• Benchmarks LLM HardwareCorner sur Spark ; IntuitionLabs ; Memeburn