llama.cpp vs Ollama en 2026: ¿Qué runtime debe ejecutar?

Ollama y llama.cpp a menudo se comparan como si fueran motores de inferencia rivales. La elección real es entre un servicio de modelos gestionado y un conjunto de herramientas que operas directamente.

Ollama envuelve una versión fijada y parcheada de llama.cpp dentro de un planificador, un almacén de modelos y una API, de modo que el modelo con nombre se convierte en la unidad que operas. llama.cpp directo invierte esto: el proceso llama-server y sus banderas (flags) son la unidad, y cada decisión sobre el contexto, la caché KV y la colocación en GPU es algo que tú realizas y que puedes mostrar en un comando.

Esta guía compara ambos de la manera en que realmente se toma la decisión: instalación y comandos diarios, gestión y ciclo de vida de modelos, control del runtime, APIs, rendimiento, modos de fallo y seguridad. Termina con disparadores concretos para mantener Ollama, pasar a llama-server y una ruta de migración de bajo riesgo entre ellos. Si aún estás decidiendo entre enfoques locales, autoalojados (self-hosted) y en la nube a un nivel más alto, comienza con la visión general del alojamiento de LLM; para el panorama más amplio de herramientas locales más allá de esta pareja, la comparación de alojamiento de LLM locales cubre vLLM, LM Studio, LocalAI y más.

llama.cpp vs Ollama: la respuesta corta

Si solo necesitas un backend confiable para Open WebUI, un asistente de programación o unos pocos guiones locales, Ollama suele ser la opción menos distrayente. Si sigues preguntándote qué seleccionó, asignó, cambió u ocultó Ollama, probablemente hayas llegado al punto en el que llama-server es el sistema más limpio.

Lo que la comparación realmente significa en 2026

llama.cpp es un proyecto de inferencia en C y C++ con backends de CPU y GPU, herramientas de modelos GGUF, programas de línea de comandos y un servidor HTTP. Su programa de servicio directo soporta Chat Completions compatible con OpenAI, Responses, incrustaciones (embeddings), solicitudes multimodales, llamada de funciones, salida estructurada, lotes continuos, decodificación especulativa, endpoints de monitoreo y una interfaz web integrada.

Ollama es un servicio de nivel superior. Mantiene un almacén local de modelos, da a los modelos nombres estables, descarga e importa artefactos, aplica plantillas y valores predeterminados, selecciona un backend disponible, planifica procesos de modelo y descarga los modelos inactivos. Su API nativa también informa tiempos de carga y procesamiento que son convenientes para aplicaciones locales.

La afirmación frecuentemente repetida de que “Ollama es solo una envoltura alrededor de llama.cpp” es útil en dirección pero técnicamente incompleta. Ollama fija el código fuente de llama.cpp, aplica parches de compatibilidad y lanza un servidor a través de su propio planificador, pero también tiene un comportamiento de producto que llama.cpp no define; en el silicio de Apple, Ollama puede usar su motor MLX. La ruta de la solicitud hace que la diferencia sea concreta:

Esto conduce al modelo mental más útil:

• Con Ollama, el modelo con nombre es la unidad que operas.
• Con llama.cpp directo, el proceso del servidor y sus banderas son la unidad que operas.

Instalación y la superficie de comandos diarios

Ollama optimiza los primeros cinco minutos. Tras la instalación, descargar y iniciar un modelo es deliberadamente breve:

ollama run qwen3:8b

El nombre del modelo representa más que sus pesos. Ollama puede asociar una plantilla, parámetros, un prompt del sistema, una licencia, un adaptador y una versión mínima de runtime con ese nombre. ollama list, ollama show, ollama ps y ollama stop proporcionan una superficie de gestión coherente.

llama.cpp directo comienza más cerca del metal. Puedes descargar un binario de lanzamiento, compilar una versión específica de backend, usar un contenedor o usar la ruta de descarga más reciente de Hugging Face, como detalla el inicia rápida de llama.cpp. Un servidor local GGUF podría iniciarse así:

llama-server \
  --model /srv/models/qwen3-8b-q4_k_m.gguf \
  --alias qwen3-8b \
  --host 127.0.0.1 \
  --port 8080 \
  --ctx-size 32768 \
  --n-gpu-layers all \
  --flash-attn on

