grok-bot
ea82f772ad
Tippfehler-Cluster (02–05, 09, 12, 23, 27–28) und Terminologie (Outcomes 16↔18, Budget 16↔23, prompt_version, Coding-Agent, fester Workflow). Handoff: Git-Remote, P0/P1A/P1B erledigt, nächster Slice Faktencheck.
13 KiB
Kosten, Latency, SLOs
Die Demo war „schnell genug“, das Budget „irgendwie im Cloud-Topf“. Nach dem Launch: die Monatsrechnung hat ein eigenes Slack-Channel, p95 liegt über der Aufmerksamkeitsspanne der Nutzer, und das Team diskutiert, ob man „einfach das billigere Modell“ nimmt — ohne zu wissen, € pro erfolgreichem Task oder welche Kaskade die Latenz frisst.
Kosten und Latenz sind keine Betriebsnachträge. Sie sind Produkt- und Architektureigenschaften (T7). Und ein SLO, der nur Uptime kennt, zertifiziert zuverlässigen Unsinn.
Kern in einem Satz: Steuert Unit Economics (€ pro erfolgreichem Task), Latency-Budgets (TTFT und Total) und SLOs inkl. Qualitätsmetriken — mit Caching, Routing, Caps und ehrlichen Trade-offs, nicht mit Hoffnung auf den nächsten Provider-Rabatt (T3, T7).
Anschluss: Tiers und Routing → Kapitel 09; Caps im Harness → Kapitel 16; Serving-Modi → Kapitel 21; Messung → Kapitel 22; Quality online → Kapitel 18. Envelope in der Spec: templates/ai-feature-spec.md.
Bridge: Klassisches SE → AI Engineering
| Klassisches SE | Bei Foundation-Model-Features … |
|---|---|
| €/Request, Compute-Units | €/Task und Tokens × Tier × Multiplikatoren (Repair, Tools, Cascade) |
| p50/p95 Latency | TTFT und Total; Multi-Hop-Summen |
| Caching (HTTP, CDN, Redis) | exakter Cache, semantischer Cache, Prompt-Prefix/KV wo verfügbar |
| Autoscaling | oft Quota und Token-Throughput; Self-Host: GPU-Util |
| Error Budget / SLO | Availability plus Latency plus Quality plus Cost Cap |
| Feature flag kill switch | Budget Cap und Tier-Downgrade als Steuerhebel |
| Capacity planning | Volumen × Tokens × Preis; Peak ≠ Average |
Die Brücke: ihr budgetiert probabilistische Arbeit mit variabler Tiefe. Ein „Request“ kann 1 oder 40 Model-Calls sein — ohne Caps gewinnt die Varianz.
Unit Economics: die richtige Größe
Nicht: € pro HTTP-Call allein
Besser:
€ pro erfolgreichem Task ≈
(Summe cost_estimate über alle Calls des Graphen)
/ (Tasks mit outcome in {success, success_degraded*})
*Degraded nur zählen, wenn die Spec ihn als akzeptablen Erfolg führt — sonst verzerrt ihr die Ökonomie.
Kostentreiber (Hebel-Reihenfolge oft so)
| Treiber | Hebel |
|---|---|
| Model-Tier | Routing, Cascade, nicht Strong-by-Default (Kapitel 09) |
| Tokens in | Context kürzen, RAG statt Dump, Memory-Tiers (Kapitel 10) |
| Tokens out | max_tokens, Structured Output statt Essay |
| Calls pro Task | weniger Steps, Repair-Cap, Agent-Caps (Kapitel 14, 16) |
| Retries | Fehlerklassen, Circuit Breaker (Kapitel 21) |
| Tools | weniger Roundtrips; teure Tools async |
| Shadow/Canary/Judge | Sample-Rate, nicht 100 % Doppelverkehr |
| Cache miss | Cache-Policy wo spez-konform |
Keine erfundenen Branchen-Benchmarks: eure Zahlen aus Telemetrie und Provider-Preisen mit Stand Monat Jahr in der internen Preis-Tabelle. Patterns oben bleiben, Preise nicht.
Decision Frame: lohnt Optimierung jetzt?
| Signal | Tendenz |
|---|---|
| €/success unbekannt | erst messen (Kap. 22) |
| ein Feature > X % der Rechnung | dort Routing/Context/Cache |
| Quality unter Spec | nicht blind billiger machen |
| Volumen noch winzig | Architektur sauber, Mikro-Opt später |
| Peak sprengt Quota | Admission + async + caps |
Caching: wo es hilft — und wo es lügt
| Cache-Art | Idee | Vorsicht |
|---|---|---|
| Exact | gleicher Request-Hash → gleiche Antwort | AuthZ/Tenant im Key; TTL; keine personalisierten Secrets |
| Semantic | ähnliche Query → treffer | Drift, falsche Treffer, Eval nötig; oft nur FAQ-artig |
| Retrieval/Doc | Chunks/Embeddings nicht neu holen | Freshness, Invalidierung |
| Tool result | idempotente Reads cachen | Stale Writes niemals |
| Provider prefix / KV (wo angeboten) | gemeinsame Prompt-Präfixe billiger/schneller | Anbieter-spezifisch; Stand prüfen; Spec nicht umbauen nur dafür |
Regeln
- Cache-Key inkl. Policy- und Prompt-Version, Tenant, Locale.
- Write-Pfade und personalisierte Decisions selten cachen.
- Cache-Hit in Traces (
cache_hit=true) — sonst optimiert ihr Blind. - Semantic Cache nur mit Akzeptanzkriterien und Stichproben; Halluzination aus dem Cache ist immer noch Halluzination, nur billiger.
Routing und Caps als Steuerhebel
Bereits in Kapitel 09 und 16 — hier die Wirtschafts- und SLO-Lesart:
| Hebel | Cost | Latency | Risiko |
|---|---|---|---|
| Fast/Cheap Default | ↓ | ↓ | Quality auf harten Cases |
| Cascade on hard signals | ↓ im Mittel | ↑ im Tail | doppelte Arbeit bei Eskalation |
| Strong everywhere | ↑↑ | ↑ | Budget- und p95-Brand |
| max_tokens / max_steps | ↓ | ↓ | abgeschnittene Tasks |
| Budget object (€, tokens, deadline) | hartes Limit | hartes Limit | mehr degrade/refuse |
| Async für Heavy | Peak glätten | UX anders | Komplexität |
Budget Caps gehören in die Spec-Envelope und in den Code — nicht nur in die Finance-Alarm-E-Mail nach Monatsende.
Budget: {
max_cost_per_request, # wie max_cost_eur im Orchestrierungs-State
max_cost_per_tenant_day,
max_tokens_per_request, # max_tokens im State
max_model_calls, # Teil von max_steps
max_repairs, # separat vom Retry-Budget (Kap. 16)
deadline_at
}
Dieselbe Envelope im Harness-State (Kapitel 16). Bei Überschreitung: spezifizierter Fallback (degrade, queue, refuse, human) — nicht still weitermachen.
Latency: budgetieren wie Features
Zerlegung
| Segment | Beispiel |
|---|---|
| Gateway / Auth | ms |
| Retrieval | oft 50–300 ms+ (Stack-abhängig) |
| Model TTFT | UX-kritisch bei Stream |
| Model Total | hängt von out-tokens und Last |
| Tools | Downstream-p95 |
| Validate/Repair | × zusätzliche Model-Zeit |
| Queue wait (async) | oft unterschätzt |
p95 Total ≈ Summe der p95-Segmente nur grob; Korrelation und Multi-Hop machen es schlimmer. Deshalb: messen, nicht addieren und beten.
Budgets in der Spec
| Größe | Nutzen |
|---|---|
| TTFT p95 (interactive stream) | „fühlt sich lebendig an“ |
| Total p95 (default path) | fertige Antwort |
| Total p95 (escalated path) | ehrlich getrennt |
| Hard deadline | Abbruch / degrade |
| Async Job p95/p99 | Erwartungsmanagement |
Streaming verbessert wahrgenommene Latenz; Token-Zeit und Kosten bleiben. UX-Framing: Fortschritt, ehrliche Wartezeiten bei Jobs (Kapitel 21).
Decision Frame: Latency drücken
| Engpass | Erste Hebel |
|---|---|
| TTFT hoch | kleineres/faster Tier, kürzerer Prefix, warm path, weniger cold tools before first token |
| Total hoch, ein Call | weniger out-tokens, Structured Output, Context kürzen |
| Total hoch, viele Calls | Pipeline straffen, parallelisieren wo unabhängig, Caps |
| Retrieval dominant | Index/Hot-Cache, weniger Roundtrips |
| Tool dominant | Timeouts, parallel reads, async writes |
SLO-Design für AI-Capabilities
Klassisch: Availability, Latency. Für AI erweitern:
| SLO-Typ | Beispiel-Form (Schwellen feature-spezifisch) |
|---|---|
| Availability | Anteil Requests mit Abschluss (kein infra-fail) ≥ … |
| Latency | TTFT p95 ≤ …; Total p95 default ≤ … |
| Quality | Task-success ≥ …; oder human-reject ≤ …; repair_rate ≤ … |
| Safety | kritische Policy-Violations = 0 im Fenster (oder Incident) |
| Cost | €/success ≤ …; oder Tagesbudget Feature ≤ … (Burn-Alert) |
Error Budget — angepasst
- Latency/Availability-Budget wie gewohnt.
- Quality Budget: erlaubte Verschlechterung vs. Baseline bevor Rollback/Canary-Stop.
- Cost Budget: erlaubter Overspend bevor Kill-Switch/Tier-Down.
Ohne Quality im SLO steuert On-Call nur die grüne HTTP-Welt (Kapitel 18).
Trade-off: strenge vs. lockere SLOs
| Streng | Locker |
|---|---|
| früher Druck, mehr Invest | Launch schneller |
| mehr degrade/refuse | mehr User-Schmerz |
| braucht Messung | Schein-Ruhe |
Start: wenige SLOs an der Top-Capability, Schwellen aus Spec und realer Baseline — nicht aus Blog-„Industry average“.
Patterns und Trade-offs
Pattern: Cost envelope in every feature spec
Max €/Task, max Tokens, erwartetes Volumen — vor dem Bau.
Trade-off: Schätzungen falsch am Anfang; trotzdem bessere Architekturgespräche.
Pattern: Two-path economics
Default-path und escalated-path getrennt budgetieren und reporten.
Trade-off: mehr Metriken; verhindert „Mittel ok, Tail ruiniert uns“.
Pattern: Progressive spend
Cheap checks zuerst (rules, small model, retrieval hit?) bevor Strong.
Trade-off: etwas Orchestrierung; oft der größte €-Hebel.
Pattern: Tenant fair share
Tages-/Minuten-Budgets pro Tenant; noisy neighbor isolieren.
Trade-off: Produkt-/Pricing-Klärung; rettet Shared-Quota.
Trade-off: Qualität vs. € vs. Latenz
Quality
/\
/ \
/ \
Cost ---- Latency
Ihr bewegt euch im Dreieck. „Alles gleichzeitig maximieren“ ist kein Plan. Die Spec priorisiert; Routing und Caps implementieren die Priorität.
| Wenn Priorität … | Typische Wahl |
|---|---|
| Quality (hohes Risiko) | Balanced/Strong, mehr HITL, teurer ok |
| Cost (High-QPS) | Fast/Cheap, Cache, strenge Caps |
| Latency (Interactive) | kurze Contexts, few hops, stream, async heavy |
Anti-Patterns
| Anti-Pattern | Symptom | Besser |
|---|---|---|
| Cloud-bill as metric | eine Zahl, keine Features | €/feature, €/success |
| Optimize model only | Context 100k Tokens | T4 zuerst |
| max_tokens = 4096 default | Essay-Kosten | task-spezifisch |
| Unbounded agent | Rechnung + p99-Horror | Caps (Kap. 14/16) |
| Cache alles | falsche personalisierte Antworten | Keys + Policy |
| SLO without quality | stabiler Müll | Quality-SLO |
| Latency theater | nur p50 feiern | p95/p99 + TTFT |
| Save money after launch only | Panik-Routing | Envelope vor Launch |
| One global cost alert | zu spät, zu grob | feature + tenant burn |
| Ignore multiplikators | „Modellpreis × Requests“ | calls/repair/tool zählen |
Production Notes
Cost. Preis-Tabellen und cost_estimate aktuell halten (Stand im Config). Shadow, Eval-as-Prod-Sample und Online-Judge ins Budget einplanen. Finance und Engineering teilen dieselbe Attribution (T7).
Latency. SLOs an realen Pfaden; Synthetic getrennt ausweisen. Multi-Region und Provider-Peaks: Fallback kann Latency und Cost gleichzeitig ändern — messen.
Observability. Ohne Token- und Segment-Latenz keine Steuerung (Kapitel 22, observability-minimum.md). Cost-Spike-Alert ist Incident-Eingang (Kapitel 25).
Security. Kosten-Attacken (Prompt-Flooding, absichtlich lange Outputs) sind Abuse-Fälle: Rate Limits, Caps, AuthZ (Kapitel 19). Logging von Cost-Metadaten ist unkritischer als Prompt-Bodies.
Lifecycle. Model-Change: Cost- und Latency-Estimate vor Rollout, Canary-Stop bei Envelope-Bruch (model-change-checklist.md, Kapitel 24). Owner für Envelope und SLO-Reviews (T10).
Key Takeaways
- Steuert € pro erfolgreichem Task, nicht nur die Monatsrechnung.
- Kostentreiber: Tier, Tokens, Calls/Repairs/Tools, Retries — Hebel in Routing, Context, Caps, Cache.
- Latency: TTFT und Total, Pfade getrennt budgetieren und messen.
- SLOs für AI: Availability + Latency + Quality + Cost-Burn.
- Caching hilft nur mit korrekten Keys, TTL und spez-konformen Treffern.
- Das Quality-Cost-Latency-Dreieck explizit priorisieren — in der Spec, nicht im Incident.
Praktische nächste Schritte
- Berechnet für die Top-Capability grob €/success aus einer Woche Telemetrie (oder Provider-Export + Feature-Key).
- Tragt Cost- und Latency-Envelope in die Feature-Spec nach; fehlt sie, ist das der Bug.
- Setzt Request- und Tenant-Budget-Caps mit definiertem Fallback.
- Zerlegt p95 in Segmente (retrieve/model/tools); adressiert den größten Balken zuerst.
- Formuliert 1 Quality-SLO und 1 Cost-Burn-Alert neben Latency.
- Prüft Cache-Möglichkeiten nur für idempotente, authZ-sichere Reads.
- Weiter im Lebenszyklus: Wartung und Model-Lifecycle — ein Model-Swap kann alle drei Größen gleichzeitig verschieben.