Vram on lo0 — Blog Técnico

Servir varios modelos en una sola GPU: co-residencia, model-swapping y sleep mode

Thu, 11 Jun 2026 02:40:00 +0000

Esta es la segunda pieza de una serie operativa sobre exprimir un cluster LLM on-premise genérico de 4×H100 SXM 80 GB con NVLink. La hermana Compartir una GPU: time-slicing, MPS y MIG parte la GPU para que varios procesos la usen a la vez; esta parte el problema complementario: tienes más modelos que VRAM y necesitas que convivan en el tiempo, no solo en el espacio. La tercera, El plano de datos del RAG en CPU, saca de la GPU todo lo que no necesita estar; y el asistente soberano end-to-end (cuarta entrega, en preparación) ensambla todo esto detrás de LibreChat y LiteLLM. Aquí asumimos que la VRAM es el recurso escaso y que tener todo cargado a la vez no es opción.

TL;DR

Tienes un LLM de agentes que sirve casi todo el tráfico, uno o dos rerankers para el RAG, un modelo alterno (otra familia, otro idioma, un fine-tune) y, de vez en cuando, un modelo grande para tareas difíciles. Sumados no caben en los 80 GB de una H100. Hay tres maneras de que convivan, y la clave para no confundirlas es entender que son tres estados distintos de dónde viven los pesos:

Co-residencia — varios modelos cargados a la vez en la HBM, si la suma de sus presupuestos de VRAM cabe en la física. Es lo ideal cuando entran: cero latencia de cambio. La trampa: cada motor debe autolimitar su VRAM; si dos motores creen que tienen los 80 GB enteros, el segundo en pedir memoria revienta con OOM. En una GPU compartida por time-slicing, el reparto de tiempo no protege la memoria —los procesos siguen compitiendo por la misma HBM— y este problema empeora (lo vemos en la pieza hermana).
Model-swapping (con llama-swap) — solo uno (o muy pocos) residente a la vez. El proxy mira el campo model de la request y, si toca otro, descarga el actual y carga el pedido. Como solo hay uno dentro, cada modelo puede usar casi toda la GPU. El coste es un cold start completo: segundos desde NVMe local, minutos desde almacenamiento de red. Mezcla motores: expone endpoints OpenAI-compatible incluido /rerank con llama-server sobre GGUF.
Sleep mode de vLLM (--enable-sleep-mode, endpoints /sleep y /wake_up) — el modelo no se descarga, se duerme. Los pesos se aparcan en RAM del host (nivel 1) o se descartan dejando el proceso vivo (nivel 2). El wake es 18–200× más rápido que un cold start porque el proceso sigue vivo y conserva el allocator de CUDA, los CUDA graphs y los kernels JIT compilados —lo único que se reconstruye es el KV-cache, que se descarta al dormir. Requiere RAM suficiente para los pesos dormidos.

El árbol de decisión es corto: ¿caben todos? → co-residencia. ¿No caben, el cambio es poco frecuente y mezclas motores? → llama-swap. ¿Todo es vLLM, hay RAM de sobra y la latencia de wake importa? → sleep mode. ¿Carga sostenida de todos a la vez? → no es swap, es más GPUs o réplicas (ver una grande vs N pequeñas). Este post pone los números a cada uno sobre una H100 de 80 GB.

La analogía: un solo escenario, un solo foco

Imagina un teatro con un único escenario y un solo foco —la GPU. Tienes más actores (modelos) en la compañía que los que caben iluminados a la vez. Hay tres formas de montar la función:

Co-residencia: varios actores pequeños en escena. Si el reparto de esta escena son tres actores menudos —el LLM principal, un reranker, otro reranker—, caben todos bajo el foco al mismo tiempo. El cambio de réplica entre ellos es instantáneo: ya están en escena. Pero el escenario tiene un tamaño fijo; si metes a un cuarto actor corpulento (el modelo grande), no caben y alguien se cae del borde —eso es el OOM.
Model-swapping: el actor se va a casa. Cuando un actor termina su papel, se va a su casa (el disco). Si la escena siguiente lo requiere otra vez, tiene que volver desde casa: vestirse, maquillarse, llegar al teatro. Eso son minutos. A cambio, mientras está en escena tiene todo el escenario para él. Es el modelo de llama-swap: máxima VRAM por actor, pero la reentrada cuesta un viaje completo.
Sleep mode: el actor espera entre bambalinas. En vez de irse a casa, el actor sale de la luz del foco pero se queda entre bastidores (la RAM del host), ya vestido y maquillado. Cuando le toca, entra en dos pasos. No hay viaje, no hay vestuario: solo cruzar la cortina. Ese es el wake de vLLM: los pesos no vuelven del disco sino de la RAM, y todo lo que se tarda en “preparar al actor” —el allocator, los CUDA graphs, los kernels— ya está hecho porque nunca se fue del edificio.

La moraleja operativa es la misma que en el teatro: el coste de un actor no es solo su talento, es cuánto tarda en entrar a escena cuando lo necesitas. Co-residencia paga el sitio permanente; swap paga el viaje; sleep paga la RAM de tenerlo esperando cerca. El resto del post es elegir cuál, con presupuesto de VRAM y reloj en mano.

Los tres estados: dónde viven los pesos

Co-residencia: el presupuesto de VRAM

Co-residir es la opción por defecto cuando caben: cero latencia de cambio porque todos los modelos están ya en la HBM. La pregunta entera es ¿caben?, y se responde con un presupuesto de VRAM. La VRAM de un motor de inferencia se reparte, a grandes rasgos, en tres partidas:

$$\text{VRAM}{\text{modelo}} = \underbrace{P \cdot b}{\text{pesos}} + \underbrace{\text{KV}}{\text{caché}} + \underbrace{A}{\text{activaciones + overhead}}$$

donde $P$ es el número de parámetros, $b$ los bytes por parámetro según la cuantización, KV el presupuesto de KV-cache (que escala con concurrencia y longitud de contexto) y $A$ el overhead de activaciones, buffers de CUDA y fragmentación. La regla dura de la co-residencia es:

$$\sum_i \text{VRAM}{\text{modelo } i} + \text{margen} ;<; \text{VRAM}{\text{física}}$$

Si la suma se pasa, no hay reparto que valga: el primer motor que pida memoria por encima del hueco libre muere con OOM. Y aquí está el matiz crítico que conecta con la pieza hermana: partir la GPU por tiempo no parte la memoria. En time-slicing, dos procesos se turnan el cómputo pero comparten la HBM entera sin aislamiento; si ambos asumen que tienen los 80 GB, chocan. Solo MIG da particiones de memoria con frontera real (lo vemos en Compartir una GPU). Para co-residir bien, cada motor debe autolimitarse: en vLLM, --gpu-memory-utilization 0.45 le dice “no uses más del 45 % de la GPU”; en llama-server, controlas las capas en GPU y el tamaño de KV. Si no pones esos límites, vLLM reclama por defecto el 90 % de la GPU para sí solo, y no queda sitio para nadie más.

Ejemplo numérico: qué cabe en 80 GB

Pongamos el escenario realista. Un LLM de agentes de 32B en FP8 ($b = 1$ byte/parám):

$$P \cdot b = 32 \times 10^9 \cdot 1 \text{ B} = 32 \text{ GB de pesos}$$

