Infraestructura de IA local

Ancho de banda de memoria y límites de velocidad

¿Qué velocidad máxima de decode alcanza este modelo en esta GPU?

Vea por qué el ancho de banda de memoria, y no el cómputo, limita el decode de un LLM, compare GPU para la misma configuración y lea una medición frente a su límite.

Unidad de tamaño

1 · Modelo

Qwen3-8B

Qwen

GQALicencia: Apache 2.0

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
147,46 KB/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.

tokens

Solicitudes procesadas a la vez, el batch.

4 · Hardware

RTX PRO 6000 Blackwell Server Edition

NVIDIA · Blackwell

Centro de datos

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

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

FP4FP8FP16BF16TF32FP32
›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.

Compartir un dispositivo entre réplicas

Varias réplicas en un dispositivo, cada una con su propia parte de la memoria.

Las compute instances existen solo dentro de una instancia MIG.
›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.

Medición

Opcional: la latencia entre tokens medida para esta configuración, en milisegundos.

ms
Supuestos del runtime›3,22 GB 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.

GB

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.

Límite teórico, no la velocidad esperada

Paso de decode más corto

13,28 ms

21,21 GB leídos por GPU a 1,6 TB/s.

Límite de velocidad de una secuencia

75,28 tok/s

Tokens por segundo que no puede superar, sin speculative decoding.

Total de 4 secuencias

301,13 tok/s

Tokens por segundo en conjunto.

Tiempo de lectura de los pesos

10,26 ms

Los pesos que aloja una GPU, leídos una vez con todo el ancho de banda.

Batch de equilibrio

313

Punto en que el cómputo pasa a limitar en lugar de la memoria. La latencia sube antes.

Lo que lee una GPU en un paso

  • Pesos leídos16,38 GB77,22 %
  • KV cache leído4,83 GB22,78 %

Tiempo por paso al crecer el batch

Cada secuencia adicional suma su propia caché a los bytes que lee un paso, mientras que los pesos se leen una sola vez para todas. Los mismos límites con un contexto de 8192 tokens.

  • 1 secuencia

    11,01 ms

  • 2 secuencias

    11,77 ms

  • 4 secuencias

    13,28 ms

  • 8 secuencias

    16,31 ms

  • 16 secuencias

    22,36 ms

  • 32 secuencias

    34,46 ms

  • 64 secuencias

    58,67 ms

  • 128 secuencias

    107,08 ms

  • 256 secuencias

    203,89 ms

La misma configuración en otras GPU

Los mismos bytes sobre el ancho de banda de cada GPU. Una GPU en la que la configuración no cabe aparece marcada, y su cifra es la que daría si cupiera.

  • GB200 NVL72

    377 tok/s

  • GB300 NVL72

    377 tok/s

  • B200 HGX

    363 tok/s

  • B300 HGX

    363 tok/s

  • GH200 144 GB HBM3e

    231 tok/s

  • H200 SXM

    226 tok/s

  • H200 NVL

    226 tok/s

  • GH200 96 GB HBM3

    189 tok/s

  • H100 NVL

    186 tok/s

  • H100 SXM

    158 tok/s

  • A100 80GB SXM4

    96 tok/s

  • H100 PCIe

    94 tok/s

  • RTX PRO 6000 Blackwell Server EditionSeleccionada

    75 tok/s

  • Nota: El fabricante indica el pico de esta GPU sin decir si incluye sparsity. Se usa la mitad de la cifra, como en las GPU de la misma generación que sí lo dicen.

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á

DocumentadoConfiguración YSTVGT

vLLM · Docker · 1 GPU, RTX PRO 6000 Blackwell

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.
  1. Paso 1

    Comprobar el driver

    Confirme que el driver de NVIDIA está instalado y es lo bastante reciente para el software de abajo.

    nvidia-smi

    Resultado 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.

    De dónde salen los valores

    • La GPU elegida: RTX PRO 6000 Blackwell.
  2. Paso 2

    Comprobar las GPU

    Confirme que la máquina lista la GPU con índice 0.

    nvidia-smi -L

    Resultado 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.
  3. 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 0

    Resultado 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.

