Nvidia sirve GLM-5.3 en 2 DGX Station a 607,8 tok/s

Un modelo de 753.000 millones de parámetros servido desde dos máquinas

NVIDIA publicó un tutorial técnico que muestra cómo servir GLM-5.3 —la versión cuantizada en NVFP4 del modelo de mezcla de expertos (MoE) de Z.ai— sobre dos DGX Station con vLLM, alcanzando 607,8 tokens por segundo con concurrencia 16. El dato importa porque rompe una suposición bastante extendida entre equipos de producto: que un modelo de escala frontera solo puede servirse desde un datacenter ajeno. Aquí el checkpoint pesa unos 464 GB y cada GPU GB300 dispone de 252 GB de HBM3e, así que el modelo no entra en una sola máquina. La solución no fue comprimir más: fue repartir.

Por qué un MoE de 753B no cabe en una sola GPU

GLM-5.3 tiene 753.000 millones de parámetros, de los cuales se activan unos 40.000 millones por token. Esa activación dispersa reduce el cómputo por token, pero no el espacio en memoria: cada token puede enrutarse a expertos distintos, así que todos los pesos deben permanecer disponibles. De ahí el número que ordena toda la arquitectura: 464 GB de checkpoint frente a 252 GB de HBM3e en una GB300. Por eso el tutorial desactiva explícitamente el offload de pesos a CPU: si parte del modelo vive en RAM del sistema, la latencia por token se vuelve impredecible.

El contexto del modelo también explica el interés. Según SiliconANGLE, GLM-5.3 se presentó en agosto de 2026 como un modelo abierto basado en GLM-5.2 (publicado a mediados de julio) con arquitectura MoE de 753.000 millones de parámetros y una ventana de contexto de 1 millón de tokens. El mismo medio reporta que logró el mejor puntaje de un modelo abierto en Terminal Bench 3.0 y rindió un 50% mejor que GLM-5.2 en un benchmark interno de agentes de código. CryptoBriefing añade que los pesos se publicaron el 28 de agosto de 2026, lo que convierte el modelo en algo que un equipo puede descargar y servir por su cuenta.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Cómo se reparte el trabajo: tensor parallelism con TP=2

La técnica es tensor parallelism con TP=2: los tensores del modelo se dividen entre las dos GB300. Ambas estaciones computan cada petición y la estación A devuelve la respuesta a través de una única API compatible con OpenAI. La conexión entre nodos va por ConnectX-8 RDMA sobre dos rails directos, con enlaces de 400.000 Mb/s y MTU 9000. El resultado en memoria es elocuente: cada GPU termina con cerca de 218 GiB de pesos, aproximadamente la mitad del checkpoint, y el resto de la memoria queda libre para el KV cache.

La configuración por defecto del tutorial fija --max-model-len 98304 (el techo de contexto en tokens, que cubre entrada más salida) y --gpu-memory-utilization 0.93. Además activa MTP (multi-token prediction), una forma de decodificación especulativa en la que una capa del modelo propone cuatro tokens por paso y vLLM los verifica con el modelo completo antes de aceptarlos. Suma KV cache en FP8, que reduce a la mitad la memoria del cache frente a almacenamiento de 16 bits, y prefix caching para no reprocesar prefijos ya vistos.

Los números: dónde está el punto dulce de concurrencia

El tutorial mide con AIPerf 0.12.0 sobre 80 conversaciones de coding de SPEED-Bench (89 turnos), con prefix caching activo y cuatro tokens de borrador MTP por paso. Los resultados son la parte más útil del artículo para cualquiera que esté dimensionando infraestructura:

Concurrencia 1: 107,4 tok/s de throughput global, latencia media de 49,84 s, TTFT de 479,75 ms y 8,78 ms por token.
Concurrencia 8: 386,0 tok/s, latencia media de 114,17 s, TTFT de 433,79 ms y 19,01 ms por token.
Concurrencia 16: 607,8 tok/s, latencia media de 136,46 s, TTFT de 482,90 ms y 23,77 ms por token.
Concurrencia 32: 385,0 tok/s, latencia media de 453,54 s, TTFT de 899,36 ms y 77,90 ms por token.

