Michael Johnsonİki hizmet modele aynı sayıda istek gönderebilir, ancak tamamen farklı yükler oluşturabilir. Cohere, 9 Ekim’de yayımladığı Embed ve Rerank rehberinde paylaşımlı ya da özel işlem altyapısı seçerken istek biçimini, yükün zaman içindeki dağılımını ve gecikme gereksinimlerini dikkate almayı öneriyor. Bu, yeni bir tarife ya da ürün duyurusu değil, altyapıya ilişkin pratik bir değerlendirme.
Arama ve RAG sistemleri geliştiren ekipler için bu sonuç, dizin oluşturma ve kullanıcı sorgularını planlarken önem taşıyor: çağrı sayısı tek başına hesaplama miktarını iyi açıklamıyor. Embedding üretimi için gönderilen tek bir belge paketi, çok sayıda kısa arama sorgusundan daha fazla kaynak tüketebilir.
İstek sayısı neden yanıltıcı olabilir?
Embedding’ler metinleri, arama sisteminin anlamsal eşleştirme için kullandığı sayısal temsillere dönüştürür. Bir kataloğun ilk dizinlenmesi sırasında uygulama büyük açıklama paketleri gönderebilir; olağan arama sırasında ise model kısa bir sorgu metni alır. Bu görevlerin gereksinimleri farklıdır: paket işleme genellikle verim ve maliyet üzerinden, arama ise kullanıcıya yanıt verme süresi üzerinden değerlendirilir.
Rerank için bir başka parametre de sistemin yeniden sıralama amacıyla modele gönderdiği aday sayısıdır. Cohere’nin örneğinde kısa bir sorgu 50 belgeyle karşılaştırılıyor; şirket bu işlemin yaklaşık 11 bin token tuttuğunu tahmin ediyor. Aday sayısını artırmak, kullanıcı aramalarının sıklığı aynı kalsa bile iş miktarını artırır.
Cohere’nin hesaplamaları ne gösteriyor?
Makalede, tüketim başına ödemeden özel kapasiteye geçiş için yaklaşık ekonomik eşik değerleri veriliyor: her biri yaklaşık 200 token olan 100 metnin paket hâlinde dizinlenmesi için dakikada yaklaşık 20 istek; daha uzun belgeler için yaklaşık dört istek; belirtilen Rerank senaryosu içinse yaklaşık 29 istek. Kısa arama embedding’leri için yazarlar eşiği dakikada on binlerce istek olarak tahmin ediyor.
Bu değerler belirli varsayımlarla hesaplanmış: tek bir NVIDIA A10 GPU, günün her saati tam kapasiteyle çalışma, belirtilen istek boyutları ve yayımlanan fiyatlar. Cohere, çalışma süresi, donanım yapılandırması, indirimler ve belge hacmi değiştiğinde grafiklerin ve eşiklerin de değiştiğini ayrıca açıklıyor. Bu değerleri evrensel ölçütler değil, hesaplama yönteminin bir örneği olarak değerlendirmek daha doğru.
Ancak seçim mantığı, belirtilen örneklerden daha geniş ölçekte de geçerli. Öngörülebilir ve sürekli bir yük, rezerve edilmiş kapasiteden daha iyi yararlanabilir; uzun boşlukların arasına serpiştirilmiş kısa süreli ani artışlar ise çoğunlukla fiilî tüketime göre ödemeye daha uygundur. Etkileşimli aramada, beklenen yük altındaki gecikmeyi de test etmek gerekir: donanımın azami verimi, çalışma koşullarında gereken yanıt süresini garanti etmez.
Bu değerlendirmeyi kendi aramanıza nasıl uyarlarsınız?
Seçenekleri karşılaştırmadan önce gerçek trafikte birkaç ölçüm yapın: istek başına token ve belge sayısı, dizinleme paketlerinin boyutu, yeniden sıralanacak aday sayısı, yoğun dönemlerin süresi ve hedef gecikme. Ardından maliyeti yalnızca ortalama istek sayısına göre değil, gerçek trafik düzenine göre hesaplayın. Eksiksiz bir değerlendirme için güncel ücretleri ve barındırma koşullarını Cohere fiyatlandırma sayfasından kontrol edin: özel model ve tüketime göre işleme farklı biçimlerde ücretlendirilir.
Karma arama sistemlerinde aşamaları ayrı ayrı değerlendirmek mantıklıdır: kataloğun arka planda yeniden dizinlenmesi, kısa kullanıcı sorguları ve adayların yeniden sıralanması. Böyle bir hesaplama, tek bir altyapının uygun olup olmadığını ya da işlem hattının farklı bölümlerini farklı barındırma modelleriyle çalıştırmanın daha ekonomik olup olmayacağını sınamaya yardımcı olur. Cohere’nin yazısındaki pratik sonuç basit: önce her isteğin taşıdığı işi ölçün, ardından ödeme ve kaynak tahsisi yöntemini seçin.