Cómo dimensionar la inferencia privada: memoria, carga y latencia

Defina qué hace la aplicación, cuándo llegan las solicitudes y cuánto puede esperar el usuario. Un resumen nocturno admite una cola que un asistente interactivo no tolera. Registre solicitudes por intervalo, longitud de entrada, salida esperada, plazo de finalización y proporción de errores aceptable. Separe el tráfico habitual de los picos conocidos, como el inicio de un turno o el cierre de un lote.

Use muestras de documentos reales autorizados o equivalentes sintéticos. La longitud en caracteres no determina por sí sola el número de tokens: depende del tokenizador y del contenido. Incluya instrucciones, documentos recuperados e historial que realmente recibirá el modelo. La selección de modelos y el dimensionamiento deben avanzar juntos; cambiar de modelo puede cambiar tanto calidad como consumo.

Una primera aproximación es memoria de pesos = parámetros × bytes por parámetro. Un modelo denso hipotético de 8.000 millones de parámetros a dos bytes por parámetro requiere unos 16 GB decimales, aproximadamente 14,9 GiB, solo para los pesos. Esto no es una recomendación de GPU ni una estimación de memoria total. Faltan cachés, activaciones, buffers, estado del motor y posibles sobrecostes del formato.

A cuatro bits por parámetro, el cálculo idealizado sería 4 GB decimales para esos pesos. Los metadatos de cuantización y la implementación impiden asumir que ese número será la ocupación final. Tampoco implica velocidad cuatro veces mayor ni calidad equivalente. Compruebe compatibilidad y mida el candidato concreto. En modelos con expertos, parámetros activos por token y memoria de los pesos residentes son conceptos diferentes.

La KV cache conserva estados de atención para reutilizarlos durante la generación. Su tamaño no se deriva solo del número total de parámetros: intervienen capas, cabezas KV, dimensiones y tokens residentes. Revise la configuración de caché de vLLM para el motor y versión elegidos, sin convertir un valor de configuración en una garantía de rendimiento.

Cien usuarios registrados no equivalen a cien generaciones simultáneas. Observe la tasa de llegada y cuánto tiempo permanece cada solicitud en el sistema. Como comprobación aproximada en condiciones estables, la concurrencia media es tasa de llegada × tiempo medio en el sistema. Si llegan dos solicitudes por segundo y cada una permanece seis segundos, la media sería doce solicitudes. Es un ejemplo aritmético, no una prueba de capacidad ni una estimación de pico.

Una cola creciente rompe la utilidad de planificar solo con ese promedio. Pruebe ráfagas y observe si el sistema vuelve a su estado habitual dentro del plazo aceptado. Limite el tamaño de entrada, la salida y las solicitudes pendientes. Si admite contextos excepcionalmente largos, pruebe su efecto sobre los demás usuarios y decida si necesitan una cola o cuota separada.

Para una interfaz que transmite tokens, el tiempo hasta el primer token describe la espera inicial; la velocidad posterior determina cuánto tarda en completarse la respuesta. Para un proceso que requiere JSON válido, recibir el primer token puede aportar poco: importa completar y validar el objeto. Mida también autenticación, recuperación de documentos, red y validación, no solo el motor.

Informe mediana y percentiles altos con el tamaño de muestra y la carga de cada ejecución. Un promedio puede ocultar esperas inaceptables. Distinga solicitudes fallidas de solicitudes lentas, y respuestas generadas de tareas aceptadas. Las recomendaciones de optimización de vLLM muestran que las decisiones de memoria y rendimiento dependen de la configuración; repita la prueba después de modificarla.

Fije versión del modelo, motor, precisión, hardware y límites. Prepare tres perfiles: habitual, pico y contexto largo. Caliente el servicio, ejecute una duración suficiente para observar colas y registre solicitudes ofrecidas, completadas, rechazadas y aceptadas por calidad. Aumente la carga por etapas; conserve los resultados de cada etapa aunque no cumpla el objetivo.

Después pruebe recuperación: reinicio de un proceso, indisponibilidad de una dependencia y reducción de capacidad cuando la arquitectura lo permita. No anuncie redundancia si no ha medido el servicio con un componente fuera. Reserve margen para variación y mantenimiento a partir de esas pruebas. La capacidad nominal de un conjunto de aceleradores no describe por sí sola la capacidad disponible durante una incidencia.

El resultado debe indicar qué configuración pasa, para qué distribución de solicitudes y con qué criterios. Incluya el máximo probado, el punto donde comienza a crecer la cola y el comportamiento al superar límites. Si no hay configuración aceptable, reduzca contexto o alcance, cambie el modelo o revise el plazo de negocio; no oculte el problema aumentando únicamente el timeout.

Traslade la configuración al piloto de evaluación, su coste a la estimación económica y sus umbrales al plan de operación. El servicio de inferencia privada comienza delimitando estas condiciones antes de comprometer una plataforma. Una medida útil deja claro tanto lo que demuestra como lo que aún no se ha probado.