Cuántos desarrolladores caben en una sola GPU: análisis de rendimiento y coste

Montar un servidor propio de inferencia para agentes de codificación exige entender qué se compra realmente cuando se alquila o adquiere una GPU. A diferencia de las APIs por token de OpenAI o Anthropic, un nodo propio fija un techo de tokens por segundo que solo se alcanza bajo carga; un solo desarrollador deja la mayor parte del techo sin usar, pero 48 sesiones concurrentes cambian el escenario. La clave es la utilización, no el número de usuarios: la demanda real es irregular, con valles nocturnos y picos vespertinos, y la utilización media publicada en cargas internas de inferencia se sitúa entre el 15% y el 22%, raramente por encima del 25-35%. Para dimensionar el equipo, los autores recurren a una submuestra de SWEBench Pro de ScaleLabs como carga de trabajo realista y miden tareas completadas, no solo tokens por segundo. En su prueba con GLM-5.2 servido en SGLang sobre un nodo 8×B200 (1,5 TB de HBM total), el sistema atendió 24 sesiones concurrentes con un rendimiento agregado de 170 tokens/s a 16 usuarios, completando el 62,5% de las tareas. La actualización con Kimi K3, ejecutado en un nodo 8×B300 (2,3 TB de HBM, unos un 20% más caro en hardware), baja a 16 sesiones concurrentes, 122 tokens/s y 38 minutos de mediana por tarea, aunque eleva la tasa de resolución al 86,4% (24 puntos por encima de GLM-5.2 y Opus 4.8), con el caveat de que las tareas podrían haber formado parte del entrenamiento de K3. Frente a Claude Code, K3 resulta unas 8 veces más lento. El artículo describe también cómo las sesiones automatizadas de agentes pueden absorber capacidad nocturna o cómo la concentración horaria de un equipo en una sola zona dispara los picos de uso, y promete completar el análisis de cuántos desarrolladores pueden compartir el pool antes de que se sienta lento.