Benchmarks

Estes benchmarks comparam o Floopy AI Gateway contra chamadas diretas à OpenAI e dois concorrentes populares — LiteLLM e Helicone — usando o OpenAI Node.js SDK. Os testes rodaram com gpt-4.1-nano, 50 rounds por cenário, pior outlier excluído, com timestamps anti-cache injetados em cada prompt para evitar caching do lado do provedor.

Principais Conclusões

• Floopy é 4,8% mais rápido que chamar a OpenAI diretamente — mesmo sem nenhuma feature ativada, o connection pooling em Rust supera a própria otimização HTTP do SDK.
• Floopy com firewall é 8,6% mais rápido que direto — o Prompt Guard não adiciona latência (roda localmente via ONNX em menos de 1ms) enquanto o connection pooling economiza mais do que custa.
• Floopy + Cache + Firewall é 58% mais rápido que direto — a configuração de produção recomendada entrega P50 de 260ms com segurança e economia de custos.
• LiteLLM adiciona overhead negligível (-0,6%) — proxy baseado em Python tem boa performance para passthrough, mas não oferece melhoria de latência.
• Helicone adiciona 2,4% de overhead — proxy gerenciado introduz leve latência pelo hop de rede adicional.
• Floopy usa apenas 41MB de memória — o gateway em Rust é extremamente leve, com pico de 44MB sob carga de benchmark.

Resumo dos Resultados

Comparação de Gateways

O Floopy é o único gateway que é mensuravelmente mais rápido do que chamar o provedor diretamente.

Detalhes por Cenário

OpenAI Direct (Baseline)

Chamada direta à api.openai.com usando o OpenAI Node.js SDK.

• Avg: 664ms | P50: 633ms — latência típica para gpt-4.1-nano
• Este é o baseline contra o qual todos os gateways são comparados

Floopy (No Features)

Gateway com todas as features desabilitadas. Mede o overhead puro do proxy.

• Avg: 632ms — 32ms mais rápido que direto (4,8%)
• O gateway em Rust mantém conexões HTTPS keep-alive persistentes para a OpenAI, eliminando a negociação TLS por requisição que o reuso de conexão do SDK não consegue evitar completamente
• Min: 387ms — a melhor latência é quase 100ms menor que o melhor caso do direto (480ms)

Floopy + Exact Cache

Exact cache ativado com prompts que se repetem naturalmente ao longo de 50 rounds.

• Avg: 195ms — 70,6% mais rápido que direto
• P50: 10ms — a maioria das requisições acerta o cache, retornando do Redis em milissegundos de um dígito
• RPS: 4.8 — 3,2x o throughput de chamadas diretas
• Min: 5ms — cache hits ignoram o provedor por completo

Floopy + Firewall (Prompt Guard)

Firewall de LLM ativado. Escaneia cada prompt em busca de ataques de injeção usando um modelo ONNX local.

• Avg: 607ms — 8,6% mais rápido que direto
• O firewall roda localmente em menos de 1ms — não adiciona latência mensurável
• P99: 826ms — latência de cauda mais consistente que o direto (983ms) porque o connection pooling absorve a variância do provedor

Floopy + Cache + Firewall (Config de Produção)

Configuração de produção recomendada com cache e segurança ativados.

• Avg: 277ms — 58,3% mais rápido que direto
• P50: 260ms — consistente abaixo de 300ms com segurança e economia de custos
• Min: 6ms — cache hits são quase instantâneos mesmo com o firewall ativo
• RPS: 3.0 — 2x o throughput de chamadas diretas

LiteLLM Proxy

Proxy open-source em Python no modo passthrough (Docker, sem features de cache ou segurança).

• Avg: 660ms — 0,6% mais rápido que direto (dentro da margem de ruído)
• O runtime Python adiciona overhead que praticamente anula qualquer benefício de connection pooling
• Um proxy de passthrough justo, mas sem vantagem de latência

Helicone Proxy

Proxy gerenciado de observabilidade (hospedado na nuvem, sem features de cache ou segurança).

