DEV Community

Cover image for GPT API Hız Limitleri: Katmanlar, Kullanım Sınırları ve Apidog ile Nasıl Test Edilir
Tobias Hoffmann
Tobias Hoffmann

Posted on • Originally published at apidog.com

GPT API Hız Limitleri: Katmanlar, Kullanım Sınırları ve Apidog ile Nasıl Test Edilir

GPT API'yi çağıran bir fonksiyon yayınladınız. Staging ortamında her şey sorunsuz, ancak üretimde ilk yüz kullanıcı geldiğinde loglarınız 429 Çok Fazla İstek hatalarıyla doluyor. Sorun dakikadaki istek sayısı mı, dakikadaki token kullanımı mı, günlük kota mı, yoksa kullandığınız modelin limitleri mi? Bunu tahmin etmek yerine ölçmeniz gerekir.

Apidog'u bugün deneyin

💡 Bu makalede, mevcut GPT modeliniz için hız limitlerini nasıl okuyacağınızı, birkaç API çağrısı ve Apidog’da küçük bir yük testiyle canlı limitlerinizi nasıl doğrulayacağınızı göreceksiniz. Sonuçta, hız limiti sorunu yaşadığınızda tekrar çalıştırabileceğiniz bir iş akışı ve ekibinizle paylaşabileceğiniz kaydedilebilir bir istek koleksiyonu elde edeceksiniz.

OpenAI ile çalıştıysanız, her yeni modelle hız limiti takibinin daha karmaşık hale geldiğini bilirsiniz. GPT-5.5’in GPT-4.1’den farklı limitleri olabilir, görüntü modelleri metin modellerinden farklı sayılır ve harcamanız arttıkça kullanım seviyeniz değişebilir. Apidog; yanıt başlıklarını incelemek, eş zamanlı trafiği simüle etmek ve kodu dağıtmadan önce hangi limite takıldığınızı doğrulamak için tek bir çalışma alanı sağlar.

Gerçekten Önemli Olan Dört Limit

OpenAI, GPT API anahtarları için birden fazla hız limiti uygular. Üretim ortamında genellikle şu dört boyutla karşılaşırsınız:

  • RPM: Dakikadaki istek sayısı. Dakikada kaç API çağrısı gönderebileceğinizi belirler.
  • TPM: Dakikadaki token sayısı. Girdi ve çıktı tokenlarının toplamıdır.
  • RPD: Günlük istek sayısı. Özellikle ücretsiz ve 1. seviye anahtarlarda önemlidir.
  • IPM / TPD / toplu işlem kuyruğu limitleri: Görüntü, ses, embedding ve batch uç noktaları için modele veya uç nokta ailesine özel limitlerdir.

Bir istek reddedildiğinde API genellikle HTTP 429 ve buna benzer bir JSON gövdesi döndürür:

{
  "error": {
    "message": "Rate limit reached for gpt-5.5 in organization org-abc on tokens per min (TPM): Limit 30000, Used 28432, Requested 3120.",
    "type": "tokens",
    "param": null,
    "code": "rate_limit_exceeded"
  }
}
Enter fullscreen mode Exit fullscreen mode

Burada kritik alan message ve type değerleridir. Hata size hangi boyutu aştığınızı söyler:

  • tokens: TPM limitine takıldınız.
  • requests: RPM limitine takıldınız.
  • tokens_usage_based: token kullanımına bağlı bir sınıra takıldınız.

Bir 429, her zaman aynı anlama gelmez. RPM aşımı ile TPM aşımının çözümü farklıdır.

HTTP düzeyinde 429 için MDN 429 belgelerine ve RFC 6585 spesifikasyonuna bakabilirsiniz. OpenAI’ye özgü davranışlar için resmi hız limiti sayfasını yer imlerinize ekleyin.

Seviyeler Nasıl Çalışır?

GPT API anahtarınız bir OpenAI kullanım seviyesine bağlıdır. Bu seviye, RPM ve TPM limitlerinizin arkasındaki gerçek sayıları belirler.

Seviye geçişleri genellikle iki faktöre bağlıdır:

  1. Hesaptaki toplam harcama
  2. İlk ödeme tarihinden bu yana geçen süre

Genel görünüm şu şekildedir:

Seviye Harcama sınırı Bekleme süresi Metin RPM Metin TPM
Free none none 3 40k
1 $5 paid none 500 30k–200k by model
2 $50 paid 7 days 5,000 450k
3 $100 paid 7 days 5,000 1M
4 $250 paid 14 days 10,000 2M
5 $1,000 paid 30 days 10,000 2M+

Bu değerler açıklayıcıdır. Kesin limitler zamanla ve modele göre değişebilir. Üretim kapasitesi planlaması yapmadan önce canlı limitlerinizi yanıt başlıklarından doğrulayın.

