VPS con GPU: cuándo realmente necesitas una

¿Necesita 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 a la que se generan los tokens y el tamaño máximo del modelo que cabe en 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, una tarea de embeddings de bajo volumen o transcripción de voz con Whisper small, un VPS con CPU y suficiente RAM ya puede realizar el trabajo. Empiece con CPU, mida el valor que le limita y amplíe a partir de ahí.

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.9 GB en disco y casi lo mismo en memoria, por lo que generar un token implica mover unos 4.9 GB. Divida el ancho de banda de memoria de la máquina por ese valor y obtendrá el límite máximo de tokens por segundo. Esa única división explica casi todos los benchmarks que encontrará.

Lo que realmente aporta una GPU

Ancho de banda. La DDR5 de servidor en un host moderno mueve decenas de gigabytes por segundo. La memoria de la GPU (VRAM, memoria de vídeo) mueve cientos o más de mil. Esa relació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 próximo al de leer que al de conversar. Una GPU sólo ayuda si el modelo cabe en la VRAM, porque en cuanto las capas pasan a la RAM del sistema, la ruta lenta vuelve a controlar el rendimiento.

Rendimiento por lotes. Esta es la parte que se suele subestimar. Una GPU que genera contenido para un usuario deja 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 agregado de tokens por segundo aumenta varias veces, mientras que la velocidad por usuario apenas disminuye. Los motores de inferencia en CPU, como llama.cpp, también admiten procesamiento por lotes, con mejoras que dependen del hardware y de la carga de trabajo. Si está construyendo 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 aquí es donde las GPU ofrecen la mayor ventaja. Un contexto de 30,000 tokens que una CPU procesa en un minuto tarda unos segundos en una GPU. Las configuraciones de recuperación que introducen documentos en cada solicitud lo ponen de manifiesto constantemente.

Cifras aproximadas y cómo interpretarlas

El rendimiento real también queda por debajo de dividir el ancho de banda entre el tamaño del modelo, porque la atención sobre un contexto cada vez mayor añade trabajo que esa división sencilla no tiene en cuenta.

Como referencia, la lectura silenciosa de adultos en inglés alcanza una media de unos 4.0 a 4.3 words per second: 238 words per minute en textos no narrativos y 260 en ficción. Cualquier velocidad igual o superior a 15 tokens per second ya se percibe como una velocidad de escritura normal para un único lector. Por eso, muchas configuraciones CPU-only funcionan correctamente sin llamar la atención.

Dimensionar la VRAM antes de comprar

El tamaño del archivo del modelo es el mínimo, no el requisito real. Reserve espacio 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 de sobrecarga.

Calcule la caché en lugar de añadir un porcentaje fijo, porque cuantificar los pesos no cuantifica la caché. Para cada token, un modelo con atención completa almacena una clave y un valor por cada capa y cada cabeza KV, a 2 bytes por número en FP16, que es el tipo de caché predeterminado de Ollama. Los metadatos del modelo de Ollama, comprobados el 2026-10-27, indican que Llama 3.1 8B tiene 32 capas y 8 cabezas KV de 128 dimensiones, lo que equivale a 128 KiB por token: aproximadamente 1.07 GB con un contexto de 8k y 2.15 GB con 16k. Por tanto, un modelo 8B de 4.9 GB necesita aproximadamente 7 GB de VRAM con 8k y aproximadamente 8 GB con 16k. Un modelo 27B a 4 bits ocupa alrededor de 17 GB (Gemma 3 27B en la biblioteca de Ollama). Los metadatos de Gemma 3 indican una ventana deslizante de 1,024 tokens, que evita que gran parte de su caché siga creciendo, así que debe prever 20 GB o más. Un modelo 70B a 4 bits ocupa aproximadamente 43 GB (Llama 3.3 70B). Con 80 capas, su caché FP16 añade aproximadamente 2.7 GB con 8k y 5.4 GB con 16k, por lo que necesita una tarjeta de 48 GB con muy poco margen, o dos tarjetas más pequeñas. Este mismo cálculo sigue siendo válido mucho más allá de esas cifras, y el cálculo de VRAM para un modelo de 2.8 billones de parámetros como Kimi K3 muestra en qué momento elegir una tarjeta deja de ser siquiera la cuestión.

