Командалар үшін кілт деңгейіндегі сұраныс лимиттері — ретімен

Неліктен ортақ лимит жұмысты бұзады

Prod, тесттер және batch тапсырмалар бір API кілті арқылы өтсе, олар бірдей сұраныс қорын бөліседі. Схемада бәрі әдемі көрінеді. Ал жұмыста — көбіне керісінше.

Мәселе әдетте prod-та емес, оның жанында басталады. Дамытушы нагрузкалық тестті қосады, аналитиктер түнгі өңдеуді жібереді, біреу жаңа prompt-ты жүздеген сұраныспен тексереді. Егер бәрінде ортақ лимит болса, бұл трафик боевой трафикпен араласып кетеді. Пайдаланушы баяу жауап немесе 429 көреді, ал сервистің өзі дұрыс істеп тұрады.

Ең көп кедергі келтіретіні — бір шуылдақ клиент немесе бір шуылдақ тапсырма. Сұраныс жиілігін сәл ғана көтерсеңіз болды, ортақ қор бір минутқа, бір сағатқа, кейде бүкіл күнге жетпей қалады. Сол сәтте қалған командалар тек кідірістің өскенін, кезектің көбейгенін және өз сценарийлеріндегі қателерді көреді.

Одан кейін диагностика бұзылады. График лимиттің таусылғанын көрсетеді, бірақ басты сұраққа жауап бермейді: оны нақты кім тауысып жіберді. Prod командасы интеграцияны кінәлайды, интеграция тест стендін кінәлайды, ал test стенд үнсіз қалады, өйткені оның джобалары да сол кілтпен жүрген. Адамдар қолмен лог жинап жүргенше, мәселе клиенттерге тиіп үлгереді.

Мұндай схемаға support командасы көбіне өрт сөндіру режимінде жұмыс істейді. Түсінікті ережелердің орнына олар қолмен қолжетімділікті өшіреді, командалардан күте тұруды сұрайды және кінәліні уақыт белгісі бойынша іздейді. Бұған лимиттерді дұрыс баптаудан да көп уақыт кетеді.

LLM қосымшалары үшін бұл тіпті қолайсыз. Бір сервис қысқа сұраныстар жібереді, екіншісі ұзын batch тапсырмаларды жібереді, үшіншісі фондық retry жасайды. Егер бәрі ортақ шекке байланса, жүйе ең ауыр ағынды емес, лимитке түскен кез келгенін тежейді. Сондықтан кілт деңгейіндегі лимиттер бюрократия үшін емес, жүйенің әр бөлігі өз шегінде жұмыс істеп, көршісін тежемеуі үшін қажет.

Лимиттерді қабаттар бойынша қалай бөлуге болады

Бір ортақ шек көбіне қолмен ақау іздеуге алып келеді. Жұмыс істейтін схема бірнеше қабаттан құралады. Әдетте төртеуі жеткілікті:

• сервиске бөлек лимит;
• ортаға бөлек лимит;
• рөлге немесе кілт түріне бөлек лимит;
• тарихы жоқ жаңа кілттерге шағын әдепкі шек.

Сервис бойынша бөлу ең жиі кездесетін мәселені алып тастайды. Чат әдетте толқынды келеді, әсіресе жұмыс уақытында. Іздеу мен retrieval көбіне бірқалыпты жүктеме береді. Фондық тапсырмалар ең қауіпті: он мыңдаған жазбадан тұратын бір batch бүкіл пулды алып қойып, тірі пайдаланушыларға жауап беруді баяулатуы мүмкін. Егер әр сервистің өз шегі болса, ақау локалды болып қалады.

Prod-тың өз қоры болуы керек. Оны test пен песочницамен бөліспеңіз. Дамытушы кездейсоқ нагрузкалық прогон қосуы мүмкін, QA жаппай тексеру бастайды, ал ортақ лимит ең жаман сәтте бітеді. Dev-тағы трафик аз көрінсе де, prod бөлек өмір сүруі керек.

