LLM сұрауларын кэштеу: модельдерді бағыттау және GPU үнемдеу

GPU LLM-пен жұмыс істегенде қайдан артады

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

Көбіне уақыт «ақылға» емес, есептеу механикасына кетеді. Ең қымбат факторлар — ұзын жауапты генерациялау, үлкен кіріс контексті (чат тарихы, құжаттар, нұсқаулар) және қайта-қайта қайталанатын сұрақтар, олар әр жолы қайта есептеледі. Сондықтан LLM сұрауларын кэштеу тіпті шағын жобаларда да тиімді, егер адамдар жиі бірдей сұрақтар қойса.

Ең алғашқы симптомдар бірдей: сұрау кезегі пайда болады және шыңды уақытта жауаптар «жабысып» қалады, кешігулер секіреді (кейде 2 секунд, кейде 20), ұзын промпттарда өткізу қабілеті төмендейді, ал шығын өседі (сол пайдалы жауаптарға көбірек GPU-сағат кетеді).

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

Егер кезектер мен тұрақсыз кешігулер көрінсе және жүктеме күннен-күнге қайталанса, оңтайландыру жаңа GPU сатып алудан маңыздырақ болады. Құрал қосу көбіне мәселені кейінге ығыстырады: кэш, контекст шектеулері және модельдер арасындағы маршруттау болмаса, өсіп келе жатқан сұраулар қуаттың қалдығын қайта «жояды».

Қай нәрсені кэштеу керек және қай жерде ең тиімді

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

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

Финалдық жауаптардан бөлек, кейде аралық нәтижелерді кэштеу тиімдірек болады. Мысалы, жүйе алдымен қолайлы құжатты тауып, одан кейін модельден жауап жазуды сұрайтын болса, табылған үзінді мен метадеректерді (қай бөлім, қай версия) кэштеуге болады. Тағы бір үнемделетін зона — шаблондық бөліктер: сәлемдесу, хаттың құрылымы, стандартты дисклеймерлер. Оларды модель шақырмай-ақ жинап қою немесе заготовка ретінде сақтау оңай.

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

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

Жылдамдық жағынан кэш әдетте жеңіске жетеді, бірақ жаңалық жағынан жеңілуі мүмкін. Сондықтан өмір сүру мерзімін (TTL) және жаңарту ережесін орнатыңыз: регламенттер өзгеруі мүмкін, баға жаңартылады, саясат формулировкалары түзетіледі. Жақсы тәжірибе — жауаптарды қайдан және қай версиядан алынғанын белгілеу, осылайша қашан тазалау керек екенін түсінуге болады.

Кілттер, TTL және инвалидация: кэш зиян келтірмес үшін

Кэш тек «сол сұрау» дегеннің не екенін нақты түсінгенде ғана үнемдейді; қай кезде ескі жауаптар жойылатынын да білу керек. LLM сұрауларын кэштеуде бұл әдетте сақтау жүйесін таңдаудан маңыздырақ.

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

Нормализация сәйкестікті арттырып, шығынды азайтады. Идея қарапайым: мағына жағынан бірдей сұраулар техникалық тұрғыдан да бірдей көрінуі тиіс. Артық бос орындарды алып тастаңыз, регистрді теңестіріңіз, тырнақшаларды бір қалыпқа келтіріңіз. Кейбір тапсырмалар үшін күндер мен сандарды тұрақтандыру пайдалы болады. Мысалы, «01.01.2026 үшін есеп» және «1 қаңтар 2026 үшін есеп» бір формаға келтірілуі мүмкін, егер жауапта тек кезең маңызды болса.

TTL-ді төмендегідей таңдап алыңыз:

• минуттар немесе сағаттар — жаңалықтар, статустар, бағалар мен қалдықтар үшін
• күндер — процедуралар мен ішкі регламенттер үшін
• апталар — сирек өзгеретін анықтамалық жауаптар үшін

Инвалидация білім көзі немесе ережелер өзгергенде қажет. Білім базасын жаңартсаңыз, құжат қоссаңыз немесе маршрутизацияны өзгерткенде кэшті тегтер бойынша тазалаңыз: «құжат коллекциясы», «индекс версиясы», «саясат версиясы». Бұл қай кілттер әсер еткенін болжаудың орнына жеңілірек.

