Self-Hosted vs LLMOps Gerenciado: Quando Escolher Cada Um

A categoria LLMOps — a camada que observa, avalia e roteia tráfego entre sua aplicação e um ou mais provedores de LLM — se dividiu ao longo de um eixo arquitetural que não é nomeado com a frequência que merecia. De um lado: plataformas self-hosted, source-available, que você roda dentro da sua própria infraestrutura. Do outro: SaaS gerenciado que roda como serviço hospedado. Ambas as formas resolvem problemas parecidos. Elas não fazem os mesmos trade-offs, e a decisão entre elas merece mais que um checklist de funcionalidades.

Este post é o framework que a gente queria ter visto quando começou — neutro, eixo-primeiro, sem afirmar que um lado é inerentemente melhor. Se você está avaliando plataformas LLMOps em 2026, a escolha gerenciado-versus-self-hosted é upstream de toda comparação de funcionalidades. Erre nela e você está reconstruindo um ano depois.

O eixo, nomeado com clareza

Uma plataforma LLMOps self-hosted é entregue como código (frequentemente open-source, frequentemente em Rust, Go ou Python) que você implanta na sua própria VPC, cluster ou ambiente bare-metal. Você roda os binários. Você opera o banco de dados. Você lida com upgrades, secrets, escala, on-call. Em troca, cada byte de dado de requisição e resposta fica dentro do seu perímetro, e você controla a cadência de upgrade completamente.

Uma plataforma LLMOps gerenciada roda as mesmas capacidades gerais — gateway, observabilidade, avaliação, roteamento — como um serviço hospedado. Você aponta seu SDK para um endpoint e paga por requisição, por sessão ou por seat. O fornecedor lida com uptime, upgrades, escala e postura de segurança. Em troca, você aceita que alguns metadados (formato da requisição, latência, scores de avaliação, às vezes conteúdo redatado) cruzem uma fronteira organizacional.

A maioria das plataformas escolhe um lado e fica nele. Algumas afirmam fazer os dois, mas o formato operacional de “self-hosted com control plane gerenciado” é genuinamente diferente de qualquer escolha pura, e merece sua própria discussão mais à frente.

Quando self-hosted é a escolha certa

Self-hospedar LLMOps faz sentido, frequentemente de forma enfática, quando:

Seus dados não podem sair do perímetro. Saúde, defesa, finanças e uma lista crescente de workloads regulados na UE têm políticas que impedem qualquer terceiro — mesmo com BAA, mesmo com SOC 2 — de ver prompts ou respostas. Uma plataforma self-hosted é a única resposta arquiteturalmente limpa.
Você já tem capacidade de DevOps. Times que rodam o próprio Postgres, Kafka e Kubernetes não estão adicionando overhead significativo ao rodar mais um serviço com estado. O custo marginal de self-hospedar LLMOps para esses times é pequeno; os ganhos em controle são reais.
Você precisa de controle total de upgrade. Algumas organizações têm razões de compliance para fixar cada dependência. Uma plataforma self-hosted te deixa subir a versão N+1 no seu cronograma, depois da sua revisão de segurança, dentro da sua janela de release.
Sua lógica de roteamento precisa codificar regras de negócio proprietárias. Uma plataforma self-hosted que você pode forkar é a forma mais limpa de expressar lógica de roteamento que você jamais quereria exposta no roadmap de produto de um fornecedor.
Você quer aprender de cada requisição, em isolamento. Se seu tráfego é único o suficiente para que sinal cross-tenant fosse diluir em vez de melhorar seu roteamento, self-hospedar e tunar puramente nos seus próprios dados é o design certo.

TensorZero é o exemplo mais forte dessa abordagem no espaço LLMOps open-source — Rust, source-available, projetado para times que querem propriedade da infraestrutura e loops de feedback definidos pelo desenvolvedor. É a escolha certa para times onde os bullets acima descrevem a realidade.

Quando gerenciado é a escolha certa

LLMOps gerenciado faz sentido, frequentemente de forma enfática, quando:

DevOps é uma restrição, não uma força. A maioria dos times de produto com menos de 50 engenheiros não tem capacidade sobrando para rodar mais um serviço com estado direito. As horas gastas operando uma stack LLMOps self-hosted são horas que não foram gastas no produto.
Você quer inteligência cross-tenant. Esta é a razão mais sub-discutida. Uma plataforma gerenciada que roda tráfego de muitos clientes pode construir modelos de roteamento que aprendem com sinal agregado da base inteira. Nenhuma instalação self-hosted pode replicar isso — por definição.
Tempo até o primeiro sinal importa. Uma plataforma gerenciada te dá um prior baseado em benchmark no dia zero, antes de você ter mandado uma única requisição. Uma instalação self-hosted parte de cache frio e espera seu tráfego enchê-lo.
Você quer upgrades feitos pelo fornecedor. Lógica de roteamento melhora com pesquisa. A resposta honesta para a maioria dos times é que eles preferem herdar melhorias automaticamente do que ler um changelog e rodar uma migração.
Você precisa de economia previsível por requisição. Serviços hospedados precificam por chamada; self-hosted tem um baseline fixo de infraestrutura independente do tráfego. Abaixo de um certo volume, gerenciado é mais barato ponta a ponta.

O porém com gerenciado é a fronteira de dados. A versão honesta: você está confiando metadados sobre seu tráfego a um fornecedor, e em alguns casos conteúdo redatado usado para avaliação e treinamento. Leia os termos de processamento de dados com cuidado. Decida conscientemente.

A armadilha do híbrido

Um terceiro caminho comum — “self-hosted com control plane gerenciado” — soa como o melhor dos dois mundos. Na prática, ele tende a herdar os custos de ambos.

Você ainda opera o data plane (então ainda precisa de capacidade de DevOps). Você também aceita um control plane gerenciado (então metadados ainda cruzam uma fronteira). Os benefícios de aprendizado cross-tenant não se materializam porque seu data plane não compartilha sinal com ninguém. Os benefícios de controle de upgrade não se materializam porque o control plane sobe versão no cronograma do fornecedor.

Setups híbridos podem ser a resposta certa em casos regulatórios estreitos — quando o jurídico aceita control plane gerenciado mas não data plane gerenciado. Fora desses casos, qualquer lado do eixo puro costuma encaixar melhor que o meio.

Onde a Floopy se posiciona, e por quê

Escolhemos SaaS gerenciado deliberadamente, e a razão volta diretamente ao ponto de aprendizado cross-tenant acima.

A inteligência de roteamento da Floopy é construída a partir de sinal de NPS de usuário-final em nível de sessão coletado em toda a base de clientes. Organizações Free e Pro contribuem com sinal agregado para um modelo compartilhado que beneficia todo cliente Floopy. Organizações Enterprise podem optar por sair (opt out) para aprendizado totalmente isolado. O modelo compartilhado é o moat — e ele só é estruturalmente disponível em uma instalação multi-tenant gerenciada.

Uma Floopy self-hosted seria um produto diferente. Teria o mesmo gateway, o mesmo firewall, a mesma observabilidade por requisição — e um modelo de roteamento treinado nos dados de um único cliente. Para o time certo, é exatamente o que eles querem. Não somos a escolha certa para eles; TensorZero é mais próximo do formato que eles precisam.

Para times que querem operações gerenciadas e o benefício de inteligência de roteamento treinada em muitos workloads de produção, o formato SaaS gerenciado é o que torna isso possível. Esse é o trade que escolhemos, explicitado.

Como decidir, em cinco perguntas

Se você está tentando escolher um lado neste trimestre, as perguntas que de fato resolvem isso são curtas:

Seus dados podem sair do seu perímetro? Se não — self-hosted, ponto final.
Você tem headcount de DevOps sobrando? Se não — gerenciado.
Você quer roteamento que aprende com o tráfego de outros times? Se sim — gerenciado (com sinal cross-tenant). Se não — qualquer um funciona, com leve viés para self-hosted.
Seu volume de tráfego está acima ou abaixo de ~5M requisições/mês? Abaixo — gerenciado costuma ser mais barato. Acima — faça as contas dos dois lados.
Você precisa forkar a lógica de roteamento? Se sim — self-hosted.

Três ou mais respostas “gerenciado” significam que uma plataforma hospedada encaixa. Três ou mais respostas “self-hosted” significam rode você mesmo. Respostas mistas significam ir mais fundo antes de comprometer com qualquer lado.

Experimente o caminho gerenciado

Se o framework acima te leva para o lado gerenciado, a Floopy foi construída para esse caso ponta a ponta. O tier Free inclui o gateway completo, o firewall e o loop de feedback de quatro sinais no seu próprio tráfego — sem compromisso para ver como aprendizado cross-tenant se comporta no seu workload específico.

Comece em app.floopy.ai, ou leia Quatro Sinais, Um Loop para o detalhe técnico por trás do modelo de roteamento. Se self-hosted é o seu caminho, rode TensorZero — é a ferramenta certa para esse trabalho.

A escolha de arquitetura é upstream da escolha de funcionalidades. Faça-a deliberadamente.