A eso hay que sumarle KV-cache. Para servir con concurrencia decente y contextos de agente (que son largos: historial, herramientas, documentos), un presupuesto de KV de ~12 GB es razonable, más unos ~2 GB de activaciones y overhead. Total del LLM principal: ~46 GB. Quedan ~34 GB de los 80. Veamos qué entra ahí:

Servicio	Tamaño (FP8/INT8)	KV + overhead	VRAM total
LLM agentes 32B	32 GB	~14 GB	~46 GB
Reranker A (cross-encoder ~0.5B)	~0,5 GB	~0,5 GB	~1 GB
Reranker B (cross-encoder ~0.5B)	~0,5 GB	~0,5 GB	~1 GB
Modelo alterno 8B	~8 GB	~4 GB	~12 GB
Suma			~60 GB
Margen libre			~20 GB

Con esto, co-residen perfectamente: el LLM de 32B, los dos rerankers (que son ligerísimos —cientos de MB a 1 GB cada uno) y hasta un alterno de 8B, dejando 20 GB de colchón. Los rerankers son el caso de manual de co-residencia: tan pequeños que siempre caben junto al LLM principal, y rotarlos sería absurdo. El cambio de unos a otros es instantáneo porque están todos cargados.

¿Cuándo se rompe? Cuando entra el modelo grande ocasional, un 70B en FP8:

$$70 \times 10^9 \cdot 1 \text{ B} = 70 \text{ GB de pesos}$$

Solo los pesos del 70B ya consumen 70 de los 80 GB. No hay forma de co-residirlo con el 32B —ni de lejos—. Ahí termina la co-residencia y empieza la rotación: el 70B solo puede entrar si echamos al 32B de la GPU. Esa es la frontera exacta: co-residir mientras la suma de presupuestos quepa con margen; rotar en cuanto un modelo necesite, él solo, más VRAM de la que sobra.

Model-swapping con llama-swap: el actor se va a casa

Cuando no caben a la vez, la primera respuesta es rotar: tener un solo modelo residente y cambiarlo bajo demanda. La herramienta canónica para esto en el mundo on-premise es llama-swap: un proxy en Go que se pone delante de tus servidores de inferencia (llama.cpp, vLLM, TabbyAPI…) y los arranca y para según haga falta.

El mecanismo es elegante por lo simple. Cada request OpenAI-compatible lleva un campo model. llama-swap lee ese campo, mira qué servidor upstream tiene configurado para ese modelo, y:

Si el modelo pedido ya está cargado, enruta la request directamente.
Si está cargado otro, lo para (libera su VRAM) y arranca el correcto.
Cuando el nuevo servidor responde “listo”, reenvía la request.

El coste de un swap es exactamente un cold start completo del modelo nuevo: descargar el actual (rápido, liberar memoria) más cargar el nuevo (lento, mover los pesos del disco a la HBM). Ese segundo término es el que duele, y su magnitud la decide dónde están los pesos: desde NVMe local son segundos; desde almacenamiento de red (Ceph RGW, NFS) pueden ser minutos. Todo el análisis del camino de carga —y por qué el loader por defecto lo hace lento— está en Del disco a la HBM; aquí basta la consecuencia: un swap solo es viable si es infrecuente, porque cada cambio paga ese peaje entero.

La ventaja a cambio: como solo hay uno residente, ese modelo puede usar casi toda la GPU. El 70B que no co-reside con nadie sí cabe holgado si es el único dentro. Y llama-swap mezcla motores: puedes tener configurado un vLLM para el LLM grande, un llama-server con GGUF para el alterno, y dos llama-server para los rerankers —que exponen /rerank, /v1/rerank y /v1/reranking de forma nativa—. Esa heterogeneidad (GGUF + rerank + vLLM bajo un solo endpoint OpenAI) es justo lo que vLLM solo no te da, y la razón principal para elegir llama-swap.

ConfigMap de ejemplo: dos rerankers que rotan en el mismo puerto

Un caso concreto y útil: tienes dos rerankers —uno multilingüe y uno especializado en código— que no necesitas a la vez y prefieres no tener ambos residentes. Con llama-swap rotan en el mismo endpoint, disparados por el campo model. El ConfigMap (montado como config.yaml del proxy en un despliegue de Kubernetes) sería:

apiVersion: v1
kind: ConfigMap
metadata:
 name: llama-swap-rerankers
data:
 config.yaml: |
 # Tiempo que un modelo sigue cargado tras la última request
 # antes de que llama-swap lo descargue para liberar VRAM
 healthCheckTimeout: 60

 models:
 # Reranker multilingüe (GGUF, vía llama-server)
 "reranker-multilang":
 cmd: >
 /usr/bin/llama-server
 --model /models/bge-reranker-v2-m3.Q8_0.gguf
 --reranking
 --port ${PORT}
 --n-gpu-layers 99
 --ctx-size 8192
 # ttl: tras 300 s ocioso, se descarga y libera la GPU
 ttl: 300

 # Reranker de código (GGUF, vía llama-server)
 "reranker-code":
 cmd: >
 /usr/bin/llama-server
 --model /models/codereranker.Q8_0.gguf
 --reranking
 --port ${PORT}
 --n-gpu-layers 99
 --ctx-size 8192
 ttl: 300

Una request a /v1/rerank con "model": "reranker-multilang" arranca ese servidor; la siguiente con "model": "reranker-code" para el multilingüe y arranca el de código en el mismo ${PORT} que llama-swap gestiona. Como ambos son pequeños, el swap entre ellos es de uno o dos segundos —los GGUF cuantizados pesan pocos cientos de MB y vienen de NVMe local—. El ttl controla cuánto sigue cargado un modelo tras su última petición: subirlo evita swaps si las peticiones llegan a ráfagas; bajarlo libera la GPU antes para otros usos.

Matiz honesto: este patrón de dos rerankers que rotan tiene sentido cuando no te caben junto al resto, o cuando quieres reservar la VRAM para otra cosa. Si te caben (y un par de rerankers de 0,5 GB caben casi siempre, como vimos arriba), co-residirlos es estrictamente mejor: cero latencia de swap. llama-swap brilla cuando rotas modelos grandes o cuando mezclas motores que no coexisten bien, no para hacer malabares con modelos diminutos que cabrían juntos.

vLLM sleep mode: el actor entre bambalinas

El swap tiene un problema: cada cambio paga el cold start entero, y un cold start no es solo mover pesos. Como vimos en Del disco a la HBM, arrancar un motor de inferencia incluye inicializar el proceso de Python y el contexto CUDA, montar el allocator de memoria, capturar los CUDA graphs y compilar los kernels JIT (DeepGEMM, FlashInfer, TorchInductor). Mover los pesos es solo una de cinco partidas, y a menudo no la mayor.

El sleep mode de vLLM (--enable-sleep-mode) ataca exactamente eso: en vez de matar el proceso cuando un modelo deja de usarse, lo duerme dejando el proceso vivo. Hay dos niveles, y la diferencia es dónde van los pesos:

Nivel 1: descarga los pesos a la RAM del host (CPU) y descarta el KV-cache. El proceso sigue vivo. El wake copia los pesos de RAM a VRAM —no del disco—. Wake típico: ~0,1–0,8 s para modelos pequeños, ~3–6 s para grandes. Necesita RAM suficiente para los pesos dormidos (del orden de los GB que pesa el modelo).
Nivel 2: descarta los pesos por completo, conservando solo buffers pequeños (tensores de rope scaling, etc.). El wake sí recarga los pesos del disco, pero todo lo demás —proceso, allocator, CUDA graphs, kernels JIT— ya está hecho. Wake típico: ~0,8–2,6 s para modelos pequeños. RAM casi nula (megabytes).

La clave que explica los números: en ambos niveles, mantener el proceso vivo preserva la infraestructura cara. Por eso el benchmark del blog de vLLM (oct 2025) reporta que un wake es 18–200× más rápido que un full reload —y, lo más contraintuitivo, el nivel 2 sigue siendo 23–45× más rápido que un cold start a pesar de recargar los pesos del mismo disco, porque se salta las otras cuatro partidas—. En sus medidas sobre A100, un ciclo completo de 5 cambios de modelo pasa de 357 s sin sleep (≈48 s por cambio) a 112 s con nivel 1 (wake de 0,26 s / 0,82 s) o 125 s con nivel 2 (0,85 s / 2,58 s).

El KV-cache se descarta siempre al dormir. No es un detalle menor: significa que la primera respuesta tras el wake reconstruye el KV desde cero —paga un prefill completo—. Por eso el wake no es “gratis del todo”: el modelo está disponible en sub-segundo, pero la primera petición es un poco más lenta hasta que el KV se repuebla. Un warm-up de una petición tras el wake oculta ese coste.

# Arrancar vLLM con sleep mode (endpoints de admin, solo red de confianza)
export VLLM_SERVER_DEV_MODE=1
vllm serve <modelo> --enable-sleep-mode --port 8001

# Dormir (nivel 1: pesos a RAM del host)
curl -X POST 'localhost:8001/sleep?level=1'

# Despertar
curl -X POST 'localhost:8001/wake_up'

Aviso de seguridad (del propio blog de vLLM): los endpoints /sleep, /wake_up, /collective_rpc y /reset_prefix_cache requieren VLLM_SERVER_DEV_MODE=1 y solo deben exponerse en redes de confianza —pueden tumbar el servicio—. Son para orquestación interna (un controlador que duerme y despierta modelos según la cola), no para el plano público.

Las matemáticas de la latencia: por qué el wake gana

Pongamos números al “el wake llega de RAM, no de disco”. El coste de tener un modelo disponible es, en cada estrategia, el tiempo de mover sus pesos desde donde estén hasta la HBM (más, en swap, los otros cuatro costes del cold start). Tomemos los 34 GB de pesos del LLM de 32B en FP8 y comparemos los tres caminos.

Cold start desde NVMe (swap). Un NVMe Gen4/Gen5 razonable da del orden de ~5 GB/s efectivos por flujo con el loader por defecto (el suelo teórico del disco es mayor, pero el deserializado monohilo no lo satura —ver Del disco a la HBM). Para 34 GB:

$$t_{\text{NVMe→HBM}} \approx \frac{34 \text{ GB}}{5 \text{ GB/s}} \approx 6,8 \text{ s solo de mover bytes}$$

Y eso es antes de sumar la captura de CUDA graphs y la compilación de kernels, que añaden varios segundos más. El cold start real de un 32B ronda los 15–40 s según loader y storage. Desde red (Ceph RGW), multiplica.

Wake nivel 1 desde RAM. Los pesos no vienen del disco sino de la RAM del host, y viajan por PCIe Gen5 x16, cuyo ancho de banda práctico host→GPU es de ~50–64 GB/s. Para los mismos 34 GB:

$$t_{\text{RAM→HBM}} \approx \frac{34 \text{ GB}}{55 \text{ GB/s}} \approx 0,62 \text{ s}$$

Y no hay nada más que pagar: el allocator, los graphs y los kernels ya están. El wake real de un modelo de este tamaño cae en el rango sub-segundo a pocos segundos que reporta vLLM. La aceleración frente al cold start de NVMe es del orden de:

$$\frac{t_{\text{cold start}}}{t_{\text{wake}}} \approx \frac{15\text{–}40 \text{ s}}{0,6\text{–}3 \text{ s}} \approx 10\text{–}60\times$$

consistente con el 18–200× del blog (que en sus medidas incluye modelos más pequeños, donde el peso relativo de los CUDA graphs preservados es aún mayor y el factor sube).

Por qué la diferencia de ancho de banda lo explica casi todo. El salto clave no es 5 vs 55 GB/s (un ~11× en el transporte). Es que el cold start paga además la reconstrucción de infraestructura, que el wake se ahorra entera. La tabla:

Camino	Origen pesos	Ancho de banda	34 GB solo bytes	+ CUDA graphs / JIT	Total realista
Cold start (swap) NVMe	disco	~5 GB/s	~6,8 s	sí (varios s)	15–40 s
Cold start (swap) red	red	~1–2 GB/s	17–34 s	sí	30 s – min
Wake nivel 1	RAM host	~50–64 GB/s	~0,6 s	no (preservado)	0,6–3 s
Wake nivel 2	disco	~5 GB/s	~6,8 s	no (preservado)	7–10 s

Fíjate en la fila del nivel 2: recarga los pesos del mismo disco que el swap (~6,8 s de bytes), pero como no reconstruye graphs ni kernels, su total (~7–10 s) sigue batiendo al cold start completo (15–40 s). Es la prueba de que mover bytes es solo una parte del coste, y la que el sleep mode explota.

Supuestos, honestamente: los anchos de banda son orientativos. NVMe “5 GB/s efectivos” asume el loader por defecto; con un streamer concurrente sube. PCIe “55 GB/s” asume Gen5 x16 con buffer pinned y NUMA-local; si el buffer cae en el socket equivocado, baja. Y el rango “15–40 s” de cold start depende del modelo, la cuantización y si los ficheros están o no en page cache (la trampa del “la segunda vez cargó rápido”). Los números son para razonar órdenes de magnitud, no para dimensionar sin medir en tu hardware.

El árbol de decisión

Las tres estrategias no compiten: cada una gana en un régimen distinto. El árbol, en orden:

El nodo que más se ignora es el de la derecha arriba: "¿carga sostenida de todos a la vez?". Si tus cuatro modelos reciben tráfico constante y simultáneo, ni el swap ni el sleep ayudan —ambos asumen que los modelos se turnan en el tiempo—. Rotar bajo carga sostenida solo añade latencia de cambio sin resolver el problema de fondo: no hay suficiente cómputo. La respuesta entonces es escalar horizontal (más réplicas) o repartir en más GPUs, una decisión de capacidad que se analiza en Una grande vs N pequeñas. El swap y el sleep son herramientas para cargas temporalmente desbalanceadas: muchos modelos, pero rara vez activos a la vez.

Aplicado al cluster genérico 4×H100

Bajemos esto a las 4 H100 SXM de 80 GB con NVLink. La estrategia ganadora no es elegir una de las tres, sino repartir los modelos por GPU según su patrón de uso y aplicar a cada GPU la estrategia que le toca. Un reparto razonable:

