بناء لوحة تكاليف نماذج اللغة على BigQuery

كل استدعاء لنموذج لغة — من أي مزوّد — يكتب صفًا واحدًا في llm_events. المزوّدون يتغيرون، والسكيمة لا:

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;

عرض مادّي واحد يقود كل الرسوم:

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;

1. تكلفة كل ميزة — منطقة يومية مكدّسة حسب feature. هذا الرسم الذي يحدق فيه مديرو المنتج.
2. تكلفة كل عميل — أعلى 20 عميلًا بتكلفة الأسبوع، مع نمو أسبوع مقابل أسبوع. هذا الرسم الذي يحدق فيه مديرو الحسابات.
3. تكلفة كل نتيجة ناجحة — SUM(cost_usd) / COUNTIF(status = 'ok'). هذا الرسم يلتقط النماذج التي تنحدر إلى محاولات مكلفة.

تنبيهات التكلفة المطلقة تنطلق كلما أطلقت شيئًا. بدلها، نبّه حين تنمو تكلفة أي ميزة بأكثر من 40% أسبوعًا مقابل أسبوع في أيام تجاوزت 100 استدعاء. هذا انحدار حقيقي غالبًا: تبديل نموذج، تلقين أطول، أو ذاكرة مؤقتة مكسورة.

تنبيه ثانٍ مفيد: مضاعفة التكلفة لكل نتيجة ناجحة لأي ميزة. يلتقط انحدارات الجودة الصامتة حيث تخفي المحاولات معدل الفشل.

نمطان يعملان بامتياز:

• إدراج مباشر من تطبيقك عبر Streaming Inserts — الأرخص والأبسط عند الأحجام الصغيرة.
• مؤقّت عبر Pub/Sub → Dataflow أو مهمة تحميل مجدولة — أرخص وأكثر صمودًا فوق ~مليون استدعاء يوميًا.

في الحالتين، حافظ على استقرار السكيمة وضع جدول الأسعار في نظام إصدار. اللوحة نافعة بقدر انضباط الكتابة وراءها.