De Ollama a vLLM: cuándo migrar tu servidor local de LLM

Ollama es una de las formas más sencillas de ejecutar un modelo de lenguaje local, pero la conveniencia puede ocultar el momento en que un experimento local se convierte en un servicio de inferencia compartido que necesita una mejor programación y observabilidad.

Ahí es donde vLLM se vuelve relevante. Migrar de Ollama a vLLM no es una actualización automática. Es un intercambio: intercambias parte de la simplicidad de Ollama por un mayor control sobre la agrupación por lotes (batching), la gestión de la memoria, la concurrencia, la inferencia distribuida y las operaciones en producción.

Esta guía cubre las señales prácticas que indican que la migración es justificada, los riesgos de migrar demasiado pronto y un enfoque por etapas que mantiene ambos servidores funcionando en paralelo durante la validación. El objetivo es ayudarte a decidir en base a mediciones en lugar de listas de características. Para ver el panorama más amplio de las opciones locales, autoalojadas y en la nube más allá de solo estos dos entornos de ejecución, consulta Alojamiento de LLM en 2026: Infraestructura Local, Autoalojada y en la Nube Comparada.

Ollama y vLLM Resuelven Problemas Diferentes

Ollama está optimizado principalmente para el consumo conveniente de modelos. Ofrece a los desarrolladores una interfaz de línea de comandos concisa, una API local, una biblioteca de modelos, Modelfiles y soporte directo para configuraciones comunes de escritorio y estaciones de trabajo.

vLLM es un motor de inferencia y una plataforma de servicio. Sus preocupaciones centrales son la programación de solicitudes de alto rendimiento, la gestión eficiente de la caché KV, la agrupación continua (continuous batching), el paralelismo de modelos y la compatibilidad con aplicaciones construidas para APIs estilo OpenAI.

La distinción es importante porque los dos servidores pueden parecerse desde el exterior. Ambos pueden exponer una API de chat, transmitir tokens, ejecutar modelos cuantizados y servir aplicaciones locales. Sus modelos operativos se vuelven visiblemente diferentes solo cuando el servidor se coloca bajo una carga sostenida o concurrente.

Un resumen útil:

La pregunta no es qué servidor es universalmente mejor. Es si tu carga de trabajo sigue coincidiendo con el modelo operativo que hace atractiva a Ollama. Si quieres la imagen completa que abarca más de estos dos entornos de ejecución, nuestra comparación de Ollama, vLLM, LocalAI, Jan, LM Studio y otras herramientas locales de LLM cubre el campo más amplio.

Señales de que Has Superado a Ollama

Una respuesta lenta, por sí sola, no justifica una migración. La velocidad de generación a menudo está limitada por el tamaño del modelo, la cuantización, el ancho de banda de memoria, la longitud del prompt o la capacidad de la GPU, más que por el motor de servicio, y las señales de migración más fuertes solo aparecen una vez que la forma de la carga de trabajo en sí comienza a importar.

Múltiples Usuarios Causan Latencia Inestable

Un servidor de LLM local puede sentirse rápido durante una prueba aislada y luego degradarse drásticamente cuando varios clientes se conectan. Las solicitudes comienzan a esperar detrás de generaciones largas, el tiempo hasta el primer token se vuelve inconsistente y un único prompt grande puede afectar a todos los que comparten el modelo.

Ollama puede procesar solicitudes en paralelo, y OLLAMA_NUM_PARALLEL controla cuántas solicitudes puede manejar concurrentemente un modelo cargado — consulta cómo Ollama maneja solicitudes paralelas para conocer la mecánica de colas y memoria detrás de esa configuración. Ese paralelismo no es gratuito: los requisitos de memoria crecen tanto con el conteo de solicitudes paralelas configurado como con la longitud del contexto.

Esta suele ser la primera advertencia práctica. Una configuración que funciona para una conversación de 8K puede volverse imposible cuando cuatro clientes reservan cada uno un contexto mucho más grande.

vLLM está diseñado para combinar el trabajo de solicitudes activas mediante agrupación continua. En lugar de tratar cada solicitud como un trabajo de inferencia aislado, actualiza continuamente el lote a medida que las secuencias llegan, generan tokens y finalizan, un modelo de programación que generalmente se vuelve más valioso a medida que aumenta la concurrencia.

