Cuántas GPU se necesitan para LLM: tabla modelo → VRAM → tarjeta gráfica

Qué configuramos y para qué

En esta guía levantaremos nuestro propio servidor de inferencia LLM: el modelo funciona en una GPU, recibe solicitudes mediante API, responde en un formato compatible con OpenAI y puede utilizarse mediante una interfaz web, un bot, un plugin de IDE, un sistema RAG o un SaaS interno. Como inference engine se utilizará vLLM: gestiona eficientemente la caché KV, admite batching de solicitudes y es adecuado para modelos de las familias Llama, Qwen, Mistral, Gemma, DeepSeek y muchas otras.

La tarea principal antes de la instalación es calcular correctamente la GPU. Un error de estimación suele verse así: el modelo «casi cabe» en la VRAM, pero el servidor finaliza con CUDA out of memory durante el primer diálogo largo, con varios usuarios o al habilitar un contexto amplio. Por ello, se debe calcular no solo el volumen de los pesos, sino también la memoria para el runtime.

De qué se compone el consumo de VRAM

El consumo de memoria durante la inferencia LLM puede representarse así:

VRAM = pesos del modelo + caché KV + grafos CUDA y búferes de trabajo + margen

• Pesos del modelo — parámetros de la red neuronal. Es la parte principal, pero no la única.
• Caché KV — memoria del historial de diálogo. Crece con la longitud del contexto y el número de solicitudes paralelas.
• Búferes de trabajo — memoria temporal para CUDA, operaciones de attention, cargador y compilación de grafos.
• Margen — reserva práctica del 10–20% que reduce la probabilidad de OOM durante solicitudes pico.

En FP16 o BF16, un parámetro ocupa 2 bytes. Por lo tanto, un modelo de 8B requiere alrededor de 16 GB solo para los pesos sin procesar. En la práctica, para FP16 8B se necesita una tarjeta de al menos 20–24 GB, porque también quedan la caché KV y la memoria de servicio. Con cuantización Q4, los mismos pesos suelen ocupar 5–6 GB, pero el consumo final aun así puede ser de 8–12 GB.

Tabla: modelo → VRAM → GPU adecuada

A continuación se presentan referencias prácticas para un servicio de un solo usuario o de baja carga con un contexto de hasta 8–16 mil tokens. Los valores no son especificaciones oficiales: el consumo concreto depende de la arquitectura, el formato GGUF/AWQ/GPTQ/FP8, la versión del motor, la longitud del contexto y los parámetros de inicio.

Para los modelos Mixture of Experts no se debe tomar como referencia solo el número de parámetros activos. Por ejemplo, un MoE puede activar relativamente pocos expertos por token, pero para la inferencia normalmente los pesos de todos los expertos deben estar en memoria. Por ello, un modelo etiquetado como «8×7B» puede requerir bastante más VRAM que un modelo dense de 7B.

Cómo elegir la cuantización

Para el primer servidor, una estrategia razonable es la siguiente: si tiene 24 GB de VRAM, comience con Qwen 32B en Q4 o con 8–14B en BF16. La primera opción ofrece un modelo más potente; la segunda, mayor velocidad, contexto más largo y más usuarios paralelos. Para programación, respuestas en ruso y RAG, asegúrese de comparar los modelos con sus propios documentos: el tamaño de los parámetros por sí solo no garantiza un mejor resultado.

Self-hosted, API gestionada o híbrido

Una API gestionada es conveniente si la carga es impredecible, necesita un inicio rápido o no desea administrar una GPU. Sus desventajas son el coste con un gran volumen de tokens, la dependencia de un servicio externo y la transferencia de datos fuera del perímetro.

Una LLM self-hosted en un servidor GPU se justifica cuando las solicitudes contienen código interno, datos personales, documentos comerciales o cuando la carga es suficientemente constante. Usted controla el modelo, el retention de registros, los límites, la versión de la API y los gastos. El enfoque híbrido también es práctico: un modelo local de 8–32B procesa el flujo principal, mientras que las solicitudes complejas poco frecuentes se enrutan a una API externa.

Qué configuración de VPS se necesita para esta tarea

Un VPS normal sin GPU no es adecuado para una inferencia LLM rápida: es posible ejecutar el modelo en CPU, pero la generación de 32B o 70B será demasiado lenta para un chat interactivo. Se necesita un GPU VPS, una instancia GPU cloud o un servidor dedicated con una tarjeta gráfica asignada. Compruebe que la GPU esté dedicada íntegramente a usted o disponga de VRAM garantizada, y que el controlador NVIDIA esté disponible dentro de la máquina virtual.

