Ollama + Open WebUI self-hosted: 3 realidades que ninguém conta

Todo post de “monte seu ChatGPT grátis em casa” tem o mesmo roteiro: curl, docker run, duas linhas de comando, print de tela feliz com a resposta instantânea. Ninguém mostra o segundo dia, quando o modelo de 7B que rodou liso no vídeo de demonstração trava a CPU de um notebook comum por dezenas de segundos pra responder uma pergunta de três linhas. Ollama + Open WebUI self-hosted é real, funciona e tem documentação decente, mas o gargalo nunca foi o comando de instalação. É saber qual modelo sua máquina aguenta rodar com qualidade que sirva pra trabalho de verdade, e separar duas palavras que o marketing adora confundir: privado e seguro.

O resultado depende do hardware, não do tutorial

Ollama é um runtime que empacota o llama.cpp com uma API REST simples: baixa o modelo, carrega em memória (VRAM se tiver GPU, RAM se não tiver) e responde via localhost:11434. Open WebUI é a interface web por cima, parecida com a do ChatGPT, que conversa com essa API. A dupla é leve de configurar, isso é verdade e está bem documentado no próprio repositório do Open WebUI no GitHub.

O problema é a inferência em si. Eu rodo um Llama 3 8B em Q4 numa GPU de consumo com VRAM suficiente pra carregar o modelo inteiro, e a resposta sai token a token de forma fluida, sem aquela sensação de “a máquina tá pensando”. É uso tranquilo pra resumo de texto e código simples no dia a dia. Quando a GPU comporta o modelo, esse tipo de fluidez é a norma, e é a faixa de desempenho que aparece nos benchmarks da comunidade llama.cpp e nas discussões do repositório do Ollama no GitHub.

O cenário muda de figura quando não há GPU dedicada no jogo. Rodando só em CPU, o mesmo modelo despeja o trabalho inteiro nos núcleos do processador, e a geração de texto fica visivelmente arrastada (a documentação do llama.cpp e os relatos no subreddit r/LocalLLaMA são consistentes nisso). Sem paralelismo de GPU, cada token custa caro em tempo de processamento. Pra quem usa o ChatGPT na barra lateral do navegador o dia inteiro, isso não é “um pouco mais lento”. É inviável pra uso diário.

A cena do vídeo de demonstração quase sempre usa uma GPU dedicada decente. O tutorial não menciona isso porque o passo de instalação é idêntico nos dois casos (o ollama run llama3 roda do mesmo jeito numa máquina bem equipada e num notebook de escritório). Só que o resultado prático é completamente diferente.

Qual VRAM eu preciso de verdade, e por que ninguém fala do quantizado que sobra na conta

A métrica que decide tudo é VRAM, não “ter uma placa de vídeo”. E aqui a quantização é a palavra que separa o que é viável do que é fantasia. Modelos quantizados em Q4 (4 bits por parâmetro, em vez dos 16 ou 32 bits originais) perdem uma fração de precisão em troca de caber em memória bem menor. É prática padrão documentada pela comunidade llama.cpp e replicada nos modelos listados na biblioteca do Ollama.

Uma régua prática, baseada nos requisitos que o próprio Ollama lista para cada tamanho de modelo:

Faixa de parâmetros	Quantização comum	VRAM aproximada	Hardware de consumo típico
7B, 8B	Q4	~6 GB	GPUs de entrada/meio de linha com 8-12GB
13B	Q4	~10 GB	GPUs de meio-alto de linha
34B	Q4	~20-24 GB	GPUs de topo de linha de consumo
70B	Q4	40 GB+	Múltiplas GPUs ou aceleradores de datacenter

A faixa de 70B é onde a maioria dos tutoriais para de falar. As placas de topo de linha disponíveis no mercado doméstico não chegam perto do que um 70B quantizado precisa. Pra rodar esses modelos maiores localmente, a alternativa realista é dividir a carga entre múltiplas GPUs ou aceitar que parte do modelo vá pra RAM do sistema, o que derruba a velocidade de volta pro território da espera incômoda.

Na prática, a maior parte de quem instala Ollama em casa ou no notebook do trabalho vai operar na faixa de 7B a 13B, como eu faço. São modelos bons pra resumo, geração de código simples e chat geral, mas ficam visivelmente atrás de um GPT-4 ou Claude em raciocínio complexo e em tarefas que exigem contexto longo e preciso. Isso não é defeito do Ollama. É física de GPU.

Local não é sinônimo de privado, e é aí que a Open WebUI vaza se você deixar a porta aberta

Aqui mora a confusão mais perigosa, e ela é estritamente técnica, não ideológica. Local quer dizer que os dados não saem da sua máquina pra nuvem de terceiros, isso o Ollama entrega de fato, porque a inferência acontece inteiramente no hardware onde está instalado. Privado, nesse sentido restrito, é verdade.

Seguro é outra pergunta, e a resposta é “depende de como você expõe o serviço”. Um cenário comum em times de TI menores: alguém sobe a Open WebUI num servidor interno, libera a porta 3000 (ou a porta configurada) na rede da empresa pra que o time todo acesse via IP, e não configura nenhuma camada de autenticação além do login padrão da própria interface (ou pior, desativa a autenticação achando que, por estar “dentro da rede interna”, já está protegido). A documentação do Open WebUI é clara sobre a existência de variáveis de ambiente pra desabilitar o cadastro aberto e sobre o uso de proxy reverso com HTTPS e controle de acesso, mas isso exige uma etapa consciente de configuração. Não vem ativado por padrão em todo cenário de deploy via Docker.

O risco real não é alguém da internet batendo na porta 11434 do Ollama (embora isso também aconteça se a porta for exposta sem cuidado pra fora da rede local). O risco mais comum é lateral: qualquer pessoa na mesma rede Wi-Fi do escritório, incluindo um estagiário com acesso de convidado ou um dispositivo comprometido, consegue acessar o histórico de conversas de todo mundo que usa aquela instância, incluindo prompts com dados sensíveis de clientes ou trechos de código proprietário colados ali pra pedir ajuda. Um deploy mal configurado desses coloca, sem querer, um banco inteiro de conversas sensíveis atrás de uma porta sem cadeado nenhum.

O teto de qualidade em português que o benchmark do modelo não mostra

Os benchmarks publicados pelos laboratórios que treinam esses modelos (MMLU, HumanEval, GSM8K) são majoritariamente avaliados em inglês. O desempenho em português varia conforme a proporção de dados em português usada no treinamento, algo que a maioria dos cards de modelo no Hugging Face ou na biblioteca do Ollama não detalha com transparência.

Modelos de código aberto como o Llama 3 e variantes do Mistral tendem a responder em português de forma gramaticalmente correta, mas é comum notar perda de nuance em tarefas que exigem vocabulário técnico específico ou registro formal, como contratos ou laudos jurídicos. No meu uso diário com o Llama 3 8B, isso fica claro em pedidos mais formais: o texto sai correto, mas meio “seco”, sem a naturalidade que um GPT-4 entrega em português. Modelos ajustados especificamente para português brasileiro, como as variantes fine-tuned divulgadas por grupos de pesquisa nacionais e disponibilizadas no Hugging Face, tendem a performar melhor nesse recorte, mas em geral são de porte menor (7B ou 8B) e não chegam ao nível de raciocínio dos modelos maiores da OpenAI ou Anthropic. É uma troca: menos custo e mais controle, com um teto de qualidade linguística mais baixo. Esse teto, mais do que a latência, é o motivo pelo qual eu não recomendaria Ollama + Open WebUI pra quem depende de redação em português formal todo dia.

A conta de eletricidade que ninguém faz antes de comprar a GPU

Uma GPU de consumo rodando inferência sob carga puxa uma quantidade relevante de energia, e isso varia bastante conforme o modelo e a intensidade de uso. Se essa placa fica ligada o dia inteiro num servidor doméstico ou de escritório pequeno pra manter o Ollama disponível pra consultas esporádicas do time, o consumo elétrico mensal entra na conta de luz de um jeito que ninguém calculou antes de comprar o hardware. Compare isso com o modelo de cobrança por token de uma API como a da OpenAI ou Anthropic, onde você paga só pelo que usa: pra um time pequeno com uso esporádico, a API quase sempre sai mais barata no fim do mês. O self-host só começa a compensar financeiramente em volume alto e constante de uso (e aí entra também o tempo de alguém mantendo o servidor de pé).

Minha opinião final

Ollama + Open WebUI é uma das melhores portas de entrada pra quem quer entender como LLM funciona por baixo do capô, e pra quem tem um caso real de dado sensível que não pode sair da máquina. Mas vender isso como “ChatGPT grátis e privado” é simplificação perigosa.

Antes de prometer isso pro seu time, resolva três coisas na ordem certa. Primeiro, confira a VRAM real disponível e escolha o modelo compatível: 8B em Q4 pede uns 6GB, 13B em Q4 pede uns 10GB, e qualquer coisa acima disso sem GPU de verdade vira exercício de paciência. Segundo, configure autenticação de verdade na Open WebUI antes de liberar qualquer porta na rede interna, com proxy reverso e HTTPS (sem isso, “privado” vira “aberto pra quem estiver no mesmo Wi-Fi”). Terceiro, teste a qualidade em português com os casos de uso reais da sua equipe, não com o benchmark em inglês do card do modelo, porque é ali que a maior parte das decepções aparece depois da instalação.

É infraestrutura, com conta de luz, superfície de ataque e teto de qualidade definido pela GPU que você tem, não pela que você queria ter. Trate como projeto de TI, não como atalho mágico, e aí sim ele entrega o que promete.

Fontes consultadas

• GitHub, ollama/ollama: Get up and running with Kimi, GLM, MiniMax, DeepSeek, gpt-oss, Qwen, Gemma and other models, link
• Ollama Docs, Authentication – Ollama (API local em localhost:11434 sem autenticação), link
• Open WebUI Docs, Hardening Open WebUI, link
• Open WebUI Docs, Environment Variable Configuration / Open WebUI (ENABLE_SIGNUP, WEBUI_ADMIN_EMAIL), link
• Ollama (biblioteca de modelos), llama2:70b – Memory requirements por tamanho de modelo (7b, 13b, 70b), link
• arXiv, Which Quantization Should I Use? A Unified Evaluation of llama.cpp Quantization on Llama-3.1-8B-Instruct, link