LLM сенімділігі үшін қай тәсіл жақсы?

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

Сенімділікті төрт бөлек уәдемен өлшеу керек

Қолжетімділіктің бір пайызы клиент әртүрлі қабылдайтын ақауларды жасырады. Қате форматтағы екі секундтық HTTP жауабы чатты қолжетімді етпейді, дәл сол сияқты сұрауы кезекте бір минут тұрған мінсіз үйлесімді модель де көмектеспейді. Инфрақұрылымды таңдамас бұрын төрт бөлек көрсеткішті бекітіңіз.

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

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

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

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

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

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

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

Автоматты ауысу ақауды дұрыс таныса, үзілісті қысқартады

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

Желілік тайм-аут, HTTP 429, HTTP 500 және алғашқы токендерден кейін үзілген ағын әртүрлі әрекетті талап етеді. RFC 9110 құжаты 503 жауабындағы Retry-After тақырыбын клиент сұрауды қайталауы тиіс уақыт немесе кідіріс ретінде анықтайды. Бұл пайдалы белгі, бірақ мен оған күту бюджетінің бәрін бермеймін: провайдер клиенттің шыдамын емес, өз күйін сипаттайды. Егер Retry-After клиент мерзімінің қалған бөлігінен ұзақ болса, маршрутизатор басқа рұқсат етілген жолды таңдауы немесе сұрауды басқарылатын қатемен аяқтауы керек.

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

Практикалық бюджет былай көрінеді. Чат арнасы пайдалы жауапты 8 секундтан кешіктірмей көрсетуі керек делік. Негізгі әрекетке алғашқы токенге дейін 2,5 секунд, маршруттау мен жаңа қосылымға 0,5 секунд, резервтік модельге 4 секунд беріп, соңғы секундты жеткізу мен басқарылатын әлсіреуге қалдыруға болады. Бұл сандар әмбебап норма емес, есептеу мысалы. Өз сандарыңызды промпт пен арнаңыздың нақты кідірісінен алыңыз.

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

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

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

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

Үйлесімді API үйлесімді жауапқа кепілдік бермейді

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

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

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

Резервтік жолды негізгі модельді продакшнға жіберетін сол таңдамада тексеріңіз. Мен бірдей сөйлемдерді талап етпей, міндетті инварианттарды белгілеймін:

• JSON еркін мәтінді түзетпей, сол схемадан өтеді.
• Рұқсат етілген құралдар мен оларды шақыру шарттары өзгермейді.
• Жауап жасырын нұсқаулар мен дербес деректерді ашпайды.
• Операторға беру сол қауіп кластары үшін іске қосылады.
• Ұзындық пен тіл қызмет көрсету арнасына сай келеді.

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

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

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

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

GPU резерві сыртқы тапшылықты ішкі кезекке ауыстырады

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

Қуатты тәуліктік орташаға емес, ең жоғары ағынға сай есептеңіз. Жеңілдетілген тексеріс Литтл заңын қолданады: қажетті қатарлық шамамен сұрау жиілігінің орташа қызмет көрсету уақытына көбейтіндісіне тең. Егер апаттық режимде секундына 12 сұрау келіп, модель GPU-ды орта есеппен 3 секунд иеленсе, ауытқу мен қызметтік операцияларды есептемегенде жүйеге шамамен 36 қатар слот керек. Бұл белгілі бір модельдің сипаттамасы емес, формуланың мысалы.

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

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

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

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

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

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

Өңірлік ақау көшірме санын емес, тәуелсіздікті тексереді

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

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

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

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

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

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

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

AI Router провайдерлер арасындағы маршруттауды Қазақстандағы өз GPU-ларындағы open-weight модельдермен, PII бүркемелеумен және аудит логтарымен біріктіреді. Бұл әртүрлі жолдарды бір OpenAI-үйлесімді эндпоинттің артына жинауға мүмкіндік береді, бірақ нақты схеманың тәуелсіздігін оның өңірлік тәуелділіктерін сынау арқылы дәлелдеу қажет.

Клиенттік RTO инфрақұрылымдық RTO-дан ерте басталады

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

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

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

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

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

Жергілікті сақтау талабы рұқсат етілген өңірдегі GPU-ға және бар болса, екінші рұқсат етілген орынға алып келеді. Екінші орын жоқ кезде деректер саясатын бұзатын сыртқы API емес, операторға беру адал резерв болады. API ақауынан кейін қысқа RTO керек болса, алдын ала тексерілген провайдерлер мен жылы жергілікті пулды қолданыңыз.

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

Гибрид схема қалпына келудің екі жолын береді

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

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

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

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

Төмендегі қысқартылған саясат үзіндісі нақты өнімнің синтаксисі емес. Бұл қолданба әзірлеушілері мен эксплуатация арасындағы тексерілетін келісім:

route: support-chat
deadline_ms: 8000
attempts:
  - pool: local-reserved
    first_token_timeout_ms: 2500
    compatibility_group: support-v3
  - pool: external-multi-provider
    first_token_timeout_ms: 3500
    compatibility_group: support-v3
    pii: masked
after_stream_started: return_controlled_error
on_capacity_exhausted:
  disable_tasks: [conversation_summary, draft_variants]
  preserve_tasks: [customer_reply, human_handoff]

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

Гибрид схема бір ашық API-ға сенуден қымбат және бір GPU кластерінен күрделі. Оны қолжетімсіз немесе қате жауаптың құны тұрақты резерв пен тұрақты тексерістерден жоғары болғанда таңдаған жөн. Шағын жүктемеде тәулік бойы эксплуатациясы жоқ, толық пайдаланылмайтын кластерден гөрі тексерілген екі сыртқы провайдер мен операторға адал беру орынды.

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

Оқу-жаттығу модельді емес, жолды бұзуы керек

Қолмен ауыстырғышты тексеру тек конфигурацияны өзгерту құқығын растайды. Пайдалы оқу-жаттығу нақты тәуелділікті өшіріп, резервтік жол арқылы өкілдік диалогтарды өткізіп, клиенттік нәтижені өлшейді.

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

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

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

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

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