Cómo Ollama gestiona las solicitudes paralelas

Esta guía explica cómo Ollama maneja las solicitudes paralelas (concurrencia, colas y límites de recursos) y cómo ajustar su funcionamiento mediante la variable de entorno OLLAMA_NUM_PARALLEL (y configuraciones relacionadas).

Para más información sobre el rendimiento de procesamiento, la latencia, la VRAM y las pruebas de rendimiento entre diferentes runtime y hardware, consulta Rendimiento de LLM: Benchmarks, cuellos de botella y optimización.

Los agentes de múltiples pasos multiplican los reintentos cuando la muestreo es inestable; para conocer los valores predeterminados de temperatura, top_p y penalizaciones en modelos de la clase Qwen y Gemma, consulta parámetros de inferencia agéntica para Qwen y Gemma.

Manejo de solicitudes simultáneas

• Procesamiento paralelo: Ollama admite el procesamiento concurrente de solicitudes. Si el sistema tiene suficiente memoria disponible (RAM para inferencia por CPU, VRAM para inferencia por GPU), se pueden cargar varios modelos a la vez, y cada modelo cargado puede manejar varias solicitudes en paralelo. Esto se controla mediante la variable de entorno OLLAMA_NUM_PARALLEL, que establece el número máximo de solicitudes paralelas que cada modelo puede procesar simultáneamente. Por defecto, se configura en 4 (o 1, dependiendo de la disponibilidad de memoria), pero se puede ajustar.

• Batching (Lote): Cuando llegan simultáneamente múltiples solicitudes para el mismo modelo, Ollama las agrupa en un lote y las procesa juntas. Esto significa que ambas solicitudes se manejan en paralelo y los usuarios verán las respuestas fluir de vuelta al mismo tiempo. El servidor no espera deliberadamente para llenar un lote; el procesamiento comienza en cuanto las solicitudes están disponibles.

Colas y límites

• Colas: Si el número de solicitudes simultáneas supera la paralelización configurada (p. ej., más de OLLAMA_NUM_PARALLEL solicitudes para un modelo), las solicitudes adicionales se colocan en cola. La cola opera de manera primero en llegar, primero en salir (FIFO).

• Límites de la cola: El número máximo de solicitudes en cola está controlado por OLLAMA_MAX_QUEUE (predeterminado: 512). Si la cola está llena, las nuevas solicitudes reciben un error 503 que indica que el servidor está sobrecargado.

• Carga de modelos: El número de diferentes modelos que se pueden cargar al mismo tiempo está controlado por OLLAMA_MAX_LOADED_MODELS. Si una solicitud requiere cargar un nuevo modelo y la memoria es insuficiente, Ollama descargará los modelos inactivos para hacer espacio, y la solicitud se colocará en cola hasta que el modelo se cargue.

Escenario de ejemplo

Si dos solicitudes para el mismo modelo llegan al mismo tiempo y la paralelización del servidor está configurada en al menos 2, ambas solicitudes se procesarán juntas en un lote y ambos usuarios recibirán respuestas de forma concurrente. Si la paralelización está configurada en 1, una solicitud se procesa de inmediato y la otra se coloca en cola hasta que la primera termine.

Si las solicitudes son para diferentes modelos y hay suficiente memoria, se pueden cargar ambos modelos y las solicitudes se manejan en paralelo. Si no es así, puede ser necesario descargar un modelo y la solicitud se colocará en cola.

Tabla resumen

En resumen, Ollama está diseñado para manejar múltiples solicitudes simultáneas de forma eficiente, siempre que el servidor esté configurado para la concurrencia y tenga recursos suficientes. De lo contrario, las solicitudes se colocan en cola y se procesan en orden.

Si aumentar OLLAMA_NUM_PARALLEL ya no mantiene estable la latencia y la cola sigue creciendo bajo tráfico real, esa es una de las señales más claras que conviene ponderar frente a un cambio a un motor de servicio construido a la medida. De Ollama a vLLM: Cuándo migrar tu servidor LLM local analiza esa decisión, incluyendo el batch continuo y PagedAttention como los mecanismos que vLLM utiliza para evitar que las solicitudes concurrentes se degraden entre sí.

Manejo de insuficiencia de memoria

Cuando Ollama se encuentra con memoria insuficiente para manejar las solicitudes entrantes, emplea una combinación de mecanismos de colas y estrategias de gestión de recursos para mantener la estabilidad:

Cola de solicitudes

• Las nuevas solicitudes se colocan en una cola FIFO (primero en llegar, primero en salir) cuando la memoria no se puede asignar de inmediato.
• El tamaño de la cola está controlado por OLLAMA_MAX_QUEUE (predeterminado: 512 solicitudes).
• Si la cola alcanza su capacidad, las nuevas solicitudes reciben errores 503 “Server Overloaded” (Servidor sobrecargado).

Gestión de modelos

• Los modelos activos pueden descargarse de la memoria cuando se vuelven inactivos para liberar recursos para las solicitudes en cola.
• El número de modelos cargados simultáneamente está limitado por OLLAMA_MAX_LOADED_MODELS (predeterminado: 3 × número de GPUs o 3 para CPU).

Optimización de memoria

• Intenta procesar por lotes las solicitudes para el mismo modelo para maximizar la eficiencia de memoria.
• Para la inferencia por GPU, requiere la asignación completa de VRAM por modelo; no se admiten cargas parciales.

Escenarios de falla

Agotamiento crítico de memoria: Cuando incluso las solicitudes en cola superan los recursos disponibles, Ollama puede:

• Realizar paginación a disco (degradando gravemente el rendimiento)
• Devolver errores “out of memory” (sin memoria)
• Provocar el fallo de la instancia del modelo en casos extremos

Los administradores deben monitorear el uso de memoria y ajustar estos parámetros según las capacidades de su hardware. El manejo de memoria insuficiente se vuelve crucial al ejecutar modelos más grandes (7B+ parámetros) o al procesar múltiples solicitudes simultáneas.

Estrategias de optimización de Ollama

Habilita la aceleración por GPU con export OLLAMA_CUDA=1 y configura los hilos de CPU con export OLLAMA_NUM_THREADS=84. Mejoras de hardware

• RAM: 32GB+ para modelos de 13B, 64GB+ para modelos de 70B
• Almacenamiento: SSD NVMe para una carga/intercambio de modelos más rápida
• GPU: NVIDIA RTX 3080/4090 con 16GB+ de VRAM para modelos más grandes

Estrategias operativas

• Lotes de solicitudes: Procesa varias consultas simultáneamente para amortizar la sobrecarga de memoria
• Descarga automática de modelos: Permite a Ollama purgar los modelos inactivos de la memoria
• Caché de modelos frecuentemente usados: Mantién los modelos comunes residentes en memoria

Monitoreo y solución de problemas

• Usa nvidia-smi (GPU) y htop (CPU/RAM) para identificar cuellos de botella
• Para errores de memoria:
• Actualiza a modelos cuantizados
• Reduce las solicitudes simultáneas
• Aumenta el espacio de swap (intercambio)

Ejemplo de flujo de trabajo de optimización:

### Usa un modelo cuantizado con aceleración por GPU
export OLLAMA_CUDA=1
ollama run llama2:7b-q4_0 --context-size 2048

### Limita los modelos cargados y las solicitudes paralelas
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4

Estos ajustes pueden reducir el uso de memoria entre un 30-60% manteniendo la calidad de la respuesta, lo cual es particularmente beneficioso al ejecutar múltiples modelos o manejar altos volúmenes de solicitudes.

Variable de entorno OLLAMA_NUM_PARALLEL

OLLAMA_NUM_PARALLEL controla cuántas solicitudes Ollama ejecutará en paralelo. Si envías múltiples solicitudes al mismo servidor de Ollama, esta configuración decide en gran medida si se ejecutan de forma concurrente o si quedan en cola.

• Los valores más altos pueden aumentar el rendimiento de procesamiento si tienes suficiente CPU/GPU/VRAM, pero pueden aumentar la latencia y la presión sobre la memoria.
• Los valores más bajos reducen la contención y pueden mejorar la estabilidad, pero las solicitudes se pondrán en cola con más frecuencia.

La memoria, específicamente, escala con OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH: cuatro ranuras paralelas con una configuración de contexto de 32K reservan la caché KV como si se hubiera cargado una única secuencia de 128K, incluso antes de que alguna solicitud la utilice. En una tarjeta de 16 GB, ese cálculo de presupuesto suele importar más que el comportamiento de colas; consulta Caché KV en GPUs de 16 GB para el presupuesto completo de VRAM y por qué OLLAMA_NUM_PARALLEL=1 suele ser el punto de partida correcto para una única sesión de contexto largo.

Cómo configurar OLLAMA_NUM_PARALLEL

Linux / macOS (servicio systemd o shell):

export OLLAMA_NUM_PARALLEL=2
ollama serve

Ejecución única (prefijo solo para este comando):

OLLAMA_NUM_PARALLEL=2 ollama serve

Docker (ejemplo):

docker run --rm -e OLLAMA_NUM_PARALLEL=2 -p 11434:11434 ollama/ollama

Cómo elegir un valor

Comienza con 1-2 para una GPU única / VRAM limitada y luego aumenta gradualmente mientras observas:

• Uso de VRAM de la GPU (OOM / expulsiones)
• Uso de CPU y carga promedio
• Latencia p95 de tus solicitudes típicas
• Tasa de errores / timeouts

Si estás optimizando una página específica para el uso de CLI, consulta la sección CLI de Ollama en la hoja de referencia, además de ejemplos de comandos para ollama serve, ollama ps y ollama run.

Recetas rápidas de ajuste

Prioridad en estabilidad

• OLLAMA_NUM_PARALLEL=1
• Usa modelos más pequeños / cuantizados
• Prefiere tamaños de contexto más cortos

Prioridad en rendimiento de procesamiento

• OLLAMA_NUM_PARALLEL=2 (o más alto si tienes margen)
• Considera el agrupamiento de solicitudes (batching) en la capa del cliente
• Asegura suficiente VRAM e hilos de CPU

“Me quedo sin VRAM cuando llegan dos solicitudes”

• Reduce OLLAMA_NUM_PARALLEL
• Usa un modelo cuantizado de forma más agresiva
• Reduce la longitud del contexto / tokens máximos

Solución de problemas

Síntomas de que OLLAMA_NUM_PARALLEL es demasiado alto

• Las solicitudes fallan intermitentemente bajo carga
• OOM de GPU / descarga de modelos ocurre con frecuencia
• Picos de latencia cuando llega la segunda solicitud

Síntomas de que OLLAMA_NUM_PARALLEL es demasiado bajo

• CPU/GPU está infrautilizado
• Los retrasos por colas dominan el tiempo total de respuesta

Consejo: Si también controlas tu cliente, agrega reintentos con variación aleatoria (jitter) y conexiones keep-alive. Muchos problemas de “Ollama es lento” son en realidad colas + sobrecarga de conexión.

Ollama: Agrupamiento de solicitudes vs Ejecución paralela

El agrupamiento (Batching) en Ollama se refiere a la práctica de agrupar varias solicitudes entrantes juntas y procesarlas como una unidad. Esto permite un uso más eficiente de los recursos de cómputo, especialmente cuando se ejecuta en hardware que se beneficia de operaciones paralelizadas (como las GPU).

Cuando llegan simultáneamente múltiples solicitudes para el mismo modelo, Ollama puede procesarlas juntas en un lote si la memoria lo permite. Esto aumenta el rendimiento de procesamiento y puede reducir la latencia para cada solicitud, ya que el modelo puede aprovechar operaciones de matriz optimizadas sobre el lote.

El agrupamiento es particularmente efectivo cuando las solicitudes son similares en tamaño y complejidad, ya que esto permite una mejor utilización del hardware.

La ejecución paralela en Ollama significa manejar múltiples solicitudes al mismo tiempo, ya sea para el mismo modelo o para modelos diferentes, dependiendo de la memoria disponible y la configuración.

Ollama soporta dos niveles de paralelismo:

• Carga de múltiples modelos: Si hay suficiente memoria disponible, varios modelos pueden cargarse y servir solicitudes simultáneamente.
• Solicitudes paralelas por modelo: Cada modelo cargado puede procesar varias solicitudes en paralelo, controlado por la configuración OLLAMA_NUM_PARALLEL (el predeterminado es 1 o 4, dependiendo de la memoria).

Cuando las solicitudes superan el límite de paralelismo, se colocan en cola (FIFO) hasta OLLAMA_MAX_QUEUE.

Conclusión

Ollama aprovecha tanto el agrupamiento como la ejecución paralela para procesar múltiples solicitudes de forma eficiente. El agrupamiento agrupa solicitudes para un procesamiento simultáneo, mientras que la ejecución paralela permite que múltiples solicitudes (o modelos) se ejecuten de forma concurrente. Ambos métodos dependen de la memoria del sistema y son configurables para un rendimiento óptimo.

Para más benchmarks, ajustes de concurrencia y orientación sobre el rendimiento, consulta nuestro hub de Rendimiento de LLM: Benchmarks, cuellos de botella y optimización.

Enlaces útiles

• Hoja de referencia de comandos de Ollama
• Comparación de rendimiento de LLM - Ollama en GPU de 16GB VRAM
• Mover modelos de Ollama a un disco o carpeta diferente
• Cómo Ollama está usando los núcleos de rendimiento y eficiencia de CPU Intel
• De Ollama a vLLM: Cuándo migrar tu servidor LLM local