LLMOps

Hareket Halinde Ustalık: Üretim LLM Uygulamaları İçin Güçlü Hız Sınırlama Uygulama

Büyük Dil Modelleri (LLM'ler) yazılım geliştirmeyi devrim niteliğinde değiştirdi ancak geleneksel web uygulamalarının nadiren karşılaştığı benzersiz operasyonel zorluklar da ortaya çıkar. Tahmin edilebilir yükleri olan standart REST API'lerinin aksine, LLM etkileşimleri hesaplama açısından maliyetlidir, gecikmeye duyarlıdır ve sağlayıcıya özgü kotalarla sıkı sıkıya yönetilir. LLMOps mühendisleri için etkili hız sınırlama uygulamak yalnızca bir güvenlik önlemi değil; maliyet kontrolü, sistem kararlılığı ve kullanıcı deneyimi yönetimi için kritik bir bileşendir.

Çifte Zorluk: İstemci Tarafı ve Sağlayıcı Tarafı Kısıtlamaları

GPT-4, Claude veya vLLM veya Hugging Face Inference Endpoints üzerinden açık kaynaklı varyantlar gibi modelleri entegre ederken geliştiriciler, çift kısıtlama manzarasıyla yüzleşmek zorundadır. Bir yandan API sağlayıcısı, Dakikadaki İstekler (RPM) ve Dakikadaki Tokenlar (TPM) için sıkı hız sınırlamaları uygular. Bu sınırların aşılması, hizmet sürekliliğini bozan 429 Çok Fazla İstek hatalarına neden olur.

Öte yandan, kendi uygulama altyapınızın da sınırları vardır. Tek bir büyük yanıt, belleği tek başına kullanabilir ve diğer kullanıcılar için gecikme artışlarına yol açabilir. İstemci tarafı hız sınırlaması olmadan, ani bir trafik artışı veya kontrolsüz bir ajan döngüsü, sağlayıcı isteği engellemeden önce bütçenizi tüketebilir ve sunum altyapınızı aşırı yükleyebilir.

Uyarlanabilir Hız Sınırlayıcıların Uygulanması

Statik hız sınırlama (örneğin, "saniyede en fazla 10 istek"), token sayılarının büyük ölçüde değişmesi nedeniyle LLM'ler için genellikle yetersiz kalır. Daha etkili bir yaklaşım, token kullanımına dayalı dinamik hız sınırlamadır. Aşağıda, hem istek sıklığını hem de token verimliliğini işlemek üzere tasarlanmış, Python'da kayan pencere sayacı kullanan pratik bir uygulama yer almaktadır.

import time
from collections import defaultdict

class TokenAwareRateLimiter:
    def __init__(self, max_rpm=60, max_tpm=10000):
        self.max_rpm = max_rpm
        self.max_tpm = max_tpm
        self.request_timestamps = defaultdict(list)
        self.token_usage = defaultdict(list)

    def wait_if_needed(self, client_id, tokens_estimated):
        now = time.time()
        
        # 1. RPM'yi Kontrol Et (Dakikadaki İstekler)
        # 60 saniyelik pencerenin dışındaki eski zaman damgalarını temizle
        self.request_timestamps[client_id] = [
            t for t in self.request_timestamps[client_id] if now - t < 60
        ]
        if len(self.request_timestamps[client_id]) >= self.max_rpm:
            wait_time = 60 - (now - self.request_timestamps[client_id][0])
            if wait_time > 0:
                print(f"{client_id} için RPM sınırına ulaşıldı. {wait_time:.2f}s bekleniyor")
                time.sleep(wait_time)

        # 2. TPM'yi Kontrol Et (Dakikadaki Tokenlar)
        self.token_usage[client_id] = [
            t for t in self.token_usage[client_id] if now - t < 60
        ]
        current_token_sum = sum(self.token_usage[client_id])
        if current_token_sum + tokens_estimated > self.max_tpm:
            # Tokenlar sınırı aşıyorsa basit geri çekilme
            print(f"{client_id} için TPM sınırına yaklaşılıyor. Mevcut: {current_token_sum}")
            time.sleep(2) 

        # İsteği kaydet
        self.request_timestamps[client_id].append(now)
        self.token_usage[client_id].append(tokens_estimated)

# Kullanım Örneği
limiter = TokenAwareRateLimiter(max_rpm=60, max_tpm=50000)
limiter.wait_if_needed("user_123", tokens_estimated=500)
print("İstek izin verildi")

Dayanıklılık İçin Stratejiler: Üstel Geri Çekilme ve Devre Kesici

Sınırlardan kaçınmak idealdir, ancak onlara zarifçe yaklaşmak zorunludur. Bir 429 hatası oluştuğunda, acil yeniden denemeler sorunu yalnızca kötüleştirecektir. Jitter (rastgelelik) ile üstel geri çekilme uygulamak standart bir uygulamadır. Ancak, LLM'ler için devre kesici kalıplarını eklemeyi düşünün. Uygulamanız, sürekli yüksek hata oranları tespit ederse, yeni LLM çağrılarını geçici olarak durdurmalı ve kullanıcıları daha küçük, daha hızlı bir modele veya önbelleğe alınmış bir yanıta yönlendiren bir yedek mekanizmaya yönlendirmelidir.

Sonuç

LLMOps'ta hız sınırlama artık isteğe bağlı değildir; temel bir yetkinliktir. Sağlayıcı tarafı farkındalığını, token farkında sayıcılar ve üstel geri çekilme gibi istemci tarafı uyarlanabilir kontrollerle birleştirerek, AI uygulamalarınızın maliyet etkin, kararlı ve duyarlı kalmasını sağlarsınız. LLM manzarası evrildikçe, orkestrasyon stratejilerimiz de evrim geçirmeli; böylece ölçekleme, güvenilirlik pahasına gerçekleşmez.

Share: