Bir AI API Faturalandırma Defteri Oluşturun: Her Model Çağrısında Teklif Alın, Rezervasyon Yapın, Yerleştirin ve Mutabakat Yapın

Müşteriye yönelik AI API faturalandırma, ham sağlayıcı kullanımının aylık dışa aktarımı olamaz. Bir ağ geçidi birden fazla modeli kiracılara, ekiplere veya iş ortaklarına sunuyorsa faturalandırmanın, fatura mevcut olmadan önce daha zor bir soruyu yanıtlaması gerekir: bu isteğe şu anda izin verilmeli mi ve bunun maliyeti daha sonra nasıl açıklanacak?

Pratik model, dört aşamalı bir fatura defteridir: teklif verme, ayırma, kapatma ve mutabakat sağlama. Talepten önce olası maliyeti belirtin. İzin verilen en kötü durumu karşılamaya yetecek kadar kiracı bütçesi ayırın. Gerçek maliyeti kullanım öğrenildikten sonra ödeyin. Faturaların savunulabilir kalmasını sağlamak için ağ geçidi defterini sağlayıcı tarafındaki kayıtlarla mutabakat sağlayın.

Bu makalede, çok modelli bir API ağ geçidine yönelik kontrol döngüsü açıklanmaktadır. Ağ geçidinin dahili ekipleri mi, ön ödemeli müşterileri mi, ajans müşterilerini mi yoksa alt ortakları mı faturalandırdığını belirlemek faydalıdır.

Faturalandırma sorunu: sağlayıcı kullanımı müşteri faturası değil

Gerçek: Büyük AI sağlayıcıları tek bir evrensel jeton sayacını veya tek bir evrensel fiyatı açıklamaz. OpenAI ayrı giriş, önbelleğe alınmış giriş ve çıkış belirteci oranlarıyla model başına fiyatları yayınlar. OpenAI istemi önbelleğe alma, API yanıt kullanım alanında belirteç kullanımını önbelleğe alır. Anthropic normal giriş belirteçleri, önbellek oluşturma giriş belirteçleri, önbellek okuma giriş belirteçleri ve çıkış belirteçleri için ayrı sayaçları belgeler. Gemini fiyatlandırma, ses jetonları gibi modaliteye özgü kullanım dahil olmak üzere giriş, çıkış ve diğer jeton kategorilerini birbirinden ayırır.

Bu, bir ağ geçidinin total_tokens sayısını bir fiyatla çarparak güvenli bir şekilde faturalandıramayacağı anlamına gelir. Sağlayıcıdan bağımsız bir faturalandırma şemasının arkasında sağlayıcıya özel bağdaştırıcılara ihtiyaç duyar.

Sorun şu durumlarda daha görünür hale gelir:

• Ön ödemeli krediler: kiracı sıfırın altında harcama yapmadan önce ağ geçidinin istekleri reddetmesi gerekir.
• İş ortağı işaretlemeleri: iş ortağının, sağlayıcı faturasının bir kopyasına değil, müşteriye yönelik kendi faturasına ihtiyacı vardır.
• Akış: Yanıt, son jeton kullanımı bilinmeden önce başlar.
• İstemi önbelleğe alma: Önbelleğe alınmış giriş, önbelleğe alınmamış girişten daha ucuz olabilir, ancak bu yalnızca ayrı olarak ölçülürse.
• Akıl yürütme ve araç kullanımı: bazı modeller ek kullanım boyutlarını, gizli çıktı sınıflarını veya medya birimlerini açığa çıkarır.
• Sağlayıcı fiyat değişiklikleri: Geçen aya ait bir fatura, ücret listesi değişikliklerinden sonra da yinelenebilir olmalıdır.

Öneri: Faturalandırmayı, istek günlükleri üzerindeki kontrol paneli sorgusu olarak değil, yalnızca eklenen bir mali defter olarak ele alın.

Temel mimari

Güvenilir bir faturalandırma mimarisinin altı bileşeni vardır:

