VPS con GPU: cuándo realmente necesitas una

¿Necesita un VPS con GPU o es suficiente con CPU?

Un VPS con GPU cambia dos aspectos al ejecutar un modelo por su cuenta: la velocidad a la que se generan los tokens y el tamaño máximo del modelo que cabe en la memoria. No cambia nada más. Si su carga de trabajo consiste en un modelo de chat cuantizado de 7B a 27B que responde a una persona cada vez, en un trabajo de generación de embeddings con poco volumen o en la transcripción de voz con Whisper small, un VPS de CPU normal con suficiente RAM ya puede realizar el trabajo. Empiece con CPU, mida el valor que le está causando problemas y escale después si es necesario.

La razón es el ancho de banda de memoria. Cuando un modelo de lenguaje genera un token, lee de la memoria todos los pesos que necesita. Un modelo de 8B cuantizado a 4 bits ocupa aproximadamente 4.7 GB en disco y casi lo mismo en memoria, por lo que generar un token implica mover unos 4.7 GB. Divida el ancho de banda de memoria de la máquina por esa cantidad y obtendrá el límite máximo de tokens por segundo. Esta división explica prácticamente todos los benchmarks que encontrará.

Qué aporta realmente una GPU

Ancho de banda. La memoria DDR5 de un servidor moderno mueve decenas de gigabytes por segundo. La memoria de la GPU (VRAM, video RAM) mueve cientos o más de mil. La relación entre ambas velocidades determina la aceleración, y es grande.

Capacidad con velocidad. Un equipo con CPU y

Cifras aproximadas y cómo interpretarlas

El bloque siguiente contiene cifras publicadas habituales para una secuencia única de un modelo 8B con cuantización de 4 bits, a fecha de julio de 2026. Sirven como orientación del orden de magnitud, no como garantía. La cuantización, la longitud del contexto y el motor de inferencia modificarán estos valores.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

La fila de la GPU de 24 GB muestra 50 tokens por segundo, frente a 11 en un equipo con CPU y DDR5. Es aproximadamente cinco veces más, lo que coincide con la relación de ancho de banda y no con una diferencia en la capacidad de cálculo bruta. El rendimiento real también queda por debajo de ancho de banda dividido por el tamaño del modelo, porque la atención sobre un contexto creciente añade trabajo que esa división sencilla no tiene en cuenta.

Como referencia, una persona lee aproximadamente entre 5 y 10 palabras por segundo. Cualquier velocidad de 15 tokens por segundo o superior ya se percibe como una escritura normal para un solo lector. Por eso muchas configuraciones que sólo usan CPU funcionan correctamente sin llamar la atención.

Calcular la VRAM antes de comprar

El tamaño del archivo del modelo es el mínimo necesario, no el requisito real. Reserve memoria para los pesos, la caché KV (caché de clave-valor, la memoria que la atención mantiene para cada token) y aproximadamente 1 GB adicional para sobrecarga.

Una regla práctica a fecha de julio de 2026: tome el tamaño del archivo del modelo en gigabytes y añada un 20 por ciento para un contexto normal de 8k a 16k. Un modelo 8B de 4.7 GB necesita aproximadamente 6 GB de VRAM. Un modelo 27B de 4 bits ocupa alrededor de 16 GB y necesita aproximadamente 20 GB. Un modelo 70B de 4 bits ocupa unos 40 GB y necesita una tarjeta de 48 GB o dos tarjetas más pequeñas. El mismo cálculo sigue siendo válido con tamaños mucho mayores, y el cálculo de VRAM para un modelo de 2.8 billones de parámetros como Kimi K3 muestra cuándo elegir una tarjeta deja de ser la cuestión principal.

Los contextos largos invalidan esta regla. La caché KV crece de forma lineal con la longitud del contexto y, con 128k tokens, puede superar a los propios pesos. Si piensa usar contextos largos, dimensione primero la caché y compruebe qué opciones de cuantización de caché ofrece su motor.

Compruebe qué tiene realmente la máquina

En una instancia con GPU, confirme primero que el controlador detecta la tarjeta.

nvidia-smi

Debe aparecer una tabla con el nombre de la GPU, la versión del controlador y la memoria usada de un total disponible. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver significa que falta el controlador o que el módulo del kernel no se volvió a compilar después de actualizar el kernel. En una imagen estándar de Ubuntu, la solución suele ser sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install y reiniciar después para cargar el módulo nuevo.

Para los contenedores, el controlador por sí solo no basta. Docker necesita NVIDIA Container Toolkit para exponer el dispositivo al contenedor.

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 && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

A continuación, compruebe que el paso del dispositivo funciona desde dentro de un contenedor:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

Debe aparecer la misma tabla. Una línea docker: Error response from daemon: could not select device driver que indique una capacidad de GPU que no puede satisfacer significa que el kit de herramientas está instalado, pero Docker no se reconfiguró o no se reinició. Vuelva a ejecutar la línea nvidia-ctk y reinicie el servicio. En Compose, el equivalente es una entrada deploy.resources.reservations.devices cuyo driver sea nvidia y cuya lista de capacidades contenga gpu. Esta entrada se integra en las definiciones de servicio habituales descritas en Docker Compose en un VPS.

Mida antes de actualizar

