Otimizando Ollama no Linux: Guia de Performance e Tuning

Contexto: A Realidade dos LLMs Locais em Infraestrutura de Baixo Custo

A execução de Modelos de Linguagem Grandes (LLMs) localmente deixou de ser um nicho acadêmico para se tornar uma necessidade corporativa estratégica. Ferramentas como Ollama, LM Studio e interfaces como Open WebUI democratizaram o acesso à inteligência artificial, permitindo que desenvolvedores e empresas mantenham a privacidade dos dados sensíveis e reduzam drasticamente a latência em aplicações críticas. No entanto, a diferença entre uma experiência de usuário fluida e um gargalo técnico intransponível reside quase exclusivamente na otimização do ambiente Linux subjacente.

Muitos administradores de sistemas subestimam o impacto profundo do kernel, do gerenciamento de memória e da configuração de armazenamento ao tentar carregar pesos de modelos complexos como Qwen, Llama 3 ou DeepSeek em hardware restrito. O Ollama é uma ferramenta excepcional para abstrair a complexidade do ciclo de vida dos modelos, mas ele não opera no vácuo. Sua performance depende intrinsecamente das capacidades do sistema operacional para gerenciar a carga de trabalho da GPU (quando presente) e, crucialmente, da CPU e RAM para tarefas de inferência sem acelerador dedicado ou para o pré-processamento de dados em pipelines de RAG (Retrieval-Augmented Generation).

Neste tutorial técnico, detalhamos o processo de tuning de performance passo a passo. O objetivo é garantir que sua instância VPS para IA local ou servidor físico entregue respostas rápidas, estáveis e previsíveis, transformando limitações de hardware em vantagens de eficiência através de configurações precisas no sistema.

Pré-requisitos

Antes de iniciar o processo de otimização, certifique-se de que você possui acesso root ou sudo ao seu servidor Linux. Este guia assume que o Ollama já está instalado e funcional. Recomendamos o uso de uma distribuição baseada em Debian/Ubuntu (como Ubuntu Server ou Debian Stable) devido à vasta documentação e suporte de drivers de GPU disponíveis. Para ambientes Docker, o Docker Engine e o Docker Compose devem estar instalados e configurados para funcionar com GPUs NVIDIA, caso aplicável.

Passo a passo: Tuning de Performance LLM

1. Verificação de Hardware e Drivers: Garantir que o kernel comunica-se eficientemente com o hardware.
2. Otimizações do Kernel Linux (Sysctl): Ajustar parâmetros de memória e I/O para reduzir latência.
3. Gestão de Swap e Memória Virtual: Prevenir o thrashing e otimizar o uso de RAM.
4. Otimização de Storage e I/O: Maximizar a velocidade de carregamento de pesos de modelos.
5. Ajustes Específicos do Ollama: Configurar variáveis de ambiente para controle fino de recursos.
6. Otimize o Pipeline de Embeddings: Tuning de componentes auxiliares como Qdrant e AnythingLLM.

1. Verificação de Hardware e Drivers

A fundação de qualquer sistema de IA eficiente é a comunicação direta e sem falhas entre o software e o hardware. Se você estiver utilizando uma VPS com GPU dedicada, como instâncias baseadas em NVIDIA, a versão e a configuração do driver são fatores críticos que podem limitar até 50% da performance potencial do modelo.

Inicie verificando se os módulos do kernel estão carregados corretamente e se o sistema reconhece a GPU:

nvidia-smi

Se o comando retornar erros, falhar ou não for encontrado, é imperativo instalar os drivers proprietários adequados à sua distribuição. Para sistemas baseados em Debian/Ubuntu, que são comuns em ambientes de VPS para IA local, o caminho padrão envolve a atualização dos repositórios e instalação do driver da série server, conhecida por sua estabilidade em cargas contínuas:

sudo apt update
sudo apt install -y nvidia-driver-535-server nvidia-compute-utils

Após a instalação, é recomendável reiniciar o servidor para que os novos módulos sejam carregados no boot. Para ambientes sem GPU dedicada, o foco deve ser deslocado para a otimização da CPU e da memória RAM. Certifique-se de que seu kernel esteja atualizado, pois versões mais recentes (5.15 ou superior) possuem melhorias significativas no escalonador de processos (CFS - Completely Fair Scheduler) e no gerenciamento de energia, essenciais para cargas de trabalho intensivas de inferência.

2. Otimizações do Kernel Linux (Sysctl)

