Rate Limiting für KI-Funktionen: So verhindern Sie, dass ein einzelner Nutzer Ihr Budget leert

Begrenzen Sie KI-Funktionen auf Nutzer-, Sitzungs- und Endpunkt-Ebene – verlassen Sie sich nicht allein auf das kontoweite API-Limit Ihres LLM-Providers. Ein einzelnes kompromittiertes Konto, ein Scraping-Bot oder ein clientseitiger Bug, der sich in einer Retry-Schleife verfängt, kann aus einer planbaren Monatsrechnung eine fünfstellige Überraschung machen, bevor Ihr Ausgaben-Alert überhaupt ausgelöst wird.

Die meisten Teams lernen das auf die harte Tour. Sie liefern ein KI-Feature aus, verbinden es mit OpenAI oder Anthropic, richten eine Ausgaben-Benachrichtigung ein und gehen davon aus, damit ausreichend abgesichert zu sein. Das sind sie nicht. Ausgaben-Alerts sind ein Rauchmelder, kein Sprinklersystem: Sie sagen Ihnen, dass die Küche brennt – löschen tun sie nicht. Wenn die E-Mail bei Ihnen eintrifft, ist der Schaden längst auf Ihrer Kreditkarte.

Warum Provider-seitige Limits nicht ausreichen

Jeder LLM-Provider liefert Rate Limits mit – aber diese gelten für Ihr gesamtes Konto, nicht für Ihre einzelnen Nutzer. Die Rate-Limit-Dokumentation von OpenAI beschreibt Obergrenzen für Requests pro Minute und Tokens pro Minute, die global für Ihren API-Key gelten. Das schützt die Infrastruktur des Providers, nicht Ihr Geschäft. Wenn ein einzelner Nutzer in Ihrer App 500 Requests in einer Schleife abfeuert, fließt dieser Traffic in denselben Bucket wie der aller anderen legitimen Nutzer – und es ist Ihr Produkt, das darunter leidet, oder Ihre Rechnung, die in die Höhe schnellt, nicht die des Providers.

Das ist für uns keine Theorie. Unser eigenes Outreach-Tooling scrapt die Website jedes Prospects mit einer selbst gehosteten Firecrawl-Instanz und einem lokalen Modell und führt dann einen einzigen LLM-Call durch, der die relevanten Fakten extrahiert und die E-Mail entwirft. Wenn dieser Call in einer Retry-Schleife feststeckt oder ein Bug dieselbe Prospect-Liste zweimal einspielt, würde das kontoweite Limit von OpenAI das nicht stoppen – es würde lediglich alle anderen Requests auf diesem API-Key drosseln, einschließlich nicht verwandter, während die Schleife im Hintergrund weiter Tokens verbrennt. Die Obergrenze des Providers schützt OpenAIs Server – nicht unser Budget und nicht unseren übrigen Traffic.

Bei KI-Funktionen wiegt das schwerer als bei typischen API-Endpunkten, weil die Kostenvariation pro Request enorm ist. Ein normaler REST-Call kostet Bruchteile eines Cents – unabhängig davon, was der Nutzer tut. Ein LLM-Call kann je nach Prompt-Länge, Kontextfenster und Reasoning-Tiefe des Modells 50-mal mehr kosten. Ein Chatbot, der Nutzern das Einfügen beliebiger Texte erlaubt, oder ein Agent, der Tools in einer Schleife aufrufen kann, hat einen deutlich größeren Schadensradius als ein typischer CRUD-Endpunkt.

Was Sie tatsächlich rate-limitieren sollten

Denken Sie in Schichten, nicht in einer einzigen Zahl:

• Request-Rate pro Nutzer: Requests pro Minute pro authentifiziertem Nutzer, idealerweise mit einem Token Bucket, sodass kurze Lastspitzen erlaubt sind, anhaltender Missbrauch jedoch nicht.
• Token-Ausgaben pro Nutzer: Begrenzen Sie die Gesamtzahl der Tokens (Input + Output) pro Nutzer und Tag oder Abrechnungszeitraum – getrennt von der Request-Anzahl, da ein langer Prompt mehr kosten kann als hundert kurze.
• Tool-Calls pro Sitzung: Wenn Sie einen Agenten betreiben, der Tools aufrufen oder Sub-Requests stellen kann, begrenzen Sie die Anzahl der Schritte pro Sitzung. Genau deshalb ist unsere Outreach-Pipeline bewusst auf einen einzigen Call ausgelegt – scrapen, dann ein einziger Shot, der Fakten extrahiert und die E-Mail entwirft – statt einer mehrstufigen Kette aus „extrahieren, dann zusammenfassen, dann entwerfen". Jeder zusätzliche Schritt in einer Kette ist ein weiterer Ort, an dem eine feststeckende Schleife entstehen kann; ein Ein-Call-Design lässt einem unkontrollierten Prozess keinen Raum. Eine Schleife, die ein Tool 40-mal aufruft, weil sie nie eine Abbruchbedingung findet, ist ein häufiger und teurer Fehler in Ketten, die diese Disziplin vermissen lassen.
• Fallback nach IP und Gerät: Für nicht authentifizierte oder Freemium-Oberflächen fügen Sie ein sekundäres Limit hinzu, das nicht von der Kontoidentität abhängt – denn das ist das Erste, was ein Angreifer fälschen wird.

