Infraestructura de IA local

Capacidad de inferencia

¿Cuántas GPU necesita esta carga?

Convierta solicitudes por segundo y recuentos de tokens en los tokens por segundo que hay que atender, vea lo máximo que puede hacer el hardware y planifique con un throughput medido.

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.

Carga

Cuántas solicitudes llegan cada segundo en el momento de mayor carga.

req/s

El número medio de tokens de entrada de una solicitud.

El número medio de tokens que el modelo escribe en una respuesta.

Medición propia

Una RTX PRO 6000 Server Edition, Qwen3-8B en BF16, vLLM 0.31.0, 1200 tokens de entrada y 180 de salida, 8 solicitudes a la vez: 550,8 tokens por segundo, 356 ms hasta el primer token, 12,3 ms entre tokens.

De esta configuración con todas sus GPU, con la concurrencia indicada abajo.

tok/s

El throughput cambia con la concurrencia, así que hace falta ese número para comparar.

Opcional. La mediana con la concurrencia indicada arriba.

ms

Opcional. La mediana con la concurrencia indicada arriba.

ms

Un plan deja margen para picos. Un 80 % es un punto de partida habitual.

%

Prefill y decode

Opcional. El objetivo, para comparar con la medición.

ms

Opcional. El objetivo, para comparar con la medición.

ms

La velocidad de red que transportaría el KV cache. Son habituales 100, 200, 400 y 800.

Gbit/s

Opcional. Necesario para contar instancias.

tok/s

Opcional. Necesario para contar instancias.

tok/s
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.

Las cifras de hardware dan un límite, un mínimo. Un plan necesita un throughput medido en la propia configuración.

Tokens de salida por segundo necesarios

360 tok/s

2 solicitudes por segundo × 180 tokens generados.

Solicitudes por minuto

120 req/min

Tokens de prompt por segundo necesarios: 2400 tok/s

Cuántas copias de esta configuración

A partir de la medición

Introduzca los tokens de salida por segundo medidos y la concurrencia para obtener las copias y las GPU en que se basa un plan.

Según el hardware, como mínimo

Como mínimo 1 copia de la configuración, 1 GPU

Una copia no puede superar 372,64 tok/s con 4 solicitudes a la vez, contando los prompts de las demás solicitudes. Los motores reales van más lentos.

Solicitudes en curso

Con 2 solicitudes por segundo, 34,19 ms hasta el primer token y 10,73 ms entre tokens, hay unas 3,9 solicitudes en curso en cada momento.

  • Solicitudes en curso

    3,9

  • Secuencias que aloja una copia

    60

Una copia aloja 60 secuencias de 8192 tokens en su KV cache: es suficiente.

A partir de los límites, por tanto una cota inferior.

Prefill y decode

vLLM ejecuta prefill y decode en las mismas GPU y divide los prompts largos en bloques. En esta GPU su scheduler admite hasta 8192 tokens por paso y 1024 secuencias a la vez. Un presupuesto de tokens menor favorece el tiempo entre tokens; uno mayor, el tiempo hasta el primer token.

Enviar el KV cache de un prompt de 1200 tokens tarda como mínimo 7,08 ms a 200 Gbit/s: 176,95 MB. Es un mínimo calculado con la velocidad nominal. Las transferencias medidas fueron de 3,6 a 9 veces más lentas.

Lo que dice vLLM

  • Introduzca ambosTiempo entre tokens frente al objetivo
  • Introduzca ambosTiempo hasta el primer token frente al objetivo
  • Separar instancias puede ayudar cuando los percentiles altos del tiempo entre tokens no cumplen el objetivo, o con prompts largos y alta concurrencia, y solo si la transferencia es rápida.
  • Conviene mantenerlas juntas cuando el tiempo hasta el primer token es el objetivo que limita, cuando la transferencia es lenta o cuando el tráfico es bajo.
  • La documentación de vLLM califica el disaggregated prefilling de experimental y afirma que no mejora el throughput. Ajusta los dos tiempos por separado.

Sin tasas medidas no hay proporción. vLLM no publica ninguna fórmula para ella, y los resultados publicados varían con el objetivo: un benchmark mejoró un 40 % con un objetivo de velocidad y empeoró un 31 % con otro. Introduzca los tokens de prompt por segundo de una instancia de prefill y los tokens de salida por segundo de una instancia de decode que haya medido.

  • 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.
  • Nota: Las solicitudes en curso se calculan a partir de los límites, así que son una cota inferior. Introduzca tiempos medidos para obtener la cifra real.

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
  • Resultado calculado
  • Estimación
  • Límite teórico
