Ollama o llama.cpp en un VPS: ¿cuál elegir?

Ollama frente a llama.cpp: ¿qué capa quieres 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 ejecutan sobre ese motor. El README de Ollama todavía incluye llama.cpp como su backend de inferencia (comprobado el 27 de octubre de 2026). Por tanto, la pregunta real es qué capa quieres operar en tu VPS, no cuál es más rápida.

Ejecuta Ollama cuando quieras un servicio que descargue modelos por nombre y siga funcionando sin intervención. Ejecuta llama.cpp directamente cuando el servidor sea pequeño y necesites 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 una de esas opciones consume memoria que no tienes.

Qué es realmente cada proyecto

llama.cpp es una implementación en C y C++ de inferencia de transformadores 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 distintas. llama-server es un servidor HTTP, llama-cli es un prompt interactivo y llama-bench mide el rendimiento. El proyecto ahora publica versiones con versionado semántico (MAJOR.MINOR.PATCH), y v0.7.0, publicada el 15 October 2026, era la última el 27 October 2026. Las etiquetas nightly numeradas por compilación siguen publicándose junto a ellas, varias al día, y la más reciente el 27 October 2026 era b11913.

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. v0.32.5 se publicó el 27 July 2026, y v0.40.12 se publicó el 27 October 2026 a las 00:07 UTC. ollama pull descarga un GGUF junto con una plantilla de prompts y un conjunto de parámetros predeterminados, y después lo almacena en /usr/share/ollama/.ollama/models en Linux. Esos archivos se almacenan en el disco raíz y ocupan varios gigabytes cada uno, por lo que en un VPS con un volumen raíz de 25 GB conviene saber qué deja pull y cómo mover el directorio de modelos a otro lugar antes de que la tercera descarga lo llene.

Ese empaquetado marca toda la diferencia. Ollama decide por ti la cuantización, la plantilla y la longitud de contexto, y te proporciona un único nombre que recordar. llama.cpp expone esas opciones como flags, con valores predeterminados automáticos para los ajustes que dejas sin definir.

Eje 1: control del modelo y la cuantización

La cuantización almacena los pesos con menos bits que los 16 o 32 bits del modelo original, y las compilaciones GGUF habituales promedian aproximadamente 4, 5 u 8 bits por peso. La precisión no es uniforme en todo el archivo. En el código fuente del cuantizador de llama.cpp (consultado el 27 de octubre de 2026), una compilación Q4_K_M mantiene la mayoría de los tensores a 4 bits, pero asigna 6 bits Q6_K a la capa de salida y a los tensores de valores de atención y de reducción feed-forward de aproximadamente la mitad de las capas; los tensores pequeños, como las normas, no se cuantizan. Esto permite que un modelo de 8 billion parameters quepa en la RAM de un VPS común. Los nombres de GGUF se entienden 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 consume 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, esta elección determina si el modelo puede cargarse. El tamaño sólo representa la mitad de la decisión, porque una fila que puede pagar no es automáticamente una fila que convenga usar, y el coste real de Q4, Q8 y fp16 en la calidad de las respuestas indica si los gigabytes adicionales aportan algo perceptible.

Con llama.cpp se indica el nombre del archivo, así que esa fila se elige 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 transfieren a una GPU (0 en un equipo sólo con CPU). Las opciones no definidas tienen valores predeterminados, y --fit está activada de forma predeterminada para ajustar los argumentos no definidos a la memoria disponible del dispositivo.

Con Ollama, la cuantización viene determinada por la etiqueta que se descarga, y ollama ls muestra lo que realmente está almacenado en disco. Si el registro no incluye 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

A continuación, compílelo 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 según la VRAM disponible, y un equipo sin GPU queda en el grupo más pequeño: 4096 tokens. Si se le envía un documento de 20,000 tokens, los tokens adicionales se descartan antes de que el modelo los procese, por lo que la respuesta puede ser errónea 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. Si sólo un trabajo necesita una ventana mayor, num_ctx se puede establecer por solicitud en lugar de hacerlo para todo el servidor, lo que evita que la caché adicional se reserve para el resto de las tareas que recibe el daemon. llama.cpp tampoco tiene un valor predeterminado fiable. Establezca -c explícitamente y compruebe qué valor ha configurado.

La aritmética de memoria que nadie muestra

El archivo del modelo no representa todo el consumo. 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.

