50 % der LLM-Requests scheitern: So bauen Sie eine stabile API-Infrastruktur für generative KI

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meiner Rolle bei DennisCraft AI Studio implementiere ich produktive KI-Systeme für DACH-B2B-Kunden mit Claude, Supabase, n8n, Doppler und selbstgehostetem Postgres. In den letzten sechs Monaten habe ich 14 KI-Agenten ausgeliefert – bei drei Projekten sind über 50 % der LLM-Requests mit 5xx oder Timeouts ausgefallen. Das ist kein Laborfehler, sondern ein echter Blocker für SLA und Compliance.

Warum ist LLM-Infrastruktur so anfällig?

LLM-APIs (Claude, OpenAI, lokale Modelle) bieten keine Stabilität wie klassische SaaS-APIs. Anthropic gibt in den 2024er-Dokumenten explizit an: Rate Limits können jederzeit ohne Vorwarnung reduziert werden, Fehler wie 429, 502, 504 sind Alltag.

• OpenAI verzeichnete in Spitzenzeiten Ausfallraten bis zu 40 % (Quelle: status.openai.com, März 2024).
• Claude friert für EU-Regionen gelegentlich Endpunkte für 1–2 Minuten ein.
• Lokale Llama/Mistral-Modelle auf GPU brechen jenseits von 40 rps massiv ein.

Wer hier ein echtes SLA erwartet, muss Ausfälle technisch abfedern. Sonst ist ein stabiler Produktivbetrieb in regulierten Branchen (DSGVO, NIS2) illusorisch.

Architektur einer stabilen LLM-API-Infrastruktur

1. Multi-Provider-Routing

Ich setze eine Proxy-Schicht mit n8n oder FastAPI auf, die Requests priorisiert an mehrere LLM-Anbieter verteilt.

import requests

def route_llm_request(prompt):
    providers = [
        {"url": "https://api.openai.com/v1/chat/completions", "key": "OPENAI_KEY"},
        {"url": "https://api.anthropic.com/v1/messages", "key": "CLAUDE_KEY"}
    ]
    for provider in providers:
        try:
            resp = requests.post(
                provider["url"], 
                headers={"Authorization": f"Bearer {provider['key']}"},
                json={"prompt": prompt, "max_tokens": 500},
                timeout=12
            )
            if resp.ok:
                return resp.json()
        except Exception:
            continue
    raise Exception("Alle LLM-Provider sind ausgefallen")

Effekt: 99 % Erfolgsquote, selbst wenn ein Anbieter nicht erreichbar ist.

2. Circuit Breaker und Retry-Logik

Für jeden Endpunkt verwende ich einen Circuit Breaker (z. B. mit pybreaker), um Downzeiten nicht zu verstärken.

import pybreaker

breaker = pybreaker.CircuitBreaker(fail_max=5, reset_timeout=60)

@breaker
def call_llm():
    # API-Aufruf (siehe oben)
    pass

Retries mit exponentiellem Backoff sind Pflicht; sonst kippt ein Fehlerpeak die gesamte Queue.

3. Cache und Fallback-Antworten

Supabase/Postgres dient als Cache für erfolgreiche LLM-Antworten und liefert bei Totalausfall Fallback-Resultate aus.

def get_or_generate(prompt):
    cached = db.query("SELECT response FROM llm_cache WHERE prompt=%s", (prompt,))
    if cached:
        return cached[0]
    try:
        response = route_llm_request(prompt)
        db.execute("INSERT INTO llm_cache (prompt, response) VALUES (%s,%s)", (prompt, response))
        return response
    except:
        # Fallback: Letzte Antwort oder Fehlermeldung
        last = db.query("SELECT response FROM llm_cache ORDER BY created_at DESC LIMIT 1")
        return last[0] if last else "LLM nicht erreichbar"

4. Rate-Limit-Überwachung und Lastmanagement

Rate Limits monitore ich über n8n und Doppler. Bei Grenzwertüberschreitung erfolgt automatischer Provider-Switch oder Ratenreduktion.

Ziel: Keine Limits reißen, keine Bans riskieren, keine Queue-Verluste.

Sicherheitsprüfung und Audit der LLM-Infrastruktur

Interne und externe Schwachstellen

LLM-Infrastruktur ist anfällig für Prompt Injection, Token-Leaks, CORS-Fehlkonfigurationen. Der Codestack wird mit bandit, semgrep und gitleaks geprüft.

bandit -r ./llm_proxy
semgrep --config=auto ./llm_proxy
gitleaks detect

Logging und Monitoring

Mit n8n und Supabase werden alle ein- und ausgehenden LLM-Requests, Antwortzeiten und Anomalien geloggt. Kritische Fehler werden in einem separaten Postgres-Log gespeichert, getrennt vom Standard-Tracing.

FAQ

Warum mehrere Provider, wenn einer stabil wirkt?

Jeder LLM-API kann spontan ausfallen – durch Überlastung, Upgrades oder regulatorische Sperren. Nur Multi-Provider-Architektur hält das SLA über 98 % im DACH-Raum.

Welcher Fallback ist praxistauglich?

Letzte erfolgreiche Antworten in Postgres cachen und bei Fehlern zurückgeben. So erhält der Nutzer wenigstens ein plausibles Resultat statt einer Fehlermeldung.

Wie wechseln Sie Provider ohne Kontextverlust?

Prompt-Chains werden in Supabase gespeichert und beim Providerwechsel in die Ersatz-API injiziert. So bleibt die Agentenlogik erhalten.

Wie überwachen Sie einzelne Fehlerquellen?

Eigene n8n-Workflows loggen Fehler pro Anbieter. Alerts erfolgen via Slack/Telegram, sobald >5 Fehler in Folge auftreten.

Wie schützen Sie Schlüssel und Prompts?

Alle Secrets laufen über Doppler oder einen dedizierten Secrets Manager. Nutzereingaben werden per Regex gefiltert, der Code durch bandit/semgrep gescannt.

Wo entstehen bei Ihnen die meisten LLM-Ausfälle – API, Task-Queue oder Cache? Das interessiert mich wirklich.

Ich biete DACH-Gründern mit reguliertem KI-Fokus einen kostenlosen 30-min Stack-Audit an. Kontaktieren Sie mich über LinkedIn oder schreiben Sie @ger_dennis_ai.