MIG және GPU-ны инференске бөлу: шектеулер мен сыйымдылық

Мәселе: бір GPU, бірнеше сервис және болжамды жауап

Бір қуатты GPU көбіне бос тұрады, егер онда тек бір инференс сервисі жұмыс істесе. Командалар сол картада тағы 2–3 модель орналастырғысы келеді: чат‑бот, құжаттарды жіктеу, суреттерді тану. Бұл арзанырақ және оңайырақ басқаруға болады, әсіресе GPU тапшылығы болса немесе сатып алу ұзақ уақыт алса.

Бірақ бірге пайдалану басқарылмаса, мәселе туындайды. Бір сервис трафиктің шарығышын қабылдап, GPU кезегін толтырады да, басқаларының жауап уақыты өседі. Сырттан ұқсайды: "кеше 200 мс еді, бүгін 2 секунд", ал код өзгермеген. Тағы жамансы — ауыр модель кездейсоққа жақын уақытта жадының көп бөлігін алып, көршілерді out of memory қатесімен құлатады.

Инференсте «сыйымдылық» — абстрактты TFLOPS емес, пайдаланушы мен мониторинг көретін нақты көрсеткіштер: белгілі SLA кезінде қанша сұранысты өңдей аласыз, p95/p99 кешігулер қандай, пик кезінде кезек қалай өседі және қателер/таймауттар бар ма.

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

Дегенмен MIG бәріне жарамайды. Ол әр GPU-де болмайды және драйверлер мен платформа тарапынан қолдауды талап етеді. Тіпті MIG болса да, жалпы контур (қуат, салқындату және кейбір түйіндер) тұрақтылыққа әсер етуі мүмкін. Кей сценарийде қатты бөлулер керісінше зиян келтіруі мүмкін: егер бір сервис кейде үлкен батчтер үшін бүкіл картаны уақытша алу керек болса, кесу оның максималды өнімділігін төмендетеді. Сондықтан алдымен SLA-ны (мысалы, p95 < 300 мс) және жүктеме профилін анықтап, содан соң ғана карта бөліп немесе бөлек GPU беруді шешу керек.

MIG деген не және ол басқа бөлулерден қалай өзгеше

MIG (Multi-Instance GPU) — бір физикалық GPU-ны бірнеше аппараттық түрде оқшауланған бөліктерге бөлу режимі. Инференсте бұл бір картада бірнеше сервис болса және олардың бір-біріне кедергі келтірмеуі маңызды болғанда ыңғайлы.

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

MIG жиі келесі қарапайым тәсілдермен шатастырылады:

• Бір GPU-де бірнеше процесс — тез, бірақ кепілдік жоқ. Жад, кэш пен есептеуге бәсекелестік latency-дің секіруіне әкелуі мүмкін.
• MPS (Multi-Process Service) GPU-ны жақсырақ жүктеуге және шығындарды азайтуға көмектеседі, бірақ оқшаулау әлсіз. Бұл қатты шектеулі бөлуден гөрі ортақ пайдалану.
• MIG аппараттық түрде ресурстарды бөліп, тұрақтырақ мінез-құлық береді.

MIG әсіресе бір картада әртүрлі SLA-лары бар бірнеше API болғанда пайдалы. Мысалы, чат‑ботқа 200–400 мс қажет, ал пакетпен құжаттарды жіктеу 2–3 секундқа шыдайды. Оқшаулау болмаса, пакеттік сервис пик кезінде жылдам сервиске кедергі келтіріп, пайдаланушы тәжірибесін бұзуы мүмкін.

Практикада MIG ИИ серверлік платформаларында және дата‑орталықтарда жақсы келеді: ресурстардың үлестерін алдын‑ала келісіп, кейін оның latency мен кезек ұзындығында сақталуын тексеруге болады.

Темір мен орта қолайлығын тексеру

