LLM-тізбегіндегі таймауттар: уақыт лимитін қалай бөлу керек

Жалпы таймаут қай жерде бұзылады

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

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

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

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

Ең жаманы - себебі бірден көріне бермейді. Логта «request timeout» немесе 504 сияқты жазу ғана қалады, ал қай кезең кінәлі екені бөлінбейді. Пайдаланушы кетіп қалады, ал инженерлер шлюз бе, іздеу ме, құрал ма, әлде модель ме деп дауласады.

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

Кідіріс неден құралады

Уақыт лимиті сирек қана модель жауабына түгел кетеді. Пайдаланушы мәтінді күтіп отырғанда, жүйе желіге, кезектерге, дерек іздеуге және басқа сервистерді шақыруға миллисекундтар мен секундтарды жұмсап үлгереді. Сондықтан 10-15 секундтық лимит іс жүзінде модельге көбіне тек жартысын ғана қалдырады.

Кідіріс әдетте төрт бөліктен тұрады. Алдымен сұраныс API-шлюзге жетеді: онда желілік жол, кілтті тексеру, лимиттер және кейде трафик күрт өссе қысқа кезек болады. Содан кейін жүйе векторлық қоймада құжаттарды іздейді, нәтижелерді сүзеді және қажет болса, оларды реранктан өткізеді. Одан кейін құралдар іске қосылуы мүмкін: CRM, база бойынша іздеу, төлем сервисі, ішкі API, SQL-сұрау немесе есептеу функциясы. Тек содан кейін ғана модель жауап генерациялай бастайды.

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

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

Қарапайым мысал: банк чат-ассистентіне 12 секунд лимит берілді. Шамамен 500 мс шлюз бен желіге, 1,8 секунд іздеу мен реранкқа, тағы 2,2 секунд клиенттің мәртебесін ішкі сервисте тексеруге кетті. Модельге 8 секундтан аз уақыт қалды, бұл әлі қайта әрекет жасауға немесе тұрып қалған қадамды тоқтатуға арналған қорсыз.

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

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

Жалпы уақыт лимитін қалай таңдау керек

Бастау үшін модельден емес, пайдаланушының шыдамынан бастаған дұрыс. Чатта адамдар ең аз күтеді. Егер экран 2-3 секунд үнсіз тұрса, сервис қазірдің өзінде қатып қалғандай көрінеді. Ал алғашқы токен тез келсе, сол пайдаланушы кейінгі 5-8 секундтық жауапты да сабырмен оқиды.

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

Бастапқы шектерді сценарий түріне қарай былай қоюға болады:

• чат: алғашқы токенге дейін 1,5-2,5 секунд және толық жауапқа 8-12 секунд;
• RAG бар іздеу: алғашқы токенге дейін 2-4 секунд және толық жауапқа 10-15 секунд;
• құралдары бар агенттік сценарий: алғашқы токенге дейін 3-5 секунд немесе жылдам аралық статус және бүкіл циклге 20-40 секунд.

Бүкіл бюджетті модельге және ретриверге бермеңіз. Желіні, сұранысты тоқтатуды, лог жазуды және шлюздің соңғы кідірістерін жабуға қор қалдырыңыз. Егер PII маскалауы, аудит-логтар немесе бірыңғай API-шлюз арқылы маршруттау болса, 10-20% резерв жалған таймауттардан жиі құтқарады.

Жұмыс істейтін ереже қарапайым: алдымен адам үшін қабылдауға болатын лимитті алыңыз, содан кейін қызметтік шығындарды алып тастаңыз да, қалғанын тізбек қадамдарына бөліңіз. Мысалы, қолдау командасы жауап 12 секундтан аспаса дейді десек, шамамен 1 секундты желі мен қызметтік операцияларға бөлек қалдырып, 2 секунд шамасында алғашқы токенге жетуді мақсат етіп, қалғанын іздеу, құралдар және генерацияға беру керек.

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

Лимитті қадамдарға қалай бөлу керек

Алдымен бір сұранысқа арналған SLA-ны бекітіңіз. Орташа уақытты емес, жауап қазірдің өзінде пайдасыз болып қалатын шекті алыңыз. Егер чат 8 секундта жауап беруі керек болса, бюджетті дәл осы саннан есептеу керек.

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

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

Жалпы лимит 8 секунд болса, бөлу мынадай болуы мүмкін:

• шлюз және маршруттау - 300 мс дейін;
• ретривер - 1,2 секундқа дейін;
• бір сыртқы құрал - 1,5 секундқа дейін;
• модель - 4,2 секундқа дейін;
• желі, сериализация және күтпеген кідірістерге резерв - шамамен 800 мс.

Жұмсақ шек fallback бар жерде әсіресе пайдалы. Егер ретривер 700 мс ішінде үлгермесе, жауапты контексттің бір бөлігінсіз беруге болады. Егер құрал 1 секундтан ұзақ бөгелсе, қарау нұсқасын көрсетіп, деректер толық емес екенін белгілеуге болады. Пайдаланушы бос экраннан гөрі сәл дәлдігі төмен жауапты оңайырақ кешіреді.

Тағы бір қарапайым тексеріс бар: барлық лимиттердің қосындысы жалпы таймаутқа тең емес, одан аз болуы керек. Әйтпесе кез келген желілік секіріс бүкіл сұранысты бұзады. Продакшнда 10-15% қор - бұл артық сақтану емес, әдеттегі гигиена.

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

Ретривер мен құралдарды қалай баптау керек

Ретривер мен сыртқы құралдар жауапты көбіне бір үлкен апаттан емес, ұсақ кідірістерден бұзады. Іздеу әдеттегіден 400 мс ұзаққа созылады, CRM үшінші әрекеттен жауап береді, баға калькуляторы кезекте тұрады, ал модельге соңғы жауапқа өте аз уақыт қалады.

Іздеуді қысқа әрі болжамды ұстаған дұрыс. Егер базаға әдетте 3-5 фрагмент жеткілікті болса, «сақтық үшін» top-k=20 сұрамаған жөн. Артық құжаттар жауапты ақылды қылмайды. Керісінше, олар кідірісті өсіріп, контекстке шу қосады.

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

Барлық шақыруларға ортақ бір таймаут қою көбіне жаман аяқталады. Білім базасын іздеу үшін бұл 150-300 мс болуы мүмкін, CRM немесе биллинг үшін 500-800 мс, сирек қолданылатын сыртқы API үшін одан сәл көп, егер онсыз жауаптың мәні жоғалса.

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

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

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

Модельге не қалдыру керек

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

max_tokens арқылы алғашқы токенге дейінгі уақытты және жауаптың соңына дейінгі уақытты бөлек өлшеңіз. Пайдаланушы үшін бұл әртүрлі нәрсе. Бір басқа 700 мс ішінде алғашқы токенді көріп, кейін ұзақ жауапты жаймен оқып шығу, ал мүлде басқа жағдай - 5 секунд бойы бос экранға қарап отыру. Алғашқы токенге дейінгі уақыттың өсуі көбіне жүктеменің артуын, провайдер кезегін немесе тым ауыр промптты білдіреді.

Модельді шақырмай тұрып max_tokens-ты қатаң шектеу пайдалы. Бұл қысқа жауап жеткілікті болғанда лимитті еш қиындықсыз үнемдеудің ең қарапайым жолы. Классификацияға 20-50 токен жетуі мүмкін, қысқа түйінге - 120-200, ал ұзын хат жобасы басқа бюджет сұрайды. Шекті алдын ала қоймасаңыз, модель оңай созылыңқылыққа кетіп, артық секундтарды жеп қояды.

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

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

Стриминг ұзын финалдық жауапта әсіресе пайдалы. Ол генерацияны өзі жылдамдатпаса да, жылдамдық сезімін қатты жақсартады. Чат үшін бұл дерлік әрқашан жақсы таңдау.

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

Тағы бір жиі ұмытылатын ереже: модельдің орташа кідірісіне емес, сұраныстардың ең нашар 5-10%-ына сүйеніңіз. SLA-ны көбіне дәл солар бұзады.

Нақты сценарий мысалы

Банк чат-ботын елестетіңіз. Клиент: «Кредит картамның өтінімі қайда?» - деп жазады. Бот бірден модельді шақырып, қанша уақыт кетсе де күте алмайды. Алдымен ол білім базасынан жауап іздейді, кейін ішкі сервис арқылы өтінім мәртебесін тексереді, содан соң ғана финалдық жауапты жинайды.

Команда бүкіл сұранысқа 8 секунд берді. Бұл енді абстракт сан емес, жауап тіпті желі нашар болса да уақытында келуі үшін қадамдарға бөлу керек қатал бюджет.

Жұмыс істейтін бөлу мынадай болуы мүмкін:

• 300 мс API-шлюзге сұранысты қабылдауға, кілтті тексеруге, маршруттауға және трассировканы бастауға кетеді;
• 1,2 секунд білім базасындағы іздеуге беріледі;
• 2 секунд өтінімдер жүйесіне баратын құралға беріледі;
• 4 секунд жауапты жинайтын модельге қалады;
• 500 мс команда тұрып қалған қадамды тоқтату, желілік секірулер және нәтижені клиентке жіберу үшін резервте ұстайды.

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

Жауапта бұл қалай көрінеді

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

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

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

Логтар мен метрикалардан нені қарау керек

Орташа жауап уақыты көбіне жалған тыныштандырады. Бір сұраныс жағдайлардың жартысында 2 секундта өтеді, бірақ әр жүзіншісі дедлайнға тіреліп, бүкіл сценарийді бұзады. Сондықтан тек жалпы уақытқа емес, кідірістің құйрықтарына да қараңыз: шлюз, ретривер, құралдар және модель үшін p50, p95 және p99-ды бөлек қараңыз.

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

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

Сұранысты жазу үшін әдетте бірнеше өріс жеткілікті:

• бүкіл тізбекке арналған trace id;
• қадам атауы және оның миллисекундпен ұзақтығы;
• тоқтау себебі: сәттілік, таймаут, қате немесе ретрай;
• жалпы дедлайн және әр қадам алдындағы қалған уақыт;
• сұранысты кім тоқтатты: пайдаланушы ма, әлде дедлайн бойынша жүйе ме.

Таймауттың себебін әр кезеңде ашық жазған дұрыс. «request timeout» деген жазба аса пайдалы емес. Ал «retriever timeout after 180 ms» немесе «model canceled because 320 ms remained and tool used 900 ms» сияқты жазба әлдеқайда көбірек көмектеседі.

Тоқтатуды да бөлек қарастырған жөн. Пайдаланушы чаттан шықты, желі үзіліп қалды, фронтенд сұранысты жойды, шлюз тізбекті дедлайнмен тоқтатты - бұлар әртүрлі оқиғалар, әрі әрқайсысы әртүрлі жөнделеді. Логта олар жиі араласып кетеді де, команда бірнеше күнді қате проблемамен өткізеді.

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

Жиі жіберілетін қателер

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

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

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

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

Тағы бір үнсіз, бірақ қымбат проблема бар: клиент сұранысы әлдеқашан жабылған, ал бэкенд жұмысын жалғастырып жатыр. Шлюз, құралдар және модель әлі айналып жүр, бірақ жауапты жіберетін ешкім жоқ. OpenAI-үйлесімді API-шлюз үшін бұл әсіресе жағымсыз: токендер, GPU және квоталар ешкім көрмейтін жұмысқа жұмсалады.

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

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

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

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

Содан кейін диагностиканы тексеріңіз. Әр сатының өз қате коды болуы тиіс, сонда команда тізбек дәл қай жерде лимитке тірелгенін бірден көреді. Бір ғана ортақ «timeout» мұнда аса көмектеспейді.

Минималды жиынтық мынадай көрінеді:

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

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

Өзіңізге екі сұрақ қойған пайдалы. Кезекші инженер 30 секундта себебін көре ме? Егер бір қадам тұрып қалса, өнім пайдаланушыға түсінікті жауапты сақтай ала ма? Егер кез келгеніне жауап «жоқ» болса, іске қосуды бір күнге шегеріп, схеманы қайта тазалаған дұрыс.

Кейін не істеу керек

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

Келесі қадам - нақты өлшемдер жинау. Лимиттерді көзбен қоймаңыз. Шлюз, ретривер, құрал және модель үшін p50, p95 және таймаут үлесін қараңыз. Егер ретривер әдетте 120 мс-та жауап беріп, кейде 900 мс-қа созылса, нормалды бюджет құруға осының өзі-ақ жетеді.

Әрі қарай қысқа жоспармен жүріңіз:

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

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

Егер командаға әртүрлі модельдер мен провайдерлердің лимиттерін тез салыстыру керек болса, оларды бірдей интерфейс арқылы сынаған ыңғайлы. Бұл үшін airouter.kz-ті қолдануға болады: api.airouter.kz-ке тек base_url-ды ауыстырып, сол SDK, код және промпттарды бір OpenAI-үйлесімді эндпоинт арқылы іске қосуға мүмкіндік береді. Бұл теорияны емес, тізбектің бірдей жүктеме астындағы мінезін салыстырғыңыз келгенде пайдалы.

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