El throughput no crece de forma lineal: sube hasta C16 y cae a C32. El costo lo paga el usuario. El tiempo hasta el primer token se mantiene razonable hasta C16 y se duplica en C32, mientras el tiempo entre tokens pasa de 8,78 a 77,90 ms. Traducido: a concurrencia 32 el sistema no se rompe, pero la generación se percibe casi nueve veces más lenta. El propio tutorial lo cuantifica en throughput por usuario: de 115,3 tok/s a C1 a 13,0 tok/s a C32. La lección de capacidad es directa: la concurrencia máxima soportada no es la concurrencia óptima.

Qué significa esto para tu startup

El valor real de este tutorial no está en el récord de tokens por segundo, sino en que valida un patrón de despliegue: un modelo de 753B con una sola API, sin coste por token y con los pesos en tu propia infraestructura. NVIDIA lo plantea explícitamente como la base para inferir sobre datos sensibles o propietarios, prototipar agentes en local e iterar prompts sin factura por token.

Para un equipo pequeño eso abre tres decisiones concretas:

Soberanía de datos como argumento comercial. Si vendes a clientes regulados o con datos clínicos, financieros o industriales, poder decir que la inferencia no sale de tu infraestructura cambia conversaciones de venta. Es el caso de uso que el propio tutorial pone primero.
Coste predecible en la fase de iteración. El gasto por token castiga el ensayo y error: cada prueba de prompt tiene precio. Con el modelo en local, el costo marginal de probar cien variantes es tiempo de GPU, no factura. Para un equipo que está afinando un agente, esa diferencia cambia la velocidad de aprendizaje del producto.
Un techo de contexto que conviene bajar. Los 98.304 tokens configurados son el máximo, no el óptimo. Si tus prompts reales son cortos, reducir ese valor libera KV cache y te permite sostener más usuarios simultáneos con el mismo hardware.

Errores que cuestan horas (y cómo evitarlos)

El tutorial documenta varios fallos que aparecen recién cuando el sistema está en producción, y vale la pena tenerlos mapeados antes de comprar hardware:

NCCL viejo. El script fuerza NCCL 2.30.7 desde la imagen porque versiones anteriores pueden bloquearse al reproducir CUDA graphs entre nodos sobre RoCE (referencia al issue #52504 de vLLM). Es un fallo silencioso: el servicio arranca y se cuelga bajo carga.
Fallback a TCP sin avisar. Si el RDMA no está bien cableado, NCCL cae a sockets TCP y el rendimiento se derrumba sin error visible. El tutorial incluye una verificación que lee los logs de NCCL y exige GDRDMA y ausencia de NET/Socket y NCCL WARN.
Relojes y MTU. Antes de arrancar conviene comprobar NTPSynchronized, MTU 9000 y pings con jumbo frames. Son chequeos de dos minutos que evitan timeouts de NCCL difíciles de diagnosticar después.
Checkpoints distintos en cada nodo. El tensor parallelism exige los mismos pesos en ambos ranks. El tutorial compara el hash del listado de archivos entre estaciones y valida el config.json antes de servir.

Cuándo conviene local y cuándo no

Hay que decirlo sin adornos: dos DGX Station con GB300 son hardware de gama alta, y el cálculo económico solo cierra con volumen alto o con requisitos de confidencialidad que un endpoint alojado no puede cumplir. Si haces unas pocas peticiones al día, un proveedor de inferencia sigue siendo la decisión correcta. El punto de quiebre aparece cuando el gasto por token se vuelve una línea grande del presupuesto, cuando el dato no puede salir de tu perímetro, o cuando necesitas un modelo abierto concreto que el proveedor no ofrece.

Un detalle de seguridad que el propio tutorial subraya y que muchos equipos pasan por alto: --host 0.0.0.0 con --network host deja la API sin autenticación en todas las interfaces de la estación A, incluidas las de gestión. Antes de dar acceso a cualquier cliente hay que cerrar el puerto con firewall y añadir autenticación y TLS. Un endpoint de inferencia abierto es una fuga de datos esperando ocurrir.

Conclusión

Servir un modelo de 753.000 millones de parámetros en dos estaciones de escritorio, con una API compatible con OpenAI y 607,8 tokens por segundo en su punto dulce, deja de ser un experimento de laboratorio y pasa a ser una receta reproducible. Lo más valioso del material de NVIDIA no es el récord: es la tabla de concurrencia, que muestra con números que el throughput se derrumba después de C16 y que el usuario paga ese exceso en latencia. Para un founder, la decisión no es «local o nube» en abstracto, sino a qué concurrencia real corre tu producto y cuánto vale que los datos no salgan de tu infraestructura.