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

Банкке жеткізушінің ішкі процесі дұрыс жұмыс істеп тұрғанын емес, банк қолданбасының шекарасындағы нәтижені өлшейтін SLA қажет. Егер шлюз сұрауды қабылдап, бірақ модель уақытында жауап бермесе, нақты қай компонент бұзылғанына қарамастан бизнес үшін бұл бас тарту болады.
Сондықтан қолжетімділік пайызының өзі ештеңеге жуық пайда бермейді. Сатып алу тобы қолжетімділік формуласын, кідіріс шегін, жауап сапасын, RTO-ны, қолдау қызметінің жауап беру уақытын, сыртқы тәуелділіктер ережелерін және бұзушылық салдарын салыстыруы керек. Мен 99,95% деген тартымды көрсеткіші бар, бірақ жеткізуші іс жүзіндегі кез келген ақауды есептен шығара алатын шарттарды көрдім. Мұндай пайыз ештеңеге кепіл болмайды.
Қолжетімділік күнтізбелік ай бойынша және сәтті сұраулармен есептеледі
Жұмыс істейтін міндеттеме былай жазылады: әр күнтізбелік айдағы жарамды сұраулардың келісілген үлесі белгіленген уақыт шегіне дейін сәтті жауаппен аяқталуы тиіс. Жарамды сұрау дегеніміз - келісілген лимиттер шегінде жұмыс істейтін түпкі нүктеге жіберілген банктің дұрыс сұрауы. Бұл жерде өлшем бірлігі ішкі сервердің жұмыс істеген минуты емес, сұрау болады.
Негізгі формула шарттың қосымшасында тікелей жазылуы керек:
Availability = (Eligible Requests - Failed Requests) / Eligible Requests * 100%
Сәтсіз сұрауларға 5xx жауаптары, байланыс қабылданғаннан кейінгі желі үзілістері, шлюз тайм-ауттары, қате пішімделген жауаптар және шартта көрсетілген шектен кеш келген жауаптар жатады. Бос денесі бар 200 жауабын, үзілген ағынды немесе келісілген схема тексерісінен өтпеген JSON-ды сәтті деп санауға болмайды. Әйтпесе жеткізуші метриканы жақсартады, ал банк қателерді бұрынғыдай өңдей береді.
RFC 9110 HTTP мәртебелерін кластарға бөліп, 5xx кодтарын сервер қатесіне жатқызады. Бұл жақсы бастапқы нүкте, бірақ LLM үшін жеткіліксіз: тасымалдаудың сәтті болуы нәтиженің қолдануға жарамды екенін білдірмейді. Шартта ағындық жауаптар бөлек сипатталуы керек, өйткені бірінші токен мен толық аяқталудың сәттілік сәті екі түрлі. Кәдімгі жауап үшін сәттілік толық әрі дұрыс дене алынғаннан кейін белгіленеді. Ағын үшін қолжетімділікті сәтті басталу бойынша есептеуге болады, бірақ аяқтау оқиғасына дейінгі үзіліс ағынның аяқталуы туралы бөлек метрикаға кіруі тиіс.
Айлық терезені тоқсандық тереземен алмастыруға болмайды. Тоқсандық орташа есеп ауыр қаңтар ақауын жақсы ақпан және наурыз көрсеткіштерінің арасында жасырады, ал банк процесі дәл қаңтарда зардап шекті. Есептің уақыт белдеуі мен айдың басталу және аяқталу сәті де алдын ала бекітіледі, мысалы Алматы уақытымен. Әйтпесе екі тарап бір оқиғаны әртүрлі кезеңге жатқызуы мүмкін.
Шлюз әртүрлі контурларға қызмет көрсетсе, бір жалпы сан жеткіліксіз. Сатып алу құжаттары өнімдік API, басқару панелі және кілтті кері қайтару сияқты маңызды әкімшілік операциялар үшін бөлек көрсеткіштерді талап етуі керек. Панельдің істемеуі орындалып жатқан сұрауларды әрдайым тоқтатпайды, бірақ әшкереленген кілтті жылдам жаба алмау басқа тәуекел туғызады. Бұл оқиғаларды бір пайызға араластыруға болмайды.
Бағдар ретінде, 30 күндік айдағы 99,9% шамамен 43 минут 12 секунд, 99,95% шамамен 21 минут 36 секунд, ал 99,99% шамамен 4 минут 19 секунд қолжетімсіздікке жол береді. Бұл сандар минутпен өлшегенде ғана мағыналы. Сұраулар бойынша есептеуде рұқсат етілген нақты залал трафикке байланысты, сондықтан шартта бас тарту үлесі де, үздіксіз оқиғалардың балама ұзақтығы да көрсетілуі керек.
p95 бірінші токен мен толық жауап үшін бөлек белгіленеді
p95 шегі нақты операцияны, модель класын, кіріс көлемін, шығыс көлемін және өлшеу нүктесін сипаттауы керек. Осы шарттарсыз «p95 екі секундтан аз» деген сөйлемді тексеру мүмкін емес: қысқа жіктеу белгісін жасау мен мың токендік жауапты құруды салыстыруға келмейді.
Ағындық генерация үшін банкке кемінде екі метрика керек:
- time to first token, шлюз толық сұрауды қабылдағаннан алғашқы мағыналы бөлікке дейінгі уақыт;
- time to last token, сұрауды қабылдағаннан ағын дұрыс аяқталғанға дейінгі уақыт;
- қатаң тайм-ауттан асқан сұраулар үлесі;
- міндеттеме p95-ке байланса да, үлестірімнің ауыр шетін көрсететін p99.
Ағынсыз шақыруларда толық ұзақтық өлшенеді. Метрикаларды барлық сұрауды араластырмай, келісілген себеттерге бөледі, мысалы кірісте 2 000 токенге дейін және шығыста 500 токенге дейін. Әйтпесе қысқа сұраулардың көп саны ұзақ операциялардың кідірісін жасырады. Барлық модельден бірдей шек талап етудің қажеті жоқ: жылдам жіктеуіш пен үлкен reasoning-модельге әртүрлі профиль қажет.
Процентиль қысқа аралықтағы барлық жарамды сұраулар бойынша есептеліп, айлық нәтиже алдын ала жазылған ережемен біріктіріледі. Күнделікті p95 көрсеткіштерін орташалауға болмайды: процентильдің орташа мән қасиеті жоқ, сондықтан мұндай есеп үлестірімді бұрмалайды. Жеткізуші әр себет үшін айлық бастапқы іріктемеден p95 есептеуі немесе бакеттердің шекарасы мен бақылаулар санын қамтитын келісілген гистограмманы жариялауы керек.
Тексеруге болатын шарттың үлгісі мынадай:
Для запросов класса Interactive с входом <= 2 000 токенов и лимитом
выхода <= 500 токенов не менее 95% подходящих потоковых запросов
за каждые 15 минут получают первый содержательный токен за <= 1,8 с.
Запросы, завершившиеся 5xx или тайм-аутом, включаются в выборку
с длительностью, равной порогу тайм-аута.
Соңғы жол маңызды. Сәтсіз сұрауларды кідіріс есебінен алып тастаса, апат кезінде p95 жақсарып кетуі мүмкін, өйткені ең баяу шақырулар қате ретінде іріктемеден жоғалады. Бұл бақылау жүйелерінде жиі кездесетін қате, ол жылдамдық метрикасын бас тартқаны үшін берілетін сыйақыға айналдырады.
Банк сағаттардың қай жерде орналасатынын да анықтауы керек. Практикалық нұсқа - шлюз кірісіндегі серверлік метрика және банктің екі нүктесінен алынған тәуелсіз клиенттік метрика. Серверлік сан компоненттерді талдауға көмектеседі, клиенттік сан қолданба көрген нәтижені көрсетеді. Айырмашылық келісілген рұқсаттан асса, бір тараптың дерегін автоматты түрде дұрыс деп танымай, бірлескен тексеру басталады.
Маршруттау сапасы сұраудың сәттілігіне кіреді
LLM шлюзы жылдам әрі техникалық тұрғыдан дұрыс жауап беріп, маршрут бойынша міндеттемені бұзуы мүмкін: тыйым салынған провайдерді таңдайды, ел шегінен шығады, үйлеспейтін модельді қояды немесе сұрау параметрлерін жоғалтады. Банк үшін бұл «функцияның нашарлауы» емес, сәтсіз операция.
Шартта маршруттау саясаттарының тізілімі қажет. Әр профиль үшін рұқсат етілген модельдер мен провайдерлер, өңдеу және сақтау географиясы, резервтік маршруттың рұқсаты, қайталау санының шегі және барлық нұсқа таусылғандағы әрекет көрсетіледі. Деректер саясаты тыйым салса, жеткізуші қолжетімділікті сақтау үшін сұрауды басқа өңірге үнсіз жібермеуі керек. Өңдеу тәртібін бұзған сәтті жауаптан гөрі, себебі көрсетілген анық бас тарту дұрыс.
Тасымалдау сәттілігі мен саясат сәттілігін ажыратқан пайдалы. Біріншісі дұрыс жауаптың келгенін көрсетеді. Екіншісі шлюздің банк ережесіне сай маршрут таңдағанын растайды. Әр операция журналында сұрау мазмұнын ашпай, сұрау идентификаторы, таңдалған маршрут, модель, нәтиже санаты, ұзақтық және іске қосылған саясат сақталуы керек. Мұндай жазбалардың пішімі мен қолжетімділік мерзімі бөлек келісіледі.
Қабылдау тексерісі қайталауға болатын ретпен орындалуы мүмкін:
- Банк бір рұқсат етілген географиядағы екі модельге рұқсат беретін профиль жасайды.
- Команда келісілген тәсілмен негізгі маршрутты сынақ пулынан шығарады.
- Шлюз сұрауларды рұқсат етілген резервке ауыстырып, ауысу себебін жазады.
- Команда екі маршрутты да бұғаттап, үшінші провайдерге жасырын шығудың орнына анық бас тарту алады.
- Банк сұрау идентификаторларын маршруттау журналымен және клиенттік өлшемдермен салыстырады.
Бұл тексеріс таныстырылымдарда жиі өшірілетін айырманы ашады: ақауға төзімділік кез келген қолжетімді жолға емес, алдын ала рұқсат етілген жолға ауысуды білдіреді. Мұндағы қатенің салдары бірнеше секунд кідіріспен емес, деректер мен модельге қойылған талаптармен өлшенеді.
RTO расталған оқиғадан басталады, ал RPO әрдайым қажет емес
LLM шлюзы үшін RTO - белгілі бір маңыз деңгейіндегі оқиға расталғаннан кейін келісілген функцияны қалпына келтіруге берілетін ең ұзақ уақыт. Оны қолдау қызметінің алғашқы жауап уақытымен алмастыруға болмайды. Инженер он минутта жауап беріп, сервис төрт сағат бойы қолжетімсіз болып қалуы мүмкін.
Басталу нүктесі нақты бекітіледі: жеткізушінің мониторингі бұзушылықты анықтаған сәт пен банк апаттық арна арқылы жеткілікті дәлел жіберген сәттің ертерегі алынады. Жеткізуші оқиғаны өзі «мойындағанша» күтуді талап ету басталу уақытын жылжытуға мүмкіндік береді. Аяқталу нүктесі - бір сәтті сұрау емес, метриканың бақылау терезесі бойы, мысалы 15 минут тұрақты қалпына келуі.
RTO функциялар бойынша тағайындалады. Өнімдік сұрауларды орындау үшін ол шығындардың тарихи аналитикасына қарағанда қатаңырақ болады. Кілттерді кері қайтару және маршрутқа тыйым салуды қолдану үшін бөлек шек қажет болуы мүмкін, өйткені бұл операциялар қауіпсіздікке қатысты. Шарт толық қалпына келу мен функцияның уақытша төмендеуін ажыратуы керек. Апаттық режим аз өткізу қабілетімен бір рұқсат етілген модельді ғана сақтаса, бұл оқиғаның жабылуы емес, ішінара қалпына келу.
RPO басқа сұраққа жауап береді: қалпына келгеннен кейін күйдің қандай көлемін жоғалтуға болады. Күй сақтамайтын прокси үшін RPO қолданылмауы мүмкін. Бірақ шлюзде маршрут конфигурациялары, кілт саясаттары, лимиттер, аудит журналдары және тұтыну деректері болуы ықтимал. Күйдің әр түріне нақты RPO немесе себебі көрсетілген «қолданылмайды» жазбасы керек. Күй сипатталмай берілген жалпы RPO=0 уәдесі мықты естіледі, бірақ тексерілмейді.
Қалпына келтіру жоспары шартқа қол қойылғанға дейін сыналып, кейін келісілген мерзімділікпен тексерілуі керек. Банкке күні, сценарийі, анықтау мен қалпына келтірудің нақты уақыты, ауытқулар және аяқталған іс-шаралар қажет. Уақыт шкаласы жоқ «сынақтан өтті» есебі RTO орындалғанын дәлелдемейді.
Қолдау қызметі жауап беруге, жаңартуға және инженерлерді қосуға міндеттенеді
Қолдау қызметінің жауап уақыты процестің алғашқы қадамы ғана. Маңызды оқиға үшін шарт төрт бөлек таймер орнатуы керек: өтінімді растау, кезекші инженерді қосу, жаңарту жиілігі және RTO бойынша қалпына келу.
Маңыз деңгейлері жеткізушінің пікірімен емес, байқалатын әсермен сипатталады. P1 өнімдік API толық қолжетімсіздігін, жаппай қателерді, маршруттау саясатының расталған бұзылуын немесе шұғыл қорғаныс әрекетін орындай алмауды білдіруі мүмкін. P2 - толық бас тарту жоқ, жарамды айналма жолы бар елеулі нашарлау. Жеткізуші басымдықты біржақты төмендете алса, ол белгіні ауыстырып, SLA-ны қағаз жүзінде орындайды. Деңгейді төмендетуге тек жазбаша негіздеме мен айналма жолдың істейтінін дәлелдегенде рұқсат беріледі.
Әр деңгейге арналған кестеде мыналар болуы тиіс:
- қамту режимі, мысалы P1 үшін 24x7, P3 үшін жұмыс уақыты;
- өтініш арнасы және портал істемегендегі резервтік арна;
- растау уақыты және техникалық маманды қосу уақыты;
- мазмұнды жаңартулар аралығы;
- себеп туралы алдын ала және түпкілікті есеп мерзімі.
«Мазмұнды жаңарту» жаңа деректерді қамтиды: ағымдағы әсер, қабылданған шара, тексеру нәтижесі, келесі бақылау сәті және өзгерген болжам. «Жұмыс істеп жатырмыз» деген автоматты хат таймерді тоқтатпайды. P1 үшін банкке телефон немесе басқа синхронды апаттық арна қажет, өйткені істемей тұрған қолдау панелінің ішіндегі өтінім пайдасыз.
Шартта кезекшінің өкілеттігі де жазылады. Бірінші желі өтінімді тек кезекке жібере алса, 15 минутта жауап беру уәдесінің пайдасы аз. Шлюз телеметриясын көретін және маршрутты ауыстыра алатын, ақаулы компонентті шектейтін немесе қалпына келтіруді бастайтын инженерді қосу мерзімі қажет. Ұзақ P1 кезінде оқиға басшысы мен техникалық иесінің қашан қосылатыны көрсетіледі.
Себепті талдау «сыртқы провайдер ақауы» деген сөйлеммен шектелмеуі керек. Дұрыс есеп уақыт шкаласын, зардап шеккен сұраулар мен саясаттарды, тікелей себепті, резервтің неге істемегенін, иелері мен мерзімдері көрсетілген әрекеттерді және түзетуді тексеру тәсілін қамтиды. Банкке жеткізушінің ішкі құпиялары керек емес, бірақ тәуекелдің қайталану ықтималдығын бағалауға жеткілікті дерек қажет.
Сыртқы провайдер әмбебап ерекшелікке айналмауы керек
Шлюз бірнеше маршрутты басқаруды сатады, сондықтан сыртқы модельдің істемеуін SLA-дан автоматты түрде алып тастауға болмайды. Шлюздің мәні дәл осындай ақау кезінде көрінеді: мәселені анықтау, рұқсат етілген баламаны таңдау немесе басқарылатын бас тартуды анық қайтару. Сыртқы провайдерлерді толық алып тастау банкке жұқа прокси қабатының ғана SLA-сын қалдырады, ал банк бүкіл тізбектің нәтижесін сатып алады.
Әділ ереже басқарылатын және басқарылмайтын оқиғаларды ажыратады. Шлюз жеткізушісі провайдерді таңдау, оның күйін тексеру, қайталау, резервтеу, саясатты сақтау және қатені дұрыс жеткізу үшін жауап береді. Ол белгілі бір сыртқы модель ешқашан істен шықпайтынын уәде етуге міндетті емес. Бірақ шарт резервтік маршрутқа рұқсат беріп, шлюз оны уақытында пайдаланбаса, оқиға шлюз қолжетімділігінің есебіне кіреді.
Ерекшелікті мына шарттардың бәрі бір уақытта орындалғанда ғана қабылдауға болады:
- оқиға шлюз бақылауынан толық тыс жерде пайда болды;
- барлық келісілген әрі рұқсат етілген резерв те қолжетімсіз болды немесе банк саясаты оларды тыйды;
- шлюз оқиғаны дұрыс анықтап, қарастырылған әрекеттерді орындады;
- жеткізуші банкке идентификаторлар, уақыт шкаласы және сыртқы себептің дәлелдерін берді;
- ерекшелік бүкіл күнді емес, сыртқы оқиғаның нақты уақытын ғана қамтиды.
Жеткізуші сыртқы провайдердің жоспарлы жұмысын алдын ала біліп, маршрутты ертерек ауыстыра алса, оны есептен шығармауы керек. Сатып алынған квотаның таусылуы, модель провайдерімен шарттың мерзімі бітуі немесе лимиттердің қате конфигурациясы да шлюз жеткізушісінің жауапкершілігінде қалады. «Үшінші тарап» ұйымдық шекараны сипаттайды, бірақ бақылаудың жоқтығын дәлелдемейді.
Банк бір модельді немесе бір провайдерді өзі талап ететін pinning режимі бөлек келісіледі. Бұл жағдайда шлюз өз қабатының дұрыс жұмыс істегенін дәлелдесе, сыртқы қолжетімсіздікті бөлек көрсеткішке шығаруға болады. Сатып алу тобы екі санды салыстыруы керек: басқарылатын пулдың end-to-end қолжетімділігі және бекітілген маршрут кезіндегі шлюздің өз қолжетімділігі. Біріншісі алынған сервисті көрсетеді, екіншісі себепті анықтауға көмектеседі.
Форс-мажор қалыпты интернет ақауларын, провайдердің шамадан тыс жүктелуін немесе қуат жетіспеуін қайталамауы керек. Бұл техникалық оқиғалар жиналатын себет емес, айрықша заңдық санат. Уәде етілген пайыздан кейінгі ерекшеліктер тізімі ұзарған сайын, сол пайыздың құны азаяды.
«Бұлттық және телекоммуникациялық операторлардың әрекеттері» деген тұжырымға ерекше назар қажет. Ол кең жазылса, сервис жұмыс істейтін инфрақұрылымның басым бөлігін есептен шығарады. Банк оны жеткізуші резервтеу, қуат қоры немесе маршрутты ауыстыру арқылы орынды түрде алдын ала алмаған оқиғалармен шектеуі тиіс. Архитектура екінші байланыс арнасын уәде етсе, бір арнаның қалыпты ақауы бұл шартқа сай келмейді.
Сыртқы себептің дәлелі жария күй парағының суретімен шектелмейді. Мұндай бет үшінші тараптың мәлімдемесін ғана растайды және оқиға уақытын жиі дөңгелектейді. Шлюздің өз анықтау белгілері, жауап санаттары, зардап шеккен рұқсат етілген маршруттар тізімі және автоматиканың әрекеттері қажет. Банк біріктірілген деректерді қабылдай алады, бірақ уақыт аралығы мен себептік байланыс тексерілуі тиіс.
Провайдер API-ды, лимиттерді немесе пайдалану ережелерін өзгертсе, жауапкершілік хабарлау мерзіміне және шлюздің үйлесімділікті сақтау туралы шарттық міндетіне байланысты. Кенеттен жасалған үйлесімсіз өзгеріс расымен оның бақылауынан тыс болуы мүмкін. Берілген мерзім бойы жарияланған көшу талабын елемеу шлюзді басқару аймағына жатады. Бұл шекараны сыртқы API алғашқы рет жаңарғанға дейін жазып қойған дұрыс.
Сервистік кредиттер бұзушылық ауырлығынан жылдамырақ өсуі керек
Сервистік кредит банктің залалын өтемейді. Ол залалды дәлелдеуді талап етпейтін автоматты қаржылық салдар туғызады. Сондықтан кредит жеткізушіге сезілетіндей болуы және шарт пен заң рұқсат еткен жағдайда банктің басқа қорғаныс құралдарын талап ету құқығын алмастырмауы керек.
Деңгейлер шағын «қолдау төлемінен» емес, зардап шеккен сервис үшін айлық төлемнен есептеледі. Мысалы, шарттағы міндеттемеден төмен, бірақ 99,90%-дан төмен емес нәтиже зардап шеккен сервис төлемінің 5% кредитін беруі мүмкін. 99,50%-дан 99,90%-ға дейінгі деңгей 10%, 99,00%-дан 99,50%-ға дейінгі деңгей 20%, ал 99,00%-дан төмен нәтиже 30% беруі мүмкін. Шектің дәл мәні дау тудырмауы үшін аралықтар бір-бірімен қабаттаспауы керек.
Бұл әмбебап сандар емес және оларды есепсіз қабылдау туралы кеңес те емес. Банк деңгейлерді өз архитектурасымен, төлем көлемімен және резервтік режим құнымен салыстыруы керек. Қағида мынада: ауыр бұзушылық пропорциядан да үлкен кредит береді. Кез келген нәтиже үшін бірдей 5% мінез-құлықты өзгерте қоймайды.
«Зардап шеккен сервис» ұғымы да нақты анықталуы керек. Бір өнімдік маршрут бірнеше банк қолданбасына қызмет көрсетсе, ақау бүкіл шлюзді тоқтатқанда жеткізуші бір істемеген модельдің бағасын ғана есеп негізі етпеуі тиіс. Керісінше, сынақ профиліндегі жергілікті ақау бүкіл жылдық төлемге кредит беруге міндетті емес. Шарт қосымшасында шот компоненттері өлшенетін сервистермен және маңыз профильдерімен алдын ала байланыстырылуы керек.
Қолжетімділік кредитін рұқсат етілген ерекшеліктерді қолданғаннан кейін есептеу ыңғайлы, бірақ ерекшеліктердің өзі бөлек тексеріледі. Жеткізуші бастапқы бас тарту санын, әрбір алып тастауды және соңғы іріктемені көрсетуі керек. Тек ақырғы пайызды жариялайтын формула кредиттің даулы техникалық жұмыс немесе сыртқы ақау салдарынан азайтылғанын түсінуге мүмкіндік бермейді.
Валюта мен есеп айырысу тәртібі де орындалуға әсер етеді. Шартта кредиттің қай шотта көрінетіні, оны келесі төлемге есептеуге болатыны және шарт сол шотқа дейін тоқтатылса не болатыны жазылады. «Кредит жеткізушінің шешімі бойынша беріледі» деген тұжырым автоматты салдарды жояды, сондықтан оны алып тастау керек.
p95, RTO және қолдау міндеттемелерінің бұзылуын қолжетімділік ішінде ерітуге болмайды. Оларға бөлек кредиттер немесе түсінікті аудару ережесі бар бұзушылық ұпайлары қажет. API уақыттың 99,99%-ында қолжетімді болып, бірақ әр кеш сайын клиенттік процесс үшін тым баяу жауап беруі мүмкін. Мұндайда жеткізуші уәде етілген сапаны орындамады. Жалпы кредиттерге шек қоюға болады, бірақ ол бірнеше тәуелсіз бұзушылықтың салдарын жоймауы тиіс.
Автоматты есептеу «бес жұмыс күні ішінде талап жіберіңіз» деген рәсімнен жақсы. Жеткізушіде телеметрия бар, сондықтан ол есепті айлық есепке қосуы керек. Банк өз өлшемдерімен сандарға дау айту құқығын сақтайды. Шарт бәрібір өтінішті талап етсе, мерзім орынды болуы және жасырын ақау сәтінен емес, толық есеп алынғаннан кейін басталуы керек.
Қайталану бір кредиттен маңызды. Шарт қайталанған бұзушылықтан кейін түзету жоспарын талап ету құқығын және жылжымалы кезеңдегі келісілген ауыр бұзушылық санынан кейін айыппұлсыз шығу құқығын беруі керек. Әйтпесе жеткізуші жүйелі нашар сервис үшін жылдар бойы шағын жеңілдік бере алады.
Есеп әр санды қайта есептеуге мүмкіндік беруі керек
Жасыл көрсеткіші бар айлық PDF SLA бақылауына жарамайды. Банк командасы нәтижені қайталай есептей алатын деректер алуы керек: жарамды сұраулар саны, санаттар бойынша қателер, кідіріс үлестірімі, есептен шығарылған аралықтар, оқиғалар және қолданылған кредиттер.
Ең аз агрегат жолы мынадай болуы мүмкін:
{"period":"2026-06","route_profile":"retail-assistant-prod","eligible":1842231,"failed":1320,"ttft_p95_ms":1420,"timeout_count":284,"excluded":91,"exclusion_reason":"bank-approved-maintenance"}
Мұндағы сандар нормативті емес, пішінді көрсетеді. Агрегатқа шығарылған оқиғалардың идентификаторлар тізімі және есептеу ережесінің нұсқасы керек. Сұрау идентификаторлары промпт мәтінін бермей-ақ, банкке іріктемені салыстыруға мүмкіндік береді. Жеткізуші метрика алгоритмін өзгертсе, жаңа нұсқа келісілгеннен кейін ғана қолданылады және өткен кезеңдерді қайта жазбайды.
Екі тараптың сағаттары синхрондалып, уақыт пішімі мен рұқсат етілген айырма бекітіледі. Банк өзінің синтетикалық тексерістерін және қолданба метрикаларын сақтайды. Синтетика нақты трафик аз кезде толық ақауды анықтайды, ал нақты сұраулар қалыпты жүктемедегі әсерді көрсетеді. Бірде-бір дереккөз жалғыз ақиқат деп жарияланбауы керек.
Дау кезінде тараптар алдымен жарамды сұрау анықтамасын, уақыт терезелерін және идентификаторларды салыстырып, содан кейін бастапқы оқиғаларды тексереді. «Жеткізуші деректері түпкілікті» деген тұжырым тәуелсіз бақылауды сәндік рәсімге айналдырады. Салыстыру мерзімін, экспорт пішімін және сирек кездесетін шешілмейтін дауға тәуелсіз сарапшыны тарту тәртібін бекіткен дұрыс.
Деректерді шексіз сақтау міндетті емес, бірақ мерзім банк бақылауына, тексерулерге және шарт бойынша талап қою кезеңіне жетуі керек. Нақты мерзімді тәуекел, қауіпсіздік және жазбалар мамандары бірге таңдайды. SLA есептің қолжетімділігін және жарияланған нұсқаның өзгермеуін бекітуі тиіс.
AI Router бір OpenAI-үйлесімді түпкі нүкте, сыртқы провайдерлер мен өзінде орналастырылған модельдер арасындағы маршруттау, сондай-ақ аудит журналдары мен кілт деңгейіндегі лимиттерді ұсынады. Банк сатып алуы бұл мүмкіндіктерді бәрібір нақты SLI, шек және дәлелге айналдыруы керек, өйткені функциялар тізімі міндеттеме емес.
Қабылдау сынағы шартты сынақ стендінде бұзуға тырысуы керек
Қол қоюға дейін сатып алу тобы SLA-ны алдын ала дайындалған бірнеше ақауға қолдануы керек. Тараптар сынақ кезінде бірдей нәтиже есептей алмаса, өнімдік апат кезіндегі дау ұзағырақ әрі қымбатырақ болады.
Дұрыс қабылдау жинағына баяу сәтті жауап, сыртқы модельдің 5xx қатесі, алғашқы токендерден кейінгі ағын үзілісі, резервтік өңірге тыйым салу, провайдер лимитінің таусылуы, панельдің істемеуі және нашарлау кезінде кілтті кері қайтару кіреді. Әр оқиға үшін күтілетін санат, таймердің басталуы мен аяқталуы, рұқсат етілген резерв, журналдағы жазба және кредитке әсері алдын ала жазылады.
Каскад сценарийі ерекше пайдалы. Негізгі модель 429 қайтара бастайды, шлюз сұрауды тым көп қайталайды, кезек өседі, содан кейін резервке де кешіккен трафик толқыны келеді. Оқиғаны сыртқы провайдер бастады, бірақ шлюздің қайталау саясаты залалды күшейтті. Бүкіл аралықты сыртқы ақау ретінде алып тастайтын шарт апаттың басқарылатын бөлігін жасырады. Дұрыс формула анықтау кідірісін, артық қайталауларды және сәтсіз ауысуды шлюз жауапкершілігінде қалдырады.
Сатып алу кестесі әр қатысушыдан «иә» белгісін емес, нақты мән мен ұсыныстағы тармаққа сілтеме талап етуі керек. Салыстыру өрістері түсінікті: өлшеу нысаны, формула, терезе, профиль бойынша шектер, RTO, қолдау, сыртқы ерекшеліктер, дәлелдер, кредиттер, қайталанған бұзушылықтар және шығу құқығы. Таныстырылым «жоғары қолжетімділік» деп уәде берсе де, бос өріс міндеттеменің жоқтығын білдіреді.
Жеткізушінің ішкі жүйесіне қол жеткізбей тексеруге болмайтын уәдені қабылдамау керек. Жақсы SLA екі тарапқа бірдей арифметика және жеткілікті байқалатын дерек береді. Жеткізуші сыртқы модель қателерін қосудан бас тартса, соңғы нәтиженің қай бөлігіне жауап беруге дайын екенін және оның тұжырымы нақты қанша минут бас тартуға мүмкіндік беретінін сұраңыз. Мұндай есептен кейін жарнамалық пайыз әдетте әлдеқайда қарапайым көрінеді.
Банк ең жоғары пайызға емес, дауласуға ең аз орын қалдыратын пайызға қол қоюы керек. Баяу, қате маршрутталған немесе үзілген жауап бас тарту деп саналатын, RTO реакция уақытынан бөлінген, ал әр ерекшелік дәлелді талап ететін шарт банкке пайдалы. Сервис мәртебесі мен клиент тәжірибесі сәйкес келмей қалған түнгі үште адамдар дәл осы жолдарды оқиды.
Жиі қойылатын сұрақтар
Банк үшін LLM шлюзы қолжетімділігінің қандай пайызы жеткілікті?
Бәріне ортақ пайыз жоқ: талап процестің маңызына және банктің резервтік режиміне байланысты. Алдымен рұқсат етілген тоқтау уақытын анықтап, формула қателерді, тайм-ауттарды және баяу жауаптарды санайтынын, ал ерекшеліктер міндеттемені босатпайтынын тексеріңіз.
Қолжетімділікті минутпен бе, әлде сұраумен бе есептеу керек?
API үшін жарамды сұраулар бойынша есеп дәлірек, өйткені олар алынған нәтижені көрсетеді. Нақты трафик аз кезде ұзақ толық ақау жасырынбауы үшін үздіксіз оқиғалардың ұзақтығын да көрсетіңіз.
Сыртқы LLM жауабы шлюз SLA-сына кіре ме?
Иә, басқарылатын пулдың end-to-end көрсеткішіне түпкі жауап кіруі керек. Шлюз барлық келісілген әрекетті орындап, рұқсат етілген резервтер қолжетімсіз болып, жеткізуші тексерілетін дәлел бергенде ғана сыртқы себепті алып тастауға болады.
Қолдау қызметінің жауап уақыты RTO-дан несімен ерекшеленеді?
Жауап уақыты жеткізушінің өтінімді қашан растағанын немесе маманды қашан қосқанын көрсетеді. RTO функцияның тұрақты қалпына келуіне дейінгі уақытты шектейді, сондықтан оператордың жылдам жауабы RTO орындалғанын білдірмейді.
Модельдің ағындық жауабы үшін p95 қалай өлшенеді?
Алғашқы мағыналы токенге дейінгі уақыт пен ағынның дұрыс аяқталуына дейінгі уақытты бөлек өлшеңіз. Кіріс және шығыс көлемі бойынша себеттерді белгілеңіз, қателерді іріктемеге қосыңыз және күнделікті процентильдерді орташаламаңыз.
HTTP 200 LLM сұрауын сәтті ете ме?
Дене дұрыс, ағын аяқталған, схема сақталған және жауап шарттағы шекке дейін келген жағдайда ғана. Сервер 200 қайтарса да, бос JSON, үзілген ағын немесе маршруттау саясатының бұзылуы бас тарту болып қалады.
Жоспарлы жұмысты қолжетімділік есебінен шығаруға бола ма?
Банк уақытын, ұзақтығын және зардап шегетін функцияларды алдын ала келісіп, жеткізуші мұндай жұмыстар лимитінен аспаса, болады. Шұғыл жұмыс пен уақытылы хабарланбаған сыртқы провайдер жұмысы автоматты ерекшелік болмауы керек.
SLA бұзылғандағы сервистік кредит қандай болуы керек?
Кредит зардап шеккен сервис төлемінен есептеліп, бұзушылық ауырлаған сайын өсуі керек. Ол автоматты түрде есептеледі және қайталанған бұзушылық салдарын, шығу құқығын немесе шарттағы басқа қорғаныс құралдарын алмастырмайды.
Айлық SLA есебін тексеру үшін банкке қандай деректер керек?
Жарамды сұраулар саны, санат бойынша қателер, кідіріс гистограммалары, тайм-ауттар, себептері бар ерекшеліктер және оқиғалардың уақыт шкаласы қажет. Сұрау идентификаторлары промпт мазмұнын ашпай, банк метрикаларымен салыстыруға мүмкіндік береді.
Сатып алу кезінде әртүрлі LLM шлюздерінің SLA-сын қалай салыстыруға болады?
Ұсыныстарды бірдей өрістері бар бір кестеге көшіріңіз: формула, терезе, кідіріс профильдері, RTO, қолдау, ерекшеліктер, дәлелдер және кредиттер. Қатысушы нақты есептеу әдісінсіз пайыз берсе, бұл өрісті бос деп санаңыз.