Dimensionamiento de una configuración GPU on-premises frente a la carga de trabajo real

Una configuración de hardware que un comité de compras pueda defender no es una cifra provista por un fabricante. Es la intersección de tres mediciones realizadas sobre el perfil de carga de trabajo de la propia organización: latencia, rendimiento y memoria. Cada parámetro limita a los otros dos, y la configuración defendible es la más compacta que satisface los tres bajo el nivel de servicio acordado. Cualquier dimensionamiento que reporte uno solo de estos tres factores de forma aislada constituye un simple pronóstico. Refleja el desempeño del hardware en una prueba sintética genérica, no la demanda real del despliegue bajo la carga de trabajo para la cual fue adquirido.

Por qué la configuración se mide, no se estima

La arquitectura de referencia que publica un fabricante de hardware se calibra frente a pruebas de rendimiento públicas. Estas pruebas están diseñadas para comparar equipos entre distintos fabricantes, no para revelar los puntos de falla de una carga de trabajo específica. Una configuración derivada de una ficha técnica halaga inevitablemente a dicha ficha. La infraestructura que una organización realmente necesita solo se revela al reproducir el tráfico real - sus patrones de concurrencia, la distribución de longitud de contexto y la combinación de consultas - frente a una configuración objetivo. Dimensionar sin dicha reproducción transforma el riesgo operativo en optimismo de compra. Ese optimismo sale a relucir más adelante ante el comité de auditoría en forma de sobrecostos presupuestarios o interrupciones del servicio.

La metodología descrita a continuación dimensiona la infraestructura reproduciendo la carga de trabajo real frente a configuraciones candidatas en un laboratorio de GPU propio y midiendo los tres presupuestos. El proceso define dos límites claros: el piso (la configuración mínima indispensable que cumple el nivel de servicio objetivo) y el techo (el umbral a partir del cual el hardware adicional no genera mejoras medibles en el servicio). Las decisiones de compra se toman justamente entre estos dos valores.

Captura del perfil de carga de trabajo

Una configuración de hardware es tan precisa como la carga de trabajo utilizada para dimensionarla. El primer paso captura la carga de producción real en lugar de emplear un sustituto sintético:

• la combinación de solicitudes, incluyendo la cola larga de consultas reguladas y de baja frecuencia que los puntos de referencia uniformes omiten;
• la distribución de longitud de contexto generada por usuarios reales, incluyendo las solicitudes pico que exigen memoria al máximo en lugar de promedios que la subestiman;
• los patrones de concurrencia impulsados por las operaciones del negocio (como los cierres de trimestre, las conciliaciones diarias o los plazos de entrega regulatorios) en lugar de promedios en estado estable;
• la sensibilidad a la latencia de cada categoría de solicitud, estableciendo objetivos específicos de nivel de servicio en lugar de un único umbral genérico.

El entorno de pruebas reconstruye este comportamiento como un perfil de carga estandarizado que se aplica a través de las configuraciones candidatas. Dado que el perfil de carga se mantiene constante, cualquier variación en los presupuestos medidos proviene directamente de la configuración de hardware.

El presupuesto de latencia

La latencia se mide como una distribución y no como un promedio. El dimensionamiento se rige por la latencia de cola - habitualmente los percentiles 95 y 99 por categoría de solicitud - debido a que la degradación del servicio y las observaciones de auditoría se manifiestan primero en la cola. Un promedio encubre los cuellos de botella al combinar solicitudes de rutina rápidas con casos límite demorados. La latencia de cola saca a la luz dichos casos límite antes del despliegue.

La latencia es la restricción principal porque delimita el tiempo que una solicitud puede esperar antes de que sus etapas de prefill y decode ingresen en cola. Una arquitectura que cumple los objetivos de rendimiento agrupando solicitudes en lotes de gran tamaño mostrará un alto rendimiento agregado junto con una latencia de cola inaceptable. Esa configuración resulta convincente en una demostración comercial, pero falla en producción. Medir el presupuesto de latencia frente a distribuciones de solicitudes reales descarta tempranamente configuraciones inviables.

El presupuesto de rendimiento

El rendimiento es la tasa sostenida de solicitudes que una configuración mantiene dentro de la latencia objetivo, no su pico teórico antes de la saturación. El dimensionamiento se rige por el punto de saturación: el nivel de concurrencia donde la latencia comienza a aumentar más rápido que el rendimiento. El punto de operación objetivo debe situarse holgadamente por debajo de este punto de inflexión, garantizando margen para absorber picos operativos.