Рөлдер бойынша қабаттар тәуекелді дәлірек басқаруға көмектеседі. Пайдаланушы трафигіне тұрақты жауап уақыты керек. Интеграциялар қысқа кідірісті көбіне көтере алады. Batch тапсырмаларды қатаңырақ шектеуге немесе түнгі терезеге шығаруға болады. Әкімшілік кілттерді шағын, бірақ кепілді қорымен ұстаған дұрыс, сонда команда пик кезінде де кіріп, мәселені түзете алады.

Жаңа кілттерге арналған әдепкі лимит те пайдалы. Жаңа сервис алғашқы күні нақты мәнді сирек біледі. Оған шағын шек беріңіз, бір-екі апта нақты жүктемені жинаңыз, содан кейін көтеріңіз. Осылай сіз іске қосуды тұншықтырмайсыз және белгісіз трафикті ортақ бассейнге жібермейсіз.

Егер команда OpenAI-мен үйлесімді бір шлюз арқылы жұмыс істесе, мұндай схеманы ұстау жеңілірек. AI Router-де сервис пен ортаға бөлек кілт беріп, бәрін бір ортақ лимитке араластырмай-ақ қоюға болады.

Сервис бойынша лимиттер

Егер барлық сервис LLM-ге бір кілт арқылы шықса, мәселе тез басталады. Түнгі импорт, құжаттарды жаппай тексеру немесе сәтсіз retry бүкіл қорды жеп қояды, ал дәл сол уақытта пайдаланушы чат ашып немесе форма толтырып, баяу жауап алады.

Сондықтан сервистерді команда немесе иесі бойынша емес, жүктеме сипаты мен қате құны бойынша бөлген дұрыс. Тәжірибеде әдетте төрт топ болады: интерфейстегі клиенттік чат пен кеңестер, real-time іздеу мен классификация, фондық джобалар мен импорттар, сондай-ақ ішкі құралдар мен тест сценарийлері.

Пайдаланушы бірден көретін сервистер бірқалыпты жұмыс істеуі керек. Олар үшін күрт секірмейтін, болжамды лимит жақсы. Шек теориялық максимумнан сәл төмен болса да, пик кезінде жауап тұрақты қалады.

Фондық тапсырмаларды қатаңырақ шектеу керек. Оларға сирек бірден жауап қажет болады, бірақ кезек өссе немесе воркер қателерді қайталай берсе, олар қолжетімді барлық сұранысты өзіне тартып алады. Мұндай тапсырмалар үшін қарапайым байланыс жеткілікті: төменірек лимит, кезек және кідірістен кейін қайталау ережесі. Сонда импорт кешірек аяқталады, бірақ клиент көретін сервисті құлатпайды.

Лимитті шамамен қоюға болмайды. Нақты трафикке қараңыз: сервис кәдімгі күні қанша сұраныс жібереді, пикте не болады, секіріс қанша уақытқа созылады. Егер чаттың пигінде секундына 20 сұраныс болса, ал фондық тексеруде қысқа 200-лік секірістер болса, екеуіне бірдей шек қоюдың мәні жоқ.

Шлюз кілт деңгейінде лимит қоя алса, әр сервиске бөлек кілт берген ыңғайлы. Сонда шуылдақ өңдеуші боевой сценарийдің ресурсын алып қоймайды, ал қайсысы лимитке тірелгенін және кезекті қай жерде түзету керек екенін бірден көресіз, тек санды көтерумен шектелмейсіз.

Орталар бойынша лимиттер

Барлық ортаға бірдей лимит беру көбіне prod-қа зиян тигізеді. Тесттер, отладка және бір реттік прогондар ортақ қорды оңай тауысып тастайды, содан кейін боевой сервис ең жаман сәтте 429 алады.

Prod-тың өз минимумы болуы керек, оны ешкім тартып ала алмайды. Егер сізде сұраныс немесе token бойынша ортақ бюджет болса, оны бір шелекке салмаңыз. Боевой кілттерге бөлек лимит бөліңіз және stage немесе dev-ке одан уақытша болса да алуға мүмкіндік бермеңіз.

