El experimento no procede de un laboratorio ni de una ficha oficial del fabricante, así que conviene leerlo como una medición práctica y no como una cifra de referencia universal. Aun así, los datos ayudan a entender qué ocurre en una infraestructura local cuando se le exige trabajar con contexto muy largo y varios usuarios simultáneos. En este caso, el autor dice haber montado el equipo para servir inferencia multiusuario en su negocio, con una CPU EPYC 7402P, 128 GB de RAM y cuatro GPUs Radeon AI PRO R9700 limitadas a 210 W.
Qué midió exactamente
La prueba se hizo con Radiance v1.17.0 sobre Ubuntu 26.04.1, kernel 7.0 y ROCm 10.1, usando un modelo cuantizado de Qwen 3.8 Flash Next y una configuración para hasta ocho secuencias simultáneas. El autor fijó una ventana máxima de 200.000 tokens, activó la caché de prefijos en host y limitó el número de tokens especulativos a tres. También usó texto técnico real como contexto y lanzó cada ronda al mismo tiempo para simular el peor caso de carga.
Ese detalle importa porque el resultado no mide solo cuánto tarda en escribir el modelo, sino también cómo se comporta cuando tiene que leer bloques grandes de contexto antes de emitir la primera palabra. La tabla distingue entre el tiempo hasta el primer token y la velocidad de escritura posterior, y separa además el primer turno frío del segundo, donde ya existe caché de conversación.
Los arranques fríos siguen siendo el cuello de botella
La cifra más llamativa está en el prefilling, es decir, en la fase de lectura inicial del contexto. El autor resume que esa fase se mantiene en torno a 6.800 tokens por segundo en total, prácticamente con independencia del número de usuarios. Con ocho usuarios y contextos de 128K, la lectura de 1,02 millones de tokens tardó 151 segundos. En el peor escenario, ocho usuarios lanzando a la vez un prompt nuevo de 128K acabaron esperando alrededor de 2,5 minutos para el primer token.
La tabla encaja con esa lectura: en 128K, el primer token del turno 1 pasa de 18,8 segundos con un usuario a 150,8 segundos con ocho usuarios. El salto no parece venir de la generación en sí, sino de la cola compartida de lectura del contexto. En otras palabras, el sistema no se cae, pero sí convierte la entrada inicial en la parte más cara de la experiencia.
Donde el sistema mejora: seguimientos y caché
La parte más favorable del ensayo aparece en el segundo turno, cuando la conversación ya tiene contexto previo y el sistema puede reutilizar caché. El autor afirma que entre el 94% y el 99% del trabajo procede de la caché en esos seguimientos, con tiempos hasta el primer token de entre 0,2 y 2,5 segundos incluso con ocho usuarios y 128K de contexto. Después, la escritura por usuario se mueve entre 80 y 225 tokens por segundo, según el tamaño del contexto y la carga concurrente.
Hay un dato especialmente útil para entender el alcance práctico: con un solo usuario, la velocidad de escritura en 128K fue de 189 tokens por segundo, frente a 195 tokens por segundo en 32K. Eso sugiere que, al menos en esta configuración, el tamaño del contexto afecta mucho menos a la fase de generación que a la fase de lectura inicial. Para un flujo de trabajo de agentes o asistentes que encadenan preguntas y respuestas, esa diferencia pesa más que el número bruto de tokens por segundo.
Qué enseña sobre un servidor local para agentes
La conclusión operativa es clara: este tipo de montaje parece más adecuado para cargas con conversación persistente que para oleadas de prompts fríos de gran tamaño. Cuando el contexto ya está cacheado, el sistema responde con rapidez suficiente para varios usuarios; cuando todos llegan a la vez con una ventana larga, el tiempo hasta el primer token se dispara. El propio autor señala que hay que dimensionar la caché del host pensando en usuarios y longitud de contexto, porque una configuración demasiado ajustada puede recortar de forma importante el porcentaje de caché efectiva y multiplicar la latencia.
También hay una lectura de infraestructura: la prueba indica que las cuatro tarjetas trabajaron al límite de 210 W durante el prefilling y que dos de ellas alcanzaron 91 °C de hotspot y 92 °C de memoria en la secuencia más exigente. No es un fallo, pero sí una pista de que la estabilidad térmica y el reparto de carga seguirán siendo factores relevantes si este tipo de servidores se usa durante horas o en entornos menos controlados.
Lo que falta por verificar
El test es interesante porque mezcla contexto extremo, concurrencia real y hardware que no suele aparecer en comparativas estándar. Pero todavía faltan dos cosas para convertirlo en una referencia más sólida: una réplica independiente con la misma pila de software y una comparación directa con otras configuraciones de GPUs o con modelos equivalentes en distintos motores de inferencia. Hasta entonces, lo más prudente es tomar estos números como una señal útil para planificar servidores locales de agentes, no como una garantía general sobre lo que dará cualquier montaje parecido.
