Екі модельге хеджделген сұраулар: p95 қашан төмендейді

p95 мәселесі қай жерде пайда болады

p95 мәселесі метрикалар жаман емес сияқты көрінгенімен, қолданушылар бәрібір «баяулау» деп шағымдана бастағанда байқалады. Орташа жауап уақыты 2,4 секунд болуы мүмкін, ал дашбордта бәрі қалыпты көрінеді. Бірақ сұраулардың бір бөлігі кейде 8-12 секундқа созылса, адам есінде дәл сол кідірістер қалады.

Орташа мән кідірістің құйрығын жасырады. Егер 90 сұрау 2 секундта аяқталып, 10 сұрау 10 секундқа созылса, орташа уақыт сирек іркілістердің қаншалықты жағымсыз екенін көрсетпейді. p50 де тыныштандырады: медиана шамамен 2 секунд болып қалады. Ал p95 трафиктің едәуір бөлігі әлдеқашан баяу сезілетінін бірден көрсетеді.

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

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

Кідіріс құйрығы ең қатты жауап бірден керек болатын сценарийлерде байқалады: қызметкерлерге арналған чаттар мен copilot-интерфейстерде, бірнеше LLM шақыруы бар агенттік пайплайнында, онлайн-классификация мен дерек шығаруда, дауыс сценарийлерінде және экран алдында адам күтетін кез келген user-facing функцияларда.

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

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

Хеджделген сұрау деген не

Хеджделген сұрау — сервис кейде бірдей промптты екі модельге жіберіп, p95 бойынша баяу құйрықты күтпейтін схема. Мұндағы басты сөз — «кейде». Сіз әр сұрауды екі рет жібермейсіз, екінші шақыруды ереже бойынша іске қосасыз: мысалы, егер бірінші модель 400 мс ішінде жауап бастамаса немесе сұрау кідіріс қаупі жоғары санатқа түссе.

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

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

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

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

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

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

Екінші шақыру нақты қашан көмектеседі

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

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

Әдетте схема төрт шартта жақсы жұмыс істейді. Негізгі модельде тұрақты емес, сирек іркілістер бар. Қосалқы модель басқа провайдерде немесе басқа стекке сүйенеді де, сол бір ақауды қайталамайды. Дубль 300-800 мс сияқты таймермен, бірден емес, кешіктіріліп қосылады. Және артық шақыру құны сорылып кеткен SLA-дан төмен болады.

Контакт-орталыққа арналған чат-көмекшіні елестетіңіз. 93-97% жағдайда негізгі модель сұрауға тез жауап береді. Бірақ сұраулардың бір бөлігі бірнеше секундқа бөгеліп, оператор кеңессіз қалады. Егер жарты секундтан кейін сол сұрауды екінші модельге жіберіп, бірінші жарамды жауапты алсаңыз, p95 көбіне орташа уақыттан да айқынырақ төмендейді. Ал шығын тек таймер іске қосылған үлесте ғана өседі.

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

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

Схема қашан жай ғана бюджетті жейді

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

Бұл шек тым төмен болғанда болады. Айталық, бірінші модель көбіне 700-900 мс-та жауап береді, ал сіз екіншісін 300 мс-тен кейін-ақ іске қосасыз. Нәтижесінде трафиктің басым бөлігі қайталанады, ал p95 өте аз ғана төмендейді. Орташа баға болса тез әрі күтпегенсіз өседі.

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

Жеке тұзақ — ұзын жауаптар. Қысқа классификаторда қосымша параллель шақыру тиын-тебен тұруы мүмкін. Ал 800-1500 токендік жауап генерациясында сурет басқаша: негізгі шығын енгізуге емес, шығаруға кетеді. Ұзын генерацияны қатаң бақылаусыз хедждесеңіз, инференс шығыны өте тез өседі.

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

Тағы бір жағымсыз сценарий бар: екінші модель жылдамырақ, бірақ сапасы төмен. Пайдаланушы немесе оператор әлсіз нәтижені көріп retry басады, не жүйе өзі қайталайды. Сонда сіз екі параллель сұрауға төлеп қана қоймай, үшіншісіне де төлейсіз. Формалды түрде p95 төмендейді. Ақша мен сапа жағынан бұл — сәтсіздік.

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

