DGX Spark es la opción adecuada para el desarrollo local, la creación de prototipos y los experimentos de un solo especialista; DGX Station conviene cuando se necesita mucha más memoria, modelos de mayor tamaño o un recurso informático compartido para un equipo pequeño; un sistema DGX en rack es necesario cuando la inteligencia artificial se convierte en un servicio permanente con usuarios simultáneos y requisitos de disponibilidad, tolerancia a fallos, supervisión y escalabilidad. La frontera entre la IA de escritorio y el centro de datos no la determina el número de parámetros del modelo ni el rendimiento máximo en petaflops, sino la responsabilidad sobre el resultado: si el fallo de un dispositivo interrumpe el trabajo de los clientes o un proceso empresarial, una sola estación de trabajo ya no es suficiente.
En este artículo, el término DGX Server se utiliza como denominación general para los sistemas NVIDIA DGX en rack y la infraestructura construida a su alrededor. No es el nombre de un modelo independiente. DGX B300 se utiliza como ejemplo actual de la clase de servidor. Las especificaciones están actualizadas a julio de 2026.
NVIDIA DGX servers
Tres clases de sistemas, tres modelos de explotación
DGX Spark suele pertenecer a un desarrollador, que lo utiliza para probar modelos, crear prototipos y evaluar una futura arquitectura. Su fallo interrumpe el trabajo personal, pero no detiene un servicio externo.
DGX Station puede utilizarse como una potente máquina personal o como un nodo compartido para un equipo pequeño. Las funciones de administración de nivel servidor permiten instalarla en una sala independiente, pero físicamente sigue siendo un único sistema y un único punto de fallo.
Una DGX en rack está diseñada desde el principio para un centro de datos y para conectarse a redes, almacenamiento, supervisión y planificadores compartidos. La alta disponibilidad solo aparece cuando existen varios nodos y la infraestructura que los rodea.
DGX Spark, DGX Station y DGX en rack: diferencias principales
| Criterio | DGX Spark | DGX Station | DGX en rack |
|---|---|---|---|
| Función principal | Desarrollo personal | Cargas locales exigentes y recurso compartido para un equipo | Plataforma de IA para producción |
| Usuarios | Un especialista principal | Un especialista o un equipo pequeño | Varios equipos y servicios |
| Cargas típicas | Prototipos, ejecución local, ajuste fino eficiente en parámetros | Modelos grandes, contextos largos, investigación | Inferencia bajo carga, entrenamiento, servicios compartidos |
| Ubicación | Puesto de trabajo | Oficina, laboratorio o sala independiente | Centro de datos preparado |
| Administración | Principalmente local | BMC, Redfish y supervisión de GPU | Administración centralizada de nodos y clústeres |
| Escalado | Uno o dos sistemas | Hasta dos estaciones conectadas | Varios servidores y racks |
| Tolerancia a fallos | No incluida | Un único dominio de fallo | Diseñada a nivel de varios nodos |
| Criterio de elección | Velocidad de las iteraciones personales | Capacidad para el modelo y acceso compartido | SLA, carga y crecimiento |
El rendimiento máximo de estos sistemas no puede convertirse directamente en tokens por segundo. La velocidad real depende de la arquitectura y la precisión del modelo, la longitud del contexto, el tamaño del lote de solicitudes, el paralelismo y el entorno de software.
DGX Spark: un sistema personal, no un centro de datos en miniatura
Imagen oficial de DGX Spark.
Fuente de la imagen: NVIDIA
DGX Spark está basado en el superchip GB10 Grace Blackwell con un procesador Arm de 20 núcleos. El sistema incluye 128 GB de memoria coherente LPDDR5X, una unidad NVMe de 4 TB, un adaptador ConnectX-7, red de 10 Gbit/s y una fuente de alimentación de 240 W. NVIDIA indica que ofrece hasta 1 petaflop de cálculo FP4, admite modelos de hasta 200.000 millones de parámetros y permite ajustar modelos de hasta 70.000 millones de parámetros. Se pueden conectar dos sistemas para experimentar con modelos de hasta 405.000 millones de parámetros.
Estos límites no implican la misma velocidad para cualquier modelo. Poder cargar los pesos no garantiza una generación cómoda con un contexto largo o con varios usuarios.
Para qué tareas es adecuado Spark
- desarrollo local de aplicaciones y agentes de IA;
- inferencia para uso personal;
- creación de prototipos de búsqueda documental;
- experimentos con cuantización y LoRA;
- pruebas de contenedores y bibliotecas;
- tratamiento de datos confidenciales;
- preparación de un proyecto para migrarlo a la nube o a un centro de datos.
Spark acelera las iteraciones personales, pero sus 128 GB de LPDDR5X no deben considerarse equivalentes a la HBM de un servidor. Además de los pesos, la memoria se utiliza para la caché de contexto, los búferes de trabajo, las activaciones y el sistema operativo. Por ello, un modelo puede cargarse correctamente, pero responder demasiado despacio con un contexto largo o varios usuarios.
Spark utiliza Arm. Las herramientas de NVIDIA admiten esta arquitectura, pero las extensiones propias y los contenedores antiguos pueden haberse compilado únicamente para x86, algo que debe tenerse en cuenta antes de la migración.
Qué aporta conectar dos sistemas Spark
Dos sistemas resultan útiles para experimentar con modelos más grandes y con ejecución distribuida. Sin embargo, la comunicación se realiza a través de una red externa, lo que introduce latencia, dependencia de la estrategia de paralelismo y un diagnóstico más complejo.
Sigue siendo una configuración de investigación y no un equivalente directo de un servidor con varias GPU. En un sistema en rack, los aceleradores están conectados mediante una fábrica interna especializada, mientras que dos unidades Spark siguen siendo ordenadores independientes.
DGX Station: estación de trabajo y nube personal
DGX Station, basada en GB300 Grace Blackwell Ultra, ofrece 252 GB de HBM3e en el lado de la GPU y 496 GB de LPDDR5X en el lado de la CPU, para un total de 748 GB de memoria coherente. NVIDIA especifica hasta 20 petaflops de cálculo FP4, compatibilidad con modelos de hasta un billón de parámetros, un adaptador ConnectX-8 de hasta 800 Gbit/s, siete instancias MIG, BMC, Redfish y NVIDIA Data Center GPU Manager. La potencia total del sistema alcanza los 1.600 W.
La cifra de 748 GB también requiere una aclaración. El sistema ofrece un espacio de direcciones coherente unificado, pero los 252 GB de HBM3e y los 496 GB de memoria de CPU tienen un ancho de banda diferente. No son 748 GB de memoria GPU con la misma velocidad.
Cuándo Station es claramente mejor que Spark
Station es necesaria cuando el modelo y el contexto no caben en 128 GB, el ajuste fino requiere más memoria de trabajo, se procesan grandes conjuntos de datos o un equipo pequeño comparte un único sistema.
Hasta siete instancias MIG permiten dividir el acelerador entre distintas cargas, asignando a cada instancia una parte de los recursos de cálculo, la caché y la HBM. Por ejemplo, un especialista puede ejecutar un modelo, otro analizar datos y un tercero probar un entorno de software actualizado.
MIG no combina los recursos para formar un acelerador mayor. Esta tecnología divide una GPU física en particiones aisladas; no acelera una única carga sumando todas las instancias independientes.
Por qué Station se denomina nube personal
Station puede instalarse en una sala separada y utilizarse como nodo de servidor compartido. BMC, Redfish y DCGM proporcionan administración remota y métricas, mientras que el equipo obtiene partición de recursos, una colección compartida de modelos y una cola de tareas.
Por su forma de acceso, es un pequeño recurso de nube interna. El sistema puede funcionar sin monitor conectado, mientras los usuarios ejecutan los cálculos de forma remota.
Por qué sigue sin ser un centro de datos
MIG aísla a los usuarios dentro de un acelerador, pero todas las particiones dependen del mismo chasis, del mismo sistema de alimentación y del mismo nodo de software. Una actualización o un fallo de hardware detiene todas las cargas.
Una sola Station no proporciona automáticamente:
- el envío de solicitudes a un nodo de reserva;
- actualizaciones sin interrupción de todo el servicio;
- mantenimiento del rendimiento durante los picos de demanda;
- almacenamiento compartido tolerante a fallos;
- escalado independiente de varios servicios;
- redundancia de los modelos y del estado de las aplicaciones.
DGX Station puede funcionar como servidor, pero no sustituye a un clúster ni crea por sí sola alta disponibilidad.
Incluso dos sistemas Station conectados siguen siendo dos nodos. Utilizarlos para una aplicación permanente requiere un balanceador de carga externo, almacenamiento compartido, sincronización de la configuración y una lógica de aplicación capaz de sobrevivir a la pérdida de uno de los sistemas.
Qué cambia al pasar a una DGX en rack
Vista frontal oficial de NVIDIA DGX B300 con el panel instalado.
Fuente de la imagen: NVIDIA DOCS
DGX B300 muestra la magnitud de la diferencia. Su chasis de 10U contiene ocho aceleradores Blackwell Ultra SXM con un total de 2,1 TB de memoria GPU. Dos conmutadores NVLink proporcionan hasta 14,4 TB/s de ancho de banda agregado entre los aceleradores. La conectividad externa incluye ConnectX-8 de hasta 800 Gbit/s y una DPU BlueField-3. El consumo estimado de un sistema es de aproximadamente 14 kW.
No se trata simplemente de una Station más rápida. Una DGX en rack está diseñada para:
- uso centralizado por varios equipos;
- entrenamiento distribuido y a gran escala;
- ajuste fino completo o intensivo en recursos;
- procesamiento por lotes a gran escala;
- servicio de varios modelos;
- inferencia de producción con solicitudes simultáneas;
- agentes permanentes y servicios de IA empresariales;
- conexión a redes compartidas de almacenamiento y administración.
Dentro de DGX B300, los aceleradores están conectados mediante la fábrica NVLink. Para los modelos distribuidos entre varias GPU, esto es fundamentalmente distinto de la comunicación entre sistemas de escritorio independientes a través de una red externa.
Las interconexiones de alta velocidad no solo son necesarias para el entrenamiento. Un modelo grande también puede dividirse entre varios aceleradores durante la inferencia. Si las particiones del modelo intercambian activaciones de forma continua, la latencia y el ancho de banda de la interconexión afectan directamente al rendimiento final.
La clase de servidor no la define únicamente la GPU
Un sistema en rack añade administración de hardware, diagnóstico, supervisión empresarial, planificadores, cuotas, actualizaciones centralizadas y conexiones a redes separadas de administración, almacenamiento y cálculo.
Sin embargo, una única DGX B300 sigue siendo un punto de fallo si todas las solicitudes se dirigen a ella. Ocho GPU en un solo chasis aumentan el rendimiento, pero no protegen la aplicación frente a la caída del servidor, un fallo del sistema operativo o una interrupción por mantenimiento.
Un servidor DGX todavía no es un centro de datos
Más allá del chasis, un servidor necesita alimentación, refrigeración, red, almacenamiento y un modelo de operación. Esta infraestructura circundante es la que convierte un nodo de cálculo en una plataforma de producción.
Para DGX B300, NVIDIA describe un rack con dos sistemas que consume aproximadamente 30 kW de media y hasta 39,4 kW en picos. Una configuración densa con cuatro sistemas requiere aproximadamente 58 kW de media y hasta 76 kW en picos. La documentación también trata la alimentación trifásica, la redundancia, la carga sobre el suelo, los pasillos de servicio, el cableado, la detección de fugas y la refrigeración.
El proyecto también requiere alimentación y refrigeración redundantes, redes de administración y cálculo, almacenamiento compartido, un registro de modelos, un planificador de GPU, balanceadores de carga, métricas y registros centralizados, control de acceso, copias de seguridad y despliegue automatizado.
Una infraestructura alternativa no tiene por qué limitarse a una DGX preintegrada. Las empresas pueden considerar servidores Dell PowerEdge de 17.ª generación de uso general, con aceleradores, procesadores, almacenamiento y red configurados para la carga.
En los sistemas que utilizan GPU PCIe también son populares los servidores AMD EPYC por su gran número de líneas PCIe, así como los servidores Intel Xeon cuando la infraestructura ya está estandarizada sobre esa plataforma.
Una DGX preintegrada simplifica la compatibilidad de los componentes y del conjunto de software. Un servidor OEM ofrece más libertad al elegir la configuración. En ambos casos, la tolerancia a fallos procede de una arquitectura con varios nodos, no de la marca del hardware.
DGX System, BasePOD y SuperPOD no son lo mismo
Un sistema DGX individual es un nodo de cálculo. DGX BasePOD es una arquitectura de referencia para combinar varios sistemas con red, almacenamiento y administración.
DGX SuperPOD es una plataforma escalable de centro de datos en la que los nodos de cálculo, InfiniBand y Ethernet, los servidores de administración, el software y el almacenamiento se diseñan como un sistema unificado. La documentación de NVIDIA describe SuperPOD específicamente como una combinación de sistemas DGX, fábricas de red, nodos de administración y almacenamiento, no simplemente como racks llenos de GPU.
Después del primer servidor, el objeto de diseño deja de ser una máquina individual. Hay que calcular las rutas de datos, el número de puertos de red, el ancho de banda del almacenamiento, la redundancia de los servicios de administración y el comportamiento de las aplicaciones cuando se pierde un nodo.
SuperPOD no es necesario para todos los proyectos. Entre una sola estación de trabajo y una instalación a gran escala hay muchas opciones intermedias: varios servidores GPU, un clúster pequeño, equipos alojados en un centro de datos o una combinación de recursos locales y servicios en la nube.
Es natural intentar limitarse a la inversión mínima necesaria. Una Station con BMC es, en la práctica, un servidor y resulta suficiente en algunos casos, pero no en todos.
Cuándo Station deja de ser suficiente
| Cambio en el proyecto | Limitación de una sola Station | Qué aporta la infraestructura de servidor |
|---|---|---|
| Los clientes utilizan el modelo de forma continua | La caída de un nodo detiene el servicio | Varias instancias y balanceo de carga |
| Aumenta el número de solicitudes simultáneas | Aumentan las colas y la latencia | Escalado horizontal |
| Trabajan varios equipos | Los usuarios compiten por una sola GPU | Grupos de recursos, cuotas y prioridades |
| Se necesitan distintos modelos al mismo tiempo | La memoria y el cálculo se fragmentan | Enrutamiento y escalado independiente |
| Las actualizaciones no pueden implicar una interrupción | Hay que detener toda la Station | Actualizaciones graduales de los nodos |
| Aparecen requisitos de SLA | Un solo chasis sigue siendo un punto único de fallo | Redundancia y conmutación por error automática |
| Aumenta el volumen de datos y artefactos | Las unidades locales son insuficientes | Almacenamiento compartido y registro de modelos |
| Se necesita observabilidad continua | La telemetría de un nodo no muestra todo el servicio | Métricas, registros y alertas unificados |
La IA de escritorio termina cuando el resultado del modelo se convierte en un compromiso con otras personas o sistemas empresariales. Un modelo pequeño puede requerir un clúster de servidores si miles de usuarios lo utilizan las 24 horas. Por el contrario, un modelo con cientos de miles de millones de parámetros puede seguir siendo una carga de investigación en Station si lo utiliza un solo especialista y se admite una interrupción.
La transición suele estar impulsada por cinco cambios:
- La inactividad adquiere un coste. Una caída del sistema afecta a las ventas, la atención al cliente, la producción o las operaciones internas.
- La carga se vuelve impredecible. Un nodo gestiona el flujo medio, pero no soporta los picos.
- La propiedad de los recursos se distribuye. Los equipos necesitan cuotas, prioridades y aislamiento.
- Las actualizaciones ya no pueden realizarse para todos al mismo tiempo. El tráfico debe desplazarse entre versiones.
- El modelo pasa a formar parte de una aplicación. Hay que observar toda la ruta de la solicitud, no solo la utilización de la GPU.
Qué clase se adapta a distintas cargas
Desarrollo local y RAG
Spark resulta práctico para experimentar con frecuencia con código, prompts, cuantización y un índice documental limitado.
Station es necesaria cuando el modelo, el contexto o el conjunto de datos no caben en 128 GB, o cuando todo un departamento comparte el recurso. Para la búsqueda empresarial local puede servir como un sistema intermedio conveniente.
Un grupo de servidores resulta necesario cuando la búsqueda atiende a muchos usuarios, aplica distintos permisos sobre los documentos y debe funcionar sin una ventana de inactividad común. En este caso, la base de datos vectorial, la obtención de los documentos de origen y la interfaz de la aplicación deben escalarse junto con el modelo.
Ajuste fino
LoRA y otros métodos eficientes en parámetros son adecuados para Spark o Station con modelos de tamaño moderado. Modifican una proporción relativamente pequeña de los parámetros y no requieren almacenar un conjunto completo de pesos entrenables ni estados del optimizador.
El ajuste fino completo requiere memoria para los pesos, los gradientes, los estados del optimizador, las activaciones y los datos. El volumen de trabajo puede ser muchas veces superior al tamaño del archivo del modelo terminado.
Cuando una carga se distribuye entre varias GPU, NVLink, la red externa y la velocidad del almacenamiento se vuelven decisivos. Si los aceleradores permanecen inactivos mientras esperan datos o sincronización, no se aprovecha su rendimiento máximo.
Inferencia y agentes de IA
Para un solo usuario importan la capacidad del modelo y el tiempo de respuesta. Un servicio de producción también debe controlar las solicitudes simultáneas, la latencia, las colas, las distintas versiones del modelo y la recuperación tras un fallo.
Un agente personal puede ejecutarse en Spark, mientras que un agente de departamento puede hacerlo en Station. Un sistema multiagente conectado a aplicaciones empresariales requiere operaciones de nivel servidor: almacenamiento de estado, control de acceso, reintentos de operaciones fallidas y observabilidad de todo el proceso.
El propio modelo lingüístico puede seguir siendo de tamaño moderado. La infraestructura se complica no solo por los requisitos de cálculo, sino también por el número de herramientas, la duración de las tareas, el historial almacenado y el coste de una acción incorrecta.
Por qué la capacidad de memoria es solo una parte del cálculo
Durante la inferencia, la memoria no solo se utiliza para los pesos, sino también para la caché de contexto, que crece con el número de conversaciones y la longitud de su historial. El ajuste fino añade activaciones, gradientes y estados del optimizador. La cuantización reduce el tamaño de los pesos, pero no elimina los demás costes y puede afectar a la calidad y la velocidad.
El NVMe local resulta práctico para el modelo activo, pero un equipo necesita un catálogo compartido, control de versiones, derechos de acceso, copias de seguridad y transferencia rápida de datos entre nodos. Los entornos de producción suelen separar el almacenamiento de trabajo, los archivos de objetos, el registro de modelos y las copias de seguridad.
La red también se compone de varios planos:
- acceso de los usuarios a la aplicación;
- administración del hardware;
- comunicación entre los nodos de cálculo;
- obtención de modelos y conjuntos de datos;
- transmisión de métricas y registros.
La presencia de ConnectX en el chasis no crea una fábrica de clúster sin conmutadores, cables, topología y software adecuados.
Economía: el precio del sistema no es el único coste
Para el desarrollo, los factores importantes son el tiempo de espera del acelerador, la velocidad de los experimentos, el almacenamiento de datos y el coste del trabajo del especialista. Para un servicio de producción, incluyen el coste por solicitud, la utilización de la GPU, la latencia, la capacidad de reserva, la electricidad, la refrigeración, la red, el soporte y las pérdidas causadas por la indisponibilidad.
Spark se convierte en un falso ahorro cuando varios especialistas esperan cada día a que el recurso quede libre. Un clúster no resulta rentable si permanece inactivo. Station suele ser el nivel intermedio: elimina la limitación de memoria y permite el acceso compartido sin exigir un proyecto completo de centro de datos.
También debe tenerse en cuenta el perfil de la carga. El desarrollo interactivo suele generar picos irregulares: un especialista ejecuta un experimento, evalúa el resultado y modifica el código. La inferencia de producción puede funcionar de forma continua, pero su carga depende de la hora del día y de la actividad de los usuarios.
La nube resulta práctica para entrenamientos grandes ocasionales y picos de demanda, mientras que las cargas continuas y predecibles pueden asignarse a hardware propio. Un modelo híbrido requiere contenedores portables y almacenamiento independiente del entorno de cálculo.
Cómo pasa un proyecto de Spark a Station y a una plataforma de servidor
Prototipo personal
El desarrollador prueba el modelo y la arquitectura de la aplicación. Incluso en esta fase se necesitan contenedores, un entorno reproducible y mediciones del uso de memoria y la latencia. Los datos y el estado no deben quedar estrechamente ligados a la unidad local de Spark.
Recurso compartido para el equipo
Cuando aparecen varios usuarios, la carga se traslada a Station o a otro nodo potente. Se añaden acceso remoto, una cola de tareas, partición de GPU, una colección compartida de modelos y métricas operativas.
En esta fase queda claro con qué frecuencia los usuarios interfieren entre sí, si el aislamiento de MIG es suficiente y si todo el sistema puede detenerse para realizar actualizaciones.
Servicio de producción
En el centro de datos, la aplicación se despliega en varios nodos, el cálculo se separa del almacenamiento y se añaden balanceo de carga, gestión de versiones y recuperación automática.
Spark y Station utilizan procesadores Arm, mientras que DGX B300 utiliza Intel Xeon. Por tanto, los contenedores deben compilarse para varias arquitecturas y las extensiones binarias deben probarse por separado. El conjunto unificado de NVIDIA facilita la migración de modelos, pero no garantiza la compatibilidad de todo el código personalizado.
Debe medirse toda la ruta de la solicitud: obtención de datos, búsqueda, preparación del contexto, ejecución del modelo y almacenamiento del resultado. Una generación más rápida no ayudará si el principal retraso se produce en el almacenamiento.
Errores habituales al comparar sistemas DGX
- Suponer que un modelo cargado ya funciona de manera aceptable. Puede caber en la memoria, pero responder demasiado despacio o no gestionar solicitudes simultáneas.
- Tratar 128, 748 y 2.100 GB como el mismo tipo de memoria. Spark utiliza LPDDR5X, Station combina HBM3e con LPDDR5X del lado de la CPU y la cifra de DGX B300 corresponde a la memoria de ocho GPU.
- Equiparar MIG con la tolerancia a fallos. MIG aísla los recursos de los usuarios, pero todas las particiones se detienen si falla el nodo físico.
- Considerar dos sistemas de escritorio equivalentes directos a un servidor con varias GPU. Una carga distribuida depende de la red e introduce latencia adicional.
- Elegir un sistema por sus cifras máximas de FP4. No muestran la velocidad de un modelo concreto con la precisión, la longitud de contexto y la carga requeridas.
- Suponer que el despliegue local es automáticamente seguro. Sin actualizaciones, controles de acceso, cifrado y registro, un sistema local también crea riesgos.
- Comprar un servidor sin calcular la infraestructura circundante. Una DGX en rack puede requerir mejoras en la alimentación, la refrigeración, la red y el almacenamiento.
Qué elegir
DGX Spark es adecuado para un especialista o una pequeña carga de investigación cuando son importantes el funcionamiento local, las iteraciones rápidas y la posibilidad de ejecutar modelos grandes sin depender continuamente de la nube.
DGX Station es necesaria cuando los modelos, el contexto o los datos ya no caben en Spark y el recurso de cálculo lo utiliza un experto o un equipo pequeño. Ofrece administración de nivel servidor y partición de recursos, pero sigue siendo un único nodo.
Una DGX en rack o un clúster de servidores GPU se vuelve necesario cuando el modelo se convierte en un servicio: aparecen usuarios simultáneos, SLA, varios equipos, escalado independiente, almacenamiento y supervisión centralizados, y un único punto de fallo deja de ser aceptable.
Un centro de datos no comienza con la octava GPU ni con un determinado número de parámetros. Comienza cuando ya no basta con proporcionar potencia de cálculo: esa capacidad debe operarse de forma fiable, segura y predecible.
Índice:
