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 comodidad puede ocultar el momento en que un experimento local se convierte en un servicio de inferencia compartido que necesita una mejor planificación y observabilidad.

Es ahí donde vLLM se vuelve relevante. Sin embargo, migrar de Ollama a vLLM no es una actualización automática. Es un intercambio: se cede parte de la simplicidad de Ollama a cambio de un mayor control sobre el loteo (batching), la gestión de memoria, la concurrencia, la inferencia distribuida y las operaciones de producción.

Esta guía cubre las señales prácticas que indican que la migración está justificada, los riesgos de migrar demasiado pronto y un enfoque por etapas que permite mantener ambos servidores funcionando en paralelo durante la validación. El objetivo es ayudar a decidir basándose en mediciones y no en listas de funciones. Para obtener una visión más amplia de las opciones locales, autoalojadas y en la nube, más allá de solo estos dos entornos de ejecución, consulte Alojamiento de LLM en 2026: Comparación de infraestructura local, autoalojada y en la nube.

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 un 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 planificación de solicitudes de alto rendimiento, la gestión eficiente de la caché KV, el loteo continuo, la paralelización de modelos y la compatibilidad con aplicaciones diseñadas para APIs estilo OpenAI.

Esta distinción es importante porque los dos servidores pueden parecer similares 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 somete a una carga sostenida o concurrente.

Un resumen útil:

La pregunta no es qué servidor es universalmente mejor. Es si su carga de trabajo aún coincide con el modelo operativo que hace atractivo a Ollama. Si desea una visión más completa que abarque 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 ha Superado a Ollama

Una respuesta lenta no justifica, por sí sola, una migración. La velocidad de generación suele estar 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, en lugar del motor de servicio, y las señales de migración más fuertes solo aparecen una vez que la forma misma de la carga de trabajo comienza a importar.

Varios Usuarios Causan Latencia Inestable

Un servidor local de LLM 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 una única solicitud con un prompt grande puede afectar a todos los que comparten el modelo.

Ollama puede procesar solicitudes paralelas, y OLLAMA_NUM_PARALLEL controla cuántas solicitudes un modelo cargado puede manejar concurrentemente; consulte cómo Ollama maneja las solicitudes paralelas para conocer la mecánica de cola y memoria detrás de esa configuración. Esa paralelización no es gratuita: los requisitos de memoria crecen tanto con la cantidad de solicitudes paralelas configurada como con la longitud del contexto.

Esto a menudo es la primera advertencia práctica. Una configuración que funciona para una conversación de 8K de un solo usuario 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 a través del loteo continuo. 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 terminan; un modelo de planificación que generalmente se vuelve más valioso a medida que aumenta la concurrencia.

La Utilización de la GPU es Baja Mientras Hay Solicitudes en Cola

Una cola no significa necesariamente que la GPU esté completamente utilizada. En una configuración de servicio simple, el trabajo puede serializarse incluso cuando solicitudes adicionales podrían haber contribuido con cálculos útiles al paso de decodificación actual.

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

El resultado no garantiza una latencia más baja para cada solicitud individual. Sin embargo, bajo carga, 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 codificación de contexto largo, los pipelines RAG y las sesiones de agentes pueden enviar repetidamente system prompts grandes o prefijos de documentos compartidos. Procesar esos tokens de entrada es la etapa de prelleno (prefill), y puede dominar el tiempo hasta el primer token.

vLLM admite prelleno fragmentado (chunked prefill) y caché de prefijo automático. La caché de prefijo permite que las solicitudes posteriores reutilicen bloques de la caché KV cuando su secuencia inicial de tokens coincide con un prefijo ya procesado.

Esto es particularmente útil cuando las solicitudes comparten:

• Un system prompt largo
• Las mismas definiciones de herramientas
• Un resumen estable del repositorio
• Ejemplos few-shot repetidos
• Un prefijo de documento RAG común
• Un historial de conversación compartido

La caché de prefijo no hace que la generación de salida sea más rápida. Reduce el cálculo repetido del prompt, por lo que su beneficio depende de si las solicitudes contienen realmente prefijos idénticos reutilizables.

Necesita Más de una GPU

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

Esto no hace que la inferencia multi-GPU sea fácil. El ancho de banda de interconexión de la 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 una ruta deliberada para la inferencia distribuida. Ollama suele ser una mejor opción para un solo escritorio o estación de trabajo donde el modelo elegido ya cabe cómodamente.

Necesita Observabilidad a Nivel de Producción

Las respuestas de la API de Ollama exponen campos de temporización útiles, como la duración de la carga del modelo, la duración de la evaluación del prompt, la cantidad de tokens generados y la duración de la generación. Estos valores son suficientes para la medición de rendimiento local y la registación a nivel de aplicación.

vLLM expone métricas compatibles con Prometheus a través de su punto de extremo /metrics. Esto facilita hacer seguimiento del volumen de solicitudes, las colas, el tiempo hasta el primer token, la latencia entre tokens, el uso de la caché, las suspensiones (preemptions), el rendimiento y los resultados de las 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 de tamaño insuficiente, un límite de contexto excesivo, una mala planificación, una carga fría del modelo o simplemente demasiadas solicitudes simultáneas.

Donde vLLM Gana Realmente

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

Loteo Continuo (Continuous Batching)

El loteo estático 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 pide una clasificación corta, otro envía un prompt de 20K tokens y un tercero genera varios miles de tokens de código.

El loteo continuo cambia el lote activo a medida que avanzan las solicitudes. Las secuencias completadas salen, las nuevas 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. Brinda poco beneficio cuando un solo usuario envía una solicitud a la vez.

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

Durante la generación, el servidor almacena las claves y valores de atención para los tokens procesados previamente. Esta caché KV puede consumir una gran cantidad de memoria de la 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 los desperdicios evitables alrededor de ese costo. Para la aritmética detrás de ese costo subyacente —cuántos bytes necesita realmente una determinada longitud de contexto, y cómo la precisión de la caché (FP8, Q8_0, Q4_0) se contrapone a ello en una tarjeta de 16 GB—, consulte Caché KV en GPUs de 16 GB.

Caché de Prefijo

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

La caché de prefijo automática puede reutilizar la caché calculada 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, las marcas de tiempo, el orden de los documentos o los 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 admite varias formas de paralelismo, incluyendo tensor, pipeline, datos, experto y paralelismo de contexto. No todos los despliegues necesitan estos modos, pero su disponibilidad es importante cuando un servicio crece más allá de una GPU.

Para una estación de trabajo con dos GPUs adecuadas, el paralelismo de tensor 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 un rendimiento adicional.

Estas funciones introducen complejidad operativa. Deben adoptarse porque las mediciones demuestren 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 la GPU, la longitud máxima del modelo, las secuencias activas máximas, la cuantización, los tipos de datos de la caché, decodificación especulativa, llamada a 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 Aún Gana

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 solo desarrollador que usa una interfaz de chat, un asistente de código o una API local ocasional, las ventajas operativas de vLLM pueden no compensar nunca 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 adecuado para la experimentación y el uso privado en el escritorio.

Colecciones de Modelos GGUF

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

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

Descarga Mixta de CPU y GPU

La inferencia en el escritorio a veces depende de la descarga parcial a la GPU porque el modelo completo no cabe en la VRAM. Esto puede ser práctico para un 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 requerida pueden ser servidos eficazmente por la configuración de aceleradores disponible. Una carga de trabajo que depende en gran medida de la RAM del sistema y la descarga a la CPU puede ser más adecuada para Ollama o llama.cpp.

Cambio Rápido de Modelos

Ollama facilita descargar, ejecutar, detener y cambiar entre muchos modelos locales. Eso es útil para la evaluación, la escritura, la codificación, las incrustaciones (embeddings), la visión y la experimentación ad hoc.

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

Administración Mínima

Ollama es intencionalmente de opiniones fuertes (opinionated). 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 solo usuario, una latencia aceptable y ninguna cola significativa, la migración es probable que cree 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 una métrica incompleta. Dos servidores pueden producir un rendimiento de decodificació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 entre tokens
• Latencia de solicitud de extremo a extremo
• Rendimiento de procesamiento del prompt
• Rendimiento de tokens de salida
• Solicitudes completadas por minuto
• Tiempo de espera en cola
• Consumo de memoria de la GPU
• Utilización de la GPU
• Tasa de fallas y timeouts

Ejecute 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, es más probable que la prueba compare el empaquetamiento 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 su tráfico real. Para un asistente de codificación compartido, esto podría incluir system prompts largos, prefijos repetidos, respuestas en streaming y de dos a ocho sesiones simultáneas.

Planificar la Migración del Modelo Primero

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

Antes de cambiar el servidor, identifique:

1. La familia y versión original del modelo
2. Si es un modelo base o ajustado por instrucciones (instruction-tuned)
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 a herramientas o salida estructurada
8. Cualquier adaptador LoRA o system prompt personalizado

Luego elija un checkpoint compatible con vLLM que coincida con el comportamiento previsto. No asuma que un checkpoint AWQ o FP8 se comportará de manera idéntica 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.

Verificar 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
+ grafos CUDA y asignaciones de tiempo de ejecución
+ espacio de trabajo temporal
+ cachés del 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 de contexto máxima reduce el número de solicitudes simultáneas que pueden caber, incluso si la mayoría de las solicitudes nunca usa el límite completo.

Comience con un --max-model-len realista en lugar del mayor valor anunciado por el modelo, y evite configurar la utilización de memoria de la GPU de manera tan agresiva que una variación menor en la carga de trabajo cause fallas de falta de memoria. Un servicio estable con una capacidad teórica ligeramente menor es más útil que uno que falla en su primer pico de tráfico.

Un Despliegue Mínimo de Docker Compose para vLLM

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}

Cree un archivo de entorno:

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

Inicie el servidor:

docker compose up -d

Revise los registros:

docker compose logs -f vllm

Pruebe el punto de extremo de modelos:

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

Envíe 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, fije la imagen a una liberación de vLLM probada en lugar de dejarla en latest. Revise las notas de liberación antes de actualizar, ya que las opciones de línea de comandos, las implementaciones de modelos, las métricas y el 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—, consulte el Inicio rápido de vLLM.

La Compatibilidad con la API de OpenAI No es Interchangeabilidad Completa

Tanto Ollama como vLLM proporcionan puntos de extremo 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 de 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 debería probarse a nivel de función. Examine:

• Comportamiento de eventos de streaming
• Parámetros de solicitud soportados
• Selección de plantilla de chat
• Análisis de llamadas a herramientas
• Manejo de salida de razonamiento
• Salida restringida por JSON o esquema
• Puntos de extremo de incrustaciones (embeddings)
• Entradas multimodales
• Informe de uso de tokens
• Formatos de respuesta de error
• Descubrimiento del nombre del modelo
• Aplicación de la longitud de contexto

Un cliente que solo envía completados de chat ordinarios suele ser más fácil de migrar que un marco de agentes (framework) que depende de un analizador de llamadas a herramientas particular o de 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 generalmente se obtiene de la configuración del tokenizador del modelo, aunque un operador puede proporcionar una explícitamente.

Un servidor puede iniciarse 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 del sistema son ignoradas
• Las llamadas a herramientas están mal formadas
• 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, compare el prompt totalmente renderizado usado por cada despliegue.

Usar una Migración por Etapas

Reemplazar un servidor local que funciona en un solo paso crea un riesgo innecesario. Ollama y vLLM pueden funcionar en paralelo en diferentes puertos mientras valida el nuevo despliegue.

Etapa 1: Reproducir un Modelo

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

Etapa 2: Validar el Comportamiento de la API

Ejecute pruebas de integración existentes contra el punto de extremo de vLLM, incluyendo streaming, cancelación, timeouts, llamadas a herramientas, solicitudes mal formadas, desbordamiento de contexto y acceso concurrente. Registre las diferencias de comportamiento en lugar de ocultarlas detrás de reintentos del cliente.