›La carga

  1. Solicitudes por minuto

    Resultado calculado

    Solicitudes por minuto = Solicitudes por segundo × 60

    = Dato introducido: 2 req/s × 60

    = 120 req/min

  2. Tokens de salida por segundo necesarios

    Resultado calculado

    Tokens de salida por segundo necesarios = Solicitudes por segundo × Tokens generados por solicitud

    = Dato introducido: 2 req/s × Dato introducido: 180 tokens

    = 360 tok/s

  3. Tokens de prompt por segundo necesarios

    Resultado calculado

    Tokens de prompt por segundo necesarios = Solicitudes por segundo × Tokens de prompt por solicitud

    = Dato introducido: 2 req/s × Dato introducido: 1200 tokens

    = 2400 tok/s

›Lo que permite el hardware, como mínimo

  1. Tokens de prompt en cada paso

    Límite teórico

    Tokens de prompt en cada paso = Secuencias por réplica × Tokens de prompt por solicitud ÷ Tokens generados por solicitud

    = Dato introducido: 4 × Dato introducido: 1200 tokens ÷ Dato introducido: 180 tokens

    = 26,67 tokens

  2. Paso más corto por cómputo

    Límite teórico

    Paso más corto por cómputo = 2 × Parámetros activos × (Secuencias por réplica + Tokens de prompt en cada paso) ÷ (Cómputo pico, denso × 1.000.000.000.000 × Tamaño de tensor parallel)

    = 2 × Dato introducido: 8190,74 M parámetros × (Dato introducido: 4 + Límite teórico: 26,67 tokens) ÷ (Estimación: 500 TFLOPS × 1.000.000.000.000 × Dato introducido: 1)

    = 1 ms

  3. Paso más corto con esta carga

    Límite teórico

    Paso más corto con esta carga = max(Tiempo mínimo de un paso, Paso más corto por cómputo)

    = max(Límite teórico: 10,73 ms, Límite teórico: 1 ms)

    = 10,73 ms

  4. Límite de tokens de salida de la configuración

    Límite teórico

    Límite de tokens de salida de la configuración = secuencias concurrentes ÷ Paso más corto con esta carga

    = Dato introducido: 4 ÷ Límite teórico: 10,73 ms

    = 372,64 tok/s

  5. Copias de la configuración necesarias como mínimo

    Límite teórico

    Copias de la configuración necesarias como mínimo = ceil(Tokens de salida por segundo necesarios ÷ Límite de tokens de salida de la configuración)

    = ceil(Resultado calculado: 360 tok/s ÷ Límite teórico: 372,64 tok/s)

    = 1

  6. GPU necesarias como mínimo

    Límite teórico

    GPU necesarias como mínimo = Copias de la configuración necesarias como mínimo × número de GPU

    = Límite teórico: 1 × Dato introducido: 1

    = 1

›Solicitudes en curso

  1. Tiempo que tarda una solicitud

    Resultado calculado

    Tiempo que tarda una solicitud = Tiempo hasta el primer token + Tokens generados por solicitud × Tiempo entre tokens

    = Límite teórico: 34,19 ms + Dato introducido: 180 tokens × Límite teórico: 10,73 ms

    = 1,97 s

  2. Solicitudes en curso

    Resultado calculado

    Solicitudes en curso = Solicitudes por segundo × Tiempo que tarda una solicitud

    = Dato introducido: 2 req/s × Resultado calculado: 1,97 s

    = 3,93

Supuestos

  • 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: Ley de Little: las solicitudes en curso equivalen a la tasa de llegada multiplicada por el tiempo que una solicitud pasa en el sistema, el primer token más todos los siguientes.

360 tok/sComo mínimo 1 copia de la configuración, 1 GPU

Por qué importa

Las cifras de hardware no dicen con qué rapidez ejecuta realmente un motor un modelo: las mediciones publicadas de vLLM resultaron de 30 a 270 % más lentas que una fórmula de ancho de banda y cómputo. Así que el hardware da un límite, un mínimo, y un plan necesita un throughput medido en la propia configuración. Prefill y decode comparten las GPU en vLLM por defecto. Separarlos es experimental, y ninguna regla da la proporción, así que aquí una proporción solo sale de tasas medidas.

Cómo leer el resultado

Empiece por la carga: fija los tokens de salida y de prompt por segundo necesarios. El límite de hardware indica cuántas copias de la configuración, como mínimo, podrían soportarla. Introduzca el throughput medido, con la concurrencia a la que se midió, para obtener las copias y las GPU en que se basa un plan. Solicitudes en curso indica si la memoria de una copia aloja tantas secuencias. La sección de prefill y decode lista lo que dice vLLM sobre separarlos y cuenta instancias a partir de tasas medidas.

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