Toplu İşler ve Hızlı Önbelleğe Alma ile LLM API Maliyetlerini Azaltın: Pratik Bir Başucu Kitabı

Birçok ekip, her isteği aynı eşzamanlı yol üzerinden gönderdikleri için LLM API'leri için fazla ödeme yapıyor. Bu, sohbet, kodlama asistanları, destek temsilcileri, ödeme akışları ve kullanıcıyı bekleyen her şey için uygundur. Değerlendirmeler, etiketleme, zenginleştirme, denetleme taramaları, dolgu yerleştirme, gecelik raporlar ve içerik ön işlemesi israftır.

Pratik soru "Hangi model en ucuz?" değildir. Soru şu: Hangi iş aslında anında yanıt gerektiriyor ve hangi iş bekleyebilir? Bunu yanıtladığınızda, AI API maliyet kontrolü bir mühendislik iş akışına dönüşür: trafiği sınıflandırın, gecikmeye dayanıklı işleri desteklendiği yerlerde toplu işleme gönderin, önbelleğe alma için tekrarlanan istemleri yapılandırın ve hatalar, yeniden denemeler ve operasyonel ek yük sonrasında gerçek tasarrufları ölçün.

Modele göre değil, iş yüküne göre maliyet denetimiyle başlayın

Mimariyi değiştirmeden önce, en son API kullanımının bir örneğini dışa aktarın ve bunu iş yüküne göre gruplandırın. Yararlı bir denetim tablosu şunları içermelidir:

• Uç nokta ve model: sohbet tamamlamalar, yanıtlar, yerleştirmeler, denetleme veya sağlayıcıya özel uç noktalar.
• Ortalama giriş ve çıkış jetonları: uzun istemleri kısa sınıflandırma görevlerinden ayırın.
• İstem şekli: kararlı sistem talimatları, yeniden kullanılabilir örnekler, şemalar, erişim bağlamı ve dinamik kullanıcı verileri.
• Gecikme gereksinimi: saniye, dakika, saat veya sonraki iş günü.
• Kullanıcı görünürlüğü: kişinin sonucu bekleyip beklemediği.
• Yeniden deneme ve başarısızlık oranı: hatalı biçimlendirilmiş istekler, doğrulama hataları, sağlayıcı zaman aşımları, süresi dolmuş işler ve yinelenen gönderimler.
• Sahiplik: proje, ekip, müşteri, API anahtarı veya iş ortağı hesabı.
• İşletme HDS'si: sonucun hala yararlı olduğu en son zaman.

Bu denetim genellikle "LLM trafiğinin" tek bir iş yükü olmadığını ortaya çıkarır. Etkileşimli ürün özelliklerinin, dahili otomasyonun, raporlamanın, veri hazırlamanın ve kalite değerlendirmesinin bir karışımıdır. Bunları tek bir maliyet merkezi olarak ele almak, en kolay tasarrufları gizler.

Üç şeritli bir iş yükü sınıflandırıcısı kullanın

Basit bir sınıflandırıcı, ekiplerin yanlış trafiği toplu işlere taşımasını ve ardından kaçırılan beklentiler karşısında şaşırmalarını önler.

Şerit 1: gerçek zamanlı etkileşimli istekler

Bunları eşzamanlı tutun. Bunlar arasında sohbet kullanıcı deneyimi, yardımcı pilotlar, destek temsilcileri, döngüdeki insan incelemesi, canlı arama veya erişim akışları ve anında yan etkileri olan araç çağrıları yer alır. Kullanıcı bekliyorsa daha ucuz bir yanıtın değeri gecikme nedeniyle silinebilir.

Öneri: bu şeridi model seçimi, anında düzeltme, hız sınırı yönetimi, uygun olduğu yerde önbelleğe alma ve dikkatli yeniden denemelerle optimize edin. Ürün bunu açıkça bir arka plan görevi olarak sunmadıkça, bunu 24 saatlik toplu sıraya göndermeyin.

2. Şerit: dakikalarca bekleyebilen yakın hat istekleri

Bu işlerin sayfa yüklemesini engellemesi gerekmez ancak yine de aynı oturum veya aynı saat beklentisi olabilir. Örnekler arasında yükleme sonrası belge analizi, form gönderildikten sonra CRM zenginleştirmesi veya hazır olduğunda kullanıcıyı bilgilendirebilecek bir rapor yer alır.