Ejecute el modelo que realmente pretende usar en el equipo con CPU que ya tiene y registre los valores. Con Ollama: aloje un LLM en un VPS sólo necesita una opción:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

La salida termina con los tiempos. eval rate es la velocidad de generación, expresada en tokens por segundo. prompt eval rate indica la velocidad a la que el equipo leyó la entrada. Estos dos valores muestran qué actualización resulta útil: un eval rate bajo indica un problema de ancho de banda de memoria, mientras que un prompt eval rate bajo con entradas largas indica un problema de capacidad de cálculo.

En un equipo con GPU, compruebe que el modelo se haya cargado realmente en ella:

ollama ps

La columna PROCESSOR muestra 100% GPU cuando todo cabe, o un valor como 43%/57% CPU/GPU cuando no cabe. Una distribución parcial suele rendir peor de lo esperado, porque cada token sigue esperando a la parte más lenta.

La cuestión del coste

Las instancias GPU cuestan varias veces más que una instancia CPU comparable y se facturan por cada hora que están activas, no por los tokens que producen. Una GPU activa que atiende unas pocas solicitudes al día es la forma más cara de ejecutar inferencias. El punto de equilibrio es la utilización: una GPU con mucha carga tiene un coste bajo por token y una GPU inactiva es puro desperdicio.

Hay tres patrones prácticos. Mantenga el trabajo estable de poco volumen en un VPS CPU. Envíe las solicitudes difíciles ocasionales a una API alojada y pague por token. Alquile una GPU por horas para trabajos por lotes, ajuste fino o una ejecución masiva de embeddings y destrúyala después. Es normal combinarlos. La disciplina presupuestaria descrita en Control de costes de un agente de IA en un VPS siempre activo también se aplica aquí, con la diferencia de que la fuga de costes es el tiempo de inactividad y no el recuento de tokens.

Qué sigue funcionando bien sin una GPU

Embeddings con un volumen bajo. Un modelo de embeddings pequeño procesa cientos de documentos cortos por minuto con unos pocos núcleos de CPU, y un índice que se construye una sola vez no necesita ser rápido.

Whisper small y base para transcripción. Faster-whisper en CPU transcribe casi en tiempo real con el modelo small, lo que basta para un pipeline que se ejecuta durante la noche.

Modelos de chat cuantizados de hasta aproximadamente 27B para uno o dos usuarios. Son lentos, pero legibles y utilizables.

Cualquier tarea que se pueda ejecutar como un trabajo por lotes. Si nadie está mirando la pantalla, la velocidad de ejecución es una cuestión de planificación y no un requisito.

Lo que realmente necesita una GPU: entrenamiento o fine-tuning más allá de un adaptador pequeño, atender a muchos usuarios simultáneos, generar imágenes y vídeo, y procesar voz en tiempo real cuando la latencia forma parte del producto.

FAQ

¿Cuánta VRAM necesito para un modelo 7B u 8B?

Aproximadamente 6 GB para un modelo 8B cuantizado a 4 bits con un contexto normal de 8k a 16k. Los pesos ocupan unos 4.7 GB. El resto corresponde a la caché KV y a aproximadamente 1 GB de sobrecarga. Una tarjeta de 12 GB deja un margen adecuado para contextos más largos. Si piensa usar un contexto de 128k, calcule la caché por separado, porque puede crecer más que los pesos.

¿Puedo ejecutar Ollama sin GPU?

Sí. Ollama cambia automáticamente a la CPU y sólo necesita suficiente RAM para cargar el modelo. Espere aproximadamente entre 5 y 12 tokens por segundo para un modelo 8B de 4 bits, según la velocidad de la memoria. Esto se aproxima a la velocidad de lectura de un usuario. Los prompts largos son el principal problema en la CPU, porque leer 30,000 tokens de contexto requiere muchos recursos de cómputo y tarda bastante más que generar la respuesta.

¿Por qué mi GPU apenas es más rápida que la CPU?

La causa habitual es que el modelo no cabe por completo en la VRAM. Por eso, algunas capas se ejecutan en la CPU y cada token tiene que esperar a la parte más lenta. Ejecute ollama ps y compruebe que la columna PROCESSOR muestre 100% GPU. Si aparece una división, use una cuantización más pequeña o un modelo más pequeño. Otra causa común es una prueba corta en la que el tiempo de carga del modelo domina la medición.

¿Vale la pena usar un VPS con GPU para un solo usuario?

Por lo general, no. Una persona lee entre 5 y 10 palabras por segundo, y un equipo con CPU ya genera tokens más rápido que eso para modelos de hasta aproximadamente 13B. Los casos que justifican el coste para un solo usuario son los prompts largos, la generación de imágenes y el fine-tuning. Atender a muchos usuarios al mismo tiempo es el argumento más sólido, porque el batching permite que una GPU responda a veinte solicitudes por un coste similar al de responder a una sola.

¿Debo alquilar una GPU por horas o mantener una encendida permanentemente?

Alquílela por horas cuando el trabajo sea intermitente: fine-tuning, una ejecución masiva de embeddings o un trabajo de transcripción por lotes. Manténgala encendida permanentemente sólo cuando la tarjeta esté ocupada de forma continua, porque una instancia con GPU se factura por estar activa, no por los tokens generados. Un asistente con poco tráfico resulta más barato en un VPS con CPU o en una API alojada con pago por token que en una GPU inactiva.