Ollama: NUM_PARALLEL y MAX_QUEUE, diferencias y VRAM

Qué ocurre con la segunda solicitud de Ollama mientras se genera la primera

La concurrencia de Ollama se controla mediante tres variables de entorno. De forma predeterminada, un modelo cargado atiende una solicitud cada vez. La segunda solicitud no se rechaza ni recibe una respuesta parcial. Espera en una cola hasta que haya un espacio disponible y después se ejecuta a velocidad normal.

Una solicitud entrante puede tener tres resultados. Puede iniciarse de inmediato en un espacio libre. Puede esperar en la cola. O la cola puede estar llena y el servidor puede rechazarla con HTTP 503. El resultado depende de OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE y OLLAMA_MAX_LOADED_MODELS.

La configuración predeterminada es segura. También explica por qué un segundo usuario informa de que el servidor se ha «bloqueado» cuando no hay ningún fallo. Añadir espacios requiere cambiar dos líneas. El problema está en la memoria. Cada espacio paralelo necesita su propia caché de clave/valor (caché KV), que es el bloque de memoria donde el modelo conserva los tokens que ya ha procesado. Si añade espacios sin aumentar la VRAM (memoria de vídeo de la GPU), una respuesta lenta se convierte en un error de carga.

Qué controla cada variable OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE y OLLAMA_MAX_LOADED_MODELS

Estos son los valores predeterminados de las versiones actuales de Ollama a fecha de agosto de 2026. Compruebe los valores de su instalación en lugar de confiar en estas cifras. Use la línea del registro que se muestra más abajo.

• OLLAMA_NUM_PARALLEL indica cuántas solicitudes puede procesar simultáneamente un modelo cargado. El valor predeterminado es 1, por lo que las solicitudes se procesan una tras otra.
• OLLAMA_MAX_LOADED_MODELS indica cuántos modelos diferentes permanecen cargados al mismo tiempo. El valor predeterminado es 0. Esto significa que Ollama elige tres modelos por GPU y tres modelos en una máquina sin GPU.
• OLLAMA_MAX_QUEUE indica cuántas solicitudes pueden permanecer en espera. El valor predeterminado es 512. La solicitud que llega cuando la cola está llena se rechaza inmediatamente.

La memoria máxima necesaria es el producto de los dos primeros valores. Dos modelos cargados con cuatro posiciones cada uno requieren ocho asignaciones de posiciones de caché KV, todas residentes al mismo tiempo, y Ollama intentará satisfacer esa demanda. En un equipo con una sola GPU, normalmente es mejor mantener un modelo cargado y asignarle varias posiciones, porque el cálculo sigue siendo sencillo.

Por qué cada ranura paralela consume VRAM

Cuando Ollama carga un modelo, inicia un proceso runner independiente. Dos de los argumentos que le pasa son importantes aquí: -c es el contexto total para el que el runner reserva una caché KV, y -np es el número de secuencias paralelas. Ollama establece -c en la longitud de contexto por solicitud multiplicada por el número de ranuras. Después, el runner divide ese total por igual entre las ranuras, por lo que cada solicitud sigue recibiendo la longitud de contexto solicitada.

Esa es toda la restricción y explica por qué el paralelismo no es gratuito. Pasar de una ranura a cuatro requiere cuatro veces más caché KV con la misma longitud de contexto por solicitud. Las ranuras no comparten nada, y la parte de una ranura inactiva no se presta a una ranura ocupada porque la división queda fijada cuando se inicia el runner.

Puede consultar los valores reales en lugar de los que pretendía establecer:

journalctl -u ollama --no-pager -n 500 | grep "starting llama-server"

Esa línea contiene la línea de comandos completa del runner, incluidos -c y -np. Si -np es 1 después de establecer la variable, la configuración no está llegando al servidor. La siguiente sección explica el motivo.

Si los pesos del modelo más esa caché KV no caben en la VRAM, Ollama mueve algunas capas a la RAM del sistema y esas capas se ejecutan en la CPU. Las capas de CPU son mucho más lentas que las de GPU, por lo que todas las solicitudes tardan más, incluida la única solicitud con la que empezó. Por tanto, aumentar el paralelismo puede reducir el rendimiento en lugar de aumentarlo. Con un modelo suficientemente grande, los pesos por sí solos determinan el resultado antes de realizar cualquier cálculo de ranuras. Por eso alojar por cuenta propia algo del tamaño de Kimi K3 es una cuestión de cuántas tarjetas tiene, no de cuántas ranuras establece.

ollama ps

