Rodando LLMs locais no terminal: minha busca pelo modelo ideal no Ollama e Tabby

Quem vive na linha de comando cuidando de servidores, containers e scripts sabe que o terminal é onde tudo acontece. Recentemente, senti falta de ter um assistente inteligente integrado direto ali no meu fluxo diário. Eu já usava o Tabby via plugin e rodava o Ollama para autocompletar código com o qwen2.5-coder:7b, mas percebi que precisava de algo mais versátil.

A necessidade era clara: eu queria um modelo que não servisse apenas para gerar blocos de código, mas que soubesse "conversar" sobre infraestrutura e comandos de terminal. Queria tirar dúvidas rápidas sobre CLI do cPanel, debugar encadeamentos de logs no Docker, relembrar sintaxes do Kubernetes ou colar 200 linhas de um log misterioso do Apache ou do Exim e receber direto ao ponto: "o erro de proxy reverso está na linha 42" ou "esse loop de e-mail começou por causa dessa regra de SPF".

O grande desafio? Meu hardware. Eu rodo tudo em um notebook Asus TUF 16 com uma placa RTX 5050 de 8GB de VRAM e 16GB de RAM de sistema. Rodar modelos locais em máquinas com essa faixa de memória exige saber exatamente onde cada megabyte está sendo alocado.

O gargalo da VRAM ao analisar logs longos#

Quando você joga blocos extensos de texto e logs em um modelo de linguagem, o consumo de memória sobe rapidamente. Se o modelo e o contexto não couberem inteiros na memória de vídeo (VRAM), o Ollama começa a empurrar camadas de processamento para a memória RAM do computador.

O resultado disso é uma queda drástica na velocidade: a geração de texto passa de instantânea para um ritmo arrastado e travado.

Eu precisava de opções que respondessem na hora, sem estourar o limite de 8GB da GPU e sem comprometer a estabilidade do sistema operacional.

Os modelos testados no dia a dia#

Depois de testar várias alternativas no terminal, cheguei a três modelos com funções bem definidas para esse limite de hardware:

1. O pau para toda obra: qwen2.5:7b (versão de instrução geral)#

Diferente da variante coder, a versão geral de instrução do Qwen 2.5 é muito equilibrada para conversação técnica.

• Consumo de VRAM: cerca de 4.5 GB (roda 100% liso na GPU de 8GB com muita folga).
• Pontos fortes: Respostas quase instantâneas, excelente conhecimento de comandos Linux, Docker, cPanel e ferramentas de rede.
• Destaque: Janela de contexto nativa generosa, ideal para colar logs longos sem que o modelo se perca.

2. A alternativa sólida para explicações: llama3.1:8b#

O modelo da Meta continua sendo uma das opções mais consistentes para diagnósticos conceituais.

• Consumo de VRAM: cerca de 5.5 GB.
• Pontos fortes: Muito preciso para explicar o "porquê" de uma falha ou ajudar a desenhar a arquitetura antes de subir um serviço novo no Docker.

3. O especialista em problemas difíceis: deepseek-r1:8b#

Esse é o modelo que chamo quando pego um log realmente confuso, com erros encadeados em microsserviços ou falhas silenciosas de roteamento de e-mail.

• Consumo de VRAM: cerca de 5.2 GB.
• Pontos fortes: Ele usa raciocínio passo a passo (exibindo os blocos de raciocínio dentro das tags thinking). Demora um pouco mais para entregar a resposta final, mas analisa causas-raiz complexas que uma leitura rápida deixaria passar.

A dica de ouro: expandindo a janela de contexto (num_ctx)#

Uma armadilha comum para quem usa o Ollama pela primeira vez é achar que o modelo é ruim para ler logs, quando na verdade o problema é a configuração padrão.

Por padrão, muitas sessões do Ollama sobem com um limite de apenas 2048 tokens de contexto. Se você colar um log de 150 linhas do Nginx junto com uma pergunta, o modelo simplesmente trunca o texto e ignora metade dos dados.

Para resolver isso de forma definitiva:

Via chamada de API ou integração com scripts:#

Passe o parâmetro num_ctx configurado para 8192 ou 16384 tokens:

import ollama

response = ollama.chat(
    model='qwen2.5:7b',
    options={
        'num_ctx': 8192  # Garante contexto suficiente para logs inteiros
    },
    messages=[{
        'role': 'user',
        'content': 'Analise este log do Exim e aponte o motivo do travamento: ' + log_data
    }]
)

Criando um modelfile customizado:#

Você também pode criar uma variação personalizada com contexto expandido direto no Ollama:

# Modelfile
FROM qwen2.5:7b
PARAMETER num_ctx 8192
PARAMETER temperature 0.2

Depois basta compilar localmente:

ollama create qwen-terminal -f Modelfile

O setup que ficou fixo no meu dia a dia#

Depois de muitos testes práticos, meu fluxo no terminal ficou dividido em duas pontas:

1. Geração rápida de código e scripts: deixo o qwen2.5-coder:7b conectado via plugin no Tabby.
2. Análise de logs e dúvidas de terminal: utilizo o qwen2.5:7b (ou o deepseek-r1:8b para casos cabeludos) via CLI do Ollama.

Tudo roda local, sem enviar logs sensíveis de servidores para nuvens de terceiros, com latência mínima e aproveitando 100% da aceleração da GPU de 8GB.

Conclusão#

Neste artigo compartilhei a divisão que funcionou para mim na prática: o qwen2.5-coder:7b no Tabby para geração de código e o qwen2.5:7b (ou deepseek-r1:8b nos casos difíceis) para análise de logs — tudo com num_ctx expandido para não perder metade do contexto. Com 8GB de VRAM, essa combinação cobre bem o dia a dia sem depender de nuvem.

Veja também

Inteligência Artificial Visão computacional local com Ollama: extraindo dados de prints inteiros em uma GPU de 8GB

Inteligência Artificial Auditando o bypass de custos em automação CLI: analisando o OpenCode

Inteligência Artificial Por que sua IA parece defasada? O mito do "capamento" de API vs. a realidade arquitetônica

Este post está licenciado sob CC BY-NC.