La Utilización de la GPU es Baja Mientras las Solicitudes Están en Cola

Una cola no necesariamente significa que la GPU esté siendo utilizada al máximo. En una configuración de servicio simple, el trabajo puede ser serializado incluso aunque solicitudes adicionales pudieran haber contribuido con computación útil al paso de descodificación actual.

El programador de vLLM está diseñado para mantener más trabajo útil en vuelo. PagedAttention gestiona la memoria de la caché KV en bloques, mientras que la agrupación continua permite que las secuencias activas entren y salgan del lote de ejecución dinámicamente.

El resultado no es garantizar una latencia menor para cada solicitud individual. Bajo carga, sin embargo, puede producir un rendimiento agregado sustancialmente mejor y una utilización de recursos más predecible.

Los Prompts Largos Dominan el Tiempo Hasta el Primer Token

Los asistentes de código de contexto largo, las tuberías RAG y las sesiones de agentes pueden enviar repetidamente prompts de sistema grandes o prefijos de documentos compartidos. Procesar esos tokens de entrada es la etapa de prellenado (prefill), y puede dominar el tiempo hasta el primer token.

vLLM soporta prellenado fragmentado (chunked prefill) y caché de prefijos automática. La caché de prefijos permite que solicitudes posteriores reutilicen bloques de caché KV cuando su secuencia inicial de tokens coincide con un prefijo ya procesado.

Esto es particularmente útil cuando las solicitudes comparten:

• Un prompt de sistema largo
• Las mismas definiciones de herramientas
• Un resumen de repositorio estable
• Ejemplos de pocos disparos (few-shot) repetidos
• Un prefijo de documento RAG común
• Un historial de conversación compartido

La caché de prefijos no hace que la generación de salida sea más rápida. Reduce la computación repetida de prompts, por lo que su beneficio depende de si las solicitudes contienen realmente prefijos reutilizables idénticos.

Necesitas Más de una GPU

Un modelo que no cabe en una sola GPU es una razón fuerte para considerar vLLM. Soporta paralelismo tensorial entre GPUs y paralelismo de pipeline entre múltiples nodos o dispositivos.

Esto no hace que la inferencia multi-GPU sea sin esfuerzo. El ancho de banda de interconexión de GPU, la topología PCIe, la arquitectura del modelo, la memoria compartida del contenedor y la sobrecarga de comunicación aún afectan el rendimiento.

Sin embargo, vLLM proporciona un camino deliberado para la inferencia distribuida. Ollama suele ser una mejor coincidencia para un escritorio o estación de trabajo única donde el modelo elegido ya cabe cómodamente.

Necesitas Observabilidad de Nivel de Producción

Las respuestas de la API de Ollama exponen campos de tiempo útiles como la duración de carga del modelo, la duración de evaluación del prompt, el conteo de tokens generados y la duración de generación. Estos valores son suficientes para pruebas de rendimiento locales y registros a nivel de aplicación.

vLLM expone métricas compatibles con Prometheus a través de su punto de extremos /metrics. Esto facilita el seguimiento del volumen de solicitudes, colas, tiempo hasta el primer token, latencia inter-token, uso de caché, preemptions, rendimiento y resultados de solicitudes a lo largo del tiempo.

Una vez que los usuarios dependen del servicio, la observabilidad deja de ser opcional. Sin métricas de cola, caché y latencia, es difícil distinguir entre una GPU insuficiente, un límite de contexto excesivo, una mala programación, una carga fría del modelo o simplemente demasiadas solicitudes simultáneas.

Donde vLLM Ganará Realmente

La ventaja más importante de vLLM no es que pueda producir una respuesta más rápido que Ollama en cada máquina. La ventaja significativa es que da al operador más mecanismos para usar la memoria y la computación de aceleradores costosos de manera eficiente a través de muchas solicitudes.

Agrupación Continua (Continuous Batching)

La agrupación estática tradicional funciona mejor cuando las solicitudes tienen longitudes de entrada y salida similares. El tráfico interactivo de LLM rara vez se comporta de esa manera: un usuario solicita una clasificación corta, otro envía un prompt de 20K tokens y un tercero genera varios miles de tokens de código.