MIG туралы әңгіме Kubernetes-пен және лимиттермен емес, қарапайым сұрақтан басталады: сіздің видеокарта MIG-ті қолдай ма. Бұл аппараттық мүмкіндік. Қолдау болмаса, басқа нұсқалар қалады: сервис деңгейіндегі кезектер, параллелизмді ұқыпты басқару немесе кейде виртуализация.

Қандай GPU-лар MIG-ті қолдайды және неге бұл маңызды

MIG NVIDIA-ның кейбір серверлік акселераторларында бар, ең алдымен A100, H100 және A30 (және кейбір жақын модификациялар). Қолдау болу себебі — физикалық GPU-ны оқшауланған инстанстарға бөлу. Инференсте бұл уақытты болжауды жақсартады, себебі көрші сервис кенет жадыны немесе есептеуді тартып алмайды.

Ортаның тағы не сәйкес болуы керек

Тіпті дұрыс GPU болғанымен, MIG бағдарламалық жасақтама себепті жұмыс істемеуі мүмкін. NVIDIA драйверінің қажетті нұсқасын, ОС-пен үйлесімділігін және басқару утилиталарын (ең кемі nvidia-smi) тексеріңіз. Контейнер ортасында NVIDIA Container Toolkit пен дұрыс runtime маңызды, әйтпесе MIG-инстанстар контейнерлерде көрінбеуі мүмкін.

MIG көбіне стойка серверлерінде және кластерлерде (соның ішінде Kubernetes) пайдаланылады, онда бір GPU-де бірнеше модель немесе командалар жүреді. Мысалы, GSE S200 деңгейіндегі серверде чат‑ботқа бөлек MIG-инстанс, OCR-ға басқа, ранжированиеға тағы біреу бекітіп, әрқайсысы өз шекарасымен жұмыс істейді.

Бастамас бұрын қысқа инвентаризация жасаңыз:

• GPU моделі және MIG қолдауының бар-жоғы
• GPU жадысы мен ағымдағы жүктеме
• драйвер, CUDA (қажет болса), ОС нұсқалары
• инференс қай жерде іске қосылады: bare metal, виртуализация немесе Kubernetes
• қай модельдер, олардың талаптары: салмағы, дәлдік түрі, күтілетін QPS және SLA бойынша latency

GPU-ны сіздің сервистерге қалай жоспарлап кесу керек

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

Практикалық тәсіл — трафикті «жылдам» және «фондық» етіп бөлу. Жылдамға GPU-дан кепілдендірілген бөлік, минималды кезек және батчқа қатаң шектеулер беріледі. Фондық бөлікке бөлек инстанс (немесе кішірек профиль) беріледі және ресурстар бос болмаған жағдайда кезек жинай алады.

Кейін модельдің жүктемесін бағалаңыз: салмақтың көлемі мен активациялар, максималды batch size, дәлдік (FP16/INT8) және пик жиілігі. Көп жағдайда жады есептеуден бұрын шектегіш болады. Егер модель сирек-ақ сыйса, кішкентай MIG‑бөлшек OOM-ға әкеледі немесе батчты азайтуға мәжбүр етеді, бұл өткізу қабілеттілігін төмендетеді.

Қысқа тексеру схемасы:

• әр сервис үшін SLA бойынша latency және мақсатты RPS анықтаңыз
• жадыны бағалаңыз: модель + батч және кезек ұлғаюына резерв
• не маңыздырақ: тұрақты p95/p99 немесе жалпы жоғары утилизация
• MIG профильдерін таңдап, «жылдам» сервис пен фонды бөліңіз
• пиктерге, прогревке және модель жаңартуларына резерв қалдырыңыз

Кейде бір үлкен бөлшек бірнеше кішкентайдан жақсы болады. Бұл бір сервис негізгі трафикті берсе немесе модель батчқа сезімтал болса. Ал бірнеше кішкентай бөліктер сервистер тәуелсіз болғанда және кешігулер бойынша болжамдылық қажет болғанда тиімді.