La columna PROCESSOR muestra 100% GPU cuando todo cabe. Una división como 35%/65% CPU/GPU indica que parte del modelo se está ejecutando en la CPU. La columna SIZE incluye la caché KV, por lo que aumenta cuando incrementa el número de ranuras y vuelve a cargar el modelo. Aumente OLLAMA_NUM_PARALLEL, reinicie, envíe una solicitud y ejecute ollama ps de nuevo: ese es el coste de memoria de su cambio, medido en lugar de estimado. Si esa medición indica que el modelo ya no cabe, recuerde que los pesos son la otra mitad del mismo presupuesto. Pasar de una compilación fp16 a una q8 o q4 suele liberar más VRAM que la que consume la ranura adicional que intentaba añadir.

La longitud de contexto y el número de ranuras se multiplican, por lo que deben elegirse conjuntamente. Un contexto grande con cuatro ranuras equivale a cuatro contextos grandes. Si también está ajustando la ventana de contexto num_ctx de su modelo, cambie sólo uno de los dos valores cada vez. De lo contrario, no sabrá cuál llenó la tarjeta.

Cómo configurar estas variables para que sobrevivan a un reinicio

En Linux, Ollama se ejecuta como un servicio de systemd. Ejecutar export OLLAMA_NUM_PARALLEL=4 en el shell no cambia nada, porque systemd inicia el servicio con su propio entorno y nunca ve el shell. Use un archivo drop-in.

sudo systemctl edit ollama.service

Añada esto en el editor que se abre:

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_MAX_QUEUE=32"

Después, recargue y reinicie:

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

systemctl show muestra lo que systemd entregará al proceso. Si la variable falta ahí, el drop-in no se guardó o se omitió daemon-reload. Confírmelo también desde el propio servidor:

journalctl -u ollama --no-pager | grep "server config" | tail -1

Ollama registra todo su entorno durante el arranque en una línea cuyo mensaje es server config. Ese mapa es la referencia definitiva. Es la forma más rápida de resolver cualquier duda sobre si una variable se aplicó.

Un modelo que ya está cargado conserva el número de slots con el que se inició, porque el valor queda fijado en el proceso runner durante el arranque. El reinicio anterior descarga todo, por lo que la siguiente solicitud vuelve a cargar el modelo con la nueva configuración y el tiempo de carga se paga una sola vez. Cuánto tiempo permanece cargado el modelo después es un control independiente, explicado en mantener un modelo de Ollama cargado entre solicitudes.

Aspecto de las solicitudes atendidas, en cola y rechazadas desde el cliente

Envíe varias solicitudes a la vez y mida sus tiempos. Esto ejecuta ocho solicitudes de streaming en paralelo e imprime el estado y los tiempos de cada una:

for i in $(seq 1 8); do
  curl -s -o /dev/null \
    -w "req$i http=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
    http://127.0.0.1:11434/api/generate \
    -d '{"model":"llama3.2:3b","prompt":"Explain what a KV cache is.","stream":true}' &
done
wait

ttfb es el tiempo hasta el primer byte del stream. Es similar al tiempo hasta el primer token (TTFT), porque el primer fragmento enviado contiene el primer token.

Atendidas en paralelo. Todas las solicitudes muestran un valor similar de ttfb y total aumenta al mismo tiempo para todas. La GPU se comparte entre los slots en ejecución. Por eso cada respuesta es más lenta que si se ejecutara sola, aunque se completan más respuestas por minuto. Este es el régimen que obtiene al aumentar OLLAMA_NUM_PARALLEL.

En cola. Las primeras solicitudes responden rápido y las posteriores muestran un valor elevado de ttfb, seguido de una generación normal. La espera corresponde a la cola, no al modelo. Un usuario que observa una ventana de chat ve una pausa larga sin contenido y después texto a velocidad normal. Este patrón, lento al principio y rápido después, indica una cola y no una GPU sobrecargada.

Rechazadas. El cliente recibe http=503 casi de inmediato, y el cuerpo es:

{"error":"server busy, please try again.  maximum pending requests exceeded"}

Este mensaje significa que la cola estaba llena cuando llegó la solicitud. No proporciona información sobre la VRAM ni sobre el modelo.

Hay una limitación importante: Ollama no publica la profundidad de la cola. Los endpoints ollama ps y /api/ps informan de los modelos cargados, no de las solicitudes en espera. Por tanto, debe medir la cola desde el cliente, observando el tiempo hasta el primer byte, o contar las respuestas 503 en el componente que esté delante.

Por qué un MAX_QUEUE más pequeño suele ser la mejor configuración

