How-to: GenAI-Kosten mit Budgets, Rate Limits und Telemetrie in den Griff bekommen (FinOps)

GenAI-Kosten können schnell explodieren, wenn Budgets und Limits nicht von Anfang an klar definiert sind. In diesem How-to zeige ich, wie sich sinnvolle Guardrails für den GenAI-Betrieb einrichten lassen — ohne die Innovation auszubremsen. GenAI-Kosten eskalieren meist durch fehlende Limits und fehlende Transparenz. Dieses How-to zeigt eine praxistaugliche Steuerung: Budgetierung, technische Rate Limits, Logging pro Use Case und ein „Kill Switch“ für Incidents.

Problem sauber definieren

Typische Kostentreiber:

• Unkontrollierte Experimente (Playground/Notebooks)
• Prompts mit großen Kontexten (RAG ohne Top-k/Chunking)
• Fehlende Cache-Strategie
• Keine Trennung nach Teams/Use Cases

Ziel: Kosten je Use Case nachvollziehen und harte Leitplanken setzen.

Schritt-für-Schritt: Governance-Setup

1) Einheitliches Tagging / Attribution festlegen

Definiere Pflichtfelder (mindestens):

• app (Produkt/Service)
• team
• env (dev/stage/prod)
• use_case
• cost_center

Wenn dein Provider kein Tagging unterstützt, packe es in deine Gateway/Proxy-Layer (Header/Metadata) und schreibe es in Logs.

2) Budget- und Alarm-Policy erstellen

Minimum:

• Monatsbudget pro team und pro use_case
• 50/80/100%-Alerts an Teams + FinOps

Beispiel-Policy (pseudo):

BUDGET team=search  month=2000 EUR
  ALERT at 50% -> team channel
  ALERT at 80% -> team + finops
  HARD STOP at 100% -> block non-prod, require approval for prod

3) Rate Limits technisch erzwingen (Gateway)

Lege Limits fest nach:

• API Key / Client ID
• use_case
• Umgebung

Beispiel NGINX (vereinfacht):

limit_req_zone $http_x_api_client zone=genai:10m rate=5r/s;

server {
  location /v1/chat/completions {
    limit_req zone=genai burst=20 nodelay;
    proxy_pass http://genai_backend;
  }
}

4) Request/Response-Telemetrie loggen (ohne sensible Inhalte)

Logge:

• timestamp
• client/team/use_case
• model
• tokens_in/tokens_out (oder chars)
• latency
• status/fehler

Wichtig: keine Prompts im Klartext in Standard-Logs, sondern ggf. Hash/Redaction.

5) Kill Switch definieren

Für Incidents (Kostenexplosion, Data Leak):

• Zentraler Schalter, der Requests blockt oder nur „approved“ Clients zulässt
• Runbook mit Verantwortlichen und Eskalationswegen

Beispiel (Feature Flag / Config):

# pseudo: toggling a flag in your config store
curl -X POST https://config.example/api/flags/genai_enabled -d 'false'

Schritt-für-Schritt: Kosten pro Use Case aus Logs ableiten

Angenommen du schreibst JSON-Logs wie:

{"team":"search","use_case":"supportbot","model":"gpt-4.1","tokens_in":1200,"tokens_out":300,"cost_eur":0.12}

Ein schneller Tagesreport:

jq -s '
  group_by(.team + "|" + .use_case)
  | map({
      key: (.[0].team + " / " + .[0].use_case),
      cost: (map(.cost_eur) | add),
      tokens_in: (map(.tokens_in) | add),
      tokens_out: (map(.tokens_out) | add)
    })
  | sort_by(.cost)
  | reverse
  | .[0:10]
' genai-usage.json

Optimierungshebel (Quick Wins)

Kontext reduzieren

• Top-k in RAG senken
• Chunk-Größe optimieren
• System Prompt schlank halten

Caching

• Prompt + retrieved context hashen
• Antwort für identische Anfragen (mit TTL) cachen

Model Routing

• Kleine Modelle für „easy path“
• Große Modelle nur für komplexe Fälle (Classifier/Guardrail davor)

Betriebs-Checkliste (monatlich)

• Top 10 Use Cases nach Kosten prüfen
• Limit-Policy aktualisieren (neue Teams/Keys)
• Token-Drift (Kontext wächst) erkennen
• Missbrauchsindikatoren (spikes, ungewöhnliche Clients)
• Retention/Privacy-Review der Logs

Takeaways

• Ohne Attribution (team/use_case/env) bleibt FinOps bei GenAI Blindflug.
• Budgets + Alerts sind gut; Rate Limits + Kill Switch sind besser.
• Logge Kostenmetrik „nah“ an der technischen Nutzung (Gateway), nicht nur im Billing.
• Optimierung beginnt fast immer beim Kontext (RAG) und beim Model Routing.
• Baue einen klaren Incident-Prozess für Kosten- und Data-Themen.