OrionisOrionis
Voltar ao blog
Artigos2025-03-1518 min

Por que sua empresa deveria considerar LLMs on-premise em 2025

JPL

José Pedro Lecha

2025-03-15

As regulações de governança de dados estão endurecendo em toda a América Latina. Explicamos quando faz sentido rodar modelos de linguagem na sua própria infraestrutura, quando é jogar dinheiro fora, e qual stack técnico você precisa para fazer isso direito.

O contexto regulatório: por que isso já não é opcional

Nos últimos 18 meses, o cenário regulatório na América Latina mudou radicalmente. A Argentina avançou com a regulamentação da Lei de Proteção de Dados Pessoais, o Brasil endureceu a LGPD com sanções que já ultrapassaram R$50 milhões em multas acumuladas, e o México atualizou sua Ley Federal de Protección de Datos com diretrizes específicas para inteligência artificial. Colômbia e Chile estão seguindo o mesmo caminho.

Para uma empresa de 200 pessoas no setor financeiro ou de saúde, isso tem implicações diretas: cada vez que um funcionário cola dados de um cliente no ChatGPT ou seu sistema envia informações sensíveis para a API da OpenAI, você está potencialmente violando regulações locais. Não é paranoia — é o marco legal vigente.

O problema não é que as APIs da OpenAI, Anthropic ou Google sejam inseguras. O problema é que você não controla onde os dados são processados, quem acessa eles, nem como são retidos. E para um regulador, isso é suficiente para considerar uma transferência internacional de dados não autorizada.

A tendência é clara: a soberania de dados deixou de ser um tema de compliance para se tornar um requisito operacional. As empresas que não se adaptarem vão perder contratos, enfrentar multas, ou simplesmente ficar de fora de licitações públicas e privadas.

O que significa 'on-premise' em 2025 (não é o que você pensa)

Quando falamos 'on-premise' muitos CTOs imaginam um rack de servidores no porão do escritório, com um cara de TI trocando discos às 3 da manhã. Essa imagem está desatualizada.

On-premise em 2025 tem três modalidades reais. Primeira: nuvem privada com isolamento — um VPC dedicado na AWS, GCP ou Azure com políticas de rede que garantem que os dados nunca saem da região. Segunda: bare metal em datacenter local — servidores dedicados em um datacenter como Equinix, EdgeUno ou DataCenter Paraguay, onde você tem controle físico do hardware. Terceira: hardware próprio — GPUs na sua infraestrutura existente, ideal para empresas grandes que já têm capacidade de computação.

O que importa em qualquer um dos três casos é o mesmo: os dados nunca cruzam um perímetro que você não controla. Você decide qual modelo roda, quais logs são guardados, quem acessa, e por quanto tempo a informação é retida. Isso é soberania de dados real, não marketing.

Um detalhe que muitos deixam passar: on-premise não significa desconectado. Você pode ter um deployment on-premise que se atualiza com modelos novos periodicamente, que reporta métricas de uso (sem dados sensíveis) para um dashboard central, e que escala automaticamente conforme a demanda. A experiência do usuário final pode ser idêntica a usar uma API externa.

Os modelos open-source que já competem com o GPT-4

O ecossistema de modelos open-source explodiu em 2024-2025. Já não estamos falando de modelos medíocres que dão respostas genéricas — existem opções que competem seriamente com os modelos fechados em tarefas específicas.

Llama 3.1 405B da Meta é o mais impressionante em termos de capacidade geral. Para a maioria das tarefas empresariais — resumo de documentos, classificação, extração de entidades, geração de relatórios — rende no mesmo nível do GPT-4. A versão de 70B é excelente para produção com hardware mais acessível, e a de 8B é surpreendentemente capaz para tarefas simples com latência mínima.

Mistral Large e Mixtral 8x22B são opções europeias com excelente performance em espanhol e português, algo crítico para o mercado LATAM. Qwen 2.5 da Alibaba surpreendeu a todos com sua capacidade multilíngue e eficiência em hardware limitado. E DeepSeek V3 demonstrou que é possível alcançar performance de frontier com arquiteturas mais eficientes.

