Puedes tener la GPU más avanzada del mercado, una matriz NVMe ultrarrápida y suficientes núcleos de CPU para calentar un pequeño pueblo.
Y luego, una tarde de martes, tu servidor de modelos empieza a devolver 500 porque “CUDA out of memory”.
No porque faltara cómputo. Porque se acabó la VRAM en el peor momento posible.
Después de 2026, ese modo de fallo dejará de ser un problema marginal para laboratorios de IA. Será una realidad operacional del día dos para empresas normales:
copilotos de atención al cliente, puntuación de fraude en tiempo real, pipelines creativos, datos sintéticos, modelos de vídeo y analítica que “accidentalmente” se volvió deep learning.
La VRAM está convirtiéndose en la nueva planificación de capacidad de disco—salvo que las consecuencias llegan en milisegundos, no en semanas.
La VRAM es el presupuesto, no el adorno
Antes, la VRAM era tema de discusión entre jugadores en foros mientras los demás encogían los hombros y compraban lo que TI aprobaba.
En IA y gráficos en producción, la VRAM es ahora el techo rígido que decide si envías la funcionalidad, cómo será tu latencia
y si tu canal de incidentes suena a las 2 a.m.
El patrón central es simple: el cómputo ha escalado más rápido que la “memoria utilizable por carga de trabajo”. Las GPUs siguen ganando FLOPS.
Mientras tanto, los modelos crecieron, las ventanas de contexto se alargaron, el batching se volvió más inteligente y todos quieren múltiples inquilinos concurrentes en el mismo acelerador.
La VRAM es donde esas ambiciones colisionan.
En términos de SRE: la VRAM es el nuevo “recurso que no puedes estallar”. La CPU puede picos. El disco puede encolar. La red puede bufferizar.
La VRAM es una sala de tamaño fijo. Una vez llena, no te desaceleras de forma elegante; fallas, haces thrashing o caes silenciosamente a un camino más lento
que arruina el SLO y falsea tu modelo de costos.
Por qué esto se acelera después de 2026
“Después de 2026” no es una fecha mágica. Es una predicción sobre cuándo varias tendencias se acumulan lo suficiente como para que la VRAM se convierta en el factor limitante para más equipos que antes.
Esto es lo que lo empuja por encima del borde.
1) Las ventanas de contexto siguen expandiéndose y la caché KV no es gratis
La industria pasa de prompts cortos y conversacionales a interacciones largas y con estado: historiales de clientes, bases de código, documentos de políticas, trazas de agentes multi‑paso.
Para la inferencia tipo transformer, contexto largo significa una gran caché de keys/values (KV).
Esa caché vive en VRAM porque está en la ruta crítica.
Puedes comprimirla, cuantizarla, paginarla, fragmentarla—claro. Pero el centro de gravedad sigue ahí: contexto más largo desplaza el coste desde el cómputo hacia la capacidad de memoria y el ancho de banda de memoria.
2) Los modelos multimodales devoran memoria como si fuera su trabajo
El texto solo ya estiró la VRAM. Añade imágenes, vídeo y audio, y no solo aumentas parámetros.
Añades activaciones más grandes, más estados intermedios, más buffers de pre/post‑procesado y más oportunidades de fragmentación.
El chiste es que “el vídeo son solo imágenes en el tiempo”. La factura es que el tiempo multiplica tu huella de VRAM.
3) La presión de batching pasa de “agradable de tener” a “ganancia o pérdida”
La mayoría de stacks de serving mejoran el throughput con batching. El batching quiere VRAM: más secuencias concurrentes, más caché KV, buffers temporales mayores.
Después de 2026, más empresas ejecutarán inferencia como producto, no como demo. Eso significa concurrencia sostenida, no uso ocasional.
4) Las expectativas de fiabilidad crecen más rápido que el margen de memoria
Las herramientas internas pueden fallar ocasionalmente. Las funciones orientadas al cliente no pueden. Si tu VRAM está al 92% en estado estable, no tienes “8% de margen”.
Tienes un outage programado para cuando la fragmentación suba o llegue una petición más larga que la que probaste.
5) Compartirás GPUs más agresivamente
GPUs dedicadas por servicio son caras y políticamente difíciles de justificar cuando finanzas descubre los gráficos de utilización.
Espera más GPUs multi‑tenant usando contenedores, particionado MIG o compartición a nivel de scheduler. Compartir aumenta la varianza.
Varianza más techos rígidos equivale a ruido en el pager.
6) El ancho de banda de memoria se convierte en el gobernador oculto
Incluso si “tienes suficiente VRAM”, puede que no tengas suficiente ancho de banda.
Muchas cargas de inferencia están limitadas por ancho de banda de memoria, no por cómputo.
A medida que los modelos crecen, la intensidad aritmética no siempre te salva.
El resultado operacional: después de 2026, “cuántas GPUs” deja de ser la pregunta completa.
La pregunta real es “cuánta VRAM por GPU, a qué ancho de banda, bajo qué concurrencia y con qué comportamiento de fragmentación”.
Eso no es trivia de compras. Eso es arquitectura.
Datos históricos interesantes (útiles en una reunión)
- Dato 1: Las primeras GPUs de consumo solían enviarse con “suficiente VRAM para texturas”, porque la carga dominante era el rasterizado, no el estado persistente gigante.
- Dato 2: El cambio de pipelines de función fija a shaders programables hizo las GPUs más generales, pero la VRAM seguía importando principalmente para frame buffers y assets—hasta que el deep learning secuestró el hardware.
- Dato 3: CUDA (2007) popularizó el cómputo en GPU; también convirtió la gestión de memoria GPU en una preocupación de la aplicación más que en una curiosidad del driver.
- Dato 4: La precisión mixta (FP16/BF16) no solo aceleró el cómputo—redujo huellas de parámetros y activaciones, “fabricando VRAM” mediante representación.
- Dato 5: La introducción de HBM (High Bandwidth Memory) fue una historia de ancho de banda primero, pero también moldeó los niveles de capacidad: no toda VRAM crece igual entre líneas de producto.
- Dato 6: Unified Virtual Memory y memoria gestionada prometieron simplicidad, pero muchos equipos en producción aprendieron por las malas que “paginado al host” puede convertir una petición de 50 ms en un desastre de varios segundos.
- Dato 7: Los mecanismos de atención mejoraron la calidad de modelos, pero también complicaron el comportamiento de memoria: cachés KV, shapes dinámicos y contextos largos se convierten en variables de planificación de capacidad de primera clase.
- Dato 8: MIG y características de particionado similares responden a la economía—sin embargo convierten la VRAM en un recurso programable con límites rígidos y nuevos modos de fallo.
Qué llena realmente la VRAM en cargas modernas
La gente habla de “tamaño del modelo” como si la VRAM fuera solo parámetros. En producción, la VRAM es un apartamento desordenado:
el sofá son los pesos del modelo, pero el pasillo está lleno de cajas que no recordabas haber pedido.
1) Pesos del modelo (obvio, pero aún malentendido)
Los pesos viven en VRAM por velocidad. La cuantización puede reducirlos. El sharding puede repartirlos.
Pero cada “truco ingenioso” suele aumentar la sobrecarga en otro lado: metadatos, empaquetado, restricciones de kernels o buffers adicionales.
2) Caché KV (el asesino silencioso)
Para generación autoregresiva, mantienes keys/values pasadas para no recomputar la atención desde cero.
El coste de la caché KV crece con:
- longitud de contexto
- tamaño de lote / número de secuencias concurrentes
- dimensión oculta y número de capas
- precisión (FP16/BF16/FP8/int8)
Por eso un modelo que “cabe” puede fallar bajo carga. Dimensionaste para pesos, y luego el tráfico dimensionó tu caché KV por ti.
3) Activaciones y buffers temporales
La gente de training sabe que las activaciones dominan la memoria. En inferencia, todavía obtienes temporales: workspaces de atención,
buffers de kernels fusionados, staging de tokenización y embedding, y sobrecarga por petición.
Algunos frameworks los asignan oportunistamente y los mantienen para evitar churn del allocator.
Eso es bueno para la latencia hasta que es malo para el pico de uso.
4) Fragmentación de memoria y comportamiento del allocator
La fragmentación es la brecha entre “memoria libre” y “memoria libre que realmente puedes usar”.
Puedes tener gigabytes libres y aun así fallar al asignar un bloque contiguo que necesita un kernel.
Esta es una razón por la que los incidentes de VRAM parecen irracionales: el dashboard dice 20% libre, pero el job muere igual.
5) Sobrecarga por multi‑tenancy
Si varios procesos comparten una GPU, cada uno puede cargar su propia copia de pesos.
Si usas MIG o aislamiento estricto, obtienes límites predecibles pero menos flexibilidad.
Si no usas aislamiento, el pico de un tenant se convierte en incidente de todos.
6) “Servicios de soporte” en la GPU
Algunas pilas ejecutan pre/post‑procesado en GPU: redimensionado de imágenes, decodificación, extracción de características, filtros de seguridad.
Eso es excelente para el throughput. También significa que tu presupuesto de VRAM ahora se comparte con código que no consideras “el modelo”.
Capacidad vs ancho de banda vs latencia: las tres formas en que la VRAM arruina tu día
La VRAM importa de tres maneras distintas. Confundirlas conduce a compras malas y a incidentes peores.
Capacidad de VRAM: ¿puedes ajustar el working set?
Si no puedes ajustar pesos + caché KV + sobrecarga, crasheas, haces paging, derramas al CPU o cambias silenciosamente a un tamaño de lote menor.
Los problemas de capacidad son fáciles de ver una vez aceptas que “cabe en mi máquina de desarrollo” no es un plan de capacidad.
Ancho de banda de VRAM: ¿puedes alimentar el cómputo?
Muchas cargas de inferencia están limitadas por la rapidez con que mueves datos desde VRAM a los SMs y de vuelta.
Por eso dos GPUs con tamaños de VRAM similares pueden comportarse de forma muy diferente con el mismo modelo.
Los problemas de ancho de banda suelen aparecer como “utilización de GPU baja, pero latencia mala”.
Latencia y patrones de acceso de VRAM: ¿puedes evitar stalls?
No todo acceso a memoria es igual. La fusión de kernels, layouts de tensores y comportamiento de caché importan.
Algunas optimizaciones reducen cómputo pero aumentan tráfico de memoria, y la GPU te lo cobra cortesmente.
Aquí está la verdad incómoda: después de 2026, las decisiones de compra que tratan la VRAM como una casilla para marcar (“80 GB bueno, 40 GB malo”)
perderán frente a equipos que tratan la VRAM como un presupuesto con partidas y reservas de riesgo.
Modos de fallo que verás en producción
No necesitas más teoría. Necesitas reconocer el olor de problemas de VRAM rápidamente.
1) OOMs repentinos tras un deploy, aunque modelo y GPU no cambiaran
A menudo causado por un cambio en la longitud máxima de contexto por defecto, política de batch o una nueva función que mantiene más estado por petición.
Otro clásico: una actualización del framework que cambia el comportamiento del allocator.
2) Picos de latencia bajo carga, con “VRAM libre” reportada
Normalmente fragmentación, paging o una ruta de fallback (kernels más pequeños, menos fusión, offload a CPU).
Vigila la varianza en el tamaño de petición: un prompt largo puede envenenar el comportamiento de caché para todos.
3) Throughput que se estanca muy por debajo de la capacidad teórica de la GPU
A menudo bound por ancho de banda o bloqueado por sincronización y copias de memoria.
Si estás saturando el throughput de memoria pero no los SMs, tu cuello de botella es el ancho de banda de VRAM, no “necesitas más GPUs”.
4) Incidentes de “vecino ruidoso” en multi‑tenant
Un servicio carga un segundo modelo, otro sube el batch size, un tercero empieza a hacer preprocesado en GPU.
La GPU compartida ahora se comporta como una base de datos compartida: todos niegan haber hecho nada.
5) “Funciona, pero solo después de reiniciar el pod”
Eso es fragmentación o una fuga de memoria, a veces en el framework, a veces en tu propio código.
Reiniciar libera VRAM y reinicia el estado del allocator. No es una solución; es un programa de amnistía.
Un chiste corto, porque nos lo ganamos: la VRAM es como el estacionamiento de la oficina—siempre hay “muchos espacios” hasta que intentas aparcar.
Guion de diagnóstico rápido
Cuando un servicio de inferencia está lento o falla, necesitas una secuencia determinista. No corazonadas.
Primero: confirma si es capacidad, fragmentación o ancho de banda
- Revisa VRAM usada vs total (por GPU, por proceso). Si estás cerca del techo, trátalo como riesgo de capacidad.
- Revisa logs de OOM / allocator. Si OOM ocurre con memoria libre reportada, sospecha fragmentación o asignaciones contiguas grandes.
- Revisa la utilización de ancho de banda de memoria. Si el ancho de banda está al máximo y la utilización de SM es moderada, estás limitado por ancho de banda.
Segundo: aisla si el problema es varianza por petición o estado estable
- Compara p50 vs p99 de latencia. Si p99 explota mientras p50 está bien, probablemente tienes varianza en tamaño de petición que dispara crecimiento de KV o paging.
- Inspecciona la distribución de prompts/tokens. Si un equipo decidió “incluyamos todo el historial del cliente”, ya tienes al culpable.
- Mira la concurrencia y el comportamiento del batcher. Batching que se adapta a la carga puede adaptarse accidentalmente hasta OOM.
Tercero: decide la mitigación de emergencia
- Limita tokens/contexto máximo temporalmente. Es brusco, pero detiene la hemorragia.
- Reduce el tamaño máximo de batch / concurrencia en la GPU. El throughput baja; la disponibilidad vuelve.
- Mueve un tenant fuera de la GPU o aplica aislamiento (MIG o separar pools de nodos) si confirmas vecino ruidoso.
- Reinicia para desfragmentar solo como última medida—y agenda un seguimiento para eliminar la necesidad.
Idea parafraseada de John Allspaw: “La fiabilidad viene de aprender en la realidad desordenada de producción, no de fingir que los sistemas se comportan idealmente.”
Tareas prácticas con comandos: qué ejecutar, qué significa, qué decides
Estas son las tareas que realmente quiero en tu runbook. Cada una incluye: un comando, qué significa la salida y qué decisión tomas.
Los comandos asumen Linux con GPUs NVIDIA; adáptalos si estás en otra pila.
Task 1: Snapshot del uso de VRAM por GPU y por proceso
cr0x@server:~$ nvidia-smi
Tue Jan 21 10:14:03 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 555.42 Driver Version: 555.42 CUDA Version: 12.5 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 NVIDIA A100-SXM4-80GB On | 00000000:3B:00.0 Off | 0 |
| 35% 62C P0 285W / 400W | 74210MiB / 81920MiB | 71% Default |
+-------------------------------+----------------------+----------------------+
| Processes: |
| GPU PID Type Process name GPU Memory |
|=============================================================================|
| 0 23144 C python3 72112MiB |
| 0 24701 C /usr/bin/tritonserver 1820MiB |
+-----------------------------------------------------------------------------+
Qué significa: La GPU 0 está en ~74 GB usados; un proceso python posee la mayor parte.
Decisión: Si esto es estado estable, no tienes margen. Limita tokens/batch o traslada la carga a una tier con más VRAM antes de aumentar tráfico.
Task 2: Capturar utilización y presión de memoria a lo largo del tiempo
cr0x@server:~$ nvidia-smi dmon -s pucm -d 1 -c 10
# gpu pwr gtemp mtemp sm mem enc dec mclk pclk
# Idx W C C % % % % MHz MHz
0 290 63 - 68 92 0 0 1215 1410
0 296 63 - 70 93 0 0 1215 1410
0 287 62 - 66 94 0 0 1215 1410
0 281 62 - 62 95 0 0 1215 1410
0 275 61 - 58 95 0 0 1215 1410
Qué significa: La utilización de memoria es consistentemente muy alta mientras SM es moderado.
Decisión: Podrías estar limitado por ancho de banda. Considera una tier de VRAM más rápida, optimización de kernels o reducir tráfico de memoria (cuantización, mejor batching, atención fusionada).
Task 3: Identificar qué GPU está usando realmente un contenedor
cr0x@server:~$ docker exec llm-serving env | grep -E 'CUDA|NVIDIA|VISIBLE'
NVIDIA_VISIBLE_DEVICES=0
CUDA_VISIBLE_DEVICES=0
Qué significa: Este contenedor está fijado a la GPU 0.
Decisión: Si GPU 0 está sobrecargada mientras GPU 1 está inactiva, arregla el scheduling/placement antes de comprar hardware.
Task 4: Revisar uso de VRAM y cómputo por proceso en vista compacta
cr0x@server:~$ nvidia-smi pmon -c 1
# gpu pid type sm mem enc dec command
# Idx # C/G % % % % name
0 23144 C 64 91 0 0 python3
0 24701 C 5 2 0 0 tritonserver
Qué significa: Un proceso domina tanto el cómputo como la memoria.
Decisión: Si esperabas multi‑tenancy, tu aislamiento falla (o cargaste pesos dos veces por error). Considera GPUs separadas o slices MIG por servicio.
Task 5: Detectar errores ECC o problemas de memoria a nivel hardware (raro, pero feo)
cr0x@server:~$ nvidia-smi -q -d ECC | sed -n '1,120p'
==============NVSMI LOG==============
ECC Mode
Current : Enabled
Pending : Enabled
ECC Errors
Volatile
Single Bit
Device Memory : 0
Double Bit
Device Memory : 0
Aggregate
Single Bit
Device Memory : 2
Double Bit
Device Memory : 0
Qué significa: Ocurrieron algunos errores corregidos históricamente.
Decisión: Si los contadores suben rápido o ves errores de doble bit, trátalo como riesgo de hardware; drena el nodo y haz que lo revisen.
Task 6: Confirmar topología PCIe / NVLink (ancho de banda y contención)
cr0x@server:~$ nvidia-smi topo -m
GPU0 GPU1 CPU Affinity NUMA Affinity
GPU0 X NV2 0-31 0
GPU1 NV2 X 0-31 0
Qué significa: Las GPUs están conectadas vía NVLink (bueno para sharding/paralelismo).
Decisión: Si planeaste parallelismo tensor entre GPUs, esto lo soporta. Si ves “PHB” o conectividad débil, replantea el sharding o espera latencia.
Task 7: Verificar RAM del host y swap (el paging GPU a menudo arrastra al host)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 503Gi 392Gi 21Gi 11Gi 90Gi 101Gi
Swap: 32Gi 18Gi 14Gi
Qué significa: Swap está siendo usado activamente.
Decisión: Si la memoria gestionada de GPU o el offload a CPU están en juego, la actividad de swap es una bandera roja; reduce presión de memoria o deshabilita/limita rutas de paging.
Task 8: Encontrar OOM relacionados con GPU y errores Xid en logs del kernel
cr0x@server:~$ sudo dmesg -T | grep -E "NVRM|Xid|Out of memory|oom" | tail -n 20
[Tue Jan 21 10:11:22 2026] NVRM: Xid (PCI:0000:3b:00): 13, pid=23144, Graphics Exception
[Tue Jan 21 10:11:23 2026] Out of memory: Killed process 23144 (python3) total-vm:14223312kB, anon-rss:9123456kB
Qué significa: Un error de GPU más el OOM killer del host: mala combinación.
Decisión: Trátalo como incidente de estabilidad: limita la carga, revisa drivers y asegura que el host tenga suficiente RAM si el offloading está habilitado.
Task 9: Confirmar que tu proceso no está derramando tensores silenciosamente al CPU (ejemplo PyTorch)
cr0x@server:~$ python3 - <<'PY'
import torch
print("cuda available:", torch.cuda.is_available())
print("device:", torch.cuda.get_device_name(0))
print("mem allocated:", torch.cuda.memory_allocated()//(1024**2), "MiB")
print("mem reserved:", torch.cuda.memory_reserved()//(1024**2), "MiB")
PY
cuda available: True
device: NVIDIA A100-SXM4-80GB
mem allocated: 61520 MiB
mem reserved: 74240 MiB
Qué significa: Reserved > allocated implica caching del allocator y riesgo potencial de fragmentación.
Decisión: Si reserved sigue subiendo entre peticiones, puede que necesites tunear el allocator, reciclar workers periódicamente o estandarizar shapes.
Task 10: Revisar resumen del allocator de PyTorch por pistas de fragmentación
cr0x@server:~$ python3 - <<'PY'
import torch
torch.cuda.init()
print(torch.cuda.memory_summary(device=0, abbreviated=True))
PY
|===========================================================================|
| PyTorch CUDA memory summary, device ID 0 |
|---------------------------------------------------------------------------|
| CUDA OOMs: 1 | cudaMalloc retries: 0 |
| Memory Allocated: 61.1 GiB | Memory Reserved: 72.5 GiB |
|---------------------------------------------------------------------------|
| Largest block: 512.0 MiB | Total reserved: 72.5 GiB |
|===========================================================================|
Qué significa: Hubo al menos un OOM; el bloque contiguo más grande es 512 MiB.
Decisión: Si tu próxima asignación necesita >512 MiB contiguos, puedes OOM a pesar de tener VRAM “libre”. Soluciona reduciendo buffers temporales máximos, estandarizando shapes o reiniciando workers estratégicamente.
Task 11: Validar endpoint de métricas del model server localmente (latencia vs correlación con memoria)
cr0x@server:~$ curl -s localhost:8000/metrics | grep -E 'gpu_memory|request_latency_seconds_bucket' | head
gpu_memory_used_bytes{gpu="0"} 7.775e+10
request_latency_seconds_bucket{le="0.5"} 8123
request_latency_seconds_bucket{le="1"} 9012
request_latency_seconds_bucket{le="2"} 9401
Qué significa: La memoria usada es alta; la distribución de latencia es visible.
Decisión: Si la latencia empeora conforme gpu_memory_used_bytes sube, estás limitado por presión de memoria; ajusta batching/concurrencia y topes de tokens.
Task 12: Medir distribución de tokens desde logs (proxy para crecimiento de KV cache)
cr0x@server:~$ awk -F' ' '/tokens_in=/{for(i=1;i<=NF;i++) if($i ~ /^tokens_in=/) {split($i,a,"="); print a[2]}}' /var/log/llm-serving/access.log | sort -n | tail -n 10
4096
6144
8192
8192
12288
16384
16384
24576
32768
65536
Qué significa: Tienes entradas extremadamente largas.
Decisión: Si no planeaste esto explícitamente, impone un máximo de tokens de entrada, introduce resumido o enruta peticiones de contexto largo a una tier dedicada de alta VRAM.
Task 13: Verificar configuración MIG (¿la VRAM está particionada como crees?)
cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-SXM4-80GB (UUID: GPU-aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)
MIG 1g.10gb Device 0: (UUID: MIG-aaaaaaaa-bbbb-cccc-dddd-000000000001)
MIG 1g.10gb Device 1: (UUID: MIG-aaaaaaaa-bbbb-cccc-dddd-000000000002)
MIG 2g.20gb Device 2: (UUID: MIG-aaaaaaaa-bbbb-cccc-dddd-000000000003)
Qué significa: La VRAM está partida en múltiples instancias más pequeñas.
Decisión: Si tu modelo apenas cabe en 20 GB, no lo pongas en un slice de 10 GB y esperes que funcione. Redimensiona slices o cambia modelo/cuantización.
Task 14: Revisar throttling de clocks GPU (cargas bound por memoria sufren también por potencia/temperatura)
cr0x@server:~$ nvidia-smi --query-gpu=clocks.current.memory,clocks.max.memory,temperature.gpu,power.draw,power.limit --format=csv
clocks.current.memory [MHz], clocks.max.memory [MHz], temperature.gpu, power.draw [W], power.limit [W]
1215, 1593, 63, 292.15, 400.00
Qué significa: El reloj de memoria está por debajo del máximo.
Decisión: Si consistentemente bajo bajo carga, investiga límites de potencia/termal o políticas admin; podrías estar dejando ancho de banda sin usar.
Task 15: Confirmar consistencia de driver/CUDA en nodos (la varianza causa bugs «funciona en un nodo»)
cr0x@server:~$ (nvidia-smi --query-gpu=driver_version --format=csv,noheader | head -n1; nvcc --version | tail -n 2) 2>/dev/null
555.42
Cuda compilation tools, release 12.5, V12.5.52
Qué significa: Versiones de driver y toolkit visibles.
Decisión: Si los clusters están mezclados, puedes tener comportamiento de allocator/rendimiento distinto y headroom de VRAM inconsistente. Estandariza, o al menos programa cargas por versión de stack.
Segundo chiste corto (y ya): Cuando alguien dice “vamos a aumentar batch”, una GPU empieza a redactar silenciosamente su carta de renuncia.
Tres micro-historias corporativas (todas verdaderas en espíritu)
Micro‑historia 1: El incidente causado por una suposición equivocada
Una empresa SaaS mediana lanzó un “asistente de casos” interno para ingenieros de soporte. El modelo vivía detrás de una puerta API.
El equipo hizo la prueba de carga habitual: tamaño medio de prompt, longitud media de respuesta, concurrencia media. Parecía estar bien.
Lo lanzaron y se fueron a casa siendo adultos responsables.
Dos semanas después, el asistente se hizo popular en el equipo de escalaciones. Las escalaciones significaban tickets largos.
La gente empezó a pegar hilos enteros de correos, logs y capturas (OCRizadas a texto). La media no cambió mucho,
pero la cola se volvió feroz. Una petición cada pocos minutos alcanzaba una longitud de contexto 10–20× mayor que la prueba original.
El sistema no solo se ralentizó. Se vino abajo. El servidor del modelo OOMeó, se reinició y recargó pesos.
Durante la recarga, los health checks fallaron. El gateway marcó la instancia como unhealthy, desplazó tráfico y causó un thundering herd en los pods restantes.
En minutos, una herramienta interna “no crítica” se convirtió en un outage de productividad.
La suposición equivocada no fue “la VRAM es demasiado pequeña”. Fue “la distribución de prompts es estable”. No lo era.
La solución no fue solo comprar GPUs más grandes. Implementaron:
- un tope duro en tokens de entrada con un error amigable
- una cola separada de contexto largo enrutada a un pool de nodos de alta VRAM
- un SLO que rastreaba el conteo de tokens en la cola, no solo la latencia de cola
Después dejaron de discutir si el modelo “cabe”. Empezaron a presupuestar VRAM para colas y recuperación de fallos.
Ese cambio es lo que mantiene tu pager tranquilo.
Micro‑historia 2: La optimización que se volvió en contra
Un equipo fintech ejecutaba scoring de fraude con un modelo acelerado por GPU. Querían reducir p95.
El ingeniero on-call (inteligente y bienintencionado) activó una estrategia de batching más agresiva en el server de modelos.
Los primeros gráficos se veían geniales: menos launches de kernel, mayor throughput, p50 ligeramente mejorado.
Luego llegó el patrón de tráfico real: bursty, multi‑tenant, con un par de clientes enviando vectores de features grandes.
El batcher empaquetó solicitudes con entusiasmo. El uso pico de VRAM subió. No linealmente—por saltos.
Cada vez que un batch incluía varias peticiones grandes, el servicio coqueteaba con el techo de VRAM.
Pronto vieron un nuevo comportamiento: no OOM duro, sino caídas periódicas de latencia.
El framework empezó a hacer asignaciones adicionales, el allocator no encontraba bloques contiguos grandes,
y el sistema pasó tiempo en gestión de memoria en lugar de inferencia.
Su “optimización” había creado un nuevo problema en p99.
El rollback fue inmediato. La solución permanente fue más matizada:
- batch por buckets de shape (o por tokens) en vez de “el que llegue”
- limitar batch por crecimiento predicho de KV, no solo por cuenta de requests
- reservar margen explícito de VRAM (sí, desperdiciar algo) para evitar espirales de muerte del allocator
La lección: las optimizaciones de throughput a menudo gastan VRAM como tarjeta de crédito. El estado de cuenta llega después, con intereses.
Micro‑historia 3: La práctica aburrida pero correcta que salvó el día
Una compañía de medios ejecutaba renderizado por GPU y algo de inferencia ligera en la misma flota. Tenían una regla que nadie amaba:
cada nodo GPU tenía un “archivo de presupuesto VRAM” en config management—uso esperado documentado por servicio
y un porcentaje de headroom requerido para jobs de peor caso.
Era tedioso. Los ingenieros debían actualizar el presupuesto cuando cambiaban resolución, versión de modelo, tokens máximos o habilitaban un nuevo filtro en GPU.
En las revisiones incluían la pregunta: “Muéstrame el delta de VRAM.” La gente puso los ojos en blanco. La gente siempre pone los ojos en blanco ante la prevención.
Luego una actualización de librería de un vendor cambió el comportamiento de memoria. En un subconjunto de cargas, el uso de VRAM aumentó modestamente,
pero la fragmentación empeoró. Los nodos no OOMearon inmediatamente; empezaron a fallar jobs tras unas horas de churn.
Los síntomas eran clásicos: fallos de asignación esporádicos, solo a alta concurrencia, arreglados con reinicio.
Porque tenían presupuestos y políticas de headroom, el blast radius fue limitado.
Los schedulers se negaron a co‑ubicar dos servicios de alto VRAM. Los nodos canary detectaron la regresión antes de que toda la flota se actualizara.
El incidente fue una molestia, no una crisis.
La práctica aburrida: trata la VRAM como una dimensión de capacidad de primera clase, regístrala en config y aplica headroom vía reglas de scheduling.
No hizo a nadie famoso. Sí mantuvo vivas funciones que generan ingresos.
Errores comunes: síntoma → causa raíz → solución
Aquí es donde te digo qué dejar de hacer.
1) Síntoma: “CUDA out of memory” solo cuando el tráfico es alto
Causa raíz: Crecimiento de la caché KV con la concurrencia; dimensionaste para encajar una sola petición.
Solución: Limitar tokens máximos, limitar concurrencia por GPU, adoptar batching consciente de tokens o enrutar peticiones de contexto largo a nodos separados.
2) Síntoma: OOM a pesar de reportar gigabytes libres
Causa raíz: Fragmentación o necesidad de una asignación contigua grande.
Solución: Estandarizar shapes/buckets, reducir buffers de workspace pico, tunear el allocator o reiniciar workers periódicamente (con plan, no pánico).
3) Síntoma: Picos de latencia, baja utilización de GPU, alta utilización de memoria
Causa raíz: Carga limitada por ancho de banda de memoria.
Solución: Usar GPUs con más ancho de banda, aplicar cuantización o kernels que reduzcan tráfico de memoria, aumentar intensidad de cómputo (fusión) o bajar batch si incrementa thrash de memoria.
4) Síntoma: Rendimiento varía mucho entre nodos “idénticos”
Causa raíz: Diferentes versiones de driver/CUDA/framework, particiones MIG distintas o límites térmicos/energéticos diferentes.
Solución: Estandarizar imágenes, aplicar labels de nodo y restricciones de scheduling, y monitorear clocks/estados de potencia.
5) Síntoma: Servicio se degrada lentamente en horas, arreglado con reinicio
Causa raíz: Fuga de memoria en asignaciones GPU o crecimiento de caché del allocator; acumulación de fragmentación.
Solución: Añadir límites de vida por worker, rastrear VRAM a lo largo del tiempo, reproducir con soak tests y fijar versiones de framework hasta verificar.
6) Síntoma: GPU multi‑tenant bien hasta que un equipo despliega
Causa raíz: Falta de aislamiento; un tenant carga pesos extra o aumenta batch size; “vecino ruidoso” roba VRAM.
Solución: Aplicar políticas de asignación GPU: slices MIG, pools dedicados, cuotas por tenant o compartir modelo vía una única capa de serving.
7) Síntoma: Copiar datos a GPU es de repente gran parte de la latencia
Causa raíz: Aumentaron transferencias host↔device; no se usa memoria pinned; preprocesado moved off‑GPU; o ruta NUMA/PCIe subóptima.
Solución: Usar memoria pinned, mover preprocesado a GPU (con cuidado), arreglar afinidad de CPU/NUMA y evitar copias de tensores innecesarias.
8) Síntoma: “Hicimos upgrade a un modelo más grande” y el throughput se desplomó
Causa raíz: El modelo cabe, pero la caché KV y el batching ya no caben a la concurrencia deseada; aumentó la demanda de ancho de banda.
Solución: Recalcula el presupuesto VRAM incluyendo caché KV; baja concurrencia, añade sharding o despliega una variante más pequeña/cuantizada para rutas de alta concurrencia.
Listas de verificación / plan paso a paso
Checklist A: Planificación de capacidad VRAM como adulto
- Define el envelope de la carga: tokens máximos de entrada, tokens máximos de salida, concurrencia objetivo y estallidos esperados de tráfico.
- Presupuesta partidas de VRAM: pesos + caché KV al envelope máximo + buffers temporales + overhead del framework + margen de seguridad.
- Elige una política de headroom: no operes steady‑state por encima de ~80–85% de VRAM si te importan la latencia de cola y la salud del allocator.
- Decide tu “enrutado para colas”: qué pasa con peticiones muy largas—rechazar, truncar, resumir o enrutar a un pool especializado.
- Codifícalo: archivos de config, valores Helm, variables Terraform, lo que uses. Nada de conocimiento tribal.
Checklist B: Configuración de serving que evita dolor auto‑infligido por VRAM
- Limita el batch máximo por tokens/shape, no solo por cuenta de requests.
- Usa bucketing por shape/token para reducir churn del allocator y fragmentación.
- Establece un contexto máximo explícito alineado con necesidades de negocio, no con marketing del modelo.
- Prefiere un único model server compartido por GPU en lugar de múltiples procesos cargando pesos idénticos (cuando el aislamiento lo permite).
- Mide métricas VRAM como señales SLO de primera clase: usado, reservado, fallos de asignación y time‑to‑first‑token bajo carga.
Checklist C: Respuesta a incidentes por fallos relacionados con VRAM
- Confirma: capacidad vs fragmentación vs ancho de banda usando el guion de diagnóstico rápido.
- Mitiga rápidamente: limita tokens, reduce concurrencia, drena vecinos ruidosos, reinicia solo si es necesario.
- Preserva evidencia: captura nvidia-smi, resúmenes del allocator y snapshots de distribución de tokens.
- Arregla a futuro: aplica nuevos topes/enrutados y programa soak tests antes de quitar mitigaciones.
- Post‑incidente: actualiza presupuestos VRAM y control de admisión para que la misma cola no te tumbe de nuevo.
Preguntas frecuentes
1) ¿La capacidad de VRAM es más importante que el cómputo GPU después de 2026?
Para muchas cargas de inferencia, sí—porque no puedes computar lo que no puedes mantener residente.
El cómputo ayuda cuando estás bound por cómputo. Muchas cargas en producción se vuelven bound por memoria primero.
2) Si un modelo cabe en VRAM, ¿por qué sigo obteniendo OOM?
Porque los pesos no son toda la historia. La caché KV crece con contexto y concurrencia, y la fragmentación puede impedir asignaciones grandes aun con memoria “libre”.
3) ¿La cuantización resuelve el problema de VRAM?
Ayuda mucho para los pesos y a veces para la caché KV, pero puede introducir overhead, restricciones de kernel y tradeoffs de precisión.
Trátala como una herramienta, no como una religión.
4) ¿Cuál es la perilla más simple para reducir VRAM inmediatamente?
Limitar tokens máximos (entrada y salida) y reducir la concurrencia por GPU.
Si necesitas freno de emergencia rápido, esos dos son lo más limpio.
5) ¿Es buena idea paginar la caché KV a memoria host?
Puede serlo, si tu tolerancia a latencia y perfil de carga coinciden con el tradeoff.
En muchos servicios en tiempo real, paginar convierte la latencia de cola en una pesadilla. Haz benchmarks con colas reales de producción, no promedios.
6) ¿Cuánto headroom de VRAM debo mantener?
Si te importa la estabilidad: mantén margen significativo. Un objetivo operacional común es ~15–25% libre en picos típicos,
pero el número correcto depende de comportamiento de fragmentación y varianza de peticiones.
7) ¿Debería usar MIG para aislar tenants?
Si tienes vecinos ruidosos y necesidades de aislamiento estrictas, MIG suele valer la pena.
El tradeoff es menor flexibilidad: capacidad varada y menos posibilidad de “tomar prestada” VRAM entre cargas.
8) ¿Por qué “VRAM reserved” difiere de “VRAM allocated”?
Muchos allocators reservan chunks para reutilizarlos por rendimiento. La memoria reservada puede mejorar latencia pero aumenta el pico y el riesgo de fragmentación.
Mide ambas y vigila tendencias a lo largo del tiempo.
9) ¿Discos más rápidos o más RAM del host compensan la VRAM baja?
No de forma fiable. Pueden soportar estrategias de offload, pero el offload suele aumentar la varianza de latencia y añade nuevos modos de fallo.
Usa offload deliberadamente, no como mecanismo de supervivencia.
10) ¿Cuál es el error más común al comprar hardware?
Comprar basándose en “el modelo cabe” en lugar de “el modelo cabe a la concurrencia requerida con contexto máximo, con headroom, y con colas realistas”.
La segunda afirmación es por la que tus clientes pagan.
Conclusión: próximos pasos que sí puedes hacer
La VRAM después de 2026 no es una cifra de ficha técnica. Es una restricción de producción que modela fiabilidad, coste y throughput.
Trátala como tratas los IOPS de disco, conexiones a DB o egress de red: medida, presupuestada y defendida por políticas.
Pasos prácticos:
- Añade métricas VRAM a tus dashboards estándar: usado, reservado, fallos de asignación y conteos de tokens por petición.
- Implementa control de admisión consciente de tokens: limita entradas/salidas y enruta peticiones de contexto largo intencionalmente.
- Ejecuta un soak test con prompts de cola similares a producción, no promedios. Observa la fragmentación durante horas.
- Decide tu modelo de aislamiento: GPU compartida con cuotas estrictas, slices MIG o pools dedicados—y hazlo cumplir.
- Escribe y mantiene un presupuesto VRAM por servicio. Sí, es aburrido. Por eso funciona.