El rendimiento y la latencia interactúan directamente mediante el procesamiento por lotes (batching). Aumentar el tamaño del lote incrementa el rendimiento. No obstante, más allá del punto de saturación, lotes más grandes incrementan la latencia de cola de manera desproporcionada. El punto de operación defendible es el tamaño de lote que maximiza el rendimiento respetando estrictamente los objetivos de latencia durante la prueba. El rendimiento sostenido en este punto conforma el segundo presupuesto.

El presupuesto de memoria y por qué suele ser el factor limitante

En la inferencia autorregresiva de modelos basados en transformadores, la memoria se divide en tres componentes diferenciados: los pesos del modelo, los búferes de activación y la memoria caché de clave-valor (KV cache) acumulada a medida que el contexto se expande. Los pesos del modelo y los búferes de activación son fijos según la arquitectura del modelo. En cambio, la caché KV varía dinámicamente en función de tres factores: las solicitudes concurrentes en curso, la longitud del contexto de entrada y la profundidad del modelo.

Este crecimiento dinámico convierte a la memoria en el cuello de botella más habitual. Un dimensionamiento basado en las longitudes promedio de contexto provistas por los fabricantes resuelve consultas rutinarias, pero falla ante solicitudes extensas y complejas. Dimensionar con base en una concurrencia promedio colapsa durante los picos operativos. El presupuesto de caché KV - concurrencia multiplicada por la longitud del contexto bajo el nivel de servicio objetivo - traduce las metas de rendimiento en requerimientos físicos de VRAM. Medido durante la reproducción de tráfico, el presupuesto de memoria define la capacidad máxima de procesamiento por lotes antes de que las solicitudes se pongan en cola, se desborden a memoria auxiliar o sean rechazadas. Es típicamente la restricción que dicta la escala del hardware.

Determinación de la configuración a partir de las pruebas

Una vez medidos los tres presupuestos frente a un perfil fijo de carga de trabajo, la selección del hardware se guía por datos concretos y no por suposiciones. El piso representa la configuración mínima (cantidad de aceleradores, nivel de VRAM y topología del host) que cumple los objetivos de latencia y rendimiento sin exceder los límites de memoria durante los picos de concurrencia. El techo marca el umbral a partir del cual el hardware adicional no produce mejoras medibles en el nivel de servicio. Cualquier capacidad que exceda este techo carece de beneficio operativo.

Los márgenes de alta disponibilidad y dominios de falla se calculan de manera explícita por encima del piso. Añadir un acelerador o un nodo de host adicional asegura que la falla de un solo dispositivo provoque una degradación controlada y no una caída total del sistema. Considerar este margen como capacidad física dedicada, en lugar de asumir una supuesta holgura operativa, garantiza una resiliencia genuinamente diseñada a nivel de ingeniería.

Por qué la medición se ejecuta en hardware propio

Las mediciones se llevan a cabo en infraestructura GPU dedicada, configurada para reproducir con exactitud el entorno de hardware on-premises objetivo de la compra. Este enfoque evita dos fuentes comunes de distorsión. Los entornos en la nube tarificados por consumo premian un mayor gasto de recursos, inclinando sutilmente las recomendaciones hacia el techo de capacidad. Por el contrario, los entornos de prueba de los fabricantes están optimizados para pruebas sintéticas estándar, ocultando los casos límite que incrementan los requerimientos de hardware. Realizar pruebas en hardware independiente y dedicado, cargado con perfiles de carga de trabajo reales, genera líneas base de piso y techo completamente imparciales para la adquisición.

El entregable con el que se cotiza la compra

El entregable final es un expediente integral de dimensionamiento. Este documento mapea cada configuración candidata con su rendimiento medido en latencia, velocidad de procesamiento y consumo de memoria bajo el perfil de carga de trabajo, estableciendo con claridad el piso, el punto de operación y el techo. El comité de compras fundamenta sus decisiones de adquisición en datos empíricos de prueba y no en afirmaciones comerciales. La especificación final comprende la configuración base indispensable más los márgenes por dominio de falla, acotada por el techo validado. Los parámetros de la carga de trabajo - concurrencia, longitudes de contexto y combinación de consultas - quedan debidamente registrados para que el dimensionamiento pueda actualizarse cuando las necesidades del negocio evolucionen.

Este método empírico respalda directamente la fase de Desarrollo y validación. El comportamiento del prototipo en hardware físico ofrece una justificación auditable para el desembolso de capital, reduciendo la incertidumbre en los ciclos de compras subsecuentes. Dimensionar mediante cualquier otro mecanismo genera una estimación que tarde o temprano deberá confrontarse con la realidad cuando el capital ya haya sido comprometido.