Kostenkontrolle und Cost‑Instrumentierung

1. Warum „funktioniert“ ≠ „rechnet sich“

LLM‑Anwendungen haben eine wichtige Besonderheit: Neben fixen Hosting‑Kosten entstehen oft variable Kosten für die Ausführung bestimmter Anfragen, die mit Modellaufrufen zusammenhängen.

Wichtig ist, zwei Welten zu unterscheiden:

• wenn das Modell auf der ChatGPT‑Seite läuft (der Nutzer interagiert mit eurer App in ChatGPT und diese ruft mcp-tools auf) – die Token zahlt der Nutzer über sein ChatGPT‑Abo;
• wenn euer Backend/MCP‑Server selbst das OpenAI‑API oder andere LLM‑Services aufruft – dann zahlt ihr die Token.

Genau im zweiten Fall entstehen klassische variable LLM‑Kosten, die von Anzahl und „Schwere“ (tokens_in/tokens_out) der Anfragen abhängen.

Klassisches Szenario:

1. Ihr rollt GiftGenius gut gelaunt in Produktion aus, alles fliegt, die Nutzer sind glücklich.
2. Nach einem Monat kommt die Rechnung für OpenAI + Cloud + Stripe‑Gebühren, und plötzlich stellt sich heraus, dass „erfolgreiches Wachstum“ in Wahrheit bedeutet: „Wir zahlen pro Geschenk mehr, als wir beim Verkauf verdienen“.

Der FinOps‑Ansatz (FinOps) sagt: Kosten sind eine Metrik wie Latenz oder Fehlerrate. Man muss sie protokollieren, aggregieren und auf ihrer Basis entscheiden – nicht „in Excel raten“.

Ziel dieser Vorlesung ist, euch in die Lage zu versetzen, Fragen wie diese zu beantworten:

• „Wie viel hat genau diese Geschenkempfehlung für den Nutzer user42 gekostet?“
• „Wie viel Geld hat in dieser Woche das Tool suggest_gifts verbrannt und wie viele Bestellungen hat es dabei eingebracht?“

Und zwar nicht aus der Luft gegriffen, sondern aus Logs und Metriken.

2. Kostenstruktur der ChatGPT‑App

Beginnen wir mit der Kostenlandkarte. Ohne sie ist alles andere nur ein chaotisches Sammeln von Zahlen.

LLM‑Kosten (variabel)

Das ist alles, was mit Aufrufen von Modellen aus eurem Backend zusammenhängt:

• Aufrufe von OpenAI‑Modellen aus dem MCP‑Server oder von Agenten: GPT-5.1 / GPT-5-mini / Embeddings / Rerank / Vision / TTS/STT usw.
• Zusätzliche Modelle: Reranking für Suche, Embeddings für Empfehlungen, Bildgenerierung.

Wichtig ist ein feiner Punkt: Baut ihr das Interface über das Apps SDK und nutzt nur das eingebaute ChatGPT‑Modell, zahlt ihr keine Token – der Nutzer zahlt (über sein ChatGPT‑Abo). Sobald euer MCP‑Server jedoch selbst das OpenAI‑API aufruft (Agents, Responses API, Embeddings usw.), laufen die Token auf eure Rechnung.

Grundidee: Die Kosten solcher Aufrufe sind proportional zu tokens_in und tokens_out, multipliziert mit dem Preis pro Token.

Ein MCP‑Tool‑Call ist an sich für den Entwickler tokenseitig kostenlos; Kosten entstehen erst dort, wo ihr im Handler beschließt, das OpenAI‑API oder ein anderes LLM aufzurufen.

Infrastruktur

Das ist die gesamte Hardware und die umliegenden Services:

• MCP‑Server: Vercel / AWS / GCP / Bare Metal.
• Agenten (falls sie als eigene Services laufen).
• Datenbanken: Postgres/MySQL, Vektor‑DBs, S3/Objektspeicher.
• Caches: Redis/KeyDB.
• Queues und Worker: z. B. für Hintergrundgenerierung, Recomputing von Feeds usw.

Diese Kosten sind häufiger pro Monat fix (oder stufenweise fix), daher berechnet man sie meist auf Basis aggregierter Ausgaben für Cloud‑Services und nicht pro Anfrage.

