IA generativa en tus propios servidores: cuánta memoria de GPU necesita un modelo de lenguaje privado

Para ejecutar un modelo de IA generativa (GenAI) en tus propios servidores, suma dos cosas: los pesos del modelo y la memoria que ocupan las solicitudes que está respondiendo en ese mismo momento. Con la precisión habitual de 16 bits, los pesos necesitan unos 2 GB de memoria de GPU por cada mil millones de parámetros, así que un modelo de 32.8 mil millones de parámetros necesita unos 66 GB antes de responder a nadie. Después, cada solicitud añade memoria en proporción a su longitud, y esa parte decide cuántas solicitudes puede atender el servidor a la vez.

¿Qué ocupa la memoria de la GPU cuando funciona un modelo de lenguaje?

Un modelo de lenguaje suele ejecutarse en GPU, procesadores diseñados para el tipo de cálculos que hacen los modelos, y el modelo tiene que estar en la propia memoria de las GPU mientras trabaja. Esa memoria contiene:

• Los pesos, los números que el modelo aprendió durante el entrenamiento, que se cargan una vez y se quedan ahí
• La caché KV, la memoria de trabajo del modelo para cada solicitud que está respondiendo
• Espacio de trabajo para el software que sirve el modelo

Los pesos quedan fijados en cuanto eliges un modelo y una precisión. La caché KV crece con el número de solicitudes que se responden a la vez y con su longitud. Ambas cosas pueden calcularse antes de comprar nada.

¿Cuánta memoria ocupan los pesos del modelo?

El tamaño de un modelo se cuenta en parámetros, y la precisión es el número de bits que se usan para guardar cada uno. La guía de Hugging Face para ejecutar modelos de forma eficiente, consultada el 27 de octubre de 2026, señala que «hoy en día casi todos los modelos se entrenan en bfloat16», un formato de 16 bits en el que cada parámetro ocupa 2 bytes. Su regla práctica: «cargar los pesos de un modelo de X mil millones de parámetros requiere aproximadamente 2 * X GB de VRAM con precisión bfloat16/float16», donde VRAM es la memoria de la GPU.

El ejemplo de la propia guía es Llama 2 70B, con unos 140 GB solo para los pesos. Qwen3-32B, un modelo de pesos abiertos publicado con la licencia Apache 2.0, tiene 32.8 mil millones de parámetros según su ficha de modelo, así que sus pesos ocupan unos 66 GB. «Pesos abiertos» significa que el creador publica los archivos del modelo para que cualquiera pueda ejecutarlo.

La cuantización guarda los pesos en menos bits. Con 8 bits, un parámetro ocupa 1 byte, y con 4 bits, medio byte, así que el mismo modelo necesita unos 33 GB o algo más de 16 GB. El equipo de Qwen publica una versión de 8 bits, Qwen3-32B-FP8.

La guía de Hugging Face dice que los pesos «pueden cuantizarse a 8 o 4 bits sin una pérdida significativa de rendimiento». También advierte que la cuantización a 4 bits «en la práctica puede dar a menudo resultados distintos» que la de 8 o 16 bits, y añade: «Le corresponde al usuario probarlo». Pasa tus propias preguntas de prueba por cualquier versión comprimida antes de confiar en ella.

¿Cuánta memoria añade cada solicitud?

Mientras el modelo escribe una respuesta, guarda valores para cada token que ya ha leído y escrito, para no tener que calcularlos de nuevo con cada palabra nueva. Un token es un fragmento de una palabra. Esos valores guardados son la caché KV, abreviatura de key-value cache. Una publicación de 2023 de los creadores de vLLM, un programa de código abierto para servir modelos, señala que la caché «ocupa hasta 1.7 GB para una sola secuencia en LLaMA-13B».

Puedes calcular el tamaño para tu propio modelo a partir de sus parámetros publicados. Para cada token, la caché guarda dos conjuntos de números, claves y valores, por cada capa. Qwen3-32B tiene 64 capas y guarda en su caché 8 cabezas de atención de 128 números cada una, según su ficha de modelo y su archivo de configuración. A 2 bytes por número, eso es 2 × 64 × 8 × 128 × 2 bytes, unos 262 KB por token.

Por tanto, una solicitud de 8000 tokens, como una pregunta larga con fragmentos encontrados en tus documentos más la respuesta, ocupa unos 2.1 GB hasta que termina la respuesta. El contexto nativo completo del modelo, de 32 768 tokens, ocupa unos 8.6 GB.

Cuenta las solicitudes que se están respondiendo en el mismo momento, no las personas con acceso. Quienes usan un asistente pasan la mayor parte del tiempo leyendo respuestas y escribiendo preguntas, mientras que un sistema que procesa un atraso de documentos puede mantener ocupada cada GPU toda la noche.

¿Cuántas GPU supone eso?

Las GPU de centro de datos vienen con una cantidad fija de memoria. Las páginas de especificaciones de Nvidia, consultadas el mismo día, indican 80 GB para la H100 en su versión SXM y 94 GB en su versión NVL, 141 GB para la H200 y 48 GB para la L40S.

