Nos últimos tempos, tenho estudado bastante sobre LLMs e resolvi fazer uma experiência relativamente simples: rodar um modelo de linguagem completamente local na minha máquina.
A ideia era entender melhor o que existe por trás de ferramentas como ChatGPT, Claude e Gemini, mas sem depender de uma API externa.
O objetivo inicial parecia simples:
Instalar um LLM, abrir uma interface parecida com o ChatGPT e começar a conversar com ele.
Na prática, a experiência acabou sendo muito mais interessante.
Passei por Ollama, Docker, Open WebUI, problemas de rede entre container e host, configuração de driver NVIDIA, CUDA, CPU/GPU offloading e, finalmente, uma demonstração prática de por que VRAM importa tanto quando falamos de LLMs locais.
Este artigo conta esse caminho.
O ambiente
A máquina que eu uso não é exatamente o suprassumo da computação:
CPU: Intel Core i7-7500U @ 2.70 GHz
Cores: 2
Threads: 4
GPU integrada:
Intel HD Graphics 620
GPU dedicada:
NVIDIA GeForce 940MX
VRAM: 2 GB
Sistema:
Linux Mint
O modelo que escolhi inicialmente foi:
Qwen3 8B
Quantização: Q4_K_M
Tamanho em disco: ~5.2 GB
Primeiro passo: Ollama
Para executar o modelo localmente, eu escolhi o Ollama.
Para baixá-lo, fui direto no site, na opção de download para Linux, e recebi o seguinte comando:
curl -fsSL https://ollama.com/install.sh | sh
Depois da instalação, baixei e executei o modelo:
ollama run qwen3:8b
Finalizado o download, apareceu o prompt, então fiz uma pergunta.
Funcionou! Mas nesse momento, já havia algo bem legal acontecendo:
Tudo local, sem precisar enviar o prompt para uma API externa.
Para confirmar os modelos instalados:
ollama list
No meu caso:
NAME SIZE
qwen3:8b 5.2 GB
Também é possível verificar diretamente a API do Ollama:
curl http://localhost:11434/api/tags
O Ollama expõe uma API HTTP local na porta 11434, isso significa que, além de usar o terminal, uma aplicação Java, Python, JavaScript ou qualquer outro cliente HTTP pode conversar diretamente com o modelo.
Mas eu queria algo mais confortável, queria uma interface parecida com o ChatGPT.
Entrando o Open WebUI
Para isso, eu precisava de uma interface amigável de interação, escolhi o Open WebUI.
A arquitetura seria:
Eu coloquei o Open WebUI em Docker, a interface abriu normalmente, só havia um pequeno problema, nenhum modelo aparecia.. O Ollama funcionava pelo terminal, a API funcionava, o modelo estava instalado, mas o Open WebUI não encontrava nada.
O primeiro problema: localhost não é sempre localhost
Foi aí que apareceu uma característica importante do Docker, o Ollama estava executando diretamente no Linux:
Enquanto o Open WebUI estava dentro de um container Docker.
Inicialmente, parecia natural configurar:
http://localhost:11434
Mas havia um detalhe fundamental, para o Open WebUI executando dentro do container, localhost significa o próprio container e não o host Linux.
Então eu tentei acessar o host usando:
http://host.docker.internal:11434
E adicionei:
--add-host=host.docker.internal:host-gateway
ao container.
O DNS funcionou, testando assim:
docker exec open-webui getent hosts host.docker.internal
retornando algo como:
172.17.0.1 host.docker.internal
Mas ainda assim a conexão com o Ollama dava timeout.
Verificando onde o Ollama estava escutando
Eu configurei o serviço do Ollama para escutar em todas as interfaces:
0.0.0.0:11434
Para isso:
sudo systemctl edit ollama
Eu adicionei:
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Depois reiniciei o serviço:
sudo systemctl daemon-reload
sudo systemctl restart ollama
Mesmo assim, ainda havia problemas de comunicação pela bridge do Docker, foi então que eu simplifiquei a arquitetura.
Docker usando a rede do host
Como tudo estava rodando na mesma máquina e o objetivo era estudo, eu executei o Open WebUI usando:
--network=host
O container ficou assim:
docker run -d \
--network=host \
-e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
-v open-webui:/app/backend/data \
--name open-webui \
--restart always \
ghcr.io/open-webui/open-webui:main
Agora eu podia testar a comunicação de dentro do container:
docker exec open-webui \
curl http://127.0.0.1:11434/api/tags
E finalmente recebi:
{
"models": [
{
"name": "qwen3:8b"
}
]
}
Open WebUI e Ollama estavam conversando, depois de ajustar a conexão do Open WebUI para:
http://127.0.0.1:11434
o qwen3:8b apareceu na interface.
Problema resolvido ou pelo menos parecia.
O modelo demorava uma eternidade
Eu enviei a mesma pergunta pelo Open WebUI.
Esperei...
E esperei...
E esperei mais um pouco...
Nada!
Nesse momento, surgiu a dúvida:
O sistema está travado ou o modelo simplesmente é muito lento?
O Ollama tem um comando excelente para responder isso:
ollama ps
O resultado foi:
NAME SIZE PROCESSOR CONTEXT
qwen3:8b 5.9 GB 100% CPU 4096
A resposta estava ali:
100% CPU.
O modelo não estava travado, ele estava calculando. O problema era que eu estava tentando executar um modelo de aproximadamente 8 bilhões de parâmetros usando um:
Intel Core i7-7500U
2 cores
4 threads
Não exatamente o cenário ideal, mas havia uma NVIDIA na máquina.
E a GeForce 940MX?
O Linux detectava a placa:
lspci | grep -Ei 'VGA|3D|Display'
Resultado:
Intel HD Graphics 620
NVIDIA GeForce 940MX
Então por que o Ollama estava usando apenas CPU?
Eu rodei:
nvidia-smi
E recebi:
NVIDIA-SMI has failed because it couldn't communicate
with the NVIDIA driver.
Agora eu tinha outro problema, o hardware existia, mas o driver NVIDIA não estava funcionando corretamente.
Investigando o driver NVIDIA
Primeiro, eu verifiquei os drivers disponíveis:
ubuntu-drivers devices
O sistema recomendava:
nvidia-driver-580
Também verifiquei o kernel:
uname -r
e o Secure Boot:
mokutil --sb-state
O Secure Boot estava desabilitado, que segundo uma boa e velah pesquisa no Google é uma causa comum de módulos NVIDIA não carregarem. Instalei o driver, porém mesmo depois da instalação do driver ao executar o comando:
nvidia-smi
continuava falhando, então eu fui um nível abaixo.
sudo modprobe nvidia
E apareceu um erro curioso:
could not find module by name='off'
could not insert 'off'
Essa mensagem foi uma pista importante, o sistema estava tentando resolver o módulo nvidia como off.
Em máquinas com gráficos híbridos Intel + NVIDIA, o PRIME pode manter a GPU NVIDIA desativada dependendo do perfil selecionado.
Eu verifiquei então:
prime-select query
e ajustei o perfil NVIDIA.
Depois do reboot, finalmente:
nvidia-smi
retornou:
NVIDIA GeForce 940MX
Driver Version: 580.173.02
CUDA Version: 13.0
VRAM: 2048 MiB
A GPU estava funcionando.
Agora o Ollama vai voar, certo?
Não exatamente, eEu reiniciei o Ollama, carreguei novamente o Qwen3 e executei:
ollama ps
Resultado:
PROCESSOR
95%/5% CPU/GPU
E aqui veio talvez a parte mais interessante de todo o experimento, a GPU estava funcionando, o Ollama estava usando a GPU, mas apenas uma pequena parte do modelo estava sendo processada por ela.
Por quê?
VRAM: encontramos o próximo gargalo
A GeForce 940MX possui:
2 GB VRAM
O Qwen3 8B estava ocupando aproximadamente:
6.2 GB
Além disso, parte da VRAM já estava sendo utilizada pelo ambiente gráfico, portanto simplesmente não havia memória suficiente para colocar uma parte significativa do modelo na GPU. A situação era aproximadamente:
O resultado observado pelo Ollama:
95% CPU
5% GPU
Ou seja: configurar corretamente a GPU melhorou o ambiente, mas não transformou uma GPU de 2 GB em uma GPU adequada para um modelo de 8B parâmetros.
E essa talvez tenha sido a melhor lição do experimento.
Ter uma NVIDIA não significa que o LLM rodará bem
Antes dessa experiência, seria fácil para mim resumir os requisitos como:
É melhor ter uma GPU NVIDIA porque LLM usa CUDA.
Isso está correto, mas é incompleto, para inferência local, eu preciso olhar pelo menos para:
GPU
│
├── arquitetura
├── suporte CUDA
├── driver
├── capacidade computacional
└── VRAM
E VRAM rapidamente se torna um fator limitante, um modelo possui bilhões de parâmetros, esses parâmetros precisam estar em algum lugar durante a inferência. Quanto mais consigo manter na GPU, maior tende a ser o benefício da aceleração, quando o modelo não cabe, é possível realizar offloading parcial:
GPU ← algumas camadas
CPU ← restante
Foi exatamente o que aconteceu comigo.
O que aprendi com o experimento
Eu comecei querendo apenas instalar um "ChatGPT local".
Acabei passando por:
LLM
↓
Ollama
↓
HTTP API
↓
Open WebUI
↓
Docker networking
↓
Linux networking
↓
systemd
↓
NVIDIA PRIME
↓
kernel modules
↓
CUDA
↓
GPU offloading
↓
VRAM
E justamente por isso o experimento valeu muito mais do que simplesmente instalar uma aplicação pronta.
Hoje eu consigo enxergar melhor as diferentes responsabilidades:
Quando uma resposta demora, o problema pode estar em qualquer uma dessas camadas.
E comandos simples como:
ollama ps
nvidia-smi
watch -n 1 nvidia-smi
ss -lntp
journalctl
lspci
acabam sendo extremamente úteis para descobrir onde está o gargalo.
Próximos passos
Agora que o laboratório está funcionando, existem várias experiências interessantes para continuar: embeddings, RAG, tool/function calling, agents, MCP e integração de LLMs com aplicações tradicionais.
Mas isso fica para os próximos experimentos.
O que começou como:
Quero instalar um LLM na minha máquina.
acabou sendo uma ótima introdução prática à infraestrutura necessária para realmente executar um modelo localmente e descobrir por que alguma coisa não funcionava foi, provavelmente, a parte em que mais aprendi.
