Ana içeriğe atla
OpenAI

13 Şubat 2026

Mühendislik

Hız sınırlarının ötesinde: Codex ve Sora'ya erişimi artırma

Jonah Cohen, Teknik Personel Üyesi

Yükleniyor...

Geçtiğimiz yıl içinde hem Codex hem de Sora hızla benimsenmiş ve kullanımları başlangıçta beklediğimizin çok ötesine geçmiştir. Tutarlı bir model gördük: Kullanıcılar hemen işe koyuluyor, gerçek bir değer buluyor ve ardından kullanım sınırlamalarına takılıyor.

Hız limitleri, talebi dengelemeye ve adil erişimi sağlamaya yardımcı olabilir ancak kullanıcılar değer elde ederken ani bir duraklama sinir bozucu olabilir. Kullanıcıların devam etmesini sağlarken sistem performansını ve yaklaşımımıza duyulan güveni koruyacak bir yol istedik.

Bunu çözmek için kullanımı sayan bir gerçek zamanlı erişim motoru oluşturduk. Bu motorun katmanlarından biri de kredi satın alma yeteneğidir. Kullanıcılar hız limitlerini aştığında kredi bakiyelerini harcayarak ürünlerimizi kullanmaya devam edebilirler.

Bunun arkasında sınırları, gerçek zamanlı kullanım takibini ve kredi bakiyelerini tek bir erişim modelinde birleştiren karmaşık bir sistem yer alıyor. Bu yazıda Codex ve Sora'nın ölçeklendirilmesi için erişim kontrolünün yeniden düşünülmesinin neden gerekli olduğu, kanıtlanabilir şekilde doğru olan gerçek zamanlı bir sistemin istek başına hız sınırlarını ve kredileri nasıl harmanladığı ve bu temelin artık her iki ürün için ek erişim imkanı sağladığı ele alınmaktadır.

Mevcut erişim modelleri neden yetersiz kalıyor?

Genel bir bakışla, geleneksel erişim modelleri genellikle bir seçim yapmaya zorlar:

  • Oran sınırları başlangıçta faydalı olabilir ama bittiği zaman kullanıcıları kötü bir deneyimle baş başa bırakır: "Daha sonra tekrar gelin"
  • Kullanıma dayalı faturalandırma esneklik sunar, ancak kullanıcılar ilk token'dan itibaren ödeme yapar. Bu da erken dönem keşif için ideal değildir

Codex ve Sora için, ikisi de tek başına yeterli değildi. Sadece oran sınırlarını yükseltirsek önemli talep dengeleme ve adalet kontrollerini kaybeder ve herkese hizmet verecek kapasitemizi yitiririz. Tamamen eş zamansız kullanım faturalandırmasına güvenirsek gecikme, aşım veya mutabakat sorunları ortaya çıkar. Bu da tam da kullanıcıların en çok etkileşimde oldukları anda fark ettikleri türden sorunlardır.

Bunun yerine bize gereken şey, gerçek zamanlı limitlerle kullandıkça öde erişimini birleştiren tek bir hibrit sistemdi:

"Rate-limits" ve "Credits" etiketli iki düğme içeren bir kontrol paneli kullanıcı arayüzü ve altında "Rate-Limit with Credit Fallback." başlıklı bir kart.

Bu sistem şunları yapmak zorundaydı:

  • Hız limitlerini ulaşılana kadar uygula
  • Aynı istek içinde sorunsuz bir şekilde kredilere geçiş yap
  • Bu kararı gerçek zamanlı olarak verin
  • Kredi tüketimini takip ederken titizlikle doğru ve denetlenebilir olun

Kapı değil, şelale gibi erişim

Yaptığımız temel kavramsal değişimlerden biri, erişimi bir karar akışı olarak modellemekti. "Buna izin var mı?" diye sormak yerine, şunu soruyoruz: "Ne kadarına izin veriliyor ve nereden?" Kullanım sayılırken sistem şu sırayı izler:

Özelliklerimize erişimi değerlendirmek amacıyla karar ağacı

Bu model, kullanıcıların ürünü gerçekte nasıl deneyimlediklerini yansıtmaktadır. Kullanım sınırları, ücretsiz katmanlar, krediler, promosyonlar ve kurumsal haklar, aynı karar yığınında yer alan katmanlarıdır. Bir kullanıcının bakış açısından "sistem değişmiyor". Sadece Codex ve Sora'yı kullanmaya devam ediyorlar. Bu yüzden krediler görünmez gibi gelir: Sadece şelalede olan başka bir unsurdur.

