aidoc.uz

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#

KodMa'nosiNima qilish kerak
400So'rov formati xato (masalan, sxema noto'g'ri)Kodni tekshiring, qayta urinishning foydasi yo'q
401API kalit noto'g'ri yoki yo'qKalitni tekshiring, qayta urinishning foydasi yo'q
403Kalit bor, lekin bu amalga ruxsat yo'qLoyiha/tashkilot sozlamalarini tekshiring
404So'ralgan resurs (masalan, model nomi) topilmadiModel nomini yoki endpoint'ni tekshiring
429So'rov limiti oshdi (rate limit)Kutib, qayta urining (pastda ko'ramiz)
500/503OpenAI tomonidagi vaqtinchalik muammoBiroz kutib, qayta urining

2. Nega 429 chiqadi: uch xil limit#

Rate limit — bitta emas, uchta alohida chegara:

RPM — daqiqasiga so'rovlar soni
Juda tez-tez so'rov yuborsangiz ishga tushadi
TPM — daqiqasiga token soni
Kam sonli, lekin juda uzun so'rovlar ham shu chegaraga tegadi
Hisobning umumiy limiti
Hisob darajasiga (tier) bog'liq, vaqt o'tishi va foydalanish bilan oshadi

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:

  1. Har bir so'rovga max_output_tokens qo'ying. Sozlamasiz qolgan parametr — nazoratsiz xarajatning eng oson yo'li.
  2. Foydalanuvchi darajasida limit belgilang. Bitta foydalanuvchi (yoki bitta buglik kod) cheksiz so'rov yubormasin — o'z tizimingizda soatlik/kunlik chegara qo'ying.
  3. usage maydonini 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#

BelgiSababYechim
429 tez-tez chiqadiTier limitingizdan yuqori tezlikda so'rov yuborilmoqdaNavbat qo'shing, yoki hisob tier'ini oshirish sharoitlarini tekshiring
Qayta urinish cheksiz cho'ziladimax_urinish chegarasi yo'q yoki juda kattaAniq chegara qo'ying, oxirgi urinishdan keyin xatoni yuqoriga uzating
Xarajat kutilmaganda oshib ketdimax_output_tokens yo'q yoki foydalanuvchi cheksiz so'rov yuborganIkkalasini ham qo'shing, spending limit o'rnating
Bir nechta foydalanuvchi bir-birining so'rovini "bloklaydi"Umumiy tier limiti barcha foydalanuvchilar orasida bo'linadiNavbat tizimi yoki foydalanuvchi darajasidagi kvota qo'shing
Yodda saqlang
  • 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.
Amaliy topshiriq

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.