Resumo

Este artigo é a segunda parte da série "O Maestro", que documenta a implantação de um orquestrador de inteligência artificial em ambiente corporativo. A Parte 1 identificou o problema: o uso fragmentado de ferramentas de IA, sem governança, sem controle de custos e sem registro centralizado. Esta parte descreve o que foi feito a seguir. Apresenta-se a avaliação de três cenários arquiteturais distintos: a execução de modelos locais no hardware da empresa, a construção de um cluster distribuído e a adoção de um proxy centralizado com APIs externas. A análise revela que os dois primeiros cenários, embora tecnicamente viáveis, apresentam barreiras significativas de custo operacional, complexidade de manutenção e qualidade percebida pelos usuários. O terceiro cenário — que combina LiteLLM como gateway e Open WebUI como interface, executados em contêineres Docker sobre hardware reutilizado — mostrou-se a abordagem mais adequada ao contexto. A arquitetura resultante é composta por cinco serviços containerizados: Caddy (reverse proxy), Open WebUI (interface), LiteLLM (gateway), PostgreSQL (banco de dados) e Redis (cache). Detalham-se as decisões sobre cardápio de modelos, nomenclatura, prompt caching, segurança, conformidade com a LGPD e especificações de hardware. Por fim, descreve-se o plano de implantação faseado em sete etapas, concebido para validar custos reais antes de expor a ferramenta a toda a base de usuários.

Palavras-chave: LiteLLM; Open WebUI; Docker; arquitetura de IA; prompt caching; infraestrutura.

1. Introdução

Este artigo é a Parte 2 de uma série denominada "O Maestro". A Parte 1 documentou o problema que motivou o projeto: o uso fragmentado de inteligência artificial por aproximadamente 120 colaboradores, sem padronização, sem controle de custos e sem registro centralizado das interações. Identificou-se que colaboradores utilizavam diferentes ferramentas com credenciais individuais ou compartilhadas, inserindo dados corporativos em plataformas externas sem qualquer política de segurança — um cenário típico de adoção bottom-up que gera riscos organizacionais crescentes.

Com o problema diagnosticado, o passo seguinte foi avaliar as alternativas disponíveis e tomar decisões arquiteturais. Este artigo descreve esse processo, com atenção especial às razões que levaram à escolha de cada componente e às implicações práticas dessas decisões.

Cabe destacar um aspecto metodológico relevante: a própria inteligência artificial desempenhou papel central na fase de planejamento. O Claude (Anthropic) foi utilizado como ferramenta de apoio técnico para análise de viabilidade de hardware, comparação de alternativas e simulação de cenários de implantação. Essa abordagem — usar IA para planejar a infraestrutura de IA — ilustra o potencial dessas ferramentas como assistentes de decisão técnica, acelerando processos e pesquisas que, de outra forma, demandariam semanas de levantamento manual.

2. Avaliação de alternativas

2.1 Cenário A: Execução de modelos locais (on-premises)

A primeira alternativa — e a mais ambiciosa — consistia na execução de modelos de linguagem diretamente no hardware da empresa, eliminando por completo a dependência de APIs externas. Essa abordagem ofereceria máximo controle sobre os dados e custo operacional reduzido a longo prazo.

Para avaliar sua viabilidade, foi realizado um levantamento do hardware disponível. A empresa dispunha de GPUs (Graphics Processing Units, unidades de processamento gráfico) remanescentes de estações de trabalho do setor de design, entre elas unidades GTX 1650 (4 GB de VRAM, memória dedicada da GPU) e modelos mais antigos como a GT 750 (2 GB de VRAM).

A análise revelou limitações significativas. A GTX 1650, embora suportada pelo Ollama (ferramenta para execução de modelos locais) e por CUDA (plataforma de computação paralela da NVIDIA), limitava a execução a modelos quantizados (comprimidos) de até 7 bilhões de parâmetros, com desempenho estimado entre 6 e 10 tokens por segundo (SOWMIYAN, 2025). Esse desempenho, aceitável para uso individual, mostra-se insuficiente para atender múltiplos usuários simultâneos em ambiente corporativo. Benchmarks independentes confirmam que GPUs com 4 GB de VRAM operam no limite inferior de viabilidade para esses modelos, exigindo compressão agressiva que compromete a qualidade das respostas (MYAIHARDWARE, 2026). As GPUs mais antigas, como a GT 750, não são sequer compatíveis com versões atuais do Ollama.