Öneri: Nearline çalışmayı açık durum durumlarına sahip bir kuyruğun arkasına yerleştirin. Sağlayıcı desteğine ve son teslim tarihine bağlı olarak, bunu küçük gruplar halinde veya daha düşük önceliğe sahip senkronize çalışanlar aracılığıyla çalıştırın. Bu şerit iş kimliklerinden, web kancalarından ve kullanıcıların görebildiği ilerlemeden yararlanır.

3. Şerit: 24 saate kadar bekleyebilen çevrimdışı toplu istekler

Bu, maliyet optimizasyonunun ana yoludur. İyi adaylar arasında şunlar yer alır:

• büyük ölçekli değerlendirmeler;
• veri kümesi etiketlemesi;
• katalog veya CRM zenginleştirmesi;
• gecelik özeti;
• uyumluluk inceleme kuyrukları;
• dolguları yerleştirme;
• denetleme taramaları;
• periyodik rapor oluşturma;
• dizine eklemeden veya yayınlamadan önce içeriğin ön işlenmesi.

Gerçek: büyük sağlayıcılar artık uygun iş yükleri için eşzamansız toplu API'ler sunuyor. OpenAI'nin Batch API'si, yüklenen bir dosyadaki istekleri okur, sonuçları bir çıktı dosyasına yazar ve 24 saat içinde işlemeyi hedefler. OpenAI, desteklenen Batch API kullanımının senkronize API'lere kıyasla %50 maliyet indirimiyle sunulduğunu belirtiyor. Anthropic'in Mesaj Grupları API'si, büyük hacimli Mesaj istekleri, eşzamansız işleme, daha yüksek verim ve %50 daha düşük maliyet için tasarlanmıştır. Google'ın Gemini Batch API'si, 24 saatlik hedef geri dönüş süresiyle standart maliyetin %50'si karşılığında büyük hacimli eşzamansız istekler için tasarlanmıştır.

Ödünleşme: "24 saate kadar", dolgular ve değerlendirmeler için mükemmeldir ancak etkileşimli iş akışları için kabul edilemez. Toplu iş, eşzamanlı çıkarımın evrensel bir alternatifi değil, bir planlama stratejisidir.

Toplu iş yolunu bir iş yaşam döngüsü olarak tasarlayın

Kaçınılması gereken uygulama hatası, toplu işlemi tek bir API çağrısı olarak ele almaktır. Bu bir yaşam döngüsüdür: Çalışmayı kabul edin, doğrulayın, ısrar edin, gönderin, anket yapın, uzlaştırın ve sonuçları ortaya çıkarın.

Referans mimarisi

1. Normalleştirilmiş bir isteği kabul edin: Mümkün olduğunca istek şeklini mevcut OpenAI uyumlu API biçiminize yakın tutun. Proje, ekip, müşteri, geçicilik anahtarı, talep edilen son tarih ve maliyet merkezi gibi meta verileri ekleyin.
2. İş yükünü sınıflandırın: isteği gerçek zamanlı, yakın hatta veya çevrimdışı toplu işlere atayın. Bu, politikaya dayalı olmalı, uygulama kodunun içine gizlenmemelidir.
3. İş kimliği oluşturun: Nearline ve offline işler için hemen bir iş tanımlayıcı döndürün.
4. Uyumluluğu doğrulayın: seçilen sağlayıcının ve modelin istenen uç nokta, yöntem, dosya boyutu, araçlar, yanıt biçimi ve diğer özellikler için toplu işi destekleyip desteklemediğini kontrol edin.
5. Kalıcı istek satırları: normalleştirilmiş JSONL satırlarını veya sağlayıcıya özel yükleri depolayın. Mutabakat için sabit bir satır kimliği ekleyin.
6. Grubu gönderin: sağlayıcı sınırlarına ve iş boyutuna bağlı olarak istek dosyasını veya satır içi toplu veriyi yükleyin.
7. Anket durumu: Doğrulanıyor, devam ediyor, tamamlandı, başarısız oldu, süresi doldu, iptal ediliyor ve uygun olduğu durumlarda iptal edildi gibi sağlayıcı durumlarını izleyin.
8. Çıktı satırlarını depolayın: Başarılı yanıtları, satır düzeyindeki hataları, belirteç kullanımını, varsa önbelleğe alınmış belirteç sayılarını ve sağlayıcı tanımlayıcılarını yazın.
9. Tüketicileri bilgilendirin: bir alma uç noktası, web kancası, kontrol paneli bildirimi veya Telegram uyarısı ortaya çıkarın.
10. Faturalandırmada mutabakat sağlayın: Maliyeti orijinal projeye, ekibe, müşteriye, API anahtarına ve iş kimliğine ilişkilendirin.

