Şirket İçi Yapay Zeka API'leri İçin Hız Sınırlama ve Geri Basınç Mekanizmaları

Yapay Zeka API'leri Neden Farklı Koruma Stratejilerine İhtiyaç Duyar

Geleneksel API hız sınırlama, web hizmetleri için iyi anlaşılmıştır: saniyede istek sınırı belirleyin, aşıldığında HTTP 429 döndürün ve istemcilerin yeniden denemesine izin verin. Ancak şirket içi yapay zeka çıkarım API'leri, standart hız sınırlamayı yetersiz ve bazen ters etki yapan özelliklere sahiptir.

Yapay zeka çıkarım istekleri maliyet açısından homojen değildir. 50 token üreten bir istek, 4.000 token'lık bir oluşturma gerektiren isteğin GPU süresinin ve belleğinin çok küçük bir kısmını tüketir. Yalnızca istek sayısına göre hız sınırlama, az sayıda pahalı isteğin GPU'nuzu tüketmesine izin verirken hız sınırlayıcı kapasite olduğunu raporlar. Tersine, ucuz sınıflandırma isteklerinin bir patlaması, GPU düşük kullanımdayken hız sınırlarını tetikleyebilir.

GPU kaynakları da CPU tabanlı hizmetlerden farklı şekilde başarısız olur. Bir web sunucusu aşırı yüklendiğinde, yanıt süreleri kademeli olarak artar. Bir GPU çıkarım sırasında bellek tükendiğinde, süreç çöker veya istek tamamen bellek yetersizliği hatasıyla başarısız olur. Kademeli bir bozulma eğrisi yoktur; bunun yerine bir uçurum vardır. Bu, geri basınç ve yük boşaltma yoluyla proaktif korumayı isteğe bağlı değil, zorunlu kılar.

Token Bilinçli Hız Sınırlama

Yapay zeka API'leri için en etkili hız sınırlama stratejisi, istek sayıları yerine token bütçeleri kullanır. Her tüketici (ekip, uygulama veya API anahtarı), hem giriş hem de çıkış token'larını kapsayan, dakikada veya saatte token olarak tanımlanan bir tahsisat alır.

Token bilinçli hız sınırlama uygulamak, bir isteğin maliyetini yürütülmeden önce tahmin etmeyi gerektirir. Giriş token'ları için bu basittir: giriş istemini token'lara ayırın ve sayın. Çıkış token'ları için istekteki max_tokens parametresini rezervasyon olarak kullanmanız gerekir. Yanıt tamamlandığında, rezervasyonu gerçek kullanıma göre uzlaştırın ve kullanılmayan token'ları bütçeye iade edin.

Pratik bir uygulama, tüketici başına kayan pencere token sayacı kullanır. Bir istek geldiğinde, tüketicinin kalan token bütçesinin tahmini maliyeti karşılayıp karşılayamayacağını kontrol edin. Evet ise, tahmini token'ları düşün ve isteği işleyin. Hayır ise, sıfırlama süresini ve kalan bütçeyi içeren bir hız sınırı hatası döndürün.

Token bütçelerini GPU kapasitenize göre belirleyin. Çıkarım kümeniz tüm tüketiciler genelinde dakikada 50.000 token'ı sürdürebiliyorsa, kapasitenin %70-80'ine kadar toplam bütçe tahsis ederek pay bırakın.

Geri Basınç Mekanizmalarını Uygulama

Geri basınç, sistem kapasiteye yaklaştığında yukarı akış çağrıcılarına yavaşlamalarını bildirme pratiğidir. Sabit sınırlar uygulayan hız sınırlamadan farklı olarak, geri basınç, çağrıcıların sınırlara ulaşmadan önce davranışlarını ayarlamalarına olanak tanıyan kademeli sinyaller sağlar.

En basit geri basınç mekanizması kuyruk derinliği izlemedir. Çoğu çıkarım sunucusu (vLLM, TGI, Triton) dahili bir istek kuyruğu sürdürür. Mevcut kuyruk derinliğini bir metrik olarak açığa çıkarın ve API yanıt başlıklarına dahil edin. Artan kuyruk derinliği gözlemleyen istemciler, hız sınırı hatalarını beklemeden proaktif olarak istek oranlarını azaltabilir.

Daha sofistike bir yaklaşım uyarlanabilir eşzamanlılık sınırları kullanır. Sabit bir hız sınırı yerine, gözlemlenen gecikmeye göre izin verilen eşzamanlı istek sayısını dinamik olarak ayarlayın. TCP Vegas algoritması iyi bir model sağlar: gecikme arttığında eşzamanlılık sınırını azaltın; gecikme stabil olduğunda kademeli olarak artırın.

Çoklu model dağıtımları için model başına geri basınç uygulayın. Tek bir aşırı yüklenmiş model, aynı API ağ geçidini paylaşan ilgisiz modellerde geri basınca neden olmamalıdır. Model uç noktası başına kuyruk derinliğini ve gecikmeyi takip edin ve geri basınç sinyallerini bağımsız olarak uygulayın.

