OpenAI API kullanım katmanları: Build, Launch, Grow ve harcama sınırları
Güncellendi October 7, 2026 · ilk yayın October 7, 2026
OpenAI, ücretli API katmanlarını 6 Ekim 2026'da Build, Launch ve Grow olarak sadeleştirdi. Kurumlar, birikmiş kredi alımları her eşiği aştığında otomatik olarak üst katmana geçer; bu genellikle daha yüksek hız limitleri açar. Katman bir kapasite ve aylık kullanım payı sinyalidir; proje veya kurum harcama limitlerinden ayrıdır. Bu limitler bütçe kontrolleri olarak ayrıca yapılandırılmalıdır.
OpenAI API kullanım katmanlarında neler değişti?
OpenAI'nin 6 Ekim değişiklik günlüğü, API platformunun beş ücretli katmandan üçe indiğini belirtiyor: Build, Launch ve Grow. Güncel hız limiti rehberi bu yeterlilik seviyelerini listeliyor: Build için toplam $5 kredi alımı, Launch için $100 ve Grow için $500. Ayrıca uygun ücretsiz katman kullanıcıları için aylık $100 kullanım limitini de belirtiyor. OpenAI, daha yüksek katmanların genellikle daha yüksek model hız limitleri aldığını söylüyor.
Satın alma tutarları, katman uygunluğunu belirlemek için kullanılan birikimli eşiklerdir. Aylık abonelik ücreti değildir ve kurumunuzun her ay tam olarak bu tutarı harcayacağı anlamına gelmez. Yayımlanan rehber bunları toplam kredi alımı olarak tanımlıyor. Gerçek katmanınızı, onaylanmış aylık kullanım limitinizi ve model bazlı limitlerinizi kurum panelinden kontrol edin; operasyonel planlama için önemli olan kurumunuzun durumudur.
Daha yüksek bir katman bir ekibe ne sağlar?
Hız limitleri dakika başına istek sayısını (RPM), dakika başına token sayısını (TPM), günlük hacmi, görüntü verimini veya kuyruktaki Batch işlerini sınırlayabilir. Bir iş aylık kullanım limitinin altında kalabilir ve yine de dakikalık bir limite takılabilir. Güncel rehber model bazlı farkları gösteriyor: GPT-6 Astra, Sol ve Terra için standart RPM/TPM örnekleri Build'de 5,000 RPM ve 1 milyon TPM iken Launch'ta 10,000 RPM ve 4 milyon TPM'ye, Grow'da ise 15,000 RPM ve 40 milyon TPM'ye çıkıyor. GPT-6 Luna için listelenen standart limitler yine farklıdır. Bunlar yayımlanmış referans değerleridir; kurumunuz, modeliniz ve projeniz için gösterilen limitlerin yerini tutmaz.
Bu ayrım lansmanlarda önemlidir. Bir ekip yeterli aylık kapasiteyi öngörmüş olabilir ve yine de yeni bir iş yükü trafiği çok hızlı gönderdiğinde ya da istek veya token verimini aştığında kısıtlanabilir. Hız limitleri kurum ve proje düzeyinde birlikte uygulanabilir ve farklı modeller tek bir limiti paylaşabilir. Bir katman adını kapasite garantisi saymadan önce yanıt başlıklarına ve panele bakın.
Katmanlar aylık harcamayı sınırlamanın bir yolu mu?
Hayır. OpenAI, onaylanmış aylık kullanım limitlerini kurum veya proje harcama limitlerinden ayrı belgeler. Harcama uyarısı API trafiği sürerken bir bildirim gönderir. Sert harcama limiti ise yapılandırılan tutara ulaşıldığında etkilenen API isteklerini 429 yanıtıyla engeller. Zorlayıcı bir kontrol gerektiğinde sert limiti seçin; uyarı görünürlük sağlar, devre kesici değildir.
Bu da bir katman eşiğini aşmak için kredi satın almanın tek başına güvenli bir maliyet kontrol politikası olmadığı anlamına gelir. Katman verimi artırabilir, ancak proje bazlı sahiplik, uyarı yönlendirmesi, kullanım tahmini veya bilinçli bir sert limitin yerini tutmaz. Daha fazla lansman kapasitesine ihtiyaç duyan bir mühendislik grubu, hem uygunluk için gereken satın alma eşiğini hem de Finans'ın uygulanmasını istediği ayrı aylık harcama tavanını modellemelidir.
Finans ve mühendislik katman yükseltmelerini nasıl yönetmeli?
- Kurumu ve projeleri envanterleyin. Her üretim projesi için katmanı, aylık kullanım payını, model bazlı RPM/TPM değerlerini, paylaşılan limitleri ve sahiplerini kaydedin.
- Açık harcama kontrolleri belirleyin. Trafiğin sabit bir bütçede durması gereken yerlerde proje düzeyinde sert limitler, ekiplerin erken uyarıya ihtiyaç duyduğu yerlerde ise uyarılar yapılandırın. Katman payının bu kontrolü sağladığını varsaymayın.
- İş yükü artışını tahmin edin. Aylık token harcamasının yanında dakika başına istek ve token sayısını da öngörün. Bir servis, aylık dolar tavanına çok önce verim limitine takılabilir.
- Katmanla ilgili satın almaları denetleyin. Kümülatif eşiği ilerleten ek kredi alımlarını erişim ve kapasite kararı olarak değerlendirin. Talep etmeden önce iş yükü tahmini, sahip ve mevcut kontrollerin gözden geçirilmesini isteyin.
- Gerçek yanıtı gözlemleyin. İstek, token ve diğer limit tükenmelerini ayırt etmek için hız limiti başlıklarını ve günlükleri kullanın. Yeniden deneme fırtınası yaratmamak için geçici hız limiti yanıtlarında geri çekilme (backoff) uygulayın.
Örneğin, varsayımsal olarak, bir ürün ekibi bir lansman kampanyasının dakika başına istekleri üç katına çıkarmasını bekliyor, ancak aylık token kullanımını Finans'ın tavanının altında tutmayı hedefliyor. Operasyonel soru, projenin model bazlı RPM ve TPM değerlerinin bu artışı kaldırıp kaldıramayacağıdır. Finansal soru ise sert harcama limitinin onaylanmış kampanya bütçesine ayarlanıp ayarlanmadığıdır. Bunlar birbiriyle ilişkili incelemelerdir, ancak farklı kontrollerdir.
Bir ekip Build'den Launch'a geçmeye nasıl karar vermeli?
Katman etiketinden değil, iş yükü kanıtından başlayın. Üretim günlükleri mevcut katmanda tekrar eden limit tükenmesi gösteriyorsa, gereken RPM ve TPM payını tahmin edin, hangi model ve proje limitlerinin geçerli olduğunu belirleyin ve katmanın etkisini panelde doğrulayın. Ardından uygunluk için gereken kredi alımını iş değeri ve bütçe politikasıyla karşılaştırın. Mevcut limitler yeterliyse, sırf bir sonraki katman var diye yükseltme yapmanın operasyonel bir faydası olmaz.
OpenAI, daha yüksek katmanların genellikle limitleri artırdığını ve yayımlanan eşiklerin değişebileceğini belirtiyor. Bir bütçe döngüsünden ya da önemli bir trafik değişikliğinden önce hız limiti rehberini ve paneli yeniden kontrol edin. Harcama uyarısı ve sert limit incelemesini, model karışımı, yeniden denemeler ve başarılı görev başına maliyetle birlikte aynı aylık FinOps rutininde tutun.
Pratik sonuç nedir?
Build, Launch ve Grow bir kapasite sorusunu yanıtlar: kurumun birikmiş alımları arttıkça hangi limitler ve kullanım payları geçerli olabilir? Harcama kontrolleriniz ise bir bütçe sorusunu yanıtlar: ekipler ne zaman uyarılmalı, istekler ne zaman durmalı? İkisini de takip edin. Bir katman yükseltmesi verim açabilir, ancak aylık maliyet sınırını yalnızca ayrı olarak yapılandırılmış bir sert limit zorlar.
Ekiplerin hangi ilgili araştırmaları okuması gerekir?
- Hız limitleri bir maliyet kontrolüdür
- Taahhütlü harcama, tahmininize yapılan bir bahistir
- Bir LLM maliyet artışı için üretim runbook'u
İlgili
Bunu kendi altyapınıza uygulamak mı istiyorsunuz? Sağlayıcı faturalarını, ağ geçidi kayıtlarını ve ana iş akışlarını getirin; maliyet etkenlerini ve tasarruf yolunu çıkaralım. Ücretsiz denetim planlayın →