Қадамдармен: MIG-ті қосу және бөліктер жасау

Бастамас бұрын GPU MIG-ті қолдайтынын (мысалы, A100, A30, H100) және NVIDIA драйвері мен басқару утилиталары орнатылғанын тексеріңіз. Жүйенің GPU-ны көріп, қателер жоқ екенін тексеру — ең жылдам әдіс.

nvidia-smi
nvidia-smi -q | grep -i mig -n

1) MIG-ті қосып, режимнің қосылғанын тексеру

MIG-ті қосу GPU деңгейінде жасалады және көбіне режимнің таза қолданылуы үшін торапты қайта жүктеуді талап етеді.

# MIG режимін қосу
sudo nvidia-smi -i 0 -mig 1

# тексеру
nvidia-smi -i 0 -q | sed -n '/MIG Mode/,+3p'

Егер "MIG Mode: Enabled" көрінсе, инстанстарды жасауға көшуге болады.

2) GPU-инстанстар (профильдер) жасаймыз және шыққанын тексереміз

Алдымен өз GPU-меңіз үшін қолжетімді профильдерді қараңыз. Содан кейін қызметтерге қажетті бөліктерді жасаңыз (мысалы, бір үлкен ауыр модельге, екі кішкентай жеңілдерге).

# қолжетімді профильдер тізімі
nvidia-smi mig -lgip

# таңдаған профильдер бойынша GPU инстанстарын жасау (мысал)
sudo nvidia-smi mig -cgi 19,14,14 -C

# нәтижені қарау
nvidia-smi mig -lgi
nvidia-smi mig -lci

MIG құрылғыларының UUID-лары пайда болғанын тексеріңіз — дәл осыға сервис бекітіледі.

3) Сервис пен нақты MIG-инстансты байланыстыру

Жіберу деңгейінде ең оңай тәсіл — қажетті MIG UUID-ды орташа айнымалы арқылы көрсету.

# процесс тек бір MIG құрылғысына ғана көрінуі үшін мысал
export CUDA_VISIBLE_DEVICES=MIG-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
./your_inference_service

4) Параметрлердің перезагрузкадан кейін қалуын қамтамасыз ету

MIG разметкасы көбіне қайта жүктегенде босап қалады. Практикалық тәсіл — жасау командаларын systemd unit немесе стартап скриптке жазып қою. Kubernetes-те бұл әдетте NVIDIA GPU Operator арқылы автоматтандырылады, егер MIG стратегиясы қосылған болса. Драйвер жаңартуларынан кейін профилдерді құжаттап, тексеріп тұру пайдалы.

Шектеулер және оқшаулау: нені қай жерде шектеу керек

MIG инференсте негізгі нәрсе береді: болжамды жады және әділ оқшаулау, яғни бір сервис кенеттен GPU-ның барлығын ала алмайды. Бірақ көбіне бір MIG жеткіліксіз. Тұрақты latency алу үшін шектеулерді бірнеше деңгейде қою керек: GPU, контейнер және инференс сервері деңгейінде.

Нені шектеу маңызды

Инференсте жиі «құлайды» не есептеулерде емес, жадыда және сұраныстар бәсекелестігінен. Сондықтан алдымен VRAM туралы ойлаңыз, содан кейін параллелизм мен кезектер туралы.

Көбіне критикалық бақылау керек заттар:

• GPU жадысы (VRAM): сервис қанша жады ала алады және пикте не болады
• сұраныстар бәсекелестігі: бір уақытта қанша сұранысқа рұқсат бересіз, latency ұлғаюын болдырмау үшін
• инференс серверінің баптаулары: worker/instance саны, batch, таймауттар
• «шулы көршілерден» қорғаныс: тым көп немесе тым ауыр сұраныстар қабылдайтын сервис

Шектеулерді қай жерде қою керек

MIG-де сіз GPU-ның бір бөлігін бекітесіз: сервис карта емес, тек өзінің бөлігі көрінеді. Бұл VRAM бойынша жақсы қорғайды, бірақ сол бөлекте де көп параллельділік рұқсат етілсе, кезектер шығады.

Жұмыс схемасы:

• GPU (MIG): сервиске профиль бекітіп, оны тек тест өткізіп өзгертіңіз
• оркестратор: нақты MIG-құрылғыны сұрап, CPU мен RAM шектеулерін қойыңыз, солайша препроцессинг тартық болмайды
• инференс сервері: concurrency шектеу, таймауттар, max batch және backpressure қосу

Мысал: «жеңіл» модель кенет 5 есе көп сұраныс ала бастады. Ол көршінің қатты SLA-сы бар сервисін ығыстырмауы тиіс. MIG шекараларын ұстайды, ал параллелизм шектеуі мен кіріс кезегі latency-тің секундтарға секірмеуін қамтамасыз етеді. Мұндай баптауды стендте тексеру ыңғайлы, мысалы GSE S200 Series деңгейіндегі серверде.

Метрикалар: сыйымдылықты түсіну үшін не өлшеу керек

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

Негізгі метрикалар жинағы

Минимум келесі мәліметтерді алыңыз және динамикада қадағалаңыз:

• GPU utilization және SM жүктемесі
• GPU жады қолданылуы және OOM жиілігі
• сұраныстар кезегінің ұзындығы және кезекте күту уақыты
• latency p50, p95, p99 және инференстің өзі (кезексіз) бөлек
• қателер: таймауттар, 5xx, сұраныстардың болдырмауы, retry-лар

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

Кезекті былай оқу керек: егер кіріс ағымы тұрақты, ал backlog өсіп жатса — өткізу қабілеттілігі жетпейді. Егер кезек аз, бірақ p95/p99 секіріп жатса, жиі себебі — джиттер: модельді прогрев, ағындар бәсекелестігі, кіріс‑шығыс тұрақсыздығы.

Жылдам диагностикалық белгілер:

• GPU utilization төмен, ал latency өсуде: CPU, желі немесе диск жағынан тартыс іздеңіз
• GPU жады шектелген: модель өлшемі, batch size және фрагментацияға назар аударыңыз
• кезек өсіп жатыр, ал инференс уақыты тұрақты: MIG-бөлшектің үлесі жетпей жатыр немесе параллелизм тым жоғары
• қалыпты GPU-де таймауттар: балансировщик, коннекшн лимиттері, пулдар тексерілсін

GSE.kz деңгейіндегі серверлер мен интеграциялық жобаларда метрикаларды MIG-инстанстар, pod-тар және сервистер бойынша бөлу ыңғайлы. Сыйымдылық сезім емес, цифр арқылы көрінетін болады: қай жерде кезек жинақталып, не SLA-ны бұзатынын көрсете аласыз.

Кезектер мен жауап уақыты арқылы сыйымдылықты қалай өлшеу керек

Инференс сыйымдылығын түсіну — кезек тұрақты өсіп кететін шекті табу. Қызмет кіріс ағынды уақытылы өңдегенше, кезек аз деңгейде тербеледі. Кіріс RPS нақты өткізу қабілетінен сәл жоғары болғанда кезек өсіп, кешігулер бірге өседі.

Жай модель: бір сұранысты өңдеуге орташа уақыт T болса, бір воркер шамамен 1/T RPS-тан жоғары ұстай алмайды. Нақты ортада батчинг, көшіру, жады бәсекелестігі қосылады, сондықтан шекті өлшеу керек.

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

• RPS-ті қадамдап арттырыңыз (мысалы, әр қадамда +10–20%) және әр кезеңді 5–15 минут ұстап тұрыңыз
• әр қадамда p50/p95/p99 latency, throughput (шынайы RPS), кезек ұзындығы және қателер/таймауттар тіркеңіз
• warm-up кезеңін (алғашқы бірнеше минут) тұрақты бөлікпен бөліңіз
• «жаман» сценарийді де қайталаңыз: ауыр сұраныстар немесе максималды батч

Графиктер әдетте былай оқылады: throughput сызығы сызықтық өседі де белгілі бір платода тоқтайды, ал сіз жүктемені арттырып жатсаңыз да өспейді. Осы сәтте latency, әсіресе p95/p99 өседі, және кезек толығымен босамайтын болады. Бұл сол конфигурация үшін (MIG-слайс, воркер саны, батч, модель) практикалық сыйымдылық шегі.

Қорытынды құжатта «максимум RPS» дегеннен гөрі SLA-да қолдануға ыңғайлы формулировканы көрсеткен дұрыс: «сервис A N RPS ұстайды, p95 < X мс (және p99 < Y мс), қателер жоқ, кезек өсімейді». Осылай MIG профильдерін салыстыру және бір GPU-да қанша сервис бірге тұра алатынын бағалау жеңіл болады.

Мысал: бір GPU-ны үш сервиске әртүрлі SLA-пен бөлу

Бір серверде бір GPU бар (мысалы, GSE S200 айналасында), және үш инференс сервисі бір уақытта бөліседі: чат‑бот, жіктеу және OCR. Олардың кешігу талаптары әртүрлі: чат‑ботқа жылдам жауап керек, жіктеуге тұрақты өткізу қабілеттілігі маңызды, ал OCR көбіне пакетпен келіп, біршама үлкен кешігуді көтереді.

Әдеттегі логика: ең сезімтал сервиске орташа MIG‑профиль беріп, p95‑ті аз ұстауға тырысасыз; пакеттегі тапсырмаларға кішірек немесе орташа профильдер бересіз.

Мүмкін схема:

• чат‑бот: орташа MIG‑профиль, пик кезінде төмен p95 ұстау үшін
• жіктеу: кішірек профиль және репликация арқылы масштабтау мүмкіндігі
• OCR: кішірек немесе орташа профиль, егер үлкен суреттер/ұзын құжаттар жиі болса

Лимиттерді тек GPU арқылы емес, сервис деңгейінде де қою керек: concurrency және батч шектеу. Әйтпесе бір сервис өз ішінде кезек жинап, кешігу өседі, ал сырттан GPU әлі 100% толып кетпеген болып көрінеді.

Бастапқы күндері бірнеше метриканы үнемі қарап тұру пайдалы:

• әр сервис бойынша p50/p95/p99
• сұраныстар кезегі ұзындығы
• қателер мен таймауттардың үлесі
• әр MIG-инстанс бойынша GPU жүктемесі мен жады
• кезекте тұру уақыты мен орындау уақытын бөлек көрсету

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

Жиі қателер мен тұзақтар

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

Қате 1: тым ұсақ разрез

Тым кіші бөліктер жадыға тез барып тіреледі: модель сыймайды, батч жетіспейді, кэш пен аралық тензорларға орын жоқ. Сонымен қатар шығындар өседі: кішкентай бөлікте әрбір қосымша операция айтарлықтай әсер етеді.

Белгісі: модель жүктеледі, бірақ нақты трафикте жиі OOM, батч кішірейіп, жауап уақытында секірістер пайда болады.

Қате 2: әртүрлі SLA-ларды араластыру

Бір бөлекте «жедел, төмен p99 керек» және «күтіңізші, жарайды» сұраныстар бірге болса, p99 дерган болады. Ұзақ сұраныстар кезекті толтырады, ал жылдамдары күтуі тиіс.

Мысал: сервис A қысқа сұраныстарға қатты SLA қояды, сервис B сирек, бірақ ауыр сұраныстар жасайды. Егер олар бір бөлікті бөліссе, бірнеше B сұранысы қатар A-ның p99-ын нашарлатады.

Қате 3: орташа latency-ге ғана қарау

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

Қате 4: тартыс GPU-де емес