La documentación actual de llama.cpp también muestra el comando unificado llama serve en su guía de inicio rápido. Los nombres de los ejecutables empaquetados pueden variar según la distribución, así que comprueba la versión de lanzamiento o el paquete que instalaste en lugar de copiar un archivo de servicio a ciegas.

El comando más largo no es automáticamente una desventaja. Es un registro ejecutable del runtime que pretendías crear. Ponlo en una unidad de systemd, un archivo Compose o un guión de shell, y la configuración se vuelve revisable en lugar de estar dispersa entre un manifiesto de modelo, variables de entorno, opciones de API y valores predeterminados del planificador.

La compensación práctica de instalación

Ollama es más fácil de instalar de manera consistente en máquinas de desarrollo. También es más fácil de explicar a alguien que debe usar un modelo pero no necesita entender la descarga de tensores, plantillas de chat o memoria KV.

llama.cpp es más fácil de hacer exacto. Tú eliges la compilación, el backend, la versión, el archivo y las banderas, lo cual es valioso cuando un nuevo kernel de GPU corrige tu carga de trabajo o un commit reciente lo rompe. Esa libertad también significa que tú eres responsable de las actualizaciones, la supervisión del servicio y las pruebas de regresión.

Gestión de modelos: nombres de librería o archivos comunes

Ollama trata los modelos de manera similar a las imágenes de contenedor. Un nombre familiar apunta a un manifiesto y blobs con dirección de contenido, y ollama pull resuelve las capas necesarias. Esto es excelente para la configuración repetible de estaciones de trabajo y para aplicaciones que deberían referirse a qwen3:8b en lugar de una larga ruta de sistema de archivos.

Un Modelfile hace que la personalización sea reproducible:

FROM ./qwen3-8b-q4_k_m.gguf
PARAMETER num_ctx 32768
PARAMETER temperature 0.7
PARAMETER top_p 0.9
SYSTEM Eres un asistente técnico preciso.

ollama create qwen3-8b-local -f Modelfile
ollama run qwen3-8b-local

Ollama puede importar un GGUF local, por lo que elegir Ollama no te restringe a la librería pública de Ollama. Sin embargo, el paso de importación entrega el artefacto al almacén de modelos de Ollama. Si también retienes el GGUF original para llama.cpp o LM Studio, ten en cuenta la copia adicional gestionada a menos que tu capa de almacenamiento la deduplique.

llama.cpp simplemente puede apuntar al GGUF que ya tienes. También puede descargar una cuantización seleccionada de Hugging Face:

llama-server -hf ggml-org/Qwen3-8B-GGUF:Q4_K_M

Este enfoque orientado a archivos funciona especialmente bien para probar cuantizaciones nuevas. Descarga un archivo, cambia una ruta y arráncalo; no hay un paso de creación y no hay duda sobre a qué blob resuelve un nombre de modelo.

Las plantillas son parte del modelo, incluso cuando parecen configuración

Los pesos no definen todo el comportamiento del chat. La plantilla de chat controla cómo los mensajes del sistema, del usuario, del asistente, de pensamiento y de herramientas se convierten en tokens. Las secuencias de parada y el comportamiento del parser pueden cambiar el resultado de nuevo.

La librería curada de Ollama reduce este riesgo porque sus modelos con nombre llevan metadatos probados, y las versiones actuales (Ollama pasó de 0.30 a 0.33.3 entre junio y septiembre de 2026) respetan cada vez más directamente los parámetros predeterminados definidos en GGUF en lugar de requerir que los reiteres en un Modelfile. Un GGUF importado manualmente aún puede necesitar una TEMPLATE, un parser o un renderizador correctos, mientras que llama.cpp normalmente lee la plantilla de chat de GGUF integrada y te permite sobrescribirla. Ningún runtime puede reparar metadatos de modelo incorrectos o faltantes por arte de magia.

Si el mismo modelo cuantizado se siente notablemente peor tras un cambio de runtime, no concluyas que un motor ha dañado los pesos. Primero compara la plantilla, el límite de contexto, los valores de muestreo, el modo de pensamiento, el parser de herramientas y la revisión del runtime, una variable a la vez, antes de tocar el modelo en sí.