Тест стендіне айтарлықтай төменірек шек жеткілікті. Ол релизді, интеграцияны және бірнеше нагрузкалық сценарийді тексеру үшін керек, шексіз эксперимент жүргізу үшін емес. Stage prod-қа жуық лимит алған кезде команда онда бәрін қатар жүргізе бастайды, ал тесттерден шыққан шу нақты пайдаланушыларға кедергі келтіреді.

Дамытуға арналған песочницаға одан да төмен лимит қажет. Дамытушылар көп қысқа сұраныс жібереді, әртүрлі модельдерді сынайды, prompt-ты өзгертеді және скриптті өшіруді ұмытады. Dev-тағы шағын шек жұмысты тежемейді, керісінше мұндай жағдайларды жақсы ұстайды. Бір ноутбуктің қатесі бүкіл командаға проблема болмайды.

Релиз кезінде лимитті көтеруге болады, бірақ тек нақты нысанаға. Бүкіл stage-ті немесе бүкіл dev-ті бірнеше сағатқа ашып тастамаңыз. Оның орнына тек версия шығаруға қатысып жатқан кілттер тобына ғана уақытша көбірек беріңіз.

Жұмыс ережесі қарапайым: prod бөлек пул мен азайтылмайтын минимум алады, stage орташа лимитпен өмір сүреді, dev және песочница кіші лимитпен жұмыс істейді, ал релиз кезінде команда тек керек кілттердің шегін қолмен көтереді. Релизден кейін қалыпты мәндерді бірден қайтару керек. Мұны көбіне ұмытады, содан уақытша көтерілген лимит апталап қалып, жаңа авария тудырады.

Бір практикалық мысал. Ритейл командасында stage-тегі nightly тесттер каталогты тексерудің жаңа нұсқасына байланысты кенеттен он есе көп сұраныс жібере бастайды. Егер stage ортақ пулда отырса, боевой іздеу баяулайды. Егер stage-тің өз төмен шегі болса, тесттер соған тіреледі, команда логтан секірісті көреді, ал prod әдеттегідей жұмыс істей береді.

Рөлдер мен кілт түрлері бойынша лимиттер

Барлығына бірдей лимит қою көбіне теңгерімсіздік тудырады. Бір сервис трафикті бірқалыпты және жиі жібереді, серіктес кенеттен секіріс береді, ал қызметкердің жеке кілті тек тест пен отладкаға керек. Осы сценарийлерді араластырсаңыз, бір көз ортақ қорды тез жеп қояды.

Кілттерді оларды кім және не үшін қолданатыны бойынша бөлген ыңғайлы: ішкі қолданбаларға арналған сервис кілттері, серіктестер мен сыртқы клиенттер кілттері, қызметкерлердің жеке кілттері, әкімшілік кілттер және мердігерлерге арналған уақытша кілттер.

Сыртқы клиенттер үшін бірден екі шек қойған пайдалы: минутқа және күнге. Минуттық лимит серіктестегі retry циклі бұзылса немесе сәтсіз релиз шықса, күрт секірісті тежейді. Күндік лимит бюджетті қорғайды және бір интеграцияға кешке дейін бүкіл сыйымдылықты алып қоюға жол бермейді.

Batch тапсырмаларды бөлек кілт класына шығарған дұрыс. Олардың өз ырғағы бар және ол тірі пайдаланушы трафигіне ұқсамайды. Түнгі қайта индекстеу, жаппай белгілеу немесе evaluation прогоны prod сұраныстарымен бәсекелеспеуі керек. Оларға өз шегі және қажет болса, өз іске қосу терезесі керек.

Лимитсіз әкімшілік кілт — жаман идея. Дәл сондай кілттер кейін ең ұзақ өмір сүреді, бірнеше сервиске көшіріледі және үнсіз қауіп көзіне айналады. Әкімшілерге де қатаң шек, тар құқықтар және бөлек әрекет журналы қалдырған дұрыс.

Мердігерлермен ереже одан да қарапайым: мерзімі бар уақытша кілт беріңіз. Егер адамға екі аптаға қолжетімділік керек болса, кілт өзі өшуі тиіс, тіпті оны кері қайтарып үлгермеген болсаңыз да.

Тәжірибеде схема кәдімгі жұмыс тәрізді көрінеді. Клиенттерге минуттық және күндік лимит беріледі, ішкі сервиске — тұрақты жұмыс дәлізі, аналитиктерге — шағын жеке шек, мердігерге — жоба мерзіміне арналған уақытша кілт. Нәтижесінде бір шуылдақ клиент қалғандарын тежемейді.

Схеманы қадамдап енгізу

Бастауды сандардан емес, қолжетімділік картасынан жасаған дұрыс. Көп командаларда кілттер олар шығарылған тапсырмалардан ұзақ өмір сүреді. Нәтижесінде бір кілтті stage, ішкі бот және клиенттік сервис бірге қолданады, ал оның иесі әлдеқашан басқа командаға ауысып кеткен. Қай кілтті кім пайдаланатынын және ол не үшін жауапты екенін ажыратпайынша, жаңа лимиттер тек шатасуды көбейтеді.

Алдымен қарапайым реестр жинаңыз: кілт атауы, сервис, орта, иесі және қосымша байланыс. Негізгі мақсат — аты-жөні жоқ кілттер мен бәрі қолданатын ортақ токендерді жою.

Содан кейін өзіңізге бақылауға бір апта беріңіз. Ережені сол күні өзгертпеңіз. Әр сервис бойынша трафикке қараңыз: қалыпты жүктеме, пик сағаттары, релизден немесе жаппай жіберілімнен кейінгі сирек секірістер. Көбіне сурет тез айқындалады: prod тұрақты, stage таңертең шуылдайды, ал ішкі құрал қысқа, бірақ өткір секірістер жасайды.

Келесі қадамда схеманы кезең-кезеңімен енгізуге болады:

1. Әр кілттің кәдімгі жұмысына арналған базалық лимит қойыңыз.
2. Қысқа секіріске арналған бөлек шек қосыңыз, сонда релиз немесе batch тапсырма бірден қатаң бөгетке тірелмейді.
3. Қолдан шыққан кілт, қандай сервис және қандай лимит іске қосылғанын көрсететін бас тарту журналын қосыңыз.
4. Жай ғана платформалық командаға емес, сервис иесіне баратын қарапайым хабарландыруларды баптаңыз.
5. Командаларды жаңа схемаға бір-бірлеп көшіріңіз, ең болжамды сервистерден бастаңыз.

Бірден мінсіз сандарды іздеудің қажеті жоқ. Ақылға қонымды бастау және фактіге қарай бір-екі түзету жеткілікті. Егер төлем сервисі әдетте секундына 20 сұраныс жасаса, оны «сақтық үшін» 200-ге көтермеңіз. Кең лимиттер сирек құтқарады. Олар көбіне мәселені алғашқы үлкен жүктемеге дейін жасырып қояды.

Жақсы тексеріс өте қарапайым: сервис иесі өз лимитін біледі, alert қайда келетінін түсінеді және өзгеріс сұрай алады. Егер бұның бірі жоқ болса, схема әлі шикі.

Мысал: бір шуылдақ клиент бәріне кедергі келтірмейді

Компанияда үш ағын бар. Біріншісі — support чат, онда операторларға әр минут сайын тез жауап керек. Екіншісі — менеджер кабинеті, мұнда қызметкерлер клиент карточкалары мен құжаттарды қарайды. Үшіншісі — түнгі сверка, ол файлдарды пакетпен өңдеп, айырмашылықтарды тексереді.

Мәселе түнде басталады, batch тапсырма жүктемені күрт арттырғанда. Егер үш ағын да API-ға бір кілтпен шығып, ортақ лимитті бөліссе, сверка сұраныс қорын тез тартып алады. Чат баяу жауап бере бастайды, ал менеджер кабинеті де кідіріс алады, тіпті пайдаланушылардың өздері еш кінәлі болмаса да.

Жұмыс схемасы әлдеқайда қарапайым. Команда әр ағынға бөлек кілт ашады және оларға әртүрлі шек қояды: «support-chat-prod» жоғары басымдық алып, шағын, бірақ тұрақты қор алады; «manager-cabinet-prod» орташа лимитпен және күрт секіріссіз жұмыс істейді; «docs-reconcile-batch» түнгі өңдеуге арналған бөлек классқа түседі.

Енді сверка кенет тым көп сұраныс жіберсе, жүйе тек сол кілтті тежейді. Batch тапсырма 429 алады, қарқынын азайтады немесе кідірісі бар қайталауға өтеді. Support чаты мен кабинет өз ырғағымен жұмыс істей береді, өйткені олардың қорын ешкім жеп қойған жоқ.

Таңертең талдау да оңайырақ. Журналда жай ғана «лимит таусылды» емес, нақты себеп көрінеді: қай кілт шекке тірелді, қай уақытта болды және қанша сұраныс жіберді. Жүйені түгел шарлап іздеудің орнына команда бірден қай жерде проблема барын түсінеді.

Егер шлюз кілт деңгейіндегі лимиттер мен аудит логтарды қолдаса, мұндай схеманы клиенттік кодты қайта жазбай-ақ енгізуге болады. AI Router-де бұл дәл сондай ыңғайлы сценарийдің бірі: әр ағынға бөлек кілт, OpenAI-мен үйлесімді бір эндпоинт және журналдар арқылы түсінікті көрініс.

Кедергі жасайтын қателер

API-дегі кептеліс көбіне тым кіші шектен емес, жүктемені дұрыс бөлмеуден пайда болады. Команда кілт деңгейінде лимит енгізеді, бірақ ескі әдеттерді қалдырады: бәріне бір құпия, бәріне бірдей квота және бас тартуларды бақылау нөлге тең. Сонда кез келген секіріс тез арада кезекке айналады.

Ең жиі қате — бір кілтті prod-та, тесттерде және дамытушылардың ноутбуктарында қолдану. Біреу нагрузкалық сценарийді қосады немесе байқаусызда шексіз циклге түседі, ал боевой сервис те сол шектеулерді көреді.

Екінші қате — барлық рөлге бірдей шек беру. Batch тапсырманың, админканың және public API-дың жүктемесі әртүрлі. Барлығына бір сан қою екі шеткі жағдайға әкеледі: біреулер үнемі шекке тіреледі, басқаларға мүлде керек емес қор артығымен қалады.

Үшінші қате — команда тек минуттық лимитке қарайды. Ол күрт секірісті тежейді, бірақ күні бойы квотаның баяу жұмсалуын ұстамайды. Күндік лимит ұмыт қалған джобаларды, ұзақ циклдерді және үнсіз retry-ді анықтауға көмектеседі.

Төртінші қате — ескі кілттерді ешкім кері қайтармайды. Жоба, пилот немесе мердігер жұмысы аяқталғаннан кейін қолжетімділік өз бетінше өмір сүре береді. Кейде дәл осындай ұмыт қалған кілт апталап артық трафик тудырады.

Бесінші қате — лимит қойып, бақылауды ұмыту. Егер ешкім 429-ды, қайталау санын және ең шуылдақ кілттерді бақыламаса, кептеліс үнсіз өседі. Ең нашары — клиент бас тарту алған сайын бірден жаңа сұраныс жіберіп, мәселені өзі күшейтеді.

Схеманың сапасын тез көрсететін қарапайым тест бар. Логтан қай сервис, қай орта және қай кілт түрі квотаны жеп қойғаны көрінуі керек. Егер бұны табуға жарты сағат кетсе, баптау нашар деген сөз.

