Cómo Ollama maneja las solicitudes en paralelo

Comprende la concurrencia y la cola de Ollama, y aprende a ajustar OLLAMA_NUM_PARALLEL para solicitudes paralelas estables.

Índice

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 otros parámetros relacionados).

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

Para más información sobre el rendimiento, la latencia, la VRAM y las pruebas comparativas entre diferentes entornos de ejecución y hardware, consulte Rendimiento de LLM: Pruebas comparativas, cuellos de botella y optimización.

Los agentes multietapa multiplican los reintentos cuando el muestreo es inestable; para configuraciones predeterminadas de temperatura, top_p y penalizaciones en modelos de la clase Qwen y Gemma, consulte Parámetros de inferencia agéntica para Qwen y Gemma.

five awesome llamas are standing in the field

Manejo de solicitudes concurrentes

  • 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, este valor es 4 (o 1, dependiendo de la disponibilidad de memoria), pero se puede ajustar.

  • Agrupación (Batching): Cuando varias solicitudes para el mismo modelo llegan simultáneamente, Ollama las agrupa y las procesa juntas. Esto significa que ambas solicitudes se manejan en paralelo, y los usuarios verán las respuestas transmitiéndose al mismo tiempo. El servidor no espera intencionadamente a llenar un lote; el procesamiento comienza tan pronto como hay solicitudes disponibles.

Colas y límites

  • Colas: Si el número de solicitudes concurrentes excede la paralelización configurada (por ejemplo, más de OLLAMA_NUM_PARALLEL solicitudes para un modelo), las solicitudes adicionales se colocan en cola. La cola opera en un modo primero en entrar, 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 indicando que el servidor está sobrecargado.

  • Carga de modelos: El número de modelos diferentes 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 quedará 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 manera concurrente. Si la paralelización está configurada en 1, una solicitud se procesa inmediatamente y la otra se queda en cola hasta que la primera termine.

Si las solicitudes son para modelos diferentes y hay suficiente memoria, se pueden cargar ambos modelos y las solicitudes se manejarán en paralelo. Si no, puede ser necesario descargar un modelo y la solicitud se quedará en cola.

Tabla resumen

Escenario Resultado
Dos solicitudes, mismo modelo, paralelización suficiente Ambas procesadas juntas en paralelo (agrupadas)
Dos solicitudes, mismo modelo, paralelización=1 Una procesada, la segunda en cola hasta que la primera se complete
Dos solicitudes, modelos diferentes, memoria suficiente Ambos modelos cargados, solicitudes manejadas en paralelo
Dos solicitudes, modelos diferentes, memoria insuficiente Una en cola hasta que haya memoria disponible o se descargue un modelo

En resumen, Ollama está diseñado para manejar múltiples solicitudes simultáneas de manera 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.

Manejo de memoria insuficiente

Cuando Ollama se enfrenta a una memoria insuficiente para manejar las solicitudes entrantes, emplea una combinación de mecanismos de cola 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 entrar, primero en salir) cuando no se puede asignar memoria inmediatamente.
  • 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 “Servidor Sobrecargado”.

Gestión de modelos

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

Optimización de memoria

  • Intenta procesar en lotes las solicitudes para el mismo modelo para maximizar la eficiencia de la memoria.
  • Para la inferencia por GPU, requiere 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 exceden los recursos disponibles, Ollama puede:

  • Usar memoria virtual en disco (degradando severamente el rendimiento)
  • Devolver errores “sin memoria”
  • Causar el fallo de la instancia del modelo en casos extremos
Configuración Propósito Valor predeterminado
OLLAMA_MAX_QUEUE Solicitudes en cola máximas 512
OLLAMA_NUM_PARALLEL Solicitudes paralelas por modelo cargado 4 (o 1 si está limitado)
OLLAMA_MAX_LOADED_MODELS Modelos cargados concurrentemente máximos 3× cantidad de GPU o 3

Los administradores deben monitorear el uso de la 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 concurrentes.

Estrategias de optimización de Ollama

Habilite la aceleración por GPU con export OLLAMA_CUDA=1 y establezca 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 carga/intercambio de modelos más rápido
  • GPU: NVIDIA RTX 3080/4090 con 16GB+ de VRAM para modelos más grandes

Estrategias operativas

  • Agrupación de solicitudes: Procese múltiples consultas simultáneamente para amortizar el sobrecosto de memoria
  • Descarga automática de modelos: Permite a Ollama purgar modelos inactivos de la memoria
  • Caché de modelos usados frecuentemente: Mantenga modelos comunes residentes en la 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 intercambio (swap)

Ejemplo de flujo de trabajo de optimización:

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

### Limite modelos cargados y 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% mientras mantienen 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 ejecutará Ollama en paralelo. Si envía múltiples solicitudes al mismo servidor de Ollama, esta configuración decide en gran medida si se ejecutan de manera concurrente o se colocan 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 sobre la memoria.
  • Los valores más bajos reducen la contención y pueden mejorar la estabilidad, pero las solicitudes se colocarán en cola con más frecuencia.

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 sola GPU / VRAM limitada, luego aumente gradualmente mientras observa:

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

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

Recetas de ajuste rápido

Prioridad a la estabilidad

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

Prioridad al rendimiento (throughput)

  • OLLAMA_NUM_PARALLEL=2 (o más alto si tiene margen)
  • Considere la agrupación de solicitudes en la capa del cliente
  • Asegúrese de tener VRAM e hilos de CPU suficientes

“Se me acaba la VRAM cuando llegan dos solicitudes”

  • Reduzca OLLAMA_NUM_PARALLEL
  • Use un modelo más agresivamente cuantizado
  • 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
  • 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

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

Consejo: Si también controla su cliente, agregue reintentos con jitter (variación aleatoria) y mantenga conexiones activas (keep-alive). Muchos problemas de “Ollama es lento” en realidad son sobrecarga de cola + conexión.

Ollama: Agrupación de solicitudes vs Ejecución paralela

La agrupación (batching) en Ollama se refiere a la práctica de agrupar múltiples solicitudes entrantes y procesarlas como una unidad. Esto permite un uso más eficiente de los recursos computacionales, especialmente cuando se ejecuta en hardware que se beneficia de operaciones paralelizadas (como las GPUs).

Cuando múltiples 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 matrices optimizadas sobre el lote.

La agrupación es particularmente efectiva 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 admite dos niveles de paralelismo:

  • Carga de múltiples modelos: Si hay suficiente memoria disponible, varios modelos pueden ser cargados 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 exceden el límite de paralelismo, se colocan en cola (FIFO) hasta OLLAMA_MAX_QUEUE.

Conclusión

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

Para más pruebas comparativas, ajuste de concurrencia y orientación de rendimiento, consulte nuestro Rendimiento de LLM: Pruebas comparativas, cuellos de botella y optimización hub.

Enlaces útiles

Suscribirse

Recibe nuevas publicaciones sobre sistemas, infraestructura e ingeniería de IA.