Кейде MIG дұрыс бапталған, бірақ баяулау CPU препроцессингте, постпроцессингте, желіде немесе дискіде болады (мысалы, үлкен кірістерді жүктеу). Содан соң GPU-ны бөлумен мәселені «емдеуге» тырыссаңыз да нәтиже болмайды.

Жылдам тексеру: GPU төмен жүктелген, бірақ кезек өсуде; немесе GPU жүктелген, бірақ негізгі кешігулер GPU-ге жіберуден бұрын жатыр.

Қате 5: пиктерден қорғалған емес

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

Көмектесетін шаралар:

• максималды кезек ұзындығына немесе күту уақытына шектеу
• backpressure: перегрузкада бас тарту немесе деградация
• әр түрлі сұраныс кластар үшін бөлек кезектер
• клиент пен серверде айқын таймауттар
• прогрев және болжамды батч (қолданылса)

MIG GPU‑ресурстарын оқшаулайды, бірақ болжамдылық тек трафикті SLA бойынша бөліп, орташа емес шетін көрсеткіштер мен кезекті бақылағанда пайда болады.

Өтініш алдында қысқа чек‑тізім

MIG-ті өндірісте қосар алдында негізгі сұрақтардан өтіңіз. Бұл бір-екі сағат алады, бірақ релизтен кейінгі талдауларды бірнеше күнге үнемдейді.

Бірінші прод‑трафикке дейін не анық болу керек

Тек "модель жылдам жұмыс істейді" деген сөздер емес, өлшенетін нақты сандар қажет:

• сервистер тізімі және олардың SLA: p95/p99 бойынша жауап уақыты, рұқсат етілген қателер пайызы, клиент таймауттары
• жады бағасы: модель салмағы плюс активациялар, кэш пен батч‑пиктер; бастапқы batch size және concurrency
• метрикалар мен ескертулер жинағы: кезек, кезекте күту уақыты, end-to-end latency, қателер, GPU/CPU жүктемесі, GPU жады
• сатылы жүктеме тестінің нәтижелері: қай QPS/concurrency кезінде кезек өседі, p99 SLA-дан қай жерде шығады, қай жерде OOM немесе троттлинг басталады
• перегрузкаға реакция жоспары: бірінші қимыл не? (concurrency шектеу, batch азайту, сапаны төмендету, трафикті бөлу, MIG қайта разрездеу, қосымша GPU қосу)

Шынайылықты жылдам тексеру

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

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

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

Ең сенімді старт — бір торапта пилот. 1–2 ең маңызды сервисті алып, MIG-ті қосып, бекітілген профильдер қойып, нақтыға ұқсас жүктемені өткізіңіз. Пилоттың мақсаты максимум сандар емес, болжамдылық: берілген latency‑де қандай throughput шығады және кезек қай жерде өседі.

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

• MIG профилі (қандай GPU түрінде тексерілген)
• сервис/модель және версиясы, batch қолданысы және негізгі параметрлер
• рұқсат етілген жүктеме: RPS немесе токен/сек, қандай шектеулермен
• SLA: p95/p99 және максималды кезек ұзындығы
• резерв: трафик өссе, қай кезде разрезді қайта қарастыру керек

Мысал: сервис A p95 120 мс-ті 10 RPS дейін ұстайды, ал 12 RPS-тан кейін кезек өсіп, p99 300 мс-тан асады. Мұндай ереже алерт пен жоспарлау үшін пайдалы: «жылдам/жай» туралы пікірталасқа қарағанда, кезек пен хвосттарды көруге жеңіл.

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

Егер пилоттан өндірістік деңгейге көшіруге көмек керек болса, GSE.kz инфрақұрылым бөлігін жаба алады: серверлер таңдау және жеткізу (S200 Series қоса), инференс стек жинау, мониторинг орнату және 24/7 қолдау көрсету. Бұл стандартты жылдам бекітіп, барлық сарапшылықты бір командада ұстауға көмектеседі.