La agrupación continua cambia el lote activo a medida que avanzan las solicitudes. Las secuencias completadas se van, las nuevas secuencias entran, y el motor intenta evitar desperdiciar capacidad del lote en solicitudes que ya han terminado.

Esto mejora el rendimiento cuando el tráfico es concurrente y desigual. Proporciona poco beneficio cuando un solo usuario envía una solicitud a la vez.

Gestión de Caché KV Paginada (Paged KV Cache Management)

Durante la generación, el servidor almacena claves y valores de atención para tokens procesados anteriormente. Esta caché KV puede consumir una gran cantidad de memoria de GPU, especialmente con contextos largos y múltiples secuencias activas.

vLLM gestiona esta caché en bloques en lugar de requerir que cada secuencia reserve una gran asignación contigua. El enfoque reduce la fragmentación de memoria y permite que la capacidad de caché disponible se use de manera más flexible.

El valor práctico es una mayor concurrencia dentro del mismo presupuesto de memoria. No elimina el costo subyacente del contexto largo, pero reduce el desperdicio evitable alrededor de ese costo.

Caché de Prefijos

Muchas solicitudes de producción comparten un comienzo sustancial. Los agentes habilitados para herramientas pueden enviar esquemas de función idénticos, los bots de soporte pueden usar los mismos documentos de política y los asistentes de código pueden incluir repetidamente las mismas instrucciones de repositorio.

La caché de prefijos automática puede reutilizar la caché computada para prefijos coincidentes. Es especialmente útil cuando un prefijo estable y grande es seguido por un sufijo específico de la solicitud relativamente pequeño.

Es menos útil cuando las plantillas, marcas de tiempo, orden de documentos o metadatos generados dinámicamente cambian cerca del comienzo de cada prompt. Pequeñas diferencias en la tokenización pueden impedir que el prefijo coincida.

Inferencia Paralela y Distribuida

vLLM soporta varias formas de paralelismo, incluyendo paralelismo tensorial, de pipeline, de datos, de expertos y de contexto. No todos los despliegues necesitan estos modos, pero su disponibilidad importa cuando un servicio crece más allá de una sola GPU.

Para una estación de trabajo con dos GPUs adecuadas, el paralelismo tensorial puede permitir que un modelo más grande se ejecute en ambos dispositivos. Para un servicio replicado, el paralelismo de datos puede crear múltiples réplicas del motor para mayor rendimiento.

Estas características introducen complejidad operativa. Deben adoptarse porque las mediciones demuestran un problema de capacidad, no porque la inferencia distribuida parezca más sofisticada.

Controles de Producción Más Amplios

vLLM expone controles para la utilización de memoria de GPU, longitud máxima del modelo, secuencias activas máximas, cuantización, tipos de datos de caché, decodificación especulativa, llamada de herramientas, salida estructurada, alias de modelos, claves de autenticación y ejecución distribuida.

Esa flexibilidad hace que el servidor sea más fácil de ajustar para una carga de trabajo particular, pero también crea más oportunidades para una configuración inválida o ineficiente. Migrar a vLLM significa asumir la responsabilidad de esas decisiones.

Donde Ollama Sigue Ganando

Una guía de migración no debería tratar a Ollama como una herramienta preliminar inferior. Para muchos despliegues locales, sigue siendo el mejor servidor.

Estaciones de Trabajo Personales

Para un desarrollador que usa una interfaz de chat, un asistente de código o una API local ocasional, las ventajas operativas de vLLM pueden nunca compensar su configuración adicional.

Ollama se instala rápidamente, descarga modelos a través de un registro simple y oculta muchos detalles específicos del modelo. Es muy adecuado para experimentación y uso privado de escritorio.

Colecciones de Modelos GGUF

Ollama tiene un flujo de trabajo natural alrededor de los modelos GGUF y Modelfiles. Los usuarios existentes pueden tener cuantizaciones, adaptadores, plantillas, prompts de sistema y parámetros curados que funcionan de manera confiable con su hardware.

