LLMs so heiß, dass sie Ihnen ein Loch ins Budget brennen
Erinnern Sie sich noch an die Anfänge der Cloud? Unser größtes FinOps-Kopfzerbrechen war die ungetaggte VM. Ein Entwickler fuhr einen riesigen Server hoch, vergaß das Label – und zack! Am Monatsende stand da ein ärgerlich rätselhafter, nicht zugeordneter Kostenposten. Schmerzhaft, klar – aber meist baute sich das Ganze über Wochen auf.
Jetzt heißt es: anschnallen. FinOps für KI ist da, und es wird Ihnen ein Schleudertrauma verpassen. Das neue Kosten-Schwarzloch ist kein heimlich laufender Server mehr, sondern Tokens, die völlig aus dem Ruder laufen.
Wenn ein nicht optimierter Prompt 100-mal pro Sekunde auf ein teures LLM trifft, leckt Ihr Budget nicht einfach … es explodiert. Wir sprechen von budgetsprengenden Kostenspitzen, die in Stunden entstehen – nicht in Monaten.
Die Lösung? Wir müssen den Fokus vom Infrastruktur-Tagging hin zur Telemetrie auf Anwendungsebene verlagern. Wir müssen die Kosten jedes einzelnen Tokens in Echtzeit nachvollziehen.
Besonders wichtig wird das bei KI-Agenten – nicht bei Chatbots, wo sich jede Session leicht einem konkreten Nutzer zuordnen lässt, sondern bei autonomen Agenten, die unter Umständen für ein ganzes Team arbeiten.
FinOps für KI: Cloud-Telemetrie allein reicht nicht
Die klassische Kostenverfolgung über Cloud-Provider-Rechnungen (Cost Explorer, Cost Management etc.) ist für die Nutzung von KI-APIs schlicht zu langsam und zu grobgranular.
Die folgende Tabelle stellt FinOps 1.0 dem aufkommenden FinOps für KI gegenüber:
| Merkmal | Frühes Cloud-FinOps | Aktuelles KI-FinOps (API)
|----------------------|--------------------------------|----------------------------------------
| Kosteneinheit | VM-Stunde, GB Storage | Input-Token, Output-Token
-----------------------|--------------------------------|-----------------------------------------
| Kostentreiber | Idle Resources, | Prompt-Effizienz,
| | Network Egress | Modellauswahl
-----------------------|--------------------------------|-----------------------------------------
| Kostentransparenz | Tägliche/Stündliche Billing- | Echtzeit-Telemetrie pro Transaktion
| | Logs |
-----------------------|--------------------------------|-----------------------------------------
| Optimierungswerkzeug | Server abschalten | - Prompt/Code umschreiben
| | | - Echtzeit-Modellauswahl
-----------------------|--------------------------------|-----------------------------------------
Wer Kosten für KI-Anwendungen wirklich im Griff haben will, kann nicht auf die Rechnung warten. Wir brauchen FinOps-Intelligenz direkt in der Anwendungsschicht – mit einer Auswertung jedes einzelnen gesendeten oder empfangenen Tokens. Genau hier kommt OpenTelemetry (OTel) ins Spiel.
Tutorial: KI-Agenten mit OpenTelemetry instrumentieren
OpenTelemetry ist ein Open-Source-Framework und liefert einen einheitlichen Standard für das Sammeln von Observability-Daten (Traces, Metriken und Logs). Über die Tracing-Funktionen können wir unsere LLM-Aufrufe umschließen und genau den FinOps-Kontext einschleusen, den wir brauchen.
Das folgende Beispiel zeigt, wie sich die FinOps-Kostenzuordnung für KI-Agenten mit OpenTelemetry und Googles Agent Development Kit (ADK) umsetzen lässt.
Dieser Code ist Ihr Schlüssel zur FinOps-Freiheit. Er sorgt dafür, dass jedes von Ihrem KI-Agenten verbrauchte Token sofort dem richtigen Budgetverantwortlichen zugeordnet wird. Schluss mit dem Ratespiel!
Den vollständig lauffähigen Code finden Sie hier: https://github.com/antweiss/finops-ai-otel.
WICHTIGER HINWEIS: Nicht produktionstauglich!
Für dieses Tutorial nutzen wir den ConsoleSpanExporter, um rohe Trace-Daten direkt im Terminal auszugeben. In einer Produktionsumgebung würden Sie das NIEMALS so machen!
Stattdessen würden Sie den Console-Exporter durch einen dedizierten OTLP-Exporter ersetzen, der die Daten an einen robusten Backend-Service schickt, etwa:
- Google Cloud Trace: Die native Option für Google-Cloud-Nutzer.
- Ein Managed Observability Backend: Etwa Jaeger, Datadog oder New Relic.
- Eine dedizierte FinOps-Management-Plattform wie DoiT Cloud Intelligence
In solchen Backends können Sie die Daten abfragen und aggregieren und FinOps-Reports fahren wie: "Zeig mir die Gesamtzahl der verbrauchten Tokens, bei denen finops.project_code = 'BLOG-FINOPS-001' ist, in den letzten 30 Tagen." So wird aus einem Trace ein echter Kostenreport!
Schritt 1 & 2: Startklar machen
Sie kennen das Spiel! Repo klonen, Abhängigkeiten installieren, API-Key setzen.
git clone https://github.com/antweiss/finops-ai-otel.git
cd finops-ai-otel
pip install -r requirements.txt
export GEMINI_API_KEY="YOUR_API_KEY_HERE"
Schritt 3: Code ausführen und die Tokens sprudeln sehen!
Wenn Sie die Datei agent.py ausführen, wird die FinOps-Superkraft innerhalb der Funktion run_finops_session aktiviert.
python agent.py
So gelangen die FinOps-Tags hinein (der Code im Detail)
Das Ziel: Die gesamte Aktivität des Agenten in einen eigenen OpenTelemetry-Span einpacken, der unsere Budget-Details mitführt.
Den FinOps-Span starten:
with tracer.start_as_current_span("adk-agent-session") as span:
Diese eine Zeile ist der ganze Trick! Wir starten einen Span und erklären ihn zum aktuell aktiven Span. Jeder nachfolgende Code, der ebenfalls mit OTel instrumentiert ist (etwa die internen LLM-Aufrufe des Google ADK), erzeugt automatisch eigene Spans als Kinder dieses aktiven Parent-Spans.
FinOps-Metadaten (Tags) ergänzen:
span.set_attribute("finops.team_id", team_id)
span.set_attribute("finops.project_code", project_code)
Hier schleusen wir die Cost-Center-Details ein! Da die internen Spans des ADK (in denen die Token-Counts stecken) Kinder dieses Spans sind, sieht Ihr Trace-Backend den gesamten Token-Verbrauch direkt unter dem finops.project_code. Zuordnung erledigt!
Die entscheidenden FinOps-Metriken
def setup_opentelemetry_tracer():
"""Configures the Tracer to output to the console for a runnable demo."""
# 1. Create a TracerProvider
provider = TracerProvider()
# 2. Add a simple processor that exports traces to the console
# This shows the raw trace data and attributes!
provider.add_span_processor(SimpleSpanProcessor(ConsoleSpanExporter()))
# 3. Set it as the global provider
trace.set_tracer_provider(provider)
return trace.get_tracer("finops.adk.agent")
Die Ausgabe des ConsoleSpanExporter ist Ihr unmittelbarer Kostenreport. Achten Sie auf den verschachtelten LLM-Call-Span – dort sehen Sie das vollständige, abrechnungsrelevante Bild (die finops.*-Attribute setzt der Beispielcode, die llm.*-Attribute und -Metriken stammen vom LLMAgent des ADK):
FinOps für Fortgeschrittene: Spans in Multi-Agent-Flows weiterreichen
Und was ist mit komplexen Workflows, in denen ein Agent Arbeit an einen anderen delegiert? Genau hier spielt OpenTelemetry seine Stärken aus.
- Im OTel-Modell wird der Trace-Kontext des Parent-Spans automatisch entlang der Aufrufkette weitergegeben, sobald ein Agent (der Parent) einen anderen Agenten oder ein Tool (das Child) aufruft.
- Die gesamte Abfolge von Agenten und Tools läuft innerhalb des ursprünglichen FinOps-Span-Kontexts ab.
- Das heißt: Ihr einzelnes Top-Level-FinOps-Tag deckt die komplette, mehrstufige Agenten-Choreografie ab – Sie erhalten einen einheitlichen, prüfbaren Kostenreport für den gesamten Workflow! Diese Eigenschaft erbt das ADK direkt aus der OTel-Standardinstrumentierung.
Links
Zur Vertiefung der Grundlagen, auf denen diese FinOps-Lösung aufbaut:
Bestätigt die native, eingebaute Unterstützung des ADK für OpenTelemetry-Instrumentierung.
Getting Started with OpenTelemetry
Erläutert die zugrunde liegenden Prinzipien von Spans, Kontext und Context Propagation.
Beschreibt die Agent-Typen (LlmAgent, SequentialAgent), die von diesem Tracing profitieren.
Im nächsten Beitrag zeigen wir, wie Sie wirksame Cost Guardrails für Ihre KI-Anwendungen einziehen.