Ішкі ЖИ тұтынуын есептеу: квоталар, приоритеттер, есептер

Неліктен GPU туралы даулар жиі кездеседі

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

GPU тапшылығы адамдар немесе бюджет тапшылығынан өзгеше — ол бірден және жергілікті түрде көрінеді. Бюджет тоқсан сайын қайта бөлінсе, адамдар айлар бойы қабылданады. Ал GPU бүгін сағат 10:05-те бітіп қалады, біреу барлық ускорительдерді бір экспериментке қатысты алған кезде. Сырттан қарағанда «кімде-кім ресурсты жеп жіберді» сияқты көрінеді, бірақ жиі себебі оңай: ережелер болмаған.

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

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

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

Не есептеу керек: терминдерге келісейік

«GPU-ны кім жеді» сияқты дауларға түспеу үшін ең алдымен не есептелетінін келісіңіз. Әйтпесе бір бөлім токендерді, екінші — видеокарт сағаттарын, үшінші — сақтау шығындарын санап отыратын болады.

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

Онлайн-инференс пен пакеттік тапсырмаларды бірден бөлу дұрыс.

Онлайн-инференс — чаттар, операторқа ұсыныстар, құжат бойынша іздеу. Онда латенттілік пен қолжетімділік маңызды болғандықтан лимиттер көбіне «сұрау бойынша» анықталады және шарықтау кезінде қорғаныс қосылады.

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

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

Есеп бірліктерін басқару ережелеріне сәйкес таңдаңыз: сұрау үшін (онлайн), 1K немесе 1M токен үшін (командаларды салыстыру ыңғайлы), GPU-минут үшін (пакеттік тапсырмаларға), гигабайт-ай сақтау үшін (датасеттер мен нәтижелерге).

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

Квоталарды қалай қою керек: департаменттер, жобалар және рөлдер

Квоталарды ең оңай сол жерде енгізіңіз, сіз жауапкершілікті қалай есептеуді білетін жерден. Егер бюджеттер мен нәтижелер департаменттерге бекітілсе (ИТ, ҚБ, аналитика), департаменттер бойынша квотадан бастаңыз. Егер жұмыс нақты бастамалар арқылы жүрсе (мысалы, «қолдау чат-боты» немесе «құжатты тану»), жобаларға квота беру ыңғайлы, ал департаменттерді меншік иелері мен бақылаушылар ретінде қалдырыңыз.

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

Әдетте бірнеше рөл жеткілікті:

• Қарапайым қолданушы: шағын квоталар, типтік модельдерге қолжетімділік.
• Өнім командасы: тұрақты релиздер мен қолдауға тұрақты квота.
• Зерттеу тобы: икемді квоталар, бірақ эксперимент жоспары мен қысқа нәтижелік есеппен.
• Платформа әкімшісі: ережелер шегінде ресурстарды қайта бөлу құқығы.

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

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

Мысалы: компанияда LLM қолдау және аналитикаға енгізіледі. Қолдауға тоқтап қалмау үшін фиксирленген базалық квота беріледі. Аналитиктерге нақты есеп не зерттеу үшін 3–5 күнге қосымша GPU сұрауға рұқсат беріледі. Осылайша «міндетті» және «өтініш бойынша» жұмысы алдын ала ажыратылған болады.

Тапсырмалардың приоритеттері: GPU-ны бірінші кім және қашан алады

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

Қызмет көрсету класстарынан бастап, оларды кезектер мен күту уақыттарына байлау ыңғайлы:

• Критикалық: тоқтау шығын келтіреді немесе сервис бұзылады (мысалы, колл-орталықтағы триаж).
• Маңызды: командалардың жұмысын қолдайды, бірақ кешігуге шыдайды (мысалы, күнделікті есептер).
• Эксперимент: зерттеулер, прототиптер, біржолғы тесттер, «сынақ үшін» оқыту.

Содан кейін параллельділіктің лимиттерін енгізіңіз. Оңай логика: бөлімнің үлкен бюджеті болса да, ол бірден 20 тапсырманы іске қосып, бүкіл кластерді баспауы тиіс. Мысалы, «маңызды» үшін бір департаментке бір уақытта 2 параллель іске қосуға, «эксперимент» үшін — 1-ге рұқсат етуге болады.

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