Para comenzar con un modelo de 8–14B en Q4 o BF16, es razonable disponer de un servidor con una GPU de 24 GB de VRAM, 8 vCPU, 64 GB de RAM y 200 GB de NVMe. Como una de las opciones, puede elegir un VPS con las características indicadas, si la instancia seleccionada realmente proporciona una GPU NVIDIA con 24 GB de memoria de vídeo.

Por qué la RAM del sistema también es importante

La memoria del sistema no sustituye la VRAM en la inferencia GPU. El offload de una parte del modelo a RAM es posible en llama.cpp, pero reduce drásticamente la velocidad debido a la transferencia de datos por PCIe. La RAM es necesaria para el sistema operativo, Docker, la carga del modelo, los tokenizadores, la base de datos vectorial, las cachés y la descarga de archivos. Para una GPU con 24 GB, 32 GB de RAM es el mínimo, pero para un servidor RAG estable es mejor contar con 64 GB.

Cuándo se necesita dedicated en lugar de VPS

Dedicated es preferible con dos o más GPU, cuando se necesita NVLink, controladores no estándar, carga 24/7 con rendimiento predecible o almacenamiento de grandes conjuntos de modelos. Las GPU virtuales pueden tener limitaciones de P2P, MIG, power limit y ancho de banda PCIe. Para una sola tarjeta de 24–48 GB y una carga moderada, un GPU VPS suele ser más sencillo y económico de operar.

Si planea usar tensor parallel para un modelo de 70B en dos GPU, compruebe la topología con el comando nvidia-smi topo -m. La conexión NVLink es preferible, pero PCIe también funciona; simplemente la latencia y la velocidad de generación pueden ser peores. No combine tarjetas con cantidades de VRAM muy diferentes: el modelo estará limitado por la tarjeta más pequeña y surgirán esquemas de distribución ineficientes.

Ubicación y latencia

La ubicación afecta a la latencia hasta el primer byte de la respuesta, no a la velocidad de generación de tokens en sí. Para usuarios de Europa, normalmente elija un centro de datos europeo; para usuarios de Rusia y la CEI, un punto con buena conectividad de red con sus operadores. Si el servidor recibe documentos mediante un pipeline RAG o accede a bases de datos internas, ubíquelo más cerca de estos sistemas. Tenga en cuenta los requisitos legales relativos a los datos personales y a la ubicación de almacenamiento de las copias de seguridad.

Preparación del servidor

A continuación se utiliza Ubuntu Server 24.04 LTS. Esta versión es adecuada para las ramas actuales de Docker, NVIDIA Container Toolkit, CUDA 12.x y las imágenes modernas de vLLM. Realice la configuración inicial desde la consola del proveedor o mediante SSH con un usuario que tenga permisos de root.

Cree un administrador independiente

# Создаёт пользователя llmadmin, добавляет его в группу sudo и готовит каталог SSH.
adduser llmadmin
usermod -aG sudo llmadmin
install -d -m 700 -o llmadmin -g llmadmin /home/llmadmin/.ssh

Añada la clave SSH pública al archivo /home/llmadmin/.ssh/authorized_keys. No copie la clave privada al servidor ni la almacene en imágenes de Docker o en el repositorio.

# Записывает публичный ключ администратора и задаёт безопасные права доступа.
nano /home/llmadmin/.ssh/authorized_keys
chown llmadmin:llmadmin /home/llmadmin/.ssh/authorized_keys
chmod 600 /home/llmadmin/.ssh/authorized_keys

Actualice el sistema e instale las utilidades básicas

# Обновляет пакеты Ubuntu и устанавливает утилиты диагностики, firewall и fail2ban.
apt update && apt full-upgrade -y
apt install -y ca-certificates curl gnupg lsb-release jq htop nvtop \
  ufw fail2ban unattended-upgrades git vim

Después de la actualización, reinicie el servidor, especialmente si se actualizó el kernel. Luego vuelva a conectarse con el usuario creado y asegúrese de que sudo funciona.

# Перезагружает сервер, чтобы применить обновлённое ядро и драйверы.
reboot

Configure SSH y el firewall

Primero asegúrese de que el acceso mediante clave funciona en un segundo terminal. Solo después desactive la autenticación mediante contraseña. Si comete un error en la configuración de SSH, podrá recuperar el acceso mediante la consola out-of-band.

