Ollama frente a llama.cpp en un VPS: cuál elegir

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

Ollama y llama.cpp no son competidores en el sentido que presupone 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 ejecutan 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 administrar en su VPS, no cuál es más rápida.

Use Ollama si quiere un servicio que descargue modelos por nombre y siga funcionando sin intervención. Ejecute llama.cpp directamente si el servidor tiene pocos recursos y necesita elegir el archivo de modelo exacto, el tamaño de contexto exacto y el número exacto de hilos, porque en un VPS pequeño cada uno de esos ajustes consume memoria de la que no dispone.

Qué es realmente cada proyecto

llama.cpp es una implementación en C y C++ para ejecutar inferencias de modelos transformer, basada en la biblioteca ggml. Lee archivos GGUF. GGUF (formato de archivo universal de GGML) es un contenedor de un solo archivo que incluye los pesos, el tokenizador y los metadatos que el motor necesita para ejecutar el modelo. El proyecto distribuye binarios separados para tareas distintas. llama-server es un servidor HTTP, llama-cli es un indicador interactivo y llama-bench mide el rendimiento. Las versiones publicadas se identifican por número de compilación, no por versiones semánticas. 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 utiliza versiones semánticas, y v0.32.5 se publicó el 27 de julio de 2026. ollama pull descarga un archivo 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. Eso permite que un modelo de 8 billion parameters quepa en la RAM de un VPS normal. Los nombres de GGUF se entienden cuando se conoce el patrón: Q4_K_M significa cuantización K de 4 bits, de tamaño medio. Un número más alto 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 de archivo publicados en el repositorio bartowski/Meta-Llama-3.1-8B-Instruct-GGUF de Hugging Face, consultados el 2 de agosto de 2026 y convertidos de bytes a GiB. Hay 6 compilaciones de un modelo, y 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 única elección determina si el modelo llega a cargarse.

Con llama.cpp se indica el archivo, por lo que debe elegir usted mismo esa fila.

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 equipo que sólo usa CPU). No se calcula ningún valor automáticamente.

Con Ollama, la cuantización viene incluida en la etiqueta que descarga, y ollama ls muestra lo que realmente tiene en el disco. Si el registro no contiene la compilación que necesita, importe usted mismo un archivo GGUF. 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 el valor predeterminado a partir de la VRAM disponible, y un equipo sin GPU queda en el intervalo 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 llegue a verlos. Por eso, la respuesta puede ser incorrecta con seguridad sobre un archivo que sólo ha leído a medias. 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 confirme qué valor ha configurado.

La aritmética de memoria que nadie le muestra

El archivo del modelo no representa todo el consumo. La caché KV (caché de claves y valores) mantiene una entrada por capa y por token de contexto. Su tamaño aumenta a medida que crece la conversación.

Calculemos el caso de 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, con 2 bytes para cada uno en f16. Por tanto, 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 uno 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, además de unos 0.5 GiB para la caché y la memoria del propio entorno de ejecución. No cabe en 4 GiB de RAM. Cabe en 8 GiB con margen para trabajar. Si aumenta el contexto a 32k en ese mismo equipo con 8 GiB, la caché consume todo el margen. 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.

Ollama multiplica este consumo. OLLAMA_NUM_PARALLEL tiene el valor predeterminado 1, y la memoria que necesita un modelo escala según 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.

Eje 2: el daemon que debe administrar

El script de instalación de Ollama escribe una unidad de systemd, crea un usuario de sistema ollama y habilita el servicio. Obtiene la gestió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 un 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 puede convertir una respuesta de dos segundos en una de treinta segundos si el almacenamiento es lento. Un keep-alive prolongado corrige la latencia y consume la RAM de forma permanente. Ambos son costes reales. Elija la opción que cause menos problemas.

llama.cpp no proporciona ningún daemon, por lo 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 recargas inesperadas, 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 un VPS.

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

Este eje se ha acotado mucho. Ahora ambos proyectos admiten 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 indicar qué hace cada ranura de solicitudes y /metrics en formato Prometheus. Si planea monitorizar este servicio, esta diferencia probablemente será decisiva.

