Дата-орталықтағы NVIDIA GPU мониторингі: DCGM және ескертпелер

GPU мәселелерін алдын-ала неден іздеу керек

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

SLA үшін қауіпті тек аппараттық ақаулар ғана емес, сонымен қатар өнімділіктің жасырын жоғалуы. Қызу қорғаныс үшін жиіліктерді төмендетеді және инференс немесе оқыту айтарлықтай баяулайды. Жадтағы (ECC) қателер тапсырмалардың құлауына, контейнерлердің қайта іске қосылуына және, сирек болса да, нәтижелердің қате шығуына әкелуі мүмкін. Тұрақты throttling кластердегі жоспарлы жүктемені кезекке айналдырады.

Дата-орталықта NVIDIA GPU мониторингін үш қабатта құру ыңғайлы:

• түйін деңгейі: қуат, салқындату, драйвер, жалпы тұрақтылық;
• әр GPU: нақты қай карта нашарлай бастағанын анықтау;
• қосымша: бизнестегі әсер — орындалу уақытының өсуі, retry-лердің көбеюі, throughput-тің төмендеуі.

Инцидентке дейін ұстайтын ерте сигналдар:

• бірдей жүктемеде және желдеткіш жылдамдығында температураның өсуі;
• түзетілуге болатын ECC қателерінің пайда болуы, әсіресе санның күннен күнге өсуі;
• жиі болатын throttling оқиғалары және жүктеме кезінде effective clocks-тың төмендеуі;
• бірдей өнімділік кезінде тұтынудың өсуі (салқындату немесе қуат проблемаларының белгісі);
• утилизацияның тұрақсыздығы: пилообразные графиктер, кенет тоқтап қалулар.

Практиктегі мысал: бір стойкада тапсырмалар 10–15% ұзақ жұмыс істей бастады, бірақ қаталар болған жоқ. Егер әр карта бойынша температура, ECC және throttling метрикалары болса, себепті әдетте тез табуға болады: бір GPU әлдеқашан қызып, жиіліктерін жиі төмендеткен.

DCGM қарапайым тілмен: дата-орталықта не береді

DCGM (Data Center GPU Manager) — NVIDIA ұсынған серверлік ортадағы GPU-ларды пайдалану құралдары жиынтығы. Ол видеокартаны мониторинг объектісіне айналдырады: статусымен, метрикалардың тарихымен және жылдам денсаулық тексерістерімен. Көбінесе DCGM базалық қабат болады, оның үстіне дашбордтар мен алертер жасалады.

DCGM-ның күшті жағы — деректер жинауды стандарттау және әр түрлі түйіндер мен модельдер арасында салыстыру мүмкіндігі. Әртүрлі утилиталардың шашылған көрсеткіштері орнына бір метрикалар көзі мен бірыңғай тексерістер пайда болады.

Health checks пен метрикалар: айырмашылығы неде

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

Трендтік метрикалар басқа сұраққа жауап береді: уақыт өте нашарлап жатыр ма? Мұнда күндер мен апталар бойынша графиктер маңызды: бірдей жүктемеде температураның өсуі, түзетілуге болатын ECC-тің көбеюі, жиіліктердің өзгеруі, throttling уақыт үлесі.

DCGM түрлі деңгейдегі деректер береді, бұл диагностика дәлдігін арттырады:

• GPU толықтай: температура, жүктеме, жиіліктер, қуат;
• жад: көлемі, қателер;
• MIG (қосылған болса): инстанстар бойынша метрикалар;
• NVLink және PCIe: қателер мен өткізу қабілеті;
• қуат және шектер: power cap және жиіліктердің төмендеу себептері.

Көп жағдайда контексттің жоқтығы қате қорытындыларға әкеледі. Жоғары температура әрқашан ақау дегенді білдірмейді: бұл ұзақ 100% compute кезінде қалыпты болуы мүмкін. Керісінше, төмен жүктеме кезінде жоғары тұтыну power limit-тер немесе фондық процестер салдарынан болуы мүмкін. Сондықтан бір көрсеткішті емес, бірнеше белгіні бірге қарау пайдалы.