Bu model uygulamayı basit tutar. Ürün ekipleri işi gönderir ve iş durumlarını alır. Ağ geçidi veya düzenleme katmanı, sağlayıcı farklılıklarını, toplu dosyaları, yeniden denemeleri ve hesaplamayı yönetir.

Açık iş durumlarını kullanın

Her sağlayıcı farklı adlar kullansa bile dahili durumları tanımlayın:

• sıraya alındı: kabul edildi ancak gönderilmedi;
• doğrulanıyor: sağlayıcı veya ağ geçidi dosyayı kontrol ediyor;
• çalışıyor: gönderildi ve işleniyor;
• tamamlandı: mevcut tüm sonuçlar toplandı;
• completed_with_errors: bazı satırlar doğrulama veya yürütmede başarısız oldu;
• süresi doldu: tüm satırlar tamamlanmadan son tarih geçti;
• iptal edildi: kullanıcı, sistem veya politika tarafından durduruldu;
• başarısız oldu: müdahale gerektiren iş düzeyindeki başarısızlık.

Gerçek: OpenAI, doğrulanıyor, başarısız oldu, devam ediyor, tamamlandı, süresi doldu, iptal ediliyor ve iptal edildi gibi toplu durumları belgeliyor. Ayrıca, bir partinin süresi dolarsa zaten tamamlanmış işin iade edilip ücretlendirileceğini, kalan işin ise iptal edileceğini belirtir.

Öneri: Toplu işlerin ya hep ya hiç olduğunu asla varsaymayın. En baştan satır düzeyinde durum işlemeyi oluşturun.

Arızalar ve genel giderlerden sonra tasarrufları hesaplayın

Basit bir tasarruf modeli çoğu ekip için yeterlidir:

temel_maliyet = senkronize_giriş_maliyeti + senkronize_çıkış_maliyeti
Batch_cost = indirimli_batch_giriş_maliyeti + indirimli_batch_çıkış_maliyeti
düzeltilmiş_batch_cost = toplu_maliyet + orkestrasyon_maliyeti + depolama_maliyeti + yeniden çalıştırma_maliyeti
tahmini_tasarruflar = baseline_cost - düzeltilmiş_batch_cost

Daha sonra bunu genel olarak değil, iş yükü başına hesaplayın. Gecelik bir değerlendirme paketi önemli ölçüde tasarruf sağlayabilir. Çok sayıda hatalı biçimlendirilmiş satırın, acil geri dönüşlerin veya tekrarlanan yeniden çalıştırmaların olduğu yakın hattaki bir iş akışı, beklenenden daha az tasarruf sağlayabilir.

En azından şu metrikleri izleyin:

• senkronizasyon ve toplu jeton harcaması;
• modele göre giriş ve çıkış jetonları;
• toplu iş sayısı ve iş başına ortalama satır;
• satır düzeyinde başarısızlık oranı;
• süresi dolmuş iş oranı;
• yeniden çalıştırma maliyeti;
• senkronizasyona geri dönüş maliyeti;
• ekip, proje, anahtar, müşteri ve iş ortağı hesabına göre maliyet.

Öneri: Otomatik eşzamanlı geri dönüşü varsayılan olarak değil, istisna olarak değerlendirin. Son teslim tarihlerini korur ancak aşırı kullanılırsa beklenen tasarrufları ortadan kaldırabilir. "Yalnızca işin son teslim tarihinin iki saat içinde olması ve işin başlamaması durumunda geri dönüş" gibi bir politika ekleyin.

Tekrarlanan uzun önekler için bilgi istemini önbelleğe alma ekleyin

Toplu işleme, uygun işin birim fiyatını azaltır. İstemi önbelleğe alma, sağlayıcı davranışı desteklediğinde tekrarlanan uzun istemlerin etkili maliyetini ve gecikmesini azaltır.

Gerçek: OpenAI istem önbelleğe alma, desteklenen modellerde 1.024 jetondan daha uzun istemlere otomatik olarak uygulanır, önceden hesaplanan en uzun öneki önbelleğe alır ve API kullanım ayrıntılarında cached_tokens raporunu verir. OpenAI, bilgi istemi önbelleklerinin genellikle 5 ila 10 dakika işlem yapılmadığında temizlendiğini, son kullanımdan sonraki bir saat içinde kaldırıldığını ve bilgi istemi önbelleklerinin kuruluşlar arasında paylaşılmadığını söylüyor.

Uygulama modeli basittir: Sabit içeriği ilk sıraya, geçici içeriği ise son sıraya koyun.

