LLM-сервистегі ұзын промпттарға арналған Admission control

Неге ұзын промпттар кезекті бітеп тастайды

Ұзын промпт сервиске тек көлемімен ғана салмақ түсірмейді. Ол модель бүкіл кіріс контекстін оқып, жауапқа дайындалатын prefill кезеңінен ұзағырақ өтеді. Осы уақыттың бәрінде слот босамайды, ал қалған сұраныстар күтіп қалады.

Мәселе мынада: бір ғана осындай шақыру ондаған қысқа сұранысты тежеп тастауы мүмкін. 300-500 токендік чатқа отырған пайдаланушы бірден жауап күтеді, бірақ ол 40 000 токендік сұраныспен бір кезекке түседі. Кезек үшін бұл жай ғана екі сұраныс емес. Бұл бір ресурсқа таласып тұрған жеңіл әрі өте ауыр екі тапсырма.

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

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

Ең жағымсыз жері — SLA көбіне CPU-дан бұрын төмендейді. Әдетте тар жер процессорда емес, ұзын контекстті өңдеу уақытында, бос емес GPU слоттарында, жадта және жалпы token throughput-та болады. Дашбордта әлі айқын апат көрінбейді, ал пайдаланушылар кешігуді сезініп үлгереді.

Әдетте бұл былай білінеді:

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

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

Сұраныс бюджетін неден құрау керек

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

Бюджет неден тұрады

Алдымен кіріс пен шығыс токендерін бөлек қараңыз. Кіріс prefill мен жадқа салмақ түсіреді, ал шығыс генерация уақытын алады. Жалпы лимиті бірдей екі сұраныс әртүрлі әрекет етеді. Кірісте 20 000 токені, жауапта 500 токені бар сұраныс сервисте кірісте 2 000, шығыста 5 000 токені бар сұраныстан ауырлау болады.

Сондықтан екі лимит ұстаған дұрыс: бірі prefill үшін, екіншісі жауап үшін. Prefill лимиті кезекті тым ұзын құжаттар мен хат-хабарлардан қорғайды. Жауап лимиті бір шақырудың генерацияға шамадан тыс уақыт алып кетуіне жол бермейді. Жалпы лимит те керек, бірақ ол жалғыз өзі көп нәрсені шешпейді.

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

Tool call-дарды бөлек есептеңіз. Модель іздеу, SQL, RAG немесе ішкі функцияны шақырғанда, кері жаңа мәтін алады. Ол мәтін қайтадан контекстке түсіп, бюджетті тез үлкейтеді. Тіркемелерге де солай: PDF, хаттар, клиент карточкалары және білім базасының үзінділері. 30 беттік бір файл prefill лимитін толық жеп қоюы мүмкін.

Қарапайым ереже

Практикада бюджетті төрт бөлікке бөлген ыңғайлы:

• жүйелік және қызметтік контекст
• пайдаланушының енгізуі
• тіркемелер мен табылған құжаттар
• күтілетін жауап және мүмкін tool call-дар

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

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

Приоритетті қалай бөлу керек

Приоритетті ресурсты кім қаттырақ сұрайтыны бойынша емес, кешігудің құны бойынша есептеген дұрыс. Егер адам чатта жауап күтіп отырса, қосымша 2-3 секунд бірден сезіледі. Ал есеп құрастыру, архивті белгілеу немесе түнгі batch өңдеу болса, ол күте алады.

Сондықтан трафикті кемінде үш классқа бөлу керек: чат, batch және фондық тапсырмалар. Мұның өзі-ақ ұзын промпттардың ортақ кезекті бітеп тастамауына жетеді. Сырттай сұраныстар бірдей көрінуі мүмкін, бірақ олардың талабы бөлек. Чатқа төмен кідіріс керек. Batch көлемді жақсы көреді. Фондық тапсырмалар үзілісті қалыпты көтереді.

Негізгі ереже қарапайым. Пайдаланушы жауап күтетін чат пен интерфейстік сұраныстар жоғары приоритет алады. Batch тапсырмалар өз квотасымен жүреді де, токендердің немесе слоттардың алдын ала белгіленген бөлігінен артық алмайды. Фондық job-тар төмен приоритет алады және ең алдымен жүктеме артқанда баяулайды. Уақыт терезесі де маңызды: күндіз онлайн трафик басым, түнде жаппай тапсырмалардың квотасын кеңейтуге болады.

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

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

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

Промптты мағынасын жоғалтпай қалай қысқартуға болады

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

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

Құжаттармен жұмыс істегенде дөрекі кесу сирек көмектеседі. Егер контекстке 20 беттік келісімшарт салынса, лимитке сыйғаны үшін алғашқы 5 бетті ғана қалдырудың мәні жоқ. Оның орнына қысқа түйін жасаған дұрыс: тараптар, сома, мерзім, шектеулер және керек бөлімнен 1-2 нақты дәйексөз. Айыппұл туралы сұраққа бүкіл құжаттан гөрі айыппұл туралы бір абзац пайдалырақ.

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

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

Тағы бір жиі қате — бүкіл кіріс лимитін толтырып тастап, жауапқа орын қалдырмау. Егер модель 32k токен қабылдаса, бұл 32k-дің бәрін промптқа беріңіз деген сөз емес. Алдымен completion үшін бюджет бөліңіз. Егер 800 токендік жауап керек болса, сол 800 токенді алдын ала қалдыру қажет. Әйтпесе сервис жауаптың үзіліп қалуына немесе лимит бойынша қабылдамауға тап болады.

Әр қысқартуды логта белгілеу пайдалы. Қандай хабарламаны немесе құжатты алып тастағаныңызды, қанша токен үнемделгенін, бастапқы мәтінді немен алмастырғаныңызды және қысқарту қандай ереже бойынша іске қосылғанын жазып отырыңыз. Кейін бұл көп уақыт үнемдейді: жауап сапасы төмендегенде команда абстрактылы "модель қатесін" емес, нақты себебін көреді.

Қашан бірден қабылдамау керек

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

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

Пайдаланушы не болғанын өзі-ақ түсінуі керек. Жауапта себеп пен рұқсат етілген өлшемді тура көрсеткен дұрыс: қанша токен келгенін, қандай лимит қолданылып тұрғанын және әрі қарай не істеу керегін. Мысалы: "Сұраныста 240000 токен бар. Бұл модель үшін 128000 қолжетімді. Контексті қысқартыңыз немесе тапсырманы async-режимге жіберіңіз".

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

Лезде қабылдамауға болатын төрт типтік себеп бар:

• промпт модельдің немесе клиент саясатының қатаң лимитінен жоғары
• құнды бағалау бір шақыру бюджетінен асып кетеді
• сұраныс batch немесе async талап етеді, бірақ sync режимге келіп тұр
• кіріс деректері бұзылған: бос мәтін, сынық JSON, жүздеген бетке созылған қайталанатын контекст

Егер команда бірыңғай шлюз арқылы жұмыс істесе, мұндай тексерісті маршрутизацияға дейін жасаған жақсы. Сонда анық нашар сұраныс әрі қарай кетпейді, rate limit-ті жеп қоймайды және артық audit-логтар тудырмайды.

Жылдам әрі түсінікті қабылдамау 40 секунд күтіп, кезектің өсіп, соңында бәрібір сол қабылдамауға тап болғаннан әлдеқайда жақсы.

Admission control-дың қадамдық схемасы

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

Ең нашар схема — барлық сұраныс алдымен ортақ кезекке түседі де, тек содан кейін тексеріледі. Бір өте ұзын промпт бір слотты оңай алып қояды, соның артынан бірден ондаған қысқа сұраныс баяулайды, ал олар дерлік бірден өтер еді.

1. Сұраныс көлемін токенмен бағалаңыз. Тек пайдаланушы мәтінін емес, system prompt-ты, диалог тарихын, тіркелген құжаттарды және күтілетін жауап көлемін де есептеңіз.
2. Клиент шектеулерін тексеріңіз. Қалған квота, rate limit, белсенді сұраныстар саны және кезектің ағымдағы ұзындығын бірге қараған дұрыс.
3. Қызмет класын тағайындаңыз. Операторға арналған интерактивті чат жоғары приоритет алады, құжаттарды түнгі пакет өңдеу — төмен, песочницадағы эксперименттер — одан да төмен.
4. Егер сұраныс тым үлкен болса, алдын ала бекітілген ережелер бойынша қысқарту қолданыңыз. Алдымен ескі хабарламаларды, кейін қайталануларды, содан соң екінші деңгейлі тіркемелерді алып тастаңыз. System prompt, жаңа репликалар және міндетті өрістерге тимеген жөн.
5. Содан кейін үш шешімнің бірін қабылдаңыз: сұранысты бірден жіберу, оны бөлек кезекке қою немесе қабылдамау.

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