vLLM soporta GGUF, pero su camino más fuerte generalmente es a través de repositorios de modelos de Hugging Face soportados y formatos de cuantización como AWQ, GPTQ, BitsAndBytes, FP8 o formatos específicos del proveedor. Mover un despliegue existente de GGUF a vLLM sin evaluar un formato de punto de control más nativo puede preservar la inconveniencia de la migración mientras se pierden algunas de las ventajas de rendimiento.

Descarga Mixta de CPU y GPU

La inferencia de escritorio a veces depende de la descarga parcial de GPU porque el modelo completo no cabe en la VRAM. Esto puede ser práctico para uso ocasional, particularmente cuando la latencia no es crítica.

vLLM es generalmente más convincente cuando el modelo y la capacidad de caché KV requeridos pueden ser servidos efectivamente por la configuración de acelerador disponible. Una carga de trabajo que depende en gran medida de la RAM del sistema y la descarga de CPU puede estar mejor adaptada a Ollama o llama.cpp.

Cambio Rápido de Modelos

Ollama facilita tirar, ejecutar, detener y cambiar entre muchos modelos locales. Eso es útil para evaluación, escritura, codificación, embeddings, visión y experimentación ad hoc.

Un despliegue de vLLM se construye más comúnmente alrededor de un modelo seleccionado deliberadamente que permanece cargado como un servicio. El despliegue de múltiples modelos es posible, pero requiere una planificación de recursos más explícita.

Administración Mínima

Ollama es intencionalmente de opinión. Eso puede ser una limitación bajo carga, pero es una ventaja cuando nadie quiere mantener una plataforma de inferencia, y si el servidor local tiene un usuario, latencia aceptable y ninguna cola significativa, la migración probablemente creará trabajo en lugar de eliminarlo.

No Migrar Basándose Solo en Tokens por Segundo

La velocidad de generación de tokens de una sola solicitud es un indicador incompleto. Dos servidores pueden producir un rendimiento de descodificación similar para una secuencia mientras se comportan muy diferente con ocho clientes concurrentes.

Una evaluación útil debería medir al menos:

• Tiempo hasta el primer token
• Latencia inter-token
• Latencia de solicitud de extremo a extremo
• Rendimiento de procesamiento de prompts
• Rendimiento de tokens de salida
• Solicitudes completadas por minuto
• Tiempo de espera en cola
• Consumo de memoria de GPU
• Utilización de GPU
• Tasa de falla y tiempo de espera (timeout)

Ejecuta la misma familia de modelos, precisión, longitud de contexto, conjunto de prompts, límite de salida y nivel de concurrencia en ambos servidores. De lo contrario, la prueba es más probable que compare el empaquetado y la configuración del modelo que los motores de servicio.

La comparación más útil es una pequeña prueba de carga que represente tu tráfico real. Para un asistente de código compartido, eso podría incluir prompts de sistema largos, prefijos repetidos, respuestas en streaming y dos a ocho sesiones simultáneas.

Planifica la Migración del Modelo Primero

Los nombres de los modelos de Ollama no mapean automáticamente a identificadores de modelos equivalentes de vLLM. Un paquete de Ollama puede contener una cuantización GGUF particular, una plantilla de prompt, configuración de tokens de parada y parámetros predeterminados.

Antes de cambiar el servidor, identifica:

1. La familia y versión original del modelo
2. Si es un modelo base o ajustado por instrucciones
3. La cuantización actual y la precisión efectiva
4. La plantilla de prompt o chat
5. La longitud de contexto configurada
6. Tokens de parada y valores predeterminados de generación
7. Requisitos de llamada de herramientas o salida estructurada
8. Cualquier adaptador LoRA o prompts de sistema personalizados

Luego elige un punto de control soportado por vLLM que coincida con el comportamiento pretendido. No asumas que un punto de control AWQ o FP8 se comportará idénticamente a la construcción GGUF usada previamente en Ollama — la migración del modelo a menudo es más significativa que la migración de la API.

Verifica la VRAM Antes de Iniciar vLLM

Que un modelo quepa en la memoria de la GPU no significa que pueda servir la carga de trabajo requerida. La VRAM debe cubrir más que los pesos del modelo.

El presupuesto de memoria práctico incluye:

pesos del modelo
+ caché KV
+ gráficos CUDA y asignaciones de tiempo de ejecución
+ espacio de trabajo temporal
+ cachés de procesador multimodal, si se usan
+ margen de seguridad

Los contextos largos y las secuencias concurrentes expanden principalmente el requisito de caché KV. Por lo tanto, aumentar la longitud máxima del contexto reduce el número de solicitudes simultáneas que pueden caber, incluso si la mayoría de las solicitudes nunca usan el límite completo.

Comienza con un --max-model-len realista en lugar del valor más grande anunciado por el modelo, y evita configurar la utilización de memoria de GPU tan agresivamente que una variación menor de la carga de trabajo cause fallos de memoria insuficiente. Un servicio estable con ligeramente menos capacidad teórica es más útil que uno que falla en su primer pico de tráfico.

Un Despliegue Mínimo de vLLM con Docker Compose

El siguiente ejemplo inicia un servidor vLLM compatible con OpenAI en el puerto 8000:

services:
  vllm:
    image: vllm/vllm-openai:latest
    container_name: vllm
    restart: unless-stopped
    ports:
      - "8000:8000"
    ipc: host
    gpus: all
    volumes:
      - ${HOME}/.cache/huggingface:/root/.cache/huggingface
    environment:
      HF_TOKEN: ${HF_TOKEN:-}
    command:
      - --model
      - Qwen/Qwen3-8B
      - --served-model-name
      - local-model
      - --max-model-len
      - "16384"
      - --gpu-memory-utilization
      - "0.90"
      - --api-key
      - ${VLLM_API_KEY:-change-me}

Crea un archivo de entorno:

cat > .env <<'EOF'
HF_TOKEN=
VLLM_API_KEY=replace-with-a-long-random-value
EOF

Inicia el servidor:

docker compose up -d

Verifica los registros:

docker compose logs -f vllm

Prueba el punto de extremos de modelos:

curl http://localhost:8000/v1/models \
  -H "Authorization: Bearer replace-with-a-long-random-value"

Envía una solicitud de chat:

curl http://localhost:8000/v1/chat/completions \
  -H "Authorization: Bearer replace-with-a-long-random-value" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-model",
    "messages": [
      {
        "role": "user",
        "content": "Explain continuous batching in two paragraphs."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 300,
    "stream": false
  }'

Para un despliegue mantenido, fija la imagen a una versión de vLLM probada en lugar de dejarla en latest. Revisa las notas de lanzamiento antes de actualizar porque las opciones de línea de comandos, implementaciones de modelos, métricas y comportamiento del motor pueden evolucionar. Este archivo Compose es intencionalmente mínimo; para la guía de configuración más completa — compatibilidad con la API de OpenAI, ajuste de PagedAttention y una comparación más profunda de vLLM-vs-Ollama — consulta el Inicio Rápido de vLLM.

La Compatibilidad con la API de OpenAI No Es Interoperabilidad Completa

Tanto Ollama como vLLM proporcionan puntos de extremos compatibles con OpenAI, lo que puede hacer que la migración de la aplicación sea relativamente pequeña. En muchos clientes, cambiar la URL base, la clave API y el nombre del modelo es suficiente para establecer una conexión.

Por ejemplo:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="replace-with-a-long-random-value",
)

response = client.chat.completions.create(
    model="local-model",
    messages=[
        {
            "role": "user",
            "content": "What should I monitor on an LLM server?",
        }
    ],
    temperature=0.2,
)

print(response.choices[0].message.content)

La compatibilidad aún debe probarse a nivel de características. Examina:

• Comportamiento de eventos en streaming
• Parámetros de solicitud soportados
• Selección de plantilla de chat
• Análisis de llamadas de herramientas
• Manejo de salida de razonamiento
• Salida JSON o restringida por esquema
• Puntos de extremos de embeddings
• Entradas multimodales
• Informe de uso de tokens
• Formatos de respuesta de error
• Descubrimiento de nombres de modelos
• Aplicación de longitud de contexto

Un cliente que solo envía completaciones de chat ordinarias generalmente será más fácil de migrar que un marco de agentes que depende de un analizador de llamadas de herramientas particular o una extensión no estándar.

