NVIDIA DGX Spark: análisis, especificaciones, rendimiento y compra

De la caja a una estación de IA reproducible

La primera configuración debe producir un inventario, no solo una demostración. Registra referencia, firmware, versión de DGX OS, red, almacenamiento y usuarios. Después valida CUDA y una carga conocida antes de añadir aplicaciones de terceros.

1. Revisa ubicación y alimentación. Deja ventilación y evita conectar periféricos o adaptadores no previstos durante el diagnóstico inicial.
2. Completa la configuración del sistema. Crea una cuenta administrativa separada del uso diario y aplica las actualizaciones recomendadas.
3. Configura red. Utiliza una dirección conocida, DNS y segmentación. No publiques servicios de modelo en Internet.
4. Comprueba almacenamiento. Separa espacio para modelos, contenedores, datos y copias. Define un umbral de capacidad.
5. Valida el entorno NVIDIA. Confirma que el sistema reconoce el acelerador y ejecuta un contenedor o ejemplo oficial.
6. Prueba un modelo pequeño. Mide carga, prefill y generación, y verifica que el proceso utiliza la GPU.
7. Versiona la configuración. Guarda sistema, programa que ejecuta el modelo, modelo, cuantización y resultados.

Arquitectura ARM64: DGX Spark utiliza una CPU Grace basada en ARM. El software debe disponer de paquetes o contenedores compatibles. Revisa binarios nativos y extensiones CUDA antes de dar por hecho que un entorno x86 se trasladará sin cambios.

Calcular qué aporta la memoria coherente a una carga concreta

La ventaja principal es la capacidad: CPU y GPU comparten 128 GB. Esto permite mantener pesos y contexto que superan la VRAM habitual. No significa que toda la memoria esté disponible para el modelo ni que tenga el mismo ancho de banda que una GPU discreta de gama alta.

Cuándo una GPU discreta sigue siendo preferible

Si el modelo y el contexto caben con margen en VRAM, una GPU discreta con mayor ancho de banda suele generar más rápido. Spark no sustituye automáticamente una estación RTX; resuelve otra frontera: capacidad local compacta con CUDA y un entorno integrado.

Cuándo Spark cambia la viabilidad

Cuando una variante necesita más memoria de la disponible en una GPU convencional, la alternativa suele ser descargar a RAM, cuantizar más, reducir contexto o pasar a infraestructura de mayor capacidad. Spark permite mantener una carga mayor dentro del espacio coherente y evita parte de esos compromisos.

Reducir incompatibilidades mediante entornos fijados

Utiliza contenedores o entornos virtuales por proyecto. Fija imagen, dependencias y modelo. No instales bibliotecas globales para cada prueba; un cambio de CUDA, PyTorch o extensión puede romper otras cargas.

• Imagen o entorno por aplicación
• Compatibilidad ARM64 comprobada
• Versiones de CUDA y framework registradas
• Modelos y datasets fuera de la capa del contenedor
• Secretos mediante variables protegidas o gestor
• Puertos ligados a localhost o red interna
• Prueba de actualización y reversión

Para Ollama, confirma que el modelo es local, la ventana efectiva y el procesador mediante ollama ps. Para Open WebUI, deja Ollama en una red interna. Para ComfyUI, separa modelos y nodos personalizados y registra snapshots.

Crear una ficha de benchmark que se pueda comparar

Las cifras publicadas solo son útiles si indican modelo, precisión, motor, contexto y versión. Prefill y generación son fases distintas. Una optimización puede acelerar una de ellas sin cambiar la otra.

1. Descarga una variante identificable y registra su tamaño.
2. Reinicia o libera memoria para medir carga en frío.
3. Ejecuta un prompt corto y otro con el contexto objetivo.
4. Conserva número de tokens de entrada y salida.
5. Registra tiempo de carga, prefill, generación y total.
6. Repite con el modelo residente y calcula variación.
7. Añade sesiones concurrentes y percentiles.
8. Comprueba memoria, temperatura y errores durante una prueba sostenida.

Ficha mínima
- equipo y versión de sistema
- motor y versión
- familia, variante y cuantización
- contexto solicitado y efectivo
- tokens de entrada y salida
- tiempo de carga
- tokens/s de prefill y generación
- pico de memoria
- concurrencia y percentil de latencia

No compares el petaFLOP FP4 con FLOPS FP64 científicos. Son precisiones y cargas diferentes. Para una compra, compara el trabajo real que debe terminar el equipo.

Preparar el emparejamiento para modelos de hasta 405B

NVIDIA destaca el enlace de dos DGX Spark mediante ConnectX para cargas distribuidas y modelos de hasta 405B. Necesitas dos sistemas compatibles, un cable DAC QSFP adecuado y software que reparta el modelo. No es una suma automática para cualquier aplicación.

Para una pyme, más de dos unidades suelen ser más sencillas de operar como réplicas, colas, embeddings, lotes o modelos por función. NVIDIA también valida tres nodos en anillo y hasta cuatro mediante un switch compatible; repartir un único modelo entre ellos exige un programa que ejecuta el modelo distribuido, una topología soportada y pruebas de recuperación. La guía de clústeres de DGX Spark separa ambos escenarios.

Convertir Spark en un servicio interno sin exponer la consola

Usuarios → HTTPS / SSO → aplicación → cola → servidor de modelo
                                      ↘ métricas y límites

• Identidad y autorización en la aplicación
• Ollama o programa que ejecuta el modelo accesible solo desde red interna
• Cuotas de contexto, salida y concurrencia
• Modelos permitidos y versiones fijadas
• Separación entre chat, lotes y tareas de entrenamiento
• Registro proporcional sin prompts completos por defecto
• Copias de configuración, índices y datos autorizados
• Plan de mantenimiento y continuidad

Un único Spark puede servir a varias personas si el modelo y la latencia lo permiten. Cuando el problema es cola, añade réplicas o separa cargas; un modelo más grande puede empeorar el servicio.