# Отключает root-вход и парольную аутентификацию, оставляя вход только по SSH-ключу.
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
AllowUsers llmadmin
EOF

sudo sshd -t && sudo systemctl restart ssh

# Открывает только SSH, HTTP и HTTPS; API vLLM наружу не публикуется.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable
sudo systemctl enable --now fail2ban

No exponga a Internet el puerto de vLLM, normalmente 8000. Este escuchará únicamente en 127.0.0.1, mientras que el acceso externo se realizará mediante Caddy con TLS y una clave de API. Esto protege el servidor frente a un inference público accidental, que puede agotar rápidamente la VRAM y el tráfico.

Compruebe la GPU antes de instalar los contenedores

# Показывает модель GPU, объём VRAM, драйвер NVIDIA и активные процессы.
nvidia-smi

Si no se encuentra el comando o no muestra la tarjeta, instale primero el controlador NVIDIA recomendado desde el repositorio de Ubuntu o consulte la documentación de la plataforma. No instale CUDA Toolkit únicamente para vLLM: el contenedor de vLLM incluye el userspace CUDA necesario, mientras que en el host es fundamental contar con un controlador NVIDIA compatible.

Instalación del software paso a paso

Para un arranque similar a production, utilice Docker Compose. Este aísla las dependencias, simplifica las actualizaciones y permite fijar la versión de la imagen de forma reproducible. En 2026, las ramas actuales de Docker Engine 28+, NVIDIA Container Toolkit 1.17+ y vLLM 0.10+ deben verificarse en las release notes oficiales antes de actualizar un servidor de production.

Instale Docker Engine

# Добавляет официальный репозиторий Docker для Ubuntu 24.04.
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Устанавливает Docker Engine, Compose plugin и containerd из официального репозитория.
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER
newgrp docker

Compruebe que Docker funciona sin sudo. Ejecute el comando newgrp docker únicamente en la sesión actual; después de un nuevo acceso SSH, el grupo se aplicará automáticamente.

# Запускает тестовый контейнер и проверяет доступ пользователя к Docker daemon.
docker run --rm hello-world

Instale NVIDIA Container Toolkit

# Добавляет официальный репозиторий NVIDIA Container Toolkit.
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

# Устанавливает runtime NVIDIA и перезапускает Docker с поддержкой GPU-контейнеров.
sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Проверяет, что контейнер видит GPU и драйвер хоста.
docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi

La etiqueta de la imagen CUDA puede cambiar tras el lanzamiento de nuevas versiones. Lo más importante es que la versión del controlador en el host sea compatible con el CUDA runtime dentro del contenedor. Si el comando de prueba termina con un error de compatibilidad, actualice el controlador NVIDIA del host en lugar de intentar copiar manualmente las bibliotecas CUDA al contenedor.

Cree la estructura de trabajo

# Создаёт отдельный каталог, где будут compose-файл, секреты и конфигурация Caddy.
sudo mkdir -p /opt/llm-server/{caddy-data,caddy-config}
sudo chown -R $USER:$USER /opt/llm-server
cd /opt/llm-server
umask 077

Para el primer arranque utilizaremos un modelo instruct de 8B en formato Hugging Face. Para modelos cerrados o gated se necesitará un token de Hugging Face con permisos para descargar el modelo. Para modelos públicos no es necesario indicar un token, pero sigue siendo imprescindible limitar el acceso de los clientes mediante una clave de API.

# Генерирует секретный ключ для клиентов API и создаёт файл переменных окружения.
openssl rand -hex 32
nano /opt/llm-server/.env
chmod 600 /opt/llm-server/.env

Añada la clave generada al archivo .env. No publique este archivo ni lo añada a Git.

VLLM_API_KEY=вставьте_сюда_случайную_строку_из_64_символов
HF_TOKEN=
DOMAIN=llm.example.com

Configuración

La configuración siguiente ejecuta vLLM en localhost y Caddy en los puertos públicos 80/443. Caddy obtiene y renueva automáticamente el certificado de Let’s Encrypt si el registro A/AAAA del dominio ya apunta a la IP del servidor y los puertos 80 y 443 están disponibles desde el exterior.

Cree el archivo Docker Compose

El ejemplo está diseñado para una GPU de 24 GB y un modelo de 8B. El parámetro gpu_memory_utilization se ha establecido deliberadamente en 0.88 y no en 1.0: esta reserva reduce el riesgo de OOM. Para GPU de 48–80 GB y una mayor carga, puede aumentar gradualmente el valor hasta 0.92–0.95, después de probar previamente el servidor con una prueba prolongada.