H100 #0 — El caballo de batalla (co-residencia). El LLM de agentes de 32B (servicio principal, tráfico constante) co-reside con los dos rerankers y, si caben, el alterno de 8B. Es la GPU que nunca rota: todo lo que vive aquí se usa de continuo y entra holgado en 80 GB (los ~60 GB del ejemplo de arriba). Cero latencia de cambio entre el LLM y sus rerankers, que es justo lo que el RAG necesita —un reranker rápido es inútil si hay que esperar un swap cada vez—.

H100 #1 — Servicios ligeros con MIG. Si tienes muchos servicios pequeños heterogéneos —un modelo de embeddings, un clasificador, un guardrail, un STT/TTS—, partir esta GPU con MIG en instancias aisladas (cada una con su trozo de HBM con frontera real) da co-residencia con aislamiento de memoria, evitando que un servicio que infla su KV tumbe a los demás. El detalle de cuándo MIG bate a time-slicing está en Compartir una GPU; la regla aquí: co-residir servicios ligeros en una GPU tiene sentido cuando caben y conviene aislarlos, y MIG es la herramienta para lo segundo.

H100 #2 — El modelo grande ocasional (sleep mode o swap). El 70B que solo se invoca para tareas difíciles no merece una GPU dedicada despierta —estaría ociosa la mayor parte del tiempo, quemando 700 W para nada—. Dos opciones:

Si esta GPU también sirve un modelo mediano de forma habitual y solo eventualmente necesitas el 70B, usa sleep mode: duerme el mediano (nivel 1, pesos a RAM), despierta el 70B… salvo que el 70B no quepa ni solo despierto junto al mediano dormido en VRAM —recuerda que dormir nivel 1 libera la VRAM, los pesos van a RAM, así que sí cabe—. El wake del mediano al volver es sub-segundo.
Si el 70B viene en GGUF o mezclas motores, llama-swap rota entre el mediano y el 70B por el campo model. Cada invocación del 70B paga su cold start (segundos desde NVMe local), aceptable si es ocasional.

H100 #3 — Réplica / desbordamiento. La cuarta GPU absorbe picos: una réplica del LLM principal para cuando la cola del #0 crece, o capacidad de reserva. Aquí no hay swap: es capacidad pura, la respuesta al nodo “carga sostenida” del árbol.

El principio transversal: co-residir lo que se usa junto y de continuo (LLM + rerankers); aislar con MIG lo ligero y heterogéneo; dormir o rotar lo grande y ocasional; replicar lo que satura. Las cuatro GPUs no hacen lo mismo —cada una ejecuta la estrategia que su patrón de carga pide—. Y el NVLink entre ellas importa para otra cosa (tensor parallel del 70B si no cupiera ni en una; ver Una grande vs N pequeñas), pero para el problema de este post —muchos modelos, una GPU— la palanca es cuándo cada modelo necesita estar despierto.

Trampas y cosas que no son lo que parecen

“Co-residir es siempre mejor si caben.” Casi, pero ojo al KV-cache: co-residir dos modelos significa partir el presupuesto de KV entre ambos. Si el LLM principal necesita un KV grande para concurrencia alta y contextos largos, meterle un compañero le recorta ese KV y baja su throughput. A veces es mejor darle la GPU entera al principal y rotar el secundario. Co-residir no es gratis: el inquilino le quita sitio a la caché del que importa.

“El sleep mode es como el swap pero más rápido.” No exactamente. El swap libera el proceso; puedes tener N modelos configurados y solo pagas RAM/disco por el residente. El sleep mode mantiene un proceso vivo por modelo dormido —cada vLLM dormido sigue ocupando su slot de proceso, su RAM (nivel 1) y su hueco de gestión—. Sleep escala bien a unos pocos modelos que rotan; para muchos (10+), nivel 2 (RAM mínima) o directamente swap encajan mejor. No metas 15 modelos en sleep nivel 1 esperando que la RAM aguante.

“El wake es instantáneo, no pierdo nada.” El wake del modelo es sub-segundo, pero el KV-cache se descartó al dormir. La primera petición tras el wake paga un prefill completo para repoblar el KV —más lenta de lo normal—. Si tu SLA es estricto en la primera respuesta tras un período ocioso, mete un warm-up automático tras el wake. El prefix caching ayuda a que ese reprefill sea más barato si hay prefijos estables.

“llama-swap con ttl bajo me ahorra VRAM gratis.” Te ahorra VRAM mientras nadie use ese modelo, pero cada vez que vuelve paga el cold start. Un ttl agresivo en un modelo con tráfico a ráfagas convierte cada ráfaga en una espera de carga. El ttl correcto depende del patrón temporal de las peticiones, no de cuánta VRAM quieres liberar. Mídelo.

“Time-slicing me deja co-residir más modelos.” Falso y peligroso. El time-slicing reparte tiempo de cómputo, no memoria —todos los procesos siguen compitiendo por la misma HBM sin aislamiento—. Co-residir vía time-slicing no te da más VRAM efectiva; te da más procesos peleándose por la misma, y un OOM cuando la suma se pasa. Para partición de memoria real, MIG. El detalle, en la pieza hermana.

Conclusión

Tener más modelos que VRAM no es un problema de hardware insuficiente: es un problema de gestión temporal de un recurso escaso. La intuición de “necesito una GPU por modelo” es cara y casi siempre falsa, porque los modelos rara vez se usan todos a la vez. Las tres estrategias son tres respuestas a la misma pregunta —dónde viven los pesos de los modelos que ahora no estás usando—: en la HBM si caben (co-residencia, cero latencia pero cuestan sitio), en el disco si el cambio es raro (swap, máxima VRAM por modelo pero un viaje de vuelta de segundos a minutos), o en la RAM si la latencia de cambio importa (sleep mode, wake de sub-segundo a costa de tener la RAM ocupada). El sleep mode es la incorporación más interesante de 2025 porque rompe el falso dilema “todo cargado vs recargar cada vez”: al mantener el proceso vivo y preservar el allocator, los CUDA graphs y los kernels, convierte un cold start de 30–100 s en un wake de menos de un segundo —y lo hace incluso cuando recarga los pesos del mismo disco (nivel 2), porque mover bytes nunca fue el coste entero—. En el cluster de cuatro H100, la jugada no es elegir una estrategia sino repartir: co-residir lo que va junto, aislar lo ligero con MIG, dormir o rotar lo grande y ocasional, replicar lo que satura. La GPU es el escenario con un solo foco; el arte está en saber qué actor entra a escena, cuál se va a casa y cuál espera entre bambalinas.

Ver también

Acelerar el cold start de modelos: de minutos a segundos — cómo bajar el coste del cold start que paga cada swap.
Compartir una GPU: time-slicing, MPS y MIG — la pieza hermana: cómo repartir una GPU entre varios procesos en el espacio (no en el tiempo). Clave aquí para entender por qué el time-slicing no protege la memoria y por qué MIG es lo que da co-residencia con aislamiento real de HBM.
Del disco a la HBM: el cold start y la carga del modelo — el camino de carga que el swap paga entero en cada cambio y que el sleep mode esquiva; por qué mover bytes es solo una de cinco partidas del arranque.
Multi-LoRA serving: fundamentos — la alternativa cuando los “varios modelos” son adaptadores del mismo base: en vez de rotar modelos enteros, sirves muchos LoRA sobre un base co-residente sin coste de swap.
Ingeniería del prefix cache hit rate — el KV-cache se descarta al dormir; un buen hit rate de prefijos estables abarata el reprefill de la primera petición tras el wake.
Una grande vs N pequeñas: tensor parallel y réplicas — la rama “carga sostenida de todos a la vez” del árbol: cuando rotar no basta y hay que repartir en más GPUs o réplicas.
Entornos mixtos NVIDIA / Intel: servidores y NUCs — dónde colocar los servicios ligeros (rerankers, embeddings) que no necesitan una H100: a veces co-residir no es en la GPU grande sino en hardware más modesto.