O ponto-chave é que para 80% dos casos de uso empresariais — que não exigem raciocínio complexo de frontier — esses modelos são mais que suficientes. E podem rodar na sua infraestrutura sem pagar por token.

80% dos casos de uso empresariais não exigem modelos frontier. Os modelos open-source como Llama 3.1 e Mistral já competem com o GPT-4 em tarefas como resumo, classificação e extração de entidades.

Comparação real de custos: API vs. on-premise

Vamos fazer as contas com um caso real. Uma empresa de serviços financeiros com 150 funcionários que usa LLMs para analisar documentos jurídicos, gerar relatórios de compliance, e auxiliar no atendimento ao cliente.

Com APIs externas (GPT-4o): processam aproximadamente 2 milhões de tokens de entrada e 500K de saída por dia. A preços atuais da OpenAI, isso dá ~USD 25/dia em input e ~USD 7,50 em output. Uns USD 975/mês. Parece barato, né? Mas some: USD 200/mês em ferramentas de orquestração, USD 150 em logging e monitoramento externo, e o custo oculto de latência variável que afeta a experiência do usuário. Total real: ~USD 1.400/mês.

Com on-premise (Llama 3.1 70B em 2x NVIDIA A100): o custo das GPUs em leasing é de aproximadamente USD 3.500/mês. Some USD 500 de infraestrutura de suporte (rede, storage, energia) e USD 300 de manutenção. Total: ~USD 4.300/mês. Mas esse custo é fixo — não importa se você processa 2M de tokens ou 20M.

O breakeven está em aproximadamente 6-8 milhões de tokens diários. Se sua empresa vai escalar o uso de AI (e todas fazem isso), o on-premise se torna mais barato em 6-12 meses. Além disso, você elimina a dependência de preços que mudam sem aviso — a OpenAI já subiu e baixou preços várias vezes.

Existe um terceiro custo que ninguém coloca na planilha: o custo de um incidente de dados. Um vazamento de dados de clientes processados por uma API externa pode custar milhões em multas e reputação. O on-premise reduz esse risco drasticamente.

O breakeven entre API e on-premise está em 6-8 milhões de tokens diários. Se sua empresa vai escalar o uso de AI, o on-premise se torna mais barato em 6-12 meses.

Comparação de custos: API externa vs. On-Premise

API externa (GPT-4o)

~USD 1.400/mês — custo variável por token, latência variável, dependência de preços do provedor

On-premise (Llama 3.1 70B)

~USD 4.300/mês — custo fixo independente do volume, sem limites de tokens, controle total

Breakeven

6-8M tokens/dia — a partir desse volume o on-premise é mais econômico

Custo oculto

Incidente de dados com API externa: multas de milhões + dano reputacional

Casos por indústria: onde o on-premise é imprescindível

Fintech e bancos: os bancos e fintechs da região já estão usando LLMs para análise de risco de crédito, detecção de fraude em tempo real, e geração automática de relatórios regulatórios. Um banco de médio porte na Argentina que implementou Llama 3 on-premise para análise de solicitações de crédito reduziu o tempo de avaliação de 48 horas para 15 minutos, processando dados do BCRA, Veraz e documentação interna sem que nada saísse da sua rede. O regulador aprovou justamente porque os dados nunca saem do perímetro.

Saúde: hospitais e planos de saúde processam prontuários, exames laboratoriais e imagens médicas com dados extremamente sensíveis. Uma rede de clínicas no Uruguai implementou Mistral para gerar resumos de prontuários e alertas de interações medicamentosas. Tudo roda em um cluster dedicado dentro do datacenter deles, cumprindo a Lei de Proteção de Dados de Saúde local.

Jurídico: escritórios de advocacia e áreas jurídicas corporativas lidam com contratos, litígios e documentação confidencial. Um escritório grande de Buenos Aires usa Llama 3 para revisar contratos e detectar cláusulas problemáticas. Processam mais de 500 contratos por mês sem que um único byte saia da infraestrutura deles.

Energia e mineração: empresas com operações em locais remotos onde a conectividade é intermitente. Um on-premise garante que os modelos continuam funcionando mesmo se cair o link de internet.

O stack técnico: o que você realmente precisa

