El titular de DGX Spark para quienes construyen no es «una GPU bajo el monitor». Es 128 GB de memoria de sistema unificada coherente en un Grace Blackwell GB10, más una ruta de software soportada por NVIDIA (DGX OS, contenedores, clustering). Esa combinación cambia lo que puedes alojar en local — y no borra las cuentas de memoria, los bugs de serving ni la economía de la nube.
Este artículo es el compañero operativo de qué es DGX Spark. Las especificaciones y los mensajes de producto se anclan a la página de producto y a las notas de la versión de NVIDIA (documentación revisada el 2026-08-04).
La inferencia local sigue consumiendo mucha energía y generando calor. Dimensiona circuitos y refrigeración para carga continua, no para el modo demo en reposo. No expongas puertos compatibles con OpenAI a internet pública sin autenticación, TLS y política de red.
Memoria unificada: qué significa «128 GB coherentes» en la práctica
En una caja clásica con GPU discreta planificas alrededor de la VRAM de la GPU para pesos y caché KV, y de la RAM del host para todo lo demás — con copias caras a través del límite PCIe.
En Spark, la arquitectura de NVIDIA presenta memoria de sistema unificada coherente: CPU y GPU comparten un único pool grande (128 GB LPDDR5x según NVIDIA). Para el diseño de serving eso significa:
- Los pesos de modelos grandes pueden residir en el mismo pool que el runtime usa para activaciones y caché KV.
- Sigues teniendo un techo duro: pesos + KV + overhead del framework + OS + otros servicios deben caber.
- Las características de ancho de banda y latencia difieren de las GPUs de datacenter con mucho HBM. NVIDIA lista el ancho de banda de memoria en la página de producto; trátalo como límite de hardware, no como promesa de tok/s.
Presupuesto aproximado de memoria (ilustrativo, no una garantía)
Úsalo como boceto de planificación. Las huellas exactas dependen de la arquitectura, la cuantización y el motor de serving.
| Consumidor | Qué consume |
|---|---|
| Pesos del modelo | Término dominante; FP4/FP8/INT4 cambian la curva con fuerza |
| Caché KV | Crece con longitud de contexto × secuencias concurrentes |
| Runtime / CUDA graphs / framework | Overhead fijo no trivial |
| OS + Docker + agentes + monitorización | Fácil de subestimar en una caja «dedicada» |
| Margen | Deja margen para picos y actualizaciones |
Presupuesta a partir de los contextos concurrentes medidos en pico, no de un solo chat. El crecimiento de la caché KV es uno de los riesgos de OOM; reprodúcelo con una prueba de carga en lugar de tratar un fallo hipotético de dos sesiones como si fuera un hecho histórico.
Cómo leer la afirmación de ~200B en un solo nodo de NVIDIA
NVIDIA comercializa DGX Spark para modelos de IA de hasta ~200 mil millones de parámetros en una unidad de escritorio con la gran memoria unificada. Léelo como:
- Comunicación de capacidad del proveedor, no un SLA medido para cada checkpoint abierto.
- Implícitamente ligado a precisión eficiente (NVIDIA destaca rendimiento pico de clase FP4 de hasta 1 PFLOP FP4) y a una ruta de serving soportada.
- Independiente de si tu modelo preferido, tokenizer, plantilla de tool-calling y suite de eval se comportan bien a ese tamaño.
Lo que la afirmación no dice:
- 200B a precisión completa con contexto largo y alta concurrencia.
- Paridad con modelos de vanguardia alojados en tareas difíciles.
- Un número específico de tokens/s que puedas poner en un contrato con clientes.
Para modelos mayores o serving con tensor-parallel, NVIDIA documenta escalado multinodo (que se suele describir como 2–4 Sparks) vía ConnectX-7. Consulta la documentación de clustering y conectar dos Sparks. Las recetas de comunidad (por ejemplo vLLM tensor-parallel sobre RoCE) son específicas de la receta; trata sus tok/s y contexto máximo como informes que debes volver a medir, no como garantías universales.
Candidatos documentados de stack de serving
Un modelo mental útil:
DGX OS (stack de NVIDIA basado en Ubuntu)
→ drivers de NVIDIA / runtime de contenedores
→ contenedor de serving (vLLM, TensorRT-LLM, NIM u otro)
→ HTTP compatible con OpenAI (o gRPC)
→ agentes / n8n / apps en la LAN
DGX OS y contenedores
DGX Spark ejecuta DGX OS. Planifica actualizaciones, ventanas de reinicio y permisos de Docker (o equivalente) igual que para cualquier host de inferencia. Los playbooks de NVIDIA asumen una instalación actual de DGX OS y acceso GPU de contenedor / nvidia-smi funcionando antes de perseguir bugs del modelo.
Opciones de serving (elige por criterios, no por moda)
| Stack | Motivo típico para elegirlo | Precauciones |
|---|---|---|
| vLLM | Serving compatible con OpenAI, cobertura amplia de modelos abiertos, recetas multinodo | Compatibilidad de versión + cuantización; ajusta max seqs/KV |
| TensorRT-LLM (TRT-LLM) | Engines optimizados por NVIDIA para modelos soportados | Coste de build del engine; «mejor ruta» más estrecha por modelo |
| NVIDIA NIM / rutas NGC | Cuando quieres un microservicio empaquetado por NVIDIA para un modelo listado | Catálogo de modelos y términos de licencia; no todo checkpoint de HF |
| llama.cpp / clase Ollama | UX local simple para modelos más pequeños o cuantizados | Puede no ser la ruta para las cargas más grandes de clase Spark |
Los playbooks en NVIDIA dgx-spark-playbooks cubren vLLM, TRT-LLM, Ollama y rutas relacionadas. Empieza la evaluación desde un playbook vigente documentado por el proveedor, fija la versión de cada artefacto y personaliza solo después de reproducir una línea base en el propio equipo.
Endpoint orientado a agentes
La mayoría del pegamento de pymes (n8n, Hermes, OpenClaw, apps propias) espera una URL base compatible con OpenAI /v1/chat/completions en la LAN o VPN. Mantén ese contrato estable aunque cambies engines detrás. Registra model id, cuantización y versión del servidor en cada ejecución de eval para que «empeoró» sea diagnosticable.
Protocolo de medición (mínimo)
Antes de llamar a un modelo local «producción»:
- Empieza con un conjunto de evaluación de 20–50 prompts que representen el trabajo real (no chat de juguete), luego amplíalo al descubrir clases de fallo; esto es un rango de prueba de humo, no una garantía estadística.
- Registra fecha, versión del motor de serving, model id, precisión, contexto máximo y concurrencia.
- Mide latencia p50/p95 y cualquier tasa de OOM/timeout bajo esa concurrencia.
- Puntúa calidad con una rúbrica humana o comprobaciones automatizadas en las que confíes para esa tarea.
- Vuelve a ejecutar el mismo protocolo tras cada actualización de engine o OS.
Sin ese bucle, Spark se convierte en folclore: «se notaba rápido el martes pasado».
Modos de fallo para los que debes diseñar
| Fallo | Síntoma | Mitigación |
|---|---|---|
| OOM de pesos / KV | Proceso terminado, CUDA OOM, workers colgados | Baja contexto, concurrencia o precisión; divide entre nodos |
| Limitación térmica / de potencia | Saltos bruscos de latencia bajo carga sostenida | Mide bajo carga; comprueba flujo de aire y circuito |
| Contenedor obsoleto / desfase de driver | Fallos misteriosos tras actualizar el OS | Fija versiones; prueba de humo tras cada actualización |
| Disco lleno (caché de modelo) | Fallos de descarga, capas corruptas | Dimensiona NVMe para modelos + logs; poda cachés |
| Caída de un solo nodo | Los agentes fallan en abierto o en silencio | Health checks; ruta alternativa en la nube o SaaS |
| API sin autenticación | Cualquiera en la LAN extrae tu modelo privado | Vincula el servicio a una interfaz privada; auth; ACL de red |
| Caída brusca de calidad por cuantización | Disparate fluido en tareas difíciles | Conjunto de eval específico de la tarea antes de la puesta en producción |
| Abuso de herramientas del agente | Modelo local + shell ≠ seguro | Sandbox (consulta NemoClaw); listas de permitidos |
Local no significa sin registro en ningún sitio. Decide la retención de prompts, trazas de herramientas y documentos recuperados. El cifrado de disco y el control de acceso importan tanto como «sin API en la nube».
Cuándo la nube sigue ganando
Mantén una regla escrita, no un sentimiento:
Prefiere nube / inferencia gestionada cuando:
- Necesitas calidad de vanguardia que el modelo abierto local no alcanza en tu conjunto de eval.
- La carga es irregular y domina el CapEx ocioso.
- Te falta capacidad de ops para DGX OS, contenedores y guardias.
- Necesitas HA multirregión o SLAs del proveedor.
- El modelo o modalidad que necesitas aún no está disponible (o no es estable) en la ruta de serving de Spark.
Prefiere Spark (o Spark + segundo nodo) cuando:
- Los datos deben quedarse en las instalaciones o en una LAN controlada para ese flujo.
- La latencia a un bucle de agente en escritorio/LAN importa más que la calidad absoluta de vanguardia.
- El volumen estable de inferencia amortiza el CapEx.
- Tienes personal para asumir el parcheo, las evals y la respuesta a incidentes.
Encuadre de costes sin falsa precisión
No inventes un mes de punto de equilibrio a partir de un blog. Construye un modelo corto con supuestos etiquetados:
| Entrada | Fuente |
|---|---|
| Hardware + impuestos + envío | Presupuesto fechado de un distribuidor o de NVIDIA |
| Potencia (continua vs ciclo de trabajo) | Consumo medido o notas PSU/TDP × kWh local — etiquétalo como estimación |
| Horas de ingeniería / mes | Tu realidad de nómina |
| Alternativa en la nube | Precio actual de token o GPU-hora para el mismo nivel de calidad |
Si la alternativa en la nube es más barata y aceptable para la clase de datos, Spark es opcional. Si la clase de datos prohíbe la ruta en la nube, el CapEx es un coste de cumplimiento, no una optimización de tok/s.
El híbrido sigue siendo el patrón maduro: clasifica la petición, enruta trabajo restringido en local, envía trabajo público o de razonamiento duro a modelos alojados aprobados tras eliminar la información sensible. Ese es el mismo marco que patrones de despliegue de IA privada.
Lista de comprobación para quien implementa (un solo nodo)
- Confirma DGX OS, driver y
nvidia-smien una línea base de actualización reciente. - Elige un stack de serving y un modelo para la primera ruta candidata a producción.
- Mide: tiempo de carga, tok/s a concurrencia fija, contexto máximo antes de OOM, calidad en un conjunto de eval fijo (fecha la ejecución).
- Expón HTTP compatible con OpenAI solo en una interfaz privada con autenticación.
- Añade health checks y una alternativa documentada en la nube.
- Solo entonces conecta agentes, canales o n8n.
No hagas esto aún
- No prometas a clientes «200B en local» sin nombrar precisión, contexto y latencia medida.
- No ejecutes el primer agente con shell sin restricciones en el mismo host que guarda secretos de producción.
- No te saltes la documentación multinodo y esperes que la magia del QSFP arregle el OOM de un solo nodo.
- No trates una captura de tok/s de la comunidad como planificación de capacidad.
La inferencia local en Spark es real cuando el presupuesto de memoria, el stack de serving y la disciplina de ops son reales. El hardware elimina una clase de techos de VRAM; no elimina la ingeniería.