Қарапайым мысал: қолдау чаты банк клиенттеріне кеңейтілген жауаптар жасайды. Егер екінші шақыру дерлік әрдайым іске қосылып, cancel кешігіп жатса, төлем шамамен екі есеге өседі. Оның үстіне, жылдамырақ модель көбіне тон немесе факт бойынша мүлт кетсе, команда қосымша қайталауларға да тап болады. Графикте p95 жақсы көрінеді, бірақ бизнес әр диалогқа дерлік көбірек төлейді.

Іске қосу шегін қалай таңдау керек

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

Орташа жауап уақытына сену қиын. Мұндай схема үшін кемінде p95 пен p99 қаралады. Егер орташа 2 секунд болса, ал p95 8 секундқа секірсе, мәселе жалпы жылдамдықта емес, ұзын құйрықта. Дәл сол құйрықты екінші параллель шақыру қысқартуы тиіс.

Алдымен трафикті бөліңіз

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

Трафикті кемінде төрт топқа бөлу жеткілікті: 100-150 токенге дейінгі қысқа жауаптар, орташа жұмыс сұраулары, ұзын генерация мен қысқаша мазмұндау, сондай-ақ қатаң SLA бар тапсырмалар. Содан кейін әр топ бойынша p95 пен p99-ды жеке есептеңіз. Көбіне хедж тек бір категорияда керек болып, қалған трафик онысыз жақсы жұмыс істейді.

Өтелу нүктесін іздеңіз

Іске қосу шегі — екінші сұрауды қашан жіберетініңізді анықтайтын күту уақыты. Шек тым ерте болса, шығынды дерлік екі еселейді. Тым кеш болса, p95-ті қысқартуға үлгермейді.

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

Егер 800 мс шегі p95-ті 300 мс-ке түсірсе, бірақ екінші шақыру трафиктің 35%-ында іске қосылса, схема тым қымбат болуы мүмкін. Егер 1400 мс шегі p95-ті шамамен сондай мөлшерде қысқартып, ал дубль тек 8% жағдайда керек болса, бұл қалыпты компромисске көбірек ұқсайды.

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

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

Модель жұбын қалай таңдау керек

Хедждеу үшін алынған модель жұбы қағазда ғана жақсы көрінбеуі тиіс. Әуелі бірдей нақты промпттар жиынын екі модельден өткізіп, орташа кідірісті емес, құйрықты салыстырыңыз. Көбіне А моделі медиана бойынша жылдамырақ, бірақ ұзын жауаптарда p95-те жиі сүрінеді. B моделі қалыпты жағдайда сәл баяуырақ болуы мүмкін, бірақ жүктеме түскенде бірқалыптырақ. Мұндай жұп екі бірдей «жылдам» модельден жақсырақ.

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

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

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

Ортақ failure point-і бар екі модельді қатар қоймаңыз. Егер олар бір провайдерде, бір өңірде немесе бір кезекте тұрса, олардың кідірісі көбіне бірдей өседі. Онда екінші шақыру p95-ті түсірмейді, тек есепті екі еселейді. Әртүрлі failure domain-дерден модель алған дұрыс.

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

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

Схеманы қадам-қадаммен қалай енгізу керек

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

Келесі қадам — схеманы тар ауқымда қосу. Екінші шақыруды бірден бүкіл ағынға қоспаңыз. 1-5% трафиктен бастаңыз да, қарапайым шек қойыңыз: екінші тармақ бірінші жауап 600-800 мс ішінде басталмаса ғана қосылады. Қысқа сұраулар үшін шек әдетте төменірек, ұзындары үшін жоғарырақ.

1. Бір сценарийді таңдаңыз. Бүкіл өнімді емес, p95 пайдаланушыға кедергі келтіріп тұрған бір сұрау түрін алыңыз: қолдау чаты, білім базасын іздеу немесе қысқа жауап генерациясы.
2. Жеңімпазды баптаңыз. Бір модель жарамды жауап берген сәтте немесе ағынды бастағанда оны жеңімпаз деп есептеп, екінші тармақты бірден тоқтатыңыз.
3. Қатаң лимит қойыңыз. Хедждеу үлесін, күндік шығынды және бір кілтке не қызметке рұқсат етілетін параллель дубль санын шектеңіз.
4. Метрикаларды бөліңіз. Бірінші және екінші тармақ бойынша деректерді бөлек сақтаңыз: кім жеңді, кім тоқтады, алғашқы жауап қанша уақыт алды, қанша токен жанып кетті және қателер қайда болды.
5. Аптадан аптаға салыстырыңыз. Тек p95-тің төмендеуін емес, сол ұтыстың бағасын да қараңыз.

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