Setzen Sie all das serverseitig durch – in demselben Service, der Ihren Provider-API-Key hält. Clientseitiges Throttling ist eine UX-Annehmlichkeit, keine Sicherheitsmaßnahme. Wenn Ihre Rate-Limiting-Logik vom Browser aus einsehbar und umgehbar ist, schützt sie Ihr Budget nicht.

Bauen Sie es als Gate, nicht als Nachgedanken

Das sauberste Muster ist ein Ausgaben- und Rate-Gate, das zwischen Ihrer Anwendung und dem LLM-Call sitzt, sodass jeder Request – unabhängig davon, welches Feature ihn ausgelöst hat – denselben Check durchläuft. Dieses Gate sollte Folgendes verfolgen:

1. Die aktuelle Nutzung im Verhältnis zum Nutzer-Limit (Redis mit Sliding Window oder Token Bucket eignet sich hierfür gut)
2. Eine harte Obergrenze, die einen klaren Fehler zurückgibt, anstatt stillschweigend in eine Warteschlange zu stellen oder zu wiederholen
3. Eine Möglichkeit, Limits für bestimmte verifizierte Nutzer anzuheben, ohne neu deployen zu müssen

Retries verdienen besondere Aufmerksamkeit. Ein naiver Retry-on-failure-Wrapper um einen LLM-Call, kombiniert mit einem Rate-Limit-Fehler, kann sich hochschaukeln: Der Request schlägt fehl, der Client wiederholt ihn, der Retry wird ebenfalls rate-limitiert – und schon haben Sie eine Thundering Herd, die jede Sekunde auf Ihr Gate einschlägt. Setzen Sie auf exponentielles Backoff und begrenzen Sie die Gesamtzahl der Retries pro Request, nicht nur pro Minute.

Wenn Sie außerdem mehrere Provider aus Kosten- oder Zuverlässigkeitsgründen einsetzen, ist dasselbe Gate der richtige Ort, um Limits vor dem Routing durchzusetzen – ein weiterer Grund, diese Logik zu zentralisieren, anstatt Checks über alle KI-Endpunkte zu verteilen. Die Abwägungen dieser Routing-Schicht haben wir gesondert in unserem Artikel zu LLM-Kostenoptimierung und zu Multi-LLM-Provider-Failover behandelt.

Ein Muster, das nicht nur Risiken, sondern auch Kosten senkt

Der günstigste Request ist der, den Sie gar nicht erst stellen. In unserem eigenen Outreach-Tooling scrapen wir die Website jedes Prospects mit einer selbst gehosteten Firecrawl-Instanz und einem lokalen Modell – und wir haben festgestellt, dass ein einziger Call, der die relevanten Fakten extrahiert und die E-Mail in einem Schritt entwirft, eine mehrstufige Kette aus „extrahieren, dann zusammenfassen, dann entwerfen" sowohl bei den Kosten als auch bei der Latenz schlägt. Weniger Calls pro Arbeitseinheit bedeutet, dass Ihre Rate Limits von Natur aus schwerer zu erreichen sind und Ihre Obergrenze pro Nutzer weiter trägt. Prüfen Sie, bevor Sie zu aggressivem Throttling greifen, ob Ihr Feature mehr LLM-Calls stellt als nötig, um die Aufgabe zu erfüllen. Rate Limiting begrenzt den Schaden durch einen böswilligen Akteur; Disziplin bei der Call-Anzahl reduziert den Schaden, den ein normaler Nutzer allein durch die bestimmungsgemäße Nutzung des Produkts anrichten kann.

Wie das mit Vendor-Keys zusammenspielt

Wenn Sie einen verwalteten KI-Anbieter statt eigener Provider-Keys nutzen, fragen Sie ihn direkt, wie er den Traffic verschiedener Kunden voneinander isoliert und ob Limits pro Konto konfigurierbar oder fest vorgegeben sind. Das ist eine der Fragen, die Sie in jedes Anbieter-Gespräch einbringen sollten – neben den Preismodell-Fragen, die wir in BYOK vs. managed LLM keys skizzieren. Wenn ein Anbieter das nicht klar beantworten kann, gehen Sie davon aus, dass die Isolation nicht existiert, und planen Sie Ihr eigenes Gate unabhängig davon.

Das Minimum, das Sie vor dem Launch ausliefern sollten

Wenn Sie nur drei Dinge tun, bevor ein KI-Feature live geht: Setzen Sie ein nutzerbasiertes Token-Limit vor jeden LLM-Call, begrenzen Sie Tool-Call-Schleifen in jedem agentischen Flow, und stellen Sie sicher, dass Retries mit Backoff arbeiten, anstatt sich aufzuschaukeln. Das erfordert keine exotische Infrastruktur – eine Redis-Instanz und ein paar Dutzend Zeilen Middleware decken die meisten Produkte ab. Es ist eine günstige Absicherung gegen die eine Fehlerart, die aus einem ansonsten gut geführten KI-Feature einen Budgetposten macht, den Sie erklären müssen.

Wenn Sie ein KI-Feature planen und vor dem Launch eine zweite Meinung zu den Schutzmaßnahmen möchten, sprechen Sie uns an.