Como o Ollama Lida com Solicitações Paralelas
Compreenda a concorrência e o enfileiramento do Ollama, e saiba como ajustar o OLLAMA_NUM_PARALLEL para solicitações paralelas estáveis.
Este guia explica como o Ollama lida com solicitações paralelas (concorrência, filas e limites de recursos) e como ajustá-lo usando a variável de ambiente OLLAMA_NUM_PARALLEL (e outros parâmetros relacionados).
Links rápidos: O que é OLLAMA_NUM_PARALLEL? · Receitas rápidas de ajuste · Como funciona a fila · Solução de problemas · Relacionado: Lista de comandos da CLI do Ollama
Para mais informações sobre throughput, latência, VRAM e benchmarks em diferentes runtimes e hardware, consulte Desempenho de LLM: Benchmarks, Gargalos & Otimização.
Agentes multi-step multiplicam as tentativas quando a amostragem é instável; para configurações padrão de temperatura, top_p e penalidades em modelos da classe Qwen e Gemma, consulte parâmetros de inferência agêntica para Qwen e Gemma.

Tratamento de Solicitações Concorrentes
-
Processamento Paralelo: O Ollama suporta o processamento concorrente de solicitações. Se o sistema tiver memória suficiente disponível (RAM para inferência por CPU, VRAM para inferência por GPU), vários modelos podem ser carregados simultaneamente, e cada modelo carregado pode lidar com várias solicitações em paralelo. Isso é controlado pela variável de ambiente
OLLAMA_NUM_PARALLEL, que define o número máximo de solicitações paralelas que cada modelo pode processar simultaneamente. Por padrão, isso é definido como 4 (ou 1, dependendo da disponibilidade de memória), mas pode ser ajustado. -
Agrupamento (Batching): Quando várias solicitações para o mesmo modelo chegam simultaneamente, o Ollama as agrupa (batch) e as processa juntas. Isso significa que ambas as solicitações são tratadas em paralelo, e os usuários verão as respostas sendo transmitidas (streaming) ao mesmo tempo. O servidor não espera intencionalmente para preencher um lote; o processamento começa assim que as solicitações estão disponíveis.
Filas e Limites
-
Filas: Se o número de solicitações concorrentes exceder o paralelismo configurado (por exemplo, mais de
OLLAMA_NUM_PARALLELsolicitações para um modelo), as solicitações adicionais são colocadas em fila. A fila opera em modo primeiro-a-entrar, primeiro-a-sair (FIFO). -
Limites da Fila: O número máximo de solicitações em fila é controlado por
OLLAMA_MAX_QUEUE(padrão: 512). Se a fila estiver cheia, novas solicitações recebem um erro 503 indicando que o servidor está sobrecarregado. -
Carregamento de Modelos: O número de modelos diferentes que podem ser carregados ao mesmo tempo é controlado por
OLLAMA_MAX_LOADED_MODELS. Se uma solicitação exigir o carregamento de um novo modelo e a memória for insuficiente, o Ollama descarregará modelos ociosos para abrir espaço, e a solicitação ficará em fila até que o modelo seja carregado.
Cenário de Exemplo
Se duas solicitações para o mesmo modelo chegarem ao mesmo tempo e o paralelismo do servidor estiver definido para pelo menos 2, ambas as solicitações serão processadas juntas em um lote, e ambos os usuários receberão respostas simultaneamente. Se o paralelismo estiver definido como 1, uma solicitação é processada imediatamente, e a outra fica em fila até que a primeira termine.
Se as solicitações forem para modelos diferentes e houver memória suficiente, ambos os modelos podem ser carregados e as solicitações tratadas em paralelo. Caso contrário, um modelo pode precisar ser descarregado, e a solicitação ficará em fila.
Tabela Resumo
| Cenário | Resultado |
|---|---|
| Duas solicitações, mesmo modelo, paralelismo suficiente | Ambas processadas em paralelo (agrupadas) |
| Duas solicitações, mesmo modelo, paralelismo=1 | Uma processada, segunda em fila até a conclusão da primeira |
| Duas solicitações, modelos diferentes, memória suficiente | Ambos os modelos carregados, solicitações tratadas em paralelo |
| Duas solicitações, modelos diferentes, memória insuficiente | Uma em fila até que memória esteja disponível ou um modelo seja descarregado |
Em resumo, o Ollama foi projetado para lidar com múltiplas solicitações simultâneas de forma eficiente, desde que o servidor esteja configurado para concorrência e possua recursos suficientes. Caso contrário, as solicitações são colocadas em fila e processadas em ordem.
Se aumentar OLLAMA_NUM_PARALLEL não mantém mais a latência estável e a fila continua crescendo sob tráfego real, esse é um dos sinais mais claros a serem ponderados antes de migrar para um mecanismo de serving projetado para isso. Ollama para vLLM: Quando Migrar Seu Servidor Local de LLM detalha essa decisão, incluindo o agrupamento contínuo e o PagedAttention como mecanismos que o vLLM usa para evitar que solicitações concorrentes degradem umas às outras.
Tratamento de Memória Insuficiente
Quando o Ollama encontra memória insuficiente para lidar com solicitações entrantes, ele emprega uma combinação de mecanismos de fila e estratégias de gerenciamento de recursos para manter a estabilidade:
Enfileiramento de Solicitações
- Novas solicitações são colocadas em uma fila FIFO (First-In, First-Out) quando a memória não pode ser alocada imediatamente.
- O tamanho da fila é controlado por OLLAMA_MAX_QUEUE (padrão: 512 solicitações).
- Se a fila atingir a capacidade, novas solicitações recebem erros 503 “Servidor Sobrecarregado”.
Gerenciamento de Modelos
- Modelos ativos podem ser descarregados da memória quando ficam ociosos para liberar recursos para solicitações em fila.
- O número de modelos carregados simultaneamente é limitado por OLLAMA_MAX_LOADED_MODELS (padrão: 3× quantidade de GPUs ou 3 para CPU).
Otimização de Memória
- Tenta agrupar (batch) solicitações para o mesmo modelo para maximizar a eficiência de memória.
- Para inferência em GPU, requer alocação completa de VRAM por modelo - cargas parciais não são suportadas.
Cenários de Falha
Esgotamento Crítico de Memória: Quando até mesmo as solicitações em fila excedem os recursos disponíveis, o Ollama pode:
- Fazer paging para o disco (degradando severamente o desempenho)
- Retornar erros “sem memória” (out of memory)
- Travar a instância do modelo em casos extremos
| Controle de Configuração | Propósito | Valor Padrão |
|---|---|---|
| OLLAMA_MAX_QUEUE | Solicitações máximas em fila | 512 |
| OLLAMA_NUM_PARALLEL | Solicitações paralelas por modelo carregado | 4 (ou 1 se limitado) |
| OLLAMA_MAX_LOADED_MODELS | Maximum concurrently loaded models | 3× quantidade de GPUs ou 3 |
Administradores devem monitorar o uso de memória e ajustar esses parâmetros com base nas capacidades do seu hardware. O tratamento de memória insuficiente torna-se crucial ao executar modelos maiores (7B+ parâmetros) ou processar múltiplas solicitações concorrentes.
Estratégias de otimização do Ollama
Ative a aceleração por GPU com export OLLAMA_CUDA=1 e defina os threads da CPU via export OLLAMA_NUM_THREADS=84.
Melhorias de Hardware
- RAM: 32GB+ para modelos 13B, 64GB+ para modelos 70B
- Armazenamento: NVMe SSDs para carregamento/swap de modelos mais rápido
- GPU: NVIDIA RTX 3080/4090 com 16GB+ de VRAM para modelos maiores
Estratégias Operacionais
- Agrupar Solicitações (Batching): Processar múltiplas consultas simultaneamente para amortizar a sobrecarga de memória
- Descarregamento Automático de Modelos: Permite que o Ollama limpe modelos ociosos da memória
- Cache de Modelos Frequentes: Manter modelos comuns residentes na memória
Monitoramento e Solução de Problemas
- Use
nvidia-smi(GPU) ehtop(CPU/RAM) para identificar gargalos - Para erros de memória:
- Atualize para modelos quantizados
- Reduza solicitações concorrentes
- Aumente o espaço de swap
Exemplo de fluxo de trabalho de otimização:
### Use modelo quantizado com aceleração por GPU
export OLLAMA_CUDA=1
ollama run llama2:7b-q4_0 --context-size 2048
### Limite modelos carregados e solicitações paralelas
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4
Esses ajustes podem reduzir o uso de memória em 30-60% enquanto mantêm a qualidade da resposta, particularmente benéfico ao executar múltiplos modelos ou lidar com alto volume de solicitações.
Variável de ambiente OLLAMA_NUM_PARALLEL
OLLAMA_NUM_PARALLEL controla quantas solicitações o Ollama executará em paralelo. Se você enviar múltiplas solicitações para o mesmo servidor Ollama, esta configuração decide em grande parte se elas serão executadas simultaneamente ou ficarão em fila.
- Valores maiores podem aumentar o throughput se você tiver CPU/GPU/VRAM suficientes, mas podem aumentar a latência e a pressão sobre a memória.
- Valores menores reduzem a contenda e podem melhorar a estabilidade, mas as solicitações ficarão em fila com mais frequência.
Como definir OLLAMA_NUM_PARALLEL
Linux / macOS (serviço systemd ou shell):
export OLLAMA_NUM_PARALLEL=2
ollama serve
Execução única (prefixo apenas para este comando):
OLLAMA_NUM_PARALLEL=2 ollama serve
Docker (exemplo):
docker run --rm -e OLLAMA_NUM_PARALLEL=2 -p 11434:11434 ollama/ollama
Como escolher um valor
Comece com 1–2 para uma única GPU / VRAM limitada, e aumente gradualmente enquanto monitora:
- Uso de VRAM da GPU (OOM / evictions)
- Uso de CPU e média de carga (load average)
- Latência p95 das suas solicitações típicas
- Taxa de erro / timeouts
Se você estiver otimizando uma página específica para uso de CLI, consulte a seção CLI do Ollama na lista de comandos, além de exemplos de comandos para
ollama serve,ollama ps, eollama run.
Receitas rápidas de ajuste
Foco em Estabilidade
OLLAMA_NUM_PARALLEL=1- Use modelos menores / quantizados
- Prefira tamanhos de contexto mais curtos
Foco em Throughput
OLLAMA_NUM_PARALLEL=2(ou maior se houver margem)- Considere o agrupamento de solicitações na camada do cliente
- Garanta VRAM e threads de CPU suficientes
“Acabo ficando sem VRAM quando duas solicitações chegam”
- Reduza
OLLAMA_NUM_PARALLEL - Use um modelo mais agressivamente quantizado
- Reduza o comprimento do contexto / tokens máximos
Solução de problemas
Sintomas de que OLLAMA_NUM_PARALLEL está muito alto
- Solicitações falham intermitentemente sob carga
- OOM da GPU / descarregamento de modelos ocorre frequentemente
- Picos de latência quando a segunda solicitação chega
Sintomas de que OLLAMA_NUM_PARALLEL está muito baixo
- CPU/GPU está subutilizado
- Atrasos na fila dominam o tempo total de resposta
Dica: Se você também controla seu cliente, adicione retries com jitter e conexões keep-alive. Muitos problemas de “Ollama está lento” são realmente sobrecarga de fila + conexão.
Ollama: Agrupamento de Solicitações vs Execução Paralela
Agrupamento (Batching) no Ollama refere-se à prática de agrupar múltiplas solicitações entrantes e processá-las como uma unidade. Isso permite um uso mais eficiente dos recursos computacionais, especialmente quando executado em hardware que se beneficia de operações paralelizadas (como GPUs).
Quando múltiplas solicitações para o mesmo modelo chegam simultaneamente, o Ollama pode processá-las juntas em um lote se a memória permitir. Isso aumenta o throughput e pode reduzir a latência para cada solicitação, pois o modelo pode aproveitar operações de matriz otimizadas sobre o lote.
O agrupamento é particularmente eficaz quando as solicitações são similares em tamanho e complexidade, pois isso permite melhor utilização do hardware.
Execução paralela no Ollama significa lidar com múltiplas solicitações ao mesmo tempo, seja para o mesmo modelo ou para modelos diferentes, dependendo da memória disponível e da configuração.
O Ollama suporta dois níveis de paralelismo:
- Carregamento Múltiplo de Modelos: Se houver memória suficiente, vários modelos podem ser carregados e servir solicitações simultaneamente.
- Solicitações Paralelas por Modelo: Cada modelo carregado pode processar várias solicitações em paralelo, controlado pela configuração OLLAMA_NUM_PARALLEL (padrão é 1 ou 4, dependendo da memória).
Quando as solicitações excedem o limite de paralelismo, elas são colocadas em fila (FIFO) até OLLAMA_MAX_QUEUE.
Conclusão
O Ollama utiliza tanto o agrupamento quanto a execução paralela para processar múltiplas solicitações de forma eficiente. O agrupamento agrupa solicitações para processamento simultâneo, enquanto a execução paralela permite que múltiplas solicitações (ou modelos) sejam executadas concorrentemente. Ambos os métodos dependem da memória do sistema e são configuráveis para desempenho ideal.
Para mais benchmarks, ajuste de concorrência e orientação de desempenho, confira nosso hub de Desempenho de LLM: Benchmarks, Gargalos & Otimização.