Cloudflare, AI Gateway kullanımının aylık faturalarda görünme biçimini değiştirdi ve bu düzenleme, operasyonel açıdan ilk bakışta göründüğünden daha önemli. 1 Eylül tarihli değişiklik günlüğünde şirket, aylık kullanım faturalarının artık girdi tokenları ve çıktı tokenları için ayrı satır öğeleri yerine model başına bir toplam maliyet satır öğesi gösterdiğini söyledi. Cloudflare ayrıca tutarlı bir sağlayıcı/model tanımlayıcı kullanarak faturalar ve günlükler genelinde model adlarını standartlaştırdığını söyledi.

Değişiklik, AI Gateway kredi satın alımlarına ilişkin faturalar için geçerli değildir. Aylık kullanım faturalarıyla ilgilidir: Finans ekiplerinin, platform ekiplerinin ve satıcıların trafik ağ geçidinden geçtikten sonra tüketimi uzlaştırmak için kullandıkları kayıtlar.

Yalnızca yüksek düzeyde bir faturaya ihtiyaç duyan müşteriler için yeni biçimin okunması daha kolay olabilir. Marjları hesaplayan, AI maliyetlerini kiracılara tahsis eden veya token karışımını iş yüküne göre denetleyen ekipler için, ayrıntılı defterin nerede olması gerektiği değişir. Fatura artık bir jeton muhasebesi yapısı olmaktan çıkıp model düzeyinde bir maliyet özetine dönüşüyor.

Cloudflare AI Gateway faturalandırmasında neler değişti?

Bu güncellemeye kadar, aylık kullanım faturaları giriş-jeton ve çıkış-jeton ücretlerini ayırabiliyordu. Bu ayrım önemlidir çünkü birçok model sağlayıcı bu token sınıflarını farklı şekilde fiyatlandırır. Büyük istemler gönderip kısa yanıtlar alan bir iş yükünün, her ikisi de aynı modelle ilişkilendirilmiş olsa bile, küçük istemler gönderip uzun yanıtlar üreten bir iş yükünden farklı bir maliyet profili vardır.

Cloudflare'in yeni fatura yapısı, bu ayrı jeton türü satır öğelerini model başına tek bir toplam maliyet satırına daraltır. Bunun pratik etkisi, model düzeyinde faturalandırmanın daha net olması, ancak bu maliyetin nasıl oluşturulduğuna ilişkin fatura düzeyinde daha az ayrıntıdır.

Aynı zamanda, model tanımlayıcılarının faturalar ve günlükler genelinde standartlaştırılması, farklı ancak bağlantılı bir sorunu ele alır: takma ad kayması. Çok modelli sistemlerde aynı model, günlüklerde, fatura aktarımlarında, kontrol panellerinde, müşteri raporlarında ve dahili yönlendirme kurallarında biraz farklı adlar altında görünebilir. Tutarlı bir sağlayıcı/model adlandırma formatı, finans ve mühendislik ekiplerinin kullanım günlüklerindeki bir dizeyi faturalardaki biraz farklı bir dizeyle eşleştirme olasılığını azaltır.

Değişikliğin bu kısmı, birleşik AI API faturalandırmasını çalıştıran herkes için açıkça faydalıdır. Tasarı bir şey söylüyorsa ve günlük akışı başka bir şey söylüyorsa mutabakat, manuel bir haritalama uygulamasına dönüşür. Standart tanımlayıcılar, otomatik birleştirmelere, kontrol panellerine ve müşteri bildirimlerine güvenmeyi kolaylaştırır.

Fatura ayrıntı düzeyi neden önemlidir?

Daha zor olan takas, belirteç ayrıntı düzeyidir. Yapay zeka altyapı ekipleri genellikle bir model için ücretlendirilen toplam tutardan daha fazlasına ihtiyaç duyar. Maliyet artışının daha uzun istemlerden mi, daha ayrıntılı çıktılardan mı, bir yönlendirme değişikliğinden mi, önbellek eksik düzeninden mi, yeni bir aracı döngüsünden mi yoksa bağlam olarak büyük dosyalar göndermeye başlayan bir müşteri entegrasyonundan mı kaynaklandığını bilmeleri gerekiyor.

Model düzeyinde bir fatura satırı borçlu olunan tutarı doğrulayabilir. Yükü yaratan davranışı tek başına açıklayamaz. Bu açıklamanın günlüklerden, dışa aktarımlardan, ağ geçidi telemetrisinden veya ayrı bir kullanım defterinden gelmesi gerekir.

Bu, en çok model sağlayıcı ile son müşteri arasında yer alan işletmeler için önemlidir. Bayiler, dahili platform ekipleri, yerleşik yapay zeka özelliklerine sahip SaaS ürünleri ve müşteri iş yüklerini yöneten ajansların tümü savunulabilir maliyet ilişkilendirmesine ihtiyaç duyar. Yukarı yönlü faturaları artık girdi ve çıktı jetonu maliyetlerini ayrı satırlar olarak göstermiyorsa fatura zamanından önce bu ayrımı korumaları gerekir.

