Ollama + Open WebUI Avançado 2026: WSL2, GPU, HTTPS e RBAC

Ollama Open WebUI LLM local Docker Compose NVIDIA CUDA WSL2 GPU passthrough Cloudflare Tunnel RBAC backup troubleshooting Nemotron Qwen Llama Mistral DeepSeek Claude Code Continue.dev IA local AI sysadmin developer  |  ✎ Duarte Spínola  |  2026-06-15

O artigo
cobriu a instalação básica — o docker-compose.yml, o download do NVIDIA Nemotron-3-Nano 30B, e os primeiros passos. Este artigo é o guia avançado para sysadmins e developers que já têm o stack a correr e precisam de o operar em produção: catálogo de 12+ modelos (Qwen 2.5/3, Llama 3.3, DeepSeek-R1, Mistral, Phi-4, Gemma 3, Granite 3) com VRAM e janela de contexto, tuning de performance (num_ctx, num_gpu, kv_cache_type, flash_attention), GPU passthrough em WSL2, HTTPS via Cloudflare Tunnel, multi-utilizador com RBAC (admin, user, grupos, ACLs), backup de modelos e DB (24GB+ por modelo), troubleshooting dos 8 problemas mais comuns, e integração com Claude Code / Continue.dev para usar Ollama como backend de coding assistants. Foco em PMEs, equipas de developers, e researchers AI que precisam de IA local sem custos de API e com privacidade total (dados nunca saem da máquina).

1. O que Está a Acontecer — Ollama 0.5+, Open WebUI 0.4+, e o Ecossistema de IA Local em 2026

O ano de 2025-2026 foi de maturação explosiva para IA local. O Ollama atingiu 0.5.x com suporte estável a vision models, function calling, structured outputs (JSON mode), e embeddings; o Open WebUI atingiu 0.4+ com RAG (Retrieval-Augmented Generation) nativo, web search integrado, e RBAC empresarial. Os modelos open-weight passaram de “alternativa fraca ao GPT-4” para “competitivos ou superiores em tarefas específicas” (Tabela 1.1).

Tabela 1.1 — Marcos do Ecossistema IA Local (2024-2026)

Tabela 1.2 — Ollama vs APIs Pagas (Trade-offs)

Insight chave: Ollama em 2026 é viável para 80% dos casos de uso empresarial. Os 20% que exigem cloud são: (a) conhecimento em tempo real (web search resolve parcialmente), (b) multimodal avançado (vídeo, audio longo), (c) capacidade de raciocíno extrema (modelos >100B com context window longo). Para tudo o resto, local é o caminho.

2. Cenários em que este setup avançado se aplica

• [S] Developer solo / freelancer — A usar Ollama + Continue.dev ou Claude Code como coding assistant local, sem enviar código para cloud. Custo zero de API. Privacidade total. Modelo típico: Qwen 2.5 Coder 7B (7GB VRAM) ou DeepSeek-Coder-V2 16B (16GB VRAM).

• [S] Equipa de desenvolvimento (5-15 devs) — Servidor Ollama partilhado com Open WebUI multi-utilizador (RBAC, histórico partilhado). Coding assistants por developer. Modelo típico: Qwen 2.5 Coder 32B (20GB VRAM) ou Llama 3.3 70B quantizado (48GB VRAM).

• [S] PME a servir múltiplos casos de uso — Ollama + Open WebUI para summarization, Q&A, análise de contratos, customer support. 5-50 utilizadores. RBAC com grupos por departamento. Cloudflare Tunnel para HTTPS. Backup diário dos 50GB+ de modelos + DB. Modelo típico: Nemotron-3-Nano 30B (24GB VRAM) ou Qwen 2.5 72B quantizado (48GB).

• [S] Startup AI / agency — Múltiplas GPUs, multi-model serving (vários Ollama em paralelo, load balancing). Ollama + Open WebUI + LiteLLM como gateway para múltiplos modelos. LangSmith ou LangFuse para observability. Modelo típico: mix de Llama 3.3 70B + DeepSeek-R1 70B + Mistral Large.

