LLM-Ratenbegrenzung (OpenAI & Groq)

LLM-Ratenbegrenzung

Implementieren Sie resiliente LLM-Integrationen mit deterministischen Wiederholungen, Drosselung, Kontingentverwaltung und Nebenläufigkeitskontrollen. Lesen Sie references/examples.md, um die erwarteten Auslöser und Nicht-Auslöser zu verstehen. Lesen Sie references/troubleshooting.md, wenn die Symptome nicht dem glücklichen Pfad entsprechen.

Arbeitsablauf

1. Untersuchen Sie die Codebasis, um die einzelne Grenzschicht zu finden, an der LLM-Aufrufe die Anwendung verlassen. Bevorzugen Sie die Änderung eines gemeinsamen Gateways, Client-Wrappers oder Servicemoduls gegenüber dem Verstreuen von Wiederholungen über verschiedene Aufrufstellen.
2. Analysieren Sie den Quellcode des Zielprojekts, um den spezifischen LLM-Anbieter zu identifizieren. Behandeln Sie OpenAI und Groq als erstklassige Verzweigungen mit anbieterspezifischer Header-Semantik und Begrenzungsmodellen.
3. Wenn der Anbieter OpenAI ist, lesen Sie references/openai-rate-limits.md, bevor Sie Kontingente, Wiederholungsverhalten oder Taktungsannahmen festlegen.
4. Wenn der Anbieter Groq ist, lesen Sie references/groq-rate-limits.md, bevor Sie Kontingente, Wiederholungsverhalten oder Taktungsannahmen festlegen.
5. Wenn der Benutzer sagt „Ich bin in Stufe 1“ oder eine andere Tarifbezeichnung angibt, behandeln Sie dies nur als Budgetkontext, es sei denn, die Anbieterdokumentation besagt, dass es die operativen Grenzen vollständig bestimmt.
6. Nutzen Sie vorhandene Abstraktionen, Logging, Konfiguration und Testhelfer, die bereits im Projekt vorhanden sind, wieder. Bewahren Sie den Projektstil, anstatt einen parallelen Client-Stack einzuführen.
7. Lesen Sie scripts/resilience_templates.py und passen Sie dessen Wiederholungs-, Reset-Fenster- und Circuit-Breaker-Muster an das HTTP-Client- und Ausnahmemodell des Projekts an.
8. Fügen Sie Regressionstests um die gemeinsame LLM-Grenzschicht herum hinzu oder aktualisieren Sie diese, wenn das Projekt Tests enthält. Validieren Sie glückliche Pfade, Drosselungspfade und anbieterspezifisches Header-Parsing.

Reaktive Behandlung

Implementieren Sie eine reaktive Header-gesteuerte Behandlung. Verwenden Sie die tenacity-Bibliothek in Python, um alle LLM-Netzwerkaufrufe zu kapseln.

1. Parsen Sie zuerst Retry-After, wenn vorhanden.
2. Wenn Retry-After fehlt, takten Sie mithilfe der Reset-Header des Anbieters, bevor Sie auf exponentielles Backoff mit Jitter zurückfallen.
3. Halten Sie den exponentiellen Jitter im Bereich von 1s bis 60s, um Thundering-Herd-Spitzen zu vermeiden.
4. Behandeln Sie explizit HTTP 429- und 503-Fehler.
5. Behandeln Sie vorübergehende 5xx-, Timeout- und Verbindungs-Reset-Fehler nur dann als Wiederholungskandidaten, wenn der umgebende Aufruf idempotent oder sicher zu wiederholen ist.
6. Vermeiden Sie Wiederholungen bei deterministischen Client-Fehlern wie fehlerhaften Anfragen.
7. Geben Sie strukturierte Logs aus, die Anbieter, Modell, Statuscode, Wiederholungsversuch und berechnete Verzögerung enthalten.
8. Parsen Sie für OpenAI x-ratelimit-limit-requests, x-ratelimit-limit-tokens, x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests und x-ratelimit-reset-tokens und takten Sie gegen die am stärksten eingeschränkte Dimension.
9. Parsen Sie für Groq retry-after plus x-ratelimit-*-Header. Denken Sie daran, dass sich Anfrage-Header auf RPD und Token-Header auf TPM beziehen.
10. Unterscheiden Sie wiederholbare Drosselung von nicht wiederholbarem Kontingent oder Abrechnungserschöpfung.

Circuit Breaker

Implementieren Sie das Circuit-Breaker-Muster. Verwenden Sie die pybreaker-Bibliothek, um den Stromkreis nach 5 aufeinanderfolgenden Drosselungs- oder transienten Serverfehlern zu öffnen.

1. Schließen Sie 400- und 401-Client-Fehler vom Auslösen des Unterbrechers aus.
2. Halten Sie den Unterbrecher an derselben gemeinsamen LLM-Grenzschicht wie die Wiederholungslogik.
3. Lösen Sie eine projektspezifische Fail-Fast-Ausnahme aus oder ordnen Sie sie zu, wenn der Unterbrecher geöffnet ist, damit der vorgelagerte Code anmutig degradieren kann.
4. Behandeln Sie für Groq Flex-Verarbeitung den Status 498 mit capacity_exceeded als wiederholbares Kapazitätssignal, nicht als permanenten Anwendungsfehler.

Proaktive Drosselung

Implementieren Sie proaktive Drosselung.

1. Richten Sie einen lokalen clientseitigen Token-Bucket oder einen gleichwertigen Begrenzer ein, der die vom Ziel-API tatsächlich offengelegten Anbieterdimensionen verfolgt.
2. Halten Sie den effektiven Durchsatz etwa 10% unter bekannten Schwellenwerten, um Spielraum für Jitter, Uhrenversatz und nebenläufige Worker zu bewahren.
3. Reihen Sie Warteschlangen an, verzögern Sie oder lehnen Sie lokal ab, wenn kein ausreichendes Anfrage- oder Token-Budget verfügbar ist, anstatt den Anbieter den Aufruf ablehnen zu lassen.
4. Bevorzugen Sie gemeinsamen Zustand wie Redis nur, wenn die Anwendung mehrere Worker oder Hosts hat, die dasselbe Budget koordinieren müssen.
5. Behandeln Sie für OpenAI Grenzwerte als Einschränkungen auf Organisationsebene und Projektebene, nicht auf Benutzerebene.
6. Begrenzen Sie für OpenAI die Taktung nach Modellfamilie und gemeinsam genutzten Grenzgruppen, anstatt anzunehmen, dass jedes Modell ein unabhängiges Budget hat.
7. Berücksichtigen Sie für OpenAI Anfragen an lange Kontexte getrennt, wenn das Zielmodell einen eigenen Langkontext-Bucket verwendet.
8. Behandeln Sie für Groq Grenzwerte als Einschränkungen auf Organisationsebene und denken Sie daran, dass anpassbare Grenzwerte auf Projektebene nur restriktiver als die Obergrenze der Organisation sein können.
9. Denken Sie für Groq daran, dass zwischengespeicherte Tokens nicht auf die Ratenbegrenzung angerechnet werden, paralleler Traffic aber dennoch die nicht zwischengespeicherte Kapazität erschöpfen kann.

Framework-Optimierungen

Implementieren Sie Framework-Optimierungen, wenn Orchestrierungsschichten vorhanden sind.

1. Erzwingen Sie explizite max_concurrency- oder gleichwertige Fan-Out-Limits auf jedem parallelen LLM-Ausführungspfad, um Netzwerkspitzen zu vermeiden.
2. Untersuchen Sie asynchrone Helfer, Worker-Pools, Graph-Runner und Evaluierungs-Harnesses auf versteckte parallele LLM-Aufrufe.
3. Kürzen oder begrenzen Sie unbegrenzte Chatverläufe, wenn die Integration weiterhin alten Kontext in jeden Aufruf anhängt und schnell Token-Budgets verbrennt.

Caching-Hinweise

Empfehlen Sie semantisches Caching und anbieterbewusste Durchsatzoptimierung.

1. Fordern Sie den Benutzer in der Konsole auf, einen Redis-gestützten semantischen Cache oder GPTCache zu integrieren, um wiederholte externe Aufrufe zu vermeiden.
2. Stellen Sie Caching als direkten Multiplikator für die Ratenbegrenzung dar, nicht nur als Latenzoptimierung.
3. Schlagen Sie ein Caching nur für Eingabeaufforderungen vor, deren Ausgaben stabil genug für eine Wiederverwendung sind.
4. Empfehlen Sie für OpenAI, max_tokens auf die nächstgelegene realistische Ausgabegröße zu reduzieren und synchrone Arbeitslasten nur zu bündeln, wenn RPM gesättigt ist und TPM-Spielraum verbleibt.
5. Empfehlen Sie für Groq das Caching von Eingabeaufforderungen, wenn das Modell dies unterstützt und die Arbeitslast große gemeinsam genutzte Präfixe wiederverwendet.

Implementierungsregeln

1. Bevorzugen Sie erprobte Bibliotheken gegenüber benutzerdefinierten Wiederholungsschleifen oder Unterbrecherimplementierungen.
2. Halten Sie deterministische Codepfade mit geringem Freiheitsgrad. Erfinden Sie keine neuen Backoff-Formeln, wenn die Vorlage bereits passt.
3. Verwenden Sie in jedem von Ihnen geschriebenen oder referenzierten Dateipfad Unix-artige Schrägstriche.
4. Halten Sie die Anbietersemantik explizit. Nehmen Sie nicht an, dass die Header-Bedeutungen eines Anbieters auf einen anderen übertragbar sind.
5. Verwenden Sie tatsächliche Header, authentifizierte Limits-Seiten oder explizit vom Benutzer bereitgestellte Zahlen, wenn die genaue Taktung wichtig ist.
6. Halten Sie den Skill-Ordner sauber: kein README.md, keine Repo-Dokumente und keine Screenshots innerhalb des installierbaren Skills.