Zahlungs- und externe Services

GiftGenius nutzt ACP/Stripe, damit entstehen:

• Gebühren pro erfolgreicher Zahlung (bei Stripe einige Prozent + Fixanteil).
• Verluste durch Fraud und Chargebacks.
• Kosten externer APIs: E‑Mail / SMS / Push‑Benachrichtigungen, zusätzliche Analytics usw.

Am Anfang sind das Peanuts, aber mit dem Scale werden sie spürbar. Daher ist es hilfreich, sie zumindest auf Log‑/Report‑Ebene zu trennen.

Kleine Merktabelle

tokens_in/out × price_per_token

Unser Ziel: diese Kategorien an konkrete Ereignisse im System anzubinden (Tool‑Calls, Workflows, Checkout), statt nur die finalen Monatssummen zu betrachten.

3. Wo Usage‑Daten erfassen: drei Ebenen

Damit Kosten nicht „einmal im Monat“, sondern in Echtzeit berechnet werden, muss man Instrumentierung in den Code einbauen. Es gibt genau drei Stellen.

MCP‑Server: jeder Tool‑Aufruf

Der MCP‑Server ist der natürliche Punkt, über den ChatGPT eure Tools aufruft. Hier können wir:

• Start/Ende des Aufrufs erfassen.
• duration_ms (oder latency_ms) messen.
• Token aus der OpenAI‑Antwort sammeln (wenn unser Modell über den MCP aufgerufen wird) oder sie zumindest schätzen.
• user_id, tenant_id, request_id/trace_id setzen, um Logs zu verknüpfen.

Schematisch sieht ein Log‑Event tool_invocation für GiftGenius so aus:

{
  "timestamp": "2025-11-20T12:34:56Z",
  "level": "info",
  "event": "tool_invocation",
  "request_id": "abc123",
  "user_id": "user42",
  "service": "mcp-giftgenius",
  "tool_name": "suggest_gifts",
  "tokens_in": 120,
  "tokens_out": 350,
  "cost_estimate_usd": 0.045,
  "latency_ms": 320
}

Dasselbe als TypeScript‑Typ und ein Stück Code.

// types/telemetry.ts
export interface ToolInvocationLog {
  event: 'tool_invocation';
  requestId: string;
  userId?: string;
  toolName: string;
  tokensIn?: number;
  tokensOut?: number;
  costEstimateUsd?: number;
  latencyMs: number;
}

// mcp/logger.ts
export function logToolInvocation(payload: ToolInvocationLog) {
  console.log(JSON.stringify({
    timestamp: new Date().toISOString(),
    level: 'info',
    ...payload,
  }));
}

Und nun ein Wrapper um den Handler des MCP‑Tools (angenommen suggest_gifts).

// mcp/tools/suggestGifts.ts
export async function handleSuggestGifts(ctx: Context, input: Input) {
  const started = Date.now();

  const llmResult = await callGiftModel(input); // hier rufen wir OpenAI auf

  const duration = Date.now() - started;
  const { prompt_tokens, completion_tokens } = llmResult.usage ?? {};
  const costEstimate = estimateCost(prompt_tokens, completion_tokens);

  logToolInvocation({
    event: 'tool_invocation',
    requestId: ctx.requestId,
    userId: ctx.userId,
    toolName: 'suggest_gifts',
    tokensIn: prompt_tokens,
    tokensOut: completion_tokens,
    costEstimateUsd: costEstimate,
    latencyMs: duration,
  });

  return llmResult.output;
}

Selbst wenn ihr Token „über den Daumen“ anhand der Textlänge schätzt, ist das schon besser als nichts.

Agent‑Ebene (Agents SDK): Workflow‑Schritte

Wenn ihr das Agents SDK nutzt, kann der Agent selbst mehrere Tools nacheinander aufrufen. Hier ist es wichtig, den Kontext des Schritts zu loggen: welche Aufgabe der Agent zu lösen versucht.

Zum Beispiel kann man bei jedem Tool‑Aufruf des Agent‑Runners Felder workflow_name und step_name hinzufügen: „Ideensuche“, „Filter nach Budget“, „Checkout vorbereiten“.

