Como o Ollama Lida com Requetes Paralelos

Este guia explica como o Ollama lida com requisições paralelas (concorrência, fila e limites de recursos), e como ajustar isso usando a variável de ambiente OLLAMA_NUM_PARALLEL (e outras configurações relacionadas).

Para mais informações sobre throughput, latência, VRAM e benchmarks entre diferentes runtimes e hardwares, consulte Desempenho de LLMs: Benchmarks, Gargalos e Otimização.

Agentes multi-etapas multiplicam as tentativas quando a amostragem é instável; para as 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 Requisições Concorrentes

• Processamento Paralelo: O Ollama suporta o processamento concorrente de requisições. Se o sistema tiver memória disponível suficiente (RAM para inferência por CPU, VRAM para inferência por GPU), vários modelos podem ser carregados ao mesmo tempo, e cada modelo carregado pode lidar com várias requisições em paralelo. Isso é controlado pela variável de ambiente OLLAMA_NUM_PARALLEL, que define o número máximo de requisiçõ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.

• Lotes (Batching): Quando várias requisições para o mesmo modelo chegam simultaneamente, o Ollama as agrupa em lotes e as processa juntas. Isso significa que ambas as requisições são processadas em paralelo, e os usuários verão as respostas sendo transmitidas de volta ao mesmo tempo. O servidor não espera intencionalmente para preencher um lote; o processamento começa assim que as requisições ficam disponíveis.

Filas e Limites

• Fila (Queuing): Se o número de requisições concorrentes exceder a paralelismo configurado (por exemplo, mais de OLLAMA_NUM_PARALLEL requisições para um modelo), as requisições adicionais são colocadas em fila. A fila opera de forma primeiro a entrar, primeiro a sair (FIFO).

• Limites da Fila: O número máximo de requisições em fila é controlado por OLLAMA_MAX_QUEUE (padrão: 512). Se a fila estiver cheia, novas requisições recebem um erro 503 indicando que o servidor está sobrecarregado.

• Carregamento de Modelos: O número de diferentes modelos que podem ser carregados ao mesmo tempo é controlado por OLLAMA_MAX_LOADED_MODELS. Se uma requisição exigir o carregamento de um novo modelo e a memória for insuficiente, o Ollama descarregará modelos ociosos para liberar espaço, e a requisição ficará na fila até que o modelo seja carregado.

Cenário de Exemplo

Se duas requisições para o mesmo modelo chegarem ao mesmo tempo e o paralelismo do servidor estiver definido para pelo menos 2, ambas as requisições serão processadas juntas em um lote, e ambos os usuários receberão respostas simultaneamente. Se o paralelismo estiver definido para 1, uma requisição será processada imediatamente, e a outra ficará na fila até a primeira terminar.

Se as requisições forem para modelos diferentes e houver memória suficiente, ambos os modelos podem ser carregados e as requisições processadas em paralelo. Caso contrário, um modelo pode precisar ser descarregado, e a requisição ficará na fila.

Tabela Resumo

Em resumo, o Ollama é projetado para lidar com várias requisições simultâneas de forma eficiente, desde que o servidor esteja configurado para concorrência e tenha recursos suficientes. Caso contrário, as requisiçõ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 considerar em relação a uma migração para um motor de entrega (serving engine) de propósito específico. Do Ollama para o vLLM: Quando Migrar Seu Servidor Local de LLM aborda essa decisão, incluindo o continuous batching e o PagedAttention como os mecanismos que o vLLM usa para impedir que requisições concorrentes se prejudiquem mutuamente.

Tratamento de Memória Insuficiente

Quando o Ollama encontra memória insuficiente para lidar com requisições recebidas, ele emprega uma combinação de mecanismos de fila e estratégias de gerenciamento de recursos para manter a estabilidade:

Fila de Requisições

• Novas requisiçõ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 requisições).
• Se a fila atingir a capacidade, novas requisições recebem erros 503 “Servidor Sobrecarregado”.

Gerenciamento de Modelos

• Modelos ativos podem ser descarregados da memória quando ficam ociosos para liberar recursos para requisições em fila.
• O número de modelos carregados simultaneamente é limitado por OLLAMA_MAX_LOADED_MODELS (padrão: 3× número de GPUs ou 3 para CPU).

Otimização de Memória

• Tenta processar requisições para o mesmo modelo em lote para maximizar a eficiência de memória.
• Para inferência por 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 requisições em fila excedem os recursos disponíveis, o Ollama pode:

• Fazer paginação para o disco (degradando severamente o desempenho)
• Retornar erros “memória insuficiente” (out of memory)
• Causar a falha (crash) da instância do modelo em casos extremos

Os administradores devem monitorar o uso de memória e ajustar esses parâmetros com base nas capacidades do hardware. O tratamento de memória insuficiente torna-se crucial ao executar modelos maiores (7B+ parâmetros) ou processar várias requisições concorrentes.

Estratégias de otimização do Ollama

Habilite a aceleração por GPU com export OLLAMA_CUDA=1 e defina as threads da CPU com export OLLAMA_NUM_THREADS=84. Melhorias de Hardware

• RAM: 32GB+ para modelos de 13B, 64GB+ para modelos de 70B
• Armazenamento: SSDs NVMe para carregamento/troca de modelos mais rápidos
• GPU: NVIDIA RTX 3080/4090 com 16GB+ de VRAM para modelos maiores