O kernel Linux possui centenas de parâmetros que controlam como a memória é alocada, liberada e como os dados são escritos em disco. Para LLMs, o gerenciamento da dirty page cache (páginas de memória modificadas não escritas no disco) e a latência de entrada/saída (I/O) são fatores determinantes para a estabilidade da resposta.

Ajuste da Latência de Disco (I/O Scheduler)

Ollama realiza leituras massivas de arquivos de modelo (pesos) do disco durante o carregamento e, em alguns casos, durante a operação. Em discos NVMe de alta performance, o escalonador padrão pode introduzir overhead desnecessário. Os escalonadores none ou mq-deadline geralmente oferecem a menor latência possível.

Verifique qual escalonador está ativo atualmente no seu bloco de dispositivo (substitua sda pelo seu disco, como nvme0n1):

cat /sys/block/sda/queue/scheduler

Para aplicar o escalonador none (recomendado para NVMe modernos que já possuem seu próprio gerenciamento interno), execute:

echo none > /sys/block/sda/queue/scheduler

Para tornar essa configuração permanente e aplicável após reinicializações, adicione uma regra no arquivo /etc/udev/rules.d/99-ollama-iops.rules:

ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="none"

Otimização da Memória Suja (Dirty Pages)

Quando o sistema opera, os dados são escritos primeiro na memória cache antes de serem persistidos no disco. O parâmetro vm.dirty_ratio define a porcentagem máxima de memória que pode conter páginas sujas antes de forçar uma gravação síncrona bloqueante. Para inferência de IA, queremos evitar essas pausas súbitas que causam picos de latência.

Edite o arquivo /etc/sysctl.conf ou, preferencialmente, crie um arquivo dedicado em /etc/sysctl.d/99-ollama.conf com as seguintes diretrizes para suavizar a escrita:

# Reduz a latência ao forçar escrita mais frequente, mas em lotes menores
vm.dirty_background_ratio = 1
vm.dirty_ratio = 5

# Aumenta a preferência do kernel para manter arquivos de cache (modelos) na memória
vm.vfs_cache_pressure = 50

Após editar o arquivo, aplique as mudanças imediatamente sem reiniciar:

sudo sysctl -p /etc/sysctl.d/99-ollama.conf

3. Gestão de Swap e Memória Virtual

Um dos maiores inimigos da performance em LLMs é o thrashing (troca excessiva de memória). Se a RAM física se esgotar e o sistema começar a usar o disco como memória secundária via swap, a latência aumenta exponencialmente, podendo transformar segundos de resposta em minutos de espera.

Ajuste do Swappiness

O valor padrão de vm.swappiness é 60, o que incentiva o kernel a mover processos inativos para o swap prematuramente para liberar RAM. Para servidores dedicados a IA, queremos manter tudo na RAM física o máximo possível.

# Defina swappiness para 1 (quase zero)
echo "vm.swappiness=1" | sudo tee -a /etc/sysctl.d/99-ollama.conf

No entanto, definir o valor como 0 absoluto pode ser perigoso, pois pode causar kills OOM (Out of Memory) abruptos se houver um pico súbito de memória não previsto. Um valor entre 1 e 10 é o ideal para equilibrar a retenção na RAM com uma válvula de segurança.

Zswap e Compressão em Tempo Real

Se você possui uma VPS com menos RAM (ex: 8GB ou 16GB) e precisa rodar modelos maiores que excedem a memória física, ativar o zswap pode ser um divisor de águas. O zswap armazena páginas trocadas comprimidas na memória (RAM), reduzindo drasticamente a necessidade de escrita física no disco e mantendo a velocidade de acesso.

Verifique se o zswap está habilitado em seu kernel:

cat /sys/module/zswap/parameters/enabled

Se necessário, ative-o via GRUB editando /etc/default/grub e adicionando ao parâmetro GRUB_CMDLINE_LINUX_DEFAULT:

zswap.enabled=1 zswap.compressor=zstd

O algoritmo ZSTD oferece um excelente equilíbrio entre velocidade de compressão e descompressão. Após a edição, atualize o GRUB:

sudo update-grub

4. Otimização de Storage e I/O

O diretório padrão onde o Ollama armazena os modelos é /root/.ollama/models. A localização física deste diretório impacta diretamente a velocidade de carregamento inicial (cold start) e a capacidade de pré-carregar modelos para inferência rápida.

Movendo para SSD/NVMe Dedicado