So könnt ihr später nicht nur nach Tools, sondern auch nach Schritten im Szenario auswerten: vielleicht gehen 80 % der Kosten auf einen nutzlosen „zusätzlichen Verfeinerungsschritt“.

Beispiel eines kleinen „Hook“ rund um den Agenten:

// agents/logStep.ts
export function logAgentStep(data: {
  requestId: string;
  workflow: string;
  step: string;
  toolName: string;
}) {
  console.log(JSON.stringify({
    timestamp: new Date().toISOString(),
    level: 'info',
    event: 'agent_step',
    ...data,
  }));
}

Und im Runner verwenden:

// agents/giftAgent.ts
logAgentStep({
  requestId: run.requestId,
  workflow: 'gift_selection',
  step: 'rank_candidates',
  toolName: 'rerank_gifts',
});

Commerce: Checkout und Geld

In der Commerce‑Schicht interessieren uns Events:

• checkout_started – Kauf gestartet.
• checkout_success – Zahlung erfolgreich.
• checkout_failed – Fehler mit Code/Typ.

Und dazu sollten wir anheften:

• amount, currency.
• request_id derselben Session wie beim tool_invocation.

Dann können wir beantworten: „Dieser Kauf kostete uns N Cent LLM‑Kosten und brachte M US‑Dollar Umsatz.“

Beispiel eines einfachen Checkout‑Event‑Handlers:

// api/commerce/logCheckout.ts
export function logCheckoutEvent(e: {
  type: 'checkout_started' | 'checkout_success' | 'checkout_failed';
  requestId: string;
  userId?: string;
  amountCents?: number;
  currency?: string;
  errorCode?: string;
}) {
  console.log(JSON.stringify({
    timestamp: new Date().toISOString(),
    level: 'info',
    service: 'commerce',
    ...e,
  }));
}

4. Strukturierte Logs für Kosten (Bezug zu M17)

Der entscheidende Punkt: keine „freien“ Textlogs à la console.log("Tool suggest_gifts used 123 tokens"). Alles als JSON.

Im Modul 17 haben wir uns bereits darauf geeinigt, Anfragen als JSON mit Basisfeldern wie request_id, user_id, tool_name usw. zu loggen. Darauf setzen wir nun Kosten‑Felder.

Felder, die in kostenrelevanten Logs unbedingt enthalten sein müssen:

• timestamp, level.
• event (tool_invocation, agent_step, checkout_success usw.).
• request_id, trace_id – um die Ereigniskette eines Workflows zu verknüpfen.
• user_id, tenant_id – um später nach Nutzern/Unternehmen zu aggregieren.
• tool_name / service.
• tokens_in, tokens_out, cost_estimate_usd.
• latency_ms, success/error_code.

In den Beispielen nennen wir das Kostenfeld cost_estimate_usd (Kosten in US‑Dollar) und halten diesen Namen im Code und in den Dashboards durchgängig ein.

Genau diese Struktur erlaubt es:

• Aggregate zu bauen: durchschnittlicher cost_estimate_usd je tool_name, je user_id, je workflow.
• „Teure“ Anfragen mit erhöhter Latenz oder Fehlern zu korrelieren und zu entscheiden, was zuerst optimiert wird.

Wenn ihr in M17 bereits ein grundlegendes logger.info({...}) gebaut habt, ist das Hinzufügen der Kosten‑Felder kein neues Framework, sondern ein paar zusätzliche Properties im Objekt.

5. Wie man LLM‑Kosten im Code grob berechnet

Die Formeln sind hier wirklich nicht schlimm. Uns reicht die Größenordnung, nicht die letzte zentgenaue Übereinstimmung mit dem Billing.

Usage aus der OpenAI‑Antwort nutzen

Wenn euer MCP‑Server das OpenAI Responses API aufruft, erhält er in der Regel ein Objekt usage:

{
  "usage": {
    "prompt_tokens": 120,
    "completion_tokens": 350,
    "total_tokens": 470
  }
}

Daran lässt sich die Kostenrechnung gut aufhängen. Verschiedene Modelle haben unterschiedliche Preise pro 1 M Eingabe‑/Ausgabe‑Token.

