Bedrock-Kosten-Optimierung
Ausloeser
Cost-Explorer-Lookup am 2026-05-17: Sonnet 4.6 in eu-central-1 hat in Mai (1.-17.) **0. Input/Output-Ratio 95:1 (12.31M In / 0.13M Out) — Geld steckt fast vollstaendig in System-Prompts + Kontext-Injection, nicht in Antworten. Kein Prompt-Caching aktiv (kein Cache Read-Usage-Type im Cost-Explorer).
Akut-Findings (2026-05-17)
| Sev | Befund | Wirkt auf | Action-Phase |
|---|---|---|---|
| ROT | Kein Application Inference Profile pro Caller — wir wissen nicht wer die 12.3M Input-Tokens frisst | alle Bedrock-Caller | Phase 4 |
| ROT | Kein AWS Budget-Alarm + keine Budget-Action — Runaway-Loop koennte ueber Nacht $500+ machen | Account av-production | Phase 3 |
| ROT | Keine max_tokens-Caps in eigenen Callern dokumentiert — Default Sonnet 4.5 ist 8192 | mcp-whatsapp Brain, Lambda-Routinen, Open-WebUI | Phase 3 |
| GELB | MCP-Tool-Descriptions vermutlich nicht token-optimiert — mcp-papierkram hat ~70 Tools | Eigenbau-MCPs | Phase 5 (nach Daten) |
| GELB | Open-WebUI VF-System-Prompt + RAG-Settings (Top-K, Chunk-Size) nicht auditiert | Open-WebUI VF-Pilot | Phase 5 |
| GELB | Cohere Embed Multilingual (1.44) in Mai — Titan v2 5x billiger wo keine Cross-Lingual-Suche | RAG-Pipelines | Phase 5 |
| GELB | Prompt-Caching 1h-TTL (seit Jan 2026) noch nicht Default | Caller mit System-Prompt > 1k Tokens | Phase 5 (parallel-Session) |
| GRUEN | Modell-Routing Haiku-First wird parallel schon implementiert | Open-WebUI, mcp-whatsapp | Phase 5 (parallel-Session) |
Ziel-Architektur
Drei Ebenen die nach dem Projekt eingebaut sind:
- Sichtbarkeit — Application Inference Profile pro Caller + Cost-Allocation-Tags in Billing → Cost Explorer zeigt direkt welcher Caller wie teuer ist.
- Notbremsen — Budget+Action,
max_tokens-Caps, Stop-Sequences, Bedrock-Service-Quotas. Verhindert Runaway-Kosten, unabhaengig von Caller-Bugs. - Compounding-Disziplin — Token-Audit als Pflicht-Check fuer alle zukuenftigen MCPs und Lambdas, verankert in
mcp-best-practices,mcp-eigenbau-Skill,routine-anlegen-Skill.
Das Wiederverwendbare wandert in einen neuen Skill bedrock-cost-optimize (siehe Phase 3) — der Skill ist Cause + Effect dieses Projekts.
Sub-Files
- Roadmap — alle 6 Phasen in zeitlicher Reihenfolge, Abhaengigkeiten, Schaetzungen
- Caller-Inventar — alle Bedrock-Caller mit Audit-Status pro Hebel
- Phase 1 — Discover — wer ruft was wann, ohne aendern
- Phase 2 — Baseline — Token-Counts pro Caller messen
- Phase 3 — Gate + Skill-Scaffold — Notbremsen + Skill anlegen
- Phase 4 — Profile — AIPs + Tags + 3 Tage messen
- Phase 5 — Optimize — datengetriebene Tier-2-Hebel
- Phase 6 — Compound — Wissen in den Vault zurueckspielen
Erfolgs-Kriterien
- Bedrock-Modell-Kosten in Juni < 42.77 in halbem Monat = Trend $85+)
- Cost Explorer zeigt fuer jeden Bedrock-Call den Caller (via AIP)
- Jeder neue MCP / jede neue Lambda durchlaeuft Token-Audit vor Live-Gang (verankert in
mcp-eigenbau+routine-anlegen) - Budget-Action existiert und wuerde bei $80 hart abriegeln
Out-of-Scope
- Modell-Wahl-Strategie (Sonnet vs Haiku vs Opus) — laeuft in anderer Session, nicht hier doppelt definieren
- Prompt-Caching-Implementierung — laeuft in anderer Session, hier nur als Defaults im Skill verankern
- Open-WebUI-Feature-Roadmap — Optimierung beruehrt nur Settings (System-Prompt, RAG-Params), keine Features