Agrupar claves de API con Bifrost

Bifrost es un AI Gateway rápido basado en Go. Si estás alcanzando los rate limits con tu proveedor de LLM y necesitas agrupar varias claves de API para aumentar tu throughput, Bifrost ofrece un motor de routing nativo y performante para gestionar el balanceo de carga.

Configurar la agrupación de claves en un único nodo de Bifrost es fácil; escalar ese setup entre múltiples nodos en producción requiere una planificación arquitectónica cuidadosa para no superar las cuotas de tu proveedor.

Aquí está exactamente cómo agrupar claves de API en Bifrost y cómo escalar ese setup de forma segura.

1. Configurar la agrupación de claves en Bifrost

Bifrost permite definir varias claves de API para un único proveedor y asignarles pesos. El motor de routing distribuirá automáticamente las peticiones entrantes entre estas claves según sus pesos y estado de salud.

Para un despliegue GitOps-friendly y stateless, se configura usando un archivo config.json montado en el contenedor de Bifrost.

{
  "$schema": "https://www.getbifrost.ai/schema",
  "providers": {
    "openai": {
      "keys": [
        {
          "name": "openai-key-primary",
          "value": "env.OPENAI_API_KEY_1",
          "models": ["gpt-4o", "gpt-4o-mini"],
          "weight": 0.7
        },
        {
          "name": "openai-key-secondary",
          "value": "env.OPENAI_API_KEY_2",
          "models": ["gpt-4o", "gpt-4o-mini"],
          "weight": 0.3
        }
      ]
    }
  }
}

En esta configuración, Bifrost actúa como un router inteligente. Enviará aproximadamente el 70 % del tráfico a la clave primaria y el 30 % a la secundaria. Si la clave primaria recibe un 429 Too Many Requests de OpenAI, la lógica interna de Bifrost la marcará temporalmente como degradada y enrutará el tráfico a la clave secundaria.

2. Ejecutar la petición

Desde el código de tu aplicación, tratas a Bifrost exactamente como la API estándar de OpenAI. No necesitas construir ninguna lógica de routing en tu app.

Simplemente apunta el baseURL de tu SDK a tu instancia de Bifrost y proporciona una clave de API ficticia (o una Virtual Key si tienes gobernanza habilitada).

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: "vk-my-bifrost-key", // The gateway authenticates this
  baseURL: "http://localhost:8080/v1" // Pointing to Bifrost
});

const response = await client.chat.completions.create({
  model: "openai/gpt-4o",
  messages: [{ role: "user", content: "Analyze this dataset..." }]
});

Bifrost intercepta esta petición, selecciona la clave de API física apropiada según los pesos en config.json, la añade a los headers y hace proxy de la petición a OpenAI.

3. La trampa de escalado multi-nodo

Este setup funciona para un único nodo masivo de Bifrost. El problema aparece cuando necesitas alta disponibilidad y escalas a múltiples instancias detrás de un balanceador de carga.

En el Bifrost open-source (OSS), cada nodo actúa como un motor de decisión independiente.

• El Nodo A carga el config.json y rastrea el uso de TPM/RPM de openai-key-primary en su memoria local.
• El Nodo B carga el mismo config.json y rastrea su propio uso local.

Como el Bifrost OSS no sincroniza el estado de runtime (como rate limits en vivo o token buckets) entre nodos en tiempo real, el Nodo A no tiene idea de cuántos tokens acaba de enviar el Nodo B a OpenAI. Bajo tráfico concurrente pesado, los nodos superarán colectivamente los límites físicos del proveedor, resultando en errores 429 upstream y peticiones caídas.

(Nota: Bifrost ofrece un tier Enterprise de pago que usa un protocolo de consenso RAFT modificado para sincronizar este estado, pero aquí nos enfocamos en la arquitectura OSS.)

4. Cómo escalarlo de verdad: Externalizar el Plano de Control

Si quieres usar Bifrost OSS en múltiples nodos sin superar los límites, debes adoptar la arquitectura de 3 capas. Debes quitar la enforcement "inteligente" de cuotas de Bifrost y externalizarla a un Plano de Control coordinado globalmente.

En esta arquitectura, Bifrost es puramente un Motor de Routing y Ejecución. Elige la clave y hace la llamada de red.

Para forzar los rate limits globales, colocas un sistema de cuotas dedicado (como OpenMeter o un Kong API Gateway con rate limiting respaldado por Redis) delante de Bifrost.

El flujo:

1. Tu app envía una petición a la capa Kong/Redis.
2. El Plano de Control consulta Redis: ¿Tiene este usuario/equipo suficiente capacidad global de TPM en toda nuestra infraestructura?
3. Si sí, decrementa el contador global y reenvía la petición al balanceador de carga de Bifrost.
4. Bifrost recibe la petición, usa sus pesos internos para elegir una clave de API física y ejecuta la llamada.

Al dividir la enforcement global de cuotas en Redis y el routing de claves físicas en Bifrost, obtienes el rendimiento del proxy Go de Bifrost mientras mantienes tus rate limits sólidos a través de cualquier número de nodos.

En el próximo post, veremos cómo LiteLLM maneja exactamente este problema, ya que toma un enfoque distinto al empaquetar Redis directamente en su capa de proxy open-source.