services:
  vllm:
    image: vllm/vllm-openai:v0.10.0
    container_name: vllm
    restart: unless-stopped
    env_file:
      - .env
    environment:
      HF_TOKEN: ${HF_TOKEN}
      NVIDIA_VISIBLE_DEVICES: all
      NVIDIA_DRIVER_CAPABILITIES: compute,utility
    command:
      - --model
      - Qwen/Qwen2.5-7B-Instruct
      - --served-model-name
      - qwen-7b
      - --host
      - 127.0.0.1
      - --port
      - "8000"
      - --api-key
      - ${VLLM_API_KEY}
      - --dtype
      - auto
      - --max-model-len
      - "8192"
      - --gpu-memory-utilization
      - "0.88"
      - --max-num-seqs
      - "8"
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - huggingface-cache:/root/.cache/huggingface
    gpus: all
    ipc: host

  caddy:
    image: caddy:2.10.0-alpine
    container_name: caddy
    restart: unless-stopped
    depends_on:
      - vllm
    env_file:
      - .env
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-data:/data
      - ./caddy-config:/config

volumes:
  huggingface-cache:

La etiqueta de la imagen está fijada deliberadamente para evitar que una actualización se produzca automáticamente y rompa la API o la compatibilidad con CUDA. Antes de utilizarla, compruebe que la etiqueta indicada esté disponible en el registro oficial de vLLM. Después de las pruebas, actualice la versión de forma controlada durante una maintenance window.

Cree el Caddyfile

{$DOMAIN} {
    encode zstd gzip

    @api path /v1/ /health
    handle @api {
        reverse_proxy vllm:8000
    }

    respond "LLM API is available at /v1" 200
}

# Скачивает образы, запускает контейнеры в фоне и показывает их текущее состояние.
cd /opt/llm-server
docker compose up -d
docker compose ps

# Показывает поток логов vLLM; Ctrl+C завершает только просмотр, а не контейнер.
docker compose logs -f vllm

# Проверяет, что модель загружена, а GPU-память занята процессом контейнера.
nvidia-smi
curl -s http://127.0.0.1:8000/v1/models \
  -H "Authorization: Bearer $(grep VLLM_API_KEY .env | cut -d= -f2)" | jq

# Отправляет тестовый chat completion через публичный HTTPS endpoint.
export API_KEY="$(grep VLLM_API_KEY /opt/llm-server/.env | cut -d= -f2)"

curl -sS https://llm.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $API_KEY" \
  -d '{
    "model": "qwen-7b",
    "messages": [
      {"role": "system", "content": "Отвечай кратко и по-русски."},
      {"role": "user", "content": "Объясни, что такое KV-кэш в LLM."}
    ],
    "temperature": 0.3,
    "max_tokens": 180
  }' | jq '.choices[0].message.content'

# Перезапускает только vLLM после изменения compose-файла и показывает последние сообщения старта.
cd /opt/llm-server
docker compose up -d --force-recreate vllm
docker compose logs --tail=100 vllm

Copias de seguridad y mantenimiento

Por lo general, los pesos del modelo no necesitan copiarse en una copia de seguridad diaria: son grandes, se pueden descargar de forma reproducible desde el repositorio oficial y pueden ocupar decenas o cientos de gigabytes. Pero si utiliza su propio modelo ajustado, adaptadores LoRA, un checkpoint privado o archivos cuantizados preparados manualmente, es obligatorio hacer una copia de seguridad de estos datos.

Qué se debe respaldar

• La configuración: compose.yaml, Caddyfile, units de systemd, scripts de despliegue.
• Los secretos: el archivo .env, preferiblemente en un almacenamiento cifrado.
• Los datos TLS de Caddy: el directorio caddy-data, para conservar los certificados y la cuenta ACME.
• Modelos propios y LoRA: un directorio o volume independiente con sumas de comprobación.
• Datos RAG: la base de datos vectorial, los documentos fuente, los metadatos, PostgreSQL/SQLite si están disponibles.
• Registros de auditoría: solo si lo permite la política de privacidad; no guarde los prompts de los usuarios indefinidamente sin motivo.

Copia de seguridad sencilla mediante restic en S3

