Asosiy kontentga o‘tish
Innovialabs

LLM shlyuz: provayderlar o‘rtasida marshrutlash, fallback va limitlar

Chuqur4 daq

Qisqacha

LLM shlyuz — barcha AI chaqiruvlari o‘tadigan yagona ichki xizmat: u vazifaga mos modelni tanlaydi, nosozlikda provayderni almashtiradi, limit va byudjetlarni nazorat qiladi, kalit va loglarni bir joyda saqlaydi.

Shlyuz nima va u nima uchun kerak

LLM shlyuz — ilovalaringiz va model provayderlari orasidagi yupqa xizmat. Har bir servis to‘g‘ridan-to‘g‘ri OpenAI, Anthropic yoki Google’ga murojaat qilish o‘rniga, hammasi vazifa nomi bilan bitta ichki endpoint’ni chaqiradi. Shlyuz qaysi modeldan foydalanishni hal qiladi, xatoda so‘rovni qaytaradi yoki provayderni almashtiradi, limitlarni tekshiradi va nima bo‘lganini yozib boradi.

U sizda bittadan ortiq AI funksiya yoki bittadan ortiq provayder paydo bo‘lishi bilan kerak bo‘ladi. Usiz API kalitlari repozitoriylarga tarqalib ketadi, har bir jamoa o‘z retry’larini yozadi va hech kim X funksiya o‘tgan hafta qancha turganini ayta olmaydi.

Asosiy vazifalar

VazifaNima qiladi
Yagona APIBarcha provayderlar uchun bitta so‘rov formati
MarshrutlashModelni vazifa, narx, kechikish, ma’lumot maxfiyligi bo‘yicha tanlaydi
FallbackSo‘rovni qaytaradi va zaxira modelga o‘tadi
Limit va byudjetlarFoydalanuvchi, jamoa va funksiya uchun kvotalar
Kalitlarni boshqarishProvayder kalitlari faqat shlyuzda saqlanadi
KuzatuvchanlikLoglar, tokenlar, narx, kechikish, xatolar
KeshlashBir xil so‘rovlarga saqlangan javobni qaytaradi

Model nomi emas, vazifa bo‘yicha marshrutlash

Ilova aniq modelni emas, vazifa profilini so‘rashi kerak. Moslik konfiguratsiyada belgilanadi:

routes:
  classify-ticket:
    primary: small-fast-model
    fallback: [other-provider-small]
    max_output_tokens: 50
  draft-reply:
    primary: large-model
    fallback: [other-provider-large, small-fast-model]
    timeout_ms: 20000
  contract-analysis:
    primary: self-hosted-model
    fallback: []          # maxfiy ma’lumot, serverlarimizdan chiqmaydi

Shunday qilib funksiyani ilovani qayta reliz qilmasdan arzonroq yoki yangiroq modelga o‘tkazish mumkin. Marshrutlash uchun foydali signallar:

  • vazifa turi: oddiy tasniflash — kichik modelga, mulohaza talab qiladigan ish — kattasiga;
  • kirish hajmi: uzun hujjatlar — katta kontekst oynasiga ega modellarga;
  • ma’lumot maxfiyligi: shaxsga doir ma’lumotlar — faqat o‘z yoki tasdiqlangan modelga;
  • foydalanuvchi tarifi: pullik mijozlarga kuchliroq model berish mumkin.

Vaziyatni yomonlashtirmaydigan fallback’lar

Har bir xato qayta urinishga loyiq emas. Ularni ajrating:

  • Shu provayderda qayta urinish eksponensial kechikish va jitter bilan: taymautlar, 429, 5xx xatolar.
  • Provayderni almashtirish: takroriy nosozliklar yoki provayder nosog‘lom deb belgilangan.
  • Qayta urinmaslik: 400 validatsiya xatolari, kontent siyosati bo‘yicha rad etish, kontekstdan oshish. So‘rovni tuzating.