• [S] Researcher / acadêmico — Foco em modelos specialized (biomedical, legal, code, math). Fine-tuning com LoRA/QLoRA em datasets próprios. Backup versionado dos modelos. Hugging Face para partilhar. Modelo típico: Llama 3.1 8B fine-tuned + Mistral 7B fine-tuned.

3. Catálogo de Modelos 2026 — Qual Modelo Para Que Caso

A escolha do modelo certo depende de 3 factores: VRAM disponível, tipo de tarefa, e qualidade exigida. A Tabela 3.1 lista os 12 modelos mais relevantes em 2026 (Junho 2026).

Tabela 3.1 — 12 Modelos Ollama Mais Relevantes (2026)

Tabela 3.2 — Modelo por Caso de Uso (Recomendações)

3.1 Como carregar e gerir múltiplos modelos

4. Tuning de Performance — Os 8 Parâmetros que Mais Importam

O Ollama tem 15+ parâmetros de runtime que afectam velocidade, qualidade, e uso de VRAM. A Tabela 4.1 lista os 8 mais importantes para sysadmins.

Tabela 4.1 — 8 Parâmetros de Performance Ollama (Mais Usados)

4.1 Modelfile para modelo tuning (exemplo Nemotron 30B)

4.2 Benchmark de performance (script)

5. GPU Passthrough em WSL2 (Windows 11 24H2+)

A combinação Ollama + WSL2 + NVIDIA GPU é a forma mais comum de correr IA local em Windows 11 em 2026 (já coberta em
secção 4). Esta secção detalha o passo-a-passo específico para Ollama.

5.1 Pré-requisitos WSL2 + GPU

1. Windows 11 24H2 ou 25H2 (Build 26100+ / 26200+)
2. Driver NVIDIA Studio ou Game Ready 560+ (NÃO instalar driver NVIDIA dentro da WSL — vem como stub)
3. WSL 2.4+ (verificar com wsl --version)
4. CUDA no WSL (já incluído no driver NVIDIA Windows — NÃO instalar CUDA toolkit dentro da WSL)

Output esperado em WSL2 com GPU funcional:

5.2 Docker Compose com GPU em WSL2

O docker-compose.yml que mostrei na secção 3 do artigo básico já tem suporte GPU. Em WSL2, basta garantir que o NVIDIA Container Toolkit está instalado dentro da WSL (não no Windows host).

5.3 Verificar GPU passthrough dentro do container Ollama

Output esperado (GPU visível dentro do container):

6. HTTPS com Cloudflare Tunnel (Expor Open WebUI com Segurança)

Por default, Open WebUI corre em http://localhost:3000 — sem HTTPS, sem acesso remoto. Para uso pessoal (1 utilizador, mesma LAN), chega. Para equipa remota (5-50 utilizadores, mobile, café), precisa de HTTPS + autenticação forte. A forma mais simples em 2026 é Cloudflare Tunnel (gratuito, sem abrir portas no firewall).

6.1 Porquê Cloudflare Tunnel

6.2 Setup Cloudflare Tunnel (5 passos)

Passo 1: Ter um domínio (e.g. empresa.pt no Cloudflare Registar ou Namecheap).

Passo 2: Instalar cloudflared:

Passo 3: Login e criar tunnel:

Passo 4: Configurar tunnel (~/.cloudflared/config.yml):

Passo 5: Correr tunnel:

6.3 DNS interno para Ollama API (split-horizon)

Se os developers da equipa precisam de aceder à Ollama API (porta 11434) sem passar pelo Open WebUI (para scripts Python, Claude Code, etc.), expõe a API noutro subdomínio:

Proteger a Ollama API com API token (alternativa gratuita):

7. Multi-Utilizador com RBAC (Open WebUI Admin Panel)

O Open WebUI tem RBAC completo desde a versão 0.3+ (Mar 2025). Permite criar grupos, atribuir roles, e controlar acesso por modelo e por knowledge base.

7.1 Configuração inicial (1ª vez)

1. Login como admin (criado automaticamente no 1º signup)
2. Admin Panel → Settings → General:

• Default User Role: user (não admin — promoção manual depois)
• Enable New Sign Ups: false (adicionar manualmente)
• Enable API Key: true (para integrações externas)

