
Ein LLM-Kosten-Dashboard mit BigQuery bauen
Ein konkreter Bauplan, um OpenAI-, Anthropic- und Gemini-Nutzung in BigQuery zu loggen und ein Kosten-Dashboard zu bauen, das dein Finance-Team wirklich liest.
Logge jeden LLM-Call in eine breite Event-Tabelle in BigQuery, materialisiere einen Tages-View und exponiere drei Dashboards: Kosten pro Feature, Kosten pro Tenant, Kosten pro erfolgreichem Outcome. Alles andere ist Deko.
- Eine Event-Tabelle, ein materialisierter Tages-View, drei Dashboards.
- Kosten zur Schreibzeit auf Feature und Tenant zurechnen, nicht via Joins später.
- Kosten pro erfolgreichem Outcome tracken, nicht nur pro Call.
- Alert auf 7-Tage-Wachstum pro Feature, nicht auf absoluten Spend.
Das Event-Schema
Jeder LLM-Call — von jedem Provider — schreibt eine Zeile in llm_events. Provider ändern sich; das Schema nicht.
CREATE TABLE analytics.llm_events (
event_id STRING,
ts TIMESTAMP,
provider STRING,
model STRING,
feature STRING,
tenant_id STRING,
request_id STRING,
prompt_tokens INT64,
completion_tokens INT64,
cached_tokens INT64,
latency_ms INT64,
status STRING,
cost_usd NUMERIC,
metadata JSON
) PARTITION BY DATE(ts)
CLUSTER BY feature, tenant_id;Der Tages-View
Ein einziger materialisierter View treibt jede Grafik:
CREATE MATERIALIZED VIEW analytics.llm_daily AS
SELECT
DATE(ts) AS day,
provider, model, feature, tenant_id,
COUNT(*) AS calls,
SUM(prompt_tokens) AS prompt_tokens,
SUM(completion_tokens) AS completion_tokens,
SUM(cost_usd) AS cost_usd,
APPROX_QUANTILES(latency_ms, 100)[OFFSET(95)] AS latency_p95,
COUNTIF(status = 'ok') / COUNT(*) AS success_rate
FROM analytics.llm_events
GROUP BY day, provider, model, feature, tenant_id;Die drei Dashboards
- Kosten pro Feature — täglicher Stacked-Area nach
feature. Der Chart, den Produktmanager anstarren. - Kosten pro Tenant — Top-20-Tenants nach 7-Tage-Kosten, mit Woche-über-Woche-Wachstum. Der Chart für Account Manager.
- Kosten pro erfolgreichem Outcome —
SUM(cost_usd) / COUNTIF(status = 'ok'). Fängt Modelle, die in teure Retries abrutschen.
Alerts, die nicht Wolf schreien
Absolute Kosten-Alerts feuern bei jedem Launch. Besser: alerten, wenn Kosten pro Feature um mehr als 40% Woche-über-Woche wachsen — an Tagen mit >100 Calls. Fast immer eine echte Regression: Modelltausch, längerer Prompt, kaputter Cache.
Zweiter nützlicher Alert: Kosten pro erfolgreichem Outcome verdoppeln sich für ein Feature. Fängt stille Qualitätsregressionen, wo Retries die Fehlerrate maskieren.
Der Write-Path
Zwei Muster funktionieren gut:
- Direct insert aus deiner App via BigQuery Streaming Inserts — am günstigsten und einfachsten bei kleinen Volumina.
- Gepuffert via Pub/Sub → Dataflow oder ein geplanter Load-Job — günstiger und resilienter über ~1 Mio. Calls/Tag.
So oder so: Schema stabil halten, Preistabelle in Version Control. Das Dashboard ist nur so nützlich wie die Disziplin dahinter.
Frequently asked
Warum BigQuery statt Postgres?
Für viele Teams reicht Postgres bis ein paar Millionen Events. BigQuery gewinnt, sobald du drüber liegst oder günstige Ad-hoc-Analytics ohne Vacuum willst.
Wie ordne ich Kosten zu, wenn ein Feature zwei Modelle aufruft?
Beide Events mit demselben Feature taggen. Der Per-Outcome-View spiegelt dann die wahren Kosten des sichtbaren Features unabhängig vom internen Routing.
Funktioniert das für Embeddings und Vector-DB-Calls?
Ja — füge eine Spalte `operation` ('generation' | 'embedding' | 'rerank') hinzu und behalte das Schema. Eine Tabelle schlägt drei, wenn du nach Tenant slicest.
Building something similar?
I help teams ship production-grade AI agents, n8n workflows, and data platforms. Let's talk about what you're building.
Work with me
Islam Gamal
AI, Data & Automation Engineer. I design and ship production AI agents, n8n workflows, and cloud data platforms — with a focus on reliability, cost, and measurable business impact. Founder of Tashghil and Tek bil Arabi.
More from Islam Gamal
BigQuery Cost Control That Scales: 12 Patterns from Real Warehouses
Twelve battle-tested patterns to cut BigQuery spend 30–70% without touching data quality — partitioning, clustering, materialized views, reservations, and the FinOps loop that keeps savings from decaying.
The Modern Data Stack in 2026: What Actually Matters (and What to Skip)
A no-hype 30-minute tour of the 2026 data stack: ingestion, warehouse, transformation, orchestration, semantic layer, reverse ETL, observability, and the AI layer on top — with concrete tool picks, cost anchors, and the anti-patterns that quietly eat budgets.
Observability for AI Systems: Traces, Prompts, Tokens, and the SLOs That Actually Matter
A 30-minute production guide to instrumenting LLM applications — what to log (and what never to), how to trace agent calls end-to-end, the four golden signals for AI, drift detection on outputs, and the dashboards you actually check at 2 a.m.
Browse every article by Islam Gamal on the author page.