Pequeños modelos consumen grandes presupuestos de GPU mediante preallocación

Los modelos pequeños deberían reducir costes. En la práctica, cuatro instancias vLLM suelen ocupar cuatro GPU, ya que cada motor reserva de antemano la mayor parte de la memoria. El cuello de botella no es la tarjeta. Es la pila de serving.

Lo más importante en resumen

Relacionado:La carga del modelo devora la costosa hora de TPU  /  Kimi K3: cuando la IA construye su propia infraestructura

Cuatro modelos, cuatro tarjetas, un error de concepto

Los informes de FinOps muestran entonces un aumento en los costes de GPU a pesar de los modelos «más pequeños». La historia en el comité directivo suena paradójica. En las métricas de los nodos es algo banal: cuatro procesos, cuatro asignaciones, cuatro facturas. Sin disciplina de empaquetado, la especialización de modelos se convierte en un generador de costes en lugar de en una palanca de ahorro.

Los equipos descomponen la pila de agentes en especialistas: embedding, rerank, extracción estructurada, generación. Cada parte es pequeña. Sin embargo, cada instancia de vLLM o TEI se comporta como si fuera la única propietaria de la GPU. Quien asigna el 90 % de la VRAM al inicio no deja espacio al vecino. El resultado es una multiplicación del hardware a pesar de los «small models».

La inferencia serverless solo resuelve esto aparentemente. Los cold starts de decenas de segundos, que pueden llegar hasta cerca de un minuto, son letales para los rerankers en la ruta de búsqueda. Los warm pools cuestan de nuevo tiempo de inactividad. On-premise o GPU reservadas sin shared serving son la variante cara del mismo problema.

Qué necesita realmente la inferencia compartida

Un proceso de servidor que conozca varios modelos. Carga al primer uso. Evicción LRU cuando la memoria escasea. Nada de dogmas de un proceso por modelo. Proyectos de código abierto y routers de inferencia comerciales apuntan exactamente a esto. El nombre del proyecto es intercambiable. La pregunta arquitectónica sigue siendo: ¿quién controla el scheduler de memoria?

Los equipos de plataforma deberían fijar tres SLO. Primero, la latencia p95 por tipo de herramienta. Segundo, el margen de VRAM bajo carga. Tercero, los euros por millón de tokens en toda la pila mixta, no por modelo individual en condiciones ideales. Sin estas tres cifras, cualquier pedido de GPU sigue siendo una corazonada.

Normas operativas que ahorran dinero

Separad las cargas pesadas de prefill y las pesadas de decode si vuestro hardware lo permite. Modelos en caché para rutas críticas, carga diferida para herramientas secundarias. Nada de despliegues en sombra silenciosos de dos motores completos «solo para probar» en GPU de producción. Observabilidad en eventos de carga de modelos: cada carga es un pico de costes y latencia.

Frente a la ruta de API en la nube, gana el uso compartido en el mismo servidor si el tráfico es estable y los datos permanecen residuales. Frente a un servidor de modelo único, gana el servicio compartido en cuanto más de dos modelos están permanentemente activos. Frente a Kubernetes por pod por modelo, gana un daemon de inferencia con cuotas claras.

Kubernetes suele empeorar el problema cuando cada variante de inferencia se despliega como un deployment propio con solicitud de GPU 1. El planificador ve peticiones de recursos, no solapamiento de modelos. Sin estrategias de plugin de dispositivo y empaquetado específico, surgen islas de VRAM inactivo junto a pods en espera.

Un término medio pragmático para muchos equipos DACH: un pool de nodos de inferencia con un servidor compartido fijo por nodo, precedido de un router ligero. Escalado automático a nivel de nodo, no por pod de modelo. Los modelos especiales de alta QPS pueden permanecer dedicados. lo demás se comparte.

Documentad el peor caso. ¿Qué ocurre si el modelo generador desplaza al reranker? ¿Es aceptable la ruta LRU o necesitáis anclaje para los dos modelos principales? Sin política de anclaje, el primer pico de tráfico se convertirá en un caos de latencia.

Lista de comprobación del lunes

Enumerad todos los procesos de inferencia y sus reclamaciones de VRAM. Buscad pesos base duplicados. Simulad el caso «reranker + generador simultáneos». Si para eso se queman dos tarjetas, no tenéis un problema de capacidad. Tenéis un problema de empaquetado. Resolvedlo antes de hacer el próximo pedido.

Preguntas frecuentes

Fuente de la imagen: generada por IA (julio de 2026)