Una cola de 512 parece amplia, pero con un solo slot resulta casi inútil. La solicitud 300 espera detrás de 299 generaciones completas. Eso tarda varios minutos como mínimo. Todos los clientes HTTP abandonan mucho antes, por lo que el cliente recibe un tiempo de espera agotado. Ese resultado no informa de la causa y no proporciona a la monitorización nada que pueda activar una alerta.

Configure la cola con un tamaño aproximado a lo que el servidor pueda procesar dentro del tiempo de espera del cliente. Así, el exceso se convierte inmediatamente en un 503. Un 503 es útil: un reverse proxy puede reintentarlo, un cliente puede aplicar backoff, un dashboard puede contabilizarlo y una persona puede leerlo. Calcule el valor a partir de sus propias mediciones. Si una generación tarda unos diez segundos y el cliente espera sesenta, cada slot puede procesar aproximadamente seis solicitudes dentro de ese intervalo. Una cola mucho más profunda sólo produce tiempos de espera agotados.

Cuándo poner una cola delante de Ollama

La cola integrada funciona en orden de llegada (FIFO) y no sabe quién realiza cada llamada. Para una aplicación que se comunica con un solo servidor, esto es suficiente, y añadir infraestructura sólo introduciría más puntos de fallo. Necesita algo delante de Ollama cuando se cumpla una de estas condiciones.

• Necesita prioridad. Un chat interactivo no debería esperar detrás de un trabajo de resumen por lotes. La cola de Ollama no tiene prioridades, por lo que el trabajo por lotes debe mantenerse fuera de ella y enviarse de forma gradual.
• Necesita equidad. Un cliente puede llenar la cola por sí solo y hacer que todos los demás reciban 503.
• Necesita que el trabajo sobreviva a un reinicio. La cola reside en la memoria del servidor. Si reinicia Ollama, todas las solicitudes en espera se pierden.
• Necesita reintentos reales con retroceso, registrados en un lugar que pueda consultar después.

La opción sencilla es un reverse proxy. En nginx, limit_conn limita las conexiones simultáneas y limit_req limita la tasa de llegada por cliente, de modo que el exceso se rechaza en el proxy y nunca llega a la cola de Ollama. La opción completa es una cola de trabajos con una base de datos delante de un worker que llama a Ollama. Esto es lo adecuado cuando las solicitudes deben sobrevivir al reinicio de un proceso. Dimensionar esta arquitectura para tráfico real requiere un análisis específico: planificar un LLM autoalojado para usuarios simultáneos explica los cálculos, y ejecutar Ollama en un VPS cubre la instalación base que dan por supuestas estas variables.

Cuando la respuesta correcta es usar otro servidor

Hay un límite que no se puede superar ajustando parámetros. Ollama divide la caché KV en ranuras iguales y fijas cuando carga el modelo. La memoria de una ranura inactiva no puede utilizarla una ranura ocupada, y el número de ranuras no puede cambiar sin descargar el modelo. Este diseño es adecuado para una persona, un equipo pequeño o un agente de programación.

Los servidores diseñados para muchos usuarios simultáneos funcionan de otra manera. Asignan la caché KV en páginas pequeñas según la demanda y añaden las solicitudes nuevas a un lote que ya está en ejecución. Así, la memoria sigue la demanda real en lugar de una división fija. Si el objetivo es atender a muchos usuarios simultáneos en una sola GPU, esta diferencia arquitectónica es más importante que cualquier valor de OLLAMA_NUM_PARALLEL. La comparación entre Ollama y vLLM permite tomar esa decisión. No cambie de servidor por principio. Otro servidor requiere más operación, y si el tráfico procede de unas pocas personas, el comportamiento integrado es la opción correcta.

Mida su propio rendimiento y el tiempo hasta el primer token

Las cifras publicadas de tokens por segundo proceden de otra GPU, otro modelo, otra cuantización, otra longitud de contexto y otro prompt. Ninguno de esos factores coincide necesariamente con los suyos. Considere cualquier cifra que lea como una referencia aproximada y mida el equipo que tiene delante.

Ollama devuelve los tiempos en el objeto JSON final de cada respuesta. eval_count es el número de tokens generados y eval_duration es el tiempo empleado en generarlos, expresado en nanosegundos.

sudo apt install -y jq
curl -s http://127.0.0.1:11434/api/generate \
  -d '{"model":"llama3.2:3b","prompt":"Explain what a KV cache is.","stream":false}' \
  | jq '{prompt_eval_count, eval_count, eval_duration, tokens_per_second: (.eval_count / (.eval_duration / 1000000000))}'