Іске қоспас бұрын жылдам тексеріс

Релиз алдында қарапайым бір істен шығуды модельдеген пайдалы: бір клиент немесе бір сервис трафикті он есе арттырады. Осыдан кейін қалғандарының бәрі баяулай бастаса, схема әлі дайын емес. Мұндай тест әлсіз жерлерді әдемі диаграммадан да жақсы көрсетеді.

Кілттер тәртіпсіз берілсе, лимиттердің өзі құтқармайды. Мәселе көбіне сандарда емес, қай кілт кімге тиесілі екенін, қандай трафик көтеруі керегін және бас тарту болса кімге сигнал баратынын ешкім білмейтінінде.

Іске қоспас бұрын бірнеше нәрсені тексеріңіз:

• әр сервистің өз кілті және түсінікті иесі бар;
• prod тест стендінен бөлек өмір сүреді;
• сыртқы клиенттерге өз лимиттері қойылған;
• бас тартулар журналға жазылады, ал сигнал жауапты адамға тез жетеді;
• лимитті уақытша көтеру және кейін қайта төмендету жолы түсінікті.

Егер кем дегенде бір тармақ ақсап тұрса, релизді кідірткен дұрыс. Бір күндік қосымша дайындық әдетте бас тартуларды қолмен талдап, ортақ арнаны бітеп тастаған сервисті іздеумен өткен түннен арзанға түседі.

Әрі қарай не істеу керек

Алдымен лимит схемасының иесін тағайындаңыз. Бұл жай формалдық емес. Бір адам немесе шағын топ кімге кілт берілетінін, ол қалай аталатынын, қандай лимит қойылатынын және асулар үшін кім жауапты болатынын шешуі керек. Иесі жоқ жерде ерекшеліктер өте тез жиналады да, бір айдан кейін ұқсас екі сервис неге әртүрлі ережеде екенін ешкім түсінбей қалады.

Кілт беру ережесін қысқа әрі қарапайым етіп жасаған жақсы. Әдетте төрт өріс жеткілікті: кілтті қандай сервис қолданады, ол қай ортада жұмыс істейді, команда жағынан кім иесі, және жүктеменің қандай пигі күтіледі. Бұл prod, stage, фондық тапсырмалар мен қолмен тестерді бір ағынға араластырмауға жеткілікті.

Кейін қарапайым қайта қарау ырғағын енгізіңіз. Айына бір рет нақты трафикті ашып, үш нәрсеге қараңыз: қай жерде 429 жиі шығады, қай кілттер жүктемесіз дерлік өмір сүріп жатыр, және қай сервистер пик кезінде күрт өседі. Егер лимит керек болмаса, оны азайтыңыз. Егер сервис тұрақты түрде шекке тірелсе, шекті тек соған көтеріңіз, бүкіл аккаунтқа емес.

Кейде оқу үшін шағын секіріс ұйымдастырған пайдалы. Бір клиент немесе бір воркер бақылаудан шығып кеткендей етіп, басқарылатын сұраныс толқынын қосыңыз. Содан кейін кім бірінші зардап шеккенін, alert-тер керекті командаға жеткен-жетпегенін және prod қалыпты жылдамдықты сақтағанын тексеріңіз.

Егер сіз модельдерге сұранысты AI Router арқылы жіберсеңіз, келесі логикалық қадам — лимиттерді жалпы аккаунт деңгейіне емес, кілт деңгейіне шығару және сервис бойынша аудит логтарын үнемі қарап отыру. Сол арқылы қай ағын квотаны жеп жатқанын, қай жерде 429 өсіп жатқанын және кімді бөлек шекпен оқшаулау керегін тез байқайсыз.

Алдағы бір аптаға арналған жоспар өте қарапайым: иесін тағайындау, кілттерді сервис пен орта бойынша бөлу, бас тарту журналын қосу және бір рет шуылдақ клиент шынымен де қалғандарын құлата алмайтынын тексеру.