Instalar las herramientas

  1. Paso 4

    Comprobar Docker

    Confirme que Docker Engine está instalado.

    docker --version

    Resultado esperado

    • Una versión de Docker.
    Ayuda y fuentes
  2. Paso 5

    Instalar el NVIDIA Container Toolkit

    Requiere administrador

    Permite 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.
    Ayuda y fuentes
  3. Paso 6

    Conectar Docker con las GPU

    Requiere administrador

    Registre el runtime de NVIDIA en Docker y reinícielo.

    sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

    Resultado esperado

    • Sin errores, y Docker vuelve a arrancar.

    Tenga en cuenta

    • Reiniciar Docker detiene los contenedores en ejecución.
    Ayuda y fuentes
  4. 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-smi

    Resultado 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.

    De dónde salen los valores

    • --gpus '"device=0"'

      Por defecto Las primeras GPU, contadas desde 0.

Obtener el servidor

  1. 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.0

    Resultado esperado

    • La descarga se completa y la última línea nombra la imagen.

    Tenga en cuenta

    • La imagen ocupa varios gigabytes.
    Ayuda y fuentes

3Iniciar el servidor

Inícielo con la configuración dimensionada.
  1. 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.90

    Resultado 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.

    De dónde salen los valores

    • -d

      Por defecto Cómo se eligió ejecutarlo.

    • --name vllm-qwen3-8b

      De la calculadora El repositorio del modelo elegido.

    • --runtime nvidia

      Por defecto Cómo se eligió ejecutarlo.

    • --gpus '"device=0"'

      Por defecto Las primeras GPU, contadas desde 0.

    • --ipc=host

      Por defecto Cómo se eligió ejecutarlo.

    • -v "$HOME/.cache/huggingface":/root/.cache/huggingface

      Por defecto Dónde se guardan los pesos descargados.

    • -p 127.0.0.1:8000:8000

      Por defecto El puerto en el que responde el endpoint.

    • --model Qwen/Qwen3-8B

      De la calculadora El repositorio del modelo elegido.

    • --max-model-len 8192

      De la calculadora La longitud de contexto definida: 8192 tokens.

    • --max-num-seqs 4

      Calculado 4 secuencias repartidas entre 1 réplica.

    • --gpu-memory-utilization 0.90

      Calculado 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.

Comprobar el endpoint

  1. 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 ready

    Resultado 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.
  2. Paso 11

    Comprobar que se sirve el modelo

    Pregunte al servidor qué modelos sirve.

    curl -sS http://127.0.0.1:8000/v1/models

    Resultado 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.
  3. 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

  1. 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 0

    Resultado esperado

    • Memoria en uso cercana a la asignada al motor.
    Ayuda y fuentes
  2. 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-8b

    Resultado esperado

    • El servidor está en ejecución y sus últimas líneas de log no muestran errores.
    Ayuda y fuentes

Comparar con la calculadora

  1. 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

    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 16

    Detenerlo

    Puede detener o eliminar cosas

    Detenga vllm-qwen3-8b y libere las GPU.

    Va después del paso 9

    docker stop vllm-qwen3-8b && docker rm vllm-qwen3-8b

    Resultado 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
  • Límite teórico
›Pesos

  1. Tamaño bruto de los pesos

    Resultado calculado

    Tamañ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

    = 16,38 GB

  2. Pesos en memoria

    Resultado calculado

    Pesos en memoria = parámetros × bits efectivos por parámetro ÷ 8

    = Dato introducido: 8190,74 M parámetros × Especificación oficial: 16 bit/param ÷ 8

    = 16,38 GB

›KV cache

  1. KV cache por token

    Resultado calculado

    KV 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

    = 147,46 KB/token

  2. KV cache por secuencia

    Resultado calculado

    KV cache por secuencia = KV cache por token × longitud de contexto

    = Resultado calculado: 147,46 KB/token × Dato introducido: 8192 tokens

    = 1,21 GB

  3. KV cache

    Resultado calculado

    KV cache = KV cache por secuencia × secuencias concurrentes

    = Resultado calculado: 1,21 GB × Dato introducido: 4

    = 4,83 GB

›Memoria por GPU y en total

  1. Memoria requerida por GPU

    Estimación

    Memoria requerida por GPU = Pesos en memoria + KV cache + Sobrecarga del runtime

    = Resultado calculado: 16,38 GB + Resultado calculado: 4,83 GB + Heurística: 3,22 GB

    = 24,43 GB

  2. Modelo con sobrecarga del runtime

    Estimación

    Modelo con sobrecarga del runtime = Pesos en memoria + Sobrecarga del runtime

    = Resultado calculado: 16,38 GB + Heurística: 3,22 GB

    = 19,6 GB

