Qué ha probado exactamente
El montaje utiliza un EPYC 7402P, una placa Asrock ROMED8-2T, 128 GB de DDR4, una fuente Seasonic Prime TX-1600W y cuatro GPUs Radeon AI PRO R9700, tres de Gigabyte y una de XFX, todas limitadas a 210 W. El autor dice que compró el equipo en las dos semanas previas por unos 16.000 dólares canadienses y que lo montó como servidor de inferencia multiusuario para su negocio. Antes de empezar las pruebas, pasó memtests y estrés de CPU y GPU para descartar fallos de hardware.
El software también está bastante acotado: Ubuntu 26.04.1, kernel 7.0, controlador amdgpu incluido en el sistema, ROCm 10.1 en espacio de usuario y Radiance v1.17.0. El modelo usado es `qwen3.8-next-flash-fp8-iq4r-moe.rad`, una variante con trunk en int8, expertos con codebook de 4 bits y *drafting* especulativo de tres tokens. La configuración fija `--tp 4`, un máximo de 8 secuencias concurrentes y un contexto máximo de 200.000 tokens.
Lo que dicen las cifras
La parte más llamativa de las tablas es que el sistema parece estabilizar el *prefill* en torno a 6.800 tokens por segundo en total, con independencia del número de usuarios. En la práctica, eso significa que cuando llegan varios *prompts* largos a la vez, todos comparten la misma cola de lectura y el primer token puede tardar bastante en aparecer. Con ocho usuarios y contextos de 128K, el primer token llega de media a los 150,8 segundos y el peor caso se va a 151,5 segundos. El autor resume ese escenario como una espera de unos 2,5 minutos para recibir la primera respuesta.
Eso cambia bastante en los seguimientos. Según la prueba, entre el 94% y el 99% del trabajo de la segunda vuelta sale de caché, de modo que el primer token aparece entre 0,2 y 2,5 segundos incluso con ocho usuarios y 128K de contexto por cabeza. La velocidad de escritura por usuario se mueve en la práctica entre 80 y 225 tokens por segundo en esos seguimientos. El propio autor subraya que la longitud del contexto apenas penaliza la escritura una vez que el historial ya está cacheado: un usuario escribe a 189 tok/s con 128K frente a 195 tok/s con 32K.
En los arranques fríos, la historia es distinta. Con cuatro usuarios, algunos terminan de recibir contexto antes que otros y pueden empezar a escribir mientras el resto sigue en *prefill*, lo que deja al más lento en una franja de 9 a 32 tok/s. Con ocho usuarios, todos terminan de leer casi a la vez y la escritura conjunta se mueve entre 70 y 83 tok/s. Es decir: la experiencia cambia mucho según si el sistema está sirviendo nuevos chats largos o continuaciones sobre conversaciones ya abiertas.
Qué implica el tamaño de la caché
El autor insiste en una lección práctica: hay que dimensionar la caché de prefijos del host para el número de usuarios y la longitud del contexto. En una prueba anterior con `--prefix-cache-mib 12288`, la caché para ocho seguimientos de 64K solo alcanzó el 71%, con un peor primer token de 37,6 segundos y apenas 9 tok/s por usuario. Al subir a 32768 MiB, la caché subió al 98%, el primer token bajó a 1,5 segundos y la escritura a 94 tok/s por usuario.
Ese dato importa porque, en un servidor pensado para varios usuarios, no basta con sumar VRAM bruta. El autor señala que con `--host-pool-mib 12288` había memoria del sistema comprometida sin aportar beneficio real en una configuración de cuatro tarjetas: parte de ese espacio quedaba infrautilizado y dejaba solo 3,6 GB libres. En su lectura, 1024 MiB bastan en ese escenario concreto. Es una observación muy específica, pero útil para quien esté montando una estación de inferencia similar y no quiera reservar RAM por inercia.
Consumo, ruido y temperatura
La prueba también deja un par de datos físicos relevantes. El autor afirma que todas las tarjetas se mantuvieron en el límite de 210 W durante el *prefill* y que, en el tramo más exigente, las dos GPUs centrales llegaron a 91 °C de *hotspot* y 92 °C de memoria. Aun así, dice que el equipo resultó más silencioso de lo esperado, hasta el punto de sonar menos que su purificador de aire al máximo. Esto no es una validación independiente, pero sí da una idea de cómo se comporta este tipo de montaje fuera de una mesa de pruebas con cifras aisladas.
La fotografía que deja el experimento es clara: cuando el trabajo consiste en seguir conversaciones largas ya abiertas, esta clase de servidor puede dar respuestas rápidas y bastante estables; cuando varios usuarios entran a la vez con *prompts* largos y fríos, la primera respuesta se retrasa mucho más. Lo que todavía falta por ver es cómo se comporta este mismo equipo con otros modelos, otros *harness* de inferencia y cargas más cercanas a producción real, algo que el autor dice que sigue probando.
