Por que o Floopy Permanece Rápido Enquanto Otimiza Seus Agentes

Um ano atrás, “AI gateway mais rápido” teria sido um posicionamento defensável. Hoje não é. A latência de gateway despencou no mercado — proxies em Rust, pools de conexão com keepalive e camadas de cache co-localizadas fazem com que a maioria dos gateways sérios adicione menos de 10ms de overhead. Velocidade virou commodity.

O que não virou commodity é se sua camada de roteamento consegue tornar seus agentes mensuravelmente melhores ao longo do tempo usando o sinal de feedback que você já coleta. É sobre isso que este post realmente é. Os benchmarks vêm junto.

Velocidade, brevemente — os números ainda importam

Continuamos rodando o benchmark. Aqui está a versão curta contra gpt-4.1-nano, 50 rodadas por cenário, prompts únicos anti-cache, outlier excluído:

O gateway roda em Rust sobre Axum/Tokio com um pool compartilhado e quente de HTTPS para cada provedor, encaminhamento zero-copy e um firewall ONNX que escaneia prompts em menos de 1ms numa thread dedicada. A memória fica em ~41MB RSS ao longo de toda a execução.

Então: somos rápidos. Mas não vamos mais construir uma empresa em cima disso.

O produto real é otimização, não proxy

O Floopy é uma Plataforma de Otimização de Agentes de IA. O trabalho principal é escolher o modelo certo para cada requisição dentro dos seus agentes, usando uma pontuação ponderada dinâmica a partir de quatro fontes de feedback. O gateway é o mecanismo de entrega — é como estamos no caminho crítico para tomar essas decisões sem você reescrever sua aplicação. Mas o valor está no roteamento ficando mais inteligente, não no proxy sendo rápido.

Três coisas tornam a otimização do Floopy defensável. Nenhuma delas é sobre latência.

1. Propagação de feedback em nível de sessão

Avaliações por requisição quebram em agentes. Um único turno de usuário pode se desdobrar em tool calls, retries, raciocínio encadeado e múltiplas invocações de modelo. Pedir ao usuário para avaliar cada salto é absurdo. Pedir para ele avaliar o resultado final é normal — é exatamente o que a coleta de NPS já faz.

O Floopy ingere uma avaliação por sessão e a propaga para cada decisão de roteamento tomada dentro daquela sessão. Você faz POST em /v1/feedback com o header floopy-session-id que você já estava enviando nas requisições, e a nota vira a verdade de base para cada escolha de modelo naquele trace. Multi-turn, tool-calling, chain-of-thought — tudo coberto pelo sinal que você já coleta.

2. Roteamento ponderado multi-fonte

Feedback de fonte única é frágil. NPS de sessão é esparso no começo. Auto-scoring (LLM-as-judge) tem pontos cegos. Avaliações manuais de admin não escalam. Benchmarks públicos não refletem sua carga de trabalho.

O Floopy combina todas as quatro com pesos que mudam conforme o sinal se acumula:

Dia 0 significa que o roteamento começa a partir de priors de benchmarks públicos — você ganha otimização já na primeira requisição. Conforme o uso real chega, auto e feedback manual assumem. Uma vez que sessões suficientes recebem avaliações reais, o NPS de sessão domina. Você nunca bate na parede do cold-start.

3. Inteligência de roteamento gerenciada e compartilhada

O Floopy é multi-tenant por design. Organizações Free e Pro contribuem para um pool de roteamento compartilhado — sinal agregado e preservando privacidade sobre quais modelos performam melhor em quais formatos de tarefa. Enterprise pode optar por sair (opt-out).

É por isso que não lançamos uma versão self-hosted do cérebro de otimização. Self-hosted significa em silos — cada cliente aprende só com o próprio tráfego. Nossa aposta é que o pool cross-tenant converge mais rápido do que qualquer tenant isolado conseguiria por conta própria. O framework open-source do TensorZero é excelente e respeitamos o trabalho; é apenas uma aposta arquitetural diferente. Se sua restrição é localidade total de dados, self-host é a resposta certa. Se sua restrição é “tornar meus agentes melhores com o sinal que já coleto”, pooling gerenciado vence.

Como a velocidade de fato serve à otimização

Aqui está por que ainda nos importamos com latência: decisões de roteamento precisam ser baratas. Se ponderar quatro fontes de feedback, buscar o contexto da sessão e escolher um modelo somar 200ms, ninguém liga isso em produção. O orçamento de velocidade do gateway é o que nos compra espaço para fazer trabalho de roteamento de verdade sem o usuário notar.

• O pool compartilhado e quente de conexões faz com que gastemos quase nada no salto de encaminhamento.
• O cache exato via Redis e o cache semântico via Qdrant ficam na frente da chamada ao modelo, não atrás dela, então o roteamento em cache hit é essencialmente grátis.
• O firewall roda in-process via ONNX — sem round-trip de rede extra para escaneamento de prompt-injection.

Quando alguém roda nosso benchmark e vê “mais rápido que OpenAI direto”, o interessante não é esse número. É que o número é negativo enquanto o gateway também está tomando uma decisão de roteamento ponderada por feedback, escaneando por prompt injection e logando no ClickHouse. Esse é o orçamento dentro do qual a otimização roda.

O que isso significa para sua stack

Se você está avaliando o Floopy contra:

• LiteLLM / Portkey / Helicone — são gateways. Eles resolvem proxy, observabilidade e política básica. Se você só precisa das primitivas de gateway, são escolhas válidas. O Floopy tem essas primitivas (fizemos o benchmark delas lá em cima), mas o produto é a camada de otimização em cima. A pergunta não é “qual gateway é mais rápido”, é “você precisa de roteamento que melhora com o tempo, ou de um proxy transparente”.
• TensorZero — framework open-source, self-hosted, para roteamento dirigido por feedback. Trabalho técnico forte. O trade-off é aprendizado em silo e ops self-hosted. O Floopy é a alternativa gerenciada com pool de roteamento compartilhado e zero carga de infra. Escolha por preferência arquitetural, não por paridade de features.
• Sem gateway — você está chamando provedores diretamente. É rápido, mas você está deixando otimização na mesa. O Floopy adiciona latência negativa-a-neutra enquanto a qualidade do seu agente começa a melhorar desde a primeira requisição.

Reproduza o benchmark

Continua open source, continua reproduzível:

cd example
npm run benchmark:full

A metodologia completa, detalhes de isolamento de prompts e explicações de cenário vivem na documentação de Benchmarks.

Mas o benchmark não é mais o pitch. O pitch é: aponte seu OpenAI SDK para o Floopy, comece a fazer POST das notas de NPS que você já coleta em /v1/feedback e veja seu roteamento melhorar sessão por sessão. A velocidade está lá porque a otimização precisa do orçamento.

Cadastre-se grátis — 5.000 requisições/mês e 500 ingestões de feedback/mês incluídas no Starter. Plugue o SDK, faça POST do feedback a partir do sinal que você já tem.