A possibilidade de combinar múltiplas GPUs para somar capacidade foi também avaliada. Ferramentas como o llama.cpp permitem dividir camadas de um modelo entre GPUs distintas (GGML-ORG, 2026), e estudos recentes demonstram que configurações multi-GPU com hardware modesto podem proporcionar ganhos de 3x a 4x em velocidade de inferência (JAGUSZTINL, 2026). Duas GTX 1650 combinariam aproximadamente 8 GB de VRAM, viabilizando modelos maiores. Contudo, essa configuração exigiria investimentos em expansão física — risers PCIe, placas-mãe com múltiplos slots e estruturas de ventilação adequadas — além de aumentar significativamente a complexidade de manutenção.

Um fator determinante foi o alinhamento de expectativas com os usuários. Modelos locais de 7 bilhões de parâmetros, embora funcionais, não equivalem em qualidade aos modelos de fronteira como GPT-4, Claude ou Gemini, que os colaboradores já utilizavam. A introdução de modelos com qualidade perceptivelmente inferior poderia comprometer a adoção da ferramenta.

2.2 Cenário B: Infraestrutura distribuída (cluster de nós)

Uma segunda alternativa explorada foi a construção de um cluster distribuído, no qual cada máquina reutilizada atuaria como um nó especializado — nós de texto (com Ollama), nós de imagem (com Stable Diffusion) — coordenados por um orquestrador central.

Esse cenário, embora tecnicamente viável, apresentava desafios operacionais significativos. Para atender um pico de aproximadamente 30 usuários simultâneos, a estimativa demandaria entre 2 e 3 nós dedicados a texto, 4 a 6 nós para geração de imagens. O custo energético de 6 a 8 máquinas em operação contínua foi estimado entre R$ 800 e R$ 1.500 mensais. Além disso, a utilização de hardware antigo aumenta a probabilidade de falhas, exigindo mecanismos de recuperação automática e dedicação considerável de tempo para manutenção — um custo oculto que recairia sobre a liderança técnica.

O overhead (sobrecarga) introduzido pelas camadas de abstração também foi considerado: medições independentes indicam que o Ollama adiciona aproximadamente 10% de sobrecarga sobre o llama.cpp puro (INVENTIVEHQ, 2026), fator relevante quando o hardware já opera próximo ao limite de sua capacidade.

A Parte 1 desta série também mencionou a compatibilidade do Stable Diffusion 1.5 com GPUs de 4 GB de VRAM para geração de imagens (WILLITRUNAI, 2026), embora modelos mais recentes como o SDXL exijam 12 a 16 GB mínimos (HIVENET, 2026). Essa possibilidade foi considerada neste cenário, mas não justificou por si só a complexidade de um cluster.

2.3 Cenário C: Proxy centralizado com APIs externas (solução adotada)

Diante das limitações dos cenários anteriores, optou-se por um modelo que prioriza a governança e a centralização de acesso sem a complexidade de executar modelos localmente. Nessa abordagem, o servidor local atua exclusivamente como proxy e interface unificada, roteando as requisições dos usuários para provedores externos por meio do LiteLLM.

Essa decisão foi motivada por três fatores:

1. Qualidade dos modelos: os colaboradores continuam acessando modelos de fronteira sem regressão na experiência de uso, preservando a familiaridade já estabelecida.

2. Simplicidade operacional: o servidor precisa apenas processar requisições HTTP e manter o banco de dados, funções compatíveis com hardware modesto.

3. Velocidade de implantação: a configuração de LiteLLM + Open WebUI em Docker pode ser realizada em horas, enquanto a montagem de um cluster de inferência local demandaria semanas.

A abordagem não elimina a dependência de provedores externos nem seus custos de API, mas centraliza o controle de chaves, orçamentos e logs em um único ponto, resolvendo os problemas de governança que motivaram o projeto. A possibilidade de integrar modelos locais futuramente permanece aberta, uma vez que o LiteLLM suporta provedores locais como Ollama de forma nativa.

A escolha do Open WebUI como interface foi reforçada por sua maturidade — mais de 290 milhões de pulls no Docker Hub e 140 mil estrelas no GitHub —, além do suporte nativo a autenticação multi-usuário com três níveis de papel (administrador, usuário e pendente), isolamento de conversas por usuário e sistema de plugins para controle de taxa de uso e monitoramento de consumo (AIMOJO, 2026; GLUKHOV, 2026; SIDER.AI, 2025).

