Ollama o llama.cpp para un VPS sin GPU

Ollama frente a llama.cpp: ¿qué capa quiere ejecutar?

Ollama y llama.cpp no son competidores en el sentido que implica la pregunta. llama.cpp es el motor de inferencia: carga un archivo de modelo y convierte un prompt en tokens. Ollama es un gestor de modelos, un daemon en segundo plano y una API HTTP que se ejecuta sobre ese motor. El README de Ollama todavía incluye llama.cpp como su backend de inferencia (comprobado el 2 de agosto de 2026). Por tanto, la pregunta real es qué capa quiere operar en su VPS, no cuál es más rápida.

Ejecute Ollama cuando quiera un servicio que descargue modelos por nombre y siga funcionando sin intervención. Ejecute llama.cpp directamente cuando el servidor sea pequeño y necesite elegir el archivo de modelo exacto, el tamaño exacto del contexto y el número exacto de hilos, porque en un VPS pequeño cada uno de esos ajustes consume memoria que no tiene.

Qué es realmente cada proyecto

llama.cpp es una implementación en C y C++ para ejecutar inferencias de transformers basada en la biblioteca ggml. Lee archivos GGUF. GGUF (GGML universal file format) es un contenedor de un solo archivo que contiene los pesos, el tokenizador y los metadatos que el motor necesita para ejecutar el modelo. El proyecto distribuye binarios separados para tareas diferentes. llama-server es un servidor HTTP, llama-cli es un prompt interactivo y llama-bench mide el rendimiento. Las versiones publicadas se identifican por el número de compilación, no por una versión semántica. La etiqueta actual es b10224, publicada el 2 de agosto de 2026, y se publica una nueva etiqueta la mayoría de los días laborables.

Ollama es un programa escrito en Go. Un daemon en segundo plano, iniciado con ollama serve, carga modelos y responde a solicitudes HTTP, mientras un cliente de línea de comandos se comunica con ese daemon. Detrás de ambos hay un registro en ollama.com que contiene modelos preempaquetados. Ollama usa versiones semánticas, y v0.32.5 se publicó el 27 de julio de 2026. ollama pull descarga un GGUF junto con una plantilla de prompt y un conjunto de parámetros predeterminados, y después lo almacena en /usr/share/ollama/.ollama/models en Linux.

Ese empaquetado marca toda la diferencia. Ollama decide por usted la cuantización, la plantilla y la longitud del contexto, y le proporciona un único nombre que debe recordar. llama.cpp no decide nada y le proporciona flags.

Eje 1: control del modelo y la cuantización

La cuantización reduce cada peso de 16 o 32 bits a 4, 5 u 8 bits. Esto permite que un modelo de 8.000 millones de parámetros quepa en la RAM de un VPS normal. Los nombres de GGUF son fáciles de interpretar cuando se conoce el patrón: Q4_K_M significa cuantización K de 4 bits y tamaño medio. Un número mayor conserva más precisión y requiere más memoria.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Esos son los tamaños publicados de los archivos del repositorio bartowski/Meta-Llama-3.1-8B-Instruct-GGUF en Hugging Face, consultados el 2 de agosto de 2026 y convertidos de bytes a GiB. Hay 6 compilaciones de un mismo modelo. La más pequeña ocupa 2.96 GiB, frente a los 7.95 GiB de la más grande. La opción predeterminada habitual, Q4_K_M, ocupa 4.58 GiB. En un VPS de 4 GiB, esa elección determina si el modelo llega a cargarse.

Con llama.cpp se indica el nombre del archivo, por lo que debe elegir esa fila manualmente.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c es el tamaño del contexto en tokens, -t es el número de hilos y -ngl establece cuántas capas se trasladan a una GPU (0 en un servidor sólo con CPU). No se presupone ningún valor.

Con Ollama, la cuantización se incluye en la etiqueta que se descarga, y ollama ls muestra lo que realmente tiene en el disco. Si el registro no contiene la compilación que necesita, importe un archivo GGUF manualmente. Escriba un Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Después, créelo y compruebe el resultado:

ollama create llama31-q4 -f ./Modelfile
ollama ls