Önbelleğe alma için daha iyi bilgi istemi yapısı

Sistem talimatları
Kararlı politika metni
Kararlı çıktı şeması
Kararlı örnekler
Yeniden kullanılabilir referans bağlamı
---
Dinamik kayda özgü giriş
Dinamik kullanıcı veya satır meta verileri

Örneğin, bir katalog zenginleştirme işi 50.000 üründe aynı sınıflandırmayı, çıktı şemasını, marka kurallarını ve örnekleri yeniden kullanabilir. Her satır yalnızca ürün başlığını, açıklamasını ve özelliklerini değiştirir. Yeniden kullanılabilir öneki ilk önce yerleştirmek, sağlayıcıya, desteklendiği yerlerde önbelleğe alınmış hesaplamayı yeniden kullanma şansını artırır.

Ödünleşme: Önbelleğe alma, kalıcı depolama değildir ve garantili olarak değerlendirilmemelidir. Önbellek pencereleri, izolasyon, minimum bilgi istemi uzunluğu ve raporlama sağlayıcıya göre farklılık gösterir. Tasarruf varsaymak yerine önbelleğe alınan jetonları ölçün.

Göndermeden önce sağlayıcı desteğini doğrulayın

Toplu API'ler farklıdır. Ağ geçidi, bir işi göndermeden önce uygunluğu doğrulamalıdır.

Gerçekler: OpenAI Batch API, akışı desteklemez ve ayrı toplu iş hızı sınırlarına sahiptir. 100.000 istek veya 256 MB toplu iş boyutu sınırı, 24 saatlik süre sonu, 29 günlük sonuç kullanılabilirliği, oran sınırları ve toplu işlerin yapılandırılmış çalışma alanı harcama sınırlarını biraz aşabilme olasılığını içeren Antropik belgeler toplu sınırlamaları. Google, 20 MB'ın altındaki küçük işler için satır içi toplu istekleri ve daha büyük toplu istekler için JSONL giriş dosyalarını destekler.

Uyumluluk kontrol listesi kullanın:

• İstenen model, söz konusu sağlayıcının toplu API'si aracılığıyla mevcut mu?
• Uç nokta destekleniyor mu?
• İstek akış gerektiriyor mu? Cevabınız evet ise grubu reddedin.
• Hemen gerçekleşmesi gereken araçları veya yan etkileri kullanıyor mu?
• Toplu iş dosyası sağlayıcı sınırlarını aşıyor mu?
• Beklenen sonuç, sağlayıcının tamamlanma süresi içinde hâlâ faydalı mı?
• Çıktılar, aşağı yöndeki sistemlerin bunları almasına yetecek kadar uzun süre mevcut mu?
• İş yükü kısmi tamamlanmayı tolere edebilir mi?

Öneri: Doğrulamanın açık bir nedenden ötürü erken başarısız olması. Reddedilen bir parti adayı, daha sonra yeniden işlenmesi gereken süresi dolmuş veya hatalı biçimlendirilmiş bir işten daha ucuzdur.

Ekipler, ajanslar ve iş ortakları için güvenlik önlemleri

Toplu sistemler büyük dosyaları arka planda işledikleri için sessizce çok fazla para harcayabilirler. Geniş kullanıma sunmadan önce kontroller ekleyin:

• Ekip başına toplu bütçeler: ayrı çevrimiçi ve çevrimdışı harcama sınırları.
• Maksimum dosya boyutu ve satır sayısı: sağlayıcı sınırlarını ve kendi operasyonel sınırlarınızı uygulayın.
• Ölü mektup kuyruğu: doğrulama hataları içeren geçersiz satırları incelenmek üzere korur.
• Idempotency anahtarları: mükerrer ödemelerin yanlışlıkla yeniden gönderilmesini önler.
• PII incelemesi: toplu dosyalar yeni veri saklama ve gizlilik yükümlülükleri oluşturabilir.
• Saklama politikası: istek dosyalarının, çıktı dosyalarının ve günlüklerin ne kadar süreyle saklanacağını tanımlayın.
• Bildirim politikası: işler başarısız olduğunda, süresi dolduğunda veya bütçeyi aştığında sahipleri uyarır.
• İlişkilendirme: projeyi, ekibi, müşteriyi, API anahtarını, modeli, sağlayıcıyı, iş kimliğini ve satır kimliğini kaydedin.

Ajanslar ve bayiler için ilişkilendirme özellikle önemlidir. Bir iş ortağı birçok müşteri için zenginleştirme veya değerlendirme işleri yürütüyorsa sistem, yalnızca sağlayıcı faturası başına değil, müşteri başına ve iş başına maliyeti de rapor etmelidir.

Bu, bir AI API ağ geçidiyle nasıl eşleşir?

AI API ağ geçidi, zaten uygulamalar ve model sağlayıcılar arasında yer aldığından bunun uygulanması için doğal bir yerdir. Ağ geçidi, geliştiriciler için OpenAI uyumlu bir API yüzeyini korurken arkasına maliyet odaklı planlama ekleyebilir.

Yararlı ağ geçidi özellikleri şunları içerir:

• Birleşik faturalandırma: Eşzamanlı, toplu, önbelleğe alınmış ve yedek harcamaları tek bir yerde karşılaştırın.
• Yapay zeka kullanım analizi: kullanımı modele, sağlayıcıya, uç noktaya, ekibe, projeye ve API anahtarına göre ayırın.
• Ekip kontrolleri: Etkileşimli ve çevrimdışı iş yükleri için ayrı bütçeler belirleyin.
• API anahtarı ilişkilendirmesi: her işi hangi hizmetin veya müşterinin oluşturduğunu tanımlayın.
• Durum bildirimleri: Toplu işler tamamlandığında, başarısız olduğunda, süresi dolduğunda veya son teslim tarihi yaklaştığında uyarı gönderin.
• İş ortağı API iş akışları: ajansların veya satıcıların müşteri düzeyinde muhasebeyi korurken müşteriler adına iş oluşturmasına ve sonuçları almasına olanak tanır.

Tahmin: Daha fazla ekip LLM maliyetlerini yalnızca model değiştirmelerle değil, planlama politikalarıyla yönetecek. Toplu destek sağlayıcılar arasında olgunlaştıkça kazanan mimari, model fiyatına göre yönlendirmeden önce aciliyete, özellik uyumluluğuna ve muhasebe gereksinimlerine göre yönlendirme yapacak.

Uygulama kontrol listesi

• 30 günlük LLM API kullanımını dışa aktarın.
• Her iş yükünü gerçek zamanlı, yakın hatta veya çevrimdışı olarak sınıflandırın.
• Açık bir sahiplik ve bağışlayıcı bir son teslim tarihi olan bir çevrimdışı iş yükü seçin.
• Gerekli uç nokta ve model için sağlayıcı toplu desteğini doğrulayın.
• Dahili iş durumlarını ve satır düzeyindeki durumları tanımlayın.
• İdempotency anahtarları, iş kimlikleri ve satır başına kimlikler ekleyin.
• Normalleştirilmiş istek ve yanıt kayıtlarını saklama kontrolleriyle saklayın.
• Bir özellik işaretinin ardından ilk grubu gönderin.
• Eşzamanlı temel maliyeti, düzeltilmiş toplu maliyetle karşılaştırarak ölçün.
• Kararlı önekleri ilk sıraya koymak için tekrarlanan uzun istemleri yeniden yapılandırın.
• Önbelleğe alınmış jetonları, başarısız satırları, süresi dolmuş işleri ve yedek harcamaları izleyin.
• Yalnızca tasarruflar ve operasyonel davranış analizlerde göründükten sonra genişletin.

Harekete geçirilebilir sonuç

Her ekipten daha ucuz bir model kullanmasını isteyerek AI API maliyet kontrolüne başlamayın. Acil işleri bekleyebilecek işlerden ayırarak başlayın. Etkileşimli istekleri eşzamanlı tutun. Sağlayıcı desteği ve iş teslim tarihleri ​​uygun olduğunda değerlendirmeleri, zenginleştirmeyi, etiketlemeyi, dolguları, denetleme taramalarını ve raporları toplu olarak taşıyın. Yapı, önbelleğe alma için uzun istemleri tekrarladı. Ardından arızalar, yeniden çalıştırmalar, depolama ve yedek maliyetlerden sonraki gerçek tasarrufları ölçün.

En iyi uygulama bilerek sıkıcıdır: iş kimlikleri, doğrulama, satır düzeyinde durumlar, bütçeler, kullanım analizleri ve net sahiplik. Bu operasyonel katman, sağlayıcı indirimlerini güvenilir tasarruflara dönüştüren şeydir.

İlgili okumalar

• API anahtar ilişkilendirmesi ve ekip harcama kontrolleri
• LLM API'leri için yönlendirme, yeniden denemeler ve geri dönüş politikaları
• ilgili Model Gate uygulama notları