3. Arquitetura da solução

3.1 Os cinco serviços e suas responsabilidades

A arquitetura definida para "O Maestro" é composta por cinco serviços containerizados, organizados em camadas com responsabilidades bem definidas:

Nenhuma porta além da 80 e 443 é exposta ao exterior. Toda comunicação entre serviços ocorre na rede interna do Docker, e o acesso administrativo ao LiteLLM (porta 4000) é restrito ao loopback do servidor — acessível remotamente apenas por túnel SSH (protocolo de acesso remoto seguro).

3.2 Fluxo de requisições

O fluxo de dados segue uma cadeia linear. O usuário acessa a interface via navegador (HTTPS), o Caddy encaminha a requisição ao Open WebUI, que por sua vez se comunica com o LiteLLM usando o formato de API compatível com OpenAI. O LiteLLM roteia a requisição para o provedor adequado conforme o modelo selecionado pelo usuário, registra o consumo no PostgreSQL e utiliza o Redis para cache e controle de taxa.

A resposta retorna em streaming via Server-Sent Events (SSE) — uma técnica que permite ao servidor enviar dados progressivamente, à medida que são gerados. Esse mecanismo exige que o reverse proxy seja configurado com buffering (armazenamento temporário) desligado e timeout longo (600 segundos) para evitar o truncamento prematuro de respostas longas.

3.3 Cardápio de modelos e decisões de nomenclatura

O planejamento inicial previa a organização dos modelos em três tiers de custo — "Econômico", "Equilibrado" e "Potente" —, com nomes amigáveis que orientariam a escolha do usuário de forma consciente. Durante a implantação, porém, essa abordagem foi revista por razões práticas.

Com a entrada de múltiplos provedores (Google Gemini, HuggingFace e, futuramente, Anthropic e OpenAI), o apelido de tier deixa de ser informativo: "Potente" não diz ao usuário se está usando Claude Opus, GPT-4 ou Gemini Pro. Decidiu-se, portanto, adotar o nome real de cada modelo como identificador no Open WebUI. Essa decisão tem uma contrapartida operacional: nomes com espaços (como "Gemini 3.5 Flash") quebram comandos de shell que iterem por espaço — problema que precisou ser contornado com aspas e o operador while IFS= read -r nos scripts de validação.

A ausência de fallback (substituição automática) entre modelos diferentes é intencional: se um modelo estiver indisponível, o sistema retorna erro explícito em vez de substituí-lo silenciosamente. Essa escolha preserva a confiança do usuário na ferramenta.

3.4 Prompt caching

O prompt caching (reutilização de partes repetidas de um prompt) foi definido como obrigatório desde o primeiro dia de operação. Em conversas de chat, todo o histórico anterior é reenviado ao provedor a cada novo turno. Com o cache ativo, o trecho repetido é reutilizado em vez de reprocessado, reduzindo significativamente o consumo de tokens de entrada.

O ponto de equilíbrio ocorre em apenas duas requisições, tornando o recurso vantajoso em praticamente qualquer cenário de uso conversacional. Para o modelo Anthropic, por exemplo, o preço de leitura em cache é de aproximadamente 0,1× do preço normal de entrada, com escrita de 1,25×. Vale notar que a maioria dos provedores alternativos — como Groq, Together AI e equivalentes — não oferece prompt caching. Um modelo três vezes mais barato sem cache pode, em conversas longas, superar o custo de um modelo mais caro com cache: o ganho real dos alternativos está em tarefas de turno único.

3.5 Segurança e LGPD

A arquitetura contempla preocupações de segurança e conformidade com a Lei Geral de Proteção de Dados (LGPD). Todas as chaves de API (credenciais de acesso aos provedores) são armazenadas em arquivo .env com permissão restrita, nunca versionado em repositório Git. Uma chave-mestra gerada aleatoriamente protege o acesso administrativo ao LiteLLM, enquanto chaves virtuais com orçamento definido são distribuídas por equipe.