Einfachste Schätzfunktion in TypeScript:

// mcp/cost.ts
type Usage = { prompt_tokens?: number; completion_tokens?: number };

const PRICING = {
  inputPerMillion: 2.5,   // Dollar pro 1M Eingabe-Token, Beispiel
  outputPerMillion: 10.0, // und für Output
};

export function estimateCost(
  promptTokens?: number,
  completionTokens?: number,
): number {
  const inTokens = promptTokens ?? 0;
  const outTokens = completionTokens ?? 0;

  const inputCost = (inTokens / 1_000_000) * PRICING.inputPerMillion;
  const outputCost = (outTokens / 1_000_000) * PRICING.outputPerMillion;
  return Number((inputCost + outputCost).toFixed(6)); // leicht runden
}

Die Preise hier sind Beispiele; die echten nehmt ihr aus dem aktuellen OpenAI‑Pricing und legt sie in die Konfiguration. Wichtig ist, dass diese Funktion bei jedem Tool‑Call aufgerufen wird und das Ergebnis in das Feld cost_estimate_usd im Log wandert.

Wenn Usage nicht verfügbar ist

Manchmal verwendet ihr ein Fremd‑LLM ohne Usage‑Werte oder ihr braucht eine Vorab‑Kontrolle vor dem realen Call. Dann könnt ihr:

• Token über eine Bibliothek wie tiktoken oder ein Modell‑Äquivalent schätzen.
• Durchschnittswerte aus historischen Logs nehmen (median_tokens_in/median_tokens_out je Tool) und mit dem Preis multiplizieren.

Code‑Stub zur Längenschätzung:

// mcp/costEstimateFallback.ts
export function roughTokenEstimate(text: string): number {
  // Grobe Schätzung: 1 Token ≈ 4 lateinische Zeichen
  return Math.ceil(text.length / 4);
}

Das ist keine Rocket Science, ermöglicht aber z. B., einen Prompt mit 200000 Token nicht in einen günstigen Tarif zu lassen.

6. Schlüsselmetriken für Kosten

Gesammelte Logs sind Rohmaterial. Schauen wir uns an, welche Aggregate daraus lebenswichtig sind.

cost_per_tool_call

Was es ist: durchschnittliche Kosten eines Aufrufs eines bestimmten Tools.

Wozu:

• Zeigt, welche Tools besonders teuer sind.
• Erlaubt, „teuer und nutzlos“ zu finden: hoher avg_cost_per_call und niedrige Conversion in einen erfolgreichen Ablauf.

Wie man es aus Logs berechnet:

• Logs mit event = "tool_invocation" für den Zeitraum nehmen.
• Nach tool_name gruppieren.
• Für jedes Tool avg(cost_estimate_usd) und z. B. p95 (95. Perzentil der Kosten) berechnen.

cost_per_successful_task (oder cost_per_workflow)

Task/Workflow – das ist ein abgeschlossener Ablauf auf Nutzerebene:

• Bei GiftGenius kann das „Geschenkefindung + Karten anzeigen + Nutzer speichert N Ideen“ sein oder „Findung → Checkout → erfolgreicher Kauf“.

Was zu tun ist:

• Beim Abschluss des Workflows ein Event workflow_completed mit request_id, workflow_name und Erfolgsflag schreiben.
• Über die request_id alle tool_invocation dieses Workflows „heranziehen“ und deren cost_estimate_usd aufsummieren.

So erhalten wir „wie viel ein erfolgreicher Task gekostet hat“ – der Schlüssel zum Verständnis der Stückkosten des Szenarios.

cost_per_user / cost_per_tenant

Für B2B‑Szenarien ist oft wichtig: „Wie viel kostet uns ein Nutzer/ein Team pro Monat?“

Berechnung:

• tool_invocation und andere Kosten‑Events nach user_id oder tenant_id gruppieren.
• cost_estimate_usd über den Zeitraum (Tag, Monat) aufsummieren.

Dann mit dem Preis des Abos vergleichen. Wenn sich cost_per_user stark dem Tarifpreis annähert, ist es Zeit, entweder den Preis zu erhöhen oder den Usage zu optimieren (dazu mehr in der nächsten Vorlesung über Pricing und Experimente „Kosten ↔ Qualität“).