Продакшеннен қарапайым мысал

Банк чат-көмекшісі клиенттен мынадай хабарлама алады: "Неге менде комиссия шешілді?" Сол сәтке дейін диалогта 120 хабарлама жиналған. Онда ескі сұрақтар, қайталанулар, оператордың қызметтік фразалары және енді жауапқа әсер етпейтін мәтін бөліктері бар.

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

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

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

Әдетте қысқарту ережесі мынадай болады: клиенттің соңғы хабарламасын, диалогтың соңғы 6-8 репликасын, әңгіменің ескі бөлігінің қысқа түйінін және міндетті қызметтік өрістерді қалдыру. Қалғанын кесіп тастаған дұрыс: сәлемдесулерді, қайталауларды, ескірген тармақтарды және бұрынғы хабарламалардан алынған ұзақ дәйексөздерді.

Егер клиент бір сағат бұрын комиссия туралы дауласып, қазір картасын қайта шығаруды сұрап отырса, ескі дау жылдам сұраныста орын алмауы керек.

Мұндай тәсіл әсіресе LLM-шлюзде пайдалы, өйткені онда қысқа пайдаланушы сұраныстары да, ауыр талдау тапсырмалары да қатар өмір сүреді. Барлық модельге бір кіріс нүктесі интеграцияны жеңілдетеді, ал admission control ережелерін нақты маршрутты таңдауға дейін-ақ қолдануға болады.

Сервис тез бітеліп қалатын қателер

Admission control көбіне күрделі математикадан емес, бірнеше дөрекі баптаудан бұзылады. Сервис біраз уақыт шыдап тұрады, кейін ұзын сұраныстар тасқыны келеді, кезек бітеледі де, кідіріс бәріне бірдей өседі.

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

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

Үшінші қате дерлік әр бірінші іске қосылымда кездеседі: команда тек кірісті есептейді. Сұранысты модель терезесіне дәл келтіріп қояды да, жауапқа, жүйелік кірістіруге, tool call-дарға немесе шлюздің қызметтік токендеріне орын қалдырмайды. Сервис сұранысты қабылдайды, бірақ генерация кезінде-ақ шекке тіреледі. Пайдаланушы timeout немесе жауаптың үзіліп қалуын көреді, ал себебі қарапайым — completion үшін қор жоқ.

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

Нашар метрикалар да кем емес зиянды. Егер дашборд тек қателер мен орташа кідірісті көрсетсе, команда көз жұмып таласады. Қысқарту мен қабылдамау себептерін бөлек санаған дұрыс: кіріс токен лимитінен асты, жалпы бюджет жауапқа орын қалдырмады, жүйе чат тарихын қысқартты, жүйе табылған контекстті қысқартты, клиент қабылдамаудан кейін сервиске қайта-қайта жабысты.

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

Іске қосар алдындағы чек-лист

Релиз алдында тек орташа жүктемені емес, нашар сценарийлерді де тексеріңіз. Admission control кәдімгі сұраныстарда емес, бір клиент өте үлкен чат тарихын жіберіп, екіншісі жүздеген беттік файл жүктеген кезде сынады.

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

Минималды чек-лист мынадай:

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

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

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

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

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

Практикалық жоспар да қарапайым. Алдымен саясатты ашық бекітіңіз: кіріс токендерінің лимиті, сұраныстың жалпы бюджетіндегі лимит, клиент түрі бойынша приоритет ережелері және қабылдамаудың рұқсат етілген себептері. Содан кейін лимиттерді дерек пен аудит талаптарымен салыстырыңыз. Егер сервис тарих сақтаса, PII-ді маскалайтын болса немесе audit-лог жазса, бұл сұраныс маршруты мен рұқсат етілген контекст өлшеміне де әсер етеді.

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

Егер командада бірнеше модельмен жұмыс істейтін бір шлюз болса, ережелерді дәл сонда ұстау ыңғайлы. AI Router жағдайында бұл табиғи көрінеді: сервис бір OpenAI-үйлесімді endpoint, key деңгейіндегі rate-limit және audit-логтар береді, сондықтан базалық тексерісті маршрутизацияға дейін жасауға болады. Қазақстан мен Орталық Азиядағы командалар үшін бұл деректерді ел ішінде сақтау және PII masking маңызды болатын сценарийлерде жұмысты жеңілдетеді.

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

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