Ciclo de vida del modelo y conmutación

El planificador de Ollama es una de sus razones de existencia más fuertes. Por defecto, un modelo inactivo permanece cargado durante cinco minutos; un valor keep_alive a nivel de solicitud puede mantenerlo residente indefinidamente, cambiar la duración o descargarlo inmediatamente. ollama ps muestra los modelos cargados, la colocación del procesador, la asignación de contexto y la expiración.

# Mantener un modelo cargado.
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": -1
}'

# Descargarlo inmediatamente.
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": 0
}'

Un proceso tradicional de llama-server --model ... carga un modelo y lo mantiene hasta que el proceso termina. Ese comportamiento es maravillosamente predecible para un servicio dedicado: no hay una carga en frío sorpresiva después de un tiempo de inactividad ni un planificador que decida que otro modelo merece la memoria.

llama.cpp ahora también tiene modo enrutador. Iniciar llama-server sin un modelo puede exponer modelos en caché, un directorio GGUF o preconfiguraciones INI y cargar instancias dinámicamente según el nombre del modelo solicitado. Cierra el antiguo vacío de ciclo de vida solo parcialmente: solo un modelo es residente por trabajador a la vez, una conmutación es una descarga y recarga completa en lugar de instantánea, y no hay política de expulsión ni piscina tibia (warm pool); cada solicitud alterna entre dos modelos paga una recarga completa. Esto estrecha la brecha frente a no tener modo enrutador en absoluto, pero no hace que los dos productos sean idénticos; Ollama aún proporciona el registro más suave, la piscina tibia y la experiencia de administración. Para la guía completa de configuración, las limitaciones actuales y una comparación honesta con Ollama y llama-swap, ver la guía del modo enrutador de llama-server. Si necesitas un endpoint entre llama.cpp, vLLM, SGLang y otros motores, llama-swap es una abstracción más adecuada que pedir a cualquiera de los runtimes que se convierta en un proxy de modelos universal.

Control del runtime: donde llama.cpp justifica el trabajo extra

La ventaja decisiva de llama.cpp no es que siempre sea más rápido. Es que puedes expresar directamente el plan de memoria y ejecución, inspeccionarlo y cambiar una variable a la vez.

Precisión de contexto y caché KV

Para llama.cpp directo, el tamaño del contexto y los tipos de caché K/V se pueden establecer por proceso del servidor:

llama-server \
  --model model.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --parallel 2 \
  --flash-attn on

K y V pueden usar tipos diferentes, y llama.cpp expone controles adicionales para la asignación unificada de KV, límites de contexto por slot, reutilización de la caché de prompt y persistencia de la caché. Estas banderas no son decorativas en una GPU de 16 GB o 32 GB; determinan si las solicitudes de contexto largo caben y cuántos slots pueden permanecer útiles, y el cálculo del presupuesto de VRAM subyacente es el mismo sin importar qué runtime lo imponga; ver Caché KV en GPUs de 16 GB para la fórmula y las tablas de tipos de caché por motor.

Ollama expone el caso común importante con OLLAMA_CONTEXT_LENGTH, la opción num_ctx y OLLAMA_KV_CACHE_TYPE. Sin embargo, su tipo de caché KV es una configuración a nivel de servidor, en lugar de una elección por modelo con nombre. Ollama también escala la memoria con la paralelidad y la longitud de contexto configuradas, lo que puede hacer que un cambio inofensivo de concurrencia consuma mucha más VRAM.

Ese comportamiento pertenece principalmente a la guía de solicitudes paralelas de Ollama. Para esta comparación, la decisión es más simple: usa Ollama cuando una política de caché global sea aceptable; usa servicios separados de llama.cpp cuando diferentes modelos necesiten diferentes precisiones de caché, contexto o geometría de slots.

Selección de GPU y colocación multi-GPU

Ollama apunta a elegir una colocación sensata. Informa si un modelo está completamente en GPU, completamente en CPU o dividido, y su planificador considera la memoria disponible al cargar modelos. Para una estación de trabajo normal de GPU única, la colocación automática suele ser exactamente lo que quieres.

