Como Parar de Escrever Adaptadores para Redes Neurais e Ter Controle dos Custos de Tokens

Recentemente, estava reescrevendo a integração do Claude para um cliente atualizado e me peguei pensando. Um dia os clientes pedem para conectar o GPT-4o, no outro exigem Anthropic, e uma semana depois o departamento financeiro pergunta de onde veio uma conta de centenas de dólares em testes. Cada vez tenho que adicionar lógica de tratamento de erros, gerenciar chaves e calcular manualmente os gastos com tokens.

Essa rotina é resolvida pelo LLM Gateway da equipe The Open Co. O projeto serve como um gateway de API unificado que aceita chamadas no formato padrão OpenAI e as roteia para os provedores apropriados.

Uma Requisição para Qualquer Modelo

O conceito central é direto. Em vez de integrar múltiplos SDKs, você envia uma única requisição HTTP para um gateway local ou na nuvem. O controlador identifica automaticamente o provedor alvo, transforma o formato e retorna a resposta.

Atualmente, os principais provedores são suportados:

• OpenAI
• Anthropic
• Google Vertex AI
• Outros serviços com APIs compatíveis

Aqui está como fica uma requisição padrão ao gateway:

curl -X POST https://api.llmgateway.io/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LLM_GATEWAY_API_KEY" \
  -d '{
  "model": "gpt-4o",
  "messages": [
    {"role": "user", "content": "Hello, how are you?"}
  ]
}'

Se você precisar trocar para o Claude 3.5 Sonnet, a estrutura JSON na sua aplicação permanece a mesma. Apenas o nome do modelo no corpo da requisição muda.

Rastreamento de Custos e Métricas de Latência

Quando múltiplos serviços ou desenvolvedores trabalham com redes neurais, controlar os limites se torna difícil. Às vezes alguém executa um script com um prompt incorreto em um loop infinito e consome o orçamento de um mês em uma hora.

O gateway cuida do rastreamento. Cada transação é salva no banco de dados, e o sistema calcula automaticamente:

• Número de tokens de entrada e saída
• Custo total de cada chamada
• Tempo de resposta do modelo
• Estatísticas gerais por chaves e projetos

Através do painel web, você pode visualizar gráficos prontos e ver imediatamente qual modelo específico está consumindo a maior parte do orçamento.

Estrutura do Projeto e Execução no Docker

Os autores construíram um monorepo em TypeScript. Por baixo dos panos, tecnologias comprovadas são usadas:

• Hono gerencia o proxy de requisições da API
• Next.js gerencia a interface web e o playground
• Drizzle ORM trabalha com os bancos de dados PostgreSQL e Redis
• TypeScript garante tipagem de ponta a ponta dos componentes

Você pode fazer deploy do seu próprio serviço em poucos minutos via Docker. Os autores montaram uma imagem pronta combinando os componentes principais.

docker volume create llmgateway_postgres
docker volume create llmgateway_redis

docker run -d \
  --name llmgateway \
  --restart unless-stopped \
  -p 3002:3002 \
  -p 3003:3003 \
  -p 3005:3005 \
  -p 3006:3006 \
  -p 4001:4001 \
  -p 4002:4002 \
  -v llmgateway_postgres:/var/lib/postgresql/data \
  -v llmgateway_redis:/var/lib/redis \
  -e AUTH_SECRET="$(openssl rand -base64 32 | tr -d '\n')" \
  -e GATEWAY_API_KEY_HASH_SECRET="$(openssl rand -base64 32 | tr -d '\n')" \
  ghcr.io/theopenco/llmgateway-unified:latest

Um pequeno detalhe da documentação: não monte uma pasta da máquina host diretamente em /var/lib/postgresql/data. Devido às especificidades da inicialização de permissões do PostgreSQL no container, o processo pode travar. Os volumes nomeados no comando acima eliminam esse problema.

Se você quiser experimentar o sistema primeiro sem fazer deploy, os desenvolvedores têm uma versão na nuvem em llmgateway.io.

Limitações da Versão Gratuita

O repositório usa licenciamento duplo. O código principal é distribuído sob AGPLv3, porém algumas pastas no código-fonte pertencem à versão Enterprise.

Na versão open-source gratuita, o histórico de chamadas é armazenado por 30 dias. Se você precisa de retenção ilimitada de logs, faturamento avançado de usuários ou separação de equipes dentro da sua organização, será necessário comprar uma licença comercial.

Quem Se Beneficiará Dessa Ferramenta

Se sua aplicação faz três requisições por dia para um único modelo, não faz sentido configurar um proxy separado. Você apenas adicionará um ponto extra de falha e latência de rede insignificante.

O gateway se provará nas seguintes situações:

• O projeto usa modelos de diferentes provedores
• Rastreamento transparente de custos de tokens entre diferentes serviços é necessário
• Deploy do proxy no seu próprio ambiente é necessário
• Uma troca rápida de fallback para um modelo de backup em caso de falhas é planejada

Você pode experimentar o projeto no GitHub. O README lá é bem minimalista, mas o projeto é compreensível mesmo sem instruções longas.