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
Çok modelli ağ geçitleri için pratik bir faturalandırma kontrol modeli: bir istekten önce maliyeti tahmin edin, kiracı bütçesini ayırın, sağlayıcı kullanımını normalleştirin, fiili ücretleri kesinleştirin ve yalnızca ham sağlayıcı yanıtlarına dayanmadan faturaları mutabakata varın.
Müşteriye yönelik AI API faturalandırması, ham sağlayıcı kullanımının aylık olarak dışa aktarılması şeklinde 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 durumda kalması 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 iş ortaklarını 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 yapay zeka sağlayıcıları tek bir evrensel jeton sayacını veya tek bir evrensel fiyatı açıklamaz. OpenAI, model başına fiyatları ayrı giriş, önbelleğe alınmış giriş ve çıkış jetonu oranlarıyla yayınlar. OpenAI istemi önbelleğe alma, API yanıtı kullanım alanında önbelleğe alınan belirteç kullanımını raporlar. Antropik belgeler, normal giriş belirteçleri, önbellek oluşturma giriş belirteçleri, önbellek okuma giriş belirteçleri ve çıkış belirteçleri için sayaçları ayırır. Gemini fiyatlandırması, ses belirteçleri gibi modaliteye özgü kullanım da dahil olmak üzere giriş, çıkış ve diğer belirteç kategorilerini birbirinden ayırır.
Bu, bir ağ geçidinin total_tokens değerini tek 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: İş 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, nihai 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 ortaya çıkarır.
- Sağlayıcı fiyat değişiklikleri: Geçen aya ait bir faturanın, ücret listesi değişikliklerinden sonra da yinelenebilir olması gerekir.
Ö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:
- Kiracı hesabı: müşteri, çalışma alanı, bayi müşterisi veya dahili maliyet merkezi.
- Ücret listesi hizmeti: sağlayıcı, model, faturalandırma sınıfı, para birimi ve biçimlendirme kuralı için versiyonlandırılmış fiyatlar.
- Tahmin edici: istek parametrelerinden ve model politikasından bir ön kontrol teklifi hesaplar.
- Rezervasyon defteri: sağlayıcı görüşmesi başlamadan önce bütçeyi tutar.
- Kullanım normalleştiricisi: sağlayıcıya özel kullanım alanlarını dahili faturalandırma birimlerine dönüştürür.
- Yerleştirme ve mutabakat işleri: Ücretleri kesinleştirin ve bunları sağlayıcı tarafındaki kayıtlarla karşılaştırın.
Kontrol akışı şuna benzer:
istemci isteği
-> kiracının ve anahtarın kimliğini doğrulayın
-> modeli ve ücret listesi sürümünü seçin
-> girdi ve maksimum çıktı maliyetini tahmin edin
-> kiracı bakiyesini rezerve etmek
-> sağlayıcıyı arayın
-> geri dönen kullanımı normalleştirin
-> gerçek maliyeti belirle
-> kullanılmayan rezervasyonu serbest bırak
-> faturaya hazır defter olayı yayınlaÖnemli tasarım tercihi, isteğin yalnızca dikkate alınmamasıdır. Yürütmeden önce ve sonra mali olarak kontrol edilir.
1. Adım: sağlayıcı aramadan önce alıntı yapın
Ö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_tokensveya eşdeğer çıkış sınırı;- araç, görüntü, 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:
tahmini_maliyet =
tahmin edilen_uncached_input_tokens * input_rate
+ tahmini_cached_input_tokens * önbelleğe alınmış_giriş_oranı
+ max_output_tokens * çıktı_oranı+ request_fee
+ partner_markupÖneri: Nihai çıkış uzunluğu bilinmiyorsa, yapılandırılmış 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. Faturalandırılmış 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:
<ön>Ağ arızaları ve istemci bağlantılarının kesilmesi 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ının istek durumunu ayrı olarak izleyin.
Öneri: rezervasyonunu istek kimliği veya önemsizlik anahtarıyla bağımsız hale getirin. İstemcilerden, ağ geçitlerinden veya çalışanlardan gelen 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 bir normalleştirilmiş kullanım şeması:
<ön>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ınan 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 gösterip göstermeyeceğine, bunları bir çıktı kategorisine dahil edip etmeyeceğine veya ayrı bir fatura satırı olarak listeleyip listelemeyeceğ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 durumda 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 ek olmalı ve istek için kullanılan ücret listesi sürümüne referans vermelidir.
Sonlandırılmış bir etkinlik şöyle görünebilir:
<ön>İstek 0.032100 için ayrılmışsa ve 0.010500 olarak sonuçlandırıldıysa, defter 0.021600'u tekrar kullanılabilir bakiyeye bırakır.
Ö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 rezervasyon yaptırın, sonra halledin
Akış, ağ geçidi son kullanımı bilmeden önce kullanıcı çıktı almaya başladığından faturalandırmayı karmaşık hale getirir. Cevap, ön kontrol kontrollerini atlamamaktır. Ağ geçidinin akışı açmadan önce rezervasyon yapması gerekir.
Bu iş akışını kullanın:
- Giriş jetonlarını ve maksimum çıktı maliyetini tahmin edin.
- Kiracı bütçesini ayırın.
- Sağlayıcı akışını açın.
- Parçaları istemciye iletin.
- Sağlayıcı gönderdiğinde veya takip kullanım kaydı mevcut olduğunda son kullanımı yakalayın.
- 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:
"kullanım_kaynağı": "ağ geçidi_tahmini",
"tahmini": doğru,
"reconciliation_status": "beklemede"Ö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ı;
- belirteç, istek, resim, ses saniyesi veya araç birimi gibi birim;
- 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 olarak tek bir oranda 10 milyon jeton, 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ül: Ücret listesi versiyonlaması operasyonel çalışmayı artırır, ancak fatura anlaşmazlıklarının arkeolojiye dönüşmesini engeller. 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ırmanın eksiksiz, bağımsız, denetlenebilir ve açıklanabilir olması gerekir.
Aşağıdaki gibi sorular için analitiği kullanın:
- En çok jetonu hangi takımlar kullanıyor?
- Hangi modeller en hızlı büyüyor?
- İstemi önbelleğe alma maliyeti nerede azaltabilir?
- Hangi anahtarlar alışılmadık derecede pahalı isteklere neden oluyor?
Aşağıdaki gibi sorular için fatura defterini kullanın:
- Bu talep kiracının bakiyesine karşılık mı onaylandı?
- 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ş:
- Ağ geçidi defter olaylarını 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.
- Sağlayıcı tarafı kullanımını API anahtar kimliği, model ve gün gibi mevcut boyutlara göre gruplandırarak getirin.
- Mümkün olduğu durumlarda, istek yanıtları için kullanılan aynı bağdaştırıcı kodu aracılığıyla sağlayıcı aktarımlarını normalleştirin.
- Faturalandırma sınıfına göre miktarları ve maliyetleri karşılaştırın.
- %0,5 miktar farkı veya büyük mutlak maliyet farkı gibi eşiklerin üzerindeki sapmaları işaretleyin.
- 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.
- Eski yerleşim etkinliklerini düzenlemek yerine düzenleme etkinlikleri oluşturun.
Öneri: Mutabakatı basitleştirdiği için operasyonel olarak mümkün olduğu durumlarda 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, sağlayıcının JSON'unu 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ı;
- çıktı belirteçleri;
- varsa medya veya araç birimleri;
- indirimler, krediler veya artışlar;
- toplam tutar ve para birimi.
İş ortakları için, yalnızca iş modeli gerektiriyorsa hem toptan satış maliyetini hem de perakende ücretini dahil edin. Çoğu bayi faturasında yalnızca perakende kullanımı gösterilirken iş ortağı kontrol panellerinde marj ayrı olarak gösterilebilir.
Ö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ını ayarlayın.
- Ö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şlendikten 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ırması 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 yapay zeka sağlayıcısını açığa çıkarırsanız, faturalandırma anlaşmazlıkları sorun yaratmadan önce fatura defterini oluşturun. Dört garantiyle başlayın:
- Faturalandırılabilir her istek, bir ön kontrol teklifi alır.
- 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.
- Sağlayıcıların her yanıtı, istikrarlı faturalandırma sınıfları halinde normalleştirilir.
- 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ırmasını 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.