Exporter-лар және мониторинг схемасы: бәрін қалай байланыстыруға болады

Мониторинг үшін маңыздысы — тек метрика ғана емес, ол графиктер мен ескертпелерге қалай жететіні. Prometheus тәсіліндегі инфрақұрылымда әдетте былай жасайды: түйінде DCGM GPU күйін оқиды, ал DCGM-Exporter оны HTTP метрикалары ретінде береді.

Типтік тізбек келесідей:

• GPU бар түйін: NVIDIA драйвері + DCGM;
• экспортер: DCGM-Exporter;
• жинақтаушы (мысалы, Prometheus немесе сәйкес агент): экспортерлерді опраш етеді;
• метрика сақтау: тарихты сақтайды;
• дашбордтар және алертер: графиктер, шекті мәндер, хабарламалар.

Деректер көп болғанда еру қаупі бар, сондықтан метрикаларды деңгей бойынша бөліңіз: per-GPU деградацияны, per-process кім GPU жүктейтіні мен жадты кім алатынын, per-node контекстін (ауа температурасы, қуат, желдеткіштер, PCIe қателері) көрсету үшін.

Лейблдарды алдын ала ойластырыңыз. Жақсы лейблдар зерттеуге кеткен сағаттарды үнемдейді. Әдетте тиімді минимум: hostname, gpu_index және uuid, serial (қолжетімді болса) немесе инвентарлық ID, slot/pcie_bus_id, pool/role (training, inference, vdi).

Кластерді turnkey жинасаңыз, осы лейблдарды инвентаризация мен ұстаумен шынымен байланыстыру ыңғайлы. Сонда алерт тек «GPU 0» емес, нақты слоттағы және пулдағы карта туралы айтады.

Негізгі GPU метрикалары: ең алдымен неге қарау керек

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

Температура — бір ғана цифр емес. Ядро температурасы маңызды, сондай-ақ жад (бар болса) және hot spot көрсеткіштерін қараңыз. Кейде ядро қалыпты көрінсе де, жад шаң, кепкен термопрокладка немесе әлсіз обдув себебінен қызуы мүмкін.

Кейін — тұтыну және қуат шектері. Power draw пен power limit жұбы карта өнімділігі қуат лимитіне ұшырай ма жоқ па екенін көрсетеді.

Жиіліктер мен олардың төмендеу себептері жай ғана ағымдағы жиілікке қарағанда пайдалырақ. DCGM-де әдетте карта неге жиілігін төмендеткені көрінеді: қызу (thermal), қуат лимитіне жету (power) немесе сенімділік режимдері (reliability). Бұл себептер шеңберін тез тарылтады.

Utilization жиі адастырады. Жоғары utilization оқыту мен инференс үшін қалыпты. Мәселе — егер бірдей жүктемеде орындалу уақыты өсіп, жиіліктер төмендеп немесе throttling көбейсе.

Тағы бір ерте сигнал — PCIe: throughput пен тасымалдау қателері (retry-лер, түзетілуге болатын қателер). Бір түйінде ретрайлердің көбеюі контакттың нашарлығы, райзер деградациясы немесе слотпен проблема болуын көрсетуі мүмкін.

Жылдам бастау үшін қараңыз:

• температуралар (GPU, hot spot, жад);
• power draw vs power limit;
• жиіліктер және throttling себептері;
• GPU utilization және memory utilization;
• PCIe throughput және қателер/ретраи.

Мысалы, бір S200 Series серверде бір карта көршілерінен 8–10 C жоғары жад температурасына ие болды және кейін қысқа thermal throttling пайда болды. Бұл әдетте сол позициядағы салқындатуды тексеруге себеп болады, ECC-қа немесе тапсырмалардың құлауға дейін күтпеуге болады.

ECC және жад метрикалары: құлау болмас бұрын қалай байқау керек