Метрикаларсыз кэш зиян келтіруі оңай. Hit rate, орташа кешігу, қайталаным бөлігі және «ескі орындаулардың» саны (пайдаланушылардың ескілігі туралы шағымдары) логталсын. Осы сандар TTL тым ұзақ па, әлде кілт тым тар немесе тым кең бе екенін тез көрсетеді.

Неліктен модельдер арасындағы бағыттау GPU шығындарын азайтады

Әр сұрау ең үлкен және қымбат модельге лайық емес. Үлкен LLM әдетте баяу және көбірек GPU жадын мен есеп уақытын талап етеді. Барлық сұрауларды сол арқылы жіберсеңіз, қарапайым нәрсеге де «ақылдығын» төлейсіз.

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

«Жеңіл маршрутқа» көбіне классификация (хат тақырыбы, тональность, приоритет), өріс шығару (ЖСН, келісім-шарт нөмірі, күндер, сомалар), шаблондық қысқа жауаптар (жұмыс кестесі, өтініш статусы, құжаттар тізімі), сондай-ақ 1–2 сөйлемдік перефразация және грамматика түзету кіреді.

Үлкен модель қателік тәуекелі жоғары немесе бірнеше қадамдағы ойлауды талап ететін жерде қажет: күрделі нұсқаулар, ұзын құжаттар, аралас тілдер, екіұштылықтар, немесе бірнеше фактіні байланыстыру қажет болғанда. Тағы бір белгі — ұзын контекст (мысалы, 30 хабардан тұратын переписка) немесе жоспар құру, салыстыру, аргументация сұрауы.

Практикалық схема — каскад. Алдымен арзан талпыныс, егер күмән болса эскалация. Мысалы: «Бухгалтерияға қандай анықтама керек?» — кіші модель қысқа тізім береді. Ал «Келісім шарт талаптарын қосымшамен салыстырып, айырмашылықты түсіндір» деген сұрауды жақсырақ дереу үлкен модельге жіберген дұрыс.

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

Сұраудың түрі мен күрделілігі бойынша роутинг ережелері

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

1) Тапсырма түрі бойынша роутинг

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

Үлгі ережелер:

• Факт бойынша сұрақ-жауап (қысқа сұраулар) — кіші модель, қатал жауап форматы.
• Ұзын мәтінді суммаризациялау — орташа деңгейлі модель, шығуды шектеу.
• Аудару — арнайы модель немесе термин сақтауға арналып бапталған режим.
• Білім базасы бойынша іздеу (RAG) — алдымен іздеу, кейін генерацияны кіші модельде орындау.
• Хат немесе клиентке жауап жазу — тон мен құрылым маңызды болғандықтан мықтырақ модель.

2) Күрделілік, тіл және тәуекел бойынша роутинг

Содан кейін модель сынын көтеретін триггерлер қосыңыз.

Күрделілік: ұзын кіріс, кестелер, көп талаптар (мысалы, «3 нұсқа жаса, стильді ескер, цифрларды қос, сленг қолданба») — модель дәрежесін жоғарылату себебі.

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

Тәуекел: құқықтық, қаржылық, медициналық тақырыптар және мемлекеттік қызметтерді әуелі мықтырақ модельге жіберіп, сақтық баптарын (аз «жорамалдау», көбірек нақтылау сұрау) қосыңыз.

Эскалация ережесі: кіші модель жұмыс істемесе (екі рет нақтылау сұрады, қарама-қайшылық берді, форматты сақтамады), сұрау автоматты түрде мықтырақ модельге өзінің қысқартылған «тарихымен» жіберіледі.

Кэш пен роутингте сапаны қалай бақылау керек

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

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

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

• 20–30 жиі сұрау, онда кэш тиімді болуы тиіс
• 10–15 бір-біріне ұқсас, бірақ өзгеше формулировкалар — қате попаданияларды табу үшін
• 10 сұрау, олар үшін міндетті түрде үлкен модель қажет
• 5–10 сұрау персоналды деректермен (маскировка мен кэш тыйымын тексеру)
• 5 «провокациялық» сұрау (екіұштылық, күрделі нұсқаулар)

