Cómo estimar la memoria de GPU para inferencia de LLM autoalojados

Por qué el tamaño del modelo no determina por sí solo la memoria de GPU necesaria

El número de parámetros ofrece una primera estimación útil de la memoria de los pesos, pero no constituye un presupuesto completo. La inferencia también requiere memoria para la caché de claves y valores (KV) y las activaciones; además, el entorno de ejecución, la arquitectura y la configuración del servicio pueden modificar el uso real.

Un modelo que cabe en la memoria al cargarse aún puede superarla cuando atiende solicitudes. Las secuencias más largas y un mayor número de solicitudes activas aumentan la demanda de caché KV. Por eso, considera cualquier cálculo una estimación de planificación y valida la configuración en el entorno de destino.

• Estima los pesos y la caché KV como componentes separados.
• Define la carga de trabajo y comprueba la memoria disponible para el proceso de inferencia.

Estima la memoria de los pesos del modelo, incluida la cuantización

Para una primera estimación, multiplica el número de parámetros por los bytes utilizados por parámetro. Como equivalencias aproximadas, FP32 usa 4 bytes, FP16 2 bytes, INT8 1 byte e INT4 0,5 bytes por parámetro. La fórmula y estas equivalencias aparecen en el [estimador de memoria de inferencia de LLM](https://github.com/david-xinyuwei/llm-memory-estimator).

Por ejemplo, un modelo ilustrativo de 8.000 millones de parámetros tendría una estimación idealizada de pesos de 16 GB con 2 bytes por parámetro, 8 GB con 1 byte o 4 GB con 0,5 bytes. Son cálculos aritméticos en unidades decimales y solo corresponden a los pesos: no incluyen la caché KV, las activaciones ni las necesidades del entorno de ejecución.

La cuantización puede reducir la memoria de los pesos al utilizar menos bits por parámetro, pero esta estimación no describe por completo el modelo desplegado. Comprueba el formato real y el entorno de ejecución, y evalúa la compensación de precisión para tu modelo y tarea.

• Anota el número de parámetros y la precisión o el formato de cuantización previstos.
• Calcula los pesos como: número de parámetros × bytes por parámetro.
• Mantén la coherencia de las unidades: los GB decimales y los GiB binarios son unidades distintas, y las herramientas de GPU pueden mostrar la memoria de forma diferente.
• No interpretes el resultado como la memoria total necesaria para atender solicitudes.

Ten en cuenta la longitud del contexto y la caché KV

Durante la inferencia, la caché KV almacena datos de claves y valores de los tokens de las secuencias activas. Su consumo depende del tamaño del lote, la longitud de la secuencia, el número de capas, el número de cabezas KV, la dimensión de cada cabeza y los bytes por elemento de la caché.

Una fórmula útil es: bytes de caché KV = 2 × tamaño del lote × longitud de la secuencia × número de capas × número de cabezas KV × dimensión de cada cabeza × bytes por elemento de la caché. El factor 2 corresponde a las claves y los valores. El [estimador de memoria de inferencia](https://github.com/david-xinyuwei/llm-memory-estimator) presenta esta fórmula y contempla las cabezas KV para atención de consultas agrupadas (grouped-query attention).

En un ejemplo explícitamente hipotético, supongamos una configuración con 32 capas, 8 cabezas KV, una dimensión de cabeza de 128, un elemento de caché de 2 bytes, una secuencia de 4.096 tokens y un tamaño de lote de 1. La fórmula da 536.870.912 bytes, es decir, aproximadamente 0,5 GiB. Con un tamaño de lote de 4 y sin cambiar las demás suposiciones, la estimación es de aproximadamente 2 GiB. Estos valores solo ilustran el cálculo; no describen un modelo concreto.

Para planificar, cuenta tanto los tokens del prompt como los generados que el entorno de ejecución mantendrá simultáneamente. Un límite de contexto largo no implica que todas las solicitudes lo vayan a utilizar por completo, pero las secuencias largas pueden determinar la demanda máxima.

• Busca el número de capas, las cabezas KV y la dimensión de cada cabeza en documentación o archivos de configuración fiables.
• Utiliza el tipo de datos de la caché y el comportamiento del servicio previstos.
• Si el modelo usa atención de consultas agrupadas, utiliza su número de cabezas KV en lugar de suponer que coincide con el número de cabezas de consulta.

Considera las solicitudes simultáneas, el procesamiento por lotes y las cargas de trabajo compartidas en la GPU

La fórmula de la caché KV aumenta proporcionalmente con el tamaño del lote y la longitud de la secuencia. Por eso, varias solicitudes activas pueden requerir más caché que una sola, en especial si tienen contextos largos.

La concurrencia y el tamaño del lote están relacionados, pero no son necesariamente intercambiables: un servidor puede combinar solicitudes en lotes o gestionar las secuencias activas de otras maneras. Basa el cálculo en el comportamiento esperado del entorno de ejecución.

Ten en cuenta también otros procesos que utilicen la GPU, ya que pueden consumir memoria que de otro modo estaría disponible para la inferencia. La fragmentación y las decisiones del entorno de ejecución también pueden influir en que una configuración que parece caber sobre el papel funcione en la práctica.

• Anota el número habitual y máximo previsto de solicitudes activas.
• Comprueba si está habilitado el procesamiento por lotes y cómo gestiona el entorno de servicio las solicitudes con distintas longitudes.
• Enumera los demás procesos y cargas de trabajo que puedan coincidir con la inferencia.

Incluye la sobrecarga del entorno de ejecución sin presuponer un margen fijo

No hay un margen fijo universalmente fiable que se pueda añadir a todas las estimaciones. El uso real puede variar según el motor de inferencia, las optimizaciones del entorno de ejecución, el procesamiento por lotes, la arquitectura del modelo y la fragmentación de la memoria. El [planificador de recursos para LLM](https://pypi.org/project/llm-resource-planner/) también señala estos factores como fuentes de variación.

En lugar de añadir un porcentaje arbitrario y considerar definitivo el resultado, trata la sobrecarga como una incógnita que hay que medir. Compara los cálculos de pesos y caché con el uso observado en el entorno de ejecución y bajo la carga previstos.

Comprueba la memoria utilizable que informa el entorno donde se ejecutará el servicio. La capacidad nominal no determina cuánta memoria quedará disponible después de las asignaciones del entorno de ejecución y otras cargas de trabajo.

• Documenta el motor de inferencia, la configuración del modelo y los ajustes del servicio utilizados.
• Identifica las cargas de trabajo que compartirán la GPU y si se ejecutarán al mismo tiempo.
• Establece el margen operativo a partir de mediciones de tu propia carga de trabajo, no de un porcentaje universal.

Define el perfil de carga de trabajo antes de elegir la infraestructura

Una estimación útil empieza por describir la carga de trabajo, no solo por indicar el nombre de un modelo. Los cálculos dependen de los detalles arquitectónicos necesarios para la caché, la precisión de los pesos, las longitudes de secuencia y la concurrencia prevista.

Distingue el uso habitual del máximo que necesitas admitir. Una longitud media puede ocultar la demanda de prompts largos o de varias solicitudes simultáneas. El estimador de memoria citado anteriormente también basa sus cálculos en parámetros de arquitectura, longitud de secuencia y tamaño del lote.

• Modelo: número de parámetros, detalles de arquitectura necesarios para la fórmula de caché KV y precisión o cuantización de los pesos.
• Secuencia: longitud habitual y máxima del prompt, de la salida generada y de la secuencia total.
• Servicio: número habitual y máximo previsto de solicitudes activas, comportamiento del procesamiento por lotes y ajustes relevantes del entorno de ejecución.
• Entorno: memoria de GPU disponible para el proceso y otras cargas de trabajo que compartan la GPU.

Valida la estimación con una prueba representativa

Ejecuta el modelo real con el entorno de inferencia y la configuración del servicio previstos. Empieza con una carga normal y prueba también las secuencias largas y la concurrencia máxima que necesites admitir. El [estimador de memoria](https://github.com/david-xinyuwei/llm-memory-estimator) recomienda probar los modelos reales y supervisar el uso en el despliegue.

Observa la memoria de GPU durante la carga del modelo y mientras haya solicitudes activas. Registra la configuración junto con las mediciones para que los resultados sigan siendo útiles cuando cambies el modelo, los límites de contexto, la cuantización, el entorno de ejecución o el procesamiento por lotes.

Que una sola solicitud se complete correctamente no demuestra que el sistema pueda soportar la carga máxima. Investiga los aumentos inesperados del consumo o los fallos antes de considerar que la configuración está lista.

• Prueba el formato de modelo, la precisión, el entorno de ejecución y los ajustes previstos para el despliegue.
• Supervisa el uso real de memoria durante la carga y la atención de solicitudes.
• Repite las mediciones tras realizar cambios importantes en el modelo o la configuración del servicio.

Qué hacer si la carga de trabajo supera la memoria disponible de la GPU

Primero, identifica qué parte de la carga de trabajo causa el exceso. Si se debe a secuencias largas, reducir la longitud del contexto o limitar las solicitudes excepcionalmente largas puede reducir la demanda de caché KV. Si predominan los pesos, la cuantización puede reducir su consumo de memoria, aunque hay que evaluar la compensación de precisión para el modelo y la tarea. El [tutorial de Khronos sobre hardware y presupuesto de VRAM](https://github.khronos.org/Vulkan-Site/tutorial/latest/AI_Assisted_Vulkan/03_model_selection_specialization/03_hardware_vram.html) describe la cuantización como una reducción de bits por peso con una compensación de precisión.

Otras opciones son reducir la concurrencia máxima o cambiar la configuración del servicio. Comprueba que los límites de contexto, la gestión de solicitudes y la calidad de las salidas sigan cumpliendo los requisitos de la aplicación.

Si esos cambios no satisfacen las necesidades de la carga de trabajo, vuelve a evaluar la capacidad de GPU o el diseño del despliegue. La evidencia disponible no establece una recomendación de hardware universal: basa la comparación en resultados medidos y repite la prueba tras cualquier cambio.

• Reduce la longitud del contexto cuando la carga de trabajo admita prompts o salidas más cortos.
• Evalúa la cuantización de los pesos y comprueba la compensación de precisión para tu caso de uso.
• Reduce el número máximo de solicitudes simultáneas o ajusta el procesamiento por lotes y prueba el efecto en el servicio.
• Si la carga de trabajo requerida sigue sin caber, compara las opciones de despliegue con mediciones, no con un cálculo que solo contemple los pesos.