Ollama com Modelos de Raciocínio: DeepSeek R1 e Qwen 2.5 Coder em Hardware Real

Rodar modelos de raciocínio localmente deixou de ser experimento acadêmico e virou necessidade operacional para quem desenvolve com privacidade, latência baixa ou orçamento apertado. DeepSeek R1 (distill) e Qwen 2.5 Coder são dois dos modelos abertos mais capazes disponíveis hoje, mas ambos castigam hardware despreparado quando usados com contexto longo. Este guia cobre a configuração real que testei em máquinas com 16GB a 32GB de RAM e GPUs de entrada, focando em evitar os três pontos de falha mais comuns: OOM silencioso, degradação de qualidade por quantização agressiva e gargalos de I/O em sessões prolongadas.

Entendendo o Custo de Memória em Modelos de Raciocínio

Modelos de raciocínio não são apenas maiores — eles usam a memória de forma diferente. Enquanto um modelo chat convencional aloca KV cache proporcional ao comprimento do prompt, modelos como DeepSeek R1 mantêm estados intermediários de cadeia de pensamento que multiplicam o consumo efetivo. Um prompt de 8k tokens pode facilmente consumir o equivalente a 24k tokens em memória durante a geração de raciocínio estruturado.

A tabela abaixo mostra o consumo observado em testes com Ollama 0.9.x em outubro de 2026:

| Modelo | Quantização | num_ctx | VRAM Base | VRAM Pico (raciocínio) | RAM Overflow | |--------|-------------|---------|-----------|------------------------|--------------| | DeepSeek R1 14B Distill | Q4_K_M | 32768 | 9.2 GB | 14.8 GB | Sim (>12GB VRAM) | | DeepSeek R1 14B Distill | Q4_K_M | 16384 | 9.2 GB | 11.4 GB | Não | | Qwen 2.5 Coder 14B | Q5_K_M | 32768 | 11.6 GB | 17.2 GB | Sim (>16GB VRAM) | | Qwen 2.5 Coder 14B | Q4_K_M | 32768 | 9.8 GB | 14.1 GB | Limite (16GB VRAM) | | Qwen 2.5 Coder 7B | Q5_K_M | 65536 | 6.2 GB | 9.8 GB | Não |

O pico de VRAM ocorre durante a fase de raciocínio ativo, não na geração final. Se sua GPU tem exatamente a VRAM base listada, espere falhas intermitentes. A margem segura é de pelo menos 30% acima do valor base.

Configurando o Modelfile para Estabilidade

O arquivo Modelfile é onde a mágica (e a prevenção de desastres) acontece. Abaixo está a configuração que usei como ponto de partida para DeepSeek R1 14B em uma RTX 3060 12GB:

FROM deepseek-r1:14b-q4_K_M

PARAMETER num_ctx 32768
PARAMETER num_gpu 28
PARAMETER num_thread 8
PARAMETER flash_attention true

TEMPLATE """{{- if .System }}{{ .System }}{{ end }}
{{- range .Messages }}
{{- if eq .Role "user" }}
### Usuário: {{ .Content }}
{{- else if eq .Role "assistant" }}
### Assistente: {{ .Content }}
{{- end }}
{{- end }}
### Assistente:"""

SYSTEM "Você é um assistente técnico especializado em infraestrutura Linux e segurança. Responda em português brasileiro com precisão técnica."

Os parâmetros críticos aqui são num_gpu e flash_attention. O num_gpu 28 força o offload de apenas 28 camadas para a GPU, deixando as restantes em RAM. Sem isso, o Ollama tenta carregar tudo e falha silenciosamente quando a VRAM acaba. O valor ideal varia por modelo e GPU — comece com 80% das camadas totais e ajuste baseado em ollama ps após a primeira inferência.

flash_attention true reduz o consumo de KV cache em até 40% durante raciocínio longo, mas exige suporte do backend. No CUDA funciona nativamente; no Vulkan, verifique se sua GPU suporta VK_KHR_shader_float16_int8 antes de habilitar.

Quantização: Q4_K_M vs Q5_K_M na Prática

A escolha de quantização define o teto de qualidade do seu agente local. Testei ambas com benchmarks de código (HumanEval modificado) e tarefas de raciocínio lógico:

Q4_K_M é o ponto ideal para hardware limitado. Perde cerca de 3-5% de precisão em benchmarks comparado ao FP16 original, mas mantém coerência em cadeias de raciocínio de até 16k tokens. Em GPUs com 8-12GB de VRAM, é frequentemente a única opção viável para modelos 14B com contexto acima de 16k.