Vamos ser concretos sobre o stack. Para um deployment de produção do Llama 3.1 70B você precisa no mínimo de 2x NVIDIA A100 80GB ou equivalente (as H100 são melhores mas mais caras e difíceis de conseguir na região). Para o modelo de 8B, uma única A10G ou até uma RTX 4090 é suficiente.

Na camada de inferência usamos vLLM como servidor de inferência — é o padrão de facto para serving de LLMs em produção. Suporta batching contínuo, PagedAttention para uso eficiente de memória, e é compatível com a API da OpenAI, o que facilita a migração. Como alternativa, TGI da HuggingFace também é sólido.

Para orquestração, LangChain ou LlamaIndex se você precisa de RAG (Retrieval-Augmented Generation), que é o caso mais comum em empresas. O vector store pode ser Qdrant, Weaviate ou pgvector se você já usa PostgreSQL.

Monitoramento com Prometheus + Grafana para métricas de inferência (latência, throughput, uso de GPU, queue depth). LangSmith ou Langfuse para observabilidade das cadeias de LLM — traces, avaliação de qualidade, detecção de alucinações.

Tudo isso roda sobre Kubernetes (EKS, GKE ou k3s on-premise) com Helm charts que nós mantemos e versionamos. A equipe interna recebe documentação completa e capacitação para operar o cluster.

Stack técnico para LLMs on-premise

Hardware

2x NVIDIA A100 80GB (ou H100) — GPUs dedicadas para inferência

Inferência

vLLM — servidor com batching contínuo, PagedAttention, API compatível com OpenAI

Orquestração + RAG

LangChain / LlamaIndex + vector store (Qdrant, Weaviate ou pgvector)

Observabilidade

Prometheus + Grafana (métricas de GPU) + LangSmith/Langfuse (traces de LLM)

Plataforma

Kubernetes (EKS, GKE ou k3s) com Helm charts versionados

Quando NÃO faz sentido ir on-premise

Vou ser direto: para muitas empresas, o on-premise é uma má ideia. E parte do nosso trabalho é dizer isso quando é o caso.

Se sua empresa tem menos de 50 pessoas e não está num setor regulado, as APIs externas são quase sempre a melhor opção. O custo de infraestrutura, o overhead de manutenção, e a velocidade de iteração que você perde não se justificam. Use GPT-4o ou Claude através das APIs, implemente controles básicos de DLP (Data Loss Prevention), e pronto.

Se seu caso de uso é experimental — você está testando se AI pode melhorar um processo mas ainda não tem volume real — comece com APIs. Valide o caso de uso, meça o ROI, e quando tiver certeza de que funciona e o volume justifica, migre para on-premise.

Se você não tem uma equipe de infraestrutura (nem que seja uma pessoa) que possa monitorar o deployment, não vá para on-premise sem um contrato de suporte. Os modelos precisam de atualizações, as GPUs precisam de monitoramento, e os pipelines precisam de manutenção.

Também não faz sentido se seu caso de uso exige o último modelo de frontier constantemente. Se você precisa sempre da última versão do GPT ou Claude assim que sai, o on-premise vai te deixar sempre um passo atrás. Mas sejamos honestos: a maioria dos casos empresariais não precisa de frontier.

O caminho híbrido: o melhor dos dois mundos

A realidade é que a maioria dos nossos clientes acaba com uma arquitetura híbrida. Não é tudo on-premise nem tudo API — é uma combinação inteligente segundo o tipo de dado e o caso de uso.

O padrão que mais implementamos: dados sensíveis (informações de clientes, dados financeiros, prontuários médicos) são processados exclusivamente com o modelo on-premise. Dados não sensíveis (conteúdo de marketing, análise de tendências públicas, geração de documentação interna genérica) vão para APIs externas onde a latência é menor e os modelos são mais potentes.

Isso exige um router inteligente que classifique as requisições conforme sua sensibilidade e as direcione para o modelo apropriado. Parece complexo, mas com uma boa arquitetura de gateway se resolve em uma semana de implementação.

O benefício é claro: você cumpre as regulações onde importa, aproveita a potência dos modelos fechados onde pode, e otimiza custos. Um cliente nosso no setor de seguros reduziu seu gasto total em AI em 40% com essa abordagem, ao mesmo tempo que melhorou sua postura de compliance.