Bunu neden kendi bünyemizde geliştirdik?

Kredi tüketimini yönetmek amacıyla üçüncü taraf kullanım faturalandırma ve ölçüm platformlarını değerlendirdik. Faturalandırma ve raporlama için oldukça uygun olsalar da iki kritik gereksinimi karşılamıyorlar:

Gerçek zamanlı doğruluk

Bir kullanıcı bir sınıra ulaştığında ve kullanılabilir kredisi varsa sistem bunu derhal bilmelidir. En iyi çaba veya gecikmeli sayım, beklenmedik engeller, tutarsız bakiyeler ve yanlış ücretlendirmeler olarak kendini gösterir. Codex ve Sora gibi etkileşimli ürünlerde bu tür hatalar göze çarpar, bu da can sıkıcı olur.

Mutabakat yapılabilirlik ve güven

Ayrıca her bir sonucun şeffaflığını sağlamamız gerekiyordu:

  • Bir isteğin neden kabul verildiği veya engellendiği
  • Ne kadar kullanım yapıldığı
  • Hangi sınırlamalar veya dengelerin uygulandığı

Bu yetenek, olan bitenin sadece bir parçasını gören ayrı bir kullanım faturalandırma platformunda tek başına çözülmek yerine, karar verme sürecimize sıkı bir şekilde entegre edilmeliydi. Kullanıcıların güvenini zedelemeden ürünlerimize erişim sağlamaları için doğruluk, zamanlama ve gözlemlenebilirlik üzerinde tam kontrole sahip olmamız gerekiyordu. Bu da bizi dahili bir çözüme yönlendirdi.

Yüksek ölçekli kullanım ve bakiye sistemi oluşturma

Bunu sağlamak için, eş zamanlı erişim kararlarına yönelik özel olarak tasarlanmış dağıtık bir kullanım ve bakiye sistemi geliştirdik.

Yüksek düzeyde, sistem:

  • Kullanıcı başına ve özellik başına kullanım izler
  • İstek limiti pencerelerini korur
  • Gerçek zamanlı kredi bakiyelerini güncel tutar
  • Akış tabanlı bir eş zamansız işlemci aracılığıyla borç bakiyelerini denk güçler olarak ele alıp işler

Her istek, oran sınırlarından eş zamanlı olarak tüketip gerekirse yeterli kredinin olup olmadığını doğrulayarak ne kadar kullanımın izin verileceğine dair gerçek zamanlı bir karar verir. Ardından herhangi bir kredi borcunu eş zamansız olarak kapatırken kesin bir sonuç döndürür. Böylelikle ürünler arasında tutarlı davranış garanti edilir ve ekipler arasında yinelenen mantık ortadan kalkar.

Erişim sistemi: Gerçek zamanlı hız limitleri ile eş zamansız kredi ve bakiye takibini birleştirme.

Doğruluğu kanıtlanabilir bir faturalama sistemi

Bu sistemin temel tasarım ilkelerinden biri, faturalandırmamızın doğru olduğunu ispat edebilmemiz gerektiğidir. Bu bizim kurumsal müşterilerle başlayan kredi desteğimizin kökenini yansıtıyor. Yukarıdaki sistem diyagramında birbirine bağlı üç ayrı veri kümesi bulunmaktadır:

  • Ürün kullanım olayları: Kullanıcının gerçekten yaptığı şey
  • Para kazanma olayları: Kullanıcıdan kullanım için ne ücret aldığımız
  • Bakiye güncellemeleri: Kullanıcının kredi bakiyesini ne kadar güncellediğimiz ve nedenini açıkladık