Пайдаланушы кері байланысы қарапайым болуы тиіс: «пайдалы / пайдалы емес» және «не дұрыс емес» деген өріс. Осы фидбек бойынша роутинг ережелері мен кэш қара тізімдерін оңай түзетуге болады. Кэштеу енгізілген жағдайда есепте кэштен шыққан жауаптарға түскен негативті бағалаулар санын 따로 белгілеген жөн.

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

Есігу өзгерістерден сақтану үшін роутингті біртіндеп қосыңыз: алдымен логтарға шешімді жазып қойып, жауапқа әсер етпеңіз, кейін 5–10% трафикке жаңа ережелерді қолданыңыз, мүмкін жерде A/B тесттер қосыңыз, қателік пен шағым метрикасы бойынша тоқтату батырмасын сақтаңыз және ережелерді 1–2 апта сайын қайта қараңыз.

Енгізу қадамдық жоспары: логтардан өндірісқа дейін

Бастамас бұрын код емес, деректерден бастаңыз. 1–2 апталық сұрау логтарын алыңыз: сұрау мәтіні, пайдаланушы типі, жауап уақыты, токен бойынша шығын, модель және соңғы нәтиже (сәтті, қайталама, операторға эскалация).

Содан кейін сұрауларды мағынасы бойынша топтастырып, қайталанатын сценарийлерді табыңыз. Қолданушылардан тез шығып келетін шаблондар әдетте: «терминді түсіндір», «қысқаша резюме жаса», «хаттағы қатені тап», «клиентке жауап дайында», «контексті көп күрделі жағдай». Бұл база және кэштеу, және модель таңдау үшін.

3–6 сұрау типін сипаттап, әрқайсысына модельдер топтамасын бекітіңіз: қарапайымға — кіші, орташаға — орташа, сирек күрделіге — үлкен. Осы қадамда не қауіпсіз кэштелетінін де шешіңіз: жеке дерексіз анықтамалар, шаблондық формулировкалар, мәтін нормализациясының нәтижелері.

Санаттар дайын болса, кэшті тек қателік ықтималдығы төмендеріне қосыңыз. TTL-ді білім өзгерістері жауапқа әсер етпеу үшін реттеңіз: нұсқаулар мен анықтама үшін сағаттар немесе күндер жеткілікті, динамика үшін (бағалар, статустар) кэш қолданбаған дұрыс.

Содан кейін түсінікті эскалация ережелері бар маршрутизатор қосыңыз: мысалы, сұрау N таңбадан ұзын болса, қосымшалар бар болса, саясатты дәл келтіру қажет болса немесе классификатордың сенімділігі төмен болса — күшті модельге жіберіңіз.

Параллель түрде мониторинг пен деградация шектерін қойыңыз:

• кэшке түсу пайызы және токен үнемі
• орташа кешігу және p95
• үлкен модельге эскалация пайызы
• пайдаланушылардың шағымдары немесе қолмен сапа бағалаулары
• таймаут бойынша қателіктер үлесі

Пилотты 5–10% трафикте іске қосып, метрикалар тұрақты болғанда ғана қамтуды кеңейтіңіз. Мысалы, ішкі қолдау көмекшісі үшін алдымен «қалай өтініш толтыру» сияқты жиі сұрақтарды кэштеңіз, ал келісім-шарт сияқты күрделі мәселелерді дереу үлкен модельге жіберіп, кэшті өшіріңіз.

Практикалық мысал: ішкі қолдау көмекшісі және GPU үнемі

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

Мұнда LLM сұрауларын кэштеу жақсы көмектеседі. «FAQ тәрізді» тақырыптар үшін (жұмыс кестесі, құжаттар тізімі, типтік формулировкалар) жауаптар сақталып, қайта қолданылады. Маңыздысы — бәрін кэштемеу, тек қайталанатын және персоналды деректен тыс нәрселерді сақтау.

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

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

Жаңарту да қарапайым: регламент өзгерсе, кэштің қатысты жазбаларын тазалау, промпт өзгерсе — кілт версиясын ауыстыру арқылы ескі жауаптардың пайда болуына жол бермейсіз.

Қателіктер, олар сапа мен үнемді бұзады

Оңтайландыру көбіне күрделі математикадан емес, жүзеге асырудағы бір-екі «жұмсақ» қателіктен бұзылады. Бұл қателіктер сапа мен GPU үнемін құрам күйіне келтіреді.

Кэштегі қателіктер: бүгін үнемдейміз, ертең проблемалар

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

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