Se sua VPS possui múltiplos discos, certifique-se de que o diretório de modelos está em um bloco de armazenamento rápido (SSD ou NVMe). Se você estiver usando Docker, comum em deployments de AnythingLLM e Open WebUI, monte um volume dedicado para garantir a persistência e performance:

docker run -d --gpus all -v ollama-data:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Para sistemas físicos ou VPSs sem containerização, verifique a latência de leitura sequencial para identificar gargalos:

dd if=/dev/zero of=/tmp/testfile bs=1G count=1 oflag=direct

Se o resultado for inferior a 500MB/s em um SSD moderno, considere migrar o sistema de arquivos ou verificar se há limitações de IOPS na sua VPS. Para sistemas de arquivos ext4, desativar a atualização do tempo de acesso (atime) pode melhorar ligeiramente a performance de leitura:

# Adicionar no /etc/fstab
/dev/sda1 / ext4 defaults,noatime 0 1

Desativando Atualizações Automáticas do Antivírus

Sistemas de segurança como ClamAV podem varrer os arquivos pesados do modelo (que podem ter dezenas de GB) enquanto você tenta carregá-los ou inferir, causando travamentos e aumento de I/O. Adicione exclusões robustas para o diretório do Ollama:

# Exemplo para ClamAV
# Edite /etc/clamav/clamd.conf
DatabaseDirectory /var/lib/clamav
ScanOnAccess yes
ExcludePath /root/.ollama/models/

5. Ajustes Específicos do Ollama (Variables)

O Ollama expõe variáveis de ambiente poderosas que controlam como ele utiliza os recursos da GPU e CPU. Estas variáveis devem ser definidas no serviço systemd ou no arquivo .env se estiver usando Docker, pois elas ditam a política de alocação de memória.

Controle de Camadas da GPU (GPU Layers)

Ollama permite carregar camadas específicas na GPU. Se sua GPU tem 8GB de VRAM e você está rodando Llama-3-8B, não tente carregar tudo se houver outros processos. Use a variável OLLAMA_NUM_PARALLEL para controlar conexões simultâneas e OLLAMA_MAX_LOADED_MODELS para gerenciar a concorrência.

No arquivo de serviço systemd (geralmente em /etc/systemd/system/ollama.service.d/override.conf):

[Service]
Environment="OLLAMA_NUM_PARALLEL=2"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

Isso evita que múltiplos modelos ou requisições concorrentes competam pela VRAM, causando erros de OOM na GPU e reinicializações indesejadas do serviço.

Threads e CPU Offloading

Para inferência via CPU (sem GPU dedicada ou para pré-processamento de embeddings), controle explicitamente o número de threads. Por padrão, o Ollama tenta usar todos os núcleos disponíveis, o que pode saturar a CPU e deixar o sistema responsivo.

Environment="OLLAMA_NUM_THREAD=4"

Ajuste este valor para 50-75% dos seus núcleos totais para reservar recursos para o sistema operacional, rede e outros processos de infraestrutura. Isso garante que a inferência não bloqueie outras operações críticas do servidor.

6. Otimize o Pipeline de Embeddings (Qdrant + AnythingLLM)

Em implementações de RAG (Retrieval-Augmented Generation) utilizando AnythingLLM e bancos vetoriais como Qdrant, a performance não depende apenas do LLM, mas da velocidade de busca vetorial. Um pipeline lento aqui cria um gargalo na recuperação de contexto, atrasando a resposta final.

Otimização do Qdrant

O Qdrant usa memória mapeada (mmap) por padrão para armazenar vetores de forma eficiente. Para melhorar a velocidade de busca e indexação, certifique-se de que o sistema operacional permite um número suficiente de mapas de memória.

# Em /etc/sysctl.d/99-qdrant.conf
vm.max_map_count=1048576

O valor padrão de max_map_count (geralmente 65530) é insuficiente para bancos de vetores grandes. Aumentá-lo para 1 milhão previne erros de "Too many open files" durante a indexação massiva de documentos e garante estabilidade sob carga.

Configuração de Docker Compose para Stack Completa

Abaixo, um exemplo de docker-compose.yml otimizado para uma stack local de IA, integrando Ollama, Qdrant e uma interface web. Note as configurações de recursos e threads:

version: '3.8'
services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama-data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    environment:
      - OLLAMA_NUM_PARALLEL=2
      - OLLAMA_MAX_LOADED_MODELS=1

  qdrant:
    image: qdrant/qdrant:v1.7.4
    volumes:
      - ./qdrant_storage:/qdrant/storage:z
    environment:
      - QDRANT_SERVICE_THREADS=8 # Ajuste conforme núcleos da CPU
    ports:
      - "6333:6333"

  app:
    image: ghcr.io/sophgo/anythingllm-docker:latest
    depends_on:
      - ollama
      - qdrant
    ports:
      - "3000:3000"
    environment:
      - EMBEDDINGS_PROVIDER=ollama
      - OLLAMA_BASE_URL=http://ollama:11434

volumes:
  ollama-data:

Neste exemplo, note a configuração QDRANT_SERVICE_THREADS. Definir isso explicitamente ajuda o Qdrant a paralelizar as operações de busca vetorial, essencial para aplicações RAG que precisam recuperar contextos relevantes em milissegundos, mantendo a fluidez da conversa.

Verificação e Troubleshooting

Após aplicar todas as configurações, é crucial validar se as mudanças tiveram o efeito desejado. Utilize ferramentas de monitoramento em tempo real para observar o comportamento do sistema sob carga.

• Monitoramento de GPU: Use nvidia-smi -l 1 para verificar o uso de VRAM e temperatura a cada segundo. Se a VRAM estiver saturada, reduza as camadas carregadas ou aumente OLLAMA_MAX_LOADED_MODELS para 1.
• Monitoramento de CPU/Memória: Use htop ou top para verificar se o valor de swappiness está sendo respeitado. Se você ver uso alto de Swap, revise as configurações de memória.
• Monitoramento de I/O: Use iostat -x 1 para identificar gargalos de disco. Uma utilidade de %util acima de 80-90% sustentada indica que o disco é o gargalo, e você deve considerar mover os modelos para um SSD mais rápido ou aumentar a cache do sistema.

Aviso: Ao testar novas configurações de kernel ou variáveis de ambiente, sempre faça isso em um ambiente de staging ou em horários de baixa demanda. Reinicialize o serviço systemctl restart ollama após cada alteração nas variáveis de ambiente para garantir que elas sejam aplicadas corretamente.

Perguntas frequentes

Qual a diferença entre Ollama e LM Studio para VPS?

Ollama é projetado especificamente para rodar como um serviço de API em servidores (headless), facilitando a integração com Docker e scripts automatizados. LM Studio, por outro lado, é focado em interfaces gráficas locais para desenvolvedores individuais. Para VPS para IA local, Ollama é a escolha superior devido à sua leveza e eficiência em recursos de sistema.

Como saber se meu modelo está usando a GPU ou a CPU?

Execute nvidia-smi enquanto faz uma inferência. Se o uso da GPU aumentar significativamente, os pesos estão na GPU. Se a CPU estiver em 100% e a GPU ociosa, o Ollama está usando CPU offloading. Verifique também as variáveis de ambiente e a compatibilidade do driver.

O que é RAG pipeline tuning?

RAG (Retrieval-Augmented Generation) combina busca em banco de dados vetorial com geração de texto. O tuning envolve otimizar tanto o LLM (para gerar bem) quanto o sistema de recuperação (Qdrant/Chroma) para encontrar os documentos corretos rapidamente. Isso inclui ajustar chunk sizes, embeddings e parâmetros de busca no banco vetorial.

Posso usar Ollama sem GPU dedicada?

Sim, o Ollama é altamente otimizado para CPUs modernas (Apple Silicon, Intel Xeon, AMD EPYC). No entanto, a velocidade será menor do que em GPUs. Para VPS sem GPU, foque intensamente na otimização de memória RAM e I/O de disco, e considere usar modelos quantizados (GGUF) para reduzir o uso de recursos.

Conclusão

A otimização de um ambiente Ollama no Linux não é um evento único, mas um processo contínuo de ajuste fino entre software de IA e o kernel do sistema. Ao aplicar as configurações de sysctl, gestão de swap, I/O e variáveis de ambiente descritas neste guia, você transforma uma VPS padrão em uma máquina robusta para inferência de LLMs.

Lembre-se: a regra de ouro é sempre reservar recursos para o sistema operacional. Nunca deixe o container ou serviço do Ollama com acesso ilimitado à CPU ou RAM. Pequenos ajustes podem significar a diferença entre uma resposta instantânea e um timeout crítico. Para garantir que sua infraestrutura de IA esteja sempre performando no limite, conte com soluções de hospedagem e cloud otimizadas para cargas de trabalho intensivas.