llama.cpp expone el plan. Puedes seleccionar dispositivos, especificar capas de GPU, elegir modos de división de tensores por capa, fila o experimentales, establecer proporciones de tensores, seleccionar la GPU principal y mantener deliberadamente los pesos de expertos MoE en CPU. Esto es sustancialmente mejor para máquinas multi-GPU asimétricas y para apretar un modelo demasiado grande en un presupuesto de memoria conocido.

Si tus notas operativas contienen frases como “pon la caché KV en estos dispositivos” o “mantén solo los expertos en la RAM del sistema”, llama.cpp directo es la herramienta natural. Si el requisito es simplemente “usa la GPU si cabe”, Ollama ahorra tiempo sin renunciar a mucho.

Nuevas funciones y cadencia de backends

llama.cpp directo es donde aparecen primero las nuevas arquitecturas de modelos, tipos de cuantización, kernels de GPU y opciones de servidor experimentales. Eso es valioso durante una semana de lanzamiento de un modelo, cuando el soporte puede depender de un número de compilación específico en lugar del último paquete estable.

Ollama fija deliberadamente una revisión aguas arriba y aplica parches de compatibilidad. Esto puede retrasar una función aguas arriba, pero también puede proteger a los usuarios del cambio constante y integrarlo con el planificador, las plantillas y el empaquetado multiplataforma de Ollama. El acceso más rápido no es lo mismo que la mayor confiabilidad.

Ollama 0.30 redujo sustancialmente un vacío antiguo expandiendo la compatibilidad de GGUF, mejorando el rendimiento de NVIDIA y habilitando Vulkan por defecto para un soporte más amplio de AMD e Intel. La cadencia de lanzamientos de Ollama desde entonces ha seguido siendo rápida: 0.33.3 se lanzó a principios de septiembre de 2026, aproximadamente tres meses después, añadiendo el reporte de tokens de prompt en caché y otra actualización del backend de llama.cpp; por lo tanto, trata cualquier afirmación de versión específica en este artículo, o en cualquier otro lugar, como algo que hay que volver a verificar contra ollama --version en lugar de un hecho permanente. Cualquier comparación que diga que Ollama no puede ejecutar un GGUF local arbitrario, o que Vulkan siempre requiere una opción experimental, ya está desactualizada.

APIs, herramientas, visión y salida estructurada

Ambos runtimes son servidores de API locales creíbles en 2026. Ambos pueden manejar solicitudes de chat comunes al estilo de OpenAI, herramientas, modelos con capacidad de visión, incrustaciones (embeddings), streaming y salida estructurada cuando el modelo y la plantilla lo soportan.

La diferencia está en la superficie circundante:

No trates “compatible con OpenAI” como una certificación binaria. Ollama dice que soporta partes de la API de OpenAI, mientras que llama.cpp evita explícitamente hacer una promesa fuerte de compatibilidad. Antes de cambiar de runtimes, prueba los cuadros de streaming, los argumentos de llamada de herramientas, los campos de razonamiento, los contadores de uso, los cuerpos de error y cualquier endpoint que tu cliente consuma realmente.

Ollama generalmente gana cuando la integración de la aplicación es el trabajo. Sus SDKs e integraciones documentadas hacen que la ruta feliz sea corta. llama.cpp gana cuando el servidor en sí es el objeto de ingeniería: su vista de slots, los tiempos de tokens, las métricas, los esquemas, las plantillas, los adaptadores y los endpoints de bajo nivel son inusualmente útiles durante el diagnóstico.

Rendimiento: hace benchmarks del despliegue, no de la marca

Es tentador preguntar si llama.cpp o Ollama es más rápido. En una ruta GGUF, Ollama puede estar ejecutando un llama.cpp fijado y parcheado debajo, por lo que una respuesta universal a nivel de marca no es útil. Los resultados cambian según la revisión de la compilación, el backend, la atención flash, la asignación de contexto, los slots paralelos, los tamaños de lote, el tipo de caché, la residencia del modelo y si algunas capas cayeron a CPU.

Una comparación justa comienza con el mismo GGUF y prueba dos preguntas diferentes:

1. Arranque en frío: incluye el tiempo de carga del modelo y la latencia de la primera respuesta.
2. Servicio tibio: precarga el modelo y luego mide el procesamiento del prompt y la generación por separado.