7. Beispiel: Format tool_invocation und Dashboard für GiftGenius

Jetzt machen wir, was im Plan‑Übungsaufgabe stand: Wir entwerfen das Log‑Event und ein Minimal‑Dashboard für Tools.

Ereignisformat tool_invocation für GiftGenius

Zuvor haben wir uns das minimale Log für ein MCP‑Tool angesehen. Jetzt entwerfen wir ein ausführlicheres tool_invocation, das man in Produktion und in Dashboards verwenden kann: gleiche Idee, nur ergänzt um Felder für Services, Fehler und die Verknüpfung mit Modellen.

Zuerst der Typ in TypeScript:

// telemetry/events.ts
export interface ToolInvocationEvent {
  timestamp: string;
  level: 'info' | 'error';
  event: 'tool_invocation';
  service: 'mcp-giftgenius';
  requestId: string;
  traceId?: string;
  userId?: string;
  tenantId?: string;
  toolName: string;
  modelId?: string;
  tokensIn?: number;
  tokensOut?: number;
  costEstimateUsd?: number;
  latencyMs: number;
  success: boolean;
  errorCode?: string;
}

Und ein bequemer Helper:

// telemetry/emitToolInvocation.ts
export function emitToolInvocation(e: ToolInvocationEvent) {
  console.log(JSON.stringify(e));
  // In der Praxis: an Logtail/Datadog/ELK usw. senden
}

Jedem Tool (z. B. suggest_gifts, rerank_gifts, fetch_catalog) fügen wir am Ende des Handlers einen Aufruf von emitToolInvocation hinzu (oder in den finally-Block, damit das Log auch bei Fehlern geschrieben wird).

Einfachstes Dashboard über Tools

Eine Minimaltabelle für ein Dashboard (z. B. in Metabase / Grafana / jedem BI):

tool_name

% des Traffics

avg_cost_per_call

error_rate

avg_latency_ms

avg_revenue_per_call

Visuell sieht das meist so aus: oben eine Tabelle, unten ein paar Diagramme:

• Balkendiagramm: tool_name auf der X‑Achse, avg_cost_per_call auf der Y‑Achse.
• Streudiagramm: X = avg_cost_per_call, Y = error_rate oder conversion_to_checkout.

Solche Grafiken helfen, Kandidaten für Optimierung schnell zu finden: teuer, langsam und ohne Conversion – zuerst dorthin.

Die Verknüpfung von Kosten und Umsatz gelingt, weil wir checkout_* zusammen mit request_id loggen. Dann können wir avg_revenue_per_call als Summe des Umsatzes geteilt durch die Anzahl der Tool‑Aufrufe in den Szenarien berechnen, in denen ein checkout_success stattfand.

8. Erfassung der Infrastrukturkosten (ohne Fanatismus)

Bei LLM‑Kosten ist es elegant: Jeder Aufruf hat Token, man kann die Kosten direkt im Log berechnen. Infrastruktur lässt sich nicht so einfach greifen: Ihr habt die Monatsrechnung für Vercel, Datenbanken, Redis usw.

Zum Start kann man es einfach halten:

1. Nehmt die Gesamtmonatsrechnung für die Infrastruktur (angenommen, 200 $).
2. Teilt sie durch die Anzahl der Workflows im Monat (workflow_completed) – ergibt näherungsweise infra_cost_per_task.
3. Oder teilt durch die Anzahl aktiver Nutzer – infra_cost_per_user.

Diese Zahlen werden dann mit den LLM‑Kosten (die wir detailliert aus den Logs berechnet haben) addiert – so erhalten wir die ungefähren Vollkosten eines Szenarios oder Nutzers.

Wenn die Anwendung wächst, kann man feiner verteilen (Kosten nach Services und Tools aufschlüsseln), aber für die ersten Versionen reicht das völlig, um nicht blind zu steuern.

9. Kleines End‑to‑End‑Beispiel für GiftGenius

Wir setzen alles zu einer Mini‑Story zusammen.