Aynı sorun daha büyük şirketlerdeki ters ibraz için de geçerlidir. Bir finans ekibi "model X'in maliyeti şu kadar" ile yetinebilir. Bir mühendislik yöneticisinin, belirli bir veri havuzu asistanının, destek botunun veya belge iş akışının alışılmadık miktarda çıktı tokeni oluşturduğunu bilmesi gerekebilir. Bunlar farklı muhasebe sorularıdır.

Kimler etkilenir

Direct Cloudflare AI Gateway kullanıcıları doğrudan hedef kitledir. Faturalandırma gerçeğine ilişkin birincil kaynak olarak aylık faturaları kullanan herhangi bir ekip, yeni biçimin hâlâ dahili raporlama ihtiyaçlarını destekleyip desteklemediğini incelemelidir.

Ağ geçidi operatörleri ve AI API bayileri bu durumdan daha derinden etkilenmektedir. Birden fazla modele erişim satıyorlarsa, müşteri faturaları düzenliyorlar veya özel işaretlemeler uyguluyorlarsa, kendi istek başına kayıtlara ihtiyaçları vardır: model tanımlayıcı, sağlayıcı, giriş belirteçleri, çıktı belirteçleri, ilgili olduğu yerde önbelleğe alınmış belirteçler, birim fiyat, uygulanan indirim, müşteri anahtarı, proje, kiracı ve zaman damgası. Bu defter olmadan, basitleştirilmiş bir yukarı yönlü fatura, aşağı yönlü faturalandırmanın doğrulanmasını zorlaştırabilir.

Kontrol panelleri oluşturan geliştiriciler de benzer bir düzenlemeyle karşı karşıya kalır. Model adı standardizasyonu, eşleme hatalarını azaltmalıdır, ancak bu yalnızca dahili sistemlerin aynı kanonik tanımlayıcıları benimsemesi veya kasıtlı bir takma ad tablosunu sürdürmesi durumunda mümkündür.Burası, AI API kullanım analizi kontrol panelinin bir raporlama kolaylığından daha fazlası haline geldiği yerdir. Faturadan kaldırılan ayrıntıların saklandığı, sorgulandığı ve açıklandığı yer haline gelir.

Model Gate kullanıcıları ve benzer çok sağlayıcılı ağ geçidi müşterileri için alınacak ders basittir: sağlayıcı faturasını tek gerçek kaynak olarak görmeyin. Birleşik faturalandırma tam olarak faydalıdır çünkü sağlayıcılar kullanımı farklı şekilde biçimlendirir, fiyatlandırır ve sunar. Ağ geçidi düzeyindeki bir defter, ekiplerin, sağlayıcının seçtiği fatura biçimine sıkıştırılmadan önce bu bilgileri normalleştirmesine olanak tanır.

Model adı değişikliği, uzun vadeli daha büyük bir sinyal olabilir

Standartlaştırılmış tanımlayıcı güncellemesi, fatura biçimi tartışmasından daha uzun süre dayanabilir. Model adlandırma, yapay zeka yığınlarında operasyonel bir sorun haline geliyor. Sağlayıcılar model kimliklerini revize eder, bulut platformları aynı modeli kanala özel adlar altında sarar, ağ geçitleri uyumluluk için takma adlar ekler ve yapılandırma dosyalarındaki uygulama pin adlarını kullanır.

Sürüklenmeleri adlandırırken birçok şey sessizce bozulur. Maliyet raporları bir modeli birden çok satıra böler. Kullanımdan kaldırma kontrolleri hâlâ eski bir takma ad kullanan trafiği kaçırıyor. Yönlendirme politikaları bir ad için geçerliyken diğeri için geçerli değildir. Müşteri faturaları, geliştiricinin günlükleriyle eşleşmeyen bir etiket gösteriyor.

Cloudflare'in tutarlı sağlayıcı/model tanımlayıcılarına yönelik hareketi, yalnızca kullanışlı değil, denetlenebilir AI model seçimi sistemlerine yönelik daha geniş bir ihtiyacı yansıtıyor. İnsan dostu bir takma ad, uygulama katmanında hâlâ yararlı olabilir, ancak faturalandırma ve günlükler için sabit kanonik adlar gerekir.

Geriye kalan belirsizlik, Cloudflare müşterilerinin fatura dışında ne kadar ayrıntılı kullanım verisi tutacağı ve bunları uzun vadeli mutabakat için ne kadar kolay dışa aktarabilecekleridir. Değişiklik günlüğü, faturayı ve adlandırma değişikliklerini onaylar ancak özel ters ibraz modellerine sahip satıcılar veya kuruluşlar için her alt muhasebe sorusunu tek başına yanıtlamaz.

Pratik yanıt karmaşık değildir ancak acildir: aylık fatura gelmeden önce jeton düzeyindeki kullanımı yakalayın, alım sırasında model tanımlayıcılarını normalleştirin ve dahili defteri müşteri faturalandırması ve maliyet analizi için otorite haline getirin. Cloudflare'in faturası artık daha basit olabilir. Yapay zeka işletmeleri kendi muhasebelerinin daha az kesin olmasına izin vermemelidir.