Вытеснение ережелерін алдын ала жазып, техникалық түрде бекіту маңызды: «критикалық»-ты қолмен растаусыз тоқтатуға болмайды; «маңызды»-ны чекпоинттан кейін тоқтатып, жалғастыруға болады; «эксперимент»-ті артық жүктеме кезінде автоматты түрде прерван етуге болады. Әр класс үшін SLA уақытын беріңіз (мысалы, «критикалық» үшін 1–3 минут).

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

Есепсіз жұмыс істемейтін метрикалар

Метрикалар үш сұраққа жауап беруі керек: не іске қосылды, қанша ресурс алынды және нәтиже қандай болды.

Мінimalді метрикалар жиынтығы

Бастапқыда аз ғана көрсеткіштен бастап, оларды барлық модельдер мен қосымшалар үшін біркелкі жинаңыз:

• Токендер: кіріс және шығыс бөлек, модель мен қолданбаға байланған.
• GPU: пайдалану уақыты, орташа және шыңдық жүктеме, алынған VRAM.
• Қатардағы ресурстар: CPU, RAM, диск (I/O) және желілік трафик.
• Ішкі «шығын»: шартты бірліктер (мысалы, 1 бірлік = 1k токен + 1 бірлік = 1 минут GPU).
• Орындау сапасы: қателер, ретрайлер, тоқтатулар және таймауттар.

Бұл сандарды қалай оқу керек

Токендер мәтін жағынан жүктемені көрсетеді: ұзын промпттар мен үлкен жауаптар лимиттерді тез жейді, тіпті GPU аз жүктелсе де. GPU-уақыты мен VRAM ауыр жұмысты жеңіл тапсырмадан ажыратуға көмектеседі. VRAM шыңдары көрші жұмыстардың кенеттен құлауын түсіндіреді.

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

Деректерді жинауды қалай ұйымдастыру: тегтер, логтар және хабарламалар

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

Тегтер: не әрқашан болуы керек

Практикалық минимум:

• департамент (қаржы, ҚБ, дамыту)
• жоба немесе өнім
• орта (prod немесе test)
• иесі (адам немесе команда)
• жүктеме түрі (инференс, оқыту, пакеттік өңдеу)

Тегтер «чатта қолмен» емес, автоматты түрде: SSO-топтан, кілт атауынан немесе жоба кеңістігінен алынуы маңызды. Осылайша біреу «маркедуді ұмытып кетті» деген жағдай азаяды.

Логтар: не сақтау, не қысқарту

Сыры логты дәл сараптау үшін қажет болған мерзіше ғана сақтаңыз (мысалы, 7–14 күн), сосын агрегаттарды қалдырыңыз. Әдетте жеткілікті: уақыт, пайдаланушы немесе кілт, тегтер, модель, токендер саны (кіріс/шығыс), ұзақтық, статус, GPU-уақыт бағасы (бар болса), кэш белгісі.

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

Хабарламалар: шектер мен адресаттар

Төлем шегі бойынша алертерді қарапайым жасаңыз: кезең бойынша квотаға 70/90/100% сияқты. Оларды ролдер бойынша жіберіңіз: жоба иесіне (70%), департамент жетекшісіне және қаржы бақылауына (90%), инфрақұрылым дежур тобына (100% немесе кенет өрлеу).

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

2–4 апта ішінде квоталар мен есепті енгізудің қадамдық жоспары

Принцип оңай: алдымен келісімдер мен айқын ережелер, сосын автоматизация. Қатты шектеулерді түсініктеме бермей бастап кетсеңіз, адамдар迂路 жолын табады, және даулар көбірек болады.

1-апта: ережелер мен иелер

2–3 кездесуде квота моделін (департаменттер бойынша, жобалар бойынша немесе рөлдер бойынша) және иелерді бекітіңіз. Бір беттік RACI жеткілікті: кім квотаны мақұлдайды, кім қолжетімділікті басқарады, кім есептерді алады және кім инциденттерге жауапты. Бірден шешіңіз, не маңызды: критикалық тапсырмаларға кепілдендірілген үлес пе, әлде «кім бірінші келсе» қағидасы ма.

2–3 апта: есеп және пилот

3–5 метриканы және есеп жиілігін таңдаңыз: әкімшілерге күнделікті қысқа статус және жетекшілерге апта сайынғы есеп. Тегтер мен кілт беру ережелерін орнатыңыз: әр LLM сұрауы немесе GPU іске қосу департамент, жоба және иесі болуы тиіс. Лимиттерді бастапқыда тест ортада қосып, приоритеттеу жұмысының дұрыстығын тексеріңіз.

Пилотты 2–3 департаментте өткізіп, ережелерді фактілерге қарай түзетіңіз:

• Күн 1–3: RACI және квота моделі
• Күн 4–7: метрикалар, есептер, тегтер және қолжетімділіктер
• 2-апта: тестілік лимиттер мен приоритеттер
• 3–4 апта: пилот пен түзетулер

Қосымша квота беру процесін дереу бекітіңіз: кім өтініш береді, қандай мәліметтер (мақсат, мерзім, күтілетін токендер немесе GPU-сағаттары) және жауап беру мерзімі.

Есептілік: тұтынуды барлықа ашық ету

Негізгі қайшылық көзі — «кімде-кім барлық GPU-ны жеп қойды» деген сезім, бірақ ешкім сандарды көрсете алмайды. Есеп тек қана түсінікті, тұрақты және бірдей болғанда жұмыс істейді.

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

Жетекшілерге техникалық детальдарсыз жеке срез керек:

• жалпы GPU-сағаттар және өткен аптамен салыстырма
• ең көп тұтынған топ-3 (департамент немесе жоба)
• приоритетті тапсырмалардың үлесі (prod, қауіпсіздік, критикалық мерзімдер)
• квотадан артық пайдалану (пайызбен және сағатпен)
• ай соңына дейін болжам (норма немесе артық пайдалану тәуекелі)

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

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

Ерекшеліктер мен авариялық режимдер, бизнесті тоқтатпау үшін

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

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

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

Көбіне дауды жоятын ережелер жиынтығы:

• Авариялық режимті тек платформа дежур жетекшісі немесе ИТ-жауапты қосады, уақыт шектеуі бар (мысалы, 2–4 сағат).
• Кез келген авариялық шығарылым тіркеледі: тапсырма, иесі, себеп, қанша GPU және токен, нәтиже.
• Пиктер кезінде уақытша приоритеттер енгізіледі (айдың жабылуы, регуляторға есеп, сервис іске қосу).
• Тапсырмаларды прервать етуге рұқсат бар, егер бизнеске зиян келмесе: тесттік жүгірулер, «шартты» генерациялар.
• Тоқтатуға болмайтын тапсырмалар үшін чекпоинттер және іске қосар алдындағы ең ұзақ жұмыс уақыты бағасы міндетті.

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

Лимиттердегі жиі қателіктер және оларды қалай болдырмау

Бірінші себеп — ешкім түсінбейтін ережелер. Қолдан келгенінше «көзге қарап» квоталар бастасаңыз, айдан кейін неліктен біреуіне 40%, ал басқаға 20% берілгенін қорғау қиын болады. Лимиттерді белсенді жобалар санына, тоқсандық жоспарға, SLA міндеттемелеріне және бизнес-процестердің критикалығына байлаңыз.

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

Прод пен экспериментті бір кезекке араластыру ауыр соққы береді. Ресурстарды кем дегенде екі классқа бөліңіз: бизнес-критикалық тапсырмалар және зерттеулер. Физикалық GPU бірдей болса да, кезек логикасы әр түрлі болуы тиіс.

Тағы бір дау көзі — параллельділіктің шектелмеуі. Бір белсенді қолданушы немесе команда бір уақытта көптеген іске қосулар арқылы барлық GPU-ны бүкілдей жауып алуы мүмкін. Қолданушы мен жоба бойынша параллель іске қосуларға шектеу қойып, тапсырмалардың «салмағы» бойынша жоғарғы шекті белгілеңіз (мысалы, бір уақытта максимум N GPU).

Ақырында, есепті тек токендерге немесе тек GPU-уақытқа сүйемеңіз. Токендер LLM-нің жүктемесін жақсы көрсетеді, бірақ ауыр инференс тапсырмаларын түсіндірмейді. GPU-сағаттар «қатты» аппарат жүктемесін көрсетеді, бірақ сұраулардың тиімділігін көрсетпейді. Екі көрсеткіш те керек, плюс кезекте күту уақыты, тоқтатулар және ретрайлер.

Чек-лист: іске қоспастан бұрын және әр апта тексеруге

Бастапқыда екі мәнділікті жойыңыз. Көп дау әртүрлі күтілімнен туындайды, «лапы» емес.

Іске қоспастан тексеріңіз:

• Әр сұрау мен джобта тегтер бар: департамент, жоба, нақты жеке иесі, орта (prod/test).

