AI API Ağ Geçitleri için Sürümlü Fiyatlandırma Katalogları: Ani Fiyat Tekliflerinden ve Ters İbrazdan Kaynaklanan Fiyat Kaymasını Durdurun
Sağlayıcı fiyat kartları modele, belirteç kategorisine, önbellek davranışına, araç kullanımına, dağıtım türüne, bölgeye ve taahhüt edilen kapasite planına göre değişir. Bir ağ geçidinin sürümlendirilmiş bir fiyatlandırma kataloğuna ihtiyacı vardır, böylece fiyatlar değiştiğinde fiyat teklifleri, rezervasyonlar, defterler, bütçeler ve ters ibrazlar açıklanabilir kalır.
Ağ geçidi, sağlayıcı fiyatlandırmasını statik bir arama tablosu olarak ele aldığında AI API faturalandırması başarısız olur. İşin zor kısmı jetonları bir oranla çarpmak değil. İşin zor kısmı, istek anında hangi fiyatın geçerli olduğunu, hangi SKU'nun gerçek kullanım grubuyla eşleştiğini, fiyatın onaylanıp onaylanmadığını ve müşteri teklifinin sağlayıcı faturasından neden farklı olduğunu bilmektir.
Birden fazla modeli, hesabı, bölgeyi, önbellek modunu, toplu işleri, barındırılan araçları ve temel hazırlığı yapılan dağıtımları destekleyen bir ağ geçidinin bir fiyatlandırma kontrol düzlemine ihtiyacı vardır. Bu kontrol düzlemi, sağlayıcı fiyat kartlarını, onaylanan her ücretin sürümünü almalı, sağlayıcı kullanımını faturalandırılabilir SKU'lara eşlemeli, kullanıma sunmadan önce teklifleri test etmeli ve kapatılmış defter satırlarını faturalarla mutabakata varmalıdır.
Okuyucu Sorunu: Fiyat Kayması, Fiyatlandırma Sayfalarından Daha Fazlasını Kırıyor
Sağlayıcı fiyatlandırması, uygulama ekiplerinin nadiren doğrudan gördüğü boyutlara göre değişiklik gösterebilir: model sürümü, giriş belirteçleri, önbelleğe alınmış giriş belirteçleri, çıktı belirteçleri, akıl yürütme belirteçleri, önbellek yazmaları, barındırılan araçlar, toplu indirimler, dağıtım türü, bölge, para birimi ve taahhüt edilen kapasite planları. Bu boyutlar tek bir "belirteç başına maliyet" alanına sabitlenirse, ağ geçidi sonunda yanlış fiyat teklifi verecek, bütçeleri aşırı ayıracak, kiracılara gereğinden az fatura verecek veya harcamayı yanlış maliyet merkezine tahsis edecektir.
Hata genellikle beş yerden birinde ortaya çıkar:
- Ön kontrol teklifleri: Ağ geçidinin eski veya eksik bir ücrete göre tahmin yapması nedeniyle bir istek kabul edilir.
- Bütçe rezervasyonları: kiracı bakiyesi bir katalog kullanılarak ayrılır, ancak başka bir katalog kullanılarak kapatılır.
- Kullanım defterleri: önbelleğe alınmış belirteçler, akıl yürütme belirteçleri, araç çağrıları veya toplu birimler genel toplamlar olarak depolanır ve doğru şekilde yeniden fiyatlandırılamaz.
- Geri ödeme dışa aktarmaları: finans, farklılığı açıklamak için gereken sağlayıcı fatura boyutları olmadan kiracı toplamlarını alır.
- İş ortağı API'leri: alt ürünler, fiyatların güncel, tahmini, kullanımdan kaldırılmış veya engellenmiş olup olmadığını bilmeden fiyatları ortaya çıkarır.
Fiyatlandırma Tasarımında Korunması Gereken Gerçekler
Gerçek: Kamu sağlayıcı belgeleri genellikle fiyatlandırmayı modele ve jeton kategorisine göre ayırır. Giriş, önbelleğe alınmış giriş ve çıkış jetonlarının oranları farklı olabilir. Bazı kullanım raporları, önbelleğe alınmış giriş veya akıl yürütme belirteci sayımlarını açığa çıkarır; bu, bir ağ geçidinin yalnızca toplam belirteçleri depolamak yerine kullanım alt kategorilerini koruması gerektiği anlamına gelir.
Gerçek: fiyatlandırma her zaman yalnızca kullandıkça öde jetonları değildir. Bazı sağlayıcılar taahhüt edilen kapasiteyi, tedarik edilen verimi veya belirli model kapasitesine bağlı jeton birimlerini satar. Bu modlarda maliyet, basit bir istek başına jeton faturası yerine süreye, kapasite birimlerine veya modele özel girdi/çıktı oranlarına dayalı olabilir.
Gerçek: barındırılan araçlar ve alma özellikleri, normal model çıkarımının dışında ek faturalandırılabilir etkinlikler oluşturabilir. Arama temeli, dosya arama, URL bağlamı, kod yürütme, önbellek yazma ve aracılı ara adımlar ayrı SKU eşlemesi gerektirebilir.
Öneri: bu gerçekleri istisna olarak değil, şema gereksinimleri olarak ele alın. Bir kullanım etkinliği, kataloğun eşleyemediği faturalandırılabilir bir boyut içeriyorsa ağ geçidi, işlemi sessiz bir şekilde sıfır olarak fiyatlandırmak yerine faturalamayı beklemeye almalıdır.
Versiyonlu Fiyatlandırma Kataloğu Oluşturun
Fiyatlandırma kataloğu, sağlayıcı bağdaştırıcılarına yerleştirilmiş sabitler değil, birinci sınıf bir tablo veya hizmet olmalıdır. Katalog bir soruyu yanıtlamak için var: Bu kullanım etkinliği için, şu anda bu kiracı ve sağlayıcı hesabı bağlamında hangi onaylanmış ücret kullanılmalıdır?
Temel Katalog Alanları
Pratik bir katalog satırı en azından şu alanları içermelidir:
catalog_version_id: fiyat teklifi vermek, ayırmak, kapatmak ve mutabakat sağlamak için kullanılan değişmez sürüm.sağlayıcı: yukarı akış sağlayıcısı veya dahili sağlayıcı bağdaştırıcısı.provider_account_scope: küresel, kuruluş, proje, çalışma alanı, BYOK kiracısı, bayi hesabı veya kurumsal sözleşme.model_id_or_alias: sağlayıcı tarafından görülebilen model kimliği veya fiyatlandırılan dahili model takma adı.pricing_sku: Ağ geçidinin ödeme için kullandığı standart SKU.provider_meter_id: mevcut olduğunda isteğe bağlı yukarı akış fatura ölçer.fatura_birimi: giriş jetonu, önbelleğe alınmış giriş jetonu, çıkış jetonu, akıl yürütme jetonu, önbellek yazma, arama sorgusu, resim jetonu, ses saniyesi, toplu birim, PTU saati veya başka bir açık birim.region_scope: küresel, bölge, ikamet bölgesi, pazar yeri veya veri ikamet sınıfı.deployment_type: sunucusuz, toplu, temel hazırlığı yapılmış, ayrılmış, ince ayarlı veya dahili korumalı alan.hizmet_katmanı: standart, öncelikli, toplu, hızlı, temel hazırlığı yapılmış veya diğer ağ geçidi katmanı.para birimi: fiyat artışı, vergi, kredi veya dönüşümden önceki kurun para birimi.oran: tam ondalık oran, asla ikili kayan nokta değil.minimum_unit: faturalandırılabilir en küçük birim.rounding_rule: istek başına, fatura satırı başına, kiracı dönemi başına veya sağlayıcı tanımlı.kaynak_url: dokümantasyon, fiyat kartı, sözleşme referansı veya dahili onay bileti.observed_at: fiyatın tespit edildiği veya içe aktarıldığı zaman.etkili_başlangıçveetkili_to: geçerlilik penceresi.onay_durumu: taslak, incelendi, onaylandı, kullanımdan kaldırıldı, engellendi veya değiştirildi.
Uygulamanın önemli ayrıntısı, katalog sürümünün trafik tarafından kullanıldığında değişmez olmasıdır. Düzeltmeler, mevcut genel muhasebe satırlarının referans aldığı geçmiş sürümü değiştirmemeli, yeni bir sürüm veya düzenleme girişi oluşturmalıdır.
Model Takma Adlarını Fiyatlandırma SKU'larından Ayırın
chat-default, support-fast veya reasoning-premium gibi dahili takma adlar operasyonel kolaylıklardır. Bunlar, sağlayıcının görebildiği model kimliğini veya genel muhasebedeki fiyatlandırma SKU'sunu değiştirmemelidir.
Bir kullanım etkinliği üç kimliğin tümünü saklamalıdır:
requested_model_alias: uygulamanın istediği şey.upstream_model_id: ağ geçidinin gerçekte adlandırdığı şey.pricing_sku: faturalandırma motorunun ödeme için kullandığı şey.
Bu, takma ad tanıtımlarının geçmişi yeniden yazmasını engeller. chat-default, Ağustos'taki bir modeli ve Eylül'deki daha yeni bir modeli işaret ediyorsa, Ağustos kullanımı, Ağustos yukarı akış modeline ve Ağustos katalog sürümüne bağlı kalmalıdır.
Değişmez Katalog Versiyonuna Karşı Alıntı
Alıntılar yalnızca daha sonra açıklanabildiklerinde faydalıdır. Ağ geçidi, gönderimden önce bir katalog sürümü seçmeli, bunu ön kontrol teklifi için kullanmalı, bütçe rezervasyonunda sürdürmeli ve nihai uzlaşmaya kadar taşımalıdır.
Minimum istek yaşam döngüsü şuna benzer:
- İsteği beklenen faturalandırılabilir boyutlara göre normalleştirin: model, hizmet katmanı, bölge, jeton tahmini, önbellek uygunluğu, araçlar, toplu mod ve dağıtım türü.
- Kiracı ve sağlayıcı hesap kapsamı için etkin onaylı katalog sürümünü seçin.
- Olası her faturalandırılabilir boyut için beklenen SKU'ları çözümleyin.
- Bir ön kontrol tahmini hesaplayın ve kiracı bütçesini ayırın.
- Yalnızca gerekli tüm SKU eşlemelerinin mevcut olması durumunda yukarı akış isteğini gönderin.
- Alt kategoriler de dahil olmak üzere sağlayıcı yanıtından son kullanım meta verilerini yakalayın.
- Açık bir düzeltme iş akışı gerekmediği sürece gerçek kullanımı aynı katalog sürümünü kullanarak belirleyin.
- Ayrılan ve ödenen tutarlar arasındaki farkları kaydedin.
Öneri: ihtiyatlı varsayımlarla fiyat teklifi verin ve rezervasyon yapın, ardından yanıt sonrası kullanımdan vazgeçin. Kesin dağıtım öncesi fiyatlandırma, akış, yeniden denemeler, barındırılan araçlar, uzun süre çalışan aracılar ve önbellek isabet davranışı için zordur. Amaç mükemmel bir tahmin değil. Amaç, kontrollü teşhir ve açıklanabilir ödemedir.
Bilinmeyen Faturalandırılabilir Boyutlar Nedeniyle Kapatıldı
En tehlikeli fiyatlandırma hatası, ücretsiz kullanım haline gelen eksik bir SKU'dur. Sağlayıcı yanıtı, onaylanmış eşlemesi olmayan bir kullanım paketi içerdiğinde ağ geçidi başarısız bir şekilde kapatılmalıdır.
Faturalandırma bekletme işlemini tetiklemesi gereken örnekler:
- Bir model yanıtı
cached_input_tokensiçerir, ancak katalogda yalnızca genel giriş ve çıkış jetonu hızları bulunur. - Bir akıl yürütme modeli
reasoning_tokensdeğerini döndürür, ancak hiçbir akıl yürütme SKU'su yapılandırılmamıştır. - Barındırılan bir arama aracı sorgu başına faturalandırır, ancak ağ geçidi yalnızca model belirteçlerini kaydeder.
- Toplu iş indirim alır, ancak katalog bunu standart sunucusuz SKU ile eşleştirir.
- Tedarik edilen bir dağıtım, saatlik kapasite ücretleri oluşturur ancak kiracı defteri, jeton başına ödeme yapılmasını bekler.
- Bölgesel dağıtım, etkin katalogda bulunmayan bir yerleşim değiştiriciyi kullanıyor.
Faturalandırmanın askıya alınması etkinliği kaybetmemelidir. Ham sağlayıcı kullanımını, normalleştirilmiş kullanımı, istek tanımlayıcılarını, kiracı tanımlayıcılarını, sağlayıcı hesap kapsamını, denenen katalog sürümünü, eksik SKU alanlarını ve anlaşmanın engellenme nedenini korumalıdır. Katalog güncellenip onaylandıktan sonra bekletme kuyruğu belirleyici bir şekilde yeniden oynatılabilir.
Onaydan Önce Fiyat Kartı Fark Kontrollerini Kullan
Sağlayıcı fiyatlandırma sayfaları ve API'ler her zaman makine açısından kararlı değildir ve sözleşmeler genel fiyatları geçersiz kılabilir. Yine de otomatik fark kontrolleri uyarı olarak faydalıdır. Müşterilerin görebileceği fiyat teklifleri etkilenmeden önce değişiklikleri tespit etmeleri gerekir.
Fiyatlandırma içe aktarma kanalı, yeni gözlemlenen fiyat kartlarını en son onaylanmış katalog ve işaretle karşılaştırmalıdır:
- yeni modeller veya kullanımdan kaldırılan modeller;
- girdi, önbelleğe alınmış girdi, çıktı veya muhakeme oranları değiştirildi;
- yeni belirteç kategorileri veya araç göstergeleri;
- önbelleğe yazma veya önbellek isabet çarpanları değiştirildi;
- yeni bölge, ikamet veya pazar yeri değiştiricileri;
- toplu indirim kuralları değiştirildi;
- tedarik edilen kapasite veya taahhüt edilen kapasite kuralları değiştirildi;
- para birimi değişiklikleri;
- Yuvarlama veya minimum birim değişiklikleri;
- genel fiyat kartları ile hesaba özel sözleşme oranları arasında çakışmalar.
Öneri: Notları ve içe aktarmaları taslak veri olarak değerlendirin. Faturalanan trafiği, iş ortağının görünür fiyatlandırmasını veya finans ihracatlarını etkileyen herhangi bir değişiklik için insan onayını zorunlu kılın. Dahili denemelerde korumalı alan kataloğu kullanılabilir ancak bunun açık harcama tavanları olmalı ve hiçbir zaman onaylı müşteri faturalandırmasıyla karıştırılmamalıdır.
Fiyatlandırma CI'sı olarak Fiyat Teklifi Testleri Ekle
Fiyatlandırma değişikliklerinin, kod değişiklikleriyle aynı nedenden dolayı testlere ihtiyacı vardır: küçük bir düzenleme birçok istek şeklini etkileyebilir. Katalog satırları, SKU eşlemeleri, sağlayıcı bağdaştırıcıları veya işaretleme politikaları değiştiğinde teklif testleri çalıştırılmalıdır.
Fiyatlandırma yüzeyini kapsayan sentetik istek şekillerini kullanın:
- giriş ve çıkış jetonlarıyla standart metin isteği;
- önbelleğe alınmış giriş jetonlarıyla istek;
- Ayrı muhakeme kullanımıyla muhakeme ağırlıklı istek;
- arama, dosya veya kod yürütme ücretleri içeren araç kullanma isteği;
- Resim, ses, video veya oluşturulan medya birimleriyle çok modlu istek;
- indirimli fiyatlar ve gecikmeli ödemeyle toplu iş;
- saatlik kapasite ve yayılma davranışı ile dağıtım sağladı;
- bölgesel veya ikamet kapsamlı istek;
- sağlayıcıya özel sözleşme oranlarına sahip kiracı;
- İş ortağı kiracısı, fiyat artışı veya indirim politikasına sahip.
Her test nihai toplamdan daha fazlasını belirtmelidir. Seçilen katalog sürümünü, SKU listesini, fatura birimlerini, ücretleri, yuvarlama davranışını, para birimini, tahmini toplamı, rezervasyon tutarını ve beklenen ödeme satırlarını belirtmelidir.
Örnek Teklif Testi
<ön>Bu tür testler, kontrol panellerinin gizlediği katalog hatalarını yakalar: eksik önbelleğe alınmış jeton SKU'su, eski mantık yürütme oranı veya yalnızca tek bir sağlayıcı hesap kapsamı için görünen katman uyumsuzluğu.
Sağlayıcı Fatura Boyutlarına göre Mutabakat Etme
Geri ödeme toplamları mutabakat için yeterli değil. Ağ geçidi, genel muhasebe satırlarını sağlayıcı faturasının kullandığı boyutlarla aynı boyutlara göre toplamalı, ardından bu toplamları kiracılara, ekiplere, anahtarlara, kullanıcılara, ürünlere ve iş akışlarına eşlemelidir.
Mutabakat işi, sağlayıcı, hesap, fatura dönemi, sayaç, model, SKU, bölge, dağıtım türü, hizmet katmanı, para birimi ve katalog sürümü gibi alanlara göre gruplandırılmalıdır. Farklılıklar bilinen nedenlere göre gruplandırılmalıdır:
- döviz kuru zamanlaması veya para birimi dönüştürme;
- fatura satırı düzeyinde yuvarlama yerine istek düzeyinde yuvarlama;
- gecikmiş sağlayıcı kullanım raporları;
- barındırılan araç etkinliklerinin eksik olması;
- katalog sürümü uyuşmazlığı;
- sağlayıcı tarafı kredileri, taahhütleri veya kurumsal indirimleri;
- vergiler, pazaryeri ücretleri ve kullanım dışı masraflar;
- manuel ayarlamalar veya geri ödemeler.
Öneri: Model sağlayıcının maliyet oranları, müşteri ters ibraz oranlarından ayrıdır. Sağlayıcı faturaları, müşteriye yönelik fiyatlandırmayı otomatik olarak değiştirmemesi gereken krediler, taahhütler, indirimler veya vergiler içerebilir. Temiz bir sistem, her iki rakamı da açıklayabilir: sağlayıcının ne kadar ücretlendirdiği ve onaylı ağ geçidi politikası kapsamında kiracıya ne kadar fatura kesildiği.
Fiyat Kaynaklarını Finans ve İş Ortaklarına İfşa Edin
Fiyatlandırma kataloğu yalnızca dahili bir faturalandırma bağımlılığı değildir. Finans ekiplerinin, platform yöneticilerinin ve iş ortaklarının bir fiyatın güncel ve güvenilir olup olmadığını bilmesi gerekir.
Yönetici görünümleri ve iş ortağı API'leri aracılığıyla kaynak alanlarını açığa çıkarın:
- mevcut fiyat teklifi oranı ve para birimi;
- yürürlük tarihi ve planlanan bitiş tarihi;
- kaynak URL'si veya sözleşme referansı;
- onay durumu;
- sağlayıcı hesabı kapsamı;
- markalama veya indirim politikası;
- fiyatın tahmin edilip edilmediği, onaylandığı, kullanımdan kaldırıldığı, bloke edildiği veya yerine geçilip geçilmediği;
- son mutabakat durumu.
Bu, alt pazardaki ürünlerin, eski "en ucuz model" iddialarını veya üst pazar fiyatlandırma değişikliklerinden sonra sabit müşteri fiyatlarını sunmaktan kaçınmasına yardımcı olur. Ayrıca bütçeler ve faturalar uyuşmadığı durumlarda finansa savunulabilir bir yol sağlar.
Uygulama Kontrol Listesi
- Geçerlilik tarihleri ve onay durumlarını içeren değişmez bir fiyatlandırma kataloğu oluşturun.
- Yalnızca genel jeton toplamlarını depolamak yerine faturalandırılabilir birimleri açıkça temsil edin.
- Her kullanım etkinliğinde istenen takma adı, yukarı akış model kimliğini ve fiyatlandırma SKU'sunu saklayın.
- Fiyat tekliflerinde, rezervasyonlarda, genel muhasebe satırlarında ve mutabakat kayıtlarında
catalog_version_iddeğerini sürdürün. - Kullanım eşlenmemiş faturalandırılabilir bir boyut içerdiğinde başarısız olarak kapatılır.
- Sağlayıcı fiyat sapmalarını tespit etmek için taslak içe aktarmaları ve fark kontrollerini kullanın.
- Katalog değişiklikleri faturalandırılan müşteri trafiğini etkilemeden önce onay gerektir.
- Önbelleğe alınan belirteçler, akıl yürütme belirteçleri, araçlar, toplu işler, sağlanan dağıtımlar ve bölgesel değiştiriciler için fiyat teklifi testleri ekleyin.
- Sağlayıcı maliyet oranlarını müşteri ters ibraz oranlarından ayırın.
- Farklılığı kiracılara dağıtmadan önce sağlayıcı fatura boyutlarına göre mutabakat sağlayın.
Ödüller
Daha fazla sürüm oluşturma, daha fazla operasyonel çalışma anlamına gelir. Her fiyat değişikliğinin içe aktarılması, incelenmesi, onaylanması, test edilmesi ve kullanıma sunulması gerekir. Avantajı, eski kullanımın hiçbir zaman yanlışlıkla yeni bir ücrete göre yeniden hesaplanmamasıdır.
Kapatılmaması yeni model erişimini geciktirebilir. Faturalanan müşteri trafiği için doğru varsayılan budur. Dahili denemeler için açık harcama sınırları ve anlaşılır etiketler içeren bir korumalı alan kataloğu kullanın.
Otomatik fiyat çıkarma faydalıdır ancak yetkili değildir. Herkese açık sayfalar düzeni değiştirebilir, sözleşme indirimlerini atlayabilir veya fiyatlandırmayı düz yazıyla açıklayabilir. Sapmayı tespit etmek için otomasyonu kullanın, ardından incelenen katalog satırlarını faturalandırmayı etkilemeden önce onaylayın.
Mükemmel ön kontrol tahminleri gerçekçi değildir. Akış, yeniden denemeler, aracı döngüleri, önbellek isabetleri ve barındırılan araçlar son kullanımı değiştirebilir. Bir ağ geçidinin ihtiyatlı çekinceleri yanıt sonrası uzlaşma ve net sapma raporlamasıyla birleştirmesi gerekir.
Tahmin: Fiyatlandırma Katalogları Ağ Geçidi Altyapısı Olacak
Tahmin: Yapay zeka kullanımı ekipler arasında yayıldıkça fiyatlandırma kataloğu da model kataloğu kadar önemli hale gelecektir. Model yönlendirme "bu istek nereye gitmeli?" sorusunun cevabını verir. Fiyatlandırma kontrolü "bu isteği fiyatlandırabilir, rezerve edebilir, uzlaştırabilir ve açıklayabilir miyiz?" sorusunu yanıtlar.
Tahmin: Fiyatlandırmayı statik yapılandırma dosyalarında tutan ekipler, sağlayıcılar daha fazla belirteç kategorisi, araç ölçer, önbellek kuralı ve kapasite planı ekledikçe zorluk yaşayacaktır. Baskı, uygulama geliştiricilerinden değil, öncelikle finanstan ve iş ortaklarından gelecek.
Sonuç
Çok modelli bir ağ geçidi, fiyatlandırmayı bir yan tablo olarak ele alamaz. Yürürlük tarihleri, SKU eşlemesi, teklif testleri, onay iş akışı ve fatura mutabakatı içeren sürümlü bir kataloğa ihtiyacı var. Pratik kural basittir: Her faturalandırılmış kullanım kümesi onaylanmış bir ücretle eşleşmeli, her fiyat teklifi değişmez bir katalog sürümüne referans vermeli ve her yerleşik defter satırı, sağlayıcı fiyatları değiştikten sonra açıklanabilir kalmalıdır.
Üretim trafiğini halihazırda etkileyen boyutlarla başlayın: model, belirteç kategorisi, hizmet katmanı, bölge, dağıtım türü, önbellek davranışı ve barındırılan araçlar. Daha sonra onay durumlarını, başarısızlıkla kapatılan davranışı ve mutabakat gruplamalarını ekleyin. Bu temel, fiyat sapmalarının bir faturalandırma olayına dönüşmesini önler.