LLMopsSecurityCost Optimization

El Cron Job de $50k: Por Qué Necesitas un AI Gateway Ahora Mismo

Alex V. Lead Architect
5 min de lectura 20 de mayo de 2024

TL;DR (Resumen Ejecutivo)

  • El acceso directo a la API es una bomba de tiempo financiera.
  • El rate-limiting en el lado del cliente se puede eludir fácilmente.
  • Un Gateway centralizado nos ahorró $50k de claves comprometidas.

El Inicio: “Es solo un script de desarrollo.”

Ya lo hemos escuchado. “Solo necesito una clave de OpenAI para probar este cron job. Se ejecuta una vez por noche.”

Seis horas después, ese cron job “de una vez por noche” estaba atrapado en un bucle infinito de reintentos por culpa de un payload JSON mal formado. Lanzó 400.000 peticiones contra GPT-4 antes de que alguien se despertara.

Si esa clave era directa a OpenAI, acabas de quemar $12.000.

Si esa clave estaba detrás de un AI Gateway, el límite de presupuesto se habría activado a los $50.

El Problema: Claves Distribuidas

En la mayoría de las startups, las claves API se tratan como caramelos. Están:

  1. Hardcodeadas en ficheros .env.
  2. Compartidas por Slack.
  3. Enterradas en variables de CI/CD.

Esto crea una vulnerabilidad distribuida. No puedes rotar una clave sin romper 10 servicios desconocidos. No puedes monitorizar quién gasta qué.

graph TD
    A[Service A] -->|Key 1| OpenAi
    B[Service B] -->|Key 2| OpenAi
    C[Dev Script] -->|Key 3| OpenAi
    D[Unknown Cron] -->|Key ?| OpenAi
    style D fill:#f00,stroke:#333

La Solución: Un Gateway Centralizado

Implementamos un punto de entrada unificado para todo el tráfico LLM. Ningún servicio habla directamente con OpenAI. Hablan con llm.internal.deveez.com.

La Arquitectura

En lugar de gestionar 50 claves, gestionamos una clave maestra a nivel de Gateway y emitimos tokens virtuales a los equipos internos.

# gateway-config.yaml
policies:
  - name: "daily-budget-cap"
    type: "cost-limit"
    config:
      limit_usd: 50
      period: "daily"
      action: "reject"

El Código

Así aplicamos los límites de tasa en nuestro middleware proxy de Golang:

func RateLimitMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        teamID := r.Header.Get("X-Team-ID")
        if limiter.Allow(teamID) == false {
            http.Error(w, "Rate limit exceeded", 429)
            return
        }
        next.ServeHTTP(w, r)
    })
}

La Postura de Deveez

La seguridad no consiste en desconfiar de tus desarrolladores; consiste en protegerlos de sus propios scripts.

Un Gateway no es “burocracia”. Es un cinturón de seguridad. Si estás ejecutando LLMs en producción sin una capa de proxy, estás a un bucle while(true) de la bancarrota.

La Conclusión

  1. Revoca las claves locales de inmediato.
  2. Despliega un Gateway (Kong, LiteLLM, o uno personalizado).
  3. Establece límites estrictos por equipo.

¿Te preocupa exactamente este fallo de seguridad? Ejecuta nuestra Auditoría de Preparación para IA

A
Escrito por
Alex V.
Lead Architect

¿Listo para acelerar la velocidad de tu equipo?