Capacidad real
Cuántos usuarios simultáneos aguanta cada equipo, con datos
Las fichas de nuestros equipos dicen cuántos usuarios simultáneos aguanta cada uno: de 10 a 25 el Starter, de 25 a 60 el Pro, y estimaciones marcadas como tales para Business y Enterprise. Este artículo enseña de dónde salen esas cifras. No hace falta creernos: la cuenta es pública, los benchmarks son de terceros y las fuentes están enlazadas al final. También cuenta la condición que casi ningún vendedor menciona: el número de usuarios depende menos del tamaño de la memoria que del ancho de banda y del tipo de modelo que elijas.
El límite no es la memoria: es el ancho de banda
Generar texto obliga al equipo a leer los pesos del modelo por cada token que escribe. La velocidad de generación es, en primera aproximación, el ancho de banda de la memoria dividido por los bytes que hay que leer por token. La memoria total decide qué modelos caben; el ancho de banda decide a qué velocidad responden. Son dos límites distintos, y el segundo es el que decide cuántos usuarios puedes atender a la vez.
Los números concretos: un DGX Spark mueve 273 GB/s con memoria LPDDR5x unificada. Una DGX Station GB300 usa HBM3e a 7,1 TB/s, unas 26 veces más. Esa diferencia de clase de silicio, no el total de gigabytes, es la razón de que las fichas de Business y Enterprise hablen de cientos o miles de usuarios y las de Starter y Pro de decenas.
Para calibrar qué significa conversar bien: una persona lee unas 4 o 5 palabras por segundo. Entre 8 y 10 tokens por segundo por usuario, la respuesta va por delante de tu lectura y la conversación se siente fluida. Con 5 se puede trabajar. Por debajo de 3, se sufre.
Lo que miden los benchmarks públicos en un DGX Spark
Un modelo denso de 70.000 millones de parámetros en FP8 genera 2,7 tokens por segundo en un DGX Spark, medido por LMSYS. La aritmética anterior lo predice: 273 GB/s divididos entre 70 GB de pesos dan unos 4 teóricos como máximo. Es decir, un solo usuario, a velocidad dolorosa. Guarda este dato para la última sección.
Ahora un modelo de mezcla de expertos (MoE) medido en octubre de 2025: tenía 117.000 millones de parámetros pero solo activaba unos 5.000 millones por token, así que leía una fracción de los pesos en cada paso. El resultado en el mismo equipo fue de 33 a 38 tokens por segundo con un solo usuario, según el motor de inferencia. Con 8 usuarios generando a la vez, unos 15 tokens por segundo cada uno. Con 64, unos 6. El equipo no se cae: reparte.
La otra mitad de la historia es la ingesta de contexto, donde el Spark es fuerte: unos 1.800 tokens por segundo de lectura de prompt en esa misma prueba. Un caso RAG que adjunta varias páginas de documentación interna arranca la respuesta en un par de segundos. Lo escaso no es leer tu pregunta: es la generación sostenida cuando hay cola.
De flujos de generación a usuarios reales
Usuarios simultáneos no significa todos generando en el mismo instante. En un uso normal de chat, cada persona pasa la mayor parte del tiempo leyendo la respuesta, pensando o escribiendo; el sistema solo genera para ella una fracción del tiempo, típicamente entre el 10 y el 25 por ciento. Diez usuarios conectados suelen ser dos o tres generando a la vez.
Con eso, la ficha del Starter sale de una cuenta corta. Dos DGX Spark funcionando como dos réplicas del mismo modelo MoE atienden con comodidad unos 16 flujos de generación a más de 10 tokens por segundo cada uno. Incluso en el peor caso, los 25 usuarios de la ficha generando todos a la vez, quedan unos 12 por unidad, que las mediciones de concurrencia sitúan por encima de 10 tokens por segundo por cabeza. La ficha de 10 a 25 no es optimismo: es el margen entre el caso normal y el peor caso.
El Pro es la misma cuenta por cuatro: sus 60 usuarios de ficha son 15 flujos por unidad, de nuevo en la zona de 11 o 12 tokens por segundo con un MoE. Por eso Starter y Pro no llevan la marca de estimado: la cifra se apoya en mediciones públicas del hardware exacto.
Business y Enterprise: otra clase de silicio
La GPU de una DGX Station GB300 lleva 252 GB de HBM3e a 7,1 TB/s. Ahí la medición pública más exigente que conocemos es del equipo de vLLM: un MoE grande generó 2.816 tokens por segundo por GPU en un escenario mixto de lectura y generación. A 10 tokens por segundo por usuario, eso son cientos de flujos simultáneos en una sola GPU, con la caché de contexto incluida. La ficha de 200 a 500 usuarios es, si acaso, prudente.
El Enterprise multiplica esa GPU por ocho con 2,3 TB de HBM3e agregada, así que la misma medición escala a más de 20.000 tokens por segundo de capacidad conjunta: el orden de los más de 2.000 usuarios de su ficha. Y hay una diferencia cualitativa que las cifras de usuarios no enseñan: a partir de Business, los modelos densos grandes también conversan con soltura, no solo los MoE.
Aun así, esas dos fichas llevan la marca de estimado, y la mantienen: el hardware es tan reciente que no existe todavía un benchmark público del equipo exacto en configuración de servicio. La cifra sale de aplicar mediciones de la misma GPU en otros chasis, y la validamos con pruebas sobre tu caso antes de comprometerla en un contrato. Preferimos una estimación marcada como tal a una promesa redonda.
La trampa del modelo denso grande
Vuelve al dato de la segunda sección: un 70B denso en un equipo compacto genera entre 2,7 y 5 tokens por segundo para un solo usuario, antes de que se conecte nadie más. Juntar dos cajas pequeñas no lo arregla: el cuello sigue siendo el ancho de banda por unidad. Si alguien te promete chat fluido para todo tu equipo con un modelo denso grande en una caja compacta, pide la medición con usuarios concurrentes. Ese número existe o no existe.
La configuración honesta en Starter y Pro es un MoE moderno o un denso de hasta unos 32.000 millones de parámetros, ajustado a tu tarea. No es una limitación decorativa: es la diferencia entre 15 tokens por segundo por usuario y una espera exasperante. Qué modelo concreto encaja con tu caso y tu equipo es exactamente lo que repasamos en la guía de qué GPU necesita tu empresa, y la evaluación lo mide sobre tus tareas antes de proponer nada.
Y la simetría de siempre: si tu caso pide un modelo de frontera cerrado que ningún abierto iguala todavía, la respuesta honesta es que sigas en la API para ese flujo. El equipo se compra para las tareas donde un modelo tuyo, más pequeño y ajustado, hace el trabajo a velocidad de conversación.
De dónde salen los números
Ninguna de las cifras de este artículo es nuestra. Las mediciones de DGX Spark salen de la review de LMSYS, del barrido de concurrencia de Dendro Logic y de las pruebas de llama.cpp; la de la GPU GB300, del blog de vLLM. Todas son públicas y repetibles: puedes rehacer la cuenta sin fiarte de un vendedor, incluidos nosotros.