Um ponto crítico identificado durante a implantação: se o Open WebUI se autentica no LiteLLM com a master key — que é ilimitada por definição —, todo orçamento configurado torna-se inoperante. O bloqueio por gasto só funciona quando o Open WebUI utiliza uma chave virtual com teto definido. Essa distinção entre "orçamento configurado" e "orçamento aplicado" é sutil, mas fundamental para o controle de custos.

Do ponto de vista da LGPD, os prompts dos usuários trafegam para servidores de provedores nos Estados Unidos, configurando transferência internacional de dados. O plano prevê a contratação de termos empresariais com os provedores — modalidade que garante que os dados enviados não serão utilizados para treinamento de modelos — e a definição de política de retenção de histórico com procedimento documentado para eliminação de dados a pedido do titular.

3.6 Hardware do servidor

Todos os componentes são executados em contêineres Docker sobre um servidor reutilizado com as seguintes especificações ao término da fase de configuração:

O processador, embora modesto, é adequado: como todo o processamento de inferência ocorre na nuvem, o servidor local é essencialmente um proxy I/O-bound — orquestra, autentica, registra e roteia, mas não executa modelos. A adição de um no-break foi identificada como obrigatória para evitar corrupção do banco de dados PostgreSQL em caso de queda de energia.

4. Plano de implantação

O plano de execução define uma abordagem faseada para a implantação, refletindo a preocupação em validar custos e estabilidade antes de expor a ferramenta a todos os colaboradores:

1. Fase 0 — Pré-requisitos: confirmação de chaves de API (credenciais de acesso pagas aos provedores, diferentes de assinaturas de produtos), verificação de limites de taxa (rate limits) nos provedores, registro de DNS interno e configuração de afinidade de sessão no balanceador de links da empresa.

2. Fase 1 — Preparação do servidor: instalação do Ubuntu Server 24.04 LTS, Docker CE do repositório oficial e configuração de firewall (apenas portas 22, 80 e 443).

3. Fase 2 — Configuração: criação dos arquivos de configuração (.env, docker-compose.yml, config.yaml, Caddyfile) e do script de inicialização do banco de dados.

4. Fase 3 — Subida dos serviços: execução do Docker Compose e validação de que todos os contêineres estão operacionais.

5. Fase 4 — Validação técnica: checklist de testes que inclui verificação de HTTPS, bloqueio de portas internas, funcionamento dos modelos cadastrados, teste de prompt caching, teste de bloqueio por orçamento e teste de failover de link.

6. Fase 5 — Piloto: liberação para 10 usuários representativos por duas semanas, com medição de custo real por usuário/dia, distribuição de uso entre modelos e taxa de acerto do cache. Os dados do piloto são extrapolados para 120 usuários e comparados com o orçamento aprovado antes de prosseguir.

7. Fase 6 — Rollout: liberação em ondas (30 → 60 → 120 usuários), com monitoramento de limites de taxa a cada onda e comunicado interno explicando o funcionamento da ferramenta.

Essa abordagem gradual é fundamentada na imprevisibilidade dos custos de API: sem medição real, é impossível estimar com confiança o consumo de uma base de 120 usuários. Somente os dados do piloto permitem definir orçamentos confiáveis e ajustar o roteamento entre modelos antes do rollout completo.

5. Conclusão

Esta segunda parte da série "O Maestro" apresentou a avaliação de três cenários arquiteturais e as razões que levaram à escolha do proxy centralizado com APIs externas. A análise demonstrou que a execução de modelos locais e a construção de um cluster distribuído, embora tecnicamente possíveis, apresentavam barreiras que os tornavam inadequados ao contexto: custo energético elevado, complexidade de manutenção e qualidade de respostas aquém das expectativas dos usuários.

A arquitetura escolhida — cinco serviços containerizados em Docker sobre hardware reutilizado — mostrou-se ao mesmo tempo simples de implantar e robusta o suficiente para as necessidades da organização. As decisões sobre cardápio de modelos, nomenclatura, prompt caching e segurança foram documentadas com as justificativas que as motivaram, incluindo as que se mostraram mais complexas do que o esperado.

O plano de implantação em sete fases reflete a cautela necessária diante de um serviço cujos custos de operação dependem do comportamento real dos usuários — um dado que não pode ser estimado sem medição empírica.

A Parte 3 desta série documenta o que aconteceu quando esse plano foi colocado em prática: os problemas encontrados entre a primeira linha de comando executada e a obtenção da primeira resposta real de um modelo de linguagem, em 7 de agosto de 2026.