4-qism · Production·11-bob
Xatolarni boshqarish, rate limit va narx
API sizga 'yo'q' deganda nima qilish kerak — qayta urinish strategiyasi, uch xil limitni tushunish, xarajatni nazoratda ushlash va tier tizimi.
Lokal skriptda API chaqiruvi ishlamay qolsa, dastur shunchaki to'xtaydi va siz xatoni terminal orqali ko'rasiz. Production'da esa — bu haqiqiy foydalanuvchi haqiqiy vaqtda kutayotgan so'rov. Xatoni kutish va to'g'ri javob berish — hobbi loyiha bilan production tizim orasidagi asosiy farq.
1. Eng keng tarqalgan xato turlari#
| Kod | Ma'nosi | Nima qilish kerak |
|---|---|---|
400 | So'rov formati xato (masalan, sxema noto'g'ri) | Kodni tekshiring, qayta urinishning foydasi yo'q |
401 | API kalit noto'g'ri yoki yo'q | Kalitni tekshiring, qayta urinishning foydasi yo'q |
403 | Kalit bor, lekin bu amalga ruxsat yo'q | Loyiha/tashkilot sozlamalarini tekshiring |
404 | So'ralgan resurs (masalan, model nomi) topilmadi | Model nomini yoki endpoint'ni tekshiring |
429 | So'rov limiti oshdi (rate limit) | Kutib, qayta urining (pastda ko'ramiz) |
500/503 | OpenAI tomonidagi vaqtinchalik muammo | Biroz kutib, qayta urining |
2. Nega 429 chiqadi: uch xil limit#
Rate limit — bitta emas, uchta alohida chegara:
Qaysi limitga tegib ketganingiz javobdagi xato xabarida ko'rsatiladi — uni o'qing, taxmin qilmang.
3. Tier tizimi — limitlar vaqt bilan o'sadi#
Yangi hisob kichik limit bilan boshlanadi va muvaffaqiyatli to'lovlar tarixi hamda vaqt bilan asta-sekin yuqoriroq "tier" (daraja)ga o'tkaziladi, bu esa yuqoriroq RPM/TPM limitini anglatadi. Bu — spam va suiiste'molning oldini olish uchun. Amaliy xulosa: agar loyihangiz katta hajmda so'rov yuborishi kutilsa, buni oldindan rejalashtiring — "birdaniga" yuqori tier'ga o'tib bo'lmaydi, u vaqt va foydalanish tarixi bilan asta-sekin ochiladi. Joriy limitlaringizni har doim platform.openai.com hisobingiz sozlamalaridan tekshiring.
4. Qayta urinish strategiyasi: eksponensial orqaga chekinish#
Xato chiqdi deb darhol qayta yubormang — bu limitni yanada yomonlashtiradi. To'g'ri yondashuv: har bir muvaffaqiyatsiz urinishdan keyin kutish vaqtini ikki baravar oshirish (eksponensial orqaga chekinish, exponential backoff):
import time
import random
from openai import APIStatusError
def sorov_qayta_urinish_bilan(fn, max_urinish=5):
for urinish in range(max_urinish):
try:
return fn()
except APIStatusError as e:
if e.status_code not in (429, 500, 503):
raise # qayta urinishning foydasi yo'q xatolar — darhol tashlaymiz
if urinish == max_urinish - 1:
raise # oxirgi urinish ham muvaffaqiyatsiz — endi tashlaymiz
kutish = (2 ** urinish) + random.uniform(0, 1) # 1, 2, 4, 8... soniya + tasodifiy qo'shimcha
print(f"Xato ({e.status_code}), {kutish:.1f} soniyadan keyin qayta urinaman...")
time.sleep(kutish)
javob = sorov_qayta_urinish_bilan(
lambda: client.responses.create(model="gpt-4o-mini", input="Salom!")
)random.uniform(0, 1) qo'shilishi tasodifiy emas — agar minglab
foydalanuvchi bir vaqtda xato olib, hammasi aynan bir xil vaqtda
qayta urinsa, server yana zarba oladi. Kichik tasodifiylik bu
"to'lqin"ni tarqatadi. Bu texnika jitter deb ataladi.
5. So'rovlarni navbatga qo'yish (queueing) — ko'p foydalanuvchili tizimlar uchun#
Agar ilovangiz bir vaqtda ko'p foydalanuvchidan so'rov qabul qilsa, ularning barchasini bir zumda OpenAI'ga "otib yuborish" TPM/RPM limitiga tez tegib qoladi. Buning o'rniga so'rovlarni navbat (masalan, Redis yoki oddiy ichki navbat) orqali, belgilangan tezlikda yuborish kerak bo'ladi:
import queue
import threading
import time
sorovlar_navbati = queue.Queue()
def ishchi():
while True:
vazifa = sorovlar_navbati.get()
if vazifa is None:
break
fn, natija_qaytarish = vazifa
natija = sorov_qayta_urinish_bilan(fn)
natija_qaytarish(natija)
time.sleep(0.5) # daqiqasiga taxminan 120 so'rovdan oshmaslik uchun sun'iy kechikish
threading.Thread(target=ishchi, daemon=True).start()Bu — soddalashtirilgan misol; production tizimda odatda maxsus navbat kutubxonasi (masalan, Celery, BullMQ) yoki bulutli navbat xizmati ishlatiladi.
6. Xarajatni nazoratda ushlash#
Uch amaliy qoida:
- Har bir so'rovga
max_output_tokensqo'ying. Sozlamasiz qolgan parametr — nazoratsiz xarajatning eng oson yo'li. - Foydalanuvchi darajasida limit belgilang. Bitta foydalanuvchi (yoki bitta buglik kod) cheksiz so'rov yubormasin — o'z tizimingizda soatlik/kunlik chegara qo'ying.
usagemaydonini kuzating va logga yozing. Har bir javobda qancha token sarflanganini saqlab boring — oyning oxirida "nega hisobim shuncha chiqdi" degan savolga javob shu logdan chiqadi.
response = client.responses.create(model="gpt-4o-mini", input="...", max_output_tokens=500)
# Har bir so'rovni logga yozib boring
log_yozuv = {
"vaqt": time.time(),
"model": response.model,
"input_token": response.usage.input_tokens,
"output_token": response.usage.output_tokens,
"foydalanuvchi_id": "12345", # kimning so'rovi ekanini bilish uchun
}Bundan tashqari, platform.openai.com hisobingizda xarajat chegarasi (spending limit) o'rnatish mumkin — bu belgilangan summadan o'tilganda hisobni avtomatik to'xtatadi. Bu — dasturiy xatolik yoki kutilmagan foydalanish natijasida hisobingiz "portlab ketishi"dan himoya qiladigan so'nggi chegara.
7. Sinov (test) muhitida xatoni qasddan chaqirish#
Production kodini joylashtirishdan oldin, xato boshqaruvingiz haqiqatan
ishlashini tekshiring — atay noto'g'ri kalit yoki juda katta
max_output_tokens bilan sinab ko'ring. Xato kelganda dastur qulab
tushmasligi, foydalanuvchiga tushunarli xabar ko'rsatishi kerak
("Hozircha band, biroz keyin urinib ko'ring" — "Internal Server Error"
emas).
8. Nima noto'g'ri ketishi mumkin#
| Belgi | Sabab | Yechim |
|---|---|---|
| 429 tez-tez chiqadi | Tier limitingizdan yuqori tezlikda so'rov yuborilmoqda | Navbat qo'shing, yoki hisob tier'ini oshirish sharoitlarini tekshiring |
| Qayta urinish cheksiz cho'ziladi | max_urinish chegarasi yo'q yoki juda katta | Aniq chegara qo'ying, oxirgi urinishdan keyin xatoni yuqoriga uzating |
| Xarajat kutilmaganda oshib ketdi | max_output_tokens yo'q yoki foydalanuvchi cheksiz so'rov yuborgan | Ikkalasini ham qo'shing, spending limit o'rnating |
| Bir nechta foydalanuvchi bir-birining so'rovini "bloklaydi" | Umumiy tier limiti barcha foydalanuvchilar orasida bo'linadi | Navbat tizimi yoki foydalanuvchi darajasidagi kvota qo'shing |
- 01401/400/404 — qayta urinmang, sababni tuzating. 429/5xx — eksponensial kutish (jitter bilan) qayta urining.
- 02Uch xil rate limit bor: RPM, TPM va hisobning umumiy limiti — qaysinisi tegganini xato xabaridan bilib oling.
- 03Tier — vaqt va foydalanish tarixi bilan o'sadi, oldindan rejalashtiring.
- 04max_output_tokens har doim belgilang, spending limit o'rnating — bu ikkovi eng oddiy va samarali xarajat nazorati.
- 05usage ma'lumotini har bir so'rovda logga yozib boring.
Qayta urinish mantig'ini sinab ko'ring
4-bo'limdagi sorov_qayta_urinish_bilan funksiyasini haqiqiy API
chaqirmasdan sinab ko'ring: xatoni simulyatsiya qiluvchi soxta (mock)
funksiya yozib, qayta urinish sanog'i va kutish vaqtlari to'g'ri
ishlashini isbotlang.
Maslahatni ko'rsatish
APIStatusError'ni qo'lda ko'tarish uchun mock (soxta) funksiya yozing — u dastlabki 2 marta 429 xatosini, 3-marta muvaffaqiyatli natijani qaytarsin. sorov_qayta_urinish_bilan funksiyasi shu holatda to'g'ri ishlashini tekshiring.