A arquitetura híbrida é o padrão mais adotado: dados sensíveis vão para o modelo on-premise, dados não sensíveis vão para APIs externas. Um router inteligente classifica e direciona cada requisição.

Arquitetura híbrida: roteamento inteligente de requisições

Requisição entrante

O usuário ou sistema gera uma consulta que envolve dados

Classificador de sensibilidade

Gateway que analisa o conteúdo e determina se contém dados regulados

Rota sensível → LLM on-premise

Dados financeiros, clínicos ou pessoais são processados localmente (Llama 3.1)

Rota não sensível → API externa

Conteúdo de marketing, análises públicas vão para GPT-4o ou Claude

Resposta unificada

O resultado é entregue ao usuário sem distinção do modelo de origem

Como começar: o processo que seguimos na Orionis

Se você está avaliando ir on-premise, este é o processo que seguimos com cada cliente. Não é um pitch de vendas — é a metodologia que realmente usamos.

Semana 1-2: Diagnóstico. Auditamos seus fluxos de dados atuais, identificamos qual informação é regulada, mapeamos os casos de uso de AI existentes e potenciais, e avaliamos sua infraestrutura. Entregamos um documento de viabilidade com recomendações claras.

Semana 3-4: Proof of Concept. Montamos um deployment em um ambiente de staging com dados anonimizados. Testamos o modelo selecionado com seus casos de uso reais e medimos performance, latência e qualidade de respostas comparado com a API que você esteja usando atualmente.

Semana 5-8: Deployment em produção. Configuramos o stack completo — inferência, RAG se aplicável, monitoramento, alertas, backups, e políticas de segurança. Integramos com seus sistemas existentes via API compatível com OpenAI.

Semana 9-12: Transferência e estabilização. Capacitamos sua equipe, documentamos tudo, e fazemos suporte ativo enquanto o sistema se estabiliza em produção.

Após o deployment, oferecemos um contrato de suporte contínuo que inclui atualizações de modelos, monitoramento proativo, e consultoria para novos casos de uso. Mas o importante é que se você decidir prescindir de nós, tem tudo o necessário para operar de forma autônoma. O código, a configuração e o conhecimento são seus.

Processo de implementação on-premise

Fase 1: Diagnóstico (Semana 1-2)

Auditoria de fluxos de dados, avaliação de infraestrutura, documento de viabilidade

Fase 2: Proof of Concept (Semana 3-4)

Deployment em staging, testes com dados anonimizados, benchmarks vs. API atual

Fase 3: Produção (Semana 5-8)

Stack completo: inferência, RAG, monitoramento, alertas, integração com sistemas

Fase 4: Transferência (Semana 9-12)

Capacitação da equipe, documentação, suporte ativo, autonomia operacional

A pergunta que você deveria se fazer

Não é 'devo ir on-premise?'. A pergunta certa é: 'o que acontece com meus dados quando os envio para uma API externa, e consigo conviver com essa resposta?'.

Se a resposta é 'não tenho certeza', você precisa investigar. Se a resposta é 'não posso me dar ao luxo desse risco', você precisa de um plano. E se a resposta é 'meu regulador vai me perguntar isso', você precisa agir agora.

Os modelos open-source alcançaram um nível de maturidade que torna viável o on-premise para empresas de médio porte. O hardware é acessível. O stack técnico está maduro. E a regulação vai continuar endurecendo. As empresas que se moverem agora vão ter uma vantagem competitiva real — não só em compliance, mas na capacidade de personalizar e controlar seus modelos de AI.

Se quiser avaliar seu caso específico, escreva para [email protected]. Fazemos um diagnóstico inicial sem custo onde dizemos com honestidade se o on-premise faz sentido para sua empresa ou se você está melhor com APIs externas. Nosso compromisso é te dar a melhor recomendação, mesmo que isso signifique que não trabalhemos juntos.

Compartir:
Próximo passo

Tem um processopara automatizar?

Responda 5 perguntas rápidas e receba uma estimativa de custo e prazo na hora.

Sem compromissoResposta imediata