Pratik olarak iki noktayı unutmayın:

  1. Ödeme sonrası seviye değişimi otomatik olabilir. Harcama ve bekleme koşulları sağlandığında istekleriniz yeni limitlerle çalışmaya başlar.
  2. Seviye düşüşü olabilir. Uzun süre kullanılmayan hesaplar veya başarısız ödeme yöntemleri daha düşük limitlere neden olabilir.

Diğer sağlayıcılarla karşılaştırma yapmak isterseniz şu kılavuzlara bakabilirsiniz:

Canlı Limitlerinizi Yanıt Başlıklarından Okuyun

Kontrol panelinde arama yapmak yerine, her GPT API yanıtındaki rate limit başlıklarını okuyabilirsiniz.

Özellikle şu başlıklara bakın:

  • x-ratelimit-limit-requests: Bu uç nokta için RPM limitiniz.
  • x-ratelimit-remaining-requests: Bu dakika içinde kalan istek hakkınız.
  • x-ratelimit-limit-tokens: TPM limitiniz.
  • x-ratelimit-remaining-tokens: Bu dakika içinde kalan token hakkınız.
  • x-ratelimit-reset-requests: İstek kotasının ne zaman sıfırlanacağı.
  • x-ratelimit-reset-tokens: Token kotasının ne zaman sıfırlanacağı.

Örnek reset değerleri:

6s
1m30s
Enter fullscreen mode Exit fullscreen mode

Bu başlıkları okumak için en basit yol, tek bir düşük maliyetli chat completion isteği göndermek ve dönen başlıkları incelemektir.

Adım 1: Apidog’da GPT İsteğini Yapılandırın

Apidog’u açın, yeni bir proje oluşturun ve yeni bir istek ekleyin.

Method: POST
URL: https://api.openai.com/v1/chat/completions
Enter fullscreen mode Exit fullscreen mode

Headers sekmesine şunları ekleyin:

Anahtar Değer
Authorization Bearer {{OPENAI_API_KEY}}
Content-Type application/json

{{OPENAI_API_KEY}}, Apidog ortam değişkeninden okunur. Böylece API anahtarını isteğin içine sabitlemezsiniz.

Örnek ortam değişkenleri:

OPENAI_API_KEY=sk-...
OPENAI_ORG_ID=org-...
OPENAI_PROJECT_ID=proj_...
Enter fullscreen mode Exit fullscreen mode

Body sekmesinde JSON seçin ve şu gövdeyi ekleyin:

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "user",
      "content": "ping"
    }
  ],
  "max_tokens": 10
}
Enter fullscreen mode Exit fullscreen mode

İsteği gönderin. Yanıt geldikten sonra response panelindeki Headers sekmesini açın ve şu değerleri kaydedin:

x-ratelimit-limit-requests
x-ratelimit-remaining-requests
x-ratelimit-limit-tokens
x-ratelimit-remaining-tokens
Enter fullscreen mode Exit fullscreen mode

Bunlar mevcut hesabınız, modeliniz ve uç noktanız için canlı limitlerdir.

Chat completion isteğini daha ayrıntılı kurmak için Apidog ile ChatGPT API’sini test etme kılavuzuna bakabilirsiniz.

Adım 2: Limitleri Küçük Bir Ani Yük Testiyle Doğrulayın

Başlıklar size limiti gösterir; ancak limit noktasındaki davranışı görmek için küçük bir ani yük testi çalıştırmanız gerekir.

Apidog’da kayıtlı isteğinizi açın. Send düğmesinin yanındaki menüden test senaryosunda çalıştırmayı seçin.

Başlangıç için şu değerleri kullanın:

Iterations: 50
Concurrency: 10
Delay between iterations: 0 ms
Enter fullscreen mode Exit fullscreen mode

Bu test iki olası sonucu gösterir:

  1. Bazı istekler 429 döner.

    Limitin gerçekten devreye girdiğini doğrularsınız.

  2. Tüm istekler başarılı olur.

    RPM limitiniz düşündüğünüzden yüksek olabilir. Yanıt başlıklarındaki remaining-requests değerini kontrol edin.

Apidog test çalıştırıcısı her yanıtı kaydeder. Durum koduna göre sıralayarak tüm 429 yanıtlarını tek ekranda görebilirsiniz.

Bir 429 satırını açın ve gövdedeki message alanını okuyun. Bu alan genellikle sorunun RPM, TPM veya günlük kota olduğunu açıkça söyler.

Ek okuma için hız limiti aşıldı kılavuzuna bakabilirsiniz.

Adım 3: RPM Aşımını TPM Aşımından Ayırın

İlk test küçük isteklerle yapıldığı için çoğunlukla RPM davranışını ölçer. TPM’yi test etmek için daha az istek göndermeli, ancak her isteği daha büyük hale getirmelisiniz.