1. Admin Panel → Users → Add User — adicionar cada membro da equipa
2. Admin Panel → Groups → Create Group — criar grupos por departamento (e.g. “Developers”, “Suporte”, “Marketing”)

Tabela 7.1 — Roles Open WebUI

7.2 Configurar RBAC por modelo

Para modelos potentes (e.g. Llama 3.3 70B, DeepSeek-R1 70B), restringir o uso a developers ou admins:

1. Admin Panel → Models → seleccionar modelo → Edit
2. Visibility: Private (só vê quem tem permissão)
3. User Groups: seleccionar “Developers” e “Admins”
4. Save

7.3 OAuth com Entra ID (SSO)

Para empresas com Microsoft 365, integrar Open WebUI com Entra ID (Azure AD) para SSO:

1. Azure Portal → Entra ID → App registrations → New registration

• Name: “Open WebUI SSO”
• Redirect URI: https://ai.empresa.pt/oauth/oidc/callback

1. Certificates & secrets → New client secret → guardar
2. API permissions → Microsoft Graph → openid, profile, email, User.Read
3. Open WebUI Admin → Settings → OAuth:

• Provider: OIDC
• URL: https://login.microsoftonline.com/<TENANT_ID>/v2.0
• Client ID: <APPLICATION_ID>
• Client Secret: <CLIENT_SECRET>
• Scope: openid email profile

1. Save → utilizadores M365 podem fazer login com a mesma conta

8. Backup e Recuperação (Modelos + DB + Volumes)

Backup em Ollama+Open WebUI envolve 3 componentes que devem ser tratados separadamente:

Tabela 8.1 — O Que Fazer Backup

8.1 Backup automatizado (script diário)

8.2 Restore (em caso de desastre)

9. Troubleshooting — Os 8 Problemas Mais Comuns

Tabela 9.1 — 8 Problemas + Soluções (PME Ollama + Open WebUI)

9.1 Comandos úteis de diagnóstico

10. Integração com Coding Assistants (Claude Code, Continue.dev, Roo Code)

Uma das aplicações mais populares de Ollama em 2026 é servir como backend para coding assistants locais — evitando enviar código proprietário para APIs pagas.

10.1 Claude Code (Anthropic) com Ollama

O Claude Code (CLI da Anthropic) suporta Ollama como backend via OpenAI-compatible API:

10.2 Continue.dev (VS Code) com Ollama

O Continue.dev é a extensão VS Code open-source mais popular para coding AI. Suporta Ollama nativamente.

Setup (VS Code):

1. Instalar extensão:
   
2. Configurar (~/.continue/config.json):

1. Recarregar VS Code → painel Continue.dev na barra lateral

10.3 Roo Code (fork de Cline) com Ollama

O Roo Code (anteriormente conhecido como Roo Cline, fork do Cline) é outra extensão VS Code open-source com agentic capabilities (pode editar múltiplos ficheiros, correr comandos, etc.).

Setup (similar ao Continue):

1. Instalar
   
2. Configurar API provider: Ollama + Base URL: http://localhost:11434
3. Modelo: qwen2.5-coder:32b (recomendado) ou deepseek-r1:8b (reasoning)

10.4 Outras integrações (resumo)

11. FAQ para Sysadmins e Developers

11.1 Posso correr Ollama sem GPU?

Sim, mas com performance limitada. Em CPU-only, modelos 3B-7B correm a 3-15 tokens/segundo (utilizável para Q&A simples, summarization de documentos curtos). Para modelos 30B+, CPU-only é inutilizável (<1 TPS). Recomendação: GPU dedicada (RTX 3060+ 12GB) ou Apple Silicon M-series (32GB+ RAM unificada, ~30-50% de uma RTX 4090).

11.2 Quantos modelos posso ter instalados simultaneamente?

Ilimitado em disco, mas apenas 1-2 em VRAM ao mesmo tempo. Cada modelo 30B usa ~20-24GB VRAM; uma RTX 4090 (24GB) só carrega 1 modelo grande de cada vez. Ollama descarrega automaticamente modelos não usados para libertar VRAM. Para multi-model serving (vários modelos a responder em paralelo), precisas de 2+ GPUs ou 2+ servidores Ollama com load balancer.

11.3 Ollama substitui o OpenAI API em produção?

Depende do caso de uso. Para Q&A sobre documentos internos, summarization, customer support, coding assist — sim, 80-90% das funcionalidades estão cobertas. Para conhecimento em tempo real (eventos após 2024-2025), multimodal avançado (vídeo, audio longo), ou raciocínio extremo (OpenAI o1, Claude 4 Opus), a cloud ainda é necessária. A estratégia híbrida mais comum em 2026: Ollama para 80% (privacidade, custo, velocidade) + OpenAI/Anthropic API para 20% (reservado para tarefas que exigem cloud).

11.4 Open WebUI é seguro para uso empresarial?

Sim, com configuração adequada. O Open WebUI tem RBAC, OAuth, audit logs, multi-tenancy. Para uso empresarial:

• Desactivar signup público (Admin → Settings → Enable New Sign Ups: false)
• OAuth com Entra ID ou Google Workspace (SSO + MFA)
• HTTPS obrigatório (Cloudflare Tunnel, nginx + certbot)
• Backup diário da DB
• Updates regulares (docker compose pull && docker compose up -d)

Para healthcare, legal, financial: considerar Ollama enterprise (suporte comercial via vendors como
).

11.5 Qual a diferença entre Ollama e LM Studio?

11.6 Ollama corre no macOS Apple Silicon?

Sim, e com performance excelente. Ollama tem Metal API que aproveita a GPU Apple Silicon (M1, M2, M3, M4). Para M3 Max com 64GB RAM unificada, dá para correr Llama 3.3 70B quantizado Q4 (~40GB) com velocidades de 30-50 TPS — comparável a uma RTX 4090. Limitação: não suporta CUDA (NVIDIA-specific features como flash_attention são mais limitados).

11.7 Como migrar de OpenAI API para Ollama?

A OpenAI-compatible API do Ollama permite migrar 95% das aplicações com mudanças mínimas:

11.8 Ollama suporta fine-tuning?

Não directamente, mas Ollama suporta modelos fine-tuned (em formato GGUF). O fine-tuning faz-se com:

• Unsloth (rápido, 2-5x mais rápido que raw Hugging Face)
• Axolotl (config YAML, múltiplos modelos)
• Hugging Face TRL (SFTTrainer, DPOTrainer)
• Llama Factory (GUI web)

Após fine-tuning, converter para GGUF com llama.cpp/convert.py e importar para Ollama via ollama create <name> -f Modelfile. Para PME 25 cols sem equipa de ML, fine-tuning é overkill — RAG (via Open WebUI knowledge bases) resolve 90% dos casos de “fine-tuning” sem treinar nada.

11.9 Posso usar Ollama no telemóvel?

Sim, em Android (via Termux ou Ollama APK) e iOS (apps como
ou
). Em iPhone 15 Pro (A17 Pro, 8GB RAM), dá para correr Llama 3.1 8B Q4 (~5GB) com 8-12 TPS — utilizável para Q&A simples. Em Android high-end (Snapdragon 8 Gen 3), similar. Para uso sério, desktop/workstation com GPU continua a ser o caminho.

11.10 Ollama é a única opção para IA local?

Não. Alternativas em 2026:

• vLLM — servidor de inferência production-grade (Python, requer GPU)
• llama.cpp — base C++ do Ollama; correr directamente via CLI
• TGI (Text Generation Inference) — Hugging Face, production-ready
• LocalAI — drop-in replacement OpenAI API, multi-modelo (audio, image, embeddings)
• LM Studio — GUI desktop
• Jan (ex-Open WebUI desktop) — Electron app similar ao ChatGPT desktop

Para sysadmins: Ollama + Open WebUI é a combinação mais equilibrada em 2026. Para production-grade com SLA: vLLM ou TGI. Para experimentação single-user: LM Studio ou Jan.

12. Outras Causas Comuns de Problemas em Operação

Causa 1 — Instalar driver NVIDIA dentro da WSL. Erro clássico — ao instalar o driver .run da NVIDIA dentro da WSL, substitui-se o stub que o Windows driver criou, e o passthrough GPU deixa de funcionar. Solução: NUNCA instalar driver NVIDIA dentro da WSL — o driver do Windows host já fornece o suporte. Se já instalou, nvidia-smi dentro da WSL mostra versão errada; reinstalar WSL é a forma mais rápida de recuperar.