Calculemos el caso de Llama 3.1 8B. El modelo tiene 32 capas, 8 cabezas de claves/valores y una dimensión de cabeza de 128. Cada token almacena una clave y un valor de 2 bytes cada uno en f16, de modo 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 consume, por tanto, 512 MiB, y un contexto de 32,768 tokens consume 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 de caché y el 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é por sí sola 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. Si está dimensionando un modelo muy superior a 8B, el mismo cálculo aplicado en un modelo de 27B en un VPS que usa sólo CPU muestra qué puede alojar realmente cada nivel entre 8 y 64 GB.

Ollama multiplica este consumo. OLLAMA_NUM_PARALLEL tiene el valor predeterminado 1, y la memoria que necesita un modelo escala según el producto de ese número por la longitud del contexto. Si aumenta ambos a la vez, el daemon solicita silenciosamente varias veces la RAM que esperaba. La misma aritmética establece el límite de usuarios simultáneos, porque cada solicitud 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 de 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 un VPS con CPU que en cualquier otro entorno. Los modelos se mantienen en memoria durante 5 minutos de forma predeterminada y después se descargan. La siguiente petición debe cargar de nuevo todo el archivo antes de poder responder. Si el kernel todavía conserva el archivo en su caché de páginas, la carga es rápida, pero sólo la RAM disponible permite mantenerlo allí. Cuando otro trabajo lo expulsa de la caché, el archivo vuelve a cargarse desde el disco, por lo que volver a cargar 4.58 GiB puede convertir una respuesta de dos segundos en una de treinta segundos en un almacenamiento lento. Un keep-alive prolongado resuelve la latencia, pero consume la RAM de forma permanente. Ambos son costes reales. Elija el que tenga menor impacto. Si decide que el modelo debe permanecer siempre residente, configurar keep_alive para que sobreviva a los periodos de inactividad y a los reinicios requiere un par de líneas y evita tener que precargar el modelo manualmente cada vez que se reinicia el servidor.

llama.cpp no proporciona un daemon ni un usuario de servicio, así que debe configurar ambos por su cuenta. Desde el directorio llama.cpp en el que compiló, instale el binario y sus bibliotecas en /usr/local, cree un usuario llama y dé a ese usuario una copia del modelo:

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

Si utilizó el archivo de la versión en lugar de compilar, apunte ExecStart al llama-server que contiene, porque el archivo conserva sus bibliotecas junto al binario. Después, escriba la unidad 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ítela con sudo systemctl enable --now llama-server. El proceso mantiene el modelo durante toda su vida útil. De forma predeterminada, nada se descarga cuando queda inactivo, pero añadir --sleep-idle-seconds habilita la descarga y la recarga automáticas sin detener el servicio. Si no está familiarizado con la escritura de unidades, se trata del 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 reducido mucho. Ambos proyectos ahora 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 también mantiene una API nativa en /api/chat. Además, hay una ruta compatible con Anthropic documentada. Ninguna de estas rutas permite que el modelo busque información por sí mismo. Si la aplicación necesita respuestas más recientes que los datos de entrenamiento del modelo, planifique integrar búsquedas web mediante la API de Ollama, Open WebUI o un bucle breve de herramientas.

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"}]}'

Iniciado con los flags anteriores, llama-server escucha en 127.0.0.1:8080. Si no se especifica nada, ahora usa el puerto 9931 de forma predeterminada (comprobado el 27 de octubre de 2026), así que mantenga --port en la línea de comandos si su aplicación espera el puerto 8080. Sirve /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 mostrar qué hace cada slot de solicitudes y /metrics en formato Prometheus una vez que añade --metrics, porque ese endpoint está desactivado de forma predeterminada. Si piensa monitorizar este servicio, probablemente esa diferencia sea la que determine su elección.

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

Qué puede hacer realmente un VPS sin GPU

Un VPS sin GPU ejecuta modelos pequeños con lentitud. Ese es el resumen honesto. 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 se expresan en tokens por segundo. En un plan con vCPU compartida, un modelo 8B en Q4_K_M suele quedarse en cifras bajas de un solo dígito para tg. El procesamiento del prompt es la parte más problemática: el prompt completo se procesa antes de que aparezca el primer token de salida, por lo que un prompt de sistema largo añade una espera a cada petición. La longitud de la respuesta es la parte del coste que puede controlar directamente. A tres tokens por segundo, un modelo que genera 600 tokens mantiene ocupado el VPS durante 200 segundos, más de tres minutos sólo para generar la respuesta. Por eso, limitar la salida con num_predict es la forma más barata de evitar que una respuesta demasiado larga provoque un timeout.