1. Kiracı hesabı: müşteri, çalışma alanı, bayi istemcisi veya dahili maliyet merkezi.
2. Ücret listesi hizmeti: sağlayıcı, model, faturalandırma sınıfı, para birimi ve biçimlendirme kuralı için sürümlendirilmiş fiyatlar.
3. Tahmin edici:, istek parametrelerinden ve model politikasından bir ön kontrol teklifi hesaplar.
4. Rezervasyon defteri:, sağlayıcı çağrısı başlamadan önce bütçeyi tutar.
5. Kullanım normalleştiricisi: sağlayıcıya özel kullanım alanlarını dahili faturalandırma birimlerine dönüştürür.
6. Yerleştirme ve mutabakat işleri: masrafları kesinleştirin ve bunları sağlayıcı tarafı kayıtlarıyla karşılaştırın.

Kontrol akışı şuna benzer:

client request
  -> authenticate tenant and key
  -> select model and rate-card version
  -> estimate input and max output cost
  -> reserve tenant balance
  -> call provider
  -> normalize returned usage
  -> settle actual cost
  -> release unused reservation
  -> emit invoice-ready ledger event

Önemli tasarım seçeneği, isteğin yalnızca gözlemlenmemesidir. Yürütmeden önce ve sonra mali olarak kontrol edilir.

1. Adım: sağlayıcı aramadan önce teklif verin

Ön kontrol teklifi, bütçeleri zorunlu kılacak kadar karamsar olmalı, ancak müşterilere veya iş ortaklarına gösterilecek kadar da açıklanabilir olmalıdır.

Girdiler genellikle şunları içerir:

• kiracı kimliği ve faturalandırma planı;
• API anahtar kimliği veya proje kimliği;
• yönlendirme kuralları uygulandıktan sonra sağlayıcı ve model kimliği;
• tahmini önbelleğe alınmamış giriş jetonları;
• varsa, bilinen önbelleğe alınmış giriş uygunluğu;
• max_tokens, max_output_tokens veya eşdeğer çıktı sınırı;
• araç, resim, ses veya diğer modalite parametreleri;
• iş ortağı fiyat artışı, indirim veya bayi fiyatlandırma kuralı;
• para birimi ve yuvarlama politikası.

Metin oluşturmaya yönelik basit bir alıntı formülü şöyle olabilir:

estimated_cost =
  estimated_uncached_input_tokens * input_rate
+ estimated_cached_input_tokens   * cached_input_rate
+ max_output_tokens               * output_rate
+ request_fee
+ partner_markup

Öneri: Nihai çıkış uzunluğu bilinmediğinde, yapılandırılan maksimum çıkışa göre rezervasyon yapın. Uygulama çıkış sınırını sınırsız bırakırsa ağ geçidinin bir kiracı veya model varsayılanı uygulaması gerekir. Azami yükümlülük yoksa bütçenin uygulanması belirleyici olamaz.

Bu, pratikte ucuz olabilecek bazı isteklerin reddedilmesine neden olabilir. Takas budur. Ön ödemeli sistemler için, daha güvenli temerrüt, ödeme sonrasında kullanılmayan fonların serbest bırakılmasıyla kötümser rezervasyondur. Faturalı kurumsal müşteriler için ekipler, geçici aşımlara izin verebilir ve teklifi esas olarak uyarılar için kullanabilir.

2. Adım: kiracı bütçesini ayırın

Rezervasyon, kiracı hesabını izin verilen bakiyenin üzerinde harcama yapmaktan korur. Atomik olmalıdır: Ya rezervasyon başarılı olur ve sağlayıcı çağrısı başlayabilir ya da herhangi bir sağlayıcı maliyeti oluşmadan istek reddedilir.

Rezervasyon kaydı şunları içerebilir:

{
  "reservation_id": "res_01J...",
  "tenant_id": "tenant_123",
  "api_key_id": "key_456",
  "request_id": "req_789",
  "provider": "example_provider",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "quoted_amount": "0.032100",
  "currency": "USD",
  "status": "reserved",
  "expires_at": "2026-08-11T12:05:00Z"
}

Ağ arızaları ve istemci bağlantısı kesintileri için kısa rezervasyon süre sonlarını kullanın. Bir temizleme işi, hiçbir zaman çözüme ulaşmamış, süresi dolmuş rezervasyonları serbest bırakmalıdır. Ancak, istemcinin bağlantısı kesildiği için rezervasyonu iptal etmeyin; sağlayıcı araması yine de tamamlanabilir ve ücrete tabi olabilir. Sağlayıcı istek durumunu ayrı olarak izleyin.