Las Plantillas de Chat Son un Fallo Común de Migración

Los modelos ajustados por instrucciones esperan que las conversaciones se serialicen usando una plantilla de chat específica. La plantilla inserta marcadores de rol, separadores, tokens de control y prompts de generación en el formato usado durante el entrenamiento.

Ollama empaqueta gran parte de este comportamiento dentro de su definición de modelo. Con vLLM, la plantilla normalmente se obtiene de la configuración del tokenizador del modelo, aunque un operador puede proporcionarla explícitamente.

Un servidor puede iniciar con éxito incluso cuando la plantilla seleccionada es incorrecta. Los síntomas aparecen en el comportamiento del modelo:

• El modelo repite etiquetas de rol
• Las respuestas contienen tokens especiales
• Las instrucciones de sistema son ignoradas
• Las llamadas de herramientas están malformadas
• El modelo continúa el mensaje del usuario
• La calidad de la salida es mucho peor de lo esperado

Antes de culpar al motor de inferencia, compara el prompt completamente renderizado usado por cada despliegue.

Usa una Migración por Etapas

Reemplazar un servidor local funcional en un solo paso crea un riesgo innecesario. Ollama y vLLM pueden funcionar lado a lado en diferentes puertos mientras validas el nuevo despliegue.

Etapa 1: Reproducir Un Modelo

Elige el modelo responsable de la mayor parte del tráfico de la API y coincide su ajuste de instrucciones, requisito de contexto, parámetros de generación y comportamiento de chat lo más cerca posible. No comiences moviendo cada modelo experimental.

Etapa 2: Validar el Comportamiento de la API

Ejecuta pruebas de integración existentes contra el punto de extremos de vLLM, incluyendo streaming, cancelación, tiempos de espera, llamadas de herramientas, solicitudes malformadas, desbordamiento de contexto y acceso concurrente. Registra las diferencias de comportamiento en lugar de ocultarlas detrás de reintentos del cliente.

Etapa 3: Establecer Una Línea Base

Mide el rendimiento de una sola solicitud primero. Esto confirma que el modelo se cargó correctamente y proporciona una referencia para pruebas posteriores.

Registra tokens de prompt por segundo, tokens de salida por segundo, tiempo hasta el primer token, latencia total y uso de memoria de GPU.

Etapa 4: Agregar Concurrencia Realista

Prueba el número de solicitudes simultáneas esperadas en operación normal y durante un pico plausible, usando longitudes de prompt y salida representativas en lugar de solicitudes sintéticas idénticas. Observa la cola, el uso de caché, las preemptions, el tiempo hasta el primer token y la latencia de cola.

Etapa 5: Mover Un Cliente

Enruta una aplicación no crítica o un pequeño porcentaje de tráfico a vLLM. Mantén Ollama disponible como respaldo hasta que el nuevo servidor haya operado de manera confiable bajo uso real.

Etapa 6: Ajustar Desde Mediciones

Ajusta la longitud del modelo, la utilización de memoria, las secuencias activas máximas, la caché de prefijos, el paralelismo y la cuantización solo después de identificar una restricción medida. Cambiar varios parámetros a la vez hace que las regresiones de rendimiento sean difíciles de explicar.

Una Lista de Verificación de Migración Práctica

Antes de cambiar los clientes, verifica lo siguiente:

[ ] El modelo objetivo es soportado por vLLM
[ ] El punto de control y cuantización seleccionados caben en la VRAM
[ ] Resta suficiente VRAM para la caché KV requerida
[ ] La longitud máxima de contexto refleja el uso real
[ ] La plantilla de chat correcta está disponible
[ ] Los tokens de parada y valores predeterminados de generación están probados
[ ] El streaming funciona con clientes existentes
[ ] Las llamadas de herramientas y la salida estructurada están validadas
[ ] El alias público del modelo permanece estable
[ ] La autenticación está habilitada
[ ] El servidor no está expuesto directamente a Internet
[ ] Se recopilan métricas de Prometheus
[ ] Se recopilan métricas de GPU por separado
[ ] Las pruebas de carga incluyen concurrencia realista
[ ] Los tiempos de espera y cancelaciones están manejados
[ ] Existe una ruta de retroceso a Ollama

