Çok Katmanlı LLM Hız Sınırlaması: Dakika Başına Jeton (TPM) ve İstek (RPM) Yönetimi

Senior (L5)

⚡ÖZET VE TEKNİK CEVAP

Standart API hız sınırlayıcıları (Nginx veya Cloudflare) trafiği sadece Dakika Başına İstek (RPM) olarak ölçer ve her isteği eşit yük sayar. Ancak üretken yapay zekada bu yaklaşım çöker çünkü sağlayıcılar (OpenAI, Anthropic) iki ayrı katı kota uygular: Dakika Başına İstek (RPM) VE Dakika Başına Jeton (TPM). 100.000 jetonluk bir PDF gönderen tek bir kullanıcı, 20 jetonluk bir 'Merhaba' mesajıyla aynı 1 RPM'i harcar; fakat 5.000 kat daha fazla TPM tüketerek sağlayıcının TPM kotasını anında doldurur ve diğer tüm kullanıcıların HTTP 429 hatası alıp kilitlenmesine yol açar. Canlı yapay zeka ağ geçitleri bunu İki Boyutlu Token Bucket Zamanlaması ile çözer:

Hızlı Ön Jeton Tahmini (tiktoken ile girdi jetonunu saymak),

Atomik Redis Jeton Rezervasyonu (hem RPM hem tahmini TPM kotasını baştan kiralamak) ve

Üretim Sonrası Mutabakat (akış bittiğinde aradaki gerçek jeton farkını önbellekle dengelemek).

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

İki boyutlu LLM hız sınırlaması 4 adımda çalışır:

Ön Jeton Sayımı: Gelen metin bellekte mikro saniyeler içinde (tiktoken) taranarak tahmini toplam jeton T_{ ext{tahmin}} = T_{ ext{girdi}} + T_{ ext{max_cikti}} hesaplanır.

Çift Boyutlu Kiralama (Redis Lua): Sistem atomik olarak hem RPM sayacını (R ge 1) hem de TPM sayacını (T ge T_{ ext{tahmin}}) düşürür. TPM yetersizse istek hata vermek yerine bellek içi öncelikli kuyrukta bekletilir.

Sağlayıcı Çağrısı: İstek modele gönderilir.

Gerçekleşen Mutabakat: Akış bittiğinde gelen gerçek jeton sayısı (T_{ ext{gercek}}) okunur ve aradaki fazla rezerve edilmiş jeton farkı (T_{ ext{tahmin}} - T_{ ext{gercek}}) anında kullanıcının TPM havuzuna geri iade edilir.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Çok kiracılı SaaS yapay zeka ağ geçitleri, şirket içi geliştirici LLM vekil sunucuları, toplu belge işleme boru hatları ve kurumsal yapay zeka portalları.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
Tek bir kullanıcının 50 paralel thread ile belge özetletip şirketin tüm 1.000.000 TPM'lik OpenAI kotasını tüketmesi ve canlıdaki müşteri destek botunun 3 dakika boyunca HTTP 429 ile kilitlenmesi
✓
sağlayıcı küresel yoğunluk yüzünden erken kısıtlama uyguladığında sistemin dinamik geri çekilme (backoff) yapamaması

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

✓
Sağlayıcı loglarında Rate limit reached on tokens_per_min alarmlarının patlaması
✓
API ağ geçidinde RPM kullanımı %5 iken TPM kullanımının %100'e vurması
✓
toplu veri yüklemelerinde müşteri çağrılarının zaman aşımına uğraması

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
Çift TPM/RPM sınırlayıcılı bir yapay zeka vekil sunucusu (LiteLLM) kurun
✓
TPM kotalarını servisler arasında katı olarak paylaştırın (musteri_destek: %60, toplu_isler: %20, gelistirici: %20)
✓
TPM %85'i aştığında trafiği otomatik olarak Azure OpenAI veya Anthropic'e aktaran dinamik yük devretme (failover) devreleri kurun

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Ön jeton sayımı ve mutabakat ağ geçidinde ~1-2 ms'lik önemsiz bir gecikme ekler ve Redis gerektirir; ancak sağlayıcı kaynaklı zincirleme HTTP 429 kesintilerini tamamen ortadan kaldırır.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

10.000 kullanıcılı bir SaaS platformunda, pazarlama ekibi sabahları toplu metin üretimi başlattığında 10 saniyede 800.000 TPM kotasını dolduruyor ve canlıdaki tüm müşteri botları çöküyordu. Ekip Çift TPM/RPM sınırlayıcılı LiteLLM vekil sunucusunu devreye aldı: Toplu işlere 150.000 TPM tavanı ve geciktirme kuyruğu verildi; Canlı Müşteri Sohbetine ise 600.000 TPM öncelikli kota ayrıldı. Canlıdaki HTTP 429 hata sayısı günde 1.200'den tam olarak 0'a indi.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

Geleneksel Dakika Başına İstek (RPM) hız sınırlaması üretken yapay zeka API'ları için neden yetersizdir?

Çünkü isteklerin boyutları devasa değişkenlik gösterir: Tek bir büyük belge analizi 100.000 TPM tüketebilir ve RPM limiti aşılmasa bile sağlayıcının jeton kotasını anında tüketebilir.

İki boyutlu hız sınırlayıcılarda Jeton Mutabakatı (Token Reconciliation) nasıl çalışır?

Ağ geçidi isteği göndermeden önce tahmini bir jeton miktarını rezerve eder; üretim tamamlandığında kullanılmayan fazla rezerve jetonlar Redis'teki kullanıcı kotasına anında geri iade edilir.

Çok Katmanlı LLM Hız Sınırlaması: Dakika Başına Jeton (TPM) ve İstek (RPM) Yönetimi — Sıkça Sorulan Sorular

Hangi açık kaynaklı araçlar hazır LLM TPM/RPM hız sınırlaması sağlar?

LiteLLM Proxy, Portkey Gateway, Langfuse ve Envoy AI Gateway.

Bir kullanıcı TPM sınırını aştığında Yapay Zeka Ağ Geçidi ne yapmalıdır?

Canlı sohbetlerde `Retry-After: <saniye>` başlığıyla HTTP 429 dönmelidir; arka plan toplu işlerinde ise isteği gecikmeli bir öncelik kuyruğuna alıp sırayla eritmelidir.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸
LLM providers enforce dual rate limits: Requests-Per-Minute (RPM) and Tokens-Per-Minute (TPM).
▸
A single massive document request can exhaust entire organizational TPM quotas.
▸
Pre-flight token estimation (tiktoken) reserves RPM and TPM leases in Redis Lua.
▸
Post-generation reconciliation refunds unused estimated token headroom in real-time.

Yaygın Yanılgılar

✗
Yanılgı: Standard Nginx rate limiting protects against OpenAI 429 errors (Gerçek: Nginx knows nothing about token counts).
✗
Yanılgı: Setting max_tokens to 4,096 always charges 4,096 tokens (Gerçek: Models only charge for actual generated tokens; reconciliation balances the difference).

Karar Kılavuzu & Önceliklendirme

Deploy LiteLLM Proxy with Redis-backed TPM/RPM rate limiting for all enterprise AI applications. Partition TPM quotas strictly between interactive user chats and background batch jobs.

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL_DOCUMENTATION]OpenAI Platform Guide: Rate Limits, TPM/RPM Quotas & Tier Architecture— OpenAI Developer Platform

Bu sayfadaki teknik terimler

Application Programming Interface