Los contextos largos son donde esto importa más. En modelos con atención completa, como Llama 3.1, la caché KV crece linealmente con la longitud del contexto y, con 128k tokens, puede superar a los propios pesos. Los modelos con atención de ventana deslizante o por bloques son distintos: la documentación de Transformers de Hugging Face menciona Mistral, Gemma 2 y Llama 4 como ejemplos en los que la caché de esas capas deja de crecer cuando alcanza el tamaño de la ventana o del bloque, por lo que el total crece más lentamente. Si piensa utilizar contextos largos, dimensione primero para la caché y compruebe qué opciones ofrece su motor para la cuantificación de la caché. En Ollama, OLLAMA_KV_CACHE_TYPE=q8_0 utiliza aproximadamente la mitad de memoria que f16, y la cuantificación de la caché sólo se aplica cuando Flash Attention está habilitado. Establezca también la longitud del contexto de forma explícita. Ollama elige el valor predeterminado según la VRAM: 4k por debajo de 24 GiB, 32k entre 24 y 48 GiB y 256k con 48 GiB o más. En una tarjeta de 48 GB que ejecute un modelo 70B, ese valor predeterminado solicita mucha más caché de la que puede contener la tarjeta.

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 NVIDIA-SMI no puede acceder al controlador; compruebe que el controlador esté instalado y que su módulo del kernel esté cargado. 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 que se cargue el módulo nuevo. Para máquinas de cómputo, la documentación de servidor de Ubuntu recomienda sudo ubuntu-drivers install --gpgpu, que selecciona la rama del controlador para servidores.

En los contenedores, el controlador por sí solo no basta. 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, confirme que la transferencia 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 Docker no encontró un controlador de dispositivo que coincidiera con la solicitud; compruebe que el toolkit esté instalado y vuelva a ejecutar la línea nvidia-ctk y el reinicio. 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 cobran por el tiempo de cómputo aprovisionado, no por tokens, y el proveedor establece las tarifas y los cargos por instancias detenidas. Una GPU activa de forma permanente que atiende unas pocas solicitudes al día pasa la mayor parte del tiempo facturado inactiva. El punto de equilibrio es la utilización: una GPU ocupada tiene un coste bajo por token, mientras que una GPU inactiva es puro desperdicio.

Hay tres patrones razonables. Mantenga las cargas estables de poco volumen en un VPS con 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, y la disciplina presupuestaria descrita en Control de costes de agentes 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, no el número 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 7 GB para un modelo 8B cuantizado a 4 bits con un contexto de 8k, y aproximadamente 8 GB con 16k, usando la caché FP16 predeterminada de Ollama. Los pesos ocupan aproximadamente 4.9 GB, la caché KV añade aproximadamente 1.07 GB con 8k o 2.15 GB con 16k, y el resto corresponde a aproximadamente 1 GB de sobrecarga. Una tarjeta de 8 GB lo admite con 8k, pero va justa con 16k, mientras que una tarjeta de 12 GB deja un margen cómodo para contextos más largos. Cambiar la caché a q8_0 reduce aproximadamente a la mitad la parte correspondiente a la caché. Si piensa ejecutar con un contexto de 128k, dimensione la caché por separado, porque puede crecer hasta superar el tamaño de los pesos.

¿Puedo ejecutar Ollama sin GPU?

Sí. Ollama cambia automáticamente a la CPU y sólo 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 al ritmo de lectura de un usuario. Los prompts largos son el verdadero problema en la CPU, porque leer 30,000 tokens de contexto está limitado por el cálculo y tarda mucho más que generar la respuesta.

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

La causa habitual es que el modelo no cabía completamente en la VRAM, por lo que 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 muestre 100% GPU. Si muestra una división, use una cuantización más pequeña o un modelo más pequeño. La otra causa común es una prueba breve en la que el tiempo de carga del modelo domina la medición.

¿Merece la pena una GPU VPS para un solo usuario?

Por lo general, no. La lectura silenciosa de adultos en inglés tiene un promedio de aproximadamente 4.0 a 4.3 palabras por segundo, y los tokens por segundo deben convertirse a palabras por segundo antes de comparar el rendimiento de una máquina con CPU con ese ritmo. 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 a la vez es el argumento más sólido, porque el batching permite que una GPU comparta las lecturas de los pesos entre las solicitudes.

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

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 siempre encendida sólo cuando la tarjeta se mantenga ocupada, porque la computación GPU aprovisionada se factura por tiempo y no por los tokens producidos. Un asistente con poco tráfico sale más barato en una CPU VPS o en una API alojada con pago por token que en una GPU inactiva.