Etapa 3: Establecer una Línea Base

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

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

Etapa 4: Agregar Concurrencia Realista

Pruebe el número de solicitudes simultáneas esperadas en la operación normal y durante un pico plausible, usando longitudes representativas de prompt y salida en lugar de solicitudes sintéticas idénticas. Observe las colas, el uso de la caché, las suspensiones, el tiempo hasta el primer token y la latencia de cola (tail latency).

Etapa 5: Mover un Cliente

Dirija una aplicación no crítica o un pequeño porcentaje del tráfico a vLLM. Mantenga Ollama disponible como alternativa (fallback) hasta que el nuevo servidor haya operado de manera confiable bajo uso real.

Etapa 6: Ajustar Desde las Mediciones

Ajuste la longitud del modelo, la utilización de memoria, las secuencias activas máximas, la caché de prefijo, 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 Práctica de Migración

Antes de cambiar clientes, verifique lo siguiente:

[ ] El modelo de destino es soportado por vLLM
[ ] El checkpoint y la cuantización seleccionados caben en la VRAM
[ ] Queda suficiente VRAM para la caché KV requerida
[ ] La longitud de contexto máxima refleja el uso real
[ ] La plantilla de chat correcta está disponible
[ ] Los tokens de parada y los valores predeterminados de generación están probados
[ ] El streaming funciona con los clientes existentes
[ ] Las llamadas a 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 recogen métricas de Prometheus
[ ] Las métricas de la GPU se recogen por separado
[ ] Las pruebas de carga incluyen concurrencia realista
[ ] Los timeouts y cancelaciones se manejan
[ ] Existe una ruta de reversión (rollback) a Ollama

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

Seguridad y Exposición de Red

Ni un punto de extremo local de Ollama ni uno de vLLM deberían exponerse casualmente a internet público. Un servidor de inferencia no autenticado puede consumir capacidad costosa de la GPU, 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 largos.

vLLM puede requerir una clave de API para sus puntos de extremo compatibles con OpenAI, pero una clave de API no es una frontera de seguridad completa. Para el acceso compartido o remoto, coloque el servicio detrás de un proxy inverso o una puerta de enlace de API que proporcione TLS, restricciones de red, límites de tamaño de solicitud, límites de tasa, registros de acceso y autenticación adecuada; el mismo patrón cubierto en Ollama detrás de un proxy inverso con Caddy o Nginx se aplica igual de bien delante de vLLM.

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

Cuando No Migrar

Quédese con Ollama cuando:

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

Un paso 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 conserve Ollama solo porque era más fácil de instalar. Si los usuarios esperan regularmente en una cola, los prefijos repetidos consumen tiempo significativo de prelleno, 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.

Mantener Ollama para Desarrollo y Agregar vLLM para Servicio Compartido

La arquitectura más práctica a menudo no es una reemplazo completo. Los desarrolladores pueden mantener [Ollama funcionando en Docker Compose](https://www.glukhov.org/es/llm-hosting/ollama/ollama-in-docker-compose/ “Ejecute Ollama en Docker Compose”}) en sus estaciones de trabajo para la 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 separación también importa para la soberanía de la IA —mantener ambos entornos de ejecución autoalojados significa que los prompts, los pesos y los registros de inferencia permanecen bajo su control, sin importar 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 extremo compartido -> tráfico concurrente -> monitoreo

La disposición también reduce el riesgo de migración. Los modelos pueden probarse localmente antes de que un checkpoint adecuado se promocione 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 un ejecutor local de modelos. Elimina suficiente trabajo de empaquetamiento y configuración para que los desarrolladores puedan concentrarse en el modelo y la aplicación en lugar del stack de inferencia.

vLLM se convierte en la opción más fuerte cuando el propio servidor es el problema que debe ser ingenierizado. 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 migre porque vLLM tenga una lista de funciones más larga. Migre 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.