Cloudflare, AI Gateway'e küçük ama önemli bir kontrol ekledi: Ekipler artık bir isteğin çalıştırılmasına izin verilmeden önce üçüncü taraf sağlayıcı kimlik bilgilerine ihtiyaç duyabilir. Ağ geçidi geçerli kimlik bilgilerini bulamazsa istek, Cloudflare tarafından yönetilen Birleşik Faturalandırmaya geri dönmek yerine HTTP 400 ile başarısız olur.

Bu, kendi anahtarınızı getir veya BYOK'un pratik anlamını değiştirir. Şimdiye kadar eksik bir sağlayıcı anahtarı, farklı bir faturalandırma yolu altında olsa da başarılı bir model çağrısına neden olan bir yapılandırma sorunu olabiliyordu. Yeni ayarla birlikte eksik kimlik bilgileri ciddi bir politika ihlali haline geliyor. Müşteriye ait model hesapları merkezi olarak faturalandırılan trafikten ayıran kuruluşlar için bu ayrım, durum kodunun önerdiğinden daha önemlidir.

Ne değişti

Cloudflare'in 14 Eylül güncellemesi, yeni davranışı uygulamak için iki yol ekliyor. Ağ geçidi düzeyinde yöneticiler byok_only ayarını etkinleştirebilir. İstek zamanında, arayanlar bu istek için toptan faturalandırma geri dönüşünü önlemek için cf-aig-no-toptan satış başlığını gönderebilirler.

Kontrol uygulandığında ve sağlayıcı kimlik bilgileri mevcut olmadığında, AI Gateway HTTP 400 döndürür. Cloudflare, Workers AI isteklerine izin verildiğini söyler, dolayısıyla politika özellikle Cloudflare tarafından yönetilen kimlik bilgileri üzerinden yönlendirilebilecek üçüncü taraf sağlayıcı istekleriyle ilgilidir.

Bu özellik yeni bir yönlendirici modeli veya fiyatlandırma değildir. indirim. Bu bir faturalandırma modu korkuluğudur. Bu, onu birleşik AI API faturalandırma ile doğrudan alakalı hale getiriyor çünkü artık tek bir ağ geçidi, merkezi olarak faturalandırılan trafik ile müşterinin kendi sağlayıcı hesabından ücretlendirilmesi gereken istekler arasında daha keskin bir çizgi çizebiliyor.

Faturalandırmada geri dönüş neden riskli?

Öncelik çalışma süresi olduğunda geri dönüş kullanışlıdır. Sağlayıcının kimlik bilgisi eksikse, süresi dolmuşsa veya doğru yola eklenmemişse, ağ geçidi tarafından yönetilen kimlik bilgisi uygulamanın çalışmaya devam etmesini sağlayabilir. Ancak aynı kolaylık, karmaşık bir fatura takibi de yaratabilir.

Bir SaaS satıcısı, ajansı veya dahili platform ekibi, belirli bir kiracının trafiğinin yalnızca o kiracının OpenAI, Anthropic, Google veya diğer sağlayıcı hesabına göre çalışacağına dair söz verebilir. Ağ geçidi bunun yerine sessizce toptan bir kimlik bilgisi kullanıyorsa, istek yine de başarılı olabilir ancak ticari anlamı değişmiştir. Platform operatörü maliyeti karşılayabilir, yanlış aktarabilir veya kullanımı müşterinin kendi sağlayıcı faturasıyla uzlaştırma olanağını kaybedebilir.

Bu, özellikle bayi ve iş ortağı API modelleri için hassastır. Bir müşteri satın alma kuralları nedeniyle BYOK'ta olabilir. Bir diğeri platform faturalı kredileri kullanabilir. Üçüncüsü, düzenleme veya veri yönetimi nedenleriyle ayrı sağlayıcı hesapları gerektirebilir. Bu ortamda faturalandırma yolu, bir uygulama ayrıntısı değil, ürün sözleşmesinin bir parçasıdır.

Cloudflare'in yeni kontrolü, ekiplere bu sözleşmeyi ağ geçidi sınırında uygulanabilir hale getirmenin bir yolunu sunar. Başarısız bir istek operasyonel açıdan can sıkıcıdır ancak hata ayıklamak, daha sonra yanlış maliyet merkezinde görünen başarılı bir istekten daha kolaydır.

Kim etkilenir?

Doğrudan hedef kitle, sağlayıcıya ait kimlik bilgileri ve Cloudflare tarafından yönetilen faturalandırmanın bir karışımıyla Cloudflare AI Gateway kullanan herhangi bir ekiptir. Değişiklik, en çok birden fazla kiracının, ortamın veya iş biriminin bir ağ geçidi yapılandırmasını paylaştığı durumlarda önemlidir.