Ninguno de los dos servidores activa la autenticación automáticamente. Ambos usan loopback de forma predeterminada por un motivo válido. Acceda a ellos mediante un túnel SSH o detrás de un reverse proxy, y nunca exponga 11434 ni 8080 a Internet.

Lo que puede hacer realmente un VPS sin GPU

Un VPS sin GPU ejecuta modelos pequeños lentamente. Ese es el resumen honesto. Lo útil es saber dónde está el límite. Mida antes de diseñar cualquier cosa alrededor de é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 de 8B con Q4_K_M suele quedar en pocos tokens por segundo para tg. El procesamiento del prompt es la parte más lenta: 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: el chat interactivo a velocidad de lectura, los asistentes de programación, el trabajo con documentos largos ni cualquier proceso con un bucle de agente que haga muchas llamadas seguidas. Un bucle que hace doce llamadas de cuatro segundos cada una tarda un minuto antes de producir resultados.

Hay dos opciones cuando las cifras no son suficientes. Si el problema es la concurrencia, es decir, muchos usuarios acceden al mismo modelo al mismo tiempo, cambia la elección del motor. La comparación entre Ollama y vLLM para servir solicitudes concurrentes cubre 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 avanzan cada semana, así que registre la versión que desplegó. El comando de una línea del proyecto upstream 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, use el archivo tarball precompilado de la página de versiones. La compilación b10224 es la etiqueta actual a fecha de 2 August 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 necesita más RAM que los planes más pequeños, así que compile en un servidor más grande y copie los binarios si el servidor 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 mantener una versión estable conocida en lugar de instalar la que se haya publicado esta mañana. v0.32.5 se publicó el 27 July 2026. También existe un procedimiento manual si prefiere no pasar un script a un shell mediante una tubería:

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 añadirlos usted mismo. La guía completa de 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 rápidamente 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, pero funciona muy lentamente. llama.cpp asigna el archivo GGUF en memoria mediante mmap de forma predeterminada, por lo que un archivo mayor que la RAM puede iniciarse igualmente. El kernel pagina los pesos desde el disco y hacia él en cada token. La generación puede tardar varios segundos por token y el disco puede quedar al 100 por ciento de uso. 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 se puede cargar. Un GGUF creado para una familia de modelos más reciente que la compatible con su motor devuelve un error con el nombre de la arquitectura que no reconoce:

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 va a actualizar.

La API responde localmente, pero no desde la 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 integrada.

La primera respuesta después de una pausa es muy lenta. Se ha producido 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, lo que lo confirma. Aumente OLLAMA_KEEP_ALIVE.

Entonces, ¿cuál debe ejecutar?

Ejecute Ollama cuando quiera que los modelos se gestionen automáticamente y necesite un endpoint compatible con OpenAI sin trabajo 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 seleccionar la fila de cuantización manualmente, cuando quiera /health, /slots y /metrics para la monitorización, o cuando necesite un indicador 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 exactamente los que Ollama selecciona por usted.

Es normal ejecutar ambos. Ollama para experimentar y llama.cpp para el único modelo que pone en producción y que no quiere que cambie.

FAQ

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

Se acerca, pero el contenedor realiza trabajo real. El README de Ollama enumera llama.cpp como su backend de inferencia (comprobado el 2 de agosto de 2026). Ollama añade encima un registro de modelos, la plantilla de indicaciones que convierte los mensajes de chat en una indicación, un conjunto de parámetros de muestreo predeterminados, un daemon que descarga los modelos cuando están inactivos y una API HTTP. Al comparar tokens por segundo con la misma configuración, se compara el mismo motor consigo mismo. La elección real es la capa de administración.

¿Cuál es más rápido en una 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 se suelen observar proceden de valores predeterminados distintos, sobre todo de la longitud del contexto y del número de hilos, no del motor. Mídalo con llama-bench -m <file> -p 512 -n 128 y compare la columna tg en su propio servidor antes de confiar en 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 descargados 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 y 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.