Ejecute esto con un slot y repítalo con la concurrencia que espera utilizar realmente. Compare las dos cifras que determinan si los usuarios estarán satisfechos: el tiempo hasta el primer token y los tokens por segundo por solicitud. El rendimiento por solicitud siempre disminuye al añadir slots. La cuestión es si disminuye más de lo que sus usuarios aceptarán. Medición de tokens por segundo en un LLM local explica el método con más detalle, incluido cómo mantener constante el prompt entre ejecuciones.

Un endpoint público con una cola amplia es un objetivo de denegación de servicio

Configurar OLLAMA_HOST=0.0.0.0:11434 hace que la API escuche en todas las interfaces, y Ollama no tiene autenticación integrada. Un endpoint abierto con la cola predeterminada aceptará 512 solicitudes en espera de cualquiera que lo encuentre. Llenar esa cola cuesta casi nada al atacante: prompts largos, sin inicio de sesión, sin límite de tasa y sin coste. Sus propios usuarios recibirán respuestas 503 o tendrán que esperar mucho tiempo, mientras la máquina permanece ocupada.

Mantenga el listener en loopback y acceda a él mediante un túnel SSH o una red privada, o coloque autenticación y límites de tasa delante del endpoint. Protección de un endpoint de la API de Ollama cubre ambas opciones. Ajuste la cola después de hacerlo, porque la longitud de la cola es un parámetro de capacidad y no proporciona protección.

FAQ

¿Por qué mi segunda petición a Ollama espera a que termine la primera?

Porque OLLAMA_NUM_PARALLEL tiene el valor predeterminado 1. Por tanto, un modelo cargado procesa una petición cada vez y las demás esperan en orden. La petición en espera mantiene abierta la conexión HTTP y no envía bytes hasta que se libera un espacio. Desde el cliente, esto parece un modelo lento. La diferencia se observa en el patrón de los tiempos: una pausa larga seguida de texto a velocidad normal indica una cola, mientras que un flujo lento desde el primer token indica un modelo lento. Aumente el número de espacios mediante un drop-in de systemd y reinicie el servicio.

¿Qué significa "server busy, please try again. maximum pending requests exceeded"?

Es el error de desbordamiento de cola de Ollama, que se devuelve con el estado HTTP 503. El número de peticiones que ya estaban esperando alcanzó OLLAMA_MAX_QUEUE, cuyo valor predeterminado es 512. Por eso, la petición más reciente se rechazó en lugar de añadirse a la cola. No es un error de memoria ni un error del modelo. Aumentar la cola sólo hace que los clientes esperen más tiempo antes de recibir el mismo rechazo. Las soluciones reales son usar más espacios si dispone de suficiente VRAM, reducir la carga entrante o colocar delante una cola que pueda reintentar y establecer prioridades.

¿Aumentar OLLAMA_NUM_PARALLEL hace que Ollama sea más rápido?

No. Permite procesar más peticiones al mismo tiempo, pero cada una tarda más que si se ejecutara sola porque todas comparten una GPU. También multiplica la caché KV, ya que Ollama inicia el runner con un contexto total igual a la longitud de contexto multiplicada por el número de espacios. Si el resultado ya no cabe en la VRAM, Ollama mueve capas a la CPU y todas las peticiones se ralentizan, incluida una petición única sin competencia. Compruebe ollama ps después del cambio y confirme que la columna PROCESSOR todavía muestra 100% GPU.

¿Tengo que reiniciar Ollama después de cambiar estas variables?

Sí. El servidor las lee durante el arranque y un modelo en ejecución conserva el número de espacios fijado en su proceso runner cuando se inició. Edite el drop-in con sudo systemctl edit ollama.service y ejecute sudo systemctl daemon-reload y sudo systemctl restart ollama. Confirme el cambio con systemctl show ollama --property=Environment. Después, compruebe la línea server config en journalctl -u ollama, que muestra el entorno cargado realmente por el servidor.

¿Cuántos espacios paralelos debo configurar?

Empiece con 1 y aumente el valor paso a paso. Después de cada cambio, reinicie Ollama, envíe una petición para cargar el modelo y ejecute ollama ps. Deténgase en el último valor en el que PROCESSOR siga mostrando 100% GPU y la columna SIZE conserve margen para el contexto más largo que ofrece. Después, mida el tiempo hasta el primer token y los tokens por segundo con ese valor y bajo la concurrencia real. Reduzca un paso si la velocidad por petición ha caído por debajo de lo que sus usuarios toleran.