Referencias

vLLM Blog (Embedded LLM), Zero-Reload Model Switching with vLLM Sleep Mode, 26 oct 2025: https://blog.vllm.ai/2025/10/26/sleep-mode.html
vLLM Docs, Sleep Mode: https://docs.vllm.ai/en/latest/features/sleep_mode/
mostlygeek, llama-swap (proxy de model-swapping OpenAI/Anthropic-compatible): https://github.com/mostlygeek/llama-swap
llama-swap, Configuration: https://github.com/mostlygeek/llama-swap/blob/main/docs/configuration.md
NVIDIA, H100 Tensor Core GPU (especificaciones HBM3, 80 GB, ~3,35 TB/s): https://www.nvidia.com/en-us/data-center/h100/
NVIDIA, Reducing Cold Start Latency for LLM Inference with NVIDIA Run:ai Model Streamer: https://developer.nvidia.com/blog/reducing-cold-start-latency-for-llm-inference-with-nvidia-runai-model-streamer/

Compartir una GPU entre varias cargas: time-slicing, MPS y MIG

Thu, 11 Jun 2026 02:00:00 +0000

Este post abre una serie operativa sobre cómo exprimir un cluster LLM on-premise genérico de 4×H100 SXM. Las piezas hermanas: Servir varios modelos en una GPU: swap y sleep (qué hacer cuando los modelos no caben a la vez y hay que turnarlos en memoria), RAG en CPU: separar plano de datos y generación (mover el retrieval fuera de la GPU para liberarla) y Asistente soberano end-to-end con LibreChat, LiteLLM y RAG —el ensamblaje final, cuarta entrega en preparación—. Aquí empezamos por lo más básico: tienes una GPU y quieres meterle varias cargas encima. ¿Cómo se reparte?

TL;DR

Tienes una GPU —o pocas— y varias cargas que quieren correr encima: un modelo de chat, un servicio de embeddings, un reranker, una cola de jobs de dev. La GPU está infrautilizada si solo corre una cosa, pero meter varias a lo bruto provoca contención, OOM o caídas en cascada. Hay tres mecanismos y reparten cosas distintas. El time-slicing (réplicas del NVIDIA k8s device-plugin) multiplexa en el tiempo: anuncia que la GPU es “N GPUs” y los procesos se turnan el cómputo, pero comparten la VRAM física completa, sin aislamiento de memoria ni de fallos ni QoS. Su trampa es un OOM que no aparece en el scheduler de Kubernetes sino en tiempo de ejecución, cuando la suma de asignaciones de VRAM supera la memoria real. El MPS (Multi-Process Service) multiplexa en el espacio: reparte los SMs entre procesos que ejecutan kernels concurrentemente, reduce el overhead de context-switch y permite limitar SMs y memoria por proceso —sube el throughput cuando hay muchos kernels pequeños, pero el aislamiento de fallos sigue siendo débil. El MIG (Multi-Instance GPU) particiona en hardware: corta la GPU Hopper en hasta siete instancias con SMs, L2, memoria y ancho de banda dedicados, con aislamiento real de memoria, fallo y rendimiento; solo en datacenter (A100/H100/H200/B200), nunca en una RTX 5090. La regla: aislamiento real / multi-tenant / compliance → MIG (si es Hopper); muchos kernels pequeños concurrentes y confianza entre cargas → MPS; dev, ráfagas, GPU de consumo o sin necesidad de aislar → time-slicing. Este post lo trabaja con números: el presupuesto de VRAM de cuatro vLLM sobre una H100 anunciada como cuatro réplicas, y qué cabe en una instancia MIG de 10 GB.

La analogía: un fogón compartido, una cocina con varios cocineros, varias cocinas

Imagina que tienes un único fogón profesional y tres pedidos que cocinar a la vez. Hay tres maneras de organizarlo, y son exactamente los tres mecanismos.

Time-slicing es un solo fogón por turnos, sin despensa propia. Cada cocinero entra, cocina su plato, sale, entra el siguiente. El reparto es temporal: nadie cocina a la vez, se turnan. El problema no es el fogón —se va turnando bien— sino la despensa común: los ingredientes están en una sola alacena compartida y nadie tiene la suya. Si los tres cocineros reservan más harina de la que hay en total, no es que esperen turno: es que no hay harina. El servicio se cae para todos. Y si un cocinero deja una sartén ardiendo y provoca un incendio, quema la cocina entera, no su rincón.

MPS son varios cocineros coordinados en la misma encimera. Ahora sí cocinan a la vez, repartiéndose el espacio de la encimera (los SMs). Un jefe de cocina (el daemon MPS) coordina para que no choquen y para que la encimera no se quede vacía mientras uno espera a que hierva el agua. Puedes asignarle a cada cocinero un porcentaje de la encimera y un límite de despensa. Trabajan más rápido en conjunto porque la encimera no queda ociosa entre tareas pequeñas. Pero siguen compartiendo la cocina: si uno provoca un incendio grave, los demás lo notan.

MIG son varias cocinas independientes en el mismo edificio. Una pared de hormigón separa cada cocina: su propio fogón, su propia despensa, su propia puerta y su propio cuadro eléctrico. Lo que pasa en la cocina 3 —un incendio, una despensa vacía, un cocinero lento— no toca a la cocina 1. Es el único reparto con aislamiento de verdad. El precio: tienes que decidir de antemano cuántas cocinas y de qué tamaño, las paredes son fijas, y solo los edificios caros (datacenter) vienen preparados para levantarlas.

El resto del post es, esencialmente, cuándo quieres turnos baratos, cuándo quieres cocineros coordinados y cuándo necesitas paredes de hormigón.

Por qué compartir: el problema operativo

Una H100 SXM 80 GB no se llena con cualquier carga. Un reranker bge-reranker-v2-m3 ocupa unos cientos de MB y satura unos pocos SMs; un servicio de embeddings bge-m3 es igual de pequeño; un modelo guardrail de 1B en INT4 cabe en un par de GB. Dedicar 80 GB de HBM3 y 132 SMs a servir embeddings es usar una prensa hidráulica para clavar una chincheta —el mismo argumento de los entornos mixtos, pero ahora dentro de la GPU en lugar de moviendo la carga a otro silicio.

El objetivo de compartir es subir la utilización útil del capital fijo. Pero compartir mal introduce tres patologías:

Contención de cómputo: dos cargas pelean por los mismos SMs y ambas van lentas, con jitter de latencia impredecible.
Contención de memoria: la suma de VRAM solicitada supera la física y algo muere con un CUDA out of memory.
Fallo en cascada: una carga que peta (un kernel ilegal, un OOM) puede arrastrar a las vecinas si comparten contexto.

Los tres mecanismos atacan estas patologías con distinta profundidad. Ninguno las resuelve todas salvo MIG, y MIG cuesta hardware concreto. Veámoslos uno a uno.