GPU-дегі ECC жад қателерін табуға және олардың бір бөлігін ұшып түзетуге арналған. Дата-орталық үшін бұл деградацияның ең ерте сигналдарының бірі.

Негізгі бөлініс: SBE және DBE. SBE (single-bit error) әдетте жөнделеді және бірден тапсырмаға әсер етпеуі мүмкін, бірақ олардың өсуі әдетте нақты картаның немесе жұмыс жағдайының бұзылуын көрсетеді. DBE (double-bit error) түзелмейді және жиі драйвер құлауына, процесс тоқтауына немесе қайта жүктеуді талап етеді. DBE көбінесе инцидент ретінде қарастырылады.

SBE/DBE есептегіштерінен басқа, retired pages — қолданудан алынып тасталған жад беттеріне назар аударыңыз. Драйвер журналдарынан Xid оқиғаларын да тарту пайдалы: бір реттік Xid кездейсоқ болуы мүмкін, бірақ бір GPU-да қайталанатын Xid және ECC-тің өсуі трендтің анық белгісі.

Шуды емес, деградацияны қалай ажыратуға болады:

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

Жұмыс режимі көріністі қатты өзгертеді. Оқыту кезінде жүктеме мен қызу жоғарырақ, сондықтан жасырын мәселелер тезірек көрінеді. Инференсте қателер баяу жинақталуы мүмкін.

Түйінді қайта жүктеу есептегіштердің бір бөлігін өшіруі мүмкін екенін ескеріңіз. Сондықтан уақыттық қатарлар бойынша өсу жылдамдығына негізделіңіз.

Қысқа мысал

Егер бір серверде SBE тек GPU-2-де өссе, бұл өсу жад температурасының әдеттегіден жоғары сақталған кезеңдеріне сәйкес келсе және қатардан retired pages пайда болса — бұл картаны алдын ала ауыстыру немесе жүктемені көшіру үшін жақсы кандидат, тіпті DBE әлі болмаса да.

Throttling және жиіліктер: GPU өнімділігінен айырмашылықты қалай білуге болады

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

Дата-орталықтардағы throttling себептері: қызу (thermal), қуат шектеуі (power), сенімділік шектеулері (reliability) және төмен жүктеме кезінде үнемді режимге өту. DCGM бұл туралы throttling себептері мен ағымдағы графикалық және жад жиіліктері арқылы көрсетеді.

Clock capping және төмендетілген қуат лимиттері

Кейде мәселе жабдықта емес, баптауда болады. Қатты шектелген жиіліктер (clock capping) және тым төмен power limit GPU-ны салқын күйінде де бәсеңдетуі мүмкін. Егер қалыпты температурада power-throttle оқиғалары көп болса, қуат шектерін және профиль баптауларын тексеріңіз. Бұл әсіресе драйвер жаңартуларынан, прошивкаларды ауыстырудан, PSU-ны ауыстырудан немесе серверді басқа стойкага көшіруден кейін маңызды.

Энергияны үнемдеу мен салқындатудың деградациясын қалай ажырату керек

Қалыпты энергия үнемдеу төмен жүктеме, төмен тұтыну және жиіліктердің өзгеруімен сипатталады, бірақ жүктеме артқанда жиіліктер тез қалпына келеді.

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

Қысқа шыңдарға емес, ұзақтығы мен қайталануына қараңыз. 5–15 минут ішінде throttling уақыт үлесін бағалап, осы GPU моделі мен жүктеме түріне арналған базалық сызықпен салыстыру ыңғайлы. Егер бір сервер бірдей тапсырмаларда жиі thermal-throttle-ға түссе — бұл шаңы, ауа ағымының нашарлауы, желдеткіштердің тозуы немесе термопастаның кебуі сияқты проблемалардың ерте белгісі.

Қадам-қадам: DCGM мониторингі мен алерттерді қалай баптау керек

