LLM Uygulamalarında Hız Sınırlamasını Ustalaşmak: LLMOps için Pratik Bir Rehber

Büyük Dil Modelleri (LLM) güçlüdür, ancak aynı zamanda pahalı ve yoğun hesaplama gerektirir. Geleneksel REST API'lerinde saniyede binlerce istek ucuzca yapılabilirken, LLM API'leri genellikle sıkı verim sınırları, token sayıları ve maliyet yapılarıyla kısıtlanır. LLMOps mühendisleri için sağlam hız sınırlama stratejilerini anlamak ve uygulamak yalnızca hatalardan kaçınmakla ilgili değildir; maliyet optimizasyonu, kaynak adaleti ve uygulama kararlılığıyla ilgilidir.

LLMOps'ta Hız Sınırlamasının Neden Önemli Olduğu

OpenAI, Anthropic veya yerel GPU kümeleri gibi sağlayıcılarla entegrasyon yaparken üç ana kısıtlamayla karşılaşırsınız:

1. Maliyet Kontrolü: Kontrolsüz kullanım bütçe aşımına yol açabilir. Hız sınırlama, harcama için bir devre kesici görevi görür.
2. Sağlayıcı Kontenjanları: Çoğu sağlayıcı kademeli sınırlar uygular (ör. RPM ve TPM - Dakikadaki İstek Sayısı, Dakikadaki Token Sayısı). Bu sınırların aşıldığında HTTP 429 (Çok Fazla İstek) hataları tetiklenir. 3. Sistem Kararlılığı: Çok kiracılı (multi-tenant) ortamlarda, bir kullanıcının yoğun kullanımı diğerlerini aç bırakabilir. Adalet mekanizmaları hayati önem taşır.

Yaygın Hız Sınırlama Algoritmaları

Tüm hız sınırlayıcılar eşit yaratılmamıştır. Karşılaşacağınız en yaygın iki desen şunlardır:

1. Sabit Pencere

En basit yaklaşım. İstekleri sabit bir zaman aralığında (ör. saniye başına) sayar. Ancak, iki pencere arasındaki geçişte istek patlaması yaşanabilen "sınır etkisi" sorunundan muzdariptir.

2. Kayan Pencere Günlüğü / Sayacı

Daha doğru ve akıcıdır. İstekleri hareketli bir zaman diliminde izler. Örneğin, dakikada 100 istek uygulaması için son 60 saniyeye bakar ve sayının 100'ü aşıp aşmadığını kontrol eder. Bu, sınır sıçramasını önler ancak daha fazla bellek veya karmaşık veri yapıları gerektirir.

LLM'ler için genellikle Token Kovası (Token Bucket) tercih edilir. Kısa süreli patlamalara izin verirken uzun vadeli ortalama hızı korur; bu da kullanıcı deneyimi beklentileriyle iyi örtüşür.

429 Hatalarını Yönetme: Geri Çekilme (Backoff) Stratejisi

İstemci tarafında hız sınırlaması olsa bile, zaman zaman sağlayıcı sınırlarına takılabilirsiniz. Standart yanıt Jitter'lı Üstel Geri Çekilme (Exponential Backoff with Jitter) şeklindedir.

Temel Bileşenler:

• Üstel: Bekleme süreleri her yeniden denemede ikiye katlanır (1sn, 2sn, 4sn, 8sn).
• Jitter (Rastgelelik): Birçok istemcinin tam olarak aynı anda yeniden deneme yapmasına neden olan "gök gürültüsü sürüsü" (thundering herd) etkisini önlemek için rastgelelik eklenir.
• Maksimum Yeniden Deneme: Sonsuz döngülerden kaçınmak için her zaman bir sınır tanımlayın.

Python'da Pratik Uygulama

Aşağıda, asenkron LLM uygulamaları için uygun olan aiolimiter kütüphanesini kullanan basit bir token kovalası hız sınırlayıcı uygulaması bulunmaktadır.

import aiolimiter
import asyncio

# Bir hız sınırlayıcı tanımlayın: saniyede 10 istek, 5'lik patlama kapasitesi
rate_limiter = aiolimiter.AsyncLimiter(10, 5)

async def call_llm_endpoint():
    # API çağrısını yapmadan önce bir token edinin
    async with rate_limiter:
        try:
            # Bir LLM API çağrısını simüle edin
            response = await simulate_llm_api()
            return response
        except Exception as e:
            if "429" in str(e):
                await asyncio.sleep(1 + (2 ** retry_count) + asyncio.get_event_loop().time() % 1)
                raise
            else:
                raise

async def main():
    tasks = [call_llm_endpoint() for _ in range(20)]
    results = await asyncio.gather(*tasks)
    print(f"{len(results)} istek tamamlandı")

if __name__ == "__main__":
    asyncio.run(main())

Üretim Sistemleri İçin En İyi Uygulamalar

1. İzleyin ve Uyarı Verin: Başarılı isteklerin 429 hatalarına oranını takip edin. 429'larda ani bir artış, sağlayıcı sınırlarına takıldığınızı veya kontrolsüz bir süreç olduğunu gösterir.
2. Kademeye Göre Ayırt Edin: Premium ve ücretsiz kullanıcılar için veya dahili test ile üretim trafiği için farklı hızlar uygulayın.
3. Sağlayıcı Başlıklarını Kullanın: İstemci tarafındaki sınırlayıcıyı proaktif olarak ayarlamak için yanıtta X-RateLimit-Remaining veya benzeri başlıkları her zaman kontrol edin.
4. Ağır İşleri Kuyruğa Alın: Etkileşimsiz görevler için (ör. toplu veri işleme), gerçek zamanlı hız sınırlama yerine eşzamanlılık kontrollerine sahip bir iş kuyruğu (Celery veya AWS SQS gibi) kullanın.

Sonuç

LLMOps'ta hız sınırlama, tepki hızı ile kaynak kısıtlamaları arasında bir dengeleme eylemidir. Akıllı istemci tarafı sınırlayıcılar ve sağlam sunucu tarafı geri çekilme stratejileri uygulayarak dayanıklı, maliyet etkin ve kullanıcı dostu uygulamalar geliştirebilirsiniz. Unutmayın: Proaktif sınırlama, reaktif hata yönetimi daha ucuzdur. Küçük başlayın, metriklerinizi izleyin ve kullanım kalıplarınız değiştikçe sınırlarınızı ayarlayın.