Роутингіде қателіктер: тым батыл үнемдеу

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

Бес жиі кездесетін сигнал, баптау дұрыс емес екенін көрсететін:

• кэш кілті промпт версиясын және контекстті ескермейді, жауаптар ескіруі
• кэшке құпиялар немесе персоналды деректер түседі
• кіші модель шартсыз қолданылады, эскалация ережелері жоқ
• метрикалар жоқ (кэш hit rate, эскалация пайызы, сапа), сондықтан әсер «көзбен» анықталады
• түрлі тапсырма түрлері араласып кеткен, ережелер мен тесттер жоқ, мінез-құлық болжамсыз

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

Өнімге жіберер алдында қысқа чек-лист

Кэштеу мен модель роутингін өнімге қосардан бұрын қысқа тексеруден өтіңіз.

Біріншіден не кэштеуге болатынын шешіңіз. Қарапайым ереже: көп пайдаланушылар үшін бірдей және персоналды деректерді қамтымайтын нәрсені кэштеңіз. Сезімтал деректер үшін алдын ала тыйым орнатыңыз (мысалы, ФИО, келісім-шарт нөмері, медициналық мәліметтер), тіпті жауап «қауіпсіз» сияқты көрінсе де.

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

Финалдық тексеру:

• Кэш санаттары мен тыйымдар анықталған: не кэштейміз, не мүлде кэштемейміз, логтарда деректер қалай маскировкаданады.
• Сұрау түрлері белгіленген және модель таңдау ережелері бар (тақырып, ұзындық, дәлдік талаптары, құралдардың болуы).
• TTL мен инвалидация бапталған: білім, промпт, модель версиясы немесе қауіпсіздік саясаты өзгергенде не болады.
• Метрикалар орнатылған және бірге қаралады: hit rate, кешігу, үлкен модельге эскалация пайызы, сапа тексерулері бойынша қателер.
• Тест жиынтықтары мен откат жоспары дайын: типтік сұраулар, «күрделі» кейстер және кэшті немесе роутингті өшіруге бірден болатын айқын переключатель.

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

Келесі қадамдар: енгізу және инфрақұрылымды жоспарлау

1–2 күн ішінде істелетіннен бастаңыз: сұрау логтарын жинап, оларды типтерге бөліңіз (FAQ, білім базасы іздеуі, мәтін генерациясы, код, суммаризация). Көп жағдайда жиі сұрақтарға пилот кэш тез қайтарып береді: сәлемдесу, тапсырыс статусы, негізгі нұсқаулар, типтік қателер. Бұл GPU үнемін алғашқы нәтижелермен көрсетеді, маршрутизацияны толық енгізбей-ақ.

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

On-prem шешімді деректерге қатаң талаптар болса, құпиялылық пен кешгіңен туындайтын жауапкершіліктер бар болса, немесе кеш ақылы жабдық сатып алу жоспарына ыңғайлы болса, оны қарастыру қажет. Мұндай жағдайда қауіпсіздік, резервтеу және эксплуатацияға уақыт қойыңыз.

LLM-нүктелері үшін түйін таңдағанда балансқа назар аударыңыз, тек GPU-ға ғана емес. Көп жағдайда шектеу жады мен желіде болады: үлкен контекст, кэш және векторлы хранилище көп RAM пен жылдам диск талап етеді, параллель сұраулар желіні қосымша жүктейді.

Жұмыс жоспары апта бойынша:

• 1-апта: сұраулар аудиті, «топ-50» FAQ тізімі, базалық кэш және метрикалар.
• 2-апта: тапсырма түрлері бойынша қарапайым роутинг ережелері және контекстті шектеу.
• 3-апта: сапа тесті, A/B, үлкен модельге эскалация порогтары.
• 4-апта: қуат есептеуі, жоғарылатылғыштық, 24/7 эксплуатация жоспары.

Егер инфраструктура мен енгізуде көмек керек болса, жүйелік интеграторды тартқан дұрыс — ол жабдық пен эксплуатацияны жабады. Мысалы, GSE.kz сервер өндірушісі әрі интегратор ретінде on-prem сценарийлер үшін сервисті және тәулік бойы қолдауды ұсынады, бұл деректерге қатаң талаптар болғанда ыңғайлы болуы мүмкін.