Bayi Ürünü Olarak Toplu İndirimler: Async AI API Katmanı için Marj Yönetimi

Toplu kapasite yalnızca daha ucuz bir çıkarım değildir. Bir AI API bayisi için bu, farklı ekonomi, müşteri beklentileri, cüzdan davranışı, mutabakat kuralları ve destek riski içeren ayrı bir ürün katmanıdır. Bunu "aynı API, sadece indirimli" olarak ele almak, platformların kafa karıştırıcı faturalarla, hatalı marj varsayımlarıyla ve müşterilerin eşzamansız bir hizmetten gerçek zamanlı gecikme beklemesiyle sonuçlanmasına neden olur.

Pratik sorun şudur: Sağlayıcılar, eşzamansız toplu işleme için önemli ölçüde daha düşük fiyatlar sunabilir, ancak müşterileriniz sağlayıcıdan değil sizden satın alır. Brüt kar marjını korurken, büyük işler yapılmadan önce yeterli dengeyi ayırırken, yalnızca tamamlanan işleri hallederken ve müşterilere aynı modelin neden iki farklı fiyata sahip olabileceğini gösterirken tasarrufları açığa çıkarmak için savunulabilir bir yola ihtiyacınız var.

Gerçek, Öneri ve Tahmin Nedir?

Gerçekler

Birçok büyük AI sağlayıcısı, eşzamanlı çağrılardan daha düşük birim fiyatlandırmaya sahip eşzamansız toplu API'leri belgelemektedir. OpenAI, Toplu İşlem API işlemini 24 saatlik bir tamamlama aralığıyla ve senkronize API'lere kıyasla %50 indirimle belgeliyor. Anthropic, %50 maliyet indirimiyle büyük hacimli Mesaj istekleri için Mesaj Gruplarını belgeliyor. Google, standart maliyetin %50'si karşılığında büyük istek hacimleri için Gemini toplu iş modunu belgeliyor. Azure OpenAI, ayrı sıraya alınmış jeton kotası, 24 saatlik hedef geri dönüş ve küresel standarttan %50 daha düşük maliyetle küresel toplu işlemeyi belgelemektedir.

Bu gerçekler, her sağlayıcının her uç noktayı, bölgeyi, model özelliğini, dosya biçimini veya operasyonel davranışı aynı şekilde desteklediği anlamına gelmez. Mevcut sınırlar ve desteklenen özellikler, yayınlanmadan, fiyatlandırma güncellemelerinden veya sözleşme değişikliklerinden önce sağlayıcı belgelerine göre kontrol edilmelidir.

Öneriler

Toplamayı gerçek zamanlı çıkarımda gizli bir indirim olarak değil, eşzamansız bir katman olarak kullanıma sunun. Gerçek zamanlı ve eşzamansız kullanımı ayrı defter kategorilerinde tutun. Bir işi kabul etmeden önce müşteri cüzdan bakiyesini ayırın, ardından yalnızca tamamlanan istek satırlarını kapatın. Her ikisi de aynı model ailesini kullansa bile, gerçek zamanlı ve eşzamansız çalışma için ayrı fatura satırları gösterin. Sağlayıcı indiriminin aktarılıp aktarılmadığını, muhafaza edilip edilmediğini veya sabit bir müşteri fiyatına dahil edilip edilmediğini açıklayan bir marj politikası yayınlayın.

Tahminler

Toplu API'ler olgunlaştıkça, daha fazla bayi platformu "eşzamansız AI kredilerini" ayrı bir bütçe havuzu olarak satacak. Bazı müşteriler faturalarını düşürmek için gecikmeye duyarlı işleri toplu katmanlar aracılığıyla yönlendirmeye çalışacak, bu nedenle ağ geçitlerinin geri dönüş beklentilerini, iş boyutu kurallarını ve iş yükü sınıflandırmasını zorunlu kılan kontrollere ihtiyacı olacak. Müşterinin güvenini kazanan platformlar, faturaların denetlenmesini zorlaştırmadan toplu tasarrufları görünür hale getiren platformlar olacaktır.

Toplu Grubu Müşteriye Yönelik bir SKU# Olarak Tanımlayın

Ürüne verilecek ilk karar adlandırmaktır. "İndirimli GPT", "ucuz Claude" veya "yarı fiyatına Gemini" şeklinde satmayın. Bu isimler müşterileri hizmet davranışına değil modele ve fiyata bağlıyor. Daha anlaşılır bir katalog, hizmet katmanlarını model ailelerinden ayırır:

• Gerçek zamanlı: Gecikmenin önemli olduğu ve yanıtların kullanıcı iş akışı sırasında beklendiği etkileşimli istekler.
• Öncelik: acil uygulama yolları için daha yüksek maliyetli, daha düşük gecikmeli kapasite.
• Standart: sıradan hız ve kota davranışıyla normal eşzamanlı çıkarım.
• Async toplu iş: daha sonra tamamlanabilen ve kısmi hata işlemeyi tolere edebilen işler için sıraya alınmış işleme.

Müşteri aynı ürünün daha düşük kaliteli bir versiyonunu satın almadığı için bu ayrım AI API marj yönetimi açısından önemlidir. Farklı bir teslimat vaadi satın alıyorlar. Bu teslimat vaadi, katmanın ne için olduğunu belirtmelidir: gecelik değerlendirmeler, belge zenginleştirme, büyük yerleştirme işleri, denetleme dolguları, sentetik veri incelemesi, transkript analizi veya son kullanıcıyı engellemeyen diğer iş yükleri.

İyi bir eşzamansız SKU açıklaması dört alan içerir: desteklenen model aileleri, beklenen geri dönüş dili, maksimum iş boyutu politikası ve faturalandırma davranışı. Yukarı akış sağlayıcı sözleşmesi bunu gerçekten garanti etmedikçe "24 saat içinde garantilidir" demekten kaçının. Sağlayıcı hedef geri dönüşü söylüyorsa hedef geri dönüşü kullanın. Sağlayıcı tamamlanma aralığı diyorsa bunu müşteriye yönelik terimlerle dikkatli bir şekilde belirtin.

Göndermeden Önce Bir Fiyatlandırma Modeli Seçin

Toplu indirimler ticari bir tercih yaratır. Sağlayıcı sizden daha az ücret alabilir ancak müşterinin bu indirimin ne kadarını göreceğine siz karar verirsiniz. Üç pratik yaklaşım vardır.

Tam Geçiş İndirimi

Bu modelde, sağlayıcı toplu kapasitesi %50 daha ucuzsa müşteri fiyatı da yaklaşık %50 artı açık platform ücretiyle birlikte düşer. Bu, fiyata duyarlı müşteriler için açıklanması kolay ve çekici bir durumdur. Bayi stratejiniz kâr marjını artırmak değil, hacmi artırmak olduğunda en iyi sonucu verir.

Bunun karşılığında marj sıkıştırması yapılır. Ayrıca, iş yükü toplu iş için uygun olmadığında bile müşterileri gerçek zamanlı katmanlardan kaçınmaları konusunda eğitebilir. Tam geçişi seçerseniz gerçek zamanlı ürünü açık kullanım senaryosu rehberliği, iş kontrolleri ve farklı bütçelerle koruyun.

Kısmi Geçiş İndirimi

Burada sağlayıcı indirimi paylaşılır. Örneğin, bir sağlayıcının gerçek zamanlı maliyeti birim başına 10 ABD Doları, toplu maliyeti ise 5 ABD Dolarıdır. Eşzamansız toplu iş için müşteriden 7,50 ABD doları ücret alabilirsiniz. Müşteri, gerçek zamanlı olarak %25'lik anlamlı bir indirim görür ve siz de sıraya alma, raporlama, destek, başarısız satır işleme ve mutabakat için ek kâr marjını korursunuz.

Platform, sağlayıcı toplu dosyasını iletmenin ötesinde gerçek bir iş yaptığı için bu genellikle en savunulabilir bayi modelidir. Önemli olan şeffaflıktır: Müşterinin yukarı yönlü maliyetinizi görmesi gerekmez, ancak eşzamansız grubun kendi birim fiyatı ve fatura kategorisine sahip olduğunu görmelidir.

Sabit Eşzamansız Fiyat Planları

Bazı satıcılar, model ailesi veya pakete göre sabit fiyatları tercih eder: "Async Standart Modeller", "Async Premium Modeller" veya "Async Embeddings". Bu, yukarı akış sağlayıcı fiyatlandırmasının sık sık değiştiği durumlarda satışları ve fiyat tekliflerini basitleştirebilir. Ayrıca, sağlayıcı düzeyinde geçişten ziyade bütçenin öngörülebilirliğine önem veren müşteriler için fatura gürültüsünü de azaltır.

Risk, fiyat kaymasıdır. Sağlayıcı liste fiyatları, toplu indirimler, bölge değiştiriciler veya model eşlemeleri değişirse, sabit bir plan sessizce kârsız hale gelebilir. Yürürlük tarihlerini ve sözleşme kimliklerini içeren versiyonlu bir fiyat tablosu kullanın. Minimum yararlı şema şunları içerir:

pricing_policy_version
customer_contract_id
model_family
service_tier
provider_list_price
provider_batch_price
customer_realtime_price
customer_async_price
discount_pass_through_percent
effective_from
effective_until
currency
rounding_rule

Ayrı Gerçek Zamanlı ve Eşzamansız Defterler

Defter, ürün netliğinin işlevsel hale geldiği yerdir. Gerçek zamanlı aramalar ve eşzamansız toplu satırlar tek bir karma kullanım grubunda yer alırsa müşteriler eninde sonunda aynı modelin neden farklı ücretlerle faturalandırıldığını soracaktır. Finans, marjın doğru hesaplanıp hesaplanmadığını soracaktır. Destek ekibi kısmen tamamlanmış işleri açıklamakta zorlanacak.

Gerçek zamanlı ve eşzamansız çalışmalar için ayrı defter kategorileri kullanın. Her yerleşik kullanım kaydı en azından kiracıyı, müşteri sözleşmesini, API anahtar veya hizmet hesabını, model takma adını, sağlayıcıyı, hizmet katmanını, iş kimliğini, istek satırı kimliğini, giriş birimlerini, çıktı birimlerini, sağlayıcı maliyet esasını, müşteri fiyat esasını, rezervasyon kimliğini, ödeme durumunu ve fatura satırı grubunu içermelidir.

Bu ayırma aynı zamanda birleşik AI API faturalandırmanın anlaşılır kalmasına da yardımcı olur. Bir müşteri faturasında aynı model ailesi için iki satır gösterilebilir:

Müşterinin sağlayıcının dahili toplu nesnesini anlamasına gerek yoktur. Eşzamansız çalışmanın, farklı geri dönüş beklentileri olan farklı bir hizmet katmanı kullanması nedeniyle farklı şekilde fiyatlandırıldığını anlamaları gerekiyor.

İşleri Kabul Etmeden Önce Cüzdan Bakiyesini Ayırın

Toplu işler büyük olabilir. Bir işi parayı kontrol etmeden kabul ederseniz saatler sonra müşterinin tamamlanan iş için ödeme yapamayacağını keşfedebilirsiniz. Daha güvenli yöntem fiyat teklifi verme, rezerve etme, yürütme, kapatma ve serbest bırakmadır.

1. Alıntı: Gönderilen satırlardan, modelden, hizmet katmanından, jeton tahminlerinden, ilgiliyse araç kullanımından ve yapılandırılmış eşzamansız fiyattan maksimum müşteri ücretini tahmin edin.
2. Rezerve: Yukarı akış toplu işi oluşturmadan önce cüzdan bakiyesini veya kredi limitini koruyun.
3. Yürüt: İşi sağlayıcıya gönderin ve sağlayıcı durumunu müşteri faturalandırma durumundan ayrı olarak izleyin.
4. Yerleştirme: Yalnızca faturalandırılabilir kullanımı tamamlayan ve üreten satırları ücretlendirin.
5. Sürüm: Başarısız olan, süresi dolan, iptal edilen, reddedilen veya işlenmemiş satırlar için kullanılmayan rezervasyonu döndürün.

Fazla rezervasyon, gerçek bir müşteri deneyimi sorunudur. İhtiyatlı tahminler sizi korur ancak müşterinin kredilerini saatlerce kilitleyebilirler. Daha iyi bir uygulama, hem tahmini maksimum değeri hem de çalışan geçici tahmini saklar. Sağlayıcı, tamamlama sırasında veya sonrasında satır düzeyinde kullanımı geri verirse, geçici tutarı güncelleyin ve fazla parayı kesinleştirmeden hemen sonra serbest bırakın.

Her rezervasyon hareketi, değiştirilebilir bir bakiye düzenlemesi değil, bir defter girişi olmalıdır. Açık bir dizi şu şekilde olabilir: reservation_created, reservation_increased, row_settled, row_failed_release, job_expired_release, manual_adjustment, invoice_finalized. Bu, anlaşmazlıkları denetlenebilir hale getirir.

Yalnızca İş Düzeyinde Değil, Satır Düzeyinde Yerleşin

Toplu işler genellikle karışık sonuçlara yol açar. Bazı satırlar tamamlanır, bazıları doğrulamada başarısız olur, bazıları model sınırlarına ulaşır ve bazıları bir işin süresi dolduğunda veya iptal edildiğinde işlenmeden kalabilir. Defteriniz yalnızca grup düzeyindeki toplamları saklıyorsa hangi müşteri satırlarının faturalandırıldığını net bir şekilde yanıtlayamazsınız.

Kararlı kimliklere sahip, dayanıklı satır düzeyindeki kayıtları kullanın. Her satırda müşterinin görebileceği bir satır tanımlayıcısı, dahili bir satır kimliği, destekleniyorsa sağlayıcı özel kimliği, istek karması, model takma adı, tahmini maliyet, son kullanım, son durum, hata sınıfı, ödeme durumu ve fatura satırı referansı bulunmalıdır. İstek karması, varsayılan olarak ham istemin saklanmasını gerektirmeden, geçicilik ve anlaşmazlık incelemesine yardımcı olur.

Satır düzeyindeki yerleşimin depolama ve kullanım maliyeti daha yüksektir, ancak kısmi tamamlamanın üstesinden gelmenin tek sağlam yoludur. Ayrıca daha iyi müşteri raporlamasını da destekliyor: "9.842 satır tamamlandı, 121'i başarısız doğrulama, 37'sinin süresi doldu, 18,42 ABD doları serbest bırakıldı." Bu, "toplu iş başarısız oldu" veya "toplu iş kısmen tamamlandı" ifadesinden daha faydalıdır.

Toplu Durumu İş Ortağı Aracılığıyla Açığa Çıkarın API

Müşterileriniz ajanslar, SaaS platformları veya alt bayi portallarıysa, toplu durumunu kendi ürünlerinin içinde göstermeleri gerekir. Yararlı bir İş Ortağı API iş durumunu, satır sayılarını, tahmini maliyeti, ayrılan tutarı, kapatılan tutarı, serbest bırakılan tutarı ve hata özetlerini göstermelidir. Bu, sahip olunması güzel bir kontrol paneli özelliği değil, pratik AI API bayi işlemlerinin bir parçasıdır.

Kısa bir yanıt şekli şu şekilde görünebilir:

{
  "job_id": "batch_job_123",
  "customer_id": "cust_456",
  "service_tier": "async_batch",
  "model_alias": "chat-premium",
  "status": "running",
  "submitted_rows": 10000,
  "completed_rows": 8420,
  "failed_rows": 31,
  "expired_rows": 0,
  "estimated_customer_cost": "42.00",
  "reserved_amount": "50.00",
  "settled_amount": "35.84",
  "released_amount": "0.00",
  "currency": "USD",
  "partial_completion_allowed": true
}

Sağlayıcı ayrıntılarını müşteri açısından anlamlı durumlarla eşleştiren durumları kullanın: sıraya alındı, doğrulanıyor, çalışıyor, tamamlandı, completed_with_errors, başarısız oldu, iptal edildi, süresi dolmuş, kapatılıyor, çözüldü. Orijinal sağlayıcı durumunu, destek ekipleri için dahili bir alanda veya teşhis uç noktasında tutun.

Kötüye Kullanımı Önleyen Müşteri Kontrolleri

Müşteriler fiyata göre optimizasyon yapacağından eşzamansız katmanların kontrollere ihtiyacı vardır. Bazıları indirimin yeterince büyük olması durumunda etkileşimli iş yüklerini toplu olarak göndermeye çalışacaktır. Bu durum, kullanıcıya yönelik bir iş akışının hemen tamamlanması için tasarlanmamış bir işi beklediğinde üründe sürtüşmeye neden olur.

Müşteri, anahtar ve iş düzeyinde kontroller ekleyin:

• İzin verilen hizmet katmanları: yalnızca gerçek zamanlı, yalnızca eşzamansız veya her ikisi.
• İzin verilen model aileleri: sözleşmenin dışındaki modellerde pahalı eşzamansız işleri önler.
• Maksimum iş harcaması: müşteri tarafından yapılandırılan sınırın üzerindeki işleri reddedin.
• Kabul edilen maksimum geri dönüş süresi: müşterilerin bir işin 1 saat, 6 saat veya 24 saat sonra faydalı olup olmadığını ifade etmesine olanak tanır.
• Kısmi tamamlama politikası: tüm satırları zorunlu kıl, kısmi tamamlamayı kabul et veya başarısızlık oranı bir eşiği aşarsa iptal et.
• İş yükü etiketi: değerlendirmeler, yerleştirmeler, zenginleştirme, denetleme, dolgu, analiz veya yönetilen diğer kategoriler.

Bu kontroller aynı zamanda desteğe de yardımcı olur. Bir müşteri, eşzamansız bir işin hemen geri dönmediğinden şikayet ettiğinde iş kaydı, bunun rahat bir geri dönüş politikasına ve kabul edilen kontrollere sahip bir eşzamansız katman altında gönderildiğini göstermelidir.

Marj ve Güvene İlişkin Operasyonel Uyarılar

Toplu indirimler, yalnızca operasyonların kontrol edilmesi durumunda ekonomiyi iyileştirir. Takılan işler, sağlayıcı tarafında süre sonu, anormal satır hatası oranları, tekrarlanan doğrulama hataları, rezervasyon yaşı, ödeme gecikmesi ve gecikmeye duyarlı iş yüklerini sürekli olarak eşzamansız katmanlara gönderen müşteriler için uyarı ekleyin.

Marj uyarıları, güvenilirlik uyarıları kadar önemlidir. Etkin marjı müşteriye, model ailesine, sağlayıcıya, hizmet katmanına ve fiyatlandırma politikası sürümüne göre izleyin. Sağlayıcı fiyat değişikliği veya yönlendirme değişikliği, kârlı bir eşzamansız planı herhangi bir görünür uygulama hatası olmadan zarar eden bir plana dönüştürebilir.

Uygulama Kontrol Listesi

• Gerçek zamanlı, öncelikli, standart ve eşzamansız toplu iş için müşteriye yönelik açık SKU'lar oluşturun.
• Sağlayıcı liste fiyatı, sağlayıcı toplu fiyatı, müşteri fiyatı, geçiş yüzdesi, sözleşme kimliği ve geçerlilik tarihlerini içeren versiyonlu bir marj politikası tanımlayın.
• Gerçek zamanlı ve eşzamansız kullanımı ayrı defter kategorilerinde saklayın.
• Eşzamansız bir işi kabul etmeden önce cüzdan bakiyenizi ayırın.
• Tamamlanan satırları tek tek kapatın ve başarısız olan, süresi dolan, iptal edilen veya işlenmeyen satırlar için kullanılmayan rezervasyonu iptal edin.
• Sıraya alınmış, çalışıyor, tamamlanmış, başarısız olmuş, süresi dolmuş, kapatılmış ve kısmen faturalandırılmış durumları İş Ortağı API aracılığıyla açığa çıkarın.
• Aynı model ailesi için bile gerçek zamanlı ve eşzamansız toplu işlemleri ayrı fatura satırları olarak gösterin.
• Yukarı akış sağlayıcı sözleşmesi desteklemediği sürece sert HDS ifadelerinden kaçının.
• Model erişimi, maksimum iş harcaması, geri dönüş toleransı ve kısmi tamamlama için müşteri kontrolleri ekleyin.
• Takılan gruplar, yüksek başarısızlık oranları, eski rezervasyonlar, ödeme gecikmesi ve marj kayması hakkında uyarı.

Sonuç

Toplu API'lerin ticari değeri tek başına indirim değildir. İndirimli asenkron kapasiteyi müşterilerin anlayabileceği ve finans ekiplerinin denetleyebileceği bir ürüne dönüştürme yeteneğidir. Bu, açık eşzamansız SKU'lar, kasıtlı bir geçiş veya tutulan marj politikası, cüzdan rezervasyonu, satır düzeyinde ödeme, fatura ayırma ve İş Ortağı API görünürlüğü gerektirir.

Savunulabilecek en basit kural şudur: toplu satışı, ayrı bir taahhütle ayrı bir hizmet katmanı olarak satmak. Müşteriler, gecikmeli işleme ve kısmi tamamlama mekanizmalarını kabul ettiklerinde daha düşük birim fiyat alabilirler. Fiyatlandırma politikanız, defteriniz ve faturanız bu ödünleşimi açıkça ortaya koyduğunda marjı koruyabilirsiniz.

İlgili okumalar

• sağlayıcı fiyat sapmaları için sürümlü fiyatlandırma kataloğu