Бастау үшін: нақты не ұстамақшысыз? Әдетте мақсаттар үш: инциденттер (GPU шынымен бұзылғанда), деградация (аяқталмаған, бірақ өнімділік төмендеген кезде) және сыйымдылық (кластерде жеткілікті ресурс бар ма).

1) DCGM метрикаларын жинап, лейблдар туралы келісіңіз

Әр түйінде DCGM мен exporter орнатып, метрикалар біркелкі жиналуын қамтамасыз етіңіз. Лейблдарды бірден келісу керек, әйтпесе салыстыру қиын болады. Көбінесе жеткілікті: cluster, site, node, gpu_uuid, gpu_index, model, driver, pool.

Содан кейін негізгі метрикалар жиынын таңдаңыз: температура, тұтыну, utilization, жиіліктер, ECC, throttling себептері. Аз да болса бәрінде тұрақты және бірдей болғаны жақсы.

2) Шектер мен уақыт терезелерін қойыңыз

Шектер уақытсыз жиі шуды тудырады. Көбіне үш горизонт жеткілікті: 5 минут (жылдам инцидент), 30 минут (тұрақты деградация), 24 сағат (тренд). Қысқа түрде температураның секіруі бір нәрсе, ал тұрақты шың — салқындату мәселесі.

3) Дашбордтар: түйін және пул

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

4) Флаппингсіз және маршрутизациясы анық алерттер

Алерттер көмектесетін болуы үшін:

• іске қосылу кешігуін қосыңыз (10–15 минут ұстап тұру);
• деңгейлерді бөлектеңіз (warning және critical);
• node және gpu_uuid бойынша топтаңыз, сонда он шақты бірдей хабарламаны алуға жол бермейді;
• ECC пен жиіліктердің күрт төмендеуін дежурмен бөлістіруге жіберіңіз, ал күндік трендтерді жоспарлы жұмысқа бағыттаңыз;
• жауапты тұлғаны алдын ала анықтаңыз: ЦОД эксплуатациясы, ML командасы, вендор/интегратор.

Температура, ECC және throttling бойынша алерт мысалдары

Төменде Prometheus үшін DCGM exporter арқылы жиналатын метрикалар бойынша алерт мысалдары бар. Логика қарапайым: warning проблема басталғанын ұстайды, critical — әрекет ету қажеттілігі жоғары болғанда.

groups:
- name: gpu-alerts
  rules:
  # Температура: warning/critical үшін түрлі терезелер
  - alert: GPU_Temperature_Warning
    expr: max_over_time(DCGM_FI_DEV_GPU_TEMP[10m]) \u003e 80
    for: 10m
    labels: {severity: warning}
    annotations:
      summary: \"GPU температура повышена\"
      description: \"Проверьте охлаждение узла (воздух, фильтры, вентиляторы), нагрузку, соседние GPU. Сравните с другими картами в сервере.\"

  - alert: GPU_Temperature_Critical
    expr: max_over_time(DCGM_FI_DEV_GPU_TEMP[2m]) \u003e 90
    for: 2m
    labels: {severity: critical}
    annotations:
      summary: \"GPU перегревается\"
      description: \"Срочно: уменьшить нагрузку/перенести джобы, проверить airflow в стойке и состояние кулеров. Риск throttling и аварийных остановок.\"

  # ECC: DBE сразу, SBE по росту за период
  - alert: GPU_ECC_DBE_Detected
    expr: increase(DCGM_FI_DEV_ECC_DBE_VOL_TOTAL[5m]) \u003e 0
    labels: {severity: critical}
    annotations:
      summary: \"ECC DBE ошибка на GPU\"
      description: \"DBE обычно приводит к падениям. Зафиксируйте GPU/сервер, проверьте логи драйвера, планируйте диагностику и замену.\"

  - alert: GPU_ECC_SBE_Growing
    expr: increase(DCGM_FI_DEV_ECC_SBE_VOL_TOTAL[6h]) \u003e 100
    for: 30m
    labels: {severity: warning}
    annotations:
      summary: \"ECC SBE ошибки растут\"
      description: \"Это ранний сигнал деградации памяти или условий работы. Сравните рост по GPU, проверьте температуру и питание, запланируйте тест.\"

  # Throttling: доля времени в ограничениях и постоянный cap
  - alert: GPU_Thermal_Throttling_Ratio
    expr: (rate(DCGM_FI_DEV_THERMAL_VIOLATION[5m]) / 1e6) \u003e 0.05
    for: 10m
    labels: {severity: warning}
    annotations:
      summary: \"GPU часто уходит в thermal throttling\"
      description: \"Более 5% времени за последние минуты GPU ограничивает частоты из-за температуры. Проверьте охлаждение и плотность размещения.\"

  - alert: GPU_Power_Cap_Constant
    expr: (rate(DCGM_FI_DEV_POWER_VIOLATION[15m]) / 1e6) \u003e 0.10
    for: 30m
    labels: {severity: warning}
    annotations:
      summary: \"GPU часто упирается в power cap\"
      description: \"Если это не ожидаемая настройка, проверьте лимиты мощности, блоки питания и распределение нагрузки по GPU.\"