Нәтижені салқынқандылықпен бағалаңыз. Егер p95 25-30% төмендеп, апта сайынғы шығын 5-8% өссе, схема, бәлкім, ақталады. Егер ұтыс 10%-дан аз болып, шығын 20% және одан жоғары өссе, екінші шақыруды тек ең маңызды сұрауларға ғана қалдырған дұрыс.

Өндірістегі қарапайым сценарий

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

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

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

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

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

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

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

Ең жиі қате — жауаптың орташа уақытына қарап қуану: 2,1 секунд болды, 1,8 секундқа түсті. Бірақ пайдаланушыларды орташа мән ашуландырмайды. Оларды құйрық ашуландырады: чаттарды бұзатын, timeout-тарды іске қосатын және воркерлерді босатпай ұстайтын 8-12 секундтық сирек жауаптар. Егер p95 пен p99-ды бөлек есептемесеңіз, хедждеу тіпті пайдасы шамалы жерде де табысты идея сияқты көрінуі мүмкін.

Екінші қате — іске қосу шегін тым ерте қою. Егер екінші модель 200-300 мс-та қосылса, сіз құйрықты сақтандырмайсыз, дерлік әрдайым трафикті көшіресіз. Графиктегі кідіріс жақсы көрінуі мүмкін, бірақ инференс шоты дерлік сызықты өседі. Кәдімгі чат үшін бұл көбіне жаман мәміле.

Үшінші қате — модельдерді әртүрлі жағдайда салыстыру. Команда system prompt-ты, жауап шаблонын немесе генерация параметрлерін өзгертіп алып, кейін бір модель жылдамырақ не тұрақтырақ деп шешеді. Мұндай тест ештеңені дәлелдемейді. Алдымен бір промпт нұсқасын, бірдей temperature-ны, бірдей max tokens-ты және бірдей сұраулар жиынтығын бекітіңіз. Әйтпесе сіз модельдерді емес, екі бөлек сценарийді салыстырасыз.

Тағы бір қателік — провайдер лимиттерін ұмыту. Параллель шақырулар негізгі модель әлсіреген сәтте дәл сол жерде секіріс береді. Егер провайдерде қатаң rate limit болса, сұраулардың екінші толқыны 429-ға, кезекке немесе каналдың нашарлауына тіреледі. Онда p95 төмендемейді, керісінше өседі.

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

Іске қоспас бұрын бес нәрсені тексерген пайдалы:

• орташа уақыт емес, p50, p95 және p99-ды есептеңіз;
• хедж шын мәнінде қосылған сұраулар үлесін қараңыз;
• екі модель үшін бірдей промптты бекітіңіз;
• аяқталған және тоқтатылған шақыру құнын бөлек есептеңіз;
• rate limit-ті тыныш емес, ең жоғары жүктемеде тексеріңіз.

Осының бәрінен кейін p95 айтарлықтай төмендеп, дубльдер үлесі қалыпты болса, схемаға мән бар. Болмаса, екінші шақыру тек бюджетті жейді.

Жылдам тексеру және келесі қадамдар

Мақсат алдын ала келісілмесе, хедждеу эксперименті команданы оңай адастырады. Біреулерге p95 2,5 секундтан аспай, баға 10%-дан артық өспеуі керек. Басқаларға p99 немесе таймауттар үлесі маңызды. Алғашқы тестке дейін SLA мен шығын шегін бекітіңіз, әйтпесе екінші шақыру тез арада қымбат әдетке айналады.

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

Қысқа жоспар былай көрінеді:

• мақсатты SLA-ны жазыңыз: p95, p99, таймауттар үлесі және тест трафигі үшін баға шегі;
• дубльді іске қосу ережесін анықтаңыз: таймер бойынша, сұрау түрі бойынша, кіріс көлемі бойынша немесе нақты модель бойынша;
• механиканы тексеріңіз: жеңілген сұрауды тоқтату, жауапты дедупликациялау, бірегей сұрау ID-і және бюджет лимиті;
• схеманы бірнеше күнге 5-10% трафикте іске қосып, p95, p99, орташа баға және тоқтатылған дубльдер үлесін салыстырыңыз.

Тесттен кейін қандай әрекет жасайтыныңызды алдын ала шешіп қойған пайдалы. Егер p95 20% түсіп, баға 4% өссе, схеманы кеңейтуге болады. Егер p95 дерлік өзгермей, шығын екі еселенсе, тесттің өзі жауап беріп қойды: дубль керек емес.

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