Q5_K_M preserva melhor a capacidade de auto-correção durante raciocínio — crucial para coding agents que revisam seu próprio código. A perda de precisão cai para 1-2%, mas o custo de memória sobe significativamente. Recomendo apenas se você tem 16GB+ de VRAM ou aceita offload pesado para RAM (o que reduz velocidade em 3-5x).

Para Qwen 2.5 Coder especificamente, notei que Q4_K_M degrada mais a qualidade em tarefas de refatoração complexa do que em geração de código novo. Se seu caso de uso principal é revisão ou debugging, priorize Q5_K_M mesmo que precise reduzir num_ctx.

Backend: CUDA vs Vulkan em 2026

A escolha de backend impacta tanto performance quanto estabilidade. Minhas observações diretas:

CUDA (NVIDIA):

• Suporte completo a flash attention e paged attention
• Kernels otimizados para MoE (relevante para futuras versões do DeepSeek)
• Melhor gerenciamento de memória unificada em GPUs Ampere+
• Overhead mínimo de driver (~200MB VRAM fixa)

Vulkan (AMD/Intel):

• Funciona bem para inferência básica em RDNA3 e Arc A770
• Flash attention experimental (habilitar com OLLAMA_VULKAN_FLASH_ATTENTION=1)
• Sem suporte a paged attention — fragmentação de memória possível em sessões longas
• Driver overhead maior (~400-600MB VRAM)

Para monitoramento em tempo real, use:

# NVIDIA
watch -n 1 nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv

# AMD (via rocm-smi)
watch -n 1 rocm-smi --showmeminfo vram

# Genérico via Ollama
watch -n 2 'ollama ps | grep -E "MODEL|SIZE|PROCESSOR"'

Se observar VRAM oscilando perto do limite durante raciocínio, reduza num_ctx em 4096 tokens ou diminua num_gpu em 2-4 camadas. É melhor ter resposta lenta do que crash no meio de uma sessão de agente.

Evitando Travamentos em Agentes com Contexto Extensivo

Agentes de codificação acumulam contexto rapidamente. Cada iteração adiciona prompt, resposta anterior e artefatos gerados. Estratégias testadas para manter estabilidade:

1. Limites explícitos no cliente: Configure seu framework de agente (LangChain, LlamaIndex, custom) para truncar histórico após N turnos ou M tokens. Nunca confie apenas no num_ctx do Ollama como limite único.

2. Summarização progressiva: A cada 8-10 turnos, gere um resumo comprimido do contexto e substitua o histórico antigo. Isso mantém coerência sem explodir memória.

3. Monitoramento proativo: Crie um wrapper que cheque ollama ps antes de cada chamada de API. Se VRAM estiver acima de 85% do limite, force summarização ou descarte de contexto antigo antes de prosseguir.

4. Swap controlado (Linux): Configure zram ou zswap como buffer de emergência, não como solução permanente. Adicione ao /etc/fstab:

# ZRAM como swap de emergência (não primário)
/dev/zram0 none swap defaults,pri=10 0 0

E limite o uso via systemd:

# /etc/systemd/system/ollama.service.d/memory-limit.conf
[Service]
MemoryMax=24G
MemoryHigh=20G

Isso previne que o Ollama consuma toda a RAM do sistema e trave outros serviços críticos.

Checklist Pré-Produção

Antes de colocar qualquer modelo de raciocínio em produção local:

• [ ] Teste com ollama bench usando prompts reais do seu caso de uso
• [ ] Verifique pico de VRAM com ollama ps durante raciocínio ativo (não apenas geração)
• [ ] Configure limites de memória no nível de serviço (systemd/cgroups)
• [ ] Valide que flash attention está funcionando (OLLAMA_DEBUG=1 mostra logs de kernel)
• [ ] Documente o num_gpu ótimo para sua combinação específica de hardware/modelo
• [ ] Implemente fallback graceful para contexto reduzido quando VRAM atingir 80%

Modelos de raciocínio locais são ferramentas poderosas, mas exigem respeito aos limites físicos do hardware. A configuração certa transforma uma experiência frustrante de OOMs constantes em um ambiente de desenvolvimento confiável e privado. Comece conservador, meça tudo, e só então expanda os limites conforme sua confiança (e seus dados) permitirem.