El software que sirve el modelo deja libre parte de cada GPU. La documentación de vLLM describe su ajuste como «la fracción de memoria de la GPU que usará el ejecutor del modelo» y da 0.92 como valor predeterminado en su versión actual. En una H100 NVL de 94 GB, eso son unos 86 GB. Los pesos de Qwen3-32B en 16 bits ocupan unos 66 GB de ellos. Quedan unos 21 GB para la caché KV y el resto de la memoria de trabajo del software, lo que da espacio para menos de diez solicitudes de 8000 tokens a la vez.

Con los pesos de 8 bits quedan unos 54 GB, suficientes para unas 25 solicitudes así. En una H100 de 80 GB, los pesos de 16 bits dejan unos 8 GB, espacio para menos de cuatro.

Cuando los pesos no caben en una GPU, el modelo se reparte entre varias GPU del mismo servidor. La documentación de vLLM dice que, «si el modelo es demasiado grande para una sola GPU pero cabe en un solo nodo con varias GPU, hay que usar paralelismo de tensores», que es como llama a este reparto. Un modelo de 70 mil millones de parámetros con precisión de 16 bits no cabe en una GPU de 94 GB, y en dos de ellas quedan unos 33 GB para las solicitudes.

Estas cifras te dicen si un modelo cabe. Lo rápido que responde depende de las GPU, de la longitud de las respuestas y de la carga, y solo una prueba con tus propias solicitudes puede mostrarlo.

¿Deberíamos alquilar GPU en la nube o comprar servidores?

Alquilar primero es una forma más barata de saber qué necesitas. La lista pública de precios de Microsoft para Azure, consultada el mismo día, da estos precios de pago por uso para máquinas virtuales Linux en su región East US:

• Una H100 NVL de 94 GB (Standard_NC40ads_H100_v5): $6.98 la hora, unos $5100 por un mes de 730 horas
• Dos H100 NVL de 94 GB (Standard_NC80adis_H100_v5): $13.96 la hora, unos $10 200 al mes
• Ocho H100 de 80 GB (Standard_ND96isr_H100_v5): $98.32 la hora, unos $71 800 al mes

Son precios de lista para el pago por horas, y la capacidad reservada se vende con otras condiciones. Los precios cambian, así que pide presupuestos a más de un proveedor para la configuración que indiquen tus pruebas.

Tener servidores propios tiene sentido cuando la carga es estable y sabes qué modelo vas a usar, o cuando tus normas exigen que el hardware se quede en tu propio edificio. El coste incluye entonces a las personas que mantienen esos servidores en marcha, algo que trata el artículo sobre quién opera un sistema LLM sin un equipo de ML.

¿Cómo dimensionamos el sistema para nuestro propio uso?

• Prueba uno o dos modelos candidatos con preguntas reales de tu trabajo y quédate con aquel cuyas respuestas aprueben
• Calcula cuántas solicitudes responderá el sistema a la vez en su hora de más actividad y qué longitud tiene una solicitud típica, contando la pregunta, los fragmentos encontrados en tus documentos y la respuesta
• Calcula la memoria para los pesos y la caché KV como se explica arriba, y deja un margen
• Alquila GPU durante unos días y haz una prueba de carga con tus propios prompts en ese pico
• Compra o reserva capacidad una vez terminada la prueba

vLLM incluye un comando para este tipo de pruebas, vllm bench serve. Puede informar de percentiles de «ttft» y «tpot», el tiempo hasta el primer token y el tiempo por token de salida. Decide antes de la prueba cuánto esperará tu personal las primeras palabras de una respuesta, y juzga los resultados por la hora de más actividad.

¿Quién puede montar esto?

Tu equipo de infraestructura puede operar los servidores con GPU si ya se ocupa de servidores propios, y el proveedor de hardware o de nube puede ayudar con las máquinas. Conectar el modelo a tus documentos, al inicio de sesión y a los permisos, y probar sus respuestas, es trabajo de quien construya el sistema alrededor del modelo.

La empresa o el equipo que contrates debería mostrarte las cuentas: qué modelo y qué precisión, cuánta memoria va a los pesos y cuánta a la caché KV, qué carga usó la prueba y qué midió. Pide esas cifras antes de aprobar un presupuesto de hardware.

¿Dónde encaja amBrain?

El único proyecto con modelos de lenguaje que amBrain describe en público es este: «Hemos llevado a producción una integración de LLM dentro del perímetro FinTech de un cliente: extracción y normalización de avisos no estructurados de brókers y de centros de negociación —eventos corporativos, cambios de instrumentos y de márgenes— en registros estructurados que consume el sistema de trading».

Este artículo no es un caso de estudio y no describe ningún trabajo para clientes. La frase citada no dice qué modelo usa ese sistema, en qué hardware ni dónde funciona. Las cifras anteriores son cálculos a partir de especificaciones y listas de precios publicadas, no mediciones de ese proyecto ni de ningún otro trabajo de amBrain.

Las empresas, los modelos y los productos que se nombran aquí se citan a partir de sus páginas publicadas, y el artículo no afirma que amBrain tenga relación alguna con ninguno de ellos. No da precios, plazos ni condiciones de amBrain.

amBrain desarrolla software desde 2019. Trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. Sobre la propiedad, su frase es: «El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables». Si amBrain está en tu lista corta, pídele las mismas cuentas que a cualquier otra empresa.