›Un paso de decode y sus límites

  1. Pesos leídos por GPU en un paso

    Resultado calculado

    Pesos leídos por GPU en un paso = Pesos en memoria

    = Resultado calculado: 16,38 GB

    = 16,38 GB

  2. Bytes leídos por GPU en un paso

    Resultado calculado

    Bytes leídos por GPU en un paso = Pesos leídos por GPU en un paso + KV cache

    = Resultado calculado: 16,38 GB + Resultado calculado: 4,83 GB

    = 21,21 GB

  3. Tiempo de leer los pesos una vez

    Límite teórico

    Tiempo de leer los pesos una vez = Pesos en memoria ÷ Ancho de banda de memoria de la GPU

    = Resultado calculado: 16,38 GB ÷ Especificación oficial: 1,6 TB/s

    = 10,26 ms

  4. Tiempo mínimo de un paso

    Límite teórico

    Tiempo mínimo de un paso = Bytes leídos por GPU en un paso ÷ Ancho de banda de memoria de la GPU

    = Resultado calculado: 21,21 GB ÷ Especificación oficial: 1,6 TB/s

    = 13,28 ms

  5. Límite de velocidad de una secuencia

    Límite teórico

    Límite de velocidad de una secuencia = 1 ÷ Tiempo mínimo de un paso

    = 1 ÷ Límite teórico: 13,28 ms

    = 75,28 tok/s

  6. Límite de velocidad de todas las secuencias

    Límite teórico

    Límite de velocidad de todas las secuencias = secuencias concurrentes ÷ Tiempo mínimo de un paso

    = Dato introducido: 4 ÷ Límite teórico: 13,28 ms

    = 301,13 tok/s

›Puntos de equilibrio

  1. Batch en que el cómputo pasa a limitar

    Límite teórico

    Batch en que el cómputo pasa a limitar = (Cómputo pico, denso × 1.000.000.000.000 ÷ Ancho de banda de memoria de la GPU) × bits efectivos por parámetro ÷ 8 ÷ 2

    = (Estimación: 500 TFLOPS × 1.000.000.000.000 ÷ Especificación oficial: 1,6 TB/s) × Especificación oficial: 16 bit/param ÷ 8 ÷ 2

    = 313,09

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,22 GB 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.
  • Límite teórico: Son límites, no pronósticos. Los motores reales añaden tiempo de kernels, planificación y red: las mediciones publicadas de vLLM resultaron de 30 a 270 % más lentas que la misma fórmula, y las ejecuciones del taller con una sola GPU, de 10 a 15 %.
  • Supuesto: Sin speculative decoding. Puede producir varios tokens en un paso y superar un límite por secuencia.
  • Supuesto: Se cuenta como leído en cada paso todo peso que no pertenezca a los expertos. Las consultas de embeddings leen solo unas pocas filas de la tabla de entrada, así que el mínimo real es unos pocos puntos porcentuales menor en modelos pequeños.
  • Límite teórico: El batch en el que el cómputo de un paso iguala su tiempo de memoria, calculado con el pico denso del formato en que se calculan los pesos. La latencia empieza a subir antes. En una mezcla de expertos, cada experto necesita esta cantidad de tokens propios.

Continuar con

El modelo y los ajustes se mantienen.

13,28 ms75,28 tok/sLímite de velocidad de una secuencia

Por qué importa

Cada paso de decode lee una vez los pesos que necesita y la caché de cada secuencia en ejecución, así que un paso no puede ser más corto que esos bytes divididos por el ancho de banda de memoria. Eso convierte al ancho de banda en el número que fija la rapidez con que responde un modelo, mucho antes que el cómputo de la GPU. Estos límites son pura física. Los motores reales son más lentos, y una medición indica cuánto.

Cómo leer el resultado

El paso más corto son los bytes que lee una GPU en un paso entre su ancho de banda, y de ahí salen los límites de velocidad. Son límites, nunca pronósticos: las mediciones publicadas de vLLM resultaron de 30 a 270 % más lentas. Introduzca su propio tiempo medido por token para ver cuánto se acerca. El batch de equilibrio es el punto en que el cómputo empieza a importar. En una mezcla de expertos los bytes crecen con el batch, porque se accede a más expertos.

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.

← Todas las herramientas