Causa 2 — Usar localhost no OLLAMA_BASE_URL em vez de ollama. No docker-compose.yml, o OLLAMA_BASE_URL=http://localhost:11434 faz o Open WebUI procurar Ollama no próprio container (onde não está). Solução: usar http://ollama:11434 (nome do serviço) — Docker resolve para o IP interno do container Ollama.

Causa 3 — Carregar modelos grandes demais para VRAM. Ollama 0.5+ não aborta imediatamente — fica em OOM loop (tenta alocar, falha, recomeça). Solução: monitorizar nvidia-smi durante o primeiro ollama run; se vir 100% memória, usar versão quantizada (q4_K_M em vez de q8_0) ou modelo menor.

Causa 4 — Esquecer de configurar GPU no docker-compose. Mesmo com GPU disponível, se o docker-compose.yml não tiver deploy.resources.reservations.devices, Ollama corre em CPU. Solução: adicionar o bloco deploy.resources com driver: nvidia e count: all.

Causa 5 — Backup manual sem automatizar. O primeiro backup corre; os próximos são esquecidos. Solução: cron job diário (secção 8.1) + alertas Slack/email se backup falhar (script wrapper com if [ $? -ne 0 ]; then curl -X POST <webhook>; fi (snippet bash testado em Ubuntu 24.04)).

Causa 6 — Não actualizar modelos. Modelos evoluem mensalmente (Qwen 2.5 → Qwen 3, Llama 3.3 → Llama 4 em 2027). Solução: subscrever
e fazer ollama pull semanal.

Causa 7 — Confundir “ollama create” com “ollama pull”. ollama pull descarrega um modelo da library oficial. ollama create cria um modelo customizado a partir de um Modelfile local (não descarrega nada da internet). São comandos diferentes para operações diferentes.

Causa 8 — Subestimar o storage. 12 modelos × 20GB média = 240GB de modelos, mais DB (10GB), mais knowledge bases (50GB) = 300GB facilmente. Solução: 1TB SSD mínimo para Ollama server; 2TB+ se quiser manter histórico de modelos antigos.

13. Como Evitar Problemas — Boas-Práticas de Operação

1. Monitorizar VRAM e disco. Usar Prometheus + Grafana ou Netdata para dashboards de nvidia-smi, du -sh ~/.ollama, docker stats. Alertar se VRAM >90% ou disco >80%.

2. Taggar modelos por ambiente. ollama pull qwen2.5-coder:7b puxa a latest. Para ambientes production, usar tags fixas (qwen2.5-coder:7b-v1.0) e documentar a versão. Evitar surpresas com breaking changes.

3. Limitar num_parallel em produção. Default Ollama aceita 1 request paralelo. Para 5+ utilizadores, configurar num_parallel 4 (no Modelfile ou env var OLLAMA_NUM_PARALLEL=4) — mas monitorizar VRAM.

4. Versionar Modelfile e docker-compose em Git. git init na pasta ~/ollama-webui/, commit de docker-compose.yml, Modelfile, e configs. Facilita rollback e auditoria.

5. Testar updates em staging antes de produção. docker compose pull numa VM de staging, testar 24h, depois promover. Ollama evolui rapidamente e breaking changes são comuns entre minor versions.

6. Documentar troubleshooting no wiki interno. Equipa de TI/suppport deve ter runbook com os 8 problemas comuns (secção 9) + soluções. Reduz MTTR (Mean Time To Repair).

7. Plano de disaster recovery testado. Backup é inútil se restore não foi testado. Trimestralmente, simular disaster: parar containers, restaurar de backup, validar modelos e DB.

8. Acompanhar Ollama releases e Hugging Face trends. Ollama releases mensais; novos modelos top saem quase semanalmente. Subscrever
e
para trend awareness.

14. Anexos

Anexo A — Quick Reference: Comandos Ollama Essenciais

Anexo B — Quick Reference: Open WebUI Admin

Anexo C — Contactos e Recursos Úteis

Anexo D — Glossário de Siglas