Zum Hauptinhalt springen
Kern•8–14 Stunden

Labor für AI-Kapazität, Kosten und Chaos

Teste eine AI-Workload unter Last: Concurrency, Token-/Tool-Budgets, Queues, Backpressure, 429/5xx/Timeouts, Load Shedding, Degraded Mode und Kosten pro erfolgreich verifizierter Aufgabe.

KapazitätsplanungAutoscalingQueueingBackpressureFehlerinjektionAI Unit Economics

Szenario

Aufgabe

Ein AI-Endpunkt ist unter Demo-Last stabil, aber Production-Traffic hat bursty Arrival Rates, lange Contexts, parallele Tool Calls und Provider-Quotas. Reines CPU-Autoscaling löst Token Throughput, Queue Delay, 429, Retry Amplification oder Cost Explosion nicht. Erstelle ein Kapazitätsmodell, das erfolgreich verifizierte Aufgaben statt nur laufender Pods misst.

Schrittweise Umsetzung

1. Workload-Modell erstellen

Ergebnis: Kapazitätsplanung berücksichtigt AI-spezifische Nachfrage statt nur durchschnittlicher HTTP-Requests.

Aufgaben

  • →Arrival Rate und Burstiness messen
  • →Input-/Output-Token-Verteilungen erfassen
  • →Tool-Call-Fan-out und langsamste Dependency festhalten
  • →User-facing, Batch und High-Priority Workloads trennen

Prüfungen

  • ✓P95/P99-Workload unterscheidet sich vom Durchschnitt
  • ✓Unbekannte Quota- oder Provider-Limits werden als Risiko markiert
  • ✓Priority Policy führt nicht zum Starvation kritischer Aufgaben

2. Budgets und Scaling-Signale festlegen

Ergebnis: Autoscaling reagiert auf Saturation, Queue und Token Throughput statt nur auf CPU.

Aufgaben

  • →Concurrency Ceiling definieren
  • →Token-/Tool-/Zeitbudgets festlegen
  • →Queue Age/Depth und Saturation-Signale ergänzen
  • →Kosten pro erfolgreich verifizierter Aufgabe berechnen

Prüfungen

  • ✓Budget-Erschöpfung beendet oder degradiert Aufgaben kontrolliert
  • ✓Scaling-Signal hat kausalen Bezug zum Bottleneck
  • ✓Fehlgeschlagene oder unsichere Aufgaben zählen nicht als Erfolg

3. Chaos- und Lasttests durchführen

Ergebnis: Bekannte Overload- und Dependency-Fehler erzeugen vorhersagbare Systemreaktionen.

Aufgaben

  • →429/5xx/Timeouts injizieren
  • →Tool- oder Retrieval-Dependency verzögern
  • →Burst mit Long-Context-Requests erzeugen
  • →Retry Amplification und Queue Recovery prüfen

Prüfungen

  • ✓Keine unendlichen Retries oder unbegrenztes Queue-Wachstum
  • ✓Lasttest umgeht keine Tenant-/Risk-Limits
  • ✓Recovery erzeugt keinen zweiten Spike durch synchronisierte Retries

4. Graceful Degradation verifizieren

Ergebnis: Bei knapper Kapazität reduziert das System Funktionalität, nicht Kontrolle.

Aufgaben

  • →Load Shedding testen
  • →Günstigeres/Fallback-Modell nur für geeignete Aufgaben verwenden
  • →Nicht essentielle Tools deaktivieren
  • →Recovery- und Re-entry-Kriterien dokumentieren

Prüfungen

  • ✓Fallback erfüllt den minimalen Eval-Vertrag
  • ✓Degraded Mode erhöht die Autonomie nicht
  • ✓Normal Mode startet erst nach stabilisierten Dependencies

Akzeptanzkriterien

  • Das Workload-Modell enthält Burst-, Token-, Tool-, Queue- und Provider-Quota-Eigenschaften
  • Die Capacity Policy besitzt begrenzte Concurrency-/Token-/Tool-/Zeitbudgets und explizite Autoscaling-Signale
  • Die Chaos Suite deckt 429, 5xx, Timeout, langsame Dependency, Quota-Erschöpfung und Retry Amplification ab
  • Load Shedding/Degraded Mode erhält Authority- und Privacy-Grenzen unverändert
  • Kosten werden pro erfolgreich verifizierter Aufgabe statt pro Request bewertet