Ollama o llama.cpp en un VPS sin GPU

Ollama frente a llama.cpp: ¿en qué capa quieres 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 backend de inferencia (comprobado el 2 de agosto de 2026). Por tanto, la pregunta real es qué capa quieres administrar en tu VPS, no cuál es más rápida.

Usa Ollama cuando quieras un servicio que obtenga modelos por nombre y siga funcionando sin intervención. Usa llama.cpp directamente cuando el servidor sea pequeño y necesites 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 de la que no dispones.

Qué es realmente cada proyecto

llama.cpp es una implementación en C y C++ de la inferencia de transformers basada en la biblioteca ggml. Lee archivos GGUF. GGUF (GGML universal file format) 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 independientes para tareas distintas. llama-server es un servidor HTTP, llama-cli es un prompt interactivo y llama-bench mide el rendimiento. Las versiones se identifican mediante el número de compilación, no mediante versiones semánticas. La etiqueta actual es b10224, publicada el 2 de agosto de 2026, y se publica una etiqueta nueva 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 guarda en /usr/share/ollama/.ollama/models en Linux. Esos archivos se almacenan en el disco raíz y ocupan varios gigabytes cada uno. Por eso, 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 otra ubicación antes de que la tercera descarga lo llene.

Ese empaquetado marca toda la diferencia. Ollama decide por usted la cuantización, la plantilla y la longitud de contexto, y le proporciona un único nombre que 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 mil 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 modelo, y la más pequeña ocupa 2.96 GiB frente a 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 permitirse no es automáticamente una fila que convenga usar, y lo que Q4, Q8 y fp16 cuestan realmente en calidad de respuesta indica si los gigabytes adicionales aportan algo perceptible.

Con llama.cpp se especifica 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 transfieren a una GPU (0 en un equipo sólo con CPU). No se infiere 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 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

Después, 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 el valor predeterminado según la VRAM disponible, y un equipo sin GPU entra 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 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. 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 afecte a las demás tareas que el daemon deba ejecutar. 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 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 del 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 petición debe volver a leer todo el archivo desde el disco antes de responder, por lo que recargar un archivo de 4.58 GiB convierte una respuesta de dos segundos en una de treinta segundos cuando el almacenamiento es lento. Un keep-alive prolongado corrige la latencia, pero consume la RAM de forma permanente. Ambos son costes reales. Elija el que le cause menos problemas. 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 calentar el modelo manualmente cada vez que se reinicia el servidor.

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, lo que evita sorpresas por recargas, pero tampoco permite recuperar la memoria sin detener el servicio. Si todavía 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á la aplicación

Este eje se ha reducido mucho. Ambos proyectos usan ahora el formato de chat de OpenAI, por lo que la mayoría de las bibliotecas cliente funcionan con cualquiera de ellos 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. 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 saber qué está haciendo cada ranura de solicitudes y /metrics en formato Prometheus. Si piensa monitorizar este servicio, esta diferencia probablemente sea la decisiva.

Ninguno de los dos servidores activa la autenticación por usted. De forma predeterminada, ambos se vinculan a loopback por un buen motivo. Acceda a ellos mediante un túnel SSH o desde detrás de un reverse proxy, y no exponga nunca 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 en tokens por segundo. En un plan con vCPU compartida, un modelo 8B en Q4_K_M suele quedar en los primeros valores 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 realmente puede controlar. A tres tokens por segundo, un modelo que genera 600 tokens mantiene el VPS ocupado durante tres minutos. Por eso, limitar la salida con num_predict es la forma más barata de evitar que una respuesta demasiado larga provoque un tiempo de espera agotado.

Uso 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. 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. Uso no 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 hace doce llamadas de cuatro segundos tarda un minuto antes de producir algo. Si el plan era usar un asistente de programación, dirigir un agente a un modelo que aloja usted mismo explica qué tareas resuelve realmente 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 respuesta es un VPS con una GPU conectada, donde -ngl empieza a ser relevante. Antes de elegir cualquiera de las dos opciones, obtenga una referencia 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 para VPS merece esa hora de trabajo.

Instalar llama.cpp con una compilación fijada

Ambos proyectos cambian cada semana, 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, use en su lugar el archivo tar 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 no tiene recursos suficientes.

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 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 lo que falla rápido 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, sino que funciona con extrema lentitud. De forma predeterminada, llama.cpp usa el mapeo de memoria para el archivo GGUF, por lo que incluso un archivo mayor que la RAM llega a iniciarse. El kernel carga y descarga los pesos desde el disco en cada token, y la generación tarda varios segundos por token, mientras el disco permanece al 100 por ciento de uso. Pase --no-mmap para forzar una asignación real y hacer que falle de inmediato en lugar de degradarse. Cuando interviene el kernel, dmesg muestra la causa:

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

El archivo del modelo no se carga en absoluto. Un GGUF creado para una familia de modelos más reciente que el motor produce un error con el nombre de la arquitectura que el motor no reconoce:

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

La solución es actualizar el motor, no cambiar de archivo. Este es el coste de fijar versiones y 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 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 de 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 por inactividad después de 5 minutos y el modelo vuelve a leerse 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 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 contenedor de llama.cpp?

Casi, pero el contenedor realiza tareas importantes. El README de Ollama incluye llama.cpp como su backend de inferencia (comprobado el 2 de agosto de 2026). Sobre esa base, Ollama añade un registro de modelos, la plantilla de solicitudes que convierte los mensajes de chat en una solicitud, 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. En realidad, la elección es la capa de gestió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 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 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 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, 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 un margen cómodo y 4 GiB no son suficientes. 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 este requisito también aumenta con OLLAMA_NUM_PARALLEL.