VPS con GPU: cuándo realmente necesitas una

¿Necesitas un VPS con GPU o basta con CPU?

Un VPS con GPU cambia dos aspectos de la ejecución local de un modelo: la velocidad con la que genera tokens y el tamaño máximo del modelo que puede caber en la memoria. No cambia nada más. Si tu carga de trabajo consiste en un modelo de chat cuantizado de 7B a 27B que responde a una persona cada vez, un trabajo de generación de embeddings con poco volumen o la transcripción de voz con Whisper small, un VPS normal con CPU y suficiente RAM ya puede realizar el trabajo. Empieza con CPU, mide el aspecto que te limita y escala después.

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 8B cuantizado a 4 bits ocupa aproximadamente 4.7 GB en disco y una cantidad similar en memoria, por lo que generar un token implica mover unos 4.7 GB. Divide el ancho de banda de memoria de la máquina por esa cantidad y obtendrás el límite superior de tokens por segundo. Esta división explica casi todos los benchmarks que encontrarás.

Lo que realmente aporta una GPU

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

Capacidad con velocidad. Un equipo con CPU y 64 GB de RAM puede cargar un modelo 70B a 4 bits. Funcionará, pero a un ritmo más cercano a la lectura que a una conversación. Una GPU solo ayuda en este caso si el modelo cabe en la VRAM, porque en cuanto las capas pasan a la RAM del sistema, la ruta lenta vuelve a dominar.

Rendimiento por lotes. Esta es la parte que se suele subestimar. Una GPU que genera contenido para un usuario mantiene inactiva la mayor parte de su capacidad de cómputo, porque está esperando a la memoria. Si atiende 20 solicitudes a la vez, la misma lectura de pesos sirve para las 20. El número total de tokens por segundo aumenta varias veces, mientras que la velocidad por usuario apenas disminuye. Una CPU no funciona así. Dos usuarios simultáneos en un equipo con CPU reducen aproximadamente a la mitad el rendimiento de cada uno. Si está creando una API a la que llaman muchos clientes, el procesamiento por lotes es el argumento a favor de una GPU, más que la velocidad bruta de un único flujo.

Procesamiento del prompt. Leer un prompt largo está limitado por el cómputo, no por la memoria, y es aquí donde las GPU ofrecen la mayor ventaja. Un contexto de 30,000 tokens que una CPU procesa en un minuto tarda unos pocos segundos en una GPU. Las configuraciones de recuperación que insertan documentos en cada solicitud lo ponen de manifiesto constantemente.

Cifras aproximadas y cómo interpretarlas

El bloque siguiente contiene cifras publicadas habituales para un modelo 8B con cuantización de 4 bits y una sola secuencia, 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 pueden modificarlas.

[
  {
    "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 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 del 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 contempla.

Como referencia, una persona lee aproximadamente de 5 a 10 palabras por segundo. Una velocidad de 15 tokens por segundo o superior ya se percibe como escritura normal para un solo lector. Por eso, muchas configuraciones que usan solo CPU funcionan correctamente.

Dimensionar la VRAM antes de comprar

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

Una regla práctica a 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 a 4 bits ocupa alrededor de 16 GB y necesita aproximadamente 20 GB. Un modelo 70B a 4 bits ocupa aproximadamente 40 GB y necesita una tarjeta de 48 GB, o dos tarjetas más pequeñas.

Los contextos largos invalidan esta regla. La caché KV crece linealmente con la longitud del contexto y, con 128k tokens, puede superar el tamaño de los pesos. Si planea 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 utilizada del 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 después reiniciar para que se cargue el módulo nuevo.

Para los contenedores, el controlador por sí solo no es suficiente. Docker necesita NVIDIA Container Toolkit para pasar 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

Después, 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 toolkit está instalado, pero Docker nunca se reconfiguró o reinició. Vuelva a ejecutar la línea nvidia-ctk y reinicie Docker. 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

Ejecuta el modelo que realmente piensas usar en el equipo con CPU que ya tienes y registra los valores. Con alojar un LLM en un VPS mediante Ollama solo necesitas un indicador:

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 en tokens por segundo. prompt eval rate indica la velocidad con la que el equipo lee la entrada. Estos dos valores indican qué actualización resulta útil: un valor bajo de eval rate indica un problema de ancho de banda de memoria, mientras que un valor bajo de prompt eval rate con entradas largas indica un problema de capacidad de cálculo.

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

ollama ps

La columna PROCESSOR muestra 100% GPU cuando todo cabe en la GPU, o algo parecido a 43%/57% CPU/GPU cuando no cabe. Una división parcial suele ofrecer un rendimiento peor del esperado, porque cada token sigue esperando a la mitad más lenta.

La cuestión del coste

Las instancias GPU cuestan varias veces más que una instancia CPU comparable y facturan cada hora que están activas, no según los tokens que generan. Una GPU activa permanentemente 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 ocupada tiene un coste bajo por token, mientras que una GPU inactiva es un desperdicio total.

Hay tres patrones válidos. Mantenga las cargas de trabajo estables y de bajo volumen en una 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 combinar estos métodos. La disciplina presupuestaria descrita en Control de costes de agentes de IA en una VPS siempre activa también se aplica aquí, con la diferencia de que la fuga de costes es el tiempo de inactividad, 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 en unos pocos núcleos de CPU, y un índice que se crea una sola vez no necesita generarse rápidamente.

Whisper small y base para transcripción. Faster-whisper en CPU transcribe casi en tiempo real con el modelo small, lo que basta para una canalización 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 duración real es un detalle de programación y no un requisito.

Lo que realmente necesita una GPU: entrenamiento o ajuste fino más allá de un adaptador pequeño, atender a muchos usuarios simultáneos, generación de imágenes y vídeo, y voz en tiempo real cuando la latencia es el producto.

FAQ

¿Cuánta VRAM necesito para un modelo de 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 aproximadamente 4.7 GB. El resto corresponde a la caché KV y a unos 1 GB de sobrecarga. Una tarjeta de 12 GB deja un margen adecuado para contextos más largos. Si planea usar un contexto de 128k, calcule la caché por separado, porque puede crecer más que los pesos.

¿Puedo ejecutar Ollama sin una GPU?

Sí. Ollama cambia automáticamente a la CPU y solo necesita suficiente RAM para contener 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 cálculos y tarda mucho 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 completamente en la VRAM. Por eso, algunas capas se ejecutan en la CPU y cada token espera a la parte más lenta. Ejecute ollama ps y compruebe que la columna PROCESSOR muestra 100% GPU. Si muestra una división, use una cuantización más pequeña o un modelo más pequeño. Otra causa habitual es ejecutar una prueba breve en la que el tiempo de carga del modelo domina la medición.

¿Vale la pena usar una GPU VPS 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 simultáneamente es el argumento más sólido, porque el procesamiento por lotes permite que una GPU responda a veinte solicitudes por un coste cercano al de responder a una sola.

¿Debo alquilar una GPU por horas o mantener una funcionando 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 solo cuando la tarjeta se mantenga ocupada, 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 una CPU VPS o en una API alojada con pago por token que en una GPU inactiva.