• Параллельділік лимиттері мен приоритет кластары анықталған, асып кеткенде не болатындығы анық (кезек, кері қайтару, приоритетті төмендету).

• Хабарламалар шектері орнатылған (мысалы, квотаға 70% және 90%) және жауаптылар белгіленген.

• Қосымша квота сұрау процесі бар: қайда жазу, қандай деректер керек, жауап мерзімі.

• Prod пен test бөлінісі тәжірибеде тексерілген.

Апта сайын қысқа тексеріс жасаңыз:

• Жетекшілерге есеп бар ма: департаменттер бойынша тұтыну, топ жобалар, ауытқулар.
• «Қымбат» тапсырмалар тізімі қалыптастырылған (токендер немесе GPU-сағаттар бойынша) және шешім қабылданған: оңтайландыру, внепикке ауыстыру немесе бюджет келісу.
• Кезектер мен кері қайтарулар тексерілген: кім ресурсты алмай қалды, приоритеттерге байланысты конфликттер болды ма.
• Тегтер сәйкестендірілген: «атасыз» тапсырмалар жоқ па.
• Prod тесттерден пікте зардап шекпейтіні расталған.

Мысал сценарий: үш бөлім арасында GPU-ны қалай бөлуге болады

Ортақ GPU-кластері бар және үш бөлім: Қолдау (чат-бот пен іздеу), Аналитика (выгрузкалар мен есептер), R&D (LLM-мен эксперименттер және шағын модельдерді оқыту). Барлық тапсырмалар маңызды, бірақ кешіктіруге төзімділігі әртүрлі.

Алдымен әр бөлімге кепілдендірілген базалық квоталар беріп, сонымен бірге «критикалық» тапсырмаларды белгілеңіз:

• Қолдау: 40% GPU, критикалық — чат жауаптары мен жаңа құжаттарды индексациялау
• Аналитика: 30% GPU, критикалық — таңертеңгі 10:00-ге дейінгі күнделікті есеп
• R&D: 30% GPU, критикалық — тек келісілген дедлайнға қатысты тапсырмалар

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

Ауыр пакеттiк жұмыстары күнді «жеп алмауы» үшін түнгі терезелер енгізіңіз: 22:00–08:00 аралығында R&D пен Аналитикаға жоғарырақ лимит беріп, Қолдауға онлайн-сервис үшін минималды қор қалдырыңыз.

Апта сайынғы есепті бәріне қысқа және бірдей етіп ұстаңыз: департаменттер мен жобалар бойынша GPU-сағаттар, пиков кезеңдер үлесі, ең қымбат тапсырмалар (GPU-сағаттар, токендер, күту уақыты), критикалық SLA бұзылулары.

Квоталарды «сезім бойынша» емес, деректер бойынша қайта қараңыз. Егер Қолдау тұрақты түрде 25% қолданса және піктер болмаса, базалық квотаны төмендетіп, босайғанын Аналитикаға таңертеңгі слотқа беруге болады. Қайта қарау ережесін (мысалы, айына бір рет) алдын ала келісіп, өзгерістерді бір құжатта тіркеңіз.

Келесі қадамдар: ережеден тұрақты инфрақұрылымға

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

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

Содан кейін қысқа регламент (1–2 бет): кімге квота беріледі, қосымша өсу қалай сұралады, не авариялық режим және приоритеттер қалай белгіленеді.

Алдағы 1–2 айға практикалық жоспар:

• Пиков уақыттарды есептеп, мақсатты қуатты анықтау (мысалы, орташа пикке +20–30%).
• Кеңею жоспарын жоспарлау: түйіндерді қосу, prod пен экспериментке бөлек кезектер, инциденттерге резерв.
• GPU, жад, кезектер және сұраулар құны бойынша мониторинг пен алертер орнату.
• Қызмет көрсету кестелерін, жауаптыларды және откат процедураларын келісу.
• Түнгі және демалыс күндердегі реакция кімге тиесілі екенін анықтау және не критикалық екенін анықтау.

Егер өз ресурстарыңыз жобалау мен енгізуге жетпесе, интегратор шақыру пайдалы. Қазақстанда көптеген командалар локал өндіруші және жүйелік интеграторға сүйенеді, жеткізу мен қолдауды жеңілдету үшін: мысалы, GSE.kz (gse.kz) серверлерді жеткізіп, ЖИ мен дата-орталық инфрақұрылымын интеграциялап, тәулік бойы қолдау көрсетеді.