LLM API үшін ретрайлар: ақауда есепшотты екі еселеп жібермеу жолы

Неліктен ретрайлар есепшотты тез өсіреді

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

Басында бұл ұсақ нәрсе сияқты көрінеді. Команда 15 немесе 20 секундтық таймаут қояды да, кейін retry=3-ті «сақтық үшін» қосады. Қағаз жүзінде бұл ақаудан қорғаныс сияқты. Іс жүзінде ол көбіне шығынды тікелей еселейтін құралға айналады.

Қарапайым мысал: бот 8 000 кіріс токені бар сұраныс жібереді де, жауапты күтеді. Провайдер баяу жауап береді, қолданба сұраныс тұрып қалды деп шешеді және қайталап жібереді. Бірінші шақыру бәрібір аяқталады, екіншісі де модельге жетеді. Пайдаланушыға бір ғана жауап керек, ал бірдей промпт екі рет орындалған болып шығады.

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

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

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

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

Сұранысты қашан қайталау керек, қашан тоқтау керек

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

Әдетте TCP немесе TLS үзілуін, DNS сәтсіздігін, reset қосылымын, 429 кодын және 500, 502, 503, 504 сияқты серверлік қателердің бір бөлігін қайталауға болады. 408 коды және клиенттік таймауттармен абай болған жөн. Алдымен сұраныстың қай жерде үзілгенін анықтаңыз. Ол модельге жетті ме, жоқ па білмесеңіз, соқыр қайталау қауіпті.

400, 401 және 403 кодтарында логика басқа. Мұндай жауаптар көбіне қате JSON, қолдамайтын параметр, жарамсыз API-кілт, құқықтың жетпеуі немесе контекст лимитінің асуы дегенді білдіреді. Мұнда қайталау ештеңені түзетпейді. Тек уақытты және кей жағдайда шотты құртады.

5xx-та да ғажайып күтудің қажеті жоқ. 500, 502, 503 және 504 қателерін көбіне қайталауға болады. Ал 501, үйлеспейтін жауап форматы немесе сұраныс схемасындағы айқын қате әдетте жаңа әрекет емес, кодты түзетуді қажет етеді.

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

Операция түрі шешімді ойлағаннан да қатты өзгертеді. Әдеттегі мәтін генерациясы үшін 429 немесе 503-тен кейін қайталау жиі орынды. Ал сол бір шақыру tool call іске қосса, CRM-де өтінім жасаса немесе хабарлама жіберсе, бүкіл пайплайнды қайталау әрекетті екі рет орындап қоюы мүмкін. Мұнда қадамдарды бөлу керек: модельге бөлек сұраныс, сыртқы әрекетке бөлек операция идентификаторы.

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

Таймауттарды артық дубльсіз қалай қою керек

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

Мәселе көбіне ретрайлардың өзінде емес, клиенттің сұраныс «өлді» деп тым ерте шешім шығаруында.

Бірден екі шекті бөліңіз: қосылым орнатуға кететін уақыт пен модель жауабына кететін уақыт. Қосылым үшін әдетте қысқа аралық жеткілікті. Егер TCP немесе TLS қалыпты желіде 1-3 секунд ішінде көтерілмесе, тағы 20 секунд күткеннің көп мәні жоқ.

Жауапты күту басқаша. Оны тапсырма түрі мен генерация ұзақтығына байлаған дұрыс. Құжаттан бір өріс шығару, жіктеу немесе қысқа JSON-жауап бір диапазонда жатады. Ал кеңейтілген есеп, ұзын чат жауабы немесе жүздеген токендік генерация — басқа диапазонда.

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

Бастапқы мәндер

• Қысқа жауаптар: қосылым 2 секунд, жауап 10-20 секунд.
• Қарапайым чат: қосылым 2 секунд, жауап 30-45 секунд.
• Ұзын генерация: қосылым 2-3 секунд, жауап 60-90 секунд.
• Стриминг: қосылым 2 секунд, алғашқы токен 10-15 секунд, одан кейін чанктер арасындағы бөлек лимит.

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

Бағдар мынадай: таймаут қалыпты сәтті жауаптан сәл ұзақ болуы керек, ал сирек кездесетін баяу жауаптан екі есе қысқа болмауы тиіс. Егер қысқа сұраныстардың 95%-ы 8 секундқа сыйса, 5 секунд емес, 12-15 секунд қойыңыз.

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

Қайталаулар арасындағы кідірісті қалай таңдау керек

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

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

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

Интерактив сұраныстар үшін көбіне мынадай схема жеткілікті:

• бірінші кідіріс: 500-800 мс;
• екінші кідіріс: 1.5-2.5 с;
• үшінші кідіріс: 3-5 с.

Әр кідіріске 15-30% кездейсоқ ауытқу қосқан дұрыс. Сонда екі бірдей сессия бір траекториямен жүрмейді.

Сұранысқа арналған жалпы күту бюджетін де шектеңіз. Егер жауап экрандағы пайдаланушыға керек болса, паузалар мен желілік таймауттарды қоса есептегенде барлығын 8-12 секундтың ішінде ұстаңыз. Фондық өңдеу үшін 30 секунд немесе одан сәл көбірек беруге болады, бірақ жоғарғы шек бәрібір керек. Әйтпесе бір проблемалы сұраныс ұзаққа созылып, кезекті өзімен бірге тартып кетеді.

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

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

Екі рет шот алынудан қалай қорғану керек

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

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

Бір операцияға бір кілт

Әрекет пайда болған сәтте бір ғана idempotency_key жасаңыз да, оны пайдаланушыға, әрекет түріне және жұмыс істеп жатқан нысанға байлаңыз. Мысалы: user_42:reply_ticket:9182. Формат қандай болса да болады, бастысы — тұрақты болсын және ретрайлар арасында өзгермесін.

Жаңа қайталау жаңа кілт жасамауы керек. Бұл — жиі жіберілетін қате. Қолданба таймаут алады да, сұраныс жетпеді деп ойлап, сол бір промптты басқа идентификатормен қайта жібереді. Биллинг үшін бұл көбіне екі бөлек операция сияқты көрінеді.

Өз жағыңызда кілтпен бірге операцияның соңғы күйін де сақтаңыз: статус, пайдаланушы идентификаторы, промпт немесе payload хеші, соңғы жауап немесе оның базаңыздағы сілтемесі. Егер провайдер сәтті нәтиже беріп үлгерсе, жүйе оны қайтара алуы керек және модельді екінші рет шақырмауы тиіс.

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

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

Ретрайларды кезең-кезеңімен қалай баптау керек

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

1. Алдымен артық әрекеттің құнын есептеңіз. Орташа кіріс көлемі мен жауап көлемін алыңыз, модель тарифіне көбейтіңіз де, қате жиілігін қосыңыз. Егер сервис күніне 10 000 сұраныс жасаса, 2% артық қайталаудың өзі есепшотты едәуір өсіруі мүмкін.
2. Сосын қателерді екі топқа бөліңіз. Желілік ақауларды, 429-ды және кейбір 5xx қателерін қайталаңыз. Қате форматқа, тым ұзын промптқа, авторизация қатесіне және басқа финалдық жағдайларға байланысты 4xx-ты қайталамаңыз.
3. Одан кейін әртүрлі таймаут қойыңыз. Қосылым таймауты қысқа болсын. Оқу таймаутын ұзағырақ қойыңыз, өйткені модель баяу жауап беруі мүмкін, әсіресе үлкен промпттарда немесе стримингте. Сұраныстың жалпы дедлайны да керек.
4. Содан кейін қайталаулар арасындағы кідірістер мен әрекет шегін қосыңыз. Әдетте кідірісі өсетін 2-3 әрекет және аздаған кездейсоқ ауытқу жеткілікті.
5. Соңында схеманы жасанды ақаумен тексеріңіз. Бір провайдерді өшіріңіз, жауапты баяулатыңыз немесе тест ортасында 500 қайтарыңыз. Тек сәттілікке емес, қайталаулар санына, токендердің өсуіне және соңғы бағаға да қараңыз.

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

Жұмыс жүктемесінен мысал

Кешке қолдау чатына бірден көп хабарлама келеді. Банк клиенті «Қосымшаға кіре алмай тұрмын» деп жазады. Бэкенд операторға жылдам жауап құрастыру және келесі қадамды ұсыну үшін LLM-ге сұраныс жібереді.

Мәселе модельде емес, клиенттік баптауларда басталады. Сол сәтте провайдер жүктеліп, 18 секундта жауап береді. Сіздің сервис 10 секунд қана күтеді, сұраныс құлады деп санайды да, бірден қайталап жібереді.

Картина мынадай болады:

• 00:00 - бірінші сұраныс провайдерге жіберілді;
• 00:10 - клиенттік таймаут іске қосылды, сервис қайталауды бастады;
• 00:18 - провайдер бірінші сұранысты аяқтап, жауап қайтарды;
• 00:28 - екінші сұраныстың жауабы келді.

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

Мұндай ақау көбіне зиянсыз сияқты көрінеді. Мониторингте бір таймаут және бір сәтті қайталау ғана байқалады. Бірақ шот дәл осындай ұсақ нәрселерден өседі. Үлкен жүктемеде минутына бірнеше артық дубль тез арада көзге көрінетін сомаға айналады.

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

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

Баптауда жиі жіберілетін қателер

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

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

Тәжірибеде адамдар көбіне былай қателеседі: ретрайларды әрі SDK-де, әрі өз сервисінде қосады; жауап басталғаннан кейін стримді қайталайды; кез келген таймаутты модельдің қатесі деп санайды; request_id мен идемпотенттілік кілтін жазбайды; 429 үшін шексізге жуық қайталаулар қалдырады. Осы қателердің әрқайсысы жеке-жеке жағымсыз, ал бірге келгенде хаос тудырады.

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

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

Іске қоспай тұрып қысқа тексеріс

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

Төрт нәрсені тексеріңіз.

Біріншіден, жауап кодтары бойынша ережені бөліңіз. 429 үшін кідіріс пен өсетін кешігуі бар қайталау керек. Кейбір 5xx үшін де қайталауға болады, бірақ лимит қатаңырақ болсын. Көптеген 4xx үшін қайталау қажет емес: ондай сұраныс already бұзылған.

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

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

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

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

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

Ретрай саясатын бірден бүкіл трафикке өзгертпеңіз. Алдымен қатесін өлшеу оңай болатын, жүктемесі түсінікті бір маршрутты таңдаңыз. Ішкі қызметкерлер чаты, support-bot немесе сұраныс көлемі тұрақты бір RAG-сценарий жарайды.

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

Одан кейін қысқа тексеру циклі керек: жаңа ережелерді трафиктің тек бір бөлігіне қосыңыз, өзгеріске дейінгі және кейінгі дубль құнын салыстырыңыз, request_id мен API-кілттер бойынша аудитті тексеріңіз, сосын бір кілт rate limit-ке тіреліп қалмай ма және көрші сервистерде артық қайталауларды іске қоспай ма — соны қараңыз.

Тіпті 2-3 күндік кесінді-ақ айқын сурет береді. Егер бұрын 1000 сұраныстың 70-і артық қайталауға кетсе, ал түзетуден кейін 15-і ғана қалса, әсері бірден бюджеттен де, жауап уақытынан да көрінеді.

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

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