Күрделі алерттер бір қана симптом жеткіліксіз болғанда пайдалы. Мысалы, жоғары температура мен thermal throttling-тің қатар өсуі әдетте салқындату проблемасын білдіреді. ECC өсуі (әсіресе SBE) мен драйвер журналдарындағы қайталанатын Xid бірге болса — картаны тезірек миссиялық тапсырмалардан алу керек.

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

Реалистік мысал: бір GPU деградациясын қалай тапты

Бір түйінде кенеттен бір эпоха уақыты өсті: оқыту 12–18% баяулады, ал жүктеме мен код өзгермеген. Дашбордта бір GPU басқаға қарағанда қатты қызғаны көрінді.

Метрикаларда бұл былай көрінді: проблемалық GPU температурасы 83–86°C шамасында болды, ал көршілері 70–74°C. Сонымен бірге температураға байланысты throttling оқиғалары көбейді: SM clock пен memory clock төмендеді, utilization жоғары болып қалды.

Бұл қылық power cap-пен шектелген жағдайда басқаша көрінеді: power usage power limit-ке ұмтылады, throttling себептерінде PWR басым болады, ал температура қалыпты болуы мүмкін.

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

Не істеді:

• желдеткіштер мен ауа ағымын (революциялар, фильтрлер, ағыс бағыты, кіріс температура) тексерді;
• тапсырмаларды тоқтатып, түйінді шаңнан тазалады;
• термоинтерфейс жағдайын тексеріп, термопастаны алмастырды;
• картаны көрші слотқа ауыстырып, шасси аймағының локалдық қызуын жоққа шығарды;
• егер ECC температура қалыпқа келгеннен кейін де өссе — GPU-ны ауыстыруды жоспарлады.

Нәтиже трендтермен расталды: температура 72–75°C-қа оралып, thermal throttling шамамен нөлге түсті, жиіліктер тұрақталды, эпоха уақыты бұрынғы деңгейге келді. ECC есептегіштер жүктеме кезінде өспей қалды. Бұл бастапқы себеп салқындату проблемасы екенін көрсетті, жад деградациясы емес.

GPU мониторингіндегі жиі қателер мен тұзақтар

Ең көп кездесетін қате — мониторингті тек GPU utilization графигіне алып келу және сол жерде тоқтап қалу. Utilization пен тұтыну картаның не істеп жатқанын жақсы көрсетсе де, денсаулық туралы көп айтпайды. Деградация көбінесе температурада, жүктеме кезіндегі жиіліктерде, жад қателерінде және қайталанатын құлауда көрінеді.