La longitud del contexto es el ajuste que suele causar problemas. Ollama elige su valor predeterminado a partir de la VRAM disponible, y un servidor sin GPU entra en el grupo más pequeño: 4096 tokens. Si le envía un documento de 20.000 tokens, los tokens adicionales se descartan antes de que el modelo los procese. Por eso, la respuesta puede ser incorrecta con seguridad sobre un archivo que sólo ha leído parcialmente. Auméntela con OLLAMA_CONTEXT_LENGTH en el daemon o con PARAMETER num_ctx en un Modelfile. llama.cpp tampoco tiene un valor predeterminado fiable. Establezca -c explícitamente y compruebe qué valor ha configurado.

El cálculo de memoria que normalmente no se muestra

El archivo del modelo no representa todo el coste. La caché KV (caché de claves y valores) almacena una entrada por capa y por token de contexto, y crece a medida que crece la conversación.

Hágalo para Llama 3.1 8B. El modelo tiene 32 capas, 8 cabezales de claves/valores y una dimensión de cabezal de 128. Cada token almacena una clave y un valor de 2 bytes cada uno en f16, por lo que 2 x 8 x 128 x 2 = 4096 bytes por capa. En las 32 capas, son 128 KiB por token. Un contexto de 4096 tokens requiere 512 MiB, y un contexto de 32,768 tokens requiere 4 GiB.

Por tanto, un modelo Q4_K_M 8B con un contexto de 4k necesita aproximadamente 4.58 GiB para los pesos, más unos 0.5 GiB para la caché y la memoria del propio runtime. No cabe en 4 GiB de RAM. Cabe en 8 GiB con margen suficiente para trabajar. Si aumenta el contexto a 32k en ese mismo equipo con 8 GiB, la caché consume por sí sola todo el margen disponible. Supervise el consumo en tiempo real con free -h mientras el modelo esté cargado y no confíe en una estimación que no haya medido. Si está dimensionando un modelo bastante mayor que 8B, el mismo cálculo aplicado a un modelo de 27B en un VPS que sólo usa CPU muestra qué puede alojar realmente cada nivel entre 8 y 64 GB.

Ollama multiplica este efecto. OLLAMA_NUM_PARALLEL tiene el valor predeterminado 1, y la memoria que necesita un modelo aumenta en proporción a ese número multiplicado por la longitud del contexto. Si aumenta ambos valores a la vez, el daemon solicita silenciosamente varias veces la RAM que esperaba. Ese mismo cálculo también determina el límite de usuarios simultáneos, porque cada petición concurrente necesita su propia parte de la caché KV. Esto explica por qué un servidor que funciona bien para una persona se bloquea con cinco.

Eje 2: el daemon que debe administrar

El script de instalación de Ollama escribe una unidad de systemd, crea un usuario del sistema ollama y habilita el servicio. Obtiene la administración del ciclo de vida sin tener que escribir nada de eso. La configuración se realiza mediante systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE es más importante en una VPS con CPU que en cualquier otro entorno. De forma predeterminada, los modelos se mantienen en memoria durante 5 minutos y después se descargan. La siguiente solicitud debe volver a leer todo el archivo desde el disco antes de responder, por lo que una recarga de 4.58 GiB convierte una respuesta de dos segundos en una de treinta segundos en un almacenamiento lento. Un keep-alive prolongado elimina la latencia y consume la RAM de forma permanente. Ambos son costes reales. Elija el que cause menos problemas.

llama.cpp no proporciona ningún daemon, así que debe escribir la unidad usted mismo como /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Habilítelo con sudo systemctl enable --now llama-server. El proceso mantiene el modelo durante toda su vida útil. No se descarga cuando queda inactivo, por lo que no hay sorpresas por recargas, pero tampoco puede recuperar la memoria sin detener el servicio. Si no está familiarizado con la escritura de unidades, es el mismo patrón que ejecutar sus propios servicios con systemd en una VPS.

Eje 3: la API con la que se comunicará tu aplicación

Este eje se ha reducido mucho. Ahora ambos proyectos usan el formato de chat de OpenAI, por lo que la mayoría de las bibliotecas cliente funcionan con cualquiera de los dos después de cambiar sólo la URL base.

Ollama escucha en 127.0.0.1:11434. Su ruta compatible con OpenAI es http://localhost:11434/v1/chat/completions y, además, mantiene una API nativa en /api/chat. También está documentada una ruta compatible con Anthropic.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server escucha en 127.0.0.1:8080 y ofrece /v1/chat/completions, /v1/completions y /v1/embeddings, además de su propio endpoint /completion y una interfaz web integrada. También expone rutas operativas que Ollama no ofrece: /health para una comprobación de disponibilidad, /props para la configuración del modelo cargado, /slots para ver qué está haciendo cada ranura de solicitudes y /metrics en formato Prometheus. Si planeas monitorizar este servicio, probablemente esta diferencia sea la que determine tu elección.