Usa primero una solicitud y un slot. Ajusta el tamaño del contexto, el tipo de caché K/V, la temperatura, top-p, la semilla, la salida máxima y la plantilla de chat; confirma la descarga completa en GPU desde los registros o la salida de estado. Solo entonces aumenta la concurrencia, porque Ollama y llama.cpp asignan y planifican el trabajo en paralelo de manera diferente.

Para Ollama, la respuesta final de la API nativa incluye las duraciones de carga, evaluación del prompt y generación, y las versiones actuales también informan directamente los tokens de prompt en caché en esa respuesta: útil para confirmar si la reutilización del prefijo realmente ocurrió antes de atribuir una ganancia de velocidad al runtime. Para llama.cpp, habilita el informe de rendimiento o las métricas de Prometheus e inspecciona la configuración de inicio. Una ganancia de rendimiento del cinco por ciento es inútil si una ejecución usó silenciosamente un contexto más corto, un tipo de caché diferente o una plantilla diferente.

Mi expectativa para el mismo GGUF soportado en una GPU es generalmente una paridad cercana, no una victoria garantizada de llama.cpp. llama.cpp directo puede ganar tras un ajuste deliberado o al adoptar una optimización más nueva; Ollama puede ser tan rápido cuando su motor seleccionado y los valores predeterminados se alinean con la carga de trabajo. Mide después de la configuración, no antes.

Modos de fallo que exponen la diferencia real

El modelo usa CPU inesperadamente

Con Ollama, ejecuta ollama ps e inspecciona PROCESSOR, CONTEXT y el tamaño cargado. Un contexto más grande, otro modelo residente o una ruta de GPU no soportada pueden explicar la división. Revisa los registros del servicio en lugar de asumir que la GPU fue ignorada.

Con llama.cpp, comienza con llama-server --list-devices, luego lee el registro de inicio para la colocación de tensores y los tamaños de búfer. Si estableciste una cantidad exacta de capas, un dispositivo o una división, el comando en sí es evidencia de tu intención; esto es mucho más fácil de reproducir en un informe de error.

Un contexto más largo causa un error de memoria insuficiente

Ollama elige longitudes de contexto predeterminadas según la VRAM disponible, y la documentación actual recomienda al menos 64K para cargas de trabajo de agentes y programación. Esa recomendación no es una promesa de que tu modelo, paralelismo y caché cabrán. Reduce num_ctx, reduce la paralelismo, elige caché KV q8_0 donde sea apropiado, o usa una cuantización de pesos más pequeña. Confirma la imagen real de la memoria con nvidia-smi antes y después de una solicitud larga para saber si el modelo, la caché o ambos son la restricción.

Con llama.cpp, reduce --ctx-size, cambia --cache-type-k y --cache-type-v, baja --parallel o ajusta la descarga. Como cada elección es explícita, es más fácil construir perfiles separados de contexto largo y alta concurrencia en lugar de forzar un compromiso para cada modelo.

La API se conecta, pero las respuestas están mal formadas

A menudo es un problema de plantilla o parser, especialmente con nuevos modelos de razonamiento y llamada de herramientas. Verifica que el GGUF contenga la plantilla de chat esperada y que el runtime reconozca la arquitectura. Compara una solicitud de chat simple antes de depurar el marco de agente superpuesto encima.

En Ollama, inspecciona ollama show --modelfile <nombre> y las capacidades reportadas. En llama.cpp, inspecciona los mensajes de plantilla de inicio, usa --jinja y prueba /v1/chat/completions directamente. Fija la versión de runtime que funciona antes de cambiar otra variable.

Las solicitudes se vuelven lentas después de cambiar de modelo

Ollama puede necesitar descargar un modelo y cargar otro, por lo que separa el tiempo de cola del tiempo de generación. Precarga el modelo importante con una solicitud vacía y establece un valor keep_alive intencional en lugar de depender del valor predeterminado de cinco minutos.

Un proceso dedicado de llama.cpp evita la conmutación sorpresiva porque su modelo permanece residente. Si adoptas el modo enrutador, la carga del modelo se vuelve dinámica de nuevo, y cada conmutación entre dos modelos diferentes es una descarga y recarga completa sin piscina tibia, por lo que monitorea el estado de carga y la latencia de arranque en frío igual que lo harías con Ollama.