Se puede usar 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. Para ver un ejemplo concreto de ese tamaño, en lugar de un intervalo, Nemotron 3.5 Lightning descargado y medido en un VPS muestra la etiqueta exacta, la RAM que realmente necesita y la velocidad que mantiene sin GPU. No se puede usar de forma práctica en CPU para chat interactivo a velocidad de lectura, asistentes de programación, trabajo con documentos largos ni tareas con un bucle de agente que haga muchas llamadas consecutivas. Un bucle con doce llamadas de cuatro segundos tarda un minuto antes de producir cualquier resultado. Si el plan era usar un asistente de programación, dirigir un agente a un modelo alojado por usted 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. La comparación entre Ollama y vLLM para servir solicitudes concurrentes cubre ese caso. Si el problema es la velocidad bruta, la solución 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 un VPS merece esa hora.

Instalar llama.cpp con una compilación fijada

Ambos proyectos cambian semanalmente, así que registre la versión que implementó. El instalador 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 en su lugar el tarball precompilado de la página de releases. El proyecto también publica ahora releases con versionado semántico: v0.7.0 era la versión más reciente el 27 de octubre de 2026, y su página de release apunta a nightly b11669 para los binarios. v0.8.0 le siguió el 28 de octubre de 2026, y su página de release apunta a nightly b11960 para los binarios. Los comandos siguientes usan b10224, el tag actual del 2 de agosto de 2026; sustituya este tag por el que haya probado:

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 ese mismo tag 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 de la disponible en 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 memoria.

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 conocida y estable 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 enviar 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 para ejecutar Ollama en un VPS explica paso a paso cómo configurar ese servicio.

Modos de fallo y mensajes que verá

Ollama se niega a cargar el modelo. Las versiones antiguas de Ollama comprobaban el tamaño antes de cargarlo, y ollama run devolvía una línea de este tipo:

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

El código fuente actual de Ollama ya no contiene ese mensaje (comprobado el 27 de octubre de 2026). Ahora Ollama delega la carga en llama-server, por lo que un modelo que no cabe aparece como un fallo del runner, con errores que empiezan así:

llama-server reported out-of-memory during startup
llama-server process has terminated

En ambos casos, la solución es la misma. 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 memory mapping, por lo que un archivo mayor que la RAM puede iniciarse igualmente. El kernel carga y expulsa los pesos del disco en cada token, y la generación baja a varios segundos por token mientras el disco permanece al 100 %. Pase --load-mode none para desactivar el memory mapping. Esa opción sustituyó a --no-mmap, que aparece documentada como obsoleta en la compilación fijada b10224 y ya no aparece en las compilaciones actuales (comprobado el 29 de octubre de 2026). Cuando interviene el kernel, dmesg muestra el motivo:

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 reciente que su motor produce un error con el nombre de la arquitectura que no reconoce; <arch> es el nombre almacenado en los metadatos del archivo:

llama_model_load: error loading model: unknown model architecture: '<arch>'

La solución es actualizar el motor, no cambiar de archivo. Este es el coste de fijar una versión, y por eso debe anotar el número de compilación. Necesita saber desde qué compilación está actualizando.

La API responde localmente, pero no desde su aplicación. Ollama se enlaza a 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 una red privada, porque la API no tiene autenticación delante.

La primera respuesta después de una pausa es muy lenta. Se produjo la descarga tras 5 minutos de inactividad y el modelo se está cargando de nuevo, desde el disco si la caché de páginas no lo ha conservado. Ejecutar ollama ps justo antes de la petición no muestra nada cargado, lo que lo confirma. Aumente OLLAMA_KEEP_ALIVE.

Entonces, ¿cuál deberías usar?

Usa Ollama cuando quieras que la gestión de los modelos sea automática y necesites un endpoint compatible con OpenAI sin configuración adicional. Es la opción predeterminada adecuada para una primera implementación y para cualquier entorno en el que vayas a cambiar de modelo con frecuencia.

Usa llama.cpp directamente cuando tengas la memoria tan limitada que necesites seleccionar manualmente la fila de cuantización, cuando quieras /health, /slots y /metrics para la monitorización, o cuando necesites 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 por ti.

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

FAQ

¿Ollama es sólo un wrapper de llama.cpp?

Casi, pero el wrapper realiza trabajo adicional. El README de Ollama indica llama.cpp como su backend de inferencia (comprobado el 27 de octubre de 2026). Ollama añade un registro de modelos, la plantilla de prompt que convierte los mensajes de chat en un prompt, un conjunto de parámetros de muestreo predeterminados, un daemon que descarga los modelos cuando están inactivos y una API HTTP. Cuando compara tokens por segundo con la misma configuración, está comparando el mismo motor consigo mismo. La elección real 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 se suelen observar proceden normalmente 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 cualquier otro modelo 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 unos 512 MiB de caché. Por tanto, 8 GiB de RAM son suficientes, pero 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.