Time-slicing: turnos de cómputo, despensa compartida

El time-slicing es multiplexación temporal por software. En Kubernetes, el NVIDIA GPU Operator configura el device-plugin para anunciar N réplicas de cada GPU física. Una H100 declarada con replicas: 4 aparece ante el scheduler como cuatro recursos nvidia.com/gpu, y Kubernetes puede colocar cuatro pods sobre ella. Internamente, el planificador de la GPU va dando turnos de cómputo a cada proceso: ejecuta un poco del proceso A, cambia al B, al C, al D, vuelve al A. Es el mismo time-sharing que un sistema operativo hace con la CPU.

La idea clave, y la que más confusión genera, es esta: una réplica NO es una fracción de la GPU. Es un turno de cómputo. La documentación de NVIDIA es explícita: a diferencia de MIG, no hay aislamiento de memoria ni de fallos entre réplicas. Las cuatro réplicas de la H100 ven los 80 GB completos de VRAM, sin partición. No hay 20 GB por réplica. Hay 80 GB para los cuatro, repartidos por orden de llegada de cudaMalloc.

Esto tiene tres consecuencias que hay que interiorizar:

No aísla memoria. Si la suma de lo que reservan los cuatro procesos supera 80 GB, el cuarto cudaMalloc falla con OOM. El scheduler de Kubernetes no lo ve venir: él contó cuatro recursos nvidia.com/gpu disponibles y colocó cuatro pods felizmente. El OOM aparece en tiempo de ejecución, no en scheduling. Esta es la trampa número uno del time-slicing.
No aísla fallos. Un proceso que dispara un error de CUDA irrecuperable puede dejar el contexto de la GPU en un estado que afecta a los vecinos. Comparten el mismo dispositivo sin barreras.
No da QoS de cómputo. Bajo contención, el reparto de turnos no garantiza una fracción mínima a nadie. La latencia de cada carga sufre jitter proporcional a cuántas réplicas activas peleen por la GPU en ese instante. Una carga sensible a latencia (un chat interactivo) puede ver su TTFT bailar según lo que hagan las vecinas.

¿Para qué sirve entonces? Para dev, ráfagas y baja utilización. Si tienes cuatro desarrolladores que tocan la GPU esporádicamente, anunciar cuatro réplicas deja que los cuatro tengan acceso sin pelearse casi nunca (rara vez coinciden activos). Para cargas batch tolerantes a jitter. Y, ventaja decisiva, funciona en GPUs de consumo: una RTX 5090 32 GB no soporta MIG, pero sí time-slicing. Es la única forma “Kubernetes-native” de compartir una 5090 entre varios pods.

El presupuesto de VRAM en time-slicing (el cálculo que evita el OOM)

Aquí está la matemática que hay que hacer antes de desplegar, porque Kubernetes no la hará por ti. Supongamos una H100 80 GB anunciada como 4 réplicas y queremos correr cuatro instancias de vLLM encima, una por réplica.

vLLM reserva memoria con el parámetro --gpu-memory-utilization, que es la fracción de la VRAM física total que cada instancia se queda (para pesos del modelo más KV-cache). El detalle que mata: esa fracción se calcula sobre los 80 GB físicos, no sobre un supuesto “20 GB de mi réplica” —porque la réplica no tiene 20 GB, recordemos que no hay partición de memoria. Cada vLLM ve los 80 GB y reserva su fracción de ellos.

La restricción de no-OOM es entonces que la suma de fracciones sea menor que 1:

$$\sum_{i=1}^{N} g_i < 1 \quad\Longleftrightarrow\quad \sum_{i=1}^{N} g_i \cdot V_{\text{HBM}} < V_{\text{HBM}}$$

donde $g_i$ es el --gpu-memory-utilization de la instancia $i$ y $V_{\text{HBM}} = 80$ GB. Conviene dejar margen (overhead del runtime, fragmentación, contexto CUDA), así que en la práctica se busca que la suma quede holgadamente por debajo de 1, digamos $\le 0.9$.

Caso que funciona. Cuatro vLLM a $g_i = 0.20$:

$$\sum_{i=1}^{4} 0.20 = 0.80 \quad\Rightarrow\quad 0.80 \times 80\ \text{GB} = 64\ \text{GB} < 80\ \text{GB} \quad\checkmark$$

Cada instancia reserva $0.20 \times 80 = 16$ GB. Cuatro instancias suman 64 GB, dejando 16 GB de colchón. No hay OOM. Cada vLLM tiene 16 GB para pesos más KV-cache: suficiente para un modelo de 7B–8B en FP8/INT4 con un KV-cache modesto.

Caso que revienta. Las mismas cuatro instancias, pero alguien sube $g_i = 0.30$ pensando “tengo cuatro réplicas, puedo darle más a cada una”:

$$\sum_{i=1}^{4} 0.30 = 1.20 \quad\Rightarrow\quad 1.20 \times 80\ \text{GB} = 96\ \text{GB} > 80\ \text{GB} \quad\times$$

Las primeras instancias arrancan y reservan $0.30 \times 80 = 24$ GB cada una. Tres instancias ya van por $72$ GB. La cuarta intenta reservar otros 24 GB, no quedan, y muere con CUDA out of memory. Y lo peor: Kubernetes la reprogramará sobre la misma GPU (sigue viendo cuatro réplicas), donde volverá a morir, en un CrashLoopBackOff que no se explica mirando solo el manifiesto del pod.

La regla operativa es brutalmente simple: en time-slicing, el presupuesto de VRAM lo gestionas tú a mano, sumando los --gpu-memory-utilization. El número de réplicas controla cuántos pods caben por turnos de cómputo, pero no reserva ni un byte de memoria. Confundir las dos cosas es el error recurrente.

MPS: cocineros coordinados en la misma encimera

El Multi-Process Service (MPS) ataca un problema distinto. Por defecto, cuando varios procesos usan la misma GPU sin MPS, cada uno tiene su propio contexto CUDA, y la GPU alterna entre contextos (time-slicing a nivel de driver): no ejecutan kernels a la vez, se turnan, con overhead de cambio de contexto. Si tus kernels son pequeños y no llenan la GPU ellos solos, esto deja SMs ociosos: el proceso A usa el 30 % de los SMs durante su turno y el otro 70 % se desperdicia.

MPS introduce un daemon que comparte un único contexto CUDA entre procesos, de modo que sus kernels pueden ejecutarse concurrentemente ocupando SMs distintos a la vez. Es reparto espacial de cómputo: en lugar de turnarse la encimera entera, cada cocinero ocupa una parte y trabajan en paralelo. Esto reduce el overhead de context-switch y sube el throughput cuando hay muchos kernels pequeños concurrentes que individualmente no saturan la GPU.

Y, a diferencia del time-slicing puro, MPS permite poner límites por proceso, lo que da una forma de QoS:

CUDA_MPS_ACTIVE_THREAD_PERCENTAGE limita el porcentaje de SMs que un cliente MPS puede usar. Por defecto cada cliente recibe $100 / \text{MaxSharedClients}$. Fijarlo a, digamos, 40 % cierra el techo de cómputo de ese proceso (docs MPS).
CUDA_MPS_PINNED_DEVICE_MEM_LIMIT impone un tope de memoria por cliente (válido desde CUDA 11.5). Esto es lo que el time-slicing no tiene: un límite de VRAM por proceso que el runtime hace cumplir.