Esta lista es deliberadamente operativa. Instalar vLLM suele ser más fácil que demostrar que se comporta correctamente para una aplicación existente.

Seguridad y Exposición de Red

Ni un punto de extremos local de Ollama ni uno de vLLM deberían ser expuestos casualmente a Internet público. Un servidor de inferencia sin autenticación puede consumir capacidad de GPU costosa, revelar el comportamiento del modelo y convertirse en una ruta para ataques de denegación de servicio a través de prompts o salidas muy largas.

vLLM puede requerir una clave API para sus puntos de extremos compatibles con OpenAI, pero una clave API no es un límite de seguridad completo. Para acceso compartido o remoto, coloca el servicio detrás de un proxy inverso o puerta de enlace API que proporcione TLS, restricciones de red, límites de tamaño de solicitud, límites de tasa, registros de acceso y autenticación apropiada — el mismo patrón cubierto en Ollama detrás de un proxy inverso con Caddy o Nginx aplica igual de bien frente a vLLM.

También considera los riesgos específicos del modelo. La carga de URLs multimodales, código de modelo personalizado, archivos remotos y ejecución de herramientas sin restricciones pueden expandir la superficie de ataque más allá de la generación de texto ordinaria.

Cuándo No Migrar

Quédate con Ollama cuando:

• Uno o dos usuarios acceden al servidor
• Las solicitudes son mayormente secuenciales
• El modelo ya entrega una latencia aceptable
• La gestión fácil de GGUF es importante
• Se requiere descarga de CPU o GPU parcial
• Los modelos cambian frecuentemente
• Nadie quiere operar infraestructura adicional
• No hay un problema medido de concurrencia o rendimiento

Un movimiento a vLLM debería resolver una limitación concreta. “Producción” no es un umbral mágico que invalide a Ollama, especialmente para un servicio interno con tráfico modesto.

Por el contrario, no conserves Ollama simplemente porque fue más fácil de instalar. Si los usuarios esperan regularmente en una cola, los prefijos repetidos consumen un tiempo de prellenado significativo, o un modelo más grande debe distribuirse entre GPUs, el servidor más simple puede haberse convertido en la opción más costosa operativamente.

Mantén Ollama para Desarrollo y Agrega vLLM para Servicio Compartido

La arquitectura más práctica a menudo no es un reemplazo completo. Los desarrolladores pueden mantener Ollama ejecutándose en Docker Compose en sus estaciones de trabajo para exploración de modelos, pruebas de GGUF y uso interactivo privado, mientras una instancia compartida de vLLM sirve un modelo estable a aplicaciones y equipos. Esa división también importa para la soberanía de IA — mantener ambos entornos de ejecución autoalojados significa que los prompts, pesos y registros de inferencia permanecen bajo tu control independientemente de qué servidor maneje una solicitud dada.

Esto separa dos flujos de trabajo diferentes:

Ollama:
experimentación -> cambio de modelos -> herramientas personales -> chat local

vLLM:
modelo seleccionado -> punto de extremos compartido -> tráfico concurrente -> monitoreo

Este arreglo también reduce el riesgo de migración. Los modelos pueden probarse localmente antes de que un punto de control adecuado se promueva al despliegue compartido de vLLM.

Flujo de Decisión de Migración

El siguiente diagrama resume los puntos clave de decisión:

Conclusión

Ollama es difícil de superar como ejecutor de modelos local. Elimina suficiente trabajo de empaquetado y configuración para que los desarrolladores puedan concentrarse en el modelo y la aplicación en lugar de la pila de inferencia.

vLLM se convierte en la opción más fuerte cuando el servidor en sí es el problema a ingenierizar. El tráfico concurrente, las colas, los prefijos largos repetidos, los modelos multi-GPU, la planificación de capacidad y la observabilidad de producción son las señales de migración que importan.

No migres porque vLLM tenga una lista de características más larga. Migra cuando las mediciones muestren que el modelo operativo más simple de Ollama ya no coincide con la carga de trabajo. Hasta ese punto, la simplicidad no es una debilidad técnica; es una optimización.