Circuit breaker qo‘shing: qisqa vaqtda bir necha xatodan so‘ng provayderga trafik yuborishni bir muddat to‘xtating va uni vaqti-vaqti bilan tekshirib turing. Shunda sekin avariya barcha taymautlaringizni yeb qo‘ymaydi.

Ikkita ogohlantirish:

  • bir modelga moslangan promptlar boshqasida boshqacha ishlashi mumkin, shuning uchun har bir fallback’ni o‘z eval to‘plamingizda tekshiring;
  • streaming’da birinchi token foydalanuvchiga yetib bormaguncha almashtirish xavfsiz.

Limit va byudjetlar

Provayderlar sizni daqiqasiga so‘rov va tokenlar bo‘yicha cheklaydi. Shlyuz esa sizning foydalanuvchilaringizni cheklashi kerak, toki bitta mijoz yoki tsiklga tushgan skript umumiy kvotani tugatib qo‘ymasin.

  • Rate limit: foydalanuvchiga daqiqasiga so‘rov va tokenlar, Redis yoki shunga o‘xshash xotirada token bucket.
  • Byudjetlar: foydalanuvchi, jamoa va funksiya bo‘yicha kunlik yoki oylik xarajat. Chaqiruvdan oldin narxni kirish tokenlari va chiqish limiti bo‘yicha baholang, keyin haqiqiysini yozing.
  • Yumshoq va qattiq limit: yumshoqda arzonroq modelga o‘tkazing, qattiqda tushunarli xabar bilan rad eting.
  • Chiqishni cheklash: har bir marshrut uchun javobning maksimal uzunligini doim belgilang.

Kalitlar va loglash

Provayder kalitlari faqat shlyuzda, maxfiy ma’lumotlar menejerida saqlanadi va hech qachon mijoz ilovalarida bo‘lmaydi. Ilovalar shlyuzga alohida bekor qilinadigan o‘z ichki kalitlari bilan kiradi.

Har bir so‘rov uchun loglang: marshrut, model, provayder, foydalanuvchi va funksiya ID’si, kirish va chiqish tokenlari, narx, kechikish, holat va fallback yo‘li. Prompt va javob matnlarini faqat siyosat ruxsat bergan joyda, shaxsiy ma’lumotlarni yashirib va qisqa muddatga saqlang.

O‘zingiz yozasizmi yoki tayyorini olasizmi

Open-source va bulutli shlyuzlar yagona API, fallback va xarajat hisobini allaqachon qo‘llab-quvvatlaydi. Mos kelsa, tayyorini oling; maxsus marshrutlash qoidalari, qat’iy ma’lumot lokalizatsiyasi yoki billing bilan chuqur integratsiya kerak bo‘lsa, o‘z yupqa qatlamingizni yozing. Ikkala holatda ham marshrut konfiguratsiyasini versiyalarni boshqarish tizimida saqlang.

Ko‘p uchraydigan xatolar

  • Model nomlari ilova kodiga qattiq yozilgan.
  • Qayta urinib bo‘lmaydigan xatolarni takrorlash va xarajatni ko‘paytirish.
  • Zaxira modellar promptlaringizda bir marta ham sinalmagan.
  • Shaxsiy ma’lumotli to‘liq promptlar muddatsiz saqlanadi.
  • Foydalanuvchi limitlari yo‘q va bitta mijoz hammani to‘sib qo‘yadi.

Ko‘p beriladigan savollar

Yaxshi qurilgan shlyuz odatda ancha uzoq bo‘lgan model javob vaqtiga nisbatan juda oz qo‘shadi. Uni stateless qiling, ilovalarga yaqin joylashtiring va limitlar uchun tezkor xotiradan foydalaning.

Bunda yordam beramiz

O‘zingiz shug‘ullanmasdan natija olishni istasangiz — biz har kuni shu bilan shug‘ullanamiz.

Loyihani muhokama qilish

Yana o‘qing

G‘oya yoki vazifangiz bormi? Bizga aytib bering

Ish kuni davomida javob beramiz va yechim taklif qilamiz. Konsultatsiya bepul.