Estos dos límites convierten a MPS en un mecanismo de provisioning de recursos que mitiga el noisy neighbor: puedes garantizar que un proceso no se coma más del X % de SMs ni más de Y GB. La combinación da una QoS razonable —no perfecta, pero real.

La limitación que MPS no resuelve: el aislamiento de fallos es débil. Como los clientes comparten el contexto CUDA del daemon, un error fatal en un cliente puede afectar al daemon y, por tanto, a los demás clientes (históricamente, un cliente que muere de forma sucia podía requerir reiniciar el daemon). Es mejor que el time-slicing en este aspecto, pero está lejos del aislamiento por hardware. Por eso MPS encaja cuando hay confianza entre las cargas —procesos de tu propio equipo, no tenants ajenos.

El caso de uso canónico: muchas peticiones de inferencia pequeñas y concurrentes que individualmente dejan la GPU medio vacía. MPS las solapa y sube el throughput agregado. Servir varios modelos pequeños o varias réplicas ligeras del mismo modelo en una GPU de datacenter, donde confías en todas las cargas, es territorio MPS.

MIG: paredes de hormigón

El Multi-Instance GPU (MIG) es el único de los tres que da aislamiento de verdad, porque corta la GPU en hardware. Disponible en las GPU de datacenter modernas —A100 (Ampere), H100/H200 (Hopper), B200 (Blackwell)— y nunca en las de consumo: una RTX 5090 (Blackwell de consumo) no soporta MIG, igual que las GeForce en general.

MIG divide la GPU en hasta siete instancias (GPU Instances), y cada instancia recibe una porción dedicada de:

SMs (compute slices): el cómputo se reparte en 7 slices, cada uno ~1/7 de los SMs.
L2 cache y memoria: cada instancia tiene su trozo de HBM y su porción de caché L2.
Ancho de banda de memoria: dedicado, no compartido.
Caminos de datos y motores: con barreras de fallo entre instancias.

El resultado es que una instancia MIG se comporta como una GPU más pequeña e independiente: lo que pase en una —un OOM, un kernel que peta, una carga que satura su cómputo— no afecta a las vecinas. Aislamiento de memoria, de fallo y de rendimiento (QoS), las tres cosas que el time-slicing no da y que MPS solo da a medias.

Los perfiles de la H100 80GB

MIG no permite tamaños arbitrarios: tiene perfiles fijos. En la H100 80GB, el catálogo de perfiles (notación <compute>g.<memoria>gb) es:

Perfil	Compute (slices)	Memoria	Instancias máx.
`1g.10gb`	1/7	10 GB	7
`1g.20gb`	1/7	20 GB	4
`2g.20gb`	2/7	20 GB	3
`3g.40gb`	3/7	40 GB	2
`4g.40gb`	4/7	40 GB	1
`7g.80gb`	7/7	80 GB	1 (GPU entera)

(Existe además 1g.10gb+me, una variante con media engines para codificación de vídeo.) La unidad base de memoria en la H100 80GB es de 10 GB por slice (80 GB / 8, con un slice reservado), y la de cómputo es 1/7 de los SMs. Los perfiles combinan estas unidades. Fíjate en 1g.20gb: misma fracción de cómputo que 1g.10gb (1/7 de SMs) pero el doble de memoria —útil cuando una carga necesita más VRAM que cómputo.

Un detalle importante: las particiones MIG no se mezclan libremente. La GPU se divide siguiendo una geometría válida (los perfiles encajan como piezas en una rejilla), y los perfiles se fijan al configurar la GPU; cambiarlos requiere drenar y reparticionar. Son paredes de hormigón: sólidas, pero no se mueven en caliente.

El cálculo: 7×1g.10gb frente a 1×7g.80gb

Comparemos los dos extremos. A la izquierda, siete instancias 1g.10gb: siete GPU aisladas de 10 GB cada una. A la derecha, una sola 7g.80gb: la H100 entera sin particionar.

La pregunta operativa es qué cabe en 10 GB. El presupuesto de VRAM de una instancia se reparte entre pesos del modelo y KV-cache:

$$V_{\text{inst}} = V_{\text{pesos}} + V_{\text{KV}} + V_{\text{overhead}}$$

Tomemos un modelo de 7B parámetros en FP8 (1 byte/parámetro):

$$V_{\text{pesos}} \approx 7 \times 10^9 \times 1\ \text{byte} = 7\ \text{GB}$$

En una instancia 1g.10gb (10 GB), tras los 7 GB de pesos y restando ~0.5–1 GB de overhead del runtime, quedan ~2 GB para KV-cache. Eso da para una ventana de contexto modesta y poca concurrencia —correcto para un servicio guardrail, un clasificador o un modelo de extracción que procesa prompts cortos uno a uno. Un 7B en INT4 (~3.5 GB de pesos) deja ~5.5 GB de KV-cache, mucho más holgado. Pero un modelo de 13B en FP8 (~13 GB de pesos) no cabe en una instancia de 10 GB: ni siquiera entran los pesos. Para él necesitas 1g.20gb, 2g.20gb o mayor.

Frente a esto, la 7g.80gb (GPU entera) te da los 80 GB para un modelo grande: un 70B en FP8 (~70 GB de pesos) cabe con KV-cache justo, o un 70B con más holgura repartido en tensor-parallel sobre varias GPU enteras (ver TP frente a réplicas: una grande contra N pequeñas).

La lectura es clara: particionar fino (7×1g.10gb) maximiza el número de cargas aisladas pequeñas; no particionar (1×7g.80gb) maximiza el tamaño del modelo que cabe. El KV-cache disponible por instancia se reduce proporcionalmente al particionar, así que MIG fino sirve para muchos servicios ligeros aislados, no para un modelo grande troceado. Si tu carga es un solo modelo grande, MIG no es para ti —usa la GPU entera o varias en TP.

El árbol de decisión

Las tres preguntas, en orden:

¿Necesitas aislamiento REAL?
(multi-tenant, compliance, fallo de una carga no debe tocar otra)
│
┌────┴────┐
SÍ NO
│ │
¿Es Hopper/ ¿Muchos kernels PEQUEÑOS concurrentes
Ampere/ Y confías en todas las cargas?
Blackwell? │
│ ┌────┴────┐
┌──┴──┐ SÍ NO
SÍ NO │ │
│ │ MPS ¿Dev / ráfagas / GPU de consumo
MIG │ (espacial, / sin necesidad de aislar?
│ │ QoS por │
│ no hay proceso) SÍ
│ aislam. │
│ real: TIME-SLICING
│ replantea (temporal, barato,
│ (mueve a funciona en 5090)
│ CPU, otra GPU,
│ o asume riesgo
│ con time-slicing)

Y en una frase cada rama:

MIG cuando el aislamiento es un requisito (compliance, multi-tenant, SLA duro) y tienes hardware de datacenter que lo soporta. Las paredes de hormigón cuestan, pero si las necesitas no hay sustituto.
MPS cuando tienes muchas cargas pequeñas concurrentes que dejan la GPU medio vacía y confías en todas (mismo equipo, no tenants ajenos). Subes throughput con QoS razonable, asumiendo aislamiento de fallos imperfecto.
Time-slicing cuando es dev, ráfagas, baja utilización, GPU de consumo, o simplemente no necesitas aislar nada. Barato y universal, pero gestiona el presupuesto de VRAM a mano.

