Poziomy użycia API OpenAI wyjaśnione: Build, Launch, Grow i limity wydatków
Zaktualizowano October 7, 2026 · pierwsza publikacja October 7, 2026
OpenAI uprościło płatne poziomy API do Build, Launch i Grow 6 października 2026 roku. Organizacje awansują automatycznie, gdy skumulowane zakupy kredytów przekroczą każdy próg, co zwykle odblokowuje wyższe limity szybkości. Poziom jest sygnałem pojemności i miesięcznego limitu użycia; jest odrębny od limitów wydatków na poziomie projektu lub organizacji, które trzeba skonfigurować jako kontrole budżetowe.
Co zmieniło się w poziomach użycia API OpenAI?
Z changelogu z 6 października OpenAI wynika, że platforma API przeszła z pięciu płatnych poziomów na trzy: Build, Launch i Grow. Obowiązujący przewodnik po limitach szybkości wymienia te progi kwalifikacji: Build przy $5, Launch przy $100 i Grow przy $500 łącznych zakupach kredytów. Podaje też miesięczny limit użycia $100 dla uprawnionych użytkowników darmowego poziomu. OpenAI wskazuje, że wyższe poziomy zwykle otrzymują wyższe limity szybkości dla modeli.
Kwoty zakupów to skumulowane progi, według których ustala się kwalifikację do poziomu. Nie są miesięczną ceną subskrypcji ani obietnicą, że Twoja organizacja będzie wydawać dokładnie tę kwotę co miesiąc. Opublikowany przewodnik opisuje je jako łączne zakupy kredytów. Sprawdź w panelu organizacji rzeczywisty poziom, zatwierdzony miesięczny limit użycia i limity dla poszczególnych modeli; do planowania operacyjnego liczy się status Twojej organizacji.
Co wyższy poziom daje zespołowi?
Limity szybkości mogą ograniczać liczbę żądań na minutę (RPM), tokenów na minutę (TPM), wolumen dzienny, przepustowość obrazów lub kolejkowane zadania Batch. Zadanie może mieścić się w miesięcznym limicie użycia i mimo to trafić w limit na minutę. Aktualny przewodnik pokazuje różnice zależne od modelu: dla GPT-6 Astra, Sol i Terra standardowe przykłady RPM/TPM rosną z 5,000 RPM i 1 miliona TPM na poziomie Build do 10,000 RPM i 4 milionów TPM na poziomie Launch oraz 15,000 RPM i 40 milionów TPM na poziomie Grow. Podane standardowe limity dla GPT-6 Luna znów się różnią. To opublikowane wartości referencyjne, a nie zamiennik limitów widocznych dla Twojej organizacji, modelu i projektu.
Ta różnica ma znaczenie podczas uruchomień produktów. Zespół może przewidzieć wystarczający miesięczny limit, a mimo to zostać ograniczony, gdy nowe obciążenie wysyła ruch zbyt szybko albo przekracza przepustowość żądań lub tokenów. Limity szybkości mogą obowiązywać zarówno na poziomie organizacji, jak i projektu, a różne modele mogą współdzielić jeden limit. Zanim potraktujesz nazwę poziomu jako gwarancję pojemności, przeczytaj nagłówki odpowiedzi i panel.
Czy poziomy użycia to sposób na ograniczenie miesięcznych wydatków?
Nie. OpenAI dokumentuje zatwierdzone miesięczne limity użycia osobno od konfigurowalnych limitów wydatków organizacji lub projektu. Alert wydatków wysyła powiadomienie, a ruch API trwa dalej. Twardy limit wydatków blokuje dotknięte żądania odpowiedzią 429, gdy osiągnięta zostanie skonfigurowana kwota. Wybierz twardy limit, gdy egzekwowanie ma znaczenie; alert daje widoczność, a nie bezpiecznik.
Oznacza to także, że kupowanie kredytów, by przekroczyć próg poziomu, nie jest samo w sobie bezpieczną polityką kontroli kosztów. Poziom może poprawić przepustowość, ale nie zastąpi przypisania odpowiedzialności za projekt, kierowania alertów, prognozowania użycia ani świadomie ustawionego twardego limitu. Zespół inżynierski, który potrzebuje większej pojemności na start, powinien modelować zarówno próg zakupu potrzebny do kwalifikacji, jak i odrębny miesięczny sufit wydatków, który Finanse chcą egzekwować.
Jak Finanse i inżynieria powinny zarządzać podnoszeniem poziomu?
- Zinwentaryzuj organizację i projekty. Zapisz poziom, miesięczny limit użycia, RPM/TPM dla poszczególnych modeli, wspólne limity i właścicieli każdego projektu produkcyjnego.
- Ustaw jawne kontrole wydatków. Skonfiguruj twarde limity na poziomie projektu tam, gdzie ruch ma się zatrzymać przy stałym budżecie, a alerty tam, gdzie zespoły potrzebują wczesnego ostrzeżenia. Nie zakładaj, że limit poziomu zapewnia tę kontrolę.
- Oszacuj narastanie obciążenia. Prognozuj żądania i tokeny na minutę oraz miesięczne wydatki na tokeny. Usługa może trafić w limit przepustowości długo przed miesięcznym sufitem w dolarach.
- Kontroluj zakupy związane z poziomami. Traktuj dodatkowe zakupy kredytów, które przesuwają skumulowany próg, jak decyzję o dostępie i pojemności. Przed wnioskiem wymagaj prognozy obciążenia, właściciela i przeglądu istniejących kontroli.
- Obserwuj rzeczywistą odpowiedź. Użyj nagłówków limitów szybkości i logów, by odróżnić wyczerpanie limitu żądań, tokenów lub innych. Stosuj backoff przy tymczasowych odpowiedziach z limitem szybkości, zamiast tworzyć burzę ponowień.
Na przykład, hipotetycznie: zespół produktowy spodziewa się, że kampania startowa potroi żądania na minutę, ale miesięczne zużycie tokenów pozostanie poniżej sufitu Finansów. Pytanie operacyjne brzmi, czy RPM i TPM projektu dla danego modelu udźwigną ten wzrost. Pytanie finansowe brzmi, czy twardy limit wydatków jest ustawiony na zatwierdzonym budżecie kampanii. To powiązane przeglądy, ale różne kontrole.
Jak zespół ma zdecydować o przejściu z Build na Launch?
Zacznij od dowodów z obciążenia, a nie od nazwy poziomu. Jeśli logi produkcyjne pokazują powtarzające się wyczerpywanie limitów na obecnym poziomie, oszacuj potrzebny zapas RPM i TPM, ustal, które limity modelu i projektu mają zastosowanie, i potwierdź efekt poziomu w panelu. Następnie porównaj zakup kredytów potrzebny do kwalifikacji z wartością biznesową i polityką budżetową. Jeśli obecne limity wystarczają, podnoszenie poziomu tylko dlatego, że istnieje następny, nie daje żadnej korzyści operacyjnej.
OpenAI zauważa, że wyższe poziomy zwykle podnoszą limity, a opublikowane progi mogą się zmienić. Przed cyklem budżetowym lub istotną zmianą ruchu ponownie sprawdź przewodnik po limitach szybkości i panel. Przegląd alertów wydatków i twardych limitów trzymaj w tej samej miesięcznej rutynie FinOps co miks modeli, ponowienia i koszt na udane zadanie.
Jaki jest praktyczny wniosek?
Build, Launch i Grow odpowiadają na pytanie o pojemność: jakie limity i miesięczny zakres użycia mogą obowiązywać, gdy skumulowane zakupy organizacji rosną. Twoje kontrole wydatków odpowiadają na pytanie budżetowe: kiedy ostrzec zespoły, a kiedy zatrzymać żądania. Śledź oba. Podniesienie poziomu może odblokować przepustowość, ale tylko osobno skonfigurowany twardy limit wymusza granicę kosztów miesięcznych.
Jakie powiązane badania powinny przeczytać zespoły?
- Limity szybkości to kontrola kosztów
- Zobowiązane wydatki to zakład na Twoją prognozę
- Runbook produkcyjny dla skoku kosztów LLM
Powiązane
Chcesz zastosować to w swoim stosie? Przynieś faktury dostawców, logi bramy i najważniejsze przepływy pracy; wskażemy czynniki kosztów i ścieżkę oszczędności. Umów bezpłatny audyt →