Geliştiricilerin, bir rotanın kullanılabilirliği mi yoksa katı faturalandırma izolasyonunu mu tercih etmesi gerektiğine karar vermesi gerekecektir. Finans ve operasyon ekipleri, kazara toptan satış kullanımını önlemek için daha temiz bir mekanizmaya sahip oluyor. Güvenlik ve platform ekipleri API anahtar yönetimi için başka bir avantaja daha sahip oluyor çünkü sağlayıcı kimlik bilgilerinin varlığı veya yokluğu artık doğrudan yaptırım sonucunu doğuruyor.

Daha genel anlamda AI ağ geçidi operatörleri için güncelleme bir sinyaldir. Faturalandırma kontrolleri politika kontrollerine dönüşüyor. Artık bir isteğin belirli bir model kullandığını göstermek yeterli değil. Ağ geçitlerinin, hangi kimlik bilgisi yolunun kullanıldığını, bu kimlik bilgilerinin kime ait olduğunu, çağrıyı hangi kiracının veya API anahtarının başlattığını ve geri dönüşe izin verilip verilmediğini kaydetme ihtiyacı giderek artıyor.

Model Gate kullanıcıları, ekipleri, API anahtarlarını, kullanım analizlerini ve iş ortaklarına yönelik erişimi yönetirken aynı temel sorunla karşı karşıya kalıyor. Müşteri kapsamlı anahtar yalnızca bir kimlik doğrulama belirteci değildir; bir faturalandırma modunu, bir harcama limitini, bir sağlayıcı hesabını ve bir dizi denetim beklentisini ifade edebilir. Bu anlamlar tutarlı bir şekilde uygulanmazsa analiz kontrol panelleri ve faturalar, müşterilerin satın aldıklarına inandıkları şeylerden uzaklaşabilir.

Pratik sonuçlar

İlk pratik değişiklik, hataların ele alınmasıdır. Yalnızca BYOK denetimlerini etkinleştiren uygulamalar, ağ geçidinden gelen HTTP 400'ü bir model hatası olarak değil, bir yapılandırma veya kimlik bilgisi sorunu olarak ele almalıdır.Kimlik bilgilerini düzeltmeden aynı isteği yeniden denemek yalnızca gürültüye neden olabilir.

İkinci değişiklik, katılımdır. Müşterilerin sağlayıcı anahtarlarını getirmesine izin veren ekipler, üretim trafiği başlamadan önce daha güçlü bir kimlik bilgisi kontrolü adımına ihtiyaç duyar. Kiracı, canlı iş akışı sırasında sağlayıcı anahtarının hiçbir zaman ağ geçidi rotasına eklenmediğini keşfetmemelidir.

Üçüncü değişiklik gözlemlenebilirliktir. Ağ geçidi günlükleri ve kullanım raporları, bir isteğin BYOK'u mu, platform faturalandırmasını mı yoksa engellenmiş bir geri dönüş yolunu mu kullandığını ortaya çıkarmalıdır. Bu alan olmadan, destek ekipleri bir isteğin başarısız olduğunu bilebilir ancak başarısızlığın faturalandırma sınırını koruyup korumadığını bilemez.

Son olarak, iş ortağı platformları varsayılanlarını yeniden gözden geçirmelidir. BYOK'un katı yaptırımı her zaman doğru seçim değildir. Bazı ürünler, hizmet sürekliliğini korumak için kasıtlı olarak platform faturalandırmasına geri dönebilir. Diğerleri sözleşmeler, müşteri güveni veya marj koruması nedeniyle sert bir ayrılığa ihtiyaç duyabilir. Önemli değişiklik, kararın kazara değil açık olarak verilebilmesidir.

Neyin belirsiz olduğu

Genel değişiklik politika mekaniğini açıklıyor ancak ekiplerin yine de bunun kendi sağlayıcı karması, rota yapısı ve kimlik bilgisi devralma modeli genelinde nasıl davrandığını test etmesi gerekecek. Ayrıca uygulama çerçevelerinin ve üçüncü taraf gözlemlenebilirlik araçlarının, bu faturalandırma modu ayrımını varsayılan kontrol panellerinde ne kadar yaygın şekilde ortaya çıkaracağı da henüz belli değil.

Daha geniş yön yeterince açık. Çok modelli ağ geçitleri, API proxy'leri kadar finansal kontrol düzlemleri haline geliyor. Cloudflare'in yalnızca BYOK ayarı dar bir özelliktir ancak gerçek bir hata modunu ele alır: amaçlanan faturalandırma modelini ihlal ederken teknik olarak çalışan istek.