Rollout-Map

Generisch — fuer beliebige zukuenftige Caller. Konkrete Anwendung auf av-production-Caller siehe caller-inventar.

Hebel	ECS+LiteLLM (Open-WebUI-style)	Lambda+boto3 (receptionist-style)	FastAPI/ECS-eigener Client (a-icking-style)	MCP-Server (kein Brain)
1 AIP+Tags	✓ in model_list[].litellm_params.model	✓ als modelId im converse()	✓ als model_id Konstante	➖ (kein Bedrock-Call)
2 Budget+Alarm	(Account-weit)	(Account-weit)	(Account-weit)	(Account-weit)
3 max_tokens-Cap	✓ via DEFAULT_MODEL_PARAMS env	✓ via inferenceConfig.maxTokens	✓ Konstruktor-Parameter	➖
3b Stop-Sequences	bedingt (wenn JSON-Output)	✓ bei Tool-Use	✓ bei strukturiertem Output	➖
4 Tool-Desc-Cutdown	indirekt (LiteLLM-Tools wenn aktiv)	✓ pro MCP-Tool das benutzt wird	➖ (kein Tool-Use)	✓ Hauptangriff hier
5 System-Prompt + RAG	✓ Modelfile + RAG-Settings	✓ Code-Review System-Prompt	✓ System-Prompt-Builder + RAG-Top-K	➖
6 Prompt-Caching 1h	✓ LiteLLM-Config + Verifizierung	✓ cachePoint-Block in system[]	✓ analog	➖
7 Embeddings-Modell	➖ (Open-WebUI nutzt eigenes Embedding)	➖ (selten)	✓ Provider-Wahl in Factory	➖
8 Modell-Routing	✓ TASK_MODEL + DEFAULT_MODELS	✓ env-var BEDROCK_MODEL_ID	✓ Konstante im Code	➖
9 Batch-Inference	➖ (Realtime-Chat)	✓ wenn nicht zeitkritisch	✓ fuer Eval/Bulk-Lauefe	➖
10 Service-Quotas	(Account-weit)	(Account-weit)	(Account-weit)	(Account-weit)

Reihenfolge pro Caller-Typ

ECS+LiteLLM

1. Modell-Routing (Hebel 8) — sofortiger Quick-Win bei TASK_MODEL=Sonnet
2. max_tokens-Cap (Hebel 3)
3. AIP (Hebel 1) → 3 Tage messen
4. System-Prompt + RAG (Hebel 5)
5. Prompt-Caching (Hebel 6) — komplex bei LiteLLM, parallel-Session

Lambda+boto3

1. AIP (Hebel 1) — sofort messbar wenn neue Lambda
2. max_tokens-Cap + Stop-Sequences (Hebel 3)
3. System-Prompt-Audit (Hebel 5)
4. Bei Tool-Use: Tool-Desc-Cutdown der genutzten MCPs (Hebel 4)
5. Wenn Cron-getriggert + nicht zeitkritisch: Batch-Inference (Hebel 9)

FastAPI/ECS-eigener Client

1. AIP (Hebel 1)
2. max_tokens + System-Prompt schon im Code-Review beim ersten Deploy
3. Embeddings-Provider-Wahl (Hebel 7) bei RAG-Use-Cases
4. Batch fuer Eval/Bulk-Lauefe (Hebel 9)

MCP-Server (Tool-Definitionen)

1. Tool-Description-Audit (Hebel 4) — der einzige relevante Hebel hier
2. In mcps/_index.md Token-Cost-Tier dokumentieren

Wann KEINE der Hebel reichen — Architektur-Frage

Wenn alle Hebel angewandt sind und Cost trotzdem zu hoch: Caller-Architektur infrage stellen.

• Brauchen wir wirklich einen LLM-Call hier, oder reicht ein Regex/Decision-Table?
• Koennen wir die User-Anfrage zwischenspeichern (Cache vor LLM)?
• Ist der Use-Case ueberhaupt geeignet fuer ein Frontier-Model, oder reicht ein selbst-gehostetes kleines Modell (Llama 3.2 1B z.B.)?

Diese Fragen gehoeren ins ce:brainstorm-Territory, nicht in dieses Playbook.