Infraestructura de IA local
Memoria del modelo y ajuste a la GPU
¿Cuánta memoria necesita este modelo y cabe en estas GPU?
Dimensione un modelo, un contexto y una configuración de GPU antes de descargar o comprar nada.
1 · Modelo
Qwen3-8B
Qwen
Ficha del modelo en Hugging Face(se abre en una pestaña nueva)config.json(se abre en una pestaña nueva)
- Parámetros
- 8190,74 M
- Capas
- 36
- Cabezas
- 32 de query, 8 KV
- Dimensión de cabeza
- 128
- Contexto máximo
- 40.960 tokens
- KV cache por token, 16 bits
- 144 KiB/token
- Dimensión oculta
- 4096
- Vocabulario
- 151.936
Valores leídos del config.json de Hugging Face el 30 de octubre de 2026.
Estos valores vienen de Hugging Face y no se pueden editar. Personalice para cambiarlos.
2 · Precisión
Cuántos bits ocupa cada parámetro.
›Cuantizaciones publicadas
Solo se aplica a formatos cuantizados.
Se fija aparte de los pesos. FP8 reduce el KV cache a la mitad.
3 · Carga de trabajo
Tokens por secuencia, prompt y texto generado juntos.
Solicitudes procesadas a la vez, el batch.
4 · Hardware
RTX PRO 6000 Blackwell Server Edition
NVIDIA · Blackwell
Memoria
96 GB
GDDR7 · contado como 96 GiB
Ancho de banda
1597 GB/s
Potencia máx.
300 to 600 W
Configurable.
Las barras comparan cada cifra con la mayor GPU del catálogo.
- NVLink
- Ninguno
- Instancias MIG
- 4
- Grupo NVLink
- Ninguno, solo PCIe
- GPU por servidor
- hasta 8
Cómo se integra en los servidores
- The Server Edition lists no NVLink. NVIDIA-Certified RTX PRO servers hold up to 8 GPUs. NVIDIA RTX PRO 6000 Blackwell Server Edition(se abre en una pestaña nueva)
Dividir esta GPU
MIG
Se divide en 4 slices de memoria y 4 slices de cómputo, hasta 4 instancias en una GPU. Los perfiles:
- 1g.24gb
- 2g.48gb
- 4g.96gb
Dónde puede empezar una instancia:Derivado
vGPU for Compute
10 tipos de 8 a 96 GB de framebuffer, hasta 12 vGPU en una GPU. Requiere una licencia de NVIDIA AI Enterprise y un hipervisor.
Compartir sin dividir
El time-slicing funciona en cualquier GPU, sin aislamiento de memoria ni de fallos entre las réplicas. MPS comparte una GPU completa, no una instancia MIG.
Formatos numéricos
Documentos en NVIDIA
›Especificaciones y fuentes
- Memoria
- 96 GB[1]
- Tipo
- GDDR7[1]
- Ancho de banda
- 1597 GB/s[1]
- Potencia máx.
- 300 to 600 W[2]Configurable.
- NVLink
- 0[3]No admitido.
- Instancias MIG
- 4[4]
- FP4
- 4000 TFLOPS[1]NVIDIA no dice si la cifra es densa o con sparsity.
- FP8
- 2000 TFLOPS[1]NVIDIA no dice si la cifra es densa o con sparsity.
- FP16 / BF16
- 1000 TFLOPS[1]NVIDIA no dice si la cifra es densa o con sparsity.
- TF32
- 234 TFLOPS[1]NVIDIA no dice si la cifra es densa o con sparsity.
Formatos numéricos: FP4, FP8, FP16, BF16, TF32, FP32
Las cifras de tensor son valores pico de las fichas técnicas. No son rendimiento de aplicaciones.
Fuentes
Cargando fuentes
Total de GPU. Reparten el modelo con tensor parallelism, etapas de pipeline y réplicas, como indica la distribución de abajo.
1 servidor de 8 GPU, el último con 1
Cómo se usa la GPU
Divida cada GPU en slices o compártala entre réplicas en lugar de usar más GPU. Los slices y las fracciones ejecutan réplicas del modelo: no se pueden unir en un grupo de tensor parallel.
›Distribución del despliegue
Cómo reparten el modelo las GPU. De ello se derivan la memoria por GPU, el espacio para el KV cache y el número de GPU, tal como los divide vLLM.
Etapas de pipeline
Divide las capas en tramos que corren en GPU distintas. Entre etapas pasan pocos datos, así que sirve para GPU sin enlace rápido y para servidores unidos por red.
Réplicas
Copias independientes del modelo, cada una con su propio KV cache. Se reparten las secuencias. Un modelo de mezcla de expertos reparte sus expertos entre todas.
Tamaño de tensor parallel: 1, las GPU divididas entre las etapas y las réplicas.
GPU por servidor
El tensor parallelism se queda dentro de un servidor. Más allá, las GPU pasan a ser etapas de pipeline.
Tamaño de decode context parallel
Reparte el KV cache de cada secuencia por tokens entre las GPU de tensor parallel. No añade GPU y ralentiza el decode.
Solo para modelos de mezcla de expertos.
Supuestos del runtime›3 GiB de sobrecarga por GPU, 90 % utilizables, 10 % de margen
Memoria para el contexto CUDA, las activaciones y los CUDA graphs, en la unidad de la página. Es una heurística.
Parte de la memoria de la GPU que el motor de inferencia puede usar. El valor por defecto de vLLM es 92 %.
Parte de la memoria utilizable que debe quedar libre para un ajuste holgado.
Este modelo no tiene capas de ventana deslizante.
Cabe con margen
Requiere 22,76 GiB por GPU. Quedan libres 63,64 GiB de los 86,4 GiB utilizables, más que el margen de 10 % solicitado.
Memoria requerida por GPU
22,76 GiB
de 86,4 GiB utilizables
Memoria restante por GPU
63,64 GiB
73,66 % de la memoria utilizable está libre
Tamaño bruto de los pesos
15,26 GiB
Parámetros × bits nominales
Memoria total estimada
22,76 GiB
Memoria total de las GPU
96 GiB
Memoria de una GPU
Memoria en cada GPU
Memoria de la GPU 96 GiB
- Pesos en memoria15,26 GiB67,04 %
- KV cache4,5 GiB19,77 %
- Sobrecarga del runtime3 GiB13,18 %
Presupuesto de memoria
| Parte | Memoria |
|---|---|
| Tamaño bruto de los pesosParámetros × bits nominales | 15,26 GiB |
| Pesos en memoria | 15,26 GiB |
| Sobrecarga del runtime | 3 GiB |
| Modelo con sobrecarga del runtime | 18,26 GiB |
| KV cache | 4,5 GiB |
| Total | 22,76 GiB |
Espacio para KV cache
El motor podría guardar 496.206 tokens de KV cache en lo que queda tras los pesos y la sobrecarga, suficiente para 60,57 secuencias de 8192 tokens.
vLLM muestra esto como su capacidad de KV cache al arrancar. La capacidad real es algo menor: la caché se guarda en bloques.
Número de GPU
Mínimo por memoria
1
TP 1
26,34 % de la memoria utilizable, 63,64 GiB libres por GPU
El menor número de GPU cuya memoria aloja el modelo con cualquier división. Puede que la distribución no sea una que vLLM acepte.
Menor división válida
1
TP 1
26,34 % de la memoria utilizable, 63,64 GiB libres por GPU
El menor número de GPU con una distribución que vLLM acepta: tensor parallelism dentro de un servidor, etapas de pipeline más allá.
Recomendado
1
TP 1
26,34 % de la memoria utilizable, 63,64 GiB libres por GPU
Una división válida que además mantiene el margen requerido.
Cada GPU debe alojar su propia parte, así que la memoria de varias GPU no forma un único pool de memoria. Más de ocho GPU suele significar varios servidores.
Memoria por GPU según el número de GPU
Cada barra es un número de GPU, con la distribución que recomienda la guía de vLLM para ese número. La línea es la memoria utilizable. Elija una barra para usar ese número.
- Utilizable 86,4 GiB
- Límite de margen
- Pesos en memoria
- KV cache
- Sobrecarga del runtime
- Estrella: recomendado
- Rombo: menor división válida
- Círculo: mínimo por memoria
- Con contorno: en uso
- Atenuado, discontinuo: vLLM no arrancaría con esta distribución
›Mostrar como tabla
| GPU | Distribución | Por GPU | Ajuste |
|---|---|---|---|
| 1 | TP 1 | 22,76 GiB | Cabe con margenmínimo por memoria, menor división válida, recomendado, en uso |
| 2 | TP 2 | 12,88 GiB | Cabe con margen |
| 3 | TP 3vLLM no arrancaría con esta distribución | 9,77 GiB | Cabe con margen |
| 4 | TP 4 | 7,94 GiB | Cabe con margen |
| 5 | TP 5vLLM no arrancaría con esta distribución | 7,18 GiB | Cabe con margen |
| 6 | TP 3 × PP 2vLLM no arrancaría con esta distribución | 6,39 GiB | Cabe con margen |
| 7 | TP 7vLLM no arrancaría con esta distribución | 6,3 GiB | Cabe con margen |
| 8 | TP 8 | 5,47 GiB | Cabe con margen |
| 9 | TP 1 × PP 9 | 6,1 GiB | Cabe con margen |
| 10 | TP 2 × PP 5 | 5,27 GiB | Cabe con margen |
| 11 | TP 1 × PP 11 | 5,61 GiB | Cabe con margen |
| 12 | TP 4 × PP 3 | 4,74 GiB | Cabe con margen |
| 13 | TP 1 × PP 13 | 5,13 GiB | Cabe con margen |
| 14 | TP 2 × PP 7 | 4,79 GiB | Cabe con margen |
| 15 | TP 1 × PP 15 | 5,13 GiB | Cabe con margen |
| 16 | TP 8 × PP 2 | 4,23 GiB | Cabe con margen |
Qué cabe con otros contextos y concurrencias
Cada celda es la memoria que necesita una GPU con ese contexto y ese número de secuencias, con las GPU y la distribución que haya fijado. Elija una celda para usarla.
Secuencias ↓Contexto, en tokens →
| 2K | 4K | 8K | 16K | 32K | 40Kmáx. del modelo | |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 4 | ||||||
| 16 | ||||||
| 64 | ||||||
| 128 | ||||||
| 256 | ||||||
| 512 | ||||||
| 1024 |
- Marca de verificación: cabe con margen
- Triángulo: cabe, sin el margen solicitado
- Cruz: no cabe
- Con contorno: en uso
Formas de cambiar la configuración
Margen de crecimiento
Esta configuración cabe con margen. Hasta aquí se podría llevar.
El contexto podría crecer hasta 40.960 tokens con 4 secuencias
Entonces: cabe con margen, 47,17 % de la memoria utilizable
Caben hasta 52 secuencias concurrentes con 8192 tokens
Entonces: cabe con margen, 88,84 % de la memoria utilizable
Desplegar esta configuración
Estos comandos están escritos para la configuración dimensionada arriba y las opciones elegidas aquí, y cambian con cualquiera de las dos. No se cambia nada automáticamente: una opción que deja de funcionar se conserva y se marca, con formas de corregirla.
El servidor
Ejecutar con
Runtime
El servidor que carga el modelo.
GPU
Los índices de las GPU de la máquina, tal como los lista nvidia-smi, separados por comas. La configuración usa 1 GPU.
Identificar las GPU por
Un índice depende del orden en que el driver encuentra las GPU. Un UUID está ligado a la tarjeta.
Endpoint
El puerto en el que responde el endpoint. 8000 (por defecto)
Escuchar en
El valor por defecto mantiene el endpoint en esta máquina.
El endpoint responde solo a solicitudes que lleven una clave. La clave se genera en su máquina y nunca se escribe en un comando ni en un enlace.
Más opciones
Dónde se guardan los pesos descargados. Un directorio que ya existe ahorra la descarga.
El valor por defecto es la versión para la que se escribieron estos comandos. latest sigue la más reciente.
Qué se ejecutará
vLLM · Docker · 1 GPU, RTX PRO 6000 Blackwell
- Repositorio
- Qwen/Qwen3-8BDe la calculadora
- Runtime
- vLLMPor defecto
- Se ejecuta con
- DockerPor defecto
- GPU
- 1 GPU, RTX PRO 6000 BlackwellDe la calculadora
- índice 0Por defecto
- Contexto
- 8192 tokensDe la calculadora
- Secuencias por réplica
- 4Calculado
- Memoria por GPU
- 22,76 GiB necesarios de 86,40 GiB utilizables
- Parte de cada GPU para el motor
- 90 %Calculado
- Acceso
- AbiertoDe la calculadora
- Endpoint
- 127.0.0.1:8000Por defecto
Conviene revisarlo
Se dimensionó un KV cache fp16 para pesos en bf16. Una caché de 16 bits ocupa el mismo espacio en cualquiera de los dos tipos, y vLLM la guarda en el tipo propio del modelo salvo que se indique otra cosa, así que los comandos no fuerzan fp16.
16 pasos en 5 fases. Abra uno a la vez, o todos.
1Comprobar el hardware
Mire lo que ofrece la máquina o el cluster antes de cambiar nada.3 pasos
- Paso 1
Comprobar el driver
Confirme que el driver de NVIDIA está instalado y es lo bastante reciente para el software de abajo.
nvidia-smiResultado esperado
- Una tabla con la versión del driver y una versión de CUDA de al menos 13.0, que necesita la imagen.
Ayuda y fuentes
Si no funciona
- Si la versión de CUDA es inferior a la que necesita el software, actualice el driver y vuelva a comprobar.
- nvidia-smi(se abre en una pestaña nueva)
- CUDA minor version compatibility(se abre en una pestaña nueva)
De dónde salen los valores
- La GPU elegida: RTX PRO 6000 Blackwell.
- Paso 2
Comprobar las GPU
Confirme que la máquina lista la GPU con índice 0.
nvidia-smi -LResultado esperado
- Una línea por cada GPU, y cada una indica RTX PRO 6000 Blackwell tal como lo escribe la máquina.
Ayuda y fuentes
Si no funciona
- Si falta una GPU elegida, no está en esta máquina o el driver no la ve.
- Si los nombres no coinciden con lo esperado, los índices no son los que cree. Identifique las GPU por UUID, que no depende del orden.
De dónde salen los valores
- La calculadora usa 1 GPU.
- La GPU elegida: RTX PRO 6000 Blackwell.
- Paso 3
Comprobar que la memoria está libre
La calculadora espera 22,76 GiB en cada GPU, de los 86,40 GiB que el motor puede usar. Compruebe que la memoria de la GPU con índice 0 está libre.
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv -i 0Resultado esperado
- Casi toda la memoria de la GPU está libre, al menos 22,76 GiB en cada una.
Tenga en cuenta
- Puede que otros trabajos ya usen estas GPU. Si su memoria no está libre, detenga esos trabajos o elija otras GPU antes de empezar.
Ayuda y fuentes
De dónde salen los valores
- La calculadora: 22,76 GiB necesarios de 86,40 GiB utilizables en cada GPU.
2Preparar
Obtenga acceso al modelo, instale lo que necesita el servidor y descárguelo. Aquí también se crea una GPU dividida.2 requieren permisos de administrador5 pasos
Instalar las herramientas
- Paso 4
Comprobar Docker
Confirme que Docker Engine está instalado.
docker --versionResultado esperado
- Una versión de Docker.
Ayuda y fuentes
- Paso 5
Instalar el NVIDIA Container Toolkit
Requiere administradorPermite que los contenedores usen las GPU. Estos comandos son para Ubuntu y Debian, y la página enlazada abajo tiene las demás distribuciones.
Va después del paso 1
sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \ && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update export NVIDIA_CONTAINER_TOOLKIT_VERSION=1.20.1-1 sudo apt-get install -y \ nvidia-container-toolkit=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ nvidia-container-toolkit-base=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ libnvidia-container-tools=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ libnvidia-container1=${NVIDIA_CONTAINER_TOOLKIT_VERSION}Resultado esperado
- Los paquetes se instalan sin errores.
- Paso 6
Conectar Docker con las GPU
Requiere administradorRegistre el runtime de NVIDIA en Docker y reinícielo.
sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart dockerResultado esperado
- Sin errores, y Docker vuelve a arrancar.
Tenga en cuenta
- Reiniciar Docker detiene los contenedores en ejecución.
- Paso 7
Comprobar que un contenedor ve las GPU
Ejecute nvidia-smi en un contenedor al que se da la GPU con índice 0. Solo debería aparecer esa GPU.
docker run --rm --runtime=nvidia --gpus '"device=0"' \ ubuntu nvidia-smiResultado esperado
- Una tabla con una GPU, las que eligió.
Ayuda y fuentes
Si no funciona
- Si Docker no puede arrancar con las GPU, el toolkit no está configurado o los índices no existen en esta máquina.
- Si los nombres no coinciden con lo esperado, los índices no son los que cree. Identifique las GPU por UUID, que no depende del orden.
- NVIDIA Container Toolkit: sample workload(se abre en una pestaña nueva)
- NVIDIA Container Toolkit: Specialized configurations with Docker(se abre en una pestaña nueva)
De dónde salen los valores
--gpus '"device=0"'Por defecto Las primeras GPU, contadas desde 0.
Obtener el servidor
- Paso 8
Descargar la imagen
Descargue vllm/vllm-openai:v0.32.0 antes del primer arranque, para que el arranque solo tenga que cargar el modelo.
docker pull vllm/vllm-openai:v0.32.0Resultado esperado
- La descarga se completa y la última línea nombra la imagen.
Tenga en cuenta
- La imagen ocupa varios gigabytes.
3Iniciar el servidor
Inícielo con la configuración dimensionada.1 paso
- Paso 9
Iniciar el servidor
Inicie vllm-qwen3-8b con la configuración dimensionada: el modelo Qwen/Qwen3-8B, el paralelismo, el contexto y la memoria asignada. El primer arranque descarga el modelo y tarda unos minutos.
Va después del paso 3
# config YSTVGT docker run -d --name vllm-qwen3-8b \ --runtime nvidia --gpus '"device=0"' \ --ipc=host \ -v "$HOME/.cache/huggingface":/root/.cache/huggingface \ -p 127.0.0.1:8000:8000 \ vllm/vllm-openai:v0.32.0 \ --model Qwen/Qwen3-8B \ --max-model-len 8192 --max-num-seqs 4 \ --gpu-memory-utilization 0.90Resultado esperado
- Un id de contenedor.
Tenga en cuenta
- El primer arranque descarga el modelo y prepara los kernels, lo que tarda minutos. Hasta entonces el servidor no está listo.
Ayuda y fuentes
Si no funciona
- Si se detiene con un mensaje de falta de memoria (out of memory), la configuración necesita más de lo que aloja la GPU. Reduzca el contexto o las secuencias, asigne al motor una parte mayor de la GPU o use más GPU. La calculadora muestra por cuánto.
- Si vLLM indica que el contexto es mayor de lo que cabe en el KV cache, reduzca el contexto o el número de secuencias.
- Si vLLM indica que las cabezas de atención no se pueden dividir por el tamaño de tensor parallel, use un tamaño que las divida.
- Si el puerto está ocupado, elija otro en las opciones.
- Si Docker no puede arrancar con las GPU, el toolkit no está configurado o los índices no existen en esta máquina.
- vLLM: vllm serve arguments(se abre en una pestaña nueva)
- vLLM: engine arguments(se abre en una pestaña nueva)
De dónde salen los valores
-dPor defecto Cómo se eligió ejecutarlo.
--name vllm-qwen3-8bDe la calculadora El repositorio del modelo elegido.
--runtime nvidiaPor defecto Cómo se eligió ejecutarlo.
--gpus '"device=0"'Por defecto Las primeras GPU, contadas desde 0.
--ipc=hostPor defecto Cómo se eligió ejecutarlo.
-v "$HOME/.cache/huggingface":/root/.cache/huggingfacePor defecto Dónde se guardan los pesos descargados.
-p 127.0.0.1:8000:8000Por defecto El puerto en el que responde el endpoint.
--model Qwen/Qwen3-8BDe la calculadora El repositorio del modelo elegido.
--max-model-len 8192De la calculadora La longitud de contexto definida: 8192 tokens.
--max-num-seqs 4Calculado 4 secuencias repartidas entre 1 réplica.
--gpu-memory-utilization 0.90Calculado La parte utilizable definida, 90 %, dividida entre 1 réplica en el dispositivo, redondeada hacia abajo para que las partes nunca sumen más que el dispositivo.
- El repositorio del modelo elegido.
- La longitud de contexto definida: 8192 tokens.
- La parte utilizable definida, 90 %, dividida entre 1 réplica en el dispositivo, redondeada hacia abajo para que las partes nunca sumen más que el dispositivo.
4Comprobar que funciona
Espere a que responda, hágale una pregunta y compare la memoria con la calculadora.6 pasos
Comprobar el endpoint
- Paso 10
Esperar a que esté listo
El servidor responde en /health cuando el modelo está cargado.
timeout 900 bash -c 'until curl -fs http://127.0.0.1:8000/health >/dev/null; do sleep 5; done' && echo readyResultado esperado
- La palabra ready, tras un minuto o más mientras se carga el modelo.
Ayuda y fuentes
Si no funciona
- Si no llega a estar listo, lea las últimas líneas del log: el modelo aún se está cargando o el servidor se detuvo con un error.
- Si se detiene con un mensaje de falta de memoria (out of memory), la configuración necesita más de lo que aloja la GPU. Reduzca el contexto o las secuencias, asigne al motor una parte mayor de la GPU o use más GPU. La calculadora muestra por cuánto.
- Paso 11
Comprobar que se sirve el modelo
Pregunte al servidor qué modelos sirve.
curl -sS http://127.0.0.1:8000/v1/modelsResultado esperado
- Una lista que contiene Qwen/Qwen3-8B.
Ayuda y fuentes
Si no funciona
- Si la respuesta es 401, la clave de este shell no es la que se usó para iniciar el servidor.
- Paso 12
Hacerle una pregunta
Una solicitud a través del endpoint que usarán las aplicaciones.
curl -sS http://127.0.0.1:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"model": "Qwen/Qwen3-8B", "messages": [{"role": "user", "content": "Say hello in five words."}], "max_tokens": 32}'Resultado esperado
- Una respuesta JSON con un mensaje del modelo.
Ayuda y fuentes
Si no funciona
- Si la respuesta es 401, la clave de este shell no es la que se usó para iniciar el servidor.
- Si no llega a estar listo, lea las últimas líneas del log: el modelo aún se está cargando o el servidor se detuvo con un error.
Supervisar la máquina
- Paso 13
Supervisar las GPU
Vea la memoria en uso y la actividad de la GPU con índice 0 mientras el servidor funciona.
nvidia-smi --query-gpu=index,name,memory.used,memory.total,utilization.gpu --format=csv -i 0Resultado esperado
- Memoria en uso cercana a la asignada al motor.
Ayuda y fuentes
- Paso 14
Supervisar el servidor
Compruebe que vllm-qwen3-8b se está ejecutando y cuál fue su último mensaje.
Va después del paso 12
docker ps --filter name=vllm-qwen3-8b --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' docker logs --tail 20 vllm-qwen3-8bResultado esperado
- El servidor está en ejecución y sus últimas líneas de log no muestran errores.
Ayuda y fuentes
Comparar con la calculadora
- Paso 15
Comparar con la calculadora
La calculadora esperaba 22,76 GiB en cada GPU, con el 90 % de la GPU asignado al motor. El log del propio servidor indica lo que tomó para los pesos y lo que queda para el KV cache.
Va después del paso 12
docker logs vllm-qwen3-8b 2>&1 | grep -E 'Model loading took|Available KV cache memory|GPU KV cache size'Resultado esperado
- Líneas con la memoria que ocuparon los pesos, la memoria que queda para el KV cache y cuántos tokens admite.
Ayuda y fuentes
- vLLM: parallelism and scaling(se abre en una pestaña nueva)
- vLLM: conserving memory(se abre en una pestaña nueva)
De dónde salen los valores
- La calculadora: 22,76 GiB necesarios de 86,40 GiB utilizables en cada GPU.
5Limpiar
Detenga el servidor y elimine lo que crearon estos pasos.1 paso
- Paso 16
Detenerlo
Puede detener o eliminar cosasDetenga vllm-qwen3-8b y libere las GPU.
Va después del paso 9
docker stop vllm-qwen3-8b && docker rm vllm-qwen3-8bResultado esperado
- Sin salida, y las GPU quedan libres.
Tenga en cuenta
- El endpoint deja de responder.
Ayuda y fuentes
Cálculo
- Dato introducido
- Especificación oficial
- Resultado calculado
- Estimación
- Heurística
- Supuesto
›Pesos
Tamaño bruto de los pesos
Resultado calculadoTamaño bruto de los pesos = parámetros × bits nominales por parámetro ÷ 8
= Dato introducido: 8190,74 M parámetros × Especificación oficial: 16 bit/param ÷ 8
= 15,26 GiB
Pesos en memoria
Resultado calculadoPesos en memoria = parámetros × bits efectivos por parámetro ÷ 8
= Dato introducido: 8190,74 M parámetros × Especificación oficial: 16 bit/param ÷ 8
= 15,26 GiB
›KV cache
KV cache por token
Resultado calculadoKV cache por token = 2 × capas con KV cache × cabezas KV × dimensión de cabeza × bits del KV cache por valor ÷ 8
= 2 × Dato introducido: 36 × Dato introducido: 8 × Dato introducido: 128 × Dato introducido: 16 bit ÷ 8
= 144 KiB/token
KV cache por secuencia
Resultado calculadoKV cache por secuencia = KV cache por token × longitud de contexto
= Resultado calculado: 144 KiB/token × Dato introducido: 8192 tokens
= 1,13 GiB
KV cache
Resultado calculadoKV cache = KV cache por secuencia × secuencias concurrentes
= Resultado calculado: 1,13 GiB × Dato introducido: 4
= 4,5 GiB
›Memoria por GPU y en total
Memoria requerida por GPU
EstimaciónMemoria requerida por GPU = Pesos en memoria + KV cache + Sobrecarga del runtime
= Resultado calculado: 15,26 GiB + Resultado calculado: 4,5 GiB + Heurística: 3 GiB
= 22,76 GiB
Modelo con sobrecarga del runtime
EstimaciónModelo con sobrecarga del runtime = Pesos en memoria + Sobrecarga del runtime
= Resultado calculado: 15,26 GiB + Heurística: 3 GiB
= 18,26 GiB
›Ajuste a la GPU
Memoria utilizable por GPU
EstimaciónMemoria utilizable por GPU = Memoria de la GPU × parte utilizable ÷ 100
= Especificación oficial: 96 GiB × Supuesto: 90 % ÷ 100
= 86,4 GiB
Límite holgado por GPU
EstimaciónLímite holgado por GPU = Memoria utilizable por GPU × (100 − margen requerido) ÷ 100
= Estimación: 86,4 GiB × (100 − Supuesto: 10 %) ÷ 100
= 77,76 GiB
Memoria restante por GPU
EstimaciónMemoria restante por GPU = Memoria utilizable por GPU − Memoria requerida por GPU
= Estimación: 86,4 GiB − Estimación: 22,76 GiB
= 63,64 GiB
Utilización de la memoria utilizable
EstimaciónUtilización de la memoria utilizable = Memoria requerida por GPU ÷ Memoria utilizable por GPU × 100
= Estimación: 22,76 GiB ÷ Estimación: 86,4 GiB × 100
= 26,34 %
›Espacio para KV cache
Memoria que queda para el KV cache por GPU
EstimaciónMemoria que queda para el KV cache por GPU = max(0, Memoria utilizable por GPU − Pesos en memoria − Sobrecarga del runtime)
= max(0, Estimación: 86,4 GiB − Resultado calculado: 15,26 GiB − Heurística: 3 GiB)
= 68,14 GiB
Capacidad del KV cache
EstimaciónCapacidad del KV cache = floor(Memoria que queda para el KV cache por GPU ÷ KV cache por token)
= floor(Estimación: 68,14 GiB ÷ Resultado calculado: 144 KiB/token)
= 496.206 tokens
Secuencias de este contexto que caben
EstimaciónSecuencias de este contexto que caben = Capacidad del KV cache ÷ longitud de contexto
= Estimación: 496.206 tokens ÷ Dato introducido: 8192 tokens
= 60,57 ×
›Con 1 GPU mínimo por memoria, menor división válida, recomendado
Memoria requerida por GPU
EstimaciónMemoria requerida por GPU = Pesos en memoria + KV cache + Sobrecarga del runtime
= Resultado calculado: 15,26 GiB + Resultado calculado: 4,5 GiB + Heurística: 3 GiB
= 22,76 GiB
Memoria utilizable por GPU
EstimaciónMemoria utilizable por GPU = Memoria de la GPU × parte utilizable ÷ 100
= Especificación oficial: 96 GiB × Supuesto: 90 % ÷ 100
= 86,4 GiB
Límite holgado por GPU
EstimaciónLímite holgado por GPU = Memoria utilizable por GPU × (100 − margen requerido) ÷ 100
= Estimación: 86,4 GiB × (100 − Supuesto: 10 %) ÷ 100
= 77,76 GiB
Memoria restante por GPU
EstimaciónMemoria restante por GPU = Memoria utilizable por GPU − Memoria requerida por GPU
= Estimación: 86,4 GiB − Estimación: 22,76 GiB
= 63,64 GiB
Utilización de la memoria utilizable
EstimaciónUtilización de la memoria utilizable = Memoria requerida por GPU ÷ Memoria utilizable por GPU × 100
= Estimación: 22,76 GiB ÷ Estimación: 86,4 GiB × 100
= 26,34 %
Supuestos
- Supuesto: El KV cache se guarda en bloques (16 tokens en vLLM), así que la capacidad real queda algo por debajo del número mostrado.
- Heurística: La sobrecarga del runtime es 3 GiB por GPU para el contexto CUDA, las activaciones y los CUDA graphs. Es una heurística: vLLM midió 2,57 GiB en un modelo de 8B, y varía con el motor y los ajustes. Cambiar
- Supuesto: Solo 90 % de la memoria de la GPU se asigna al modelo. Los motores de inferencia reservan el resto: el valor por defecto de vLLM es 92 % (documentación de la versión 0.32). Cambiar
- Supuesto: Un ajuste se considera holgado cuando al menos 10 % de la memoria utilizable queda libre. Cambiar
- Supuesto: NVIDIA indica la memoria de la GPU en GB, y el hardware tiene esa cantidad en GiB: una H100 de 80 GB tiene 80 GiB, y nvidia-smi muestra 79,6. Los pocos puntos porcentuales que retienen ECC y el driver quedan cubiertos por la parte utilizable.
- Supuesto: La precisión del KV cache se fija aparte de la precisión de los pesos. Cuantizar los pesos no reduce el KV cache ni la sobrecarga. Cambiar
- Supuesto: Se supone que todas las secuencias usan el contexto completo a la vez, el peor caso. El tráfico real suele ser más corto. Cambiar
- Supuesto: Se supone que varias GPU se reparten el modelo con tensor parallelism, como hace vLLM: los pesos y las cabezas KV se dividen, y cada GPU paga la sobrecarga del runtime.
Cabe con margen22,76 GiB / 86,4 GiBrequerida / utilizable
Por qué importa
La cifra de la ficha del modelo son los pesos. Un modelo en ejecución guarda además un KV cache que crece con el contexto y la concurrencia, más la sobrecarga del runtime, y cada GPU debe alojar su propia parte: la memoria de varias GPU no forma un único pool de memoria. Planificar solo con los pesos es el error de dimensionamiento más habitual.
Cómo leer el resultado
Cabe con margen deja libre en cada GPU el margen de seguridad configurado. Cabe en teoría queda por debajo de la memoria utilizable, pero con menos margen del solicitado. No cabe significa que una GPU se quedaría sin memoria. El presupuesto de memoria muestra cada parte para todas las GPU y para una. El número de GPU sigue la guía de vLLM: tensor parallelism dentro de un servidor, etapas de pipeline más allá. La distribución del despliegue permite dividir las GPU de otra forma y ver lo que aloja cada una.
IA local y soberanía
Ejecutar un modelo en hardware propio es un factor más en una decisión de soberanía. Por sí solo no hace que un despliegue sea soberano, ni que cumpla el RGPD o el Reglamento de IA de la UE.
Estas herramientas proceden del taller IA sin la nube.