Пређите на главни садржај
OpenAI

13. фебруар 2026.

Инжењеринг

Iza rate limit-a: skaliranje pristupa za Codex i Sora

Piše Jonah Cohen, član tehničkog osoblja

Учитавање…

Tokom protekle godine, i Codex i Sora beleže brzo usvajanje, a korišćenje je ubrzo premašilo ono što smo prvobitno očekivali. Videli smo dosledan obrazac: korisnici urone, pronađu stvarnu vrednost, a zatim naiđu na rate limits.

Rate limits mogu pomoći da se ublaži potražnja i obezbedi pravičan pristup; međutim, kada korisnici dobijaju vrednost, nailazak na čvrsto zaustavljanje može biti frustrirajuć. Želeli smo način da korisnici mogu da nastave, uz zaštitu performansi sistema i poverenja korisnika u naš pristup.

Da bismo to rešili, napravili smo mehanizam pristupa u realnom vremenu koji broji upotrebu. Jedan od slojeva u tom mehanizmu je mogućnost kupovine kredita. Kada korisnici premaše svoje rate limits, krediti im omogućavaju da nastave da koriste naše proizvode trošenjem svog kreditnog salda.

Ispod toga je složen sistem koji spaja ograničenja, praćenje upotrebe u realnom vremenu i kreditna salda u jedan model pristupa. Ovaj tekst objašnjava zašto je skaliranje Codex i Sora zahtevalo novo promišljanje kontrole pristupa, kako proverljivo ispravan sistem u realnom vremenu kombinuje rate limits i kredite po zahtevu i kako ta osnova sada otključava dodatni pristup za oba proizvoda.

Zašto postojeći modeli pristupa nisu bili dovoljni

Kada pogledamo širu sliku, tradicionalni modeli pristupa obično nameću izbor:

  • Rate limits mogu biti korisni u početku, ali korisnicima ostavljaju loše iskustvo kada ih potroše: „vratite se kasnije“
  • Naplata zasnovana na upotrebi je fleksibilna, ali korisnici plaćaju od prvog tokena — što nije idealno za podršku ranom istraživanju

Za Codex i Sora, nijedan od ta dva pristupa sam po sebi nije bio dovoljan. Ako bismo jednostavno povećali rate limits, izgubili bismo važnu kontrolu nad ublažavanjem potražnje i pravičnošću i ostali bez kapaciteta da svima pružimo uslugu. Ako bismo se u potpunosti oslonili na asinhronu naplatu po upotrebi, uveli bismo kašnjenje, prekoračenja ili probleme sa usklađivanjem — upravo one vrste problema koje korisnici primete kada su najviše angažovani.

Umesto toga, bio nam je potreban jedinstven hibridni sistem koji kombinuje ograničenja u realnom vremenu sa pristupom po potrošnji:

Kontrolna tabla sa dva dugmeta označena „Rate-limits“ i „Credits“ i karticom ispod pod nazivom „Rate-Limit with Credit Fallback“.

Ovaj sistem je morao da:

  • Sprovodi rate limits dok se ne dostignu
  • Besprekorno pređe na kredite u okviru istog zahteva
  • Donosi tu odluku u realnom vremenu
  • Bude rigorozno tačan i podložan reviziji pri praćenju potrošnje kredita

Pristup kao vodopad odluka, a ne kapija

Jedna od ključnih konceptualnih promena koje smo uveli bila je modelovanje pristupa kao vodopada odluka. Umesto da pitamo „da li je ovo dozvoljeno?“, pitamo „koliko je dozvoljeno i odakle?“ Kada broji upotrebu, sistem prolazi kroz sledeći niz:

Stablo odluka za procenu pristupa našim funkcijama

Ovaj model odražava kako korisnici zaista doživljavaju proizvod. Rate limits, besplatni nivoi, krediti, promocije i enterprise prava su samo slojevi u istom nizu odluka. Iz perspektive korisnika, oni ne „menjaju sisteme“ — oni jednostavno nastavljaju da koriste Codex i Sora. Zato krediti deluju nevidljivo: oni su samo još jedan element u vodopadu.

Zašto smo ovo napravili interno

Procenjivali smo platforme trećih strana za naplatu po upotrebi i merenje kako bi upravljale potrošnjom kredita. One su prikladne za fakturisanje i izveštavanje, ali nisu ispunile dva ključna zahteva:

Ispravnost u realnom vremenu

Kada korisnik dostigne ograničenje i ima dostupne kredite, sistem to mora znati odmah. Brojanje po principu najboljeg napora ili sa kašnjenjem pojavljuje se kao neočekivane blokade, nedosledna salda i netačne naplate. Za interaktivne proizvode kao što su Codex i Sora, ti propusti postaju vidljivi i frustrirajući.

Uskladivost i poverenje

Takođe nam je bilo potrebno da ponudimo transparentnost za svaki ishod:

  • Zašto je zahtev dozvoljen ili blokiran
  • Koliko je upotrebe potrošio
  • Koja ograničenja ili salda su primenjena

Ova mogućnost je morala biti tesno integrisana u naš vodopad odluka, umesto da se rešava izolovano na zasebnoj platformi za naplatu po upotrebi koja vidi samo jedan deo onoga što se dešava. Da bismo korisnicima omogućili pristup našim proizvodima bez ugrožavanja poverenja, bila nam je potrebna potpuna kontrola nad ispravnošću, tajmingom i uvidom u sistem. To nas je usmerilo ka internom rešenju.

Izgradnja sistema za upotrebu i salda velikog obima

Da bismo to omogućili, izgradili smo distribuirani sistem za upotrebu i salda, posebno dizajniran za sinhrone odluke o pristupu.