Un matiz que la documentación reciente recoge: se pueden combinar. Puedes hacer time-slicing sobre una instancia MIG (aislamiento de hardware en la frontera de la instancia, turnos de software dentro), o usar MPS dentro de una instancia MIG. Las capas no son excluyentes; el árbol elige la estrategia primaria.

Aplicado al cluster genérico 4×H100

Bajemos a números con un cluster on-premise genérico de 4×H100 SXM 80 GB con NVLink. Es habitual tener un menú de cargas heterogéneo: un modelo grande de chat, servicios ligeros (embeddings, reranker, guardrails) y una cola de dev/experimentación. Cada tipo pide un mecanismo distinto. Un reparto razonado:

GPU 0 y GPU 1 — modelo grande en tensor-parallel (sin compartir). Un modelo de 70B en FP8 ocupa ~70 GB de pesos; servido cómodo con KV-cache generoso necesita más de una H100. Lo repartimos en tensor-parallel sobre dos H100 enteras unidas por NVLink (el ancho de banda intra-nodo es lo que hace viable el TP; el detalle está en TP frente a réplicas). Aquí no compartimos: estas dos GPU son del modelo grande y punto. Aislamiento total por dedicación.

$$V_{\text{disponible}} = 2 \times 80 = 160\ \text{GB};\quad V_{\text{pesos}} \approx 70\ \text{GB};\quad V_{\text{KV}} \approx 80\ \text{GB de KV-cache}$$

Sobra memoria para una cola de peticiones larga y mucha concurrencia.

GPU 2 — partida con MIG en instancias pequeñas para servicios ligeros. Embeddings (bge-m3), reranker (bge-reranker-v2-m3) y un par de modelos guardrail (1B–3B) son cargas distintas, de equipos potencialmente distintos, y quieres que un fallo o un pico en una no toque a las demás. Multi-tenant ligero con aislamiento → MIG. Una partición razonable de la H100:

$$\underbrace{3 \times \texttt{1g.10gb}}{\text{30 GB, 3/7 SMs}} ;+; \underbrace{1 \times \texttt{4g.40gb}}{\text{40 GB, 4/7 SMs}}$$

Las tres 1g.10gb (10 GB, 1/7 SMs cada una) alojan embeddings, reranker y un guardrail 1B INT4 —cada uno aislado, sin noisy neighbor. La 4g.40gb (40 GB, 4/7 SMs) aloja un modelo intermedio de 7B–13B con KV-cache decente para un servicio de apoyo. Cada servicio tiene su despensa y su pared; si el reranker peta, el chat no se entera.

GPU 3 — time-slicing para dev y ráfagas. Los desarrolladores tocan la GPU esporádicamente: experimentos, fine-tunes cortos, pruebas de modelos. No necesitan aislamiento (es el mismo equipo) y rara vez coinciden activos. La anunciamos como 4 réplicas vía device-plugin. Cuatro pods de dev caben por turnos. Presupuesto de VRAM con la fórmula de arriba: si cada dev levanta un vLLM a --gpu-memory-utilization 0.20, suman $4 \times 16 = 64$ GB < 80 GB, sin OOM. Si alguien necesita más, baja el número de réplicas o coordina con el equipo —el coste de la flexibilidad es la disciplina manual.

Resumen del reparto:

Recurso	Mecanismo	Carga	Aislamiento
GPU 0 + GPU 1	Dedicación (TP)	70B chat en tensor-parallel	total (dedicado)
GPU 2	MIG (3×1g.10gb + 1×4g.40gb)	embeddings, reranker, guardrails, 7B–13B	hardware real
GPU 3	Time-slicing (4 réplicas)	dev, ráfagas, experimentos	ninguno (confianza)

La lógica es siempre la misma: gasta aislamiento (MIG) donde lo necesitas, gasta concurrencia barata (time-slicing) donde no, y reserva las GPU enteras para lo que de verdad las llena. Una H100 sirviendo embeddings con 7g.80gb sería tan absurdo como una RTX 5090 intentando MIG: la herramienta no encaja con la carga.

Lo que no hemos cubierto

Qué pasa cuando ni siquiera caben a la vez: si tienes más modelos que VRAM y hay que turnarlos en memoria (cargar/descargar pesos, no solo turnar cómputo), entras en territorio de swap y sleep —la pieza hermana Servir varios modelos en una GPU.
Scheduling NUMA-aware: en nodos multi-socket, qué GPU toca a qué CPU/memoria importa para la latencia; ver Kubelet resource managers en RKE2.
Autoscaling de las réplicas: cuántas instancias levantar según carga real, con KEDA y métricas de cola; ver Autoscaling de LLM en Kubernetes con KEDA.
Benchmark de jitter bajo contención: cuánto baila realmente el TTFT en time-slicing con 4 réplicas activas frente a MIG —material que merece medición propia, no estimación.

Ver también

FinOps y multi-tenancy del cluster GPU: quién paga qué — MIG como base del aislamiento y la atribución de coste entre tenants.
GitOps del stack de inferencia con Flux: operar el asistente como código — cómo se declara el reparto de GPU (MIG, gpu-memory-utilization) como código en GitOps.
Servir varios modelos en una GPU: swap y sleep — pieza hermana de la serie: cuando los modelos no caben a la vez en VRAM y hay que turnarlos en memoria, no solo en cómputo.
Kubelet resource managers en RKE2: NUMA y topología — el reparto de GPU se complica con afinidad NUMA; qué GPU asignar a qué socket para no pagar latencia de interconexión.
TP frente a réplicas: una grande contra N pequeñas — la decisión de dedicar 2 H100 enteras en tensor-parallel para el modelo grande es justo lo que aquí asumimos en el reparto del cluster.
Capacity planning para inferencia LLM on-premise — el presupuesto de VRAM (pesos + KV-cache) que aquí trabajamos por instancia es el núcleo del sizing del cluster entero.
Autoscaling de LLM en Kubernetes con KEDA — cuántas réplicas (time-sliced o no) levantar según la carga real, en lugar de fijarlas a mano.
Cinco niveles de madurez de una plataforma LLM on-premise — pasar de “una GPU, una carga” a compartir con aislamiento es uno de los saltos de madurez que marca el modelo.

Referencias

NVIDIA — Time-Slicing GPUs in Kubernetes (GPU Operator). https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html
NVIDIA — Multi-Process Service (MPS) Overview. https://docs.nvidia.com/deploy/mps/index.html
NVIDIA — MPS: Tools and Interface Reference (CUDA_MPS_ACTIVE_THREAD_PERCENTAGE, CUDA_MPS_PINNED_DEVICE_MEM_LIMIT). https://docs.nvidia.com/deploy/mps/appendix-tools-and-interface-reference.html
NVIDIA — Multi-Instance GPU (MIG) User Guide. https://docs.nvidia.com/datacenter/tesla/mig-user-guide/
NVIDIA — Supported MIG Profiles (catálogo H100 80GB). https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html
NVIDIA — k8s-device-plugin (réplicas de time-slicing). https://github.com/NVIDIA/k8s-device-plugin
vLLM — Engine Arguments (--gpu-memory-utilization). https://docs.vllm.ai/en/latest/serving/engine_args.html