Ninguno de los dos servidores activa la autenticación por ti. Ambos usan loopback de forma predeterminada por un buen motivo. Accede a ellos mediante un túnel SSH o detrás de un reverse proxy, y nunca expongas 11434 ni 8080 a Internet.

Qué puede hacer realmente un VPS sin GPU

Un VPS que sólo tiene CPU ejecuta modelos pequeños con lentitud. Ese es el resumen honesto, y lo útil es saber dónde está el límite. Mida antes de diseñar algo en torno a él:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

La columna pp indica la velocidad de procesamiento del prompt y la columna tg indica la velocidad de generación de tokens, ambas en tokens por segundo. En un plan con vCPU compartida, un modelo 8B en Q4_K_M normalmente alcanza pocos tokens por segundo en tg. El procesamiento del prompt es la parte más problemática: se procesa el prompt completo antes de que aparezca el primer token de salida, por lo que un prompt de sistema largo añade una espera a cada solicitud.

Es viable en CPU: un modelo de 1B a 4B para clasificación, extracción, resúmenes breves o enrutamiento. Las respuestas llegan en segundos y la memoria cabe en un plan normal. No es viable en CPU: chat interactivo a velocidad de lectura, asistentes de programación, trabajo con documentos largos o cualquier tarea con un bucle de agente que realice muchas llamadas consecutivas. Un bucle que realiza doce llamadas de cuatro segundos cada una tarda un minuto antes de producir algo. Si de todos modos el plan era usar un asistente de programación, dirigir un agente a un modelo que aloja usted mismo explica qué tareas resuelve realmente bien un modelo local pequeño y cuáles deben seguir usando una API alojada.

Hay dos alternativas cuando las cifras no son suficientes. Si el problema es la concurrencia, es decir, muchos usuarios accediendo al mismo modelo al mismo tiempo, cambia la elección del motor, y la comparación entre Ollama y vLLM para servir solicitudes simultáneas trata ese caso. Si el problema es la velocidad bruta, la respuesta es un VPS con una GPU conectada, donde -ngl empieza a ser relevante. Antes de cualquiera de las dos opciones, obtenga una línea base del hardware, porque el ancho de banda del disco y de la memoria influye en el tiempo de carga tanto como la CPU. Un benchmark reproducible de VPS merece esa hora.

Instalar llama.cpp y fijar una compilación

Ambos proyectos cambian semanalmente, así que registre la versión que desplegó. El comando de una línea del proyecto instala la compilación actual:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Para fijar una compilación específica, descargue en su lugar el archivo tar precompilado de la página de versiones. La compilación b10224 es la etiqueta actual al 2 de agosto de 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

También puede compilar esa misma etiqueta desde el código fuente:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev es la dependencia documentada para las funciones HTTPS. La compilación tarda varios minutos y requiere más RAM que los planes más pequeños, así que compile en un equipo más grande y copie los binarios si el equipo pequeño se queda sin recursos.

Instalar Ollama con una versión fijada

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

El script lee OLLAMA_VERSION, por lo que puede fijar una versión conocida en lugar de instalar la que se haya publicado esta mañana. v0.32.5 se publicó el 27 de julio de 2026. También existe un procedimiento manual si prefiere no canalizar un script a un shell:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

El procedimiento manual no crea la unidad de systemd ni el usuario del servicio, por lo que debe crearlos usted mismo. La guía completa para ejecutar Ollama en un VPS explica paso a paso cómo configurar el servicio.

Modos de fallo y mensajes que verá

Ollama no puede cargar el modelo. ollama run devuelve una línea con este formato:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama comprueba el tamaño antes de cargar el modelo. Por eso falla de inmediato e indica la causa. Baje una fila de cuantización, reduzca la longitud del contexto o elija un modelo más pequeño.

llama.cpp no falla, funciona con extrema lentitud. De forma predeterminada, llama.cpp asigna el GGUF a la memoria mediante mmap, por lo que incluso puede iniciar con un archivo más grande que la RAM. Después, el kernel intercambia los pesos entre el disco y la memoria en cada token. La generación puede tardar varios segundos por token y el disco puede permanecer al 100 %. Pase --no-mmap para forzar una asignación real. Así fallará de inmediato en lugar de degradar el rendimiento. Cuando interviene el kernel, dmesg muestra la causa:

Out of memory: Killed process 1234 (llama-server)

El archivo del modelo no carga en absoluto. Un GGUF creado para una familia de modelos más nueva que la compatible con su motor produce un error que indica la arquitectura desconocida:

error loading model architecture: unknown model architecture: 'qwen3next'

La solución es actualizar el motor, no usar otro archivo. Este es el coste de fijar versiones. Por eso debe anotar el número de compilación. Necesita saber desde qué versión está actualizando.

La API responde localmente, pero no desde su aplicación. Ollama escucha en 127.0.0.1:11434, por lo que otro host recibe un rechazo de conexión. Configure OLLAMA_HOST=0.0.0.0:11434 mediante systemctl edit ollama sólo cuando el puerto esté detrás de un firewall o en una red privada, porque la API no tiene autenticación incorporada.

La primera respuesta después de una pausa es muy lenta. Se produjo la descarga por inactividad tras 5 minutos y el modelo se está leyendo de nuevo desde el disco. ollama ps, ejecutado justo antes de la petición, no muestra ningún modelo cargado. Esto lo confirma. Aumente OLLAMA_KEEP_ALIVE.

Entonces, ¿cuál debería ejecutar?

Ejecute Ollama cuando quiera que los modelos se gestionen automáticamente y necesite un endpoint compatible con OpenAI sin configuración adicional. Es la opción predeterminada adecuada para un primer despliegue y para cualquier entorno en el que la selección del modelo vaya a cambiar con frecuencia.

Ejecute llama.cpp directamente cuando la memoria sea tan limitada que necesite elegir personalmente la fila de cuantización, cuando quiera /health, /slots y /metrics para la monitorización o cuando necesite una opción que Ollama no exponga. Es la opción adecuada en un VPS donde el modelo apenas cabe, porque los ajustes que permiten que quepa son precisamente los que Ollama selecciona automáticamente.

Es normal ejecutar ambos. Ollama para los experimentos y llama.cpp para el único modelo que ponga en producción y que no quiera cambiar.

FAQ

¿Ollama es sólo un envoltorio para llama.cpp?

Casi, pero el envoltorio realiza trabajo real. El README de Ollama indica que llama.cpp es su backend de inferencia (comprobado el 2 de agosto de 2026). Sobre esa base, Ollama añade un registro de modelos, la plantilla de prompts que convierte los mensajes de chat en un prompt, un conjunto de parámetros de muestreo predeterminados, un daemon que descarga los modelos inactivos y una API HTTP. Si compara los tokens por segundo con parámetros idénticos, está comparando el mismo motor consigo mismo. En realidad, lo que elige es la capa de gestión.

¿Cuál es más rápido en un VPS que sólo usa CPU?

Comparten el motor, por lo que, con el mismo archivo de modelo, cuantización, tamaño de contexto y número de hilos, los resultados son similares. Las diferencias que suelen observarse se deben normalmente a valores predeterminados distintos, sobre todo la longitud de contexto y el número de hilos, no al motor. Mídalo con llama-bench -m <file> -p 512 -n 128 y compare la columna tg en su propio servidor antes de dar por válida cualquier cifra publicada.

¿Puedo usar mi propio archivo GGUF con Ollama?

Sí. Coloque el archivo en el servidor, escriba un Modelfile cuya primera línea sea FROM ./your-model.gguf, añada las líneas PARAMETER que necesite, como num_ctx, y ejecute ollama create your-name -f ./Modelfile. ollama ls lo mostrará junto a los modelos que haya descargado del registro. Así puede usar una cuantización que el registro no ofrece.

¿Cuánta RAM necesito para un modelo 8B?

Calcule el tamaño del archivo, más la caché KV, más el runtime. Una compilación Q4_K_M de Llama 3.1 8B ocupa aproximadamente 4.58 GiB en disco, y un contexto de 4096 tokens añade aproximadamente 512 MiB de caché. Por tanto, 8 GiB de RAM ofrecen margen suficiente y 4 GiB no bastan. La caché aumenta con el contexto: el mismo modelo con un contexto de 32,768 tokens necesita por sí solo unos 4 GiB de caché. Con Ollama, recuerde que el requisito también aumenta con OLLAMA_NUM_PARALLEL.