La seguridad no es un diferenciador a menos que la configures

Ambos servidores se unen a localhost por defecto, que es el comportamiento correcto para una estación de trabajo. Cambiar el host a 0.0.0.0 convierte un servicio privado de inferencia local en un servicio de red, y ningún producto debería estar expuesto a Internet público simplemente porque una regla de firewall permitió el acceso.

llama.cpp puede imponer claves API y puede terminar TLS, aunque un proxy inverso sigue siendo útil para políticas, límites de tasa y registros. La API local de Ollama no requiere una clave API; ponla detrás de un proxy autenticado o una frontera de red privada si los clientes remotos necesitan acceso. Si necesitas acceso remoto a Ollama, la [guía de Ollama detrás de un proxy inverso](https://www.glukhov.org/es/llm-hosting/ollama/ollama-behind-reverse-proxy/ “Expón Ollama de forma segura detrás de Caddy o Nginx con HTTPS automatizado, puertas de entrada opcionales de Basic Auth o SSO, y proxying correcto de streaming y WebSocket.”}) cubre la configuración de Caddy y Nginx con comprobaciones de streaming y tiempo de espera. Los modelos con capacidad de herramientas aumentan la consecuencia de exponer la aplicación circundante, incluso cuando el servidor de inferencia en sí no ejecuta las herramientas.

Cuando mantener Ollama

Mantén Ollama cuando su automatización elimina más trabajo del que oculta. Es especialmente fuerte para estaciones de trabajo compartidas de desarrollo, aplicaciones locales de escritorio, demostraciones, herramientas de programación y pequeños servicios que rotan entre varios modelos populares.

Ollama también es la opción predeterminada mejor cuando quieres que los colegas reproduzcan una configuración con nombre sin aprender las banderas de llama.cpp. Un Modelfile, una etiqueta de modelo y dos comandos son un contrato operativo útil. La [hoja de referencia de Ollama](https://www.glukhov.org/es/llm-hosting/ollama/ollama-cheatsheet/ “Hoja de referencia de CLI de Ollama: comando ollama serve, ejemplos de comando ollama run, ollama ps, y gestión de modelos.”}) cubre ese flujo de trabajo diario con más detalle.

No migres solo porque llama.cpp directo se vea más técnico. Si tu modelo cabe, la API se comporta correctamente, la latencia es estable y no necesitas un control faltante, reemplazar Ollama crea mantenimiento sin crear capacidad.

Una advertencia que vale la pena seguir con el tiempo: la propia dirección de producto de Ollama ha comenzado a desviarse hacia la infraestructura centralizada. Ollama Turbo es un servicio de aceleración en la nube con control de inicio de sesión superpuesto sobre lo que originalmente era una herramienta local primero, privacidad primero, y no es el único cambio reciente que intercambia el control local por una capa de conveniencia alojada. Si la razón por la que elegiste Ollama en primer lugar era evitar enviar prompts a los servidores de otra persona, ese razonamiento merece una revalidación periódica en lugar de una decisión única; ver [Enshittification de Ollama: Las primeras señales](https://www.glukhov.org/es/llm-hosting/ollama/ollama-enshittification/ “Resumen de las primeras señales de la enshittification de Ollama: monetización de nube Turbo, telemetría, comportamiento de autoinicio y regresiones de rendimiento.”}) para los cambios específicos y qué observar. llama.cpp directo no tiene una venta cruzada alojada equivalente hacia la cual desviarse, lo cual es en sí mismo un punto de datos cuando se pondera el control a largo plazo contra la conveniencia a corto plazo.

Cuando pasar a llama-server

Pasa a llama-server directo cuando una o más de estas afirmaciones son verdaderas:

• Necesitas una nueva función de llama.cpp o una corrección de modelo antes de que llegue a Ollama.
• Debes fijar un commit exacto de llama.cpp y una compilación de backend.
• Modelos diferentes necesitan tipos de caché K y V o diseños de slots diferentes.
• Necesitas una colocación multi-GPU deliberada en lugar de una selección automática.
• Estás probando decodificación especulativa, MTP, escalas LoRA, caché de prompt o muestreadores inusuales.
• Las métricas nativas, el estado de los slots o las partes internas del servidor son necesarios para el diagnóstico. -Quieres que los archivos GGUF originales permanezcan como el catálogo de modelos autorizado.
• Un modelo debería permanecer residente durante el ciclo de vida de un proceso supervisado.

El disparador de migración más limpio es la inspección repetida. Si cada incidente comienza con descubrir qué eligió Ollama antes de que puedas diagnosticar el modelo, haz esas elecciones explícitas en una definición de servicio de llama.cpp.

Una migración de bajo riesgo de Ollama a llama.cpp

No comiences reproduciendo cada función de Ollama. Migra un modelo y un cliente, conserva el endpoint actual hasta que la comparación esté completa y mantén el mismo GGUF si es posible.

1. Registra ollama --version, ollama show <modelo>, ollama show --modelfile <modelo> y ollama ps.
2. Localiza o descarga el GGUF equivalente y cualquier proyector multimodal.
3. Inicia un llama-server con un alias, contexto, descarga en GPU, tipos de caché y cantidad de slots explícitos.
4. Envía una solicitud de chat simple, una solicitud de salida estructurada y una llamada de herramienta directamente a cada API.
5. Prueba el cliente real, incluyendo streaming y manejo de errores.
6. Compara la latencia de carga en frío, la velocidad del prompt tibio, la velocidad de generación, la VRAM y el formato de la respuesta.
7. Solo entonces reemplaza la URL del servicio o añade un proxy delante de ambos backends.

Para una prueba de humo simple al estilo OpenAI:

curl http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3-8b",
    "messages": [
      {"role": "user", "content": "Devuelve exactamente: runtime-ok"}
    ],
    "temperature": 0,
    "max_tokens": 16
  }'

Luego verifica el servicio en sí:

# llama.cpp
llama-server --version
llama-server --list-devices
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/v1/models

# Ollama
ollama --version
ollama ps
curl http://127.0.0.1:11434/api/ps
curl http://127.0.0.1:11434/v1/models

Si la aplicación depende de la forma de la respuesta nativa de /api/chat de Ollama, cambiar la URL base no es suficiente. Migra el cliente a una ruta compatible con OpenAI primero o añade un adaptador. La más amplia [guía de migración de Ollama a vLLM](https://www.glukhov.org/es/llm-hosting/comparisons/ollama-to-vllm-migration/ “Aprende cuándo migrar de Ollama a vLLM. Señales de migración, pasos de planificación, configuración de Docker Compose y una lista de verificación práctica para mover tu servidor local de LLM.”}) discute el mismo principio de contrato primero para un salto de runtime más grande.

Veredicto final

Ollama es el electrodoméstico de modelos local mejor. Proporciona un catálogo de modelos, recetas reproducibles, una colocación automática sensata, APIs convenientes y gestión del ciclo de vida sin exigir que cada usuario se convierta en un operador de inferencia.

llama.cpp es el instrumento de precisión mejor. llama-server expone suficiente del plan de ejecución para hacer que la VRAM restringida, el contexto largo, el hardware inusual, el soporte de nuevos modelos y los experimentos controlados sean comprensibles en lugar de misteriosos.

Para la mayoría de las personas, la secuencia correcta no es Ollama o llama.cpp para siempre. Comienza con Ollama, aprende qué restricciones importan realmente, y mueve la carga de trabajo afectada a llama.cpp directo cuando puedas nombrar el control que necesitas. Esa es una razón mucho más fuerte que perseguir una prueba de rendimiento medida bajo los valores predeterminados de otra persona.

Referencias

• Proyecto llama.cpp y backends soportados
• Características, banderas, endpoints y modo enrutador de llama-server
• FAQ de Ollama: contexto, keep-alive, concurrencia y caché KV
• Referencia de Modelfile de Ollama
• Importando modelos GGUF y Safetensors a Ollama
• Compatibilidad de la API de OpenAI de Ollama
• Cambios de GGUF, NVIDIA y Vulkan en Ollama 0.30
• Cómo Ollama fija y parchea llama.cpp
• Soporte de hardware de Ollama
• Valores predeterminados de longitud de contexto de Ollama
• Lanzamientos de Ollama (GitHub)