Der Nutzer beschreibt die zu beschenkende Person, ChatGPT schlägt vor, GiftGenius zu aktivieren. Weiter geht’s:

1. Das Widget startet den Workflow "gift_selection".
2. Euer Backend entscheidet sich, einen LLM‑Agenten zu verwenden, um Geschenke intelligenter zu finden.
3. Der Agent macht 3 Schritte:

• analyze_recipient (Analyse der Beschreibung mithilfe eines LLM).
• suggest_gifts (unser MCP‑Tool).
• rerank_gifts (zusätzliches Modell zur Verbesserung der Liste).

4. Der Nutzer sieht Geschenk‑Karten und speichert mehrere Ideen.
5. Er klickt auf „Kaufen“, ACP startet und checkout_create_session läuft.
6. Erfolgreicher checkout_success mit Betrag 79.00 USD.

Was in den Logs bleibt:

• Drei tool_invocation (jeweils mit eigenen tokens_in/tokens_out, cost_estimate_usd, latencyMs).
• Mehrere agent_step mit workflow = "gift_selection", step_name.
• checkout_started und checkout_success mit amount=7900, currency="USD".

Über die request_id verknüpfen wir alles und können sagen:

• LLM‑Kosten des Szenarios: Summe der cost_estimate_usd der drei Tools, z. B. 0.19 $.
• Infrastrukturanteil (aus Aggregaten) ca. 0.03 $ pro Workflow.
• Macht zusammen 0.22 $ Vollkosten.
• Umsatz pro Transaktion – 79 $ minus Stripe‑Gebühr und weiteres.

Das ist bereits konkrete Unit‑Economics und nicht „gefühlt ist GPT‑4 teuer“.

10. Typische Fehler bei der Cost‑Instrumentierung

Fehler Nr. 1: nur die Monatsrechnung betrachten und keine Granularität haben.
Es ist verlockend, nur auf die Gesamtrechnung von OpenAI/Cloud zu schauen. Aber ohne Bezug zu tool_name, user_id, workflow wisst ihr nicht, wo genau Geld ausgegeben wird. Am Ende wird die Optimierung zu einem „blinden Herabstufen des Modells“ statt zu einer gezielten Verbesserung teurer Szenarien.

Fehler Nr. 2: Kosten‑Daten in unstrukturierten Textlogs schreiben.
Zeilen wie "Tool suggest_gifts used 123 tokens" lassen sich nicht sauber aggregieren und filtern. Irgendwann merkt ihr, dass ihr auf JSON migrieren müsst – und dieser Umzug wird schmerzhaft. Baut direkt strukturierte Logs mit Feldern wie request_id, tool_name, tokens_in/tokens_out, cost_estimate_usd.

Fehler Nr. 3: die Verbindung Kosten ↔ Commerce‑Events ignorieren.
checkout_success ohne request_id und ohne Verknüpfung zu Tool‑Calls zu loggen heißt freiwillig darauf zu verzichten zu verstehen, welche Szenarien Gewinn bringen und welche nur Token verbrennen. Nehmt euch die Zeit, die request_id durch den gesamten Pfad vom Widget bis zum ACP durchzureichen.

Fehler Nr. 4: „perfektes“ Billing bauen wollen statt einer pragmatischen Schätzung.
Manche Teams vergraben sich beim Versuch, das OpenAI‑Billing bis auf den letzten Token perfekt nachzubilden. In der Praxis reicht die Größenordnung: Ob ein Szenario 0.02 $ oder 0.021 $ kostet, ist nicht entscheidend. Wichtig ist, dass es nicht 2 $ sind. Scheut euch nicht, ungefähre Schätzungen über usage oder sogar grobe Heuristiken zu verwenden.

Fehler Nr. 5: nur auf Kosten schauen und die Qualität vergessen.
Manchmal verleiten schöne Einsparungszahlen dazu, überall auf das billigste Modell umzuschalten. So kann man eine Anwendung „optimieren“, bis sie niemand mehr nutzen will. Kosten müssen zusammen mit Antwortqualität und Conversion betrachtet werden – diese Kopplung ist Thema der nächsten Vorlesung dieses Moduls: Pricing und Experimente „Kosten ↔ Qualität“.