Командалар арасындағы LLM лимиттері: тоқтаусыз квота схемасы

Неліктен ортақ пул тез бұзылады

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

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

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

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

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

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

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

Бүкіл компанияға бір ғана лимит беру әдетте ең шуылдақ тұтынушыға жұмыс істейді. Сондықтан квоталарды бірнеше ось бойынша бөлген дұрыс. Сонда қолдау чаты түнгі batch прогоннан ұтылмайды, ал prod dev-тегі эксперименттерден тоқтап қалмайды.

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

Сосын трафикті орталар бойынша бөліңіз. Prod, stage, dev және sandbox бір дәлізде өмір сүрмеуі керек. Prod-тың өз кепілді лимиті және ең жоғары басымдығы болғаны дұрыс. Stage-тың лимиті төменірек, бірақ тұрақты болуы керек, сонда релиздер ресурсты қолмен тартысып алмай өтеді. Dev пен sandbox-ты қатаңырақ шектеген жөн, әйтпесе бір сәтсіз тест бүкіл команданың қорын тез жеп қояды.

Бөлек уақыт ережелерін де белгілеңіз. Күндіз жүктеме көбіне пайдаланушы жауапты бірден күтетін интерактив сценарийлерден келеді. Түнде batch тапсырмаларды іске қосу ыңғайлы: таңбалау, архивтерді қысқаша мазмұндау, жаппай тексерулер. Релиз терезелерінде stage пен prod уақытша көбірек қор алады, ал фондық job-тарды баяулатқан дұрыс.

Сұрауларды трафик түрі бойынша бөлу де орынды:

• секундтар ішінде жауап беретін интерактив трафик
• қатаң SLA-сы жоқ batch тапсырмалар
• ішкі эксперименттер мен тесттер
• маңызды сервистерге арналған авариялық қор

Практикада схема былай көрінеді. Мысалы, сізде қолдау чаты, қызметкерлерге арналған ішкі көмекші және түнгі құжат өңдеу бар. Чат күндіз prod-та бөлек квота және ең қызу сағаттарға резерв алады. Қызметкерлер көмекшісі кеңсе белсенділігімен лимитті бөліседі және аздап күте алады. Түнгі құжат өңдеу 22:00-ден кейін үлкен лимит алады, ал күндіз интерактив сервистерге жол береді.

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

Өнімдер бойынша квоталар

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

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

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

Бастапқыда мынадай арақатынас жиі жұмыс істейді: пулдың 50-60%-ы сыртқы пайдаланушылары мен SLA-сы бар өнімдерге бекітіледі, 20-30%-ы ішкі сервистерге беріледі, 10-15%-ы клиент трафигі мен авариялық шоқтарға резерв ретінде сақталады, тағы 5-10%-ы прод сервистерінен бөлек пилоттар мен эксперименттерге бөлінеді.

Пилоттарды сатылымға, қолдауға немесе операцияларға бірден әсер ететін сервистермен араластырмау керек. Пилоттың ырғағы басқа: бүгін сұрау аз, ертең команда үлкен бағалау жүргізеді немесе демо дайындайды. Егер мұндай жоба prod-пен бір пулда отырса, қақтығыс өте тез басталады.

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

Орталар бойынша квоталар

Ең жиі болатын ақаулардың бірі prod-та емес, соның жанында басталады. Егер prod, stage және dev токенді бір пулдан алса, тесттер мен эксперименттер боевой трафикке керек қорды оңай тауысады.

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

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

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

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

Қарапайым ереже былай естіледі: prod чужой қателіктен аман қалуы керек, stage релизді тыныш өткізуі керек, ал dev арзан әрі басқарылатын болуы тиіс. Егер бір орта бүкіл пулды құрғата алса, схема әлі жұмыс істемейді.

Тәулік уақыты бойынша квоталар

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

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

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

Бастапқы нүкте ретінде көбіне мына схема жеткілікті:

• 9:00-20:00 аралығында чаттар, іздеу және оператор құралдары басым болады
• түнде batch-тар, қайта индекстеу, құжаттарды жаппай өңдеу және тест прогондары жүреді
• 11:00-14:00 және 16:00-18:00 сияқты аралықтарда басым емес тапсырмаларға қатаңырақ burst қойылады
• демалыс күндері күндіз prod-қа кедергі келтіретін ауыр прогондарға терезе ашылады

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

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

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

Схеманы қадамдап қалай жинауға болады

Санды емес, LLM API-ға шынымен кімдер қатынасып жатқанын тізімдеуден бастаңыз. Әдетте ол жерден тек прод сервистері емес, тест стендтері, ішкі боттар, batch тапсырмалар және аналитиктердің қолмен жазған скрипттері де тез шығады. Әр тұтынушының иесі болуы керек. Әйтпесе тапшылық кезінде бірінші қайсысын қысқарту керегін ешкім тез шеше алмайды.

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

