Bedrock-Caller-Inventar
Eine Zeile pro Caller. Status pro Hebel: β¬ offen, π‘ in Arbeit, β erledigt, β N/A.
Bestaetigte Caller (nach Phase 1)
Stand 2026-05-17, Quelle: aws ecs list-services, aws lambda list-functions, ECS-Task-Definitions in av-production (Account 425924867359).
ECS-Services im Cluster default
| Service | Container-Image | Vermutlich ruft Sonnet 4.6? |
|---|---|---|
open-webui-vf | open-webui/open-webui + litellm (Sidecar) + cloudflared | ja (Hauptverdaechtiger) β LiteLLM-Sidecar leitet auf Bedrock |
mcp-vf-hosted | (Mono-MCP-Container + cloudflared) | indirekt β selbst kein Brain, aber kann Routing-Calls machen |
McpWhatsappHosted | mcp-whatsapp + cloudflared | ja (Brain-Logic) |
McpCalcomHosted | mcp-calcom + cloudflared | nein (reiner API-Wrapper) |
ECS-Service im Cluster inference-service-prod
| Service | Container-Image | Was ist das? |
|---|---|---|
inference-service-prod | inference-service-prod:latest + cloudflared | a-icking AI-Rebuild β FastAPI, PG leistungskatalog, Embedding-Provider cohere_multilingual_v3, BEDROCK_REGION=eu-central-1. Siehe _index |
Lambdas (Region eu-central-1, andere Regionen leer)
| Lambda | Invocations 12.-15.05. | Ruft Bedrock? |
|---|---|---|
receptionist-brain | 15 (alle 15.05.) | ja (Brain) |
av-voice-bot-handler | 0 | (telefon-assistent, nicht aktiv im Burst) |
agent-daily-briefing | 6 (2/Tag 12.-14.05.) | ja |
agent-beleg-pipeline | 130 (48 + 82 am 12.+13.05.) | wahrscheinlich (Klassifikation) |
agent-tool-error-digest | 2 (15.05.) | wahrscheinlich (Digest-Schreiben) |
agent-dashboard-refresh | unbekannt | nein (vermutlich) |
Diverse *-LogRetention* | n/a | nein (CDK-Boilerplate) |
Andere Regionen
us-east-1 / us-west-2 / us-east-2: keine Lambdas/Services mit Bedrock-Bezug in av-production. Sonnet-Burst war komplett eu-central-1.
Mai-Aktivitaet β harte Zahlen aus CloudWatch
Quelle: AWS/Bedrock Namespace, Modell eu.anthropic.claude-sonnet-4-6 (ohne Version-Suffix!). Datenpunkte CloudWatch-bestaetigt.
Sonnet 4.6 β Tageshistogramm
| Tag | Invocations | InputTokens | Avg In/Call | OutputTokens | Cost |
|---|---|---|---|---|---|
| 12.05. | 52 | 514,872 | 9,902 | 7,568 | $1.82 |
| 13.05. | 32 | 3,383,517 | 105,735 | 15,662 | $11.42 |
| 14.05. | 109 | 4,646,185 | 42,625 | 49,985 | $16.16 |
| 15.05. | 174 | 3,764,805 | 21,637 | 56,971 | $13.36 |
| Ξ£ | 367 | 12,309,379 | 33,541 | 130,186 | $42.77 |
13.05. Stunden-Detail (der Killer-Tag)
| Stunde (UTC+2) | Calls | InputTokens | Avg/Call |
|---|---|---|---|
| 14:00 | 4 | 4,574 | 1,143 |
| 16:00 | 7 | 1,370,077 | 195,725 |
| 17:00 | 15 | 46,641 | 3,109 |
| 21:00 | 2 | 63,456 | 31,728 |
| 14.05. 00:00 (= 13.05. spΓ€t) | 4 | 1,898,769 | 474,692 |
475k Tokens pro Call ist KEIN normaler Chat. Drei Hypothesen:
- 1M-Context-Beta wurde genutzt (Sonnet 4.6 EU unterstuetzt das; doppelter Input-Preis ueber 200k Tokens)
- Full-Document-Indexierung / Eval-Run (Test-Setup mit ganzem Vault als Kontext)
- Agent-Loop ohne History-Truncation (jeder Step schickt komplette Konversation neu)
Phase 2 muss diese 4-6 Calls genau anschauen β sie sind die teuersten Einzelevents.
Haiku 4.5 β Tageshistogramm
| Tag | InputTokens |
|---|---|
| 12.05. | 701,626 |
| 13.05. | 603,972 |
| 14.05. | 15,821 |
| 15.05. | 53,048 |
Auffaellig: Haiku stark genutzt vor dem Sonnet-Burst, danach eingebrochen. Sieht aus wie ein Caller wechselte von Haiku zu Sonnet am 13.05. (parallel zum Beleg-Pipeline-Spike-Ende). Plausibel: Beleg-Klassifikation lief auf Haiku, jemand testete Klassifikations-Qualitaet auf Sonnet.
Cohere Embed Multilingual
CloudWatch hat InputTokenCount-Datapoints β bestaetigt: inference-service-prod (a-icking) ist der Caller, EMBEDDING_PROVIDER=cohere_multilingual_v3 ist in der Task-Def harted-coded.
Top-3-Caller (Phase-1-Schluss)
Anhand Cluster-Inventar + Lambda-Invocations + Burst-Pattern:
| Rang | Caller | Begruendung |
|---|---|---|
| 1 | open-webui-vf (ECS, default-Cluster) | LiteLLM-Sidecar geht direkt auf Bedrock Sonnet 4.6. Burst 14./15.05. matched genau die Pilot-Phase. 196k/475k Avg-Input am 13.05. spaet passt zu Open-WebUI mit langem Chat-Verlauf + grossem RAG-Top-K |
| 2 | inference-service-prod / a-icking-rebuild (ECS, eigener Cluster) | Container live in av-production seit kurzem, Bedrock-Region in Task-Env. Eval-/Test-Runs am 13.05. mit grossen Kontextfenstern passen zur Phase βBedrock-Rebuildβ (Plan vom 14.05.) |
| 3 | agent-beleg-pipeline (Lambda) + receptionist-brain (Lambda) | gemessen mit 130 + 15 Invocations im Zeitfenster. Beide sind Brain-Lambdas, ziehen Bedrock. Anteil am Sonnet-Burst eher niedriger als Open-WebUI, aber sicher mit dabei. |
Nicht-Beitragende (im Burst): av-voice-bot-handler, mcp-vf-hosted (selbst kein Brain), McpCalcomHosted (reiner API-Wrapper), Dashboard/LogRetention-Lambdas.
Identifizierungs-Limitierung
Wir koennen ohne Bedrock Model-Invocation-Logging nicht 100% beweisen welcher Caller welche Invocation gemacht hat β nur ueber Korrelation (Cluster + Container-Logs + Lambda-Timing-Match mit Bedrock-Metrik-Spikes).
Empfehlung Phase 4: Bedrock Model-Invocation-Logging aktivieren (CloudWatch Logs + optional S3-Sink). Dann ist ab dem Tag fuer jeden Call der Caller forensisch nachvollziehbar.
Hebel-Matrix β wer braucht was
max_tokens-Werte sind Erst-Vorschlag, in Phase 3 finalisiert.
| Hebel | open-webui-vf | mcp-whatsapp | mcp-vf-hosted | a-icking-rebuild | daily-briefing | beleg-pipeline | tool-error-digest | receptionist-brain |
|---|---|---|---|---|---|---|---|---|
| 1 AIP+Tags | β | β (kein Brain) | β (kein Brain) | β | β | β | β (kein Bedrock-Call dokumentiert) | β |
| 2 Budget+Action | Account-weit | |||||||
3 max_tokens Caps | β (2000) | β | β | β (1500) | β (500) | β (500) | β | β (300, p95-Lookup vor Deploy) |
| 3b Stop-Sequences | (bei strukturierter Output) | β | β | β | (selten) | β | β | β |
| 4 Tool-Desc-Cutdown | (LiteLLM-Tools, nur falls Caller diese MCPs injiziert) | β | β | (eigene Tools) | β | β | β | β (nur die genutzten MCP-Tools) |
| 5 System-Prompt + RAG | β | β | β | β | β | β | β | β |
| 6 Prompt-Cache 1h | β οΈ (Architektur-Frage, siehe Note unten) | β | β | β οΈ (System-Prompt ~700 Tokens < 4096-Min, nicht implementierbar) | β οΈ (System-Prompt < 4096, nicht implementierbar) | β οΈ (System-Prompt < 4096, nicht implementierbar) | β | β οΈ (System-Prompt ~1200 Tokens < 4096-Min, nicht implementierbar) |
| 7 Embed Titan v2 | β | β | β | β οΈ pruefen (Cohere v3 multi.) | β | β | β | β |
| 8 Modell-Routing | (parallel-Session) | β | β | β¬ | β¬ | β¬ (auf Haiku?) | β | β¬ (auf Haiku?) |
| 9 Batch-Inference | β | β | β | β¬ (Eval-Runs) | β (entweder Cache ODER Batch, nicht beide) | β (entweder Cache ODER Batch, nicht beide) | β | β |
| 10 Service-Quotas | Account-weit |
Note Hebel 6 (Caching) β Bedrock-API-Constraints:
- 4096-Token-Minimum pro Cache-Checkpoint fuer Sonnet 4.5+ und Haiku 4.5+ (Bedrock-Doku
prompt-caching.html). Caller mit System-Prompt < 4096 Tokens werden Cache-Write durchfuehren aber keine Cache-Reads bekommen β effektiv kein Hebel. Bei Open-WebUI haengt es davon ab ob System-Prompt + Modelfile + RAG-Chunks zusammen > 4096 Tokens sind. - Open-WebUI-Architektur-Frage: Caching ist nur effektiv bei wiederholten Calls mit identischem Prefix innerhalb der TTL (5min Default, 1h Beta). VF-Pilot mit niedrigem Call-Volumen pro System-Prompt-Hash bekommt vermutlich auch ohne 4096-Minimum keine Hits. Vor parallel-Session Caching-Debug: Call-Distribution pro Caller anschauen (mit AIP-Daten aus Phase 4).
- Prompt-Caching + Batch-Inference sind gegenseitig exklusiv (Bedrock-Doku: βPrompt caching is only supported for on-demand inference endpoints. It is not supported with the batch inference API.β). Pro Caller entweder ODER, nicht beide.
max_tokens-Werte oben sind Erst-Vorschlag. Vor Deploy: pro Caller CloudWatch OutputTokenCount p95 ueber 7 Tage holen, Cap = max(p95 Γ 1.5, Mindest-Antwort-Laenge). Insbesondere receptionist-brain max_tokens=300 ist ENG fuer Tool-Use-Loops (Tool-JSON + Reasoning + Antwort im selben Budget) β Risiko: abgeschnittene WhatsApp-Antworten ohne Error-Flag.
Baseline-Werte (nach Phase 2 β 2026-05-17)
Quellen: Source-Code in ~/source/, ECS-Task-Definitions, LiteLLM-Config inline im Container-Command, CloudWatch-Bedrock-Metrics.
Token-Schaetzungen via char/3.5 (deutsche Sprache, etwas mehr Tokens als 4); CloudWatch-Werte sind exakt.
| Caller | Bedrock-Modell | System-Prompt (Tokens) | Tool-Desc (Tokens) | Avg In/Call (gemessen) | Avg Out/Call (gemessen) | Mai-Calls 12.-15.05. |
|---|---|---|---|---|---|---|
| open-webui-vf | eu.anthropic.claude-sonnet-4-6 | dynamisch (Modelfile in EFS, nicht ausgelesen) + Chat-History | (Open-WebUI-Tools registriert pro User) | 33,541 | 355 | 367 (100% der Sonnet-Calls) |
a-icking-rebuild (inference-service-prod) | eu.anthropic.claude-haiku-4-5-... | ~700 (Base) + ~500 (Top-K=5 Hits) = ~1,200 | keine Tools | n/a (Haiku-Caller) | n/a | Haiku-Anteil ungeklart |
| receptionist-brain Lambda | eu.anthropic.claude-haiku-4-5-... | ~1,200 (hairdresser.md 4.2k chars) + dynamische Vars | MCP-Tools von mcp-whatsapp + mcp-calcom | n/a (Haiku) | n/a | 15 Invocations 15.05. |
| agent-beleg-pipeline Lambda | eu.anthropic.claude-haiku-4-5-... | unbekannt (Phase-5-Audit) | mcp-vf-hosted Tools | n/a (Haiku) | n/a | 130 Invocations 12.-13.05. |
| agent-daily-briefing Lambda | eu.anthropic.claude-haiku-4-5-... | unbekannt | (vermutlich keine Tools) | n/a (Haiku) | n/a | 6 Invocations 12.-14.05. |
| agent-tool-error-digest Lambda | (kein BEDROCK_MODEL_ID env-var) | (Digest-Format) | (kein Tool-Use) | unklar | unklar | 2 Invocations 15.05. |
| mcp-whatsapp | KEIN Brain β Outbound + Webhook + Inbox only | n/a | n/a | n/a | n/a | 0 Bedrock-Calls |
| mcp-vf-hosted, mcp-calcom | proxy/wrapper, kein Brain | n/a | n/a | n/a | n/a | 0 Bedrock-Calls |
Wesentliche Befunde Phase 2
1. Open-WebUI VF ist der EINZIGE Sonnet-Caller in av-production. Code-Review zeigt: a-icking ruft Haiku (bedrock_claude.py Z.24 hartcodiert), alle Lambdas haben BEDROCK_MODEL_ID=eu.anthropic.claude-haiku-4-5-... env, mcp-whatsapp hat gar kein Brain, mcp-vf-hosted + mcp-calcom sind reine Wrapper. β Alle 367 Sonnet-Calls (12.31M Input-Tokens) kommen aus Open-WebUI.
2. Open-WebUI Konfig hat drei explizite Cost-Treiber:
TASK_MODEL=claude-sonnet-4-6+TASK_MODEL_EXTERNAL=claude-sonnet-4-6β Background-Tasks (Title-Gen, Tag-Gen, Search-Query-Gen, Follow-up-Gen) laufen ALLE auf Sonnet. Schaetzung: 60-70% der Sonnet-Calls sind Background, nicht User-Chat.DEFAULT_MODEL_PARAMS={"max_tokens":8192, "thinking":{"type":"enabled","budget_tokens":4096}}β Extended Thinking AN mit 4k Budget. Erhoeht Output-Tokens und Token-Limit-Verbrauch.ENABLE_SEARCH_QUERY_GENERATION=true+BYPASS_WEB_SEARCH_EMBEDDING_AND_RETRIEVAL=trueβ pro Web-Search ein zusaetzlicher Sonnet-Call zur Query-Generation, und die 3 Web-Results gehen ROH in den Prompt (kein Embedding/Rerank-Filter).
3. LiteLLM hat Prompt-Caching konfiguriert, aber 0 Aktivitaet.
litellm_settings:
cache_control_injection_points:
- location: message
role: systemCloudWatch: CacheReadInputTokenCount = 0, CacheWriteInputTokenCount = 0 fuer Sonnet 4.6 ueber alle 4 Burst-Tage. Hypothesen:
- LiteLLM-
location: messageist evtl. nicht der korrekte Pfad fuer Bedrock-Converse-API (Bedrock erwartetcachePoint-Bloecke insystem[]odermessages[].content[]) - ODER:
cache_controlwird gesetzt aber System-Prompt aendert sich bei jedem Call (z.B. mit Zeitstempel) β Cache invalidiert
β Aufgabe der parallel-Session, hier bestaetigt als Befund.
4. 1M-Context-Beta wurde am 12./13.05. genutzt:
| Tag | Standard-Input-Tokens | 1M-Context-Input-Tokens | Anteil 1M |
|---|---|---|---|
| 12.05. | 514,872 | 314,376 | 61% |
| 13.05. | 3,383,517 | 3,175,742 | 94% |
| 14.05. | 4,646,185 | 0 | 0% |
| 15.05. | 3,764,805 | 0 | 0% |
1M-Context kostet 2x Input ueber 200k Tokens. Am 13.05. lief praktisch alles ueber die Beta. Das verdoppelt effektiv die Tag-Kosten. β Phase-5-Audit muss verstehen welcher Open-WebUI-Trigger 1M-Context anfordert (vermutlich ein User hat eine sehr lange Chat-Session gestartet, oder ein RAG-Heavy-Modus). Anti-Pattern: 1M-Context standardmaessig aktiv lassen.
5. Marvin hat Haiku am 14.05. bewusst aus LiteLLM rausgenommen (βverwirren mehr als sie helfenβ). Aber TASK_MODEL ist nicht migriert β Background-Tasks rufen jetzt Sonnet statt das billigere Haiku. Quick-Win: Haiku wieder in LiteLLM-model_list aufnehmen (als claude-haiku-4-5, NICHT in DEFAULT_MODELS bzw. nicht in der User-Sicht), dann TASK_MODEL=claude-haiku-4-5.
6. Source-Sichtbarkeit:
- a-icking-Bedrock-Code: bedrock_claude.py β sehr sauber,
max_tokens=1024Default, ConverseStream-API - a-icking-System-Prompt: system_prompt.py β 2.4k chars, ~700 Tokens. Sehr kompakt.
- receptionist hairdresser-Prompt: hairdresser.md β 4.2k chars, ~1.2k Tokens. Ok.
- Open-WebUI-Modelfile (System-Prompt) liegt in EFS (
fs-0d5cbc5aa10b080e5, Access-Pointfsap-047c3ba77cb08d6f6) β nicht direkt via API ausgelesen. Fuer Phase 5: ECS-Exec in Container oder EFS-Mount auf eine andere Compute.
Bedrock-Modelle in av-production (CloudWatch list-metrics, Mai 2026)
Welche Modelle werden ueberhaupt benutzt β vor Optimierung wissen wir was raus kann.
| Modell | Status |
|---|---|
eu.anthropic.claude-sonnet-4-6 | aktiv (Hauptkosten) |
eu.anthropic.claude-sonnet-4-5-20250929-v1:0 | aktiv-niedrig ($0.03 in Mai) |
eu.anthropic.claude-haiku-4-5-20251001-v1:0 | aktiv (Burst vor 14.05.) |
eu.meta.llama3-2-1b-instruct-v1:0 | aktiv niedrig (Test?) |
cohere.embed-multilingual-v3 | aktiv (icking-rebuild bestaetigt) |
eu.cohere.embed-v4:0 | aktiv |
cohere.embed-v4:0 (ohne EU-Prefix) | aktiv (Doppel-Eintrag, koennte konsolidiert werden) |
amazon.titan-embed-text-v2:0 | aktiv niedrig ($0.20) |
arn:...foundation-model/cohere.rerank-v3-5:0 | aktiv (Rerank) |
arn:...foundation-model/amazon.rerank-v1:0 | aktiv (Rerank) |
Sonnet 4.5 koennte raus wenn niemand es mehr ruft. Llama 3.2 1B raus wenn nur Test. Cohere-Embed-v4 mit/ohne EU-Prefix: konsolidieren auf EU.
Bemerkenswerte CloudWatch-Dimensionen
Dimensions: [{Name: ContextWindow, Value: "1M"}, {Name: ModelId, Value: "eu.anthropic.claude-sonnet-4-6"}]existiert in der Metric-Liste β 1M-Context-Beta wurde benutzt. Bestaetigt Hypothese 1 fuer den 475k-Avg-Call. Phase 2 muss genau pruefen welcher Caller die 1M-Variante anstoesst.CacheReadInputTokenCountundCacheWriteInputTokenCountDimensions existieren in der Metric-Liste, aber dieDatapointswaren in den ersten Phase-1-Lookups leer fuer Sonnet 4.6 β heisst: aktuell 0 Cache-Hits. Bestaetigt: Prompt-Caching ist nicht aktiv. (Parallel-Session arbeitet daran.)