0Pricing
AI Engineering Academy · Lección

Equilibrado de carga y estrategias con varias claves

Implemente un equilibrado de carga round-robin y ponderado entre varias claves y cuentas de API para ampliar su margen de límites de frecuencia y reducir los picos de latencia p99.

Equilibrado de carga y estrategias con varias claves es una lección gratuita de AI Engineering Academy en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de AI Engineering Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de AI Engineering Academy incluye 4 lecciones en total.

Por qué una sola clave de API no es suficiente

Una sola clave de API de OpenAI tiene un límite de frecuencia fijo, medido en solicitudes por minuto (RPM) y tokens por minuto (TPM). En el nivel 1, GPT-4o permite 500 RPM y 30.000 TPM. En una aplicación de producción con cientos de usuarios simultáneos, una sola clave alcanzará estos límites constantemente. Varias claves de API multiplican proporcionalmente el margen disponible.

Creación de varias claves de API

Puede crear varias claves de API dentro de una misma organización de OpenAI o crear varias cuentas de OpenAI (cada una con facturación independiente). Almacene cada clave en la configuración del entorno y trátelas como un pool. Mantenga las claves en un gestor de secretos, como AWS Secrets Manager o HashiCorp Vault, en lugar de incluirlas en el código fuente o en archivos .env confirmados en el control de versiones.

import os

API_KEYS = [
    os.environ['OPENAI_KEY_1'],
    os.environ['OPENAI_KEY_2'],
    os.environ['OPENAI_KEY_3'],
    os.environ['OPENAI_KEY_4'],
]

# Total effective RPM = 500 * 4 = 2000 RPM
# Total effective TPM = 30000 * 4 = 120000 TPM

Balanceo de carga round-robin

Round-robin distribuye las solicitudes de forma uniforme entre todas las claves, recorriéndolas en orden. Es sencillo de implementar y garantiza que cada clave gestione aproximadamente la misma carga con el tiempo. Use un contador seguro para subprocesos o un entero atómico para evitar que dos solicitudes simultáneas seleccionen la misma clave. Round-robin funciona bien cuando todas las claves tienen límites de frecuencia idénticos.

import itertools
import threading
from openai import OpenAI

class RoundRobinPool:
    def __init__(self, keys: list):
        self._clients = [OpenAI(api_key=k) for k in keys]
        self._cycle = itertools.cycle(range(len(self._clients)))
        self._lock = threading.Lock()

    def get_client(self) -> OpenAI:
        with self._lock:
            idx = next(self._cycle)
        return self._clients[idx]

pool = RoundRobinPool(API_KEYS)
client = pool.get_client()

Balanceo de carga ponderado

El balanceo de carga ponderado asigna a las claves de niveles superiores (con límites de frecuencia más altos) una proporción mayor del tráfico, de forma proporcional a su capacidad. Si la clave A es de nivel 3 (10.000 RPM) y la clave B es de nivel 1 (500 RPM), la clave A debería recibir aproximadamente el 95 % de las solicitudes. El balanceo ponderado evita que las claves de niveles inferiores se conviertan en cuellos de botella al mezclarse con claves de niveles superiores.

import random

class WeightedPool:
    def __init__(self, key_configs: list):
        # key_configs = [{'key': '...', 'weight': 10}, ...]
        self._clients = [OpenAI(api_key=c['key']) for c in key_configs]
        self._weights = [c['weight'] for c in key_configs]

    def get_client(self) -> OpenAI:
        return random.choices(self._clients, weights=self._weights, k=1)[0]

pool = WeightedPool([
    {'key': os.environ['OPENAI_KEY_TIER3'], 'weight': 20},
    {'key': os.environ['OPENAI_KEY_TIER1'], 'weight': 1},
])

Seguimiento del estado del límite de frecuencia por clave

La API de OpenAI devuelve encabezados de límite de frecuencia con cada respuesta: x-ratelimit-remaining-requests y x-ratelimit-remaining-tokens. Realice un seguimiento de estos encabezados por clave para saber cuáles están cerca de agotarse. Cuando una clave indique que quedan menos de 10 solicitudes en el minuto actual, desvíe temporalmente el tráfico para evitar errores 429 antes de que se produzcan.

class SmartPool:
    def __init__(self, keys: list):
        self._clients = [OpenAI(api_key=k) for k in keys]
        self._remaining = {i: 500 for i in range(len(keys))}  # initial RPM

    def get_best_client(self):
        # Pick key with most remaining capacity
        best_idx = max(self._remaining, key=lambda i: self._remaining[i])
        return self._clients[best_idx], best_idx

    def update_remaining(self, idx: int, response_headers: dict):
        remaining = int(response_headers.get('x-ratelimit-remaining-requests', 0))
        self._remaining[idx] = remaining

Gestión de errores 429 por límite de frecuencia

Cuando una clave devuelva un error 429, retírela inmediatamente del pool durante el tiempo especificado en el encabezado Retry-After (normalmente, 60 segundos). Márquela como en periodo de enfriamiento y dirija todo el tráfico a las claves restantes. Cuando termine el periodo de enfriamiento, devuelva la clave al pool. Esto evita fallos en cascada en los que los reintentos sobre la misma clave empeoran la situación.

import time
from openai import RateLimitError

class CooldownPool:
    def __init__(self, keys: list):
        self._clients = [(OpenAI(api_key=k), None) for k in keys]  # (client, cooldown_until)

    def get_available_clients(self):
        now = time.time()
        return [
            (i, c) for i, (c, until) in enumerate(self._clients)
            if until is None or until <= now
        ]

    def mark_cooling(self, idx: int, retry_after: int = 60):
        client, _ = self._clients[idx]
        self._clients[idx] = (client, time.time() + retry_after)
        print(f'Key {idx} cooling down for {retry_after}s')

Uso de OpenRouter como multiplexor

OpenRouter es un servicio proxy que expone cientos de modelos mediante un único endpoint de API compatible con OpenAI. Al enrutar las solicitudes a través de OpenRouter, obtiene automáticamente balanceo de carga entre varias cuentas de proveedores subyacentes, conmutación por error a proveedores alternativos y acceso a modelos de código abierto como respaldo. El recargo de coste es pequeño en relación con la simplicidad operativa que ofrece.

from openai import OpenAI

# OpenRouter uses the same OpenAI SDK interface
client = OpenAI(
    api_key=os.environ['OPENROUTER_API_KEY'],
    base_url='https://openrouter.ai/api/v1'
)

response = client.chat.completions.create(
    model='openai/gpt-4o',  # OpenRouter model name format
    messages=[{'role': 'user', 'content': prompt}]
)
# Automatic failover if OpenAI is down

Supervisión del estado de las claves con métricas

Realice un seguimiento de las métricas de cada clave, incluidas las solicitudes enviadas, los errores 429 recibidos y el tiempo en periodo de enfriamiento durante la última hora. Una clave con una tasa elevada de errores 429 necesita una reducción del tráfico o una actualización de nivel. Exponga estas métricas en un endpoint /metrics con formato de Prometheus para que su sistema de supervisión pueda alertar cuando alguna clave alcance los límites de forma constante.

from dataclasses import dataclass, field
from collections import defaultdict

@dataclass
class KeyMetrics:
    requests_sent: int = 0
    rate_limit_errors: int = 0
    total_tokens_used: int = 0
    cooldown_count: int = 0

class MetricPool:
    def __init__(self, keys: list):
        self._clients = [OpenAI(api_key=k) for k in keys]
        self._metrics = [KeyMetrics() for _ in keys]

    def report(self):
        for i, m in enumerate(self._metrics):
            error_rate = m.rate_limit_errors / max(m.requests_sent, 1)
            print(f'Key {i}: {m.requests_sent} req, {error_rate:.1%} 429 rate')

Distribución geográfica de las claves

Si sus usuarios están distribuidos por todo el mundo, considere mantener claves de API independientes por región geográfica y enrutar las solicitudes a la clave más cercana al usuario. Reducir el tiempo de ida y vuelta de la red mejora el TTFT. Implemente un balanceador de carga ligero en cada región (AWS Lambda@Edge o Cloudflare Worker) que seleccione la clave adecuada y actúe como proxy de la solicitud, evitando que las claves queden expuestas al cliente.

REGIONAL_KEYS = {
    'us-east': os.environ['OPENAI_KEY_US_EAST'],
    'eu-west': os.environ['OPENAI_KEY_EU_WEST'],
    'ap-southeast': os.environ['OPENAI_KEY_AP'],
}

def get_key_for_region(user_region: str) -> str:
    # Default to us-east if region unknown
    return REGIONAL_KEYS.get(user_region, REGIONAL_KEYS['us-east'])

Prueba del balanceador de carga

Escriba una prueba de carga que envíe 100 solicitudes simultáneas a través de su pool de balanceo y mida la distribución, las tasas de error y los percentiles de latencia. Verifique que ninguna clave gestione más de la proporción que le corresponde y que los errores 429 sean inferiores al 0,1 %. Use asyncio.gather o una herramienta como Locust para simular la carga simultánea que experimentará realmente su sistema en producción.

import asyncio
import time

async def load_test(pool, concurrency=100, total=1000):
    sem = asyncio.Semaphore(concurrency)
    results = []

    async def one_request():
        async with sem:
            client = pool.get_client()
            start = time.perf_counter()
            try:
                await client.chat.completions.create(
                    model='gpt-4o-mini',
                    messages=[{'role': 'user', 'content': 'Ping'}],
                    max_tokens=5
                )
                results.append(('ok', time.perf_counter() - start))
            except Exception as e:
                results.append(('error', str(e)))

    await asyncio.gather(*[one_request() for _ in range(total)])
    ok = [r for r in results if r[0] == 'ok']
    print(f'Success rate: {len(ok)/total:.1%}')
    return results

Elección de la estrategia de balanceo adecuada

Adapte la estrategia de balanceo a la estructura de sus límites de frecuencia. Use round-robin cuando todas las claves tengan límites de nivel idénticos y el tráfico se distribuya de manera uniforme. Use el balanceo ponderado cuando las claves tengan límites de nivel diferentes. Use el enrutamiento basado en el estado (omitiendo las claves cercanas al agotamiento) cuando necesite minimizar los errores 429 durante picos de tráfico. En la mayoría de los sistemas de producción, el enrutamiento basado en el estado con retroceso exponencial ofrece el mejor equilibrio entre simplicidad y resiliencia.

# Strategy selection guide:
# Scenario A: 4 keys all Tier 2 (same limits)
#   -> Round-robin: simple, even distribution
#
# Scenario B: 1 Tier 3 key + 3 Tier 1 keys
#   -> Weighted: Tier 3 gets 10x weight
#
# Scenario C: Variable traffic with burst periods
#   -> Health-aware: track remaining headers, skip near-limit keys
#
# Scenario D: Multi-region, latency-sensitive
#   -> Geographic: regional keys, route by user location

Comprobación rápida

Compruebe su comprensión de las estrategias de balanceo de carga para las API de LLM.

Resumen de la lección

En esta lección ha aprendido que el balanceo round-robin y ponderado distribuye el tráfico entre varias claves de API para multiplicar el margen de los límites de frecuencia; el seguimiento del periodo de enfriamiento evita errores 429 en cascada al retirar temporalmente las claves limitadas; y OpenRouter ofrece una opción de multiplexación gestionada con conmutación por error automática. A continuación, implementaremos proveedores de respaldo y disyuntores.

Preguntas frecuentes

¿La lección «Equilibrado de carga y estrategias con varias claves» es gratis?

Sí — el texto completo de «Equilibrado de carga y estrategias con varias claves» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de AI Engineering Academy, actualiza a CoddyKit PRO. El curso de AI Engineering Academy incluye 4 lecciones en total.

¿Qué aprenderé en «Equilibrado de carga y estrategias con varias claves»?

Implemente un equilibrado de carga round-robin y ponderado entre varias claves y cuentas de API para ampliar su margen de límites de frecuencia y reducir los picos de latencia p99. Practicas AI Engineering Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar AI Engineering Academy?

No se requiere experiencia previa. AI Engineering Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.

¿Cuánto tiempo toma la lección «Equilibrado de carga y estrategias con varias claves»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de AI Engineering Academy?

Sí. Cada lección de AI Engineering Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Medición de la latencia de los LLM: TTFT y TPOT
  2. Equilibrado de carga y estrategias con varias claves
  3. Proveedores de respaldo y disyuntores
  4. Presupuestos de tiempo de espera y degradación controlada
← Volver a AI Engineering Academy