La VRAM es la memoria de la GPU y limita qué modelo, precisión, contexto y número de solicitudes pueden procesarse sin mover datos a la RAM. No debe confundirse con la velocidad de la GPU ni con la memoria total del servidor.
Un modelo puede parecer compatible por el tamaño de sus pesos y fallar cuando se añade una conversación larga o varias peticiones simultáneas.
Qué ocupa espacio
Los pesos son una parte del consumo. Durante la inferencia también se necesitan activaciones, buffers y caché de atención. La longitud del contexto y el número de secuencias activas hacen crecer esa reserva. El runtime puede reservar memoria adicional para trabajar con eficiencia.
Precisión y cuantización
Usar menos bits reduce el tamaño de los pesos, pero puede afectar a la salida y exige un formato compatible. La cuantización no elimina la memoria de activaciones ni garantiza que la carga completa quepa. Comprueba el consumo con el contexto y la concurrencia reales.
Cuando el modelo no cabe
El sistema puede dividir pesos entre varias GPUs, mover partes a RAM o cargar capas de forma parcial. Estas técnicas permiten ejecutar una carga, pero añaden transferencias y pueden aumentar la latencia. Que el proceso arranque no significa que tenga una experiencia aceptable.
VRAM y rendimiento
Más VRAM permite alojar cargas mayores o más secuencias, pero no garantiza más tokens por segundo. El ancho de banda, la arquitectura, la precisión, el runtime y la saturación del dispositivo también importan. Mide tiempo hasta el primer token y generación sostenida.
Planificar una máquina
Incluye GPU, VRAM, RAM, CPU, almacenamiento, red, energía y refrigeración. Conserva margen para el sistema y para picos. Si la carga no justifica una GPU, una CPU puede ser suficiente para pruebas o baja concurrencia. La decisión debe partir de una prueba representativa, no solo del tamaño anunciado del modelo.
Estimar memoria antes de cargar
Calcula el tamaño de los pesos según su precisión y deja margen para runtime, buffers, activaciones y caché. Después añade el contexto y el número de secuencias simultáneas. Una estimación basada solo en gigabytes del archivo suele quedarse corta.
Concurrencia y contexto
Dos solicitudes cortas no consumen igual que dos conversaciones largas. El servidor puede limitar concurrencia, poner solicitudes en cola o reducir contexto para evitar quedarse sin memoria. Cada decisión afecta a latencia y experiencia.
Dividir la carga
Varias GPUs, offloading a RAM y carga parcial son alternativas cuando una tarjeta no basta. Exigen transferencias, comunicación y una configuración compatible. Mide el coste de mover datos antes de concluir que la carga es viable.
Memoria del servidor y almacenamiento
La RAM debe alojar procesos y partes que no estén en VRAM; el disco debe contener pesos, cachés, imágenes y logs. Una GPU con suficiente VRAM puede seguir limitada por CPU, red o I/O. La planificación debe considerar todo el camino de la solicitud.
Qué observar en producción
Registra uso de VRAM, memoria libre, errores de asignación, latencia, tokens por segundo y cola. Un crecimiento de contexto puede consumir el margen sin que cambie el modelo. Si el proceso empieza a intercambiar memoria, la latencia suele volverse irregular.
Una estimación práctica
Comienza con el tamaño de pesos en la precisión elegida y añade margen para runtime, caché, contexto y concurrencia. Mide después con una entrada larga y varias solicitudes, porque el caso mínimo puede ocultar el límite real.
Cuando hay presión de memoria
Reducir concurrencia, acortar contexto o cuantizar puede ser preferible a añadir hardware inmediatamente. Cada alternativa modifica latencia, calidad u operación. Observa errores de asignación y uso sostenido, no solo el consumo al iniciar.
La VRAM es una restricción importante, pero la aplicación sigue necesitando CPU, RAM, disco y red.
Contexto como variable
Aumentar la ventana de contexto puede aumentar la memoria de caché y reducir la concurrencia disponible. Recortar o recuperar solo la información necesaria puede ser más eficiente que comprar una GPU mayor.
Comprobar la ruta completa
Mide memoria, transferencia, latencia y throughput con la aplicación real. La VRAM suficiente no garantiza una respuesta rápida si CPU, red o almacenamiento son el límite.
Establece un límite de concurrencia antes de que la memoria se agote y provoque errores en todas las solicitudes. Una cola controlada puede ofrecer una experiencia más estable.
La medición debe incluir picos.
Una estimación que incluya picos
Establece una cola o límite de concurrencia antes de que la VRAM se agote. Más memoria ayuda, pero CPU, RAM, transferencia y almacenamiento siguen formando parte de la ruta.
El consumo debe medirse durante generación sostenida, no solo al cargar el modelo. Una carga que arranca puede fallar cuando aumenta el contexto o la concurrencia.
Planifica una ruta de degradación: reducir concurrencia, acortar contexto o poner solicitudes en cola. Comprar más VRAM no siempre es la primera medida adecuada.
Registra el límite observado.
Comprueba además el tiempo de transferencia y el uso de RAM. La memoria de la GPU es una restricción, no el único factor de rendimiento.

