Rate Limiting

Rate Limiting im Überblick

Rate Limiting ist ein unverzichtbarer Schutzmechanismus für APIs: Es begrenzt, wie viele Anfragen ein Client in einem definierten Zeitraum senden darf. Ohne Rate Limiting kann ein einzelner Nutzer oder ein fehlerhafter Client eine API mit Anfragen überfluten und sie für alle anderen unbrauchbar machen. Für KI-APIs ist Rate Limiting besonders wichtig, weil Inferenz rechenintensiv ist – jede Anfrage kostet echte Ressourcen und Geld.

Rate Limiting begrenzt, wie viele Anfragen ein Client in einem bestimmten Zeitraum an eine API senden darf. Es schützt Server vor Überlastung, verhindert Missbrauch und stellt sicher, dass alle Nutzer fair Zugang haben. Für KI-APIs wie OpenAI oder Anthropic ist Rate Limiting besonders wichtig, weil Inferenz rechenintensiv ist und Kosten pro Token entstehen.

Rate Limiting begrenzt, wie viele Anfragen ein Nutzer in einem Zeitraum machen darf. Überschreitet er das Limit, werden weitere Anfragen abgelehnt.

Warum ist das wichtig für LLM-APIs?

Ohne Rate Limiting:
User macht 10.000 Anfragen in 1 Minute
-> Kosten: $500
-> Server überlastet
-> Andere User können nicht mehr zugreifen

Mit Rate Limiting:
User macht 60 Anfragen, dann: "429 Too Many Requests"
-> Kosten kontrolliert
-> Server stabil
-> Fair für alle User

Technisch betrachtet

Algorithmen

Token Bucket Beispiel

import time
import redis

class RateLimiter:
    def __init__(self, redis_client, max_tokens=60, refill_rate=1):
        self.redis = redis_client
        self.max_tokens = max_tokens
        self.refill_rate = refill_rate  # Tokens pro Sekunde
    
    def is_allowed(self, user_id):
        key = f"rate_limit:{user_id}"
        now = time.time()
        
        # Atomare Operation mit Lua Script
        tokens, last_refill = self.redis.get_tokens(key)
        
        # Tokens auffüllen
        elapsed = now - last_refill
        tokens = min(self.max_tokens, tokens + elapsed * self.refill_rate)
        
        if tokens >= 1:
            self.redis.set_tokens(key, tokens - 1, now)
            return True
        return False

HTTP Response Headers

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1699876543

Best Practices

• Mehrere Limits: Pro Sekunde UND pro Tag
• Graceful Degradation: Warnung vor hartem Limit
• Transparenz: Limits in Response Headers kommunizieren
• Unterschiedliche Tiers: Free vs. Paid unterschiedlich limitieren