• Avg: 680ms — 2,4% mais lento que direto
• O hop de rede adicional até o proxy na nuvem da Helicone adiciona ~16ms
• Oferece logging e analytics, mas com custo de latência

Performance Visual

Floopy + Exact Cache   █████████           195ms  (-71%)  ⚡ fastest
Floopy + Cache + FW    ██████████████      277ms  (-58%)  🛡️ recommended
Floopy + Firewall      ████████████████████████████████  607ms  (-9%)
Floopy (no features)   █████████████████████████████████ 632ms  (-5%)
LiteLLM Proxy          █████████████████████████████████ 660ms  (-1%)
OpenAI Direct          ██████████████████████████████████ 664ms  baseline
Helicone Proxy         ███████████████████████████████████ 680ms  (+2%)

Uso de Memória

O gateway Floopy usa memória mínima durante todo o benchmark:

Para comparação, gateways baseados em Python tipicamente usam 200-400MB em idle. O runtime Rust não tem garbage collector, nem overhead de interpretador, nem warmup de VM.

Por Que o Floopy É Rápido

A maioria dos AI gateways é escrita em Python ou Node.js — linguagens que adicionam 5-50ms de overhead por requisição. O Floopy é escrito em Rust com Axum e Tokio, o que dá vantagens estruturais:

Connection pooling persistente. O gateway mantém conexões HTTPS quentes para cada provedor. Isso elimina handshakes TLS por requisição — economizando 20-50ms que nem o reuso de conexão do SDK consegue evitar completamente. Confirmado pela melhoria de 4,8% com todas as features desabilitadas.

Forwarding sem alocação. O modelo de ownership do Rust permite parsing e forwarding de requisições sem alocações intermediárias de buffer. Sem pausas de garbage collection.

I/O assíncrono com Tokio. Todas as operações rodam em um thread pool work-stealing. Lookups de cache, inferência do firewall e chamadas ao provedor executam concorrentemente. Nada bloqueia.

Firewall no dispositivo. O Prompt Guard roda localmente via ONNX Runtime em thread dedicada — sem chamada de API externa, sem penalidade de latência. É por isso que o cenário com firewall (607ms) é na verdade mais rápido que o direto (664ms).

Logging em background. Logs de requisição são enfileirados via channels assíncronos e inseridos em batch no ClickHouse. O logging nunca toca o caminho da resposta.

41MB de footprint de memória. Sem interpretador, sem VM, sem overhead de runtime. O binário do gateway inclui o modelo ONNX e ainda usa menos memória que uma cadeia típica de imports Python.

Metodologia

• Client: OpenAI Node.js SDK
• Model: gpt-4.1-nano
• Rounds per scenario: 50
• Concurrency: 1 (sequential — measures pure latency)
• Outlier handling: Worst result per scenario excluded
• Anti-cache: Timestamp + index injected in every prompt ([ref:{scenario}-{index}-{timestamp}]) — zero provider cache hits possible
• Gateway: Local Floopy instance (Rust/Axum), 41MB RSS
• LiteLLM: Docker container (ghcr.io/berriai/litellm:main-latest), passthrough to OpenAI
• Helicone: Managed proxy (ai-gateway.helicone.ai), passthrough to OpenAI
• Temperature: 0.0
• Max tokens: 256

Como Rodar

cd example

# Iniciar concorrente LiteLLM (requer Docker)
npm run competitors:up

# Rodar o benchmark completo (sequencial)
npm run benchmark:full

# Rodar com concorrência
npm run benchmark:full:concurrent    # 10 requisições paralelas
npm run benchmark:full:stress        # 50 paralelas, 200 rounds

# Parar concorrentes
npm run competitors:down

Defina SKIP_COMPETITORS=true para fazer benchmark apenas do Floopy vs OpenAI direto.

Toda configuração é lida do .env (OPENAI_API_KEY, FLOOPY_API_KEY, FLOOPY_URL, LITELLM_URL, HELICONE_URL, HELICONE_API_KEY, MODEL, ROUNDS, CONCURRENCY).