Na visokom nivou, sistem:

  • Prati upotrebu po korisniku i po funkciji
  • Održava prozore rate limit-a
  • Održava kreditna salda u realnom vremenu
  • Terećenja salda obrađuje idempotentno kroz striming asinhroni procesor

Svaki zahtev prolazi kroz jednu putanju evaluacije koja u realnom vremenu donosi odluku o tome kolika je upotreba dozvoljena sinhronim trošenjem iz rate limits i, po potrebi, proverom da li ima dovoljno kredita; zatim vraća jedan konačan ishod, dok se sva terećenja kredita poravnavaju asinhrono. To obezbeđuje dosledno ponašanje kroz proizvode i uklanja dupliranu logiku među timovima.

Sistem pristupa: Kombinovanje rate limit-a u realnom vremenu i asinhronog praćenja kredita i salda.

Sistem naplate sa proverljivom ispravnošću

Jedan od ključnih principa dizajna ovog sistema jeste da moramo moći da dokažemo da je naša naplata ispravna. To odražava korene naše podrške za kredite, koja je potekla od enterprise korisnika. Na gornjem dijagramu sistema imamo tri odvojena skupa podataka koja su međusobno povezana:

  • Događaji upotrebe proizvoda: Šta je korisnik zapravo uradio
  • Događaji monetizacije: Šta korisniku naplaćujemo za njegovu upotrebu
  • Ažuriranja salda: Koliko smo prilagodili kreditno saldo korisnika i zašto

Ovi skupovi podataka nisu usputni nusproizvod; oni zapravo pokreću sistem, pri čemu svaki skup podataka pokreće sledeći. Odvajanje onoga što se dogodilo, svih povezanih troškova i onoga što smo teretili omogućava nam da nezavisno revidiramo, ponavljamo i usklađujemo svaki sloj. Ovo je namerni kompromis u kome prioritet dajemo proverljivoj ispravnosti, po cenu toga da ažuriranja kreditnog salda malo kasne. Evo kako smo to postigli:

  • Događaji upotrebe proizvoda objavljuju se za sve aktivnosti korisnika, bez obzira na to da li pokreću potrošnju kredita ili ne. To pruža revizorski trag za aktivnost korisnika i omogućava nam da objasnimo zašto smo kredite naplatili ili nismo naplatili.
  • Svaki događaj nosi stabilan ključ idempotentnosti, tako da ponovni pokušaji, ponovna izvršavanja ili restarti workera nikada ne mogu dvaput da terete saldo, čime se sprečava dvostruka naplata. To nam takođe omogućava da pokrenemo grupno usklađivanje kako bismo offline proverili svoj rad.
  • Radimo asinhrona (ali i dalje gotovo u realnom vremenu) ažuriranja salda umesto sinhronih ažuriranja kako bismo stvorili revizorski trag. Tolerisemo malo kašnjenje u ažuriranju korisničkog salda kako bismo mogli da dokažemo da sistem funkcioniše i uverimo korisnike da im ne naplaćujemo pogrešno. Kada zbog tog kratkog kašnjenja premašimo kreditno saldo korisnika, to automatski refundiramo; biramo proverljivu ispravnost i poverenje korisnika umesto striktne primene.
  • Smanjujemo Credit Balance i ubacujemo zapis Balance Update u okviru jedne atomske transakcije baze podataka. Ažuriranja salda se serializuju po nalogu, tako da konkurentni zahtevi nikada ne mogu istovremeno da potroše iste kredite. Zapis Balance Update sadrži i iznos terećenja i atribuciju nazad ka događaju monetizacije koji je pokrenuo ažuriranje; objedinjavanje ovoga u jednoj transakciji baze podataka garantuje da imamo revizorski trag za svako prilagođavanje kreditnog salda.

Sva ta rigoroznost podržava jedan cilj: da pristup bude jednostavan i bezbedan. Kada ljudi stvaraju ili kodiraju, ne bi trebalo da se pitaju da li će zahtev proći, da li će im biti previše naplaćeno ili da li je njihov saldo tačan. Time što upotrebu, naplatu i salda činimo proverljivo ispravnim, korisnicima pružamo sistem koji ne odvlači pažnju od njihovog iskustva. To nam omogućava da tvrda zaustavljanja zamenimo kontinuiranim pristupom — i to je ono što čini kredite upotrebljivim usred stvarnog rada, a ne samo na fakturi.

Arhitektura u službi zamaha

Vodeći princip našeg pristupa jeste zaštita zamaha korisnika. Svaka arhitektonska odluka mapira se nazad na ishod vidljiv korisniku: salda u realnom vremenu sprečavaju nepotrebne prekide, atomska potrošnja sprečava dvostruku naplatu, a objedinjena logika pristupa obezbeđuje predvidljivo ponašanje. Rezultat je da ljudi mogu da rade duže, istražuju dublje i odvedu projekte dalje bez suočavanja sa tvrdim zaustavljanjima ili prevremenim promenama plana.

Kada su korisnici angažovani, sistem treba da im pomogne da nastave, a ne da im staje na put. Ograničenja i krediti nestaju u pozadini.

Izgradnja takvog iskustva zahtevala je da pristup, upotrebu i naplatu iznova osmislimo kao jedinstven sistem i da izgradimo infrastrukturu koja tretira ispravnost kao proizvodnu funkciju prve klase. Ista osnova može se vremenom proširiti na više proizvoda; Codex i Sora su tek početak.

Аутор

Jonah Cohen

Zahvalnice

Posebna zahvalnost celom FinEng timu koji je napravio kredite.