Restic cifra los datos en el servidor antes de enviarlos al almacenamiento compatible con S3. Guarde los secretos de acceso a S3 y la contraseña del repositorio en un archivo accesible solo por root. Antes de activar cron, compruebe manualmente la restauración de al menos un archivo.

# Instala restic y crea un directorio para los parámetros privados de copia de seguridad.
sudo apt install -y restic
sudo install -d -m 700 /root/.config/restic
sudo nano /root/.config/restic/llm-backup.env
sudo chmod 600 /root/.config/restic/llm-backup.env

RESTIC_REPOSITORY=s3:https://s3.example.net/llm-backups
RESTIC_PASSWORD=contraseña_larga_y_única_del_repositorio
AWS_ACCESS_KEY_ID=access_key
AWS_SECRET_ACCESS_KEY=secret_key

# Inicializa un repositorio restic cifrado en el almacenamiento remoto S3.
sudo bash -c 'source /root/.config/restic/llm-backup.env && restic init'

# Crea un script de copia de seguridad para la configuración, los datos TLS y los modelos personalizados.
sudo tee /usr/local/sbin/backup-llm.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
source /root/.config/restic/llm-backup.env

restic backup \
  /opt/llm-server/compose.yaml \
  /opt/llm-server/Caddyfile \
  /opt/llm-server/.env \
  /opt/llm-server/caddy-data \
  /srv/llm-models \
  --exclude-caches

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
EOF

sudo chmod 700 /usr/local/sbin/backup-llm.sh
sudo /usr/local/sbin/backup-llm.sh

Si el directorio /srv/llm-models no existe, elimínelo del script o créelo para sus propios modelos. El Docker named volume con la caché de Hugging Face no se respalda deliberadamente en este ejemplo: es una caché que puede descargarse de nuevo. Para modelos privados que puedan desaparecer del acceso externo, guarde una copia verificada en un directorio independiente que se respalde.

# Añade una ejecución diaria a las 03:25 y escribe el registro en un archivo de log del sistema protegido.
echo '25 3    root /usr/local/sbin/backup-llm.sh >> /var/log/llm-backup.log 2>&1' | \
  sudo tee /etc/cron.d/llm-backup

Verificación de la restauración

# Muestra las instantáneas y restaura la configuración en un directorio de prueba sin sobrescribir production.
sudo bash -c 'source /root/.config/restic/llm-backup.env && restic snapshots'
sudo mkdir -p /tmp/llm-restore
sudo bash -c 'source /root/.config/restic/llm-backup.env && restic restore latest --target /tmp/llm-restore'

Una copia de seguridad que no funciona es peor que no tener ninguna: crea una falsa sensación de seguridad. Una vez al mes, compruebe que los secretos, la configuración y los modelos propios realmente se restauran en otra máquina o en un directorio de prueba.

Actualizaciones y maintenance window

Las actualizaciones del controlador NVIDIA, Docker, vLLM y el modelo pueden cambiar el rendimiento, el formato de la API y el uso de VRAM. Para un único servidor, utilice una maintenance window: detenga el tráfico entrante, haga una copia de seguridad, actualice un componente, realice un smoke test y solo entonces vuelva a poner el servicio en funcionamiento.

Es posible realizar una rolling update con dos instancias independientes detrás de un reverse proxy o balanceador: primero se actualiza un nodo, pasa las pruebas y luego se dirige el tráfico hacia él. No utilice la actualización automática de la etiqueta latest para el inference engine: incluso una versión menor puede requerir un nuevo controlador o cambiar el comportamiento de la cuantización.

Solución de problemas + FAQ

¿Qué configuración de VPS es mínimamente adecuada?

Para una primera LLM de 7–8B en Q4 se necesita como mínimo una GPU con 12 GB de VRAM, 4 vCPU, 16–32 GB de RAM y 80 GB de NVMe. Esta opción es adecuada para un usuario, contexto corto y experimentos. Para un chatbot estable, RAG y modelos de 8–14B, es más práctico optar de inmediato por 24 GB de VRAM, 8 vCPU, 64 GB de RAM y 200 GB de NVMe. La RAM del sistema no compensa la falta de VRAM sin una caída importante de velocidad.

vLLM termina con CUDA out of memory. ¿Qué comprobar?

Primero ejecute nvidia-smi y compruebe que la GPU no esté ocupada por otro proceso. Después reduzca --max-model-len, por ejemplo de 8192 a 4096, y disminuya --max-num-seqs. Precisamente la caché KV suele provocar OOM después de cargar correctamente los pesos. Reduzca --gpu-memory-utilization a 0.80–0.85 si el error aparece al inicializar los grafos. Si no es suficiente, utilice una versión AWQ/GPTQ/FP8/Q4 del modelo o una GPU con más VRAM.