Екінші тұзақ — барлыққа бірдей шектер қою. Бір стойкада әртүрлі NVIDIA модельдері, әртүрлі жүктеме профильдері (оқыту, инференс, VDI) және әртүрлі ауа ағымы болуы мүмкін. Егер бірдей шекті қою: температура 80°C = критикалық, модельге және шартқа байланыссыз болса, онда сіз жалған ескертулердің көптігіне не нақты проблеманы өткізіп жіберуге тап боласыз.

Үшінші проблема — аппараттық сәйкестіксіз метрикалар. Егер uuid/serial және сервер-слот-GPU байланысы бекітілмесе, инцидент кезінде нақты қандай карта деградацияланып жатқанын анықтау қиын болады. Бұл маңызды, әсіресе техникалық қызметтен кейін карталар орындарын ауыстырса.

Тағы бір ауру — флаппинг: алерт пайда болып, қайта жойылып отырады. Әр жүктеме шыңында қысқа мерзімді throttling шуға айналып, команда жауап беруді тоқтатады.

Соңғы — тарихтың болмауы. 30–90 күнге жетерлік деректерсіз сіз трендті көре алмайсыз: температура аптасына 1–2 градус өсіп жатыр, жиіліктер шектеліп жатыр, ECC қателері жиілеп жатыр.

Пайдалы практикалар:

• өнімділік пен денсаулықты бөлу; температура, throttling және ECC үшін жеке алерттер енгізу;
• модель мен жүктеме түріне сай шектерді орнату, ауа температурасын ескеру;
• метрикаларды сериялық нөмір мен орнату орнына байлау;
• флаппингті азайту үшін кешіктірулер мен шарттар қосу;
• баяу деградацияны көру және ауыстыруды жоспарлау үшін метрикаларды жеткілікті уақыт бойы сақтау.

Қысқа чеклист: 10 минут ішінде не тексеру керек

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

Бес затты тексеріңіз:

• GPU температурасы және, егер бар болса, жад температурасы: жүктеме кезінде тұрақты қызу бар ма;
• throttling: температура немесе қуат бойынша шектеулер уақыт үлесі өсіп жатыр ма;
• ECC және retired pages: DBE жоқ, SBE күн сайын өсіп жатқан жоқ па;
• Xid: бір GPU-да қайталанатын оқиғалар жоқ па;
• топ бойынша ауытқу: бір карта немесе бір түйін температура, ECC және throttling бойынша қалғандардан ерекшеленбеуі.

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

Келесі қадамдар: мониторинг пен қолдауды стандарттау

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

Алдымен сіздің кластеріңіз бен SLA үшін маңызды метрикаларды анықтаңыз. Оқыту үшін көбінесе қуат пен температураға байланысты throttling, ECC қателері және жиіліктердің төмендеуі маңызды; VDI мен графикада чаще қызықтыратын — қызу, вентилятор жылдамдығы және жад тұрақтылығы.

Содан кейін әрекет процесін бекітіңіз: әр алерттің иесі және нақты шешім нүктесі болуы керек — кім хабар алады, кім мәселені растайды, кім GPU-ны пулдан шығарып, қанша уақытта.

Минимум стандарт ретінде бекітуге тұрарлық:

• дашбордтар жиыны: температура, жиіліктер, қуат, utilization, жад, ECC, throttling себептері;
• алерттер жиыны: критикалықтар (қазір әрекет ету) және ескертулер (бақылау және жоспарлау);
• қысқа runbook: 5 минутта не тексеру, қандай журналдар жинау, қашан эскалировать;
• карантин саясаты: күдікті GPU-ны белгілеу және оған жаңа тапсырмалар бермеу тәртібі;
• трендтерді тұрақты қарау, баяу деградацияны ұстап, ауыстыруды жоспарлау.

Профилактика жиі шектеулерді дәл баптаудан гөрі тиімді: тазалау, ауа ағымын бақылау, вентиляторлар мен термоинтерфейстерді тексеру. Егер трендтер бірдей жүктемеде температураның өскенін немесе correctable ECC-тің көбеюін көрсетсе — алдын ала қызмет көрсетуге уақыт бөлу орынды.

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