Örnek gövde:

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "system",
      "content": "<3,000 tokens of context here>"
    },
    {
      "role": "user",
      "content": "Summarise the above in one sentence."
    }
  ],
  "max_tokens": 200
}
Enter fullscreen mode Exit fullscreen mode

Bu kez daha düşük eş zamanlılıkla çalıştırın:

Iterations: 20
Concurrency: 5
Delay between iterations: 0 ms
Enter fullscreen mode Exit fullscreen mode

Eğer 30k TPM limitli 1. seviye bir hesap kullanıyorsanız, istek sayısı limitinden önce token limitine takılabilirsiniz.

Çözüm, hangi limite takıldığınıza göre değişir:

Sorun Belirti Çözüm
RPM aşımı Çok fazla küçük istek Kuyruk, batching, eş zamanlılık sınırı
TPM aşımı Az sayıda büyük istek Prompt kırpma, context azaltma, cache, isteği bölme
Günlük kota Gün sonunda 429 Kota/plan/faturalandırma kontrolü

Adım 4: Eş Zamanlı Kullanıcıları Simüle Edin

Ani yük testleri üst sınırı gösterir. Üretim trafiği ise genellikle daha karmaşıktır:

  • Birden fazla kullanıcı
  • Farklı prompt boyutları
  • Sabit trafik üzerine gelen ani yükler
  • Değişken response süreleri

Apidog’da bir test senaryosu oluşturup küçük, orta ve büyük istek gövdelerini sırayla çalıştırabilirsiniz.

Test senaryosunda şunları ölçün:

  • Her yanıtın status code değeri
  • x-ratelimit-remaining-tokens
  • x-ratelimit-remaining-requests
  • 429 yanıtlarının hangi noktada başladığı
  • 200 ve 429 yanıtlarının latency farkı

Apidog’un JavaScript pre-request ve post-response script desteğiyle her iterasyonda farklı mesaj uzunlukları da seçebilirsiniz.

Örnek mantık:

const prompts = [
  "ping",
  "Bu metni tek cümlede özetle: ...",
  "Uzun bağlam: ..."
];

const selected = prompts[Math.floor(Math.random() * prompts.length)];

apidog.variables.set("USER_PROMPT", selected);
Enter fullscreen mode Exit fullscreen mode

Body içinde değişkeni kullanın:

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "user",
      "content": "{{USER_PROMPT}}"
    }
  ],
  "max_tokens": 100
}
Enter fullscreen mode Exit fullscreen mode

Senaryo bittiğinde status code histogramını kaydedin. Bu rapor, ekip içinde “hız limitine mi takılıyoruz?” sorusunu hızlıca yanıtlamak için tekrar çalıştırılabilir bir referans olur.

Kısıtlandığınızda Ne Yapmalısınız?

Limitin nerede olduğunu ölçtükten sonra üç temel seçeneğiniz vardır.

1. Geri Çekilme ve Yeniden Deneme Ekleyin

Her GPT çağrısını retry mantığıyla sarın. 429 aldığınızda mümkünse reset başlığını okuyun:

x-ratelimit-reset-tokens
x-ratelimit-reset-requests
Enter fullscreen mode Exit fullscreen mode

Basit bir yaklaşım:

async function callWithRetry(fn, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (error) {
      const status = error.response?.status;

      if (status !== 429 || attempt === maxAttempts - 1) {
        throw error;
      }

      const reset =
        error.response?.headers?.["x-ratelimit-reset-tokens"] ||
        error.response?.headers?.["x-ratelimit-reset-requests"];

      const delayMs = parseResetHeader(reset) ?? Math.pow(2, attempt) * 1000;

      await new Promise((resolve) => setTimeout(resolve, delayMs));
    }
  }
}

function parseResetHeader(value) {
  if (!value) return null;

  if (value.endsWith("ms")) return Number(value.replace("ms", ""));
  if (value.endsWith("s")) return Number(value.replace("s", "")) * 1000;

  return null;
}
Enter fullscreen mode Exit fullscreen mode

2. Kuyruk Kullanın

Trafiğiniz ani yüklenmeler içeriyorsa, istekleri doğrudan OpenAI’ye göndermek yerine kuyruğa alın. Ardından worker’ları RPM ve TPM limitlerinin altında çalışacak şekilde sınırlandırın.

Temel yaklaşım:

API request -> queue -> rate-limited worker -> OpenAI API
Enter fullscreen mode Exit fullscreen mode

Bu model özellikle şu durumlarda işe yarar:

  • Arka plan işleme
  • Belge sınıflandırma
  • Çok sayıda küçük analiz görevi
  • RAG pipeline işlemleri

Uygulama detayları için şu yazılara bakabilirsiniz:

3. Toplu İşleme Geçin