Öneri: Rezervasyonu istek kimliği veya önemsizlik anahtarıyla bağımsız hale getirin. İstemcilerden, ağ geçitlerinden veya çalışanlardan yapılan yeniden denemeler, aynı mantıksal istek için birden fazla bütçe bekletme işlemi oluşturmamalıdır.

3. Adım: sağlayıcı kullanımını normalleştirin

Sağlayıcı yanıtları küçük bir dahili şemaya dönüştürülmelidir. Sağlayıcılar yeni kullanım alanları eklerken bile istikrarlı kalmasını sağlayın.

Pratik, normalleştirilmiş bir kullanım şeması:

{
  "input_uncached_tokens": 1200,
  "input_cached_tokens": 800,
  "cache_write_tokens": 0,
  "output_tokens": 650,
  "reasoning_or_hidden_output_tokens": 0,
  "tool_or_media_units": [],
  "request_fee_units": 1,
  "provider_request_id": "prov_abc",
  "usage_source": "provider_response",
  "is_estimated": false
}

Bu şema kasıtlı olarak herhangi bir sağlayıcının yanıtıyla aynı değildir. Sağlayıcıya özel birimler için kaçış kapaklarını korurken faturaların ihtiyaç duyduğu faturalandırma boyutlarını yakalar.

Önbelleğe alınan jetonların kendi satırları olması gerekir

Gerçek: İstemi önbelleğe alma, önbelleğe alınmamış girişten farklı şekilde fiyatlandırılabilir. Önbelleğe alınan jetonlar toplam giriş jetonlarıyla birleştirilirse müşteriden fazla ücret alınabilir veya ağ geçidi, sağlayıcı maliyetini olduğundan düşük gösterebilir. Önbelleğe alınmış giriş, hem genel muhasebede hem de faturada kendi faturalandırma sınıfı olarak görünmelidir.

Önbellek yazma ve önbellek okuma işlemleri her zaman aynı değildir

Bazı sağlayıcılar, önbellek girişleri oluşturma ile önbellekten okuma arasında ayrım yapar. Normalleştirici, önbelleğe alınmış girişin her zaman bir faturalandırma ücreti anlamına geldiğini varsaymamalıdır. Bir sağlayıcının önbellek yazma jetonları ve önbellek okuma jetonları varsa bunları ayrı olarak eşleyin veya sağlayıcıya özel alt birimler olarak koruyun.

Akıl yürütme ve gizli çıktının bir politikaya ihtiyacı vardır

Bazı modeller, akıl yürütmeyle ilgili kullanımı veya gizli çıktı sayaçlarını açığa çıkarır. Sağlayıcı bu birimleri faturalandırıyorsa, ağ geçidinin bunları doğrudan mı göstereceğine, bunları bir çıktı kategorisine mi aktaracağına veya ayrı bir fatura satırı olarak mı listeleyeceğine karar vermesi gerekir.

Öneri: Müşteriye yönelik faturalarda sade bir dil kullanılmalıdır. Örneğin: "çıktı belirteçlerini akıl yürütme", ham sağlayıcı alan adından daha açıktır. Ham alanları denetim için kullanılabilir tutun ancak her müşteriyi sağlayıcının dahili bilgilerini anlamaya zorlamayın.

4. Adım: Gerçek maliyeti belirleyin

Ödeme, normalleştirilmiş kullanımı nihai defter girişlerine dönüştürür. Yalnızca eklemeli olmalı ve istek için kullanılan ücret listesi sürümüne referans vermelidir.

Sonlandırılmış bir etkinlik şöyle görünebilir:

{
  "ledger_event_id": "led_01J...",
  "event_type": "settlement",
  "tenant_id": "tenant_123",
  "request_id": "req_789",
  "reservation_id": "res_01J...",
  "provider": "example_provider",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "lines": [
    {
      "billing_class": "input_uncached_tokens",
      "quantity": 1200,
      "unit": "token",
      "unit_price": "0.00000250",
      "amount": "0.003000"
    },
    {
      "billing_class": "input_cached_tokens",
      "quantity": 800,
      "unit": "token",
      "unit_price": "0.00000125",
      "amount": "0.001000"
    },
    {
      "billing_class": "output_tokens",
      "quantity": 650,
      "unit": "token",
      "unit_price": "0.00001000",
      "amount": "0.006500"
    }
  ],
  "total_amount": "0.010500",
  "currency": "USD",
  "status": "settled"
}