Estratégias Operacionais

• Lotes de Requisições: Processe várias consultas simultaneamente para diluir o overhead de memória
• Descarregamento Automático de Modelos: Permite que o Ollama remova modelos ociosos da memória
• Cache de Modelos Frequentemente Usados: Mantenha modelos comuns residentes na memória

Monitoramento e Solução de Problemas

• Use nvidia-smi (GPU) e htop (CPU/RAM) para identificar gargalos
• Para erros de memória:
• Faça upgrade para modelos quantizados
• Reduza as requisições concorrentes
• Aumente o espaço de swap

Exemplo de fluxo de trabalho de otimização:

### Use um modelo quantizado com aceleração de GPU
export OLLAMA_CUDA=1
ollama run llama2:7b-q4_0 --context-size 2048

### Limite modelos carregados e requisiçõ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%, mantendo a qualidade da resposta, sendo particularmente benéfico ao executar vários modelos ou lidar com altos volumes de requisições.

Variável de ambiente OLLAMA_NUM_PARALLEL

OLLAMA_NUM_PARALLEL controla quantas requisições o Ollama executará em paralelo. Se você enviar várias requisições para o mesmo servidor Ollama, esta configuração determina em grande parte se elas serão executadas concorrentemente ou colocadas em fila.

• Valores mais altos podem aumentar o throughput se você tiver CPU/GPU/VRAM suficiente, mas podem aumentar a latência e a pressão de memória.
• Valores mais baixos reduzem a contensão e podem melhorar a estabilidade, mas as requisições ficarão em fila com mais frequência.

A memória, especificamente, escala com OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH: quatro slots paralelos com configuração de contexto de 32K reservam cache KV como se uma sequência única de 128K estivesse carregada, mesmo antes de qualquer requisição usá-lo. Em um cartão de 16 GB, essa conta de orçamento geralmente importa mais do que o comportamento de fila — veja Cache KV em GPUs de 16 GB para o orçamento completo de VRAM e por que OLLAMA_NUM_PARALLEL=1 é geralmente o ponto de partida correto para uma única sessão de contexto longo.

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 limitado, e depois aumente gradualmente enquanto monitora:

• Uso de VRAM da GPU (OOM / evicções)
• Uso de CPU e média de carga (load average)
• Latência p95 das suas requisições típicas
• Taxa de erro / timeouts

Se você está otimizando uma página específica para uso via CLI, veja a seção CLI do Ollama na folha de dicas, além de exemplos de comandos para ollama serve, ollama ps e ollama run.

Receitas rápidas de ajuste

Priorizando estabilidade

• OLLAMA_NUM_PARALLEL=1
• Use modelos menores / quantizados
• Prefira tamanhos de contexto mais curtos

Priorizando throughput

• OLLAMA_NUM_PARALLEL=2 (ou mais alto se você tiver folga)
• Considere o lote de requisições na camada do cliente
• Garanta VRAM e threads de CPU suficientes

“Acabo a VRAM quando duas requisiçõ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

• Requisições falham intermitentemente sob carga
• OOM de GPU / descarregamento de modelos ocorre com frequência
• Picos de latência quando a segunda requisição chega

Sintomas de que OLLAMA_NUM_PARALLEL está muito baixo

• CPU/GPU subutilizada
• Atrasos de fila dominam o tempo total de resposta

Dica: Se você também controla o seu cliente, adicione tentativas com jitter (jitter) e conexões keep-alive. Muitos problemas de “Ollama é lento” são na verdade fila + overhead de conexão.

Ollama: Lotes de Requisições vs. Execução Paralela

Lote (Batching) no Ollama refere-se à prática de agrupar várias requisições recebidas juntas 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 várias requisiçõ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 de cada requisição, pois o modelo pode aproveitar operações de matriz otimizadas sobre o lote.

O lote é particularmente eficaz quando as requisições são semelhantes em tamanho e complexidade, pois isso permite um melhor uso do hardware.

Execução paralela no Ollama significa lidar com várias requisiçõ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 disponível, vários modelos podem ser carregados e atender requisições simultaneamente.
• Requisições Paralelas por Modelo: Cada modelo carregado pode processar várias requisições em paralelo, controlado pela configuração OLLAMA_NUM_PARALLEL (o padrão é 1 ou 4, dependendo da memória).

Quando as requisições excedem o limite de paralelismo, elas são colocadas em fila (FIFO) até o limite OLLAMA_MAX_QUEUE.

Conclusão

O Ollama utiliza tanto o lote (batching) quanto a execução paralela para processar várias requisições de forma eficiente. O lote agrupa requisições para processamento simultâneo, enquanto a execução paralela permite que várias requisições (ou modelos) sejam executadas concorrentemente. Ambos os métodos dependem da memória do sistema e são configuráveis para desempenho optimal.

Para mais benchmarks, ajustes de concorrência e orientações de desempenho, verifique nosso hub de Desempenho de LLMs: Benchmarks, Gargalos e Otimização.

Links úteis

• Folha de dicas de comandos Ollama
• Comparação de desempenho de LLMs - Ollama em GPU com 16GB de VRAM
• Mover Modelos Ollama para Outro Disco ou Pasta
• Como o Ollama usa os Núcleos de Desempenho e Eficiência da CPU Intel
• Do Ollama para o vLLM: Quando Migrar Seu Servidor Local de LLM