Dual DGX Sparks contre Mac Studio M3 Ultra : Comparaison pratique pour exécuter Qwen3.5 397B en local

Comparaison Matérielle pour Qwen3.5 397B Local
Un développeur a dépensé 2 000 $/mois en jetons API Claude avant d'investir 20 000 $ au total en matériel local : un Mac Studio M3 Ultra 512GB et une configuration dual DGX Spark, chacun coûtant environ 10 000 $ après taxes. Les deux ont été testés en exécutant Qwen3.5 397B A17B localement.
Performances du Mac Studio M3 Ultra 512GB
En utilisant la quantification 6 bits MLX, le modèle de 323 Go a été chargé dans la mémoire unifiée de 512 Go. La vitesse de génération était de 30-40 tokens/seconde avec une bande passante mémoire d'environ 800 Go/s, rendant la génération de tokens fluide. La configuration était facile : installer mlx vlm et le pointer vers le modèle. Les faiblesses incluaient un préremplissage lent (30+ secondes sur les grands prompts système) et une dégradation des performances lors de l'exécution d'embedding par lots parallèlement à l'inférence. Le développeur a dû écrire un proxy asynchrone de 500 lignes car mlx vlm ne parse pas les appels d'outils ni ne supprime les tokens de réflexion nativement.
Performances de la Configuration Dual DGX Spark
En utilisant la quantification INT4 AutoRound, 98 Go ont été chargés par nœud sur deux nœuds de 128 Go via vLLM TP=2. La vitesse de génération était de 27-28 tokens/seconde. La configuration a tiré parti des cœurs tensoriels CUDA, des noyaux vLLM et du parallélisme tensoriel pour un préremplissage plus rapide que le Mac Studio. L'embedding par lots qui prenait des jours sur MLX s'est terminé en heures sur CUDA. La bande passante mémoire était d'environ 273 Go/s par nœud, limitant la vitesse de génération malgré plus de puissance de calcul.
Les défis de configuration étaient significatifs : un seul câble QSFP fonctionnait (le deuxième plantait NCCL), l'IP du Node2 était éphémère, le plafond d'utilisation de la mémoire GPU était de 0,88 (nécessitant une recherche binaire pour le trouver), chaque mauvaise estimation coûtait 15 minutes pendant que les fragments de checkpoint se rechargeaient, le cache de page devait être vidé sur les deux nœuds avant chaque chargement de modèle, et certaines unités subissaient une limitation thermique en moins de 20 minutes. Le développeur a rapporté qu'il a fallu des jours pour atteindre la stabilité.
Architecture et Cas d'Utilisation
Le développeur a conservé les deux systèmes, utilisant le Mac Studio uniquement pour l'inférence (les 512 Go complets pour le modèle et le cache KV) et les Sparks pour le RAG, l'embedding, le reranking et d'autres tâches. Ils communiquent via Tailscale. Cette séparation empêche les modèles d'embedding de concurrencer le modèle principal pour la mémoire sur le Mac Studio tout en leur donnant des ressources CUDA dédiées sur les Sparks.
Spécifications Côte à Côte
- Coût : Les deux à 10 000 $
- Mémoire : Mac Studio 512 Go unifiée vs. Sparks 256 Go (128×2)
- Bande passante : Mac Studio ~800 Go/s vs. Sparks ~273 Go/s par nœud
- Quantification : Mac Studio MLX 6 bits (323 Go) vs. Sparks INT4 AutoRound (98 Go/nœud)
- Vitesse de Génération : Mac Studio 30-40 tok/s vs. Sparks 27-28 tok/s
- Contexte Max : Mac Studio 256K tokens vs. Sparks 130K+ tokens
- Configuration : Mac Studio facile mais manuelle vs. Sparks difficile
- Force : Mac Studio bande passante vs. Sparks puissance de calcul
- Faiblesse : Mac Studio puissance de calcul vs. Sparks bande passante
Recommandations
Le Mac Studio est recommandé si vous voulez que cela fonctionne simplement, que vous valorisez une bande passante de 800 Go/s pour une génération fluide, et que vous ne prévoyez pas de charges de travail d'embedding lourdes parallèlement à l'inférence. Les dual Sparks sont recommandés si vous êtes à l'aise avec Linux et Docker, que vous voulez CUDA et vLLM nativement, que vous prévoyez d'exécuter du RAG ou de l'embedding parallèlement à l'inférence, et que vous êtes prêt à passer des jours sur la configuration initiale pour plus de capacités à long terme. Le développeur décrit le Mac Studio comme offrant 80 % de l'expérience avec 20 % de l'effort, tandis que les Sparks offrent plus de capacités mais exigent un coût réel en temps de configuration.
Calcul du seuil de rentabilité : 2 000 $/mois de dépenses API vs. 20 000 $ de matériel total équivaut à 10 mois pour atteindre le seuil de rentabilité, après quoi l'inférence est gratuite avec une confidentialité totale.
📖 Read the full source: r/LocalLLaMA
👀 See Also

Signet : la couche mémoire open source pour agents d'IA de codage atteint 80 % de score F1 sur LoCoMo
Signet est un système de mémoire open-source pour les agents d'IA de codage qui atteint 80 % de score F1 sur le benchmark LoCoMo, contre 41 % pour le RAG standard. Il extrait les mémoires après chaque session et injecte le contexte pertinent avant les invites, fonctionnant localement avec SQLite.

Expérience Utilisateur : Passer d'OpenClaw à l'Agent Hermes sur un LLM Local
Un développeur rapporte avoir basculé d'OpenClaw à Hermes Agent en utilisant Qwen3.5-9B sur une RX 9070 XT avec 16 Go de VRAM. Hermes a accompli une tâche complexe avec 5 appels d'outils corrects contre plus de 50 étapes pour OpenClaw, terminant 2 minutes 30 plus rapidement tout en conservant les fonctionnalités de RAG, d'appel d'outils et de mémoire persistante.

MCP + Cadre de compétences : Guider les agents IA pour des flux de travail efficaces en science des données
Une approche pratique utilisant le serveur MCP et un framework de compétences pour guider les agents Claude/GPT vers des workflows de science des données efficaces et conscients de la plateforme — évitant le code lourd côté client et les mouvements de données inutiles.

Claude Code v2.1.141 : Nouvelles variables d’environnement, amélioration des hooks et corrections de bugs
Anthropic a publié Claude Code v2.1.141 avec de nouvelles variables d'environnement (CLAUDE_CODE_PLUGIN_PREFER_HTTPS, ANTHROPIC_WORKSPACE_ID), le champ terminalSequence pour les hooks, la liste des agents par répertoire de travail, et plus de 20 corrections de bugs.