Dual DGX Sparks vs Mac Studio M3 Ultra: Comparación Práctica para Ejecutar Qwen3.5 397B Localmente

Comparación de Hardware para Qwen3.5 397B Local
Un desarrollador gastaba $2K/mes en tokens de la API de Claude antes de invertir $20K en total en hardware local: una Mac Studio M3 Ultra 512GB y una configuración dual DGX Spark, cada una costando alrededor de $10K después de impuestos. Ambos fueron probados ejecutando Qwen3.5 397B A17B localmente.
Rendimiento de la Mac Studio M3 Ultra 512GB
Usando cuantización de 6 bits MLX, el modelo de 323GB se cargó en 512GB de memoria unificada. La velocidad de generación fue de 30-40 tokens/segundo con un ancho de banda de memoria de aproximadamente 800 GB/s, haciendo que la generación de tokens se sintiera fluida. La configuración fue fácil: instalar mlx vlm y apuntarlo al modelo. Las debilidades incluyeron prefilling lento (más de 30 segundos en prompts de sistema grandes) y degradación del rendimiento al ejecutar embedding por lotes junto con inferencia. El desarrollador tuvo que escribir un proxy asíncrono de 500 líneas porque mlx vlm no analiza llamadas de herramientas ni elimina tokens de pensamiento de forma nativa.
Rendimiento de la Configuración Dual DGX Spark
Usando cuantización INT4 AutoRound, 98GB se cargaron por nodo a través de dos nodos de 128GB mediante vLLM TP=2. La velocidad de generación fue de 27-28 tokens/segundo. La configuración aprovechó núcleos tensor CUDA, kernels vLLM y paralelismo de tensores para un prefilling más rápido que la Mac Studio. El embedding por lotes que tomaba días en MLX se completó en horas en CUDA. El ancho de banda de memoria fue de aproximadamente 273 GB/s por nodo, limitando la velocidad de generación a pesar de tener más capacidad de cómputo.
Los desafíos de configuración fueron significativos: solo un cable QSFP funcionó (el segundo bloqueó NCCL), la IP del Nodo2 era efímera, el límite de utilización de memoria GPU era 0.88 (requiriendo búsqueda binaria para encontrar), cada suposición incorrecta costaba 15 minutos mientras se recargaban los fragmentos del checkpoint, la caché de página necesitaba vaciarse en ambos nodos antes de cada carga del modelo, y algunas unidades limitaron térmicamente en 20 minutos. El desarrollador reportó que tomó días lograr estabilidad.
Arquitectura y Caso de Uso
El desarrollador mantuvo ambos sistemas, usando la Mac Studio solo para inferencia (512GB completos para el modelo y caché KV) y las Sparks para RAG, embedding, reranking y otras tareas. Se comunican a través de Tailscale. Esta separación evita que los modelos de embedding compitan con el modelo principal por memoria en la Mac Studio mientras les da recursos CUDA dedicados en las Sparks.
Especificaciones Cara a Cara
- Costo: Ambos $10K
- Memoria: Mac Studio 512GB unificada vs. Sparks 256GB (128×2)
- Ancho de banda: Mac Studio ~800 GB/s vs. Sparks ~273 GB/s por nodo
- Cuantización: Mac Studio MLX 6-bit (323GB) vs. Sparks INT4 AutoRound (98GB/nodo)
- Velocidad de Generación: Mac Studio 30-40 tok/s vs. Sparks 27-28 tok/s
- Contexto Máximo: Mac Studio 256K tokens vs. Sparks 130K+ tokens
- Configuración: Mac Studio fácil pero práctica vs. Sparks difícil
- Fortaleza: Mac Studio ancho de banda vs. Sparks capacidad de cómputo
- Debilidad: Mac Studio capacidad de cómputo vs. Sparks ancho de banda
Recomendaciones
La Mac Studio se recomienda si quieres que simplemente funcione, valoras 800 GB/s de ancho de banda para generación fluida, y no planeas cargas de trabajo pesadas de embedding junto con inferencia. Las Sparks duales se recomiendan si te sientes cómodo con Linux y Docker, quieres CUDA y vLLM de forma nativa, planeas ejecutar RAG o embedding junto con inferencia, y estás dispuesto a pasar días en la configuración inicial para obtener más capacidad a largo plazo. El desarrollador describe la Mac Studio como proporcionando el 80% de la experiencia con el 20% del esfuerzo, mientras que las Sparks ofrecen más capacidad pero extraen un costo real en tiempo de configuración.
Cálculo de punto de equilibrio: gasto de $2K/mes en API vs. $20K total en hardware equivale a 10 meses para alcanzar el punto de equilibrio, después de lo cual la inferencia es gratuita con privacidad completa.
📖 Read the full source: r/LocalLLaMA
👀 Ver también

ClaudeClaw: Plugin de Código Gratuito de Claude para Agentes de IA Persistentes en Plataformas de Mensajería
ClaudeClaw es un complemento gratuito y de código abierto con licencia MIT para Claude Code que ejecuta a Claude como un agente persistente en Slack, WhatsApp y Telegram. Requiere Node.js 20+, Claude Code y tu propia clave API de Anthropic, con aislamiento a nivel de sistema operativo mediante el sandbox-runtime de Anthropic.

Autoencoders de Lenguaje Natural: Convirtiendo Representaciones Internas de Claude en Texto
Transformer Circuits Thread publica Natural Language Autoencoders que decodifican las activaciones internas de Claude en texto legible. Repositorio de GitHub y demo interactiva disponibles.

Línea de estado personalizada para Claude Code muestra uso de contexto, límites de tasa y conteos de tokens de un vistazo
Un script personalizado añade una línea de estado persistente a Claude Code, que muestra el % de contexto, el % de límite de tarifa de 5 horas, lecturas de caché KV, tokens de entrada/salida acumulados, nombre del modelo y directorio de trabajo, con colores para terminales oscuros.

Manos a la obra con el modelo de Tencent: fuerte para flujos de trabajo agentivos, débil para codificación compleja
El modelo de Tencent obtiene 8/10 en tareas agentivas con bajas tasas de alucinación, pero falla en tareas de codificación complejas como los esquemas de la API de Notion. Evítalo para lógica de backend.