¿Cabe este modelo en tu GPU? Cómo estimar la VRAM antes de elegir hardware

La pregunta no es solo cuántos parámetros tiene el modelo

Saber cuántos parámetros tiene un modelo puede servir para orientarse, pero no responde por sí solo a la pregunta práctica: ¿funcionará con la configuración que necesito en esta GPU? Para contestarla hay que considerar el modelo concreto, el formato de sus pesos, el runtime, el contexto que se quiere procesar, las solicitudes simultáneas y la memoria que ya utiliza el sistema.

Por eso, «cabe» no es una propiedad aislada del modelo. Puede caber al cargarlo y quedarse sin memoria cuando crece el contexto; puede funcionar para una solicitud y no para varias; o puede arrancar porque parte del trabajo se ejecuta en RAM, aunque no todo el modelo esté en la GPU. También puede variar el resultado al cambiar el runtime o sus opciones.

El objetivo de esta guía es construir una estimación inicial y luego someterla a una prueba controlada. La estimación ayuda a descartar configuraciones claramente inviables y a saber qué medir. No sustituye una prueba con el hardware, el runtime y la carga reales. Tampoco permite deducir velocidad, calidad de respuesta ni estabilidad prolongada.

Qué ocupa memoria durante la ejecución

Una estimación útil separa al menos cuatro componentes: los pesos del modelo, la caché KV, los buffers temporales de cálculo y el espacio que necesita el runtime junto con el sistema y otros procesos. La división es conceptual: según el runtime, las opciones y el hardware, las asignaciones pueden registrarse de forma distinta y no siempre aparecen como categorías independientes en una herramienta de monitorización.

Los pesos son los datos del modelo que el runtime carga para realizar la inferencia. El tamaño del archivo puede dar una pista sobre ellos, pero no equivale automáticamente a la memoria total necesaria. El formato y la cuantización influyen en el tamaño de los pesos, y la carga también implica memoria de trabajo y estructuras del runtime. No conviene convertir el tamaño del archivo en una cifra de VRAM disponible sin medir la configuración elegida.

La caché KV guarda información asociada a tokens ya procesados para continuar generando. Su ocupación depende de la carga activa y de características del modelo, no solo de su nombre o del número de parámetros. El contexto previsto y las solicitudes en paralelo son variables que deben fijarse antes de estimar; la arquitectura y el tipo de caché configurado también pueden cambiar el resultado.

Los buffers de cálculo son memoria temporal que se utiliza durante operaciones del runtime. Su tamaño puede depender de la implementación y de las opciones activas. El runtime y el sistema, por su parte, necesitan margen propio; además, una GPU puede compartir memoria con pantalla u otros procesos. Por ello, la memoria nominal de la tarjeta no debe tratarse como si estuviera enteramente libre para el modelo.

Reúne los datos antes de hacer cuentas

Empieza por identificar el artefacto exacto del modelo: no solo su nombre comercial, sino también el archivo o formato que vas a cargar y la configuración asociada. Una ficha de configuración puede revelar dimensiones que el nombre no especifica, como el número de capas y ciertas dimensiones y cabezas de atención. Son datos que ayudan a describir la arquitectura, pero no bastan por sí solos para calcular el consumo final: también importa cómo el runtime representa y asigna la caché y los buffers.

Después fija el runtime y sus opciones. Registra la versión o configuración que estás probando, la cantidad de contexto solicitada, la concurrencia prevista y cualquier elección de tipo o ubicación de la caché. Si el runtime permite colocar algunas capas en GPU, descargar una parte a CPU o distribuir el trabajo entre tarjetas, anota también esas decisiones. Una estimación sin estas condiciones mezcla escenarios diferentes.

Por último, anota el punto de partida del equipo: memoria total y disponible de la GPU, procesos que ya la usan y si la tarjeta está dedicada a la inferencia o cumple otras funciones. Herramientas de administración de GPU pueden mostrar memoria total, reservada, usada y libre; son observaciones del estado del dispositivo, no una explicación completa de qué componente del modelo ocupa cada bloque.

Cómo construir una estimación inicial

Como primera aproximación, piensa en la VRAM requerida como la suma de pesos residentes en GPU, caché KV alojada en GPU, buffers y coste del runtime, más un margen para las variaciones de carga y los otros usos de la tarjeta. No se trata de una fórmula exacta ni de una cifra que pueda completarse con datos genéricos: las categorías y su tamaño dependen de la implementación y la configuración.

Separa los valores conocidos de las aproximaciones. El tamaño del archivo es un dato observable, pero no prueba cuánto de ese tamaño acabará residente en GPU ni cuál será el pico de memoria. El contexto y la concurrencia deseados son decisiones tuyas. La arquitectura y la estrategia de caché requieren información del modelo y del runtime. Los buffers y el margen suelen necesitar medición en el sistema donde se ejecutará.

Si una variable importante es desconocida, evita ocultarla detrás de una cifra única. Es más honesto preparar escenarios: por ejemplo, una configuración de contexto moderada y otra más exigente, cada una con la concurrencia que el servicio necesita. Esas etiquetas no garantizan consumos concretos; sirven para que la prueba cubra las condiciones de uso, en lugar de validar solo el caso más sencillo.

La documentación de un runtime puede ayudar a entender qué opciones ofrece y qué límites declara, pero una capacidad anunciada o un valor de configuración no demuestra que el equipo tolere la carga en funcionamiento. Usa la documentación para formular la prueba y el uso medido para comprobar la configuración.

La caché KV cambia con el contexto y la carga

La caché KV merece atención porque su ocupación está ligada al trabajo activo. Un contexto más largo puede requerir conservar más información para continuar la generación; varias solicitudes simultáneas pueden mantener varias secuencias activas. No se puede inferir una cifra precisa a partir del nombre del modelo o de su cantidad de parámetros.