Алдымен базалық қорғанысты қойыңыз

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

Үш приоритет деңгейін ұстаған ыңғайлы:

• табысқа немесе клиент жолына тікелей қатысты критикалық
• түсінікті SLA-сы бар ішкі жұмыс сервисі
• фондық немесе эксперименттік жүктеме

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

Схеманы бұрынғы пиктерге тексеріңіз

Квоталарды көзсіз енгізбеңіз. Тарихтағы 2-3 ең ауыр күнді алып, схеманы тест сияқты өткізіңіз. Қай жерде prod қателесетінін, қай жерде тест артық жейтінін және пик сағаттарында қанша резерв қалатынын қараңыз.

Мұндай тексеруден кейін көбіне үш нәрсе түзетіледі:

• қатаң SLA бар сервистер үшін минимум көтеріледі
• тест және dev орталарының burst-і қысқартылады
• фондық өңдеу түнгі сағаттарға ауыстырылады

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

Үш сервиске арналған бөлу мысалы

Күніне 10 млн токен және минутына 200 сұрау бар бюджетті алайық. Жағдайды нақты мысалмен талқылау оңай.

Күндіз ережелерді қатаң ұстаған дұрыс. Қолдау чаты кепілді пул алады, өйткені ондағы кез келген кідіріс клиентке бірден көрінеді. Тіпті аналитика немесе тесттер кенет өскен күннің өзінде олар чаттың күндізгі қорын жеп қоймауы керек.

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

R&D-команда sandbox-та күндізгі төбемен жұмыс істейді, өйткені ол маңызды емес болғандықтан емес, жүктемесі жиі үзік-үзік болғандықтан. Ұзын контексті бір сәтсіз тест ортақ бюджетті бір сағатта-ақ босатып жіберуі мүмкін. Тұрақты төбе prod-ты қорғайды, ал 22:00-ден кейін бұл командаға эксперименттер үшін бос көлем беруге болады.

Кәдімгі бір жұмыс күнін елестетіп көріңіз. 17:30-да қолдау чатында сұраулар күрт көбейді. Жүйе алдымен резервті чатқа береді, содан кейін егер түнгі batch ертерек іске қосылып кетсе, оны шектейді. Sandbox бұл сәтте өз күндізгі лимитінен артық ештеңе алмайды.

22:00-ден кейін схема өзгереді. Егер чат түнгі әдеттегі деңгейге қайтса, ал batch өз көлемінің бәрін пайдаланбаса, қалғанын эксперименттерге ашуға болады. Бірақ өшіру тәртібі де қатаң болуы тиіс: алдымен тесттер тоқтайды, содан кейін batch жылжиды, тек ең соңында чатқа тиіспейді.

Командалар көбіне қай жерде қателеседі

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

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

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

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

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

Жылдам өзін-өзі тексеру мұнда қарапайым: prod пен dev-та лимиттер әртүрлі, суточныйдан бөлек қысқа терезелер бар, көлемнің 10-20%-ы алдын ала бөлінбеген, ал ретрайлар, дубликаттар және кілттер бойынша секірістер логтардан көрінеді.

Қайта қарауға арналған қысқа чек-лист

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

Әр қайта қарау алдында бес нәрсені тексеріңіз:

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

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

Келесі спринтте не істеу керек

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

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

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

Бір спринтке әдетте мына жоспар жеткілікті:

• ең қатаң SLA-сы бар сервисті таңдау
• оған орталар бойынша бөлек кілттер беру
• prod лимитін және sandbox-қа төмен төбені бекіту
• шекке жақындағанда қарапайым alert-терді қосу

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

Алдын ала бір қарапайым ережені жазып қойған пайдалы: лимит бітуге жақындаса, қандай трафик алдымен қысқарады. Әдетте алдымен dev қысқарады, кейін stage, тек содан соң ішкі көмекші сияқты маңызды емес prod тапсырмалар.

Егер сізде көп команда, провайдер және кілт болса, AI Router-ды бірыңғай бақылау қабаты ретінде қолдану ыңғайлы: кілт деңгейіндегі rate limits және аудит-логтар квотаны кім жұмсағанын және теңсіздік қай жерде басталғанын тез көруге көмектеседі. Бұл квота саясатын алмастырмайды, бірақ оны орындауды айтарлықтай жеңілдетеді.

Спринт соңына қарай сізге мінсіз схема керек емес. Бір маңызды сервиске басқа адамдардың эксперименттерінен қорғайтын жұмыс істейтін нұсқа керек және келесі циклде нені өзгерту керегі көрініп тұруы тиіс.