İş yükünüz gerçek zamanlı yanıt gerektirmiyorsa, OpenAI Batch API daha uygun olabilir. Örneğin:

  • Gece çalışan zenginleştirme işleri
  • Belge sınıflandırma
  • Embedding yeniden oluşturma
  • Büyük veri seti üzerinde asenkron analiz

Bu sayede kullanıcıya dönük canlı trafiğiniz için eş zamanlı kotayı korursunuz.

Kısıtlama ve hız limiti farkını netleştirmek için kısıtlama vs. hız limiti yazısına da bakabilirsiniz.

Yaygın GPT 429 Hataları

Gerçek dünyadaki 429 hatalarının çoğu şu üç kategoriye girer.

Rate limit reached ... requests per min (RPM)

Kodunuz dakikada çok fazla çağrı yapıyor.

Yapılacaklar:

  • Eş zamanlılık sınırı koyun.
  • Her kaydı aynı anda Promise.all ile göndermeyin.
  • Worker sayısını RPM limitinize göre ayarlayın.
  • Küçük istekleri mümkünse batch haline getirin.

Rate limit reached ... tokens per min (TPM)

İstekleriniz token açısından çok büyük.

Yapılacaklar:

  • Sistem prompt’unu kısaltın.
  • RAG context boyutunu sınırlayın.
  • Uzun belgeleri parçalara bölün.
  • Gereksiz geçmiş mesajlarını göndermeyin.
  • max_tokens değerini gerçekçi bir üst sınıra düşürün.

You exceeded your current quota

Bu teknik olarak 429 gibi görünse de genellikle hız limiti değil, faturalandırma sorunudur.

Kontrol edin:

  • Aylık harcama limiti
  • Kayıtlı kart durumu
  • Ön ödemeli bakiye
  • Organizasyon veya proje kotası

Bu durumda çözüm retry değil, faturalandırma panelidir.

SSS

Apidog, GPT hız limitlerini test etmek için ücretli mi?

Hayır. Ücretsiz plan, tek istek testini ve küçük eş zamanlı test çalıştırmalarını kapsar. Daha büyük test yükleri, ekip çalışma alanları veya zamanlanmış çalıştırmalar için ücretli plana ihtiyaç duyabilirsiniz. Detaylar için Apidog fiyatlandırmasına bakın.

Gerçek token harcamadan hız limitlerini test edebilir miyim?

Kısmen. En ucuz temel kontrol için max_tokens: 1 ve tek karakterlik bir mesaj gönderebilirsiniz. Bu çok düşük maliyetlidir ve rate limit başlıkları yine döner.

Ani yük testleri gerçek token harcar, ancak her çağrıyı küçük tutabilirsiniz. Tamamen çevrimdışı test için Apidog’un mock server özelliğiyle 429 yanıtlarını simüle edip retry mantığınızı OpenAI’yi çağırmadan doğrulayabilirsiniz.

1. seviye anahtarım neden başka bir 1. seviye anahtardan daha yavaş?

Limitler genellikle tek anahtar yerine organizasyon düzeyinde paylaşılır. Aynı organizasyonda başka yoğun kullanıcılar varsa, aynı kotayı tüketiyor olabilirsiniz.

Bunu doğrulamak için aynı isteği iki farklı anahtarla çalıştırın ve şu başlıkları karşılaştırın:

x-ratelimit-remaining-requests
x-ratelimit-remaining-tokens
Enter fullscreen mode Exit fullscreen mode

Hangi modelin hangi limite sahip olduğunu nasıl anlarım?

Yanıt başlıklarını okuyun. Blog yazılarındaki tabloları yalnızca başlangıç noktası olarak kullanın.

Her model için tek bir düşük maliyetli istek gönderin ve şu başlıkları kaydedin:

x-ratelimit-limit-requests
x-ratelimit-limit-tokens
Enter fullscreen mode Exit fullscreen mode

Aynı model ailesindeki farklı snapshot sürümleri farklı limitlere sahip olabilir.

Streaming istekleri farklı mı sayılır?

TPM açısından evet. Streaming istekleri max_tokens değerine göre token ayırabilir. Bu yüzden gerçek yanıt kısa olsa bile yüksek max_tokens değeri TPM bütçenizi gereksiz tüketebilir.

max_tokens değerini ihtiyacınız olan en düşük gerçekçi üst sınıra indirin. Streaming davranışı için Apidog ile ChatGPT API’sini test etme kılavuzuna bakabilirsiniz.

Apidog hız limiti testimi ekibimle paylaşabilir miyim?

Evet. İsteği ve test senaryosunu paylaşılan bir projeye kaydedin. Ekip üyeleri kendi ortam değişkenlerini kullanarak aynı testi kendi anahtarlarıyla çalıştırabilir.

Bu, “benim anahtarım mı, organizasyon kotası mı, yoksa model limiti mi?” sorusunu hızlıca yanıtlamanızı sağlar.

Top comments (0)