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 ajustarlo utilizando la variable de entorno OLLAMA_NUM_PARALLEL (y ajustes relacionados).

Enlaces de salto: ¿Qué es OLLAMA_NUM_PARALLEL? · Recetas rápidas de ajuste · Cómo funciona la cola · Solución de problemas · Relacionado: Hoja de referencia de comandos CLI de Ollama

Para más información sobre el rendimiento, la latencia, la VRAM y las pruebas de referencia en distintos tiempos de ejecución y hardware, consulte Rendimiento de LLM: Pruebas de referencia, cuellos de botella y optimización.

Los agentes de varios pasos multiplican los reintentos cuando el muestreo no es estable; para la temperatura predeterminada, top_p y la elección de penalizaciones en modelos de la clase Qwen y Gemma, consulte parámetros de inferencia agéntica para Qwen y Gemma.

Manejo de solicitudes concurrentes

• Procesamiento paralelo: Ollama soporta el procesamiento concurrente de solicitudes. Si el sistema tiene suficiente memoria disponible (RAM para inferencia de CPU, VRAM para inferencia de 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, esto se establece en 4 (o 1, dependiendo de la disponibilidad de memoria), pero se puede ajustar.

• Lote (Batching): Cuando varias solicitudes para el mismo modelo llegan simultáneamente, Ollama las agrupa en un lote y las procesa juntas. Esto significa que ambas solicitudes se manejan en paralelo, y los usuarios verán que las respuestas fluyen de vuelta al mismo tiempo. El servidor no espera intencionalmente 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 concurrentes supera la paralelismo configurado (por ejemplo, más de OLLAMA_NUM_PARALLEL solicitudes para un modelo), las solicitudes adicionales se colocan en cola. La cola opera de manera primera entrada, primera salida (FIFO).

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

• Carga de modelos: El número de modelos diferentes que se pueden cargar al mismo tiempo se controla mediante 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 paralelismo del servidor está establecido en al menos 2, ambas solicitudes se procesarán juntas en un lote, y ambos usuarios recibirán respuestas de manera concurrente. Si la paralelismo está establecida en 1, una solicitud se procesa inmediatamente, y la otra se coloca en cola hasta que la primera termine.

Si las solicitudes son para modelos diferentes y hay suficiente memoria, ambos modelos se pueden cargar y las solicitudes se manejan en paralelo. Si no, un modelo podría necesitar ser descargado, y la solicitud se colocará en cola.

Tabla resumen

En resumen, Ollama está diseñado para manejar múltiples solicitudes simultáneas de manera eficiente, siempre que el servidor esté configurado para 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 la latencia estable y la cola sigue creciendo bajo tráfico real, esa es una de las señales más claras que vale la pena pesar frente a un cambio a un motor de servicio diseñado a medida. De Ollama a vLLM: Cuándo migrar su servidor de LLM local explica esa decisión, incluyendo el lote continuo (continuous batching) 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:

Colas de solicitudes

• Las nuevas solicitudes se colocan en una cola FIFO (Primera Entrada, Primera Salida) cuando la memoria no se puede asignar de inmediato.
• El tamaño de la cola se controla mediante OLLAMA_MAX_QUEUE (predeterminado: 512 solicitudes).
• Si la cola alcanza su capacidad, las nuevas solicitudes reciben errores 503 “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 GPU o 3 para CPU).

Optimización de memoria

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

Escenarios de fallo

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

• Paginar al disco (degradando gravemente el rendimiento)
• Devolver errores “out of memory”
• Hacer que el modelo se crashee en casos extremos

Los administradores deben monitorear el uso de memoria y ajustar estos parámetros basándose en las capacidades de su hardware. El manejo de la insuficiencia de memoria se vuelve crucial al ejecutar modelos más grandes (7B+ parámetros) o al procesar múltiples solicitudes concurrentes.

Estrategias de optimización de Ollama

Habilite la aceleración de GPU con export OLLAMA_CUDA=1 y establezca los hilos de CPU mediante export OLLAMA_NUM_THREADS=84. Mejoras de hardware

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

Estrategias operativas

• Solicitudes en lote (Batch Requests): Procesar múltiples consultas simultáneamente para amortizar el sobrecoste de memoria
• Descarga automática de modelos: Permite a Ollama purgar los modelos inactivos de la memoria
• Cache de modelos usados con frecuencia: Mantener los modelos comunes residentes en memoria

Monitoreo y solución de problemas

• Use nvidia-smi (GPU) y htop (CPU/RAM) para identificar cuellos de botella
• Para errores de memoria:
• Actualice a modelos cuantizados
• Reduzca las solicitudes concurrentes
• Aumente el espacio de swap

Flujo de trabajo de optimización de ejemplo:

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

### Limite 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 en un 30-60% manteniendo la calidad de la respuesta, lo cual es particularmente beneficioso al ejecutar múltiples modelos o manejar grandes volúmenes de solicitudes.

Variable de entorno OLLAMA_NUM_PARALLEL

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

• Los valores más altos pueden aumentar el rendimiento si tiene suficiente CPU/GPU/VRAM, pero pueden aumentar la latencia y la presión de 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 un contexto de 32K reservan caché KV como si se hubiera cargado una sola secuencia de 128K, incluso antes de que alguna solicitud lo use. En una tarjeta de 16 GB, ese cálculo de presupuesto generalmente importa más que el comportamiento de la cola — consulte 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 establecer 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

Comience con 1–2 para una GPU única / VRAM limitada, y luego aumente gradualmente mientras observa:

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

Si está optimizando una página específica para el uso de CLI, consulte 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
• Use modelos más pequeños / cuantizados
• Prefiera tamaños de contexto más cortos

Prioridad en rendimiento (throughput)

• OLLAMA_NUM_PARALLEL=2 (o más alto si tiene margen)
• Considere el lote de solicitudes (batching) en la capa del cliente
• Asegure VRAM e hilos de CPU suficientes

“Me quedo sin VRAM cuando llegan dos solicitudes”

• Reduzca OLLAMA_NUM_PARALLEL
• Use un modelo cuantizado de manera más agresiva
• Reduzca 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
• GPU OOM / descarga de modelos ocurre con frecuencia
• La latencia se dispara cuando llega la segunda solicitud

Síntomas de que OLLAMA_NUM_PARALLEL es demasiado bajo

• La CPU/GPU está subutilizada
• Los retrasos de cola dominan el tiempo total de respuesta

Consejo: Si también controla su cliente, agregue reintentos con jitter y conexiones de keep-alive. Muchos problemas de “Ollama es lento” son realmente cola + sobrecoste de conexión.

Ollama: Solicitudes en lote vs Ejecución paralela

El lote (batching) en Ollama se refiere a la práctica de agrupar varias solicitudes entrantes 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 GPUs).

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

El lote es particularmente efectivo cuando las solicitudes son similares en tamaño y complejidad, ya que esto permite un mejor aprovechamiento 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, se pueden cargar varios modelos 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 lote como la ejecución paralela para procesar múltiples solicitudes de manera eficiente. El lote agrupa las solicitudes para un procesamiento simultáneo, mientras que la ejecución paralela permite que múltiples solicitudes (o modelos) se ejecuten concurrentemente. Ambos métodos dependen de la memoria del sistema y se pueden configurar para un rendimiento óptimo.

Para más pruebas de referencia, ajuste de concurrencia y orientación de rendimiento, consulte nuestro hub de Rendimiento de LLM: Pruebas de referencia, 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 otra unidad o carpeta
• Cómo Ollama está usando los núcleos de rendimiento y eficientes de CPU Intel
• De Ollama a vLLM: Cuándo migrar su servidor de LLM local