El contenedor no ve la GPU e informa «could not select device driver».

Compruebe la GPU en el host con el comando nvidia-smi. Si no funciona, el problema está en el controlador NVIDIA o en la configuración de la GPU del VPS. Si todo está correcto en el host, asegúrese de que NVIDIA Container Toolkit esté instalado, de haber ejecutado el comando nvidia-ctk runtime configure --runtime=docker y de haber reiniciado Docker. Después pruebe el contenedor CUDA con el comando de la sección de instalación. Ejecute vLLM solo después de que la prueba tenga éxito.

El modelo se carga, pero responde muy lentamente. ¿Cómo encontrar la causa?

Compare la velocidad de tokens por segundo en los logs de vLLM y la carga de la GPU mediante nvtop o nvidia-smi dmon. Si la GPU tiene poca carga, compruebe si se está produciendo CPU-offload o si el contenedor está limitado por CPU. Si la GPU está cargada al 100%, el modelo o el contexto son demasiado grandes para la latencia deseada. Utilice un modelo más compacto, reduzca el contexto, active la cuantización o implemente una GPU más potente. Para varias solicitudes, vLLM suele ser más eficiente que una ejecución secuencial convencional.

¿Por qué 70B Q4 no cabe en una GPU de 48 GB, aunque el archivo tenga unos 40 GB?

El tamaño del archivo en disco no equivale al uso máximo de VRAM. Tras la carga se añaden metadatos de cuantización, caché KV, búferes de attention, grafos CUDA y fragmentación de memoria. En una tarjeta de 48 GB, 70B Q4 puede iniciarse solo con un contexto muy corto y paralelismo mínimo, pero es una configuración inestable. Para un uso práctico de 70B Q4, es mejor orientarse a 80 GB de VRAM o a dos GPU con tensor parallel correctamente configurado.

¿Qué elegir: VPS o dedicated para esta tarea?

Un GPU VPS es práctico para una sola GPU, pruebas, modelos de 8–32B y carga variable: es más fácil de desplegar o desactivar rápidamente. Dedicated es mejor con carga alta constante, dos o más GPU, requisitos de NVLink, gran NVMe local y rendimiento predecible. Si solo está comprobando la viabilidad económica del producto, empiece con un VPS. Si el servidor ya atiende usuarios constantemente y la GPU está cargada la mayor parte del día, compare el coste con una configuración dedicated.

¿Se puede ejecutar un modelo en varias GPU con distinta capacidad de memoria?

Técnicamente, algunos motores y esquemas de offload lo permiten, pero para production esta combinación no es recomendable. Tensor parallel distribuye capas o tensores entre las tarjetas, y la GPU más débil o con menor capacidad se convierte en un cuello de botella. Una arquitectura de GPU diferente también puede limitar dtype, FlashAttention y el rendimiento. Para 70B, es mejor utilizar tarjetas idénticas con la misma cantidad de VRAM, los mismos controladores y la conexión entre GPU más rápida posible.

¿Cómo abrir de forma segura la API para una aplicación sin convertirla en una LLM pública y gratuita?

No publique el puerto 8000 directamente: vincúlelo a 127.0.0.1. Exponga al exterior solo HTTPS mediante Caddy y active la clave API de vLLM. Además, limite el acceso mediante reglas de firewall por IP si los clientes tienen direcciones estáticas, o utilice WireGuard para una API interna. No envíe la clave al navegador de la aplicación frontend: el navegador debe comunicarse con su backend y el backend con la API de la LLM.

Conclusiones y próximos pasos

Ha obtenido un esquema práctico para elegir una GPU para LLM y un servidor vLLM básico y protegido con API HTTPS. Para la mayoría de las tareas personales y de equipos pequeños, el punto de partida óptimo sigue siendo una GPU con 24 GB de VRAM: permite elegir entre modelos rápidos de 8–14B en BF16 y modelos más grandes en Q4.

1. Pruebe 2–3 modelos con solicitudes reales, no solo con benchmarks públicos.
2. Añada métricas de tiempo de respuesta, tokens/sec, uso de VRAM y número de errores OOM.
3. Cuando aumente la carga, separe la API, la base de datos vectorial RAG y la inferencia en nodos independientes o añada una segunda instancia de GPU detrás de un balanceador.