La arquitectura importa. Para estimar con más fundamento hacen falta atributos de configuración del modelo y detalles de cómo el runtime trata la atención y la caché. Incluso con esa información, el valor observado puede depender del tipo de caché elegido, de la asignación de memoria y de las opciones del runtime. Por tanto, una regla genérica sin esos datos puede servir como orientación cualitativa, pero no como garantía de que una configuración cabe.

Los runtimes pueden ofrecer estrategias distintas, como cachés dinámicas, estáticas, cuantizadas o descargadas a CPU. Cambiar la estrategia puede cambiar la distribución de memoria y las condiciones de ejecución. No compares dos estimaciones como si fueran equivalentes si una usa otra estrategia o si difieren el runtime y sus opciones.

GPU completa, descarga a RAM o varias tarjetas

Una ejecución puede usar toda la GPU para el modelo, colocar solo una parte de sus capas en ella, descargar parte de la caché a CPU o repartir el modelo entre GPU. Algunas de estas opciones permiten probar configuraciones que no cabrían con todas sus partes en una sola tarjeta, pero no demuestran que el modelo esté íntegramente residente en VRAM. Tampoco permiten deducir por sí solas el rendimiento que tendrá.

Comprueba el modo de ejecución en las opciones del runtime y en sus registros. En herramientas que permiten especificar capas en GPU o dividir el trabajo entre tarjetas, anota los valores aplicados. Si se activa una descarga a CPU o una estrategia de caché en CPU, la memoria de la GPU deja de representar por sí sola todo el uso de memoria de la ejecución. Diferencia entre «la aplicación inició» y «la configuración cumple los requisitos de residencia y carga definidos».

En varias GPU, conocer la suma de la memoria nominal de las tarjetas tampoco basta para saber cómo se distribuirá el modelo. La división depende de las capacidades del runtime y de la configuración elegida. Evalúa cada dispositivo y la asignación efectiva, y no supongas que toda la memoria agregada está disponible para cualquier distribución.

Verifica la estimación con una prueba controlada

La prueba debe reproducir el escenario que quieres desplegar. Fija el modelo, el formato, el runtime, el contexto, la concurrencia y las opciones de caché y descarga. Registra el estado inicial de la memoria y cualquier proceso ajeno que comparta la GPU. Si cambias varias opciones a la vez, será difícil saber cuál explica el resultado.

Carga el modelo y registra la memoria usada y disponible. Luego ejecuta una solicitud con la configuración prevista. Aumenta contexto o concurrencia gradualmente, una variable cada vez, y anota el punto en que aparece un error, se activa una descarga o el consumo se acerca al límite observado. No interpretes una sola lectura como un máximo estable: observa la carga durante la ejecución, porque el uso puede diferir entre carga inicial e inferencia.

Utiliza los registros del runtime para verificar la distribución entre GPU y CPU y las opciones efectivamente aplicadas. Contrasta la observación con una herramienta de GPU que muestre memoria total, usada, reservada y libre. Esa lectura sirve para caracterizar el estado del dispositivo; por sí sola no siempre separa pesos, caché y buffers. Repite la ejecución para detectar variaciones dentro del mismo equipo y anota las condiciones exactas.

Define de antemano qué significa pasar la prueba: completar el contexto previsto, soportar la concurrencia requerida y no depender de una descarga que no estaba contemplada. Si el sistema debe reservar margen para otros procesos, inclúyelo como requisito. Una prueba que termina sin errores pero se queda sin ese margen puede ser insuficiente para el uso previsto.

Errores frecuentes y límites de la estimación

El error más habitual es usar el tamaño del archivo como si fuera el consumo total. Ese dato no incluye necesariamente caché, buffers, runtime ni memoria que ya ocupa el sistema. Otro error es comparar con la capacidad nominal de la GPU sin medir la memoria que queda disponible cuando el equipo está en el estado de uso real.

También es fácil probar solo el arranque y asumir que eso valida un contexto extenso o varias solicitudes. La carga inicial y la carga sostenida son etapas distintas de la prueba. Si cambias el contexto, la concurrencia, el tipo de caché, el runtime o la división entre GPU y CPU, estás probando otra configuración.

Por último, no extrapoles sin cautela una cifra de un runtime a otro. Las herramientas pueden diferir en cómo gestionan memoria y exponen sus métricas. Las cifras observadas describen el equipo y las opciones ensayadas; no garantizan el mismo resultado en otro sistema ni una ejecución estable indefinidamente. La prueba tampoco establece calidad de salida ni velocidad suficiente para un caso de uso.

Criterios finales para elegir o reutilizar hardware

Antes de comprar una GPU, identifica una carga representativa y comprueba si la memoria disponible puede alojar los componentes que quieres mantener en ella, además del margen que necesita el sistema. Si la estimación ya excede de forma evidente la capacidad utilizable, no hace falta fingir precisión: esa combinación requiere cambiar requisitos, distribución o hardware. Si queda cerca del límite, la prueba en el equipo exacto es especialmente importante.

Al reutilizar una GPU, mide su estado real y comprueba quién comparte la memoria. No uses la capacidad total como si estuviera libre. Si aceptas ejecución parcial en RAM o reparto entre tarjetas, registra esa decisión como parte de la configuración, no como un detalle invisible. Al comparar opciones, contrasta la misma carga y los mismos criterios.

Para ampliar el análisis de modelos locales, puedes consultar la guía de modelos locales, el comparador y la sección de descubrimiento. Mantén la misma disciplina al evaluar una opción: identifica la configuración exacta y contrasta las condiciones que importan para tu caso. La conclusión útil no es una cifra universal de VRAM, sino un resultado reproducible para un modelo, un runtime, un hardware y una carga definidos.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.