Proxy für AI

Jede große KI-Plattform begrenzt, wie viele Requests Sie senden können. OpenAI, Anthropic, Google, DeepSeek – sie alle deckeln Ihre Nutzung pro Account, pro Minute, pro Tag. Wenn Sie Produkte entwickeln, Automatisierungen betreiben oder Daten im großen Stil verarbeiten, stößt ein einzelner Account mit einer einzigen IP schnell ans Limit. Sie erhalten 429-Fehler, wartende Requests stauen sich, und Ihre Pipeline kommt zum Stillstand.

Ein AI-Proxy-Server sitzt zwischen Ihren Anwendungen und dem KI-Anbieter. Sie senden Requests an den Proxy, und dieser verteilt sie auf mehrere API-Keys – jeder Key wird über seine eigene IP-Adresse geroutet. Der Anbieter sieht separate Nutzer statt eines überlasteten Accounts. Ihre Gesamtkapazität vervielfacht sich, während jeder einzelne Key sicher innerhalb seiner Limits bleibt. In der Praxis fügt ein gut konfigurierter Proxy nur 15–30 ms Latenz pro Request hinzu – vernachlässigbar für Batch-Verarbeitung und kaum spürbar selbst in Echtzeit-Chat-Anwendungen, bei denen die Generierungszeit des Modells mit 500–3000 ms den Großteil der Wartezeit ausmacht.

Das funktioniert, weil KI-Plattformen Rate-Limits an Konten koppeln, nicht an IPs – sie überwachen jedoch IP-Muster. Wenn eine Adresse in schneller Folge 10 verschiedene API-Keys durchläuft, ist das ein Warnsignal. Separate dedizierte Proxys pro Key sorgen dafür, dass alles natürlich aussieht. Außerdem brauchen Sie eine Failover-Strategie: Überwachen Sie die Fehlerrate jedes Keys, und wenn eine bestimmte IP durchgehend 429- oder 403-Fehler zurückgibt, rotieren Sie sie automatisch aus dem Pool und leiten den Traffic dieses Keys über eine Backup-IP. Health-Checks alle 60 Sekunden pro Key-IP-Paar erkennen Probleme, bevor sie sich kaskadieren.

So sieht das Setup in der Praxis aus

Die meisten AI-API-Proxy-Setups folgen unabhängig vom Anbieter demselben Muster. Sie betreiben einen schlanken Proxy-Server (FastAPI, Node, Go – was auch immer Ihr Stack hergibt), der einen Pool aus API-Keys verwaltet. Wenn ein Request eingeht, wählt der Proxy den nächsten verfügbaren Key, routet den Request über die diesem Key zugewiesene IP und gibt die Antwort zurück. Wenn ein Key einen 429-Fehler (Rate-Limit) erhält, wechselt der Proxy zum nächsten. Hier ein minimales Python-Beispiel mit FastAPI und httpx:

import httpx, itertoolsfrom fastapi import FastAPI, Request, Response

@app.post("/v1/chat/completions")async def proxy(request: Request): body = await request.json() slot = next(keys) async with httpx.AsyncClient(proxy=slot["proxy"]) as client: r = await client.post( "https://api.openai.com/v1/chat/completions", json=body, headers={"Authorization": f"Bearer {slot['api_key']}"}, ) # TODO: Add retry logic on 429 — try next key/IP before returning error to caller return Response(content=r.content, status_code=r.status_code)

Hinweis: Dieses minimale Beispiel verwendet itertools.cycle der Einfachheit halber, führt aber bei 429-Fehlern keine automatischen Retries durch. In der Produktion sollten Sie eine Retry-Logik ergänzen, die den gedrosselten Key überspringt und das nächste verfügbare Key-IP-Paar versucht, bevor ein Fehler an den Aufrufer zurückgegeben wird. Da mittlerweile fast jeder KI-Anbieter das OpenAI-API-Format unterstützt, kann ein einziger Proxy die Format-Übersetzung übernehmen, die jeder KI-Anbieter erfordert – leiten Sie an den richtigen Anbieter weiter, und Ihre Anwendung muss den Unterschied nicht kennen. Tauschen Sie einfach die Base-URL und den Key-Pool pro Provider aus, und derselbe 20-Zeilen-Server deckt OpenAI, Anthropic, Google und DeepSeek ab.