İstek 0.032100 için ayrılmışsa ve 0.010500'da sonuçlandırılmışsa, defter 0.021600'u kullanılabilir bakiyeye geri gönderir.

Öneri: Eski fatura satırlarını hiçbir zaman mevcut fiyatlandırma tablosundan yeniden hesaplamayın. Değiştirilemez ücret listesi sürümlerini saklayın ve sürüm kimliğini her fiyat teklifi, rezervasyon ve ödeme etkinliğine ekleyin. Aksi takdirde, sağlayıcı model fiyatlarını güncelledikten sonra faturanın yeniden üretilmesi imkansız hale gelebilir.

Yayın istekleri: önce ayırtın, sonra halledin

Akış, faturalandırmayı karmaşık hale getirir çünkü kullanıcı, ağ geçidi son kullanımı bilmeden çıktı almaya başlar. Cevap, ön kontrol kontrollerini atlamamaktır. Ağ geçidi, akışı açmadan önce rezervasyon yapmalıdır.

Bu iş akışını kullanın:

1. Giriş jetonlarını ve maksimum çıktı maliyetini tahmin edin.
2. Kiracı bütçesini ayırın.
3. Sağlayıcı akışını açın.
4. Parçaları istemciye iletin.
5. Sağlayıcı gönderdiğinde veya takip kullanım kaydı mevcut olduğunda son kullanımı yakalayın.
6. Gerçek maliyeti belirleyin ve kullanılmayan rezervasyonu iptal edin.

Nihai kullanım mevcut değilse, ödemeyi kesinmiş gibi davranmak yerine tahmini olarak işaretleyin:

"usage_source": "gateway_estimate",
"is_estimated": true,
"reconciliation_status": "pending"

Öneri: günlük mutabakat, tahmini akış etkinliklerine, başarısız isteklere, zaman aşımlarına ve yeniden denemelere öncelik vermelidir. Bunlar, ağ geçidi kayıtları ile sağlayıcı faturaları arasında farklılık yaratma olasılığı en yüksek olan alanlardır.

Ücret listesi sürüm oluşturma ve biçimlendirme kuralları

Ücret listesi, değiştirilebilir bir e-tablo değil, sürümlendirilmiş bir nesne olmalıdır.

Minimum alanlar:

• sağlayıcı;
• model kimliği;
• faturalandırma sınıfı;
• birim (belirteç, istek, resim, ses saniyesi veya araç birimi gibi);
• birim fiyat;
• para birimi;
• etkili başlangıç ve bitiş zaman damgaları;
• yuvarlama politikası;
• kiracı planı veya iş ortağı işaretleme kuralı;
• kaynak referansı ve onay meta verileri.

İşaretleme kuralları açık olmalıdır. Örneğin:

• Maliyet artı: sağlayıcı maliyeti artı %20.
• Sabit perakende: kiracı, sağlayıcı fiyatından bağımsız olarak sabit bir jeton fiyatı öder.
• Kademeli: ilk 10 milyon jeton tek bir oranda, ardından daha düşük bir oranda.
• Krediler dahil: kullanımı, aşım faturalandırması başlamadan önce aylık bir tahsisatı tüketir.

Ödünleşme: ücret listesi sürümü oluşturma, operasyonel çalışmayı artırır, ancak fatura anlaşmazlıklarının arkeolojik hale gelmesini önler. Bir müşteri destek temsilcisi, 3 Ağustos'taki bir talebin neden bugünün sağlayıcı fiyatını kontrol etmeden belirli bir ücret üzerinden faturalandırıldığını açıklayabilmelidir.

Faturalandırma defterini analizlerden ayırın

Analiz ve faturalandırmanın farklı toleransları vardır. Analitikler toplanabilir, geciktirilebilir, örneklenebilir veya düzeltilebilir. Faturalandırma eksiksiz, bağımsız, denetlenebilir ve açıklanabilir olmalıdır.

Analitiği aşağıdaki gibi sorular için kullanın:

• En çok jetonu hangi takımlar kullanıyor?
• Hangi modeller en hızlı büyüyor?
• İstem önbelleğe alma maliyeti nerede azaltabilir?
• Hangi anahtarlar alışılmadık derecede pahalı isteklere neden oluyor?

Şu tür sorular için fatura defterini kullanın:

• Bu talebe kiracının bakiyesi karşılığında mı yetki verildi?
• Bu ödemeyi hangi ücret listesi sürümü oluşturdu?
• Kullanılmayan rezervasyon serbest bırakıldı mı?
• Müşteri faturası yerleşik kullanımla eşleşiyor mu?
• Ağ geçidi kullanımı sağlayıcı tarafı kullanımıyla eşleşiyor mu?

Gerçek: OpenTelemetry GenAI anlam kuralları, giriş ve çıkış belirteçleri gibi belirteç kullanım özelliklerini içerir. Bu, gözlemlenebilirlik ve izlerin maliyet olaylarıyla birleştirilmesi açısından faydalıdır. Ancak telemetri özellikleri ücret listelerinin, rezervasyonların, kapatmanın, yuvarlamanın ve fatura durumunun yerine geçmez.

Günlük mutabakat iş akışı

Mutabakat, ağ geçidinin mutabakat defterini sağlayıcı tarafı kullanımıyla karşılaştırır. Amaç her ara alanda mükemmel bir anlaşma değildir. Amaç, faturaları, ücret listelerini veya bağdaştırıcıları düzeltmek için önemli farklılıkları yeterince erken tespit etmektir.

Pratik bir günlük iş:

1. Ağ geçidi defter etkinliklerini sağlayıcıya, modele, kiracıya veya API anahtarına, faturalandırma sınıfına ve UTC gününe göre gruplandırın.
2. Sağlayıcı tarafı kullanımını API anahtar kimliği, model ve gün gibi mevcut boyutlara göre gruplandırarak getir.
3. Mümkün olduğu durumlarda, istek yanıtları için kullanılan bağdaştırıcı koduyla sağlayıcının dışa aktarımlarını normalleştirin.
4. Faturalandırma sınıfına göre miktarları ve maliyetleri karşılaştırın.
5. %0,5 miktar farkı veya herhangi bir büyük mutlak maliyet farkı gibi eşiklerin üzerindeki sapmayı işaretleyin.
6. Farklılık nedenlerini sınıflandırın: akış tahminleri, yeniden denemeler, başarısız istekler, önbellek hesaplaması, model takma adı değişiklikleri, gecikmiş sağlayıcı kayıtları veya eksik istek kimlikleri.
7. Eski uzlaşma etkinliklerini düzenlemek yerine düzenleme etkinlikleri oluşturun.

Öneri: Mutabakatı basitleştirdiği için operasyonel olarak mümkün olduğunda kiracı başına sağlayıcı API anahtarlarını kullanın. Bu, çok fazla anahtar yönetimi yükü yaratıyorsa dahili kiracı kimliklerini desteklendiği yerlerde sağlayıcı meta verileriyle eşleştirin ve güvenilir bir istek kimliği köprüsü bulundurun.

Müşterilerin anlayabileceği fatura satırları

Müşteriye yönelik bir fatura JSON numaralı sağlayıcıyı yansıtmamalıdır. Tasarıyı istikrarlı ticari terimlerle açıklamalıdır.

Faydalı fatura sütunları:

• tarih aralığı;
• kiracı, proje veya API anahtar etiketi;
• model veya model profili;
• istek sayısı;
• önbelleğe alınmamış giriş jetonları;
• önbelleğe alınmış giriş jetonları;
• çıkış jetonları;
• varsa medya veya araç birimleri;
• indirimler, krediler veya artışlar;
• toplam tutar ve para birimi.

İş ortakları için hem toptan satış maliyetini hem de perakende ücretini yalnızca iş modeli gerektiriyorsa dahil edin. Birçok bayi faturasında yalnızca perakende kullanımı gösterilirken iş ortağı kontrol panelleri marjı ayrı olarak gösterebilir.

Ödül: Birleştirilmiş bir fatura şeması okunabilirliği artırır, ancak sağlayıcıya özel faturalandırma ayrıntılarının yine de kaçış yollarına ihtiyacı vardır. Fatura satırlarını varsayılan olarak basit tutun ve ayrıntılı denetim alanlarına ihtiyaç duyan ileri düzey müşteriler için dışa aktarma olanağı sağlayın.

Uygulama kontrol listesi

Lansmandan önce

• Desteklenen tüm sağlayıcılar için normalleştirilmiş faturalandırma sınıflarını tanımlayın.
• Geçerlilik tarihlerine sahip, değişmez ücret listesi sürümleri oluşturun.
• Çıkış sınırlarını zorunlu tutun veya ağ geçidi varsayılanlarını uygulayın.
• İdempotency anahtarlarıyla atom rezervasyonlarını uygulayın.
• Her para birimi için yuvarlama kuralları belirleyin.
• Önbelleğe alınan belirteçleri, akıl yürütme belirteçlerini, medya birimlerini ve talep ücretlerini nasıl faturalandıracağınıza karar verin.
• Yeniden denemeleri, zaman aşımlarını, istemci bağlantısının kesilmesini ve sağlayıcı hatalarını test edin.
• Sonlandırılmış etkinlikleri düzenlemek yerine bir düzenleme-olay mekanizması oluşturun.

İstek işleme sırasında

• Kiracının ve anahtarın kimliğini doğrulayın.
• Yönlendirme ve geri dönüş politikasından sonra son modeli çözümleyin.
• Doğru ücret listesi sürümünü seçin.
• En kötü durum maliyetini belirtin.
• Bakiyeyi ayırın veya isteği reddedin.
• Mümkün olduğunda sağlayıcı istek kimliğini kaydedin.
• Yanıtın kullanımını normalleştirin.
• Kullanılmayan rezervasyonu halledin, iptal edin ve faturaya hazır etkinlikleri yayınlayın.

İstek işleme alındıktan sonra

• Günlük mutabakatı sağlayıcıya, anahtara, modele, faturalandırma sınıfına ve güne göre çalıştırın.
• Tahmini akış ödemelerini inceleyin.
• Eksik ücret listesi girişleriyle model kullanımını işaretleyin.
• Önbelleğe alınmış jeton hesaplamasının neden olduğu sapmayı izleyin.
• Son faturalandırmadan önce müşteri faturası önizlemeleri oluşturun.

Planlanacak tahminler

Tahmin: AI API faturalandırma daha az değil, daha çok boyutlu hale gelecek. Belirteç sınıfları, önbellek sınıfları, medya birimleri, araç yürütme ve akıl yürütmeyle ilgili sayaçların, model yetenekleri değiştikçe genişlemeye devam etmesi muhtemeldir.

Tahmin: müşteriler istek, anahtar, proje ve fatura düzeyinde kullanım açıklamaları bekleyecektir. İzlenebilir satır öğeleri olmayan aylık toplam, API erişimini yeniden satan veya ön ödemeli bütçeleri zorunlu kılan ekipler için yeterli olmayacaktır.

Tahmin: Fiyat teklifini, rezervasyonu, ödemeyi ve mutabakatı zaten ayıran ağ geçitleri, tüm fatura sistemini yeniden yazmaya gerek kalmadan faturalandırma sınıfları ekleyebildikleri için yeni fiyatlandırma modellerine daha hızlı uyum sağlayacak.

Harekete geçirilebilir sonuç

Bir ağ geçidi üzerinden birden fazla AI sağlayıcısını açığa çıkarırsanız, faturalandırma anlaşmazlıkları sorunu ortaya çıkarmadan önce fatura defterini oluşturun. Dört garantiyle başlayın:

1. Her faturalandırılabilir istek, bir ön kontrol teklifi alır.
2. Her ön ödemeli veya sınırlı kiracının, sağlayıcı görüşmesi başlamadan önce ayrılmış bütçesi vardır.
3. Sağlayıcıların her yanıtı, istikrarlı faturalandırma sınıflarına göre normalleştirilir.
4. Her faturanın, sağlayıcı tarafındaki kullanıma ve o sırada kullanılan tam ücret listesi sürümüne göre mutabakatı yapılabilir.

Bu kontrol döngüsü, birleşik AI API faturalandırmayı müşteriler için anlaşılır, ön ödemeli krediler için uygulanabilir, iş ortağı işaretlemeleri için esnek ve sağlayıcı fiyatlandırması veya kullanım biçimleri değiştiğinde denetlenebilir hale getirir.

İlgili okumalar

• LLM izlerini kullanım ve maliyetle birleştirme kayıtlar
• kiracı kullanım ölçümüyle bayi portalları oluşturma
• faturalandırmayı anlaşılır tutarken istemi önbelleğe almayı kullanma