GPU Koruması İçin Yük Boşaltma

Yük boşaltma, geri basıncın tek başına yetersiz kaldığında sistem kararlılığını korumak için isteklerin kasıtlı olarak reddedilmesidir. GPU bağımlı yapay zeka iş yükleri için yük boşaltma, bellek yetersizliği çökmelerine ve ardışık arızalara karşı son savunma hattınızdır.

Yapay zeka istekleriniz için katmanlı öncelik sistemi tasarlayın. Tüm istekler eşit iş değeri taşımaz. Müşteriye yönelik bir sohbet robotu sorgusu, tipik olarak dahili bir toplu analiz işinden daha yüksek önceliğe sahiptir. API anahtarı veya tüketici düzeyinde öncelik seviyeleri atayın ve GPU belleği veya hesaplama kullanımı bir eşiği (tipik olarak %85-90) aştığında, önce daha düşük öncelikli istekleri boşaltmaya başlayın.

GPU bellek bilinçli kabul kontrolü uygulayın. Yeni bir çıkarım isteğini kabul etmeden önce mevcut GPU bellek kullanımını kontrol edin. Yeni istek için tahmini bellek gereksinimi kullanımı güvenlik eşiğinizin üzerine çıkaracaksa, tüm uçuştaki istekleri etkileyebilecek bir bellek yetersizliği hatasını riske atmak yerine isteği hemen reddedin.

Yük boşaltırken eyleme geçirilebilir hata yanıtları sağlayın. Nedeni (bellek baskısı, hesaplama doygunluğu veya kuyruk taşması), kapasitenin mevcut olacağı tahmini süreyi ve isteğin yeniden denenmesi mi yoksa yönlendirilmesi mi gerektiğini dahil edin.

İstek Maliyetlendirme ve Adil Zamanlama

Adil zamanlama, hiçbir tüketicinin GPU kaynaklarını diğerleri pahasına tekelleştiremememesini sağlar. Bu, birden fazla ekibin aynı çıkarım altyapısını paylaştığı çok kiracılı şirket içi dağıtımlarda özellikle önemlidir.

Çıkarım ağ geçidinde ağırlıklı adil kuyruk uygulayın. Her tüketicinin istekleri ayrı bir kuyruğa girer ve zamanlayıcı, her tüketicinin ağırlığı ve son kullanımına göre işlenecek bir sonraki isteği seçer. Adil paylarından daha azını kullanan tüketiciler öncelik kazanır; paylarını aşanlar öncelikleri düşürülür ancak engellenmez.

Adillik hesaplamasında isteklerin gerçek maliyetini hesaba katın. 10.000 çıkış token'ı gerektiren bir istek gönderen tüketici, her biri 100 token'lık 100 istek gönderen tüketiciyle aynı şekilde ele alınmamalıdır. Uzun süren istekler, tüm oluşturma süresi boyunca GPU belleğini bağlar.

API tüketicilerinize kullanımlarını tahmin edip optimize edebilmeleri için bir maliyet modeli yayınlayın. Maliyet modeli, giriş uzunluğu, çıkış uzunluğu ve model boyutunun bir fonksiyonu olarak istek başına tüketilen GPU-saniyelerini ifade etmelidir. Ekipler isteklerinin gerçek kaynak maliyetini anladığında, doğal olarak optimize ederler.

Koruma Katmanınızı İzleme ve Ayarlama

Hız sınırlama ve geri basınç yapılandırmaları bir kez ayarla ve unut değildir. İş yükü kalıplarınız geliştikçe sürekli izleme ve ayarlama gerektirir. Temel koruma metriklerini izleyen panolar oluşturun: tüketici başına hız sınırı isabet oranları, kuyruk derinliği eğilimleri, yük boşaltma sıklığı ve tahsis edilen ile gerçek token kullanımı arasındaki fark.

Belirli bir tüketici için yüksek hız sınırı isabet oranı, tahsisatlarının meşru kullanım için çok düşük olduğunu gösterebilir veya aşırı istek üreten kontrolsüz bir süreci gösterebilir. Sınırları ayarlamadan önce araştırın.

Yük boşaltma olaylarını kapasite planlama sinyalleri olarak izleyin. Sisteminiz öngörülebilir yoğun saatlerde yük boşaltıyorsa, ek GPU kapasitesine veya daha iyi trafik şekillendirmeye ihtiyacınız olabilir.

Koruma mekanizmalarınızı kontrollü koşullarda test edin. Hız sınırlarınızı kasıtlı olarak aşan ve geri basıncı tetikleyen yük testleri çalıştırarak sistemin tasarlandığı gibi davrandığını doğrulayın. Yük boşaltmanın doğru eşiklerde etkinleştiğini ve düşük öncelikli trafik boşaltıldığında yüksek öncelikli isteklerin sunulmaya devam ettiğini onaylayın.

Öne çıkan görsel: Daniel Julio tarafından Unsplash'ta paylaşılmıştır.