Çok Modelli LLM API'leri için Sağlayıcıdan Tarafsız Oran Limiti Aracısı Nasıl Oluşturulur

Birkaç ekip birden fazla Yüksek Lisans sağlayıcısını paylaştığında, hız sınırlama, sağlayıcı-entegrasyon ayrıntısı olmaktan çıkar. Bu bir ortak kapasite sorunu haline gelir. Bir sağlayıcı istekleri ve giriş jetonlarını sınırlayabilir, bir diğeri giriş ve çıkış jetonlarını ayırabilir ve üçüncüsü proje düzeyinde veya değişen harcama penceresi boyunca kotalar uygulayabilir. Her SDK içindeki yeniden deneme döngüsü, kiracılar, uygulamalar, iş ortağı anahtarları ve model rotaları genelindeki bu kısıtlamaları koordine edemez.

Pratik çözüm, ağ geçidinde merkezi bir oran sınırı komisyoncusu kullanmaktır. Aracı, talebi tahmin eder, sevkıyat öncesinde kapasiteyi ayırır, politikaya göre işi kuyruğa alır veya reddeder ve rezervasyon tamamlandıktan sonra fiili kullanımla mutabakat sağlar. Sağlayıcı yanıtları daha sonra bağımsız yeniden deneme fırtınalarını tetiklemek yerine aracının kullanılabilir kapasiteye ilişkin görünümünü hassaslaştırır.

Bu mimari, dahili ekipler, üretim uygulamaları, otomasyon aracıları veya harici iş ortakları arasında öngörülebilir aktarım hızına ihtiyaç duyan tüm kurumsal LLM API için kullanışlıdır.

Sağlayıcı hız sınırları neden dakika başına istek sayısına düşürülemiyor?

Gerçek: Sağlayıcı kotaları farklı boyutlar ve kapsamlar kullanır. Ortak boyutlar arasında dakika başına istek, dakika başına giriş belirteçleri, dakika başına çıkış belirteçleri, toplam belirteçler, günlük istekler, eşzamanlılık, harcama aralıkları ve hızlanma veya artış oranı sınırları yer alır. Aynı sağlayıcı bir kuruluş, proje, çalışma alanı, model veya API ürün için farklı sınırlar uygulayabilir.

Örneğin, sağlayıcı belgelerinde aşağıdaki gibi kombinasyonlar açıklanmaktadır:

• Yanıt başlıklarında kalan kapasite ve sıfırlama bilgileri ile birlikte istek ve belirteç sınırları.
• Mesaj API'leri için ayrı giriş jetonu ve çıkış jetonu sınırları.
• Tek tek API anahtarlara eklenen kotalar yerine proje düzeyinde kotalar.
• Sağlayıcı tarafından tanımlanan bir zamanda sıfırlanan günlük istek sınırları.
• İstek ve jeton oranları kabul edilebilir görünse bile trafiği reddedebilen, harcamaya dayalı geçişli pencereler.
• Kararlı durum kullanımı yayınlanan kotanın altında olsa bile trafikte keskin bir artışa tepki veren hızlanma sınırları.

sağlayıcı RPM adı verilen yalnızca tek bir sayıyı depolayan bir ağ geçidi, sonuçta trafiği bir boyutta aşırı kabul edecek veya diğerinde kapasiteyi yetersiz kullanacaktır. Ayrıca reddin kiracı politikasından mı, sağlayıcı proje kotasından mı, günlük sınırdan mı yoksa aşırı yük yanıtından mı kaynaklandığını açıklayamaz.

Oran limiti komisyoncusu için referans mimarisi

Aracıyı istek yoluna, sağlayıcı bağdaştırıcısından önce yerleştirin. Her istek, bir SDK, bir dahili hizmet, bir otomasyon aracısı veya bir iş ortağı API anahtarı aracılığıyla gelmesine bakılmaksızın aynı rezervasyon akışından geçmelidir.

1. Kimliği normalleştirin. Kuruluşu, kiracıyı, ekibi, uygulamayı, ortamı, iş ortağını, API anahtarını, model rotasını ve iş yükü sınıfını çözümleyin.
2. Talebi tahmin edin. Beklenen giriş jetonlarını, maksimum çıktı jetonlarını, tahmini harcamayı ve tüm eşzamanlılık maliyetlerini hesaplayın.
3. Politikayı değerlendirin. Kiracı bütçelerini, sıra son tarihlerini, rota uygunluğunu, önceliğini ve geri dönüş kurallarını kontrol edin.
4. Kapasite ayırın. İlgili dahili ve sağlayıcıya yönelik paketlerde kapasiteyi atomik olarak ayırın.
5. Gönder. İsteği yalnızca rezervasyon başarılı olduktan sonra gönderin.
6. Uzlaştırma. Tahminleri gerçek kullanımla değiştirin, kullanılmayan rezervasyonları serbest bırakın ve sağlayıcı başlıklarını ve yanıt sınıflandırmasını kaydedin.
7. Sonraki eyleme karar verin. Sonucu döndürün, işi sıraya koyun, merkezi olarak yeniden deneyin, geri çekilin veya iş yükü sözleşmesine göre reddedin.

Rezervasyon hizmeti yatay olarak ölçeklenebilir olmalıdır ancak kararı her istek için atomik olmalıdır. İki çalışanın aynı kalan kapasiteyi gözlemlemesine olanak tanıyan dağıtılmış bir sayaç, ağ geçidi içindeki sağlayıcı 429 sorununu yeniden oluşturabilir.

Sağlayıcı farklılıklarını gizlemeden standart bir kota modeli kullanın

Her sağlayıcıyı tek bir soyutlamaya zorlamak yerine, sağlayıcıya özgü kısıtlamaları temsil edebilecek kanonik bir model tanımlayın.

Her sınırı kapsam, kapasite, yeniden doldurma veya sıfırlama kuralı, birim ve kaynak içeren bir paket olarak temsil edin. Bir sağlayıcı proje paketi istekler ve giriş belirteçleri içerebilir. Bir çalışma alanı grubu çıktı belirteçleri içerebilir. Dahili bir iş ortağı politikası eşzamanlılık ve harcama limitleri ekleyebilir. Kabul kararı yalnızca gerekli tüm rezervasyonların başarılı olması durumunda başarılı olur.

Sağlayıcı başlıklarını tam bir gerçek kaynağı olarak görmeyin. Aracının tahminlerini düzeltmek için bunları kullanın, ancak her yanıtta gösterilmeyen sınırlar için yapılandırılmış bir modeli koruyun. Başlık adları, kullanılabilirlik ve sıfırlama semantiği sağlayıcıya ve rotaya göre değişir.

Göndermeden önce jetonları ayırın, ardından mutabakatını yapın

Jeton rezervasyonu, aracı ile yeniden deneme sarmalayıcı arasındaki en önemli farktır. Aracının, isteği göndermeden önce bir talep tahminine ihtiyacı var.

Giriş belirteçleri için serileştirilmiş iletilerden, araç tanımlarından, yapılandırılmış çıktı şemasından ve alınan herhangi bir bağlamdan tahmin yapın. Çıkış belirteçleri için, mümkün olduğunda istek maksimumunu veya müşteri sağlamadığında modele ve iş yüküne özgü bir tahmin kullanın. Tahmini rezervasyona eklenmiş olarak saklayın, böylece daha sonra gerçek kullanımla karşılaştırılabilir.

Basit bir rezervasyon kaydı şunları içerebilir:

• Benzersiz bir istek ve rezervasyon kimliği.
• Kiracı, uygulama, API anahtarı, rota ve iş yükü sınıfı.
• Tahmini giriş jetonları, çıkış jetonları, toplam jetonlar ve harcama.
• Rezervasyona göre her paket ücretlendirilir.
• Oluşturma zamanı, sona erme süresi, sıranın son tarihi ve geçicilik anahtarı.
• Nihai fiili kullanım ve mutabakat sırasında serbest bırakılan veya tahsil edilen tutar.

İhtiyatlı tahminler, sağlayıcı 429 yanıtlarını azaltır ancak kapasiteyi zora sokabilir. Tahmin hatasını modele, rotaya, bilgi istemi ailesine, bağlam uzunluğuna ve yapılandırılmış çıktı moduna göre ölçün. Daha sonra tek bir sıra dışı isteğin tüm modeli bozmasına izin vermek yerine, sınırlı düzeltmeleri kullanarak tahminleri ayarlayın.

Yayın akışı belirli bir politika gerektirir. Maksimum çıktı tahsisini ayırabilir ve akış sona erdiğinde kullanılmayan kısmı serbest bırakabilir veya jetonlar geldikçe çıktı kapasitesini daha küçük artışlarla ayırabilirsiniz. İlk yaklaşımın akıl yürütmesi daha kolaydır; ikincisi kullanımı iyileştirebilir ancak güvenilir iptal, zaman aşımı ve bağlantı kesme işlemlerini gerektirir.

Kotaları hiyerarşik olarak uygulayın

Kapasite, en dar politikadan en geniş paylaşılan kaynağa kadar kontrol edilmelidir. Tipik bir hiyerarşi şöyledir:

1. API anahtar veya hizmet kimliği.
2. Uygulama ve ortam.
3. Ekip veya müşteri kiracısı.
4. İş ortağı veya bayi hesabı.
5. Sağlayıcı çalışma alanı veya alt hesabı.
6. Sağlayıcı projesi veya kuruluşu.
7. Model ve rota.

Bu nedenle, bir iş ortağı uygulamasından gelen bir isteğin dört başarılı rezervasyona ihtiyacı olabilir: iş ortağının eşzamanlılık politikası, müşteri kiracısının jeton bütçesi, ağ geçidinin rota tahsisi ve sağlayıcı projesinin kullanılabilir kotası. Herhangi bir rezervasyon başarısız olursa önceden alınmış olan rezervasyonları iptal edin ve başarısız olan grubun kararını uygulayın.

Adil olmak adına, hangi çalışanın ilk önce geldiği kişinin paylaşılan havuzu kullanmasına izin vermek yerine, ağırlıklı adil kuyruk veya açık döngü yöntemini kullanın. Her kiracı için ani artış kredilerini korurken, üretim trafiğine daha yüksek ağırlıklar ve arka plan işlerine daha düşük ağırlıklar atayın. Sabit bölümlemenin açıklaması daha kolaydır ancak bir kiracı sessiz kaldığında kapasiteyi boşta bırakabilir. Gürültülü kiracıların sınırlı ani artış sınırlarına sahip olması koşuluyla, ağırlıklı paylaşım genellikle kapasiteyi daha verimli kullanır.

İş yükü sözleşmelerine göre kuyruklar tasarlayın

Sıra otomatik olarak bir güvenilirlik özelliği değildir. Görünür bir 429'u on dakikalık görünmez bir gecikmeye dönüştürebilir. Her kuyruk sınıfının bir son tarihe, iptal davranışına, maksimum derinliğe ve aşırı yükleme işlemine ihtiyacı vardır.

• Etkileşimli: Kısa teslim tarihi, küçük kuyruk, öngörülebilir ret veya kapasite kullanılamadığında modelin bozulması.
• Üretim geçmişi: Daha uzun son tarih, kalıcı kuyruk, geçicilik anahtarı ve kontrollü yeniden deneme bütçesi.
• İş Ortağı: Kiracıya özel kotalar, yayınlanan yanıt meta verileri ve başka bir kiracının kuyruk durumuna erişim yok.
• Batchable: Gecikmeli yürütme, daha büyük kuyruk ve iş yükü izin verdiğinde API sağlayıcı grubuna isteğe bağlı yönlendirme.

Sıraya giriş net bir karara yol açmalıdır. API sözleşmesine bağlı olarak, yeniden deneme değeri, sıra tanımlayıcısı ve neden koduyla birlikte bir 429'u veya ağ geçidine özgü bir aşırı yük yanıtını açığa çıkarın. Sistem bu sözü yerine getiremediği sürece tamamlanma süresi sözü vermeyin.

Toplu işleme, etkileşimli olmayan çalışmayı eşzamanlı kapasiteden kaldırabilir ancak sonuç zamanlamasını, yeniden deneme davranışını, iptali ve mutabakatı değiştirir. Eşzamanlı istekleri çok uzun bir kuyruğa yerleştirmek yerine, bunu ayrı bir yürütme yolu olarak değerlendirin. Arka plan iş yükleri için operasyonel ödünleşimleri AI API maliyet kontrol politikaları ve mevcut toplu işlemlerle karşılaştırın.

Yeniden deneme ve aşırı yükleme işlemlerini merkezileştirin

Gerçek: Geçici hız sınırı yanıtlarında genellikle HTTP 429 kullanılırken, sağlayıcı aşırı yükleme koşullarında 503 veya sağlayıcıya özel bir hata kodu kullanılabilir. Bazı sağlayıcılar bir Retry-After başlığı döndürür ve sağlayıcı belgeleri, mevcut olduğunda buna uyulmasını önerir. Hızlı bir trafik artışı, olağan paket tükenmesi olmadan da hızlanma veya yavaşlama davranışı üretebilir.

Öneri: Sonra Yeniden Dene seçeneğini isteğe bağlı bir öneri olarak değil, bir alt sınır olarak değerlendirin. Etkilenen sağlayıcı kapsamını o zamana kadar duraklatın, senkronize uyanmaları önlemek için sınırlı titreşim ekleyin ve aracının hangi sıraya alınmış isteklerin kurtarılan kapasiteyi kullanabileceğine karar vermesine izin verin.

Sonra Yeniden Dene özelliği bulunmadığında veya geçersiz olduğunda, titreşimli sınırlı üstel gerilemeyi kullanın. Yeniden deneme bütçesini her SDK ve sağlayıcı bağdaştırıcısında ayrı olarak değil, aracıda tutun. Aksi takdirde, tek bir mantıksal istek, bir ağ geçidi yeniden denemesi, bir SDK yeniden denemesi, bir HTTP istemci yeniden denemesi ve sağlayıcı tarafında bir yeniden yürütme üretebilir.

Yeniden denemeden önce hataları sınıflandırın:

• Yeniden denenebilir kapasite: Geçici 429 veya belgelenmiş geçici kota yanıtı.
• Yeniden denenebilir aşırı yük: Geçici 503 veya eşdeğer sağlayıcı aşırı yük sinyali.
• Yeniden denenemeyen politika hatası: Günlük kota, harcama sınırı, devre dışı bırakılan proje veya kiracı sınırı.
• Yeniden denenemeyen istek hatası: Geçersiz şema, desteklenmeyen parametre, kimlik doğrulama hatası veya hatalı biçimlendirilmiş giriş.
• Son tarih hatası: Kalan kullanıcı veya iş akışı son tarihi, bir sonraki güvenli denemeden daha kısa olan bir istek.

Geri çekilme ayrı bir karardır. Farklı bir sağlayıcı farklı çıktı davranışına, fiyatlandırmaya, gecikmeye, ikamete veya bağlam sınırlarına sahip olabilir. Geri dönüşü yalnızca rota politikası iş yükü sözleşmesinin bu farklılıkları tolere edebileceğini doğruladığında kullanın.

Kararları ortaya çıkarın ve doygunluğu ölçün

Ağ geçidi yalnızca genel bir 429 döndürürse ekipler azaltma sorunlarını gideremez. Geçerli sınır, kalan kapasite, sıfırlama süresi, kuyruk kararı, iş yükü sınıfı ve reddetme nedeni gibi güvenli meta verileri döndürün. Başka bir kiracının kullanımını veya ham sağlayıcı kimlik bilgilerini ifşa etmekten kaçının.

En azından şunu izleyin:

• Kiracıya, rotaya ve pakete göre rezervasyon başarısı ve ret oranı.
• Sıra derinliği, kuyrukta bekleme süresi, son teslim tarihinin sona ermesi ve iptaller.
• Sağlayıcı 429 ve 503 oranları, Sonra Yeniden Deneme sıklığı ve artış hızı reddetmeleri.
• Tahmini ve gerçek jeton kullanımı ile aşırı rezervasyon nedeniyle boşa harcanan kapasite karşılaştırması.
• Eşzamanlılık doygunluğu ve her kiracının tükettiği kapasite payı.
• Mantıksal istek ve geri dönüş sıklığına göre yeniden deneme girişimleri.
• Günlük kota ve harcama aralığı boşluğu.

Yük testleri, patlama trafiğini, uzun bağlamlı istekleri, maksimum çıktı isteklerini, akış bağlantılarının kesilmesini, günlük kota tükenmesini, sağlayıcı 429 ve 503 yanıtlarını ve üretim trafiğiyle rekabet eden gürültücü bir kiracıyı içermelidir. Yalnızca isteklerin sonunda tamamlanıp tamamlanmadığını değil, aynı zamanda kuyruk son tarihlerinin, adaletin ve yeniden deneme bütçelerinin bozulmadan kalıp kalmadığını da doğrulayın.

Uygulama kontrol listesi

• Sağlayıcıya özel sınırları göz ardı etmeden standart boyutları tanımlayın.
• Her isteğe normalleştirilmiş bir kiracı, rota, iş yükü sınıfı ve geçicilik anahtarı atayın.
• Göndermeden önce girdi, çıktı, toplam jeton, harcama, istek ve eşzamanlılığı tahmin edin ve ayırın.
• Çoklu paket rezervasyonlarını atomik hale getirin ve iptal edilen rezervasyonların geçerliliğini güvenli bir şekilde sona erdirin.
• Her denemeden sonra gerçek sağlayıcı kullanımı ile yanıt başlıklarını uzlaştırın.
• Ağırlıklı adalet, seri krediler ve açık öncelik sınıfları kullanın.
• Her sıraya bir son tarih, maksimum derinlik ve aşırı yükleme işlemi verin.
• Yeniden denemeleri merkezileştirin ve sağlayıcının Yeniden Deneme Değerlerine saygı gösterin.
• Geçici kapasite hatalarını kalıcı politika ve istek hatalarından ayırın.
• Kısıtlama meta verilerini yayınlayın ve kiracıya ve rotaya göre doygunluğu izleyin.
• Sağlayıcı kota tükenmesini, artış sınırlarını, akış, geri dönüş ve gürültülü komşu davranışını test edin.

Sonuç

Çok modelli bir ağ geçidi, sağlayıcı kotasını bağımsız SDK ayarlardan oluşan bir koleksiyon olarak değil, paylaşılan altyapı kapasitesi olarak yönetmelidir. Sağlayıcıdan bağımsız bir oran limiti komisyoncusu, platform ekiplerine tek bir kabul yolu, tek bir adalet politikası, tek bir yeniden deneme bütçesi ve tahminleri gerçeklikle uzlaştırmak için tek bir yer sağlar.

Tasarım genel bir jeton paketinden fazlasını gerektiriyor. İstekleri, giriş ve çıkış jetonlarını, günlük kotaları, harcama aralıklarını, eşzamanlılığı, sağlayıcı kapsamını ve artış oranını temsil etmelidir. Bu boyutlar açık hale getirildikten sonra, ağ geçidi öngörülebilir seçimler yapabilir: şimdi gönder, son teslim tarihini belirleyerek sıraya gir, işi ayır, merkezi olarak yeniden dene veya sözleşmeye uygun bir geri dönüş kullan. Bu şekilde üretim kontrolü, üretim 429 ve 503 olaylarının yinelenen kaynağı olmaktan ziyade operasyonel bir yetenek haline gelir.

İlgili okuma

• etkileşimli olmayan LLM iş yükleri için toplu işleme