Skip to main content

> çok_katmanlı_llm_hız_sınırlaması:_dakika_başına_jeton_(tpm)_ve_i̇stek_(rpm)_yönetimi

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

Standart API hız sınırlayıcılar sağlayıcı (OpenAI/Anthropic) 429 hatalarını neden engelleyemez; iki boyutlu TPM/RPM kayan pencere zamanlayıcıları yapay zeka trafik patlamalarını nasıl dengeler?

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: (1) Hızlı Ön Jeton Tahmini (`tiktoken` ile girdi jetonunu saymak), (2) Atomik Redis Jeton Rezervasyonu (hem RPM hem tahmini TPM kotasını baştan kiralamak) ve (3) Üretim Sonrası Mutabakat (akış bittiğinde aradaki gerçek jeton farkını önbellekle dengelemek).

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

İki boyutlu LLM hız sınırlaması 4 adımda çalışır: (1) Ö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. (2) Ç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. (3) Sağlayıcı Çağrısı: İstek modele gönderilir. (4) 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

Ç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ı

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

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

Ç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)

Ö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 Örneği)

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
Q1

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.
Q2

İ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