Para ser honesto, me sorprendió. Cuando conecté dos unidades DGX Spark en un clúster y ejecuté DeepSeek-V4-Flash, el resultado fue 1.78x más rápido en tiempo de generación total (tiempo real de pared) en comparación con la Mac Studio M3 Ultra, lo que significa que completó la tarea en aproximadamente la mitad del tiempo. Y esto fue con el DGX Spark ejecutando el modelo FP8 oficial sin cuantización adicional.
Mientras realizaba estas pruebas comparativas, sentí que el punto que he estado planteando repetidamente se respaldó una vez más con números. Es decir:
El rendimiento de los LLM no se puede medir únicamente por la velocidad de decodificación (tokens por segundo, TPS) basada en el ancho de banda de la memoria.
La potencia de procesamiento de la GPU, la comunicación entre nodos, la jerarquía de memoria, la calidad de la cuantización, la longitud del contexto, el procesamiento paralelo, etc.: el "equilibrio" de todos estos factores determina la experiencia real del usuario. Y el DGX Spark simplemente tenía un mejor equilibrio.
El Benchmark Utilizado: El Benchmark de Codificación de shi3z
Para la medición, utilicé el benchmark de codificación del Japanese LLM Benchmark de shi3z. La tarea consiste en "completar una aplicación de chat que se ejecute en React en una sola generación". El código generado se inicia realmente en Docker y se prueba automáticamente usando Playwright para inicio de sesión, amigos, mensajes directos y actualizaciones en tiempo real, con una puntuación funcional sobre 80 puntos.
Los resultados de ejecutar DeepSeek-V4-Flash Q4 (cuantización de 4 bits) en una Mac Studio M3 Ultra a través del motor de inferencia ds4 de antirez están listados en el repositorio de shi3z. La siguiente tabla compara esos resultados con los de esta ocasión: clúster de 2 unidades DGX Spark + FP8 oficial.
Resultados del Benchmark
Por qué "Pierde en tok/s pero Gana en Tiempo Real"
Si miras la tabla y piensas: "Espera, la Mac es más rápida en tok/s", tienes razón. Mirando solo la velocidad instantánea de generar un token (TPS de decodificación), la Mac Studio M3 Ultra es 1.58x más rápida. Esto se debe al enorme ancho de banda de memoria de Apple Silicon.
Sin embargo, aquí hay una trampa. Para completar la misma aplicación de chat con "puntuación perfecta 80/80", la Mac escribió 8,036 tokens, mientras que el DGX Spark escribió 2,866 tokens. Es una diferencia de aproximadamente 2.8x.
Ambos usaron DeepSeek-V4-Flash sin degradación oficial de calidad, pero es natural interpretar que el lado de la Mac, cuantizado a Q4, se volvió redundante, mientras que el lado del Spark, ejecutándose en FP8 de calidad completa, se mantuvo conciso. Es un fenómeno común donde el impacto de la cuantización en la distribución de salida no se muestra en la velocidad de decodificación, pero afecta silenciosamente la estrategia de generación.
Como resultado, el cálculo se ve así:
Tiempo Real de Pared = (Tokens de Salida) ÷ (tok/s)
Mac: 8,036 ÷ 26.2 = 307 segundos Nosotros: 2,866 ÷ 16.6 = 172 segundos
Perder en tok/s pero ganar en tiempo real significa "llegar a la misma respuesta correcta en menos pasos". En el uso práctico, lo que los humanos experimentan es el "tiempo hasta que se completa la tarea", no el tok/s instantáneo.
Configuración Utilizada
- Hardware: DGX Spark × 2 (NVIDIA GB10, basado en Blackwell, 128 GB de memoria unificada cada uno)
- Interconexión de Nodos: Conexión directa mediante ConnectX-7 200 Gbps RoCE (Tensor Parallel = 2, backend distribuido de PyTorch)
- Motor de Inferencia: Receta de Aiden, que integra b12x (un conjunto de kernels CuTe DSL específicos para GB10) en vLLM 0.21.1dev
- Modelo: DeepSeek-V4-Flash oficial FP8 (154 GB, atención FP8, MoE MXFP4 — este es el formato oficial lanzado por DeepSeek)
- Contexto: 524,288 tokens (512K), util 0.82, caché KV 19.85 GiB, concurrencia 3.89×
- Predicción Multitoken (MTP): Decodificación especulativa con una tasa de aceptación de aproximadamente el 62% (ganando velocidad sin sacrificar la calidad de salida)
Una Mirada Más Cercana al Rendimiento
Más allá de los números en este benchmark, medí por separado las velocidades puras de decodificación y prefill:
- Velocidad de Decodificación Pura (Texto corto, excluyendo TTFT): Estable a aproximadamente 39 tok/s
- Velocidad de Prefill (Contexto grande): 1,277 tok/s (Esto es aproximadamente 6.5x más rápido que los 196 tok/s de la configuración anterior sin kernels b12x)
- Decodificación con Contexto Largo: Incluso al aumentarlo de 8K → 64K → 128K → 256K → 512K → 768K, la velocidad de decodificación no cayó bruscamente; de hecho, se aceleró (106 tok/s a 768K). Esto se debe a que la Atención Dispersa (DSA) de DeepSeek está implementada de forma nativa en los kernels b12x, haciendo que los cálculos de atención sean casi independientes de la longitud del contexto.
Este es un Resultado con "Sin Cuantización, Calidad Completa"
Otro punto que quiero enfatizar es que el lado del DGX Spark no utilizó ninguna cuantización adicional en el modelo. Cargamos el oficial de 154 GB distribuido en HuggingFace tal cual y lo ejecutamos en el formato de cuantización oficial diseñado por DeepSeek: atención FP8 + MoE MXFP4.
En el mundo de los LLM locales, se ha convertido en sentido común comprimir modelos enormes a IQ2 (2 bits) o Q4 para que funcionen, pero estos definitivamente recortan calidad. De hecho, anteriormente probé la versión IQ2XXS (2 bits) de DeepSeek-V4-Flash y vi un resultado de 55/80 + colapso del comportamiento del agente en el mismo benchmark. La cuantización no es un almuerzo gratis.
Una configuración que puede asegurar 256 GB de memoria unificada con dos DGX Sparks hace que la opción de "ejecutar modelos enormes con calidad completa" sea una realidad por primera vez. Creo que este es un avance más significativo de lo que sugieren los números.
Por qué el "Equilibrio" del Spark Funcionó
Desglosando los elementos técnicos que respaldaron este resultado:
- Suite de Kernels b12x: Cuatro tipos de kernels (NVFP4 fused MoE GEMM, NVFP4 dense GEMM, FP8 paged attention y sparse MLA attention) escritos específicamente para GB10 / SM12.x usando CuTe DSL. A diferencia de la ruta MARLIN en vLLM general, estos calculan directamente en modo fusionado sin des-cuantizar.
- Conexión Directa RoCE de 200 Gbps: Aunque el all-reduce entre nodos TP=2 ocurre dos veces por capa, la conexión directa de 200 Gbps mantiene la latencia efectiva baja, por lo que no se convierte en un cuello de botella para la decodificación.
- 128 GB de Memoria Unificada × 2: Una ventaja de Grace Blackwell, que no separa HBM y DDR. Permite que el modelo oficial FP8 de 154 GB se divida en dos unidades tal cual, con suficiente espacio para una caché KV de 19.85 GiB para un contexto de 512K.
- Implementación Nativa de la Atención Dispersa de DeepSeek (DSA): Los kernels b12x manejan correctamente el diseño donde la complejidad de la atención no depende de la longitud del contexto utilizando las operaciones dispersas nativas de GB10. Esto llevó al resultado de que la velocidad de decodificación no se desploma con la longitud del contexto.
En otras palabras, si solo uno de estos elementos —ancho de banda de memoria, potencia de cálculo, comunicación entre nodos, optimización de contexto largo o calidad de cuantización— fuera sobresaliente, este resultado no habría ocurrido. Spark proporciona todos estos elementos a un nivel más alto que cualquier configuración de una sola máquina en el mismo rango de precio. Esta es la verdadera naturaleza de su "equilibrio".
¿Qué Cambia en el Uso Práctico?
Para ir más allá de la teoría abstracta, aquí hay algunos beneficios concretos:
- El resumen y análisis de código de documentos enormes se vuelven realistas: Con un contexto de 512K y una velocidad de prefill de 1,277 tok/s, puedes cargar y resumir un libro completo (~300,000 tokens) en aproximadamente 4 minutos.
- Los bucles de agente no se estancan: Con concurrencia de 3.89×, puedes ejecutar chat y resumen de formato largo simultáneamente (por ejemplo, con Hermes Agent) sin que la decodificación colapse.
- No hay problemas de "el agente solo habla" debido a fallos de cuantización: Esta es una trampa en la que caí muchas veces con modelos de la serie IQ2; con calidad completa, simplemente no sucede.
- Competitivo con Mac en términos de consumo de energía: El consumo total de energía de dos GB10 durante la inferencia es de alrededor de 100W–140W, que está cerca de la Mac Studio M3 Ultra a máxima potencia. Considerando el rendimiento 1.78x, la eficiencia energética tampoco es mala.
Conclusión: La Era de Juzgar el Rendimiento de LLM Solo por TPS ha Terminado
La velocidad instantánea de generar un token —el TPS de decodificación— es ciertamente una métrica importante. Sin embargo, es como la "velocidad máxima de una carrera de 100 metros". Lo que se necesita en la práctica es el "tiempo para llegar a la misma respuesta correcta", la "calidad de la respuesta", "cuántos pueden ejecutarse simultáneamente", "qué longitud de contexto se puede manejar" y "si los bucles de agente funcionan". Estos son los puntajes totales.
Lo que mostró este resultado es que DGX Spark está comenzando a tomar la delantera en este puntaje total. Hemos entrado en una era donde puedes ejecutar un modelo enorme con calidad oficial, con contexto largo, manteniendo la compatibilidad con agentes, a 1.78x la velocidad real de una Mac Studio, simplemente conectando dos unidades en un clúster.
Durante los últimos años, la gente ha dicho "los LLM se tratan del ancho de banda de la memoria" y "el TPS de decodificación lo es todo", pero después de ejecutar realmente el Spark, siento que mi afirmación de que "el equilibrio es el rendimiento práctico" finalmente ha sido probada por los números.
El RTX Spark también fue anunciado, y hay una sensación de que las cosas se están calentando más de lo esperado (aunque el ambiente podría enfriarse una vez que se conozca el precio...). ¡Tengo grandes expectativas de que la comunidad crecerá y se acumulará más optimización y conocimiento!
Jensen es realmente increíble... ¿Continuará su reinado por mucho tiempo?
**
**
**
**
**
Bonus
Los lectores perspicaces podrían tener esta crítica:
"Entonces, ¿no sería una comparación justa si ejecutaras el FP8 oficial puro también en la Mac Studio?"
"¿No es injusta la comparación? La Mac Studio solo se volvió redundante porque se cuantizó a Q4. Si ejecutaras el FP8 oficial puro en la Mac Studio, ¿no estarían en igualdad de condiciones en términos de calidad?" Esta es una pregunta razonable.
Para ir al grano: Actualmente, no hay forma de ejecutar el 'FP8 oficial puro + MoE MXFP4' en una Mac Studio a velocidades prácticas.
- En primer lugar, no hay un motor de inferencia compatible.
No parece haber un motor que soporte completamente el formato oficial de DeepSeek-V4-Flash (atención FP8 + MoE MXFP4 + Lightning Indexer + Atención Dispersa DSA) en Apple Silicon (según una búsqueda de Claude Code).
- MLX (framework oficial de Apple Silicon para LLM de Apple): No tiene implementación nativa de MoE MXFP4 fused GEMM, no tiene FP8 paged attention y no tiene implementación MLX de la Atención Dispersa DSA de DeepSeek. Si intentaras ejecutarlo, probablemente tendrías que subir la precisión a bf16.
- llama.cpp: No puede cargar MXFP4 directamente, por lo que requiere re-cuantización a GGUF = termina siendo convertido a Q4 / Q5 / IQ2, etc., y ya no es la versión "oficial pura".
- vLLM: El soporte para Apple Silicon es limitado para empezar, y los kernels específicos de GB10 como b12x no se ejecutarán en una Mac.
- antirez/ds4: Este es un motor especializado escrito basado en MLX específicamente para DeepSeek V4 Flash con la suposición de Q4. Es la solución óptima actual para ejecutarlo en Mac Studio, pero no está construido para manejar "FP8 puro".
El hecho de que antirez escribiera un motor dedicado para DeepSeek V4 Flash específicamente para Q4 habla de la realidad de que actualmente no hay un camino práctico para ejecutar la calidad oficial tal cual en Apple Silicon.
- Incluso si se ejecutara con subida de precisión a bf16, el ancho de banda se consumiría casi por completo.
Para argumentar, digamos que alguien crea una implementación MLX que suba la precisión de los pesos oficiales a bf16. Puedes estimar lo que sucedería con un cálculo aproximado de ancho de banda:
- DeepSeek-V4-Flash tiene una configuración MoE con aproximadamente 30B de parámetros activos.
- En Q4 (4 bits), los parámetros activos ocupan unos 15 GB, y ds4 logra 26.2 tok/s (medido).
- Si el mismo modelo se mantiene en FP8 (8 bits), los parámetros activos ocupan unos 30 GB = 2x requisito de ancho de banda = teóricamente ~13 tok/s en el mismo motor.
- Además, subir la precisión a bf16 en MLX toma unos 60 GB para parámetros activos = 4x requisito de ancho de banda = teóricamente ~6.5 tok/s.
- Dado que el ancho de banda de memoria efectivo de la Mac Studio M3 Ultra es de aproximadamente 800 GB/s, leer 60 GB por cada token alcanzaría el límite de ancho de banda.
En otras palabras, la elección de "tomar la calidad pura" en Apple Silicon actualmente tiene el costo de "sacrificar más del doble de la velocidad". Ejecutar a 26.2 tok/s con ds4 + Q4 fue una elección más práctica que obtener solo 6 tok/s con bf16 de calidad completa.
- Aquí es donde entra la ventaja estructural de Spark.
Por otro lado, esta configuración de DGX Spark ejecuta el "FP8 oficial puro + MoE MXFP4 de forma nativa". Esto está respaldado por:
- La suite b12x de kernels específicos para GB10, que tiene implementaciones para ejecutar NVFP4 fused MoE GEMM y FP8 paged attention "sin des-cuantización".
- Esto no se ha escrito para Apple Silicon todavía.
- Como resultado, Spark es actualmente la única solución realista para ejecutar "calidad oficial tal cual" y "a velocidades prácticas".
Para resumir, si solo miras el ancho de banda del hardware, el valor absoluto de la Mac Studio para una sola unidad está en un nivel similar, pero la presencia o ausencia de "implementaciones de kernel que ejecuten formatos de cuantización oficiales de forma nativa" crea una diferencia decisiva. La ventaja de Spark no proviene solo del chip, sino de toda la combinación con el stack de software especializado para GB10 como b12x.
Si alguien escribe MoE MXFP4 fused GEMM, FP8 paged attention y Atención Dispersa DSA para Apple Silicon en MLX en el futuro, esta premisa se derrumbará. El panorama cambiará dependiendo de las implementaciones de la comunidad. Por ahora, el hecho es que Spark está un paso adelante en lograr la combinación de "calidad oficial × velocidad práctica".
Estos son los resultados del análisis proporcionado por Claude Code.