Bu veri kümeleri sıradan bir yan ürün değildir; aslında sistemi yönlendirir ve her veri kümesi bir sonrakini tetikler. Gerçekleşen olayları, ilişkili ücretleri ve tahsil ettiğimiz tutarları ayırarak, her katmanı bağımsız olarak denetleyebilir, tekrar oynatabilir ve mutabakatını sağlayabiliriz. Bu, kanıtlanabilir doğruluğa öncelik verdiğimiz için kredi bakiyesi güncellemelerinin biraz gecikmesine neden olan bilinçli bir tercihtir. Bunu nasıl başardık?

  • Ürün kullanım olayları, kredi tüketimini etkileyip etkilemediğine bakılmaksızın tüm kullanıcı faaliyetleri için yayınlanır. Bu da kullanıcı etkinlikleri için bir denetim izi sağlar ve kredileri neden tahsil ettiğimizi veya etmediğimizi açıklamamıza olanak tanır.
  • Her olayda sabit bir idempotency (denk güçlülük) anahtarı vardır. Bu nedenle yeniden denemeler, yeniden oynatmalar veya işçi yeniden başlatmaları bir bakiyeyi hiçbir zaman iki kez borçlandırmaz, böylece çift ücretlendirme önlenir. Bu sayede çalışmamızı çevrimdışı doğrulamak için toplu bir mutabakat çalıştırabiliriz.
  • Bir denetim izi oluşturmak amacıyla senkron güncellemeler yerine eş zamanlı olmayan (ancak yine de neredeyse gerçek zamanlı) bakiye güncellemeleri yapıyoruz. Sistemin düzgün çalıştığını kanıtlayabilmek ve kullanıcılarımıza yanlış faturalandırma yapmadığımız konusunda güvence verebilmek için kullanıcının bakiyesini güncellemede küçük bir gecikmeye izin veriyoruz. Bu kısa gecikme, bir kullanıcının kredi bakiyesini aşmamıza neden olduğunda, bakiyeyi otomatik olarak iade ederiz. Katı uygulama yerine kanıtlanabilir doğruluğu ve kullanıcı güvenini tercih ederiz.
  • Kredi Bakiyesini azaltır ve tek bir atomik veritabanı işlemiyle Bakiye Güncellemesi kaydı ekleriz. Bakiye güncellemeleri hesap bazında sıralanır, bu nedenle eş zamanlı istekler aynı kredileri harcamak için asla yarışamaz. Bakiye Güncellemesi kaydı, hem borç tutarını hem de güncellemeyi tetikleyen para kazanma olayına atıfta bulunur, bunu tek bir veritabanı işlemi içinde sarmak, kredi bakiyesindeki her düzeltme için bir denetim izi sağlamamızı garanti eder.

Tüm bu titizlik tek bir amacı destekler: Erişimi kolay ve güvenli kılmak. İnsanlar bir şeyler oluştururken veya kod yazarken, bir isteğin işleme alınıp alınmayacağını, fazla ücretlendirilip ücretlendirilmeyeceklerini ya da bakiyelerinin doğru olup olmadığını düşünmek zorunda kalmamalıdır. Kullanım, faturalama ve bakiyeleri kanıtlanabilir şekilde doğru hale getirerek kullanıcıların deneyimlerini kesintiye uğratmayan bir sistem sunuyoruz. Bu sayede ani duraklamalar olmadan sürekli erişim sağlayabiliriz ve bu da kredileri sadece faturada değil, gerçek işlerin ortasında da kullanılabilir kılıyor.

Hareketin hizmetinde mimari

Yaklaşımımızın temel ilkesi, kullanıcının hızını korumaktır. Her mimari karar, kullanıcıya dönük bir sonuca karşılık gelir: Gerçek zamanlı bakiyeler gereksiz kesintileri önler, atomik tüketim çift ücretlendirmeyi engeller ve birleşik erişim mantığı öngörülebilir davranışlar sağlar. Sonuç olarak, insanlar ani duraklamalar veya erken plan değişiklikleriyle karşılaşmadan daha uzun süre çalışabilir, daha derinlemesine keşif yapabilir ve projeleri daha ileriye taşıyabilir.

Kullanıcılar etkileşimdeyken sistem, onların devam etmelerine yardımcı olmalı, engel olmamalıdır. Sınırlar ve krediler arka planda kayboluyor.

Bu deneyimi oluşturmak, erişim, kullanım ve faturalandırmayı tek bir sistem olarak yeniden düşünmeyi ve doğruluğu birinci sınıf bir ürün özelliği olarak ele alan bir altyapı kurmayı gerektirdi. Aynı temel zamanla daha fazla ürüne yayılabilir. Codex ve Sora sadece başlangıçtır.

Yazar

Jonah Cohen

Teşekkürler

Kredileri geliştiren tüm FinEng ekibine özel teşekkürler.