HPE Apollo үшін HPC: GPU/CPU түйінін жобалау және метрикалар

HPC лабораториясында мәселе әдетте қалай басталады

HPC лабораториясы үшін «ең қуатты сервер» емес, нақты тапсырмалар бойынша есептің болжамды уақыты маңызды. Бұл GPU‑да модельдерді оқыту, CFD, молекулалық модельдеу, кескіндерді өңдеу, геномика немесе курстар мен жарияланымдарға арналған пакет есептер болуы мүмкін. Шектеулер де бірдей: сервер бөлмесіндегі орын, электр қуатын шектеу, шу, қолдау-бюджет және осыны қызмет көрсететін адамдар.

Жоспар көбіне «GPU мен CPU‑ды тығыз орналастыру» деген сәтте бұзылады. Қағазда қосымша жылдамдатқыштар мен ядролар жеткілікті көрінуі мүмкін, бірақ практикада әдетте қуат жетіспейді (стойкаға және фазаларға керек кВт жетпейді), салқындату — ауа жеткіліксіз (ыстық дәліздер ұйымдастырылмаған), және желі/хранилище — деректер уақытында келмей, GPU‑лар простауды бастайды. Кейде физика деген төртінші шектеу қосылады — узел биіктігі, стойка тереңдігі немесе салмақ шегі.

Әдетте үш тәсіл салыстырылады: бөлшектерден жинау, HPE Apollo сияқты дайын тығыз GPU‑түйін желілерін таңдау немесе бір стойкада бірнеше түйіні бар шасси таңдау. Айырмашылық тек бағада емес, сонымен бірге «тосын сыйлар құнында»: стойка, PDU, резервтеу, қолдау және запчастьтерге қойылатын талаптар қаншалықты ерте түсінілген.

«Өсіп кету» үшін қымбат сатып алмау және ақшаны жоғалтпау үшін пилотта қандай метрикалар пайдалы болатынын алдын ала келісіп алған жөн. Мысалы: типтік тапсырмадағы нәтижеге дейінгі уақыт (wall time), GPU/CPU жүктемесі, енгізу‑шығару өткізу қабілеті, көпсағаттық прогондардағы тұрақтылық және апта сайын қанша тапсырма өтетіні. Сол кезде түйінді максималды паспорттық сипаттамалар бойынша емес, өлшенетін әсерге бағыттап жобалайсыз.

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

Талаптарды қою: аппаратты таңдамас бұрын не нақтылау керек

HPC жабдықты сатып алу көбіне брендте емес, тапсырмалардың қаншалықты дәл сипатталғанында тұрып қалады. Бірдей HPE Apollo әртүрлі профильдерге бейімделуі мүмкін: бір жерде GPU маңызды, басқа жерде CPU жад көлемі немесе деректерге қолжетімділік басымды.

Одан бастаңыз: қай есептерді үнемі іске қосатыныңызды және жақсартуды қалай бағалайтыныңызды белгілеңіз. Тапсырмаларды бірнеше категорияға бөліп (мысалы, ML, CFD, молекулалық модельдеу, визуализация, VDI/қашықтан жұмыс), әрқайсысы үшін 2–3 типтік джоб жазыңыз: кіріс деректер, ұзақтығы, іске қосылу жиілігі және сәттілік критерийі.

Кейін — GPU мен CPU арақатынасын анықтаңыз. Жиі қателік: көп GPU алу, ал кейін CPU, жад немесе I/O‑да тірелу. Әр тапсырма үшін шынайы қанша CPU ағыны (threads) жүктелетінін және қанша жад қажет екенін, бір есепке қанша GPU керек екендігін және олардың арасындағы быстрая алмасу маңызды ма екенін анықтаңыз; дәлдік талаптары (FP32/FP16/FP64) тежегісі бар ма — соны ескеріңіз.

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

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

Ақырында, SLA: мақсатты есеп уақыты (time-to-result), рұқсат етілген тоқтап қалулар және техникалық қызмет көрсету терезелері. Егер қолжетімділік маңызды болса, қуат, сервис пен запас бөлшектер үшін резервті конфигурацияны таңдау конфигурацияны бекітерден бұрын қажет.

Архитектуралық эскиз: HPE Apollo үшін қай бағытты таңдау керек

Эскиз — «ең қуатты түйіннен» бастамау үшін, нақты қайсысы нәтижені өсіретінін тез анықтауға қажет. HPE Apollo үшін екі негізгі бағыт: бір түйінде барынша көп GPU жинау немесе GPU/CPU‑ны теңдестіріп, жад, желі немесе қуатта тірелмеуді қамтамасыз ету.

Бірінші кезекте мақсатты сценарийді анықтаңыз. Егер тапсырмалар — модельдерді оқыту, рендер, молекулярлық динамика болса, көбіне бір түйінде көбірек GPU тиімді. Егер классикалық CPU+MPI, препроцессинг/постпроцессинг немесе көпағынды симуляциялар болса — CPU‑ядролар, RAM көлемі және желі өткізу қабілеті маңыздырақ.

Келесі қадам — «орын физикасын» тексеру. Тіпті мінсіз конфигурация да, егер стойка қуатты көтермесе немесе салқындату жеткіліксіз болса, жұмыс істемейді.

Қай жер жиі шектейді

Тар жер әдетте төрт аймақтың бірінде көрінеді: есептеу (GPU/CPU теңгерімінің бұзылуы), жад (RAM көлемі немесе өткізу қабілетінің жетіспеуі), желі (синхронизация және масштабтау ауыр), сақтау (I/O баяулығы және датасеттерді дайындау).

Сосын пилотқа салыстыру үшін 2–3 кандидат‑конфигурация таңдаңыз, сонда әділ салыстыру болады. Мысалы: «4 GPU + көп RAM», «8 GPU + минималды CPU», «теңгерім 4–6 GPU + жылдам NVMe scratch». Алдын ала өзгертілмеуі тиіс параметрлерді (GPU түрі, бір түйінге кВт лимиті, форм‑фактор) белгілеңіз, әйтпесе пилот үзіксіз сынаққа айналады.

Бюджеттік шектерді бірден бекітіңіз: CapEx (аппарат, стойка, желі, СХД) және OpEx (электр, салқындату, қолдау, простои). Практикалық тәсіл — пайдалы есеп сағатының құнын және GPU‑ның жад, желі немесе диск себебінен простобының құнын есептеу.

Қадам бойынша: GPU/CPU есептеу түйінін жобалау

GPU‑түйіннің болжамды жұмыс істеуі үшін сервер моделінен емес, жүктеме профилінен бастаңыз: нейрондық желілерді оқыту, инференс, CFD/CAE, рендер, биоинформатика. Бұдан CPU жиілігі ме, жад өткізу қабілеті ме, VRAM көлемі ме, әлде локальді scratch жылдамдығы ма маңызды екенін анықтайсыз.

1) CPU: жиілік vs ядра және NUMA

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

NUMA‑ны ескеріңіз: екісокеттік түйінде GPU‑лар мен желі адаптерлерін «өз» CPU‑ға жақын орналастырған дұрыс. Сондай-ақ жылу пакетін қараңыз: тығыз конфигурацияда әр сокетка қосымша 50–100 Вт көп кетсе, салқындатуды айтарлықтай қиындатады.

2) ОЗУ: қанша және каналдарды қалай толтыру

Жадқа үнемдеудің салдары қатты білінуі мүмкін, әсіресе GPU‑лар CPU‑дан деректер «жайығынан» алатын кезде. Кейбір тапсырмаларда 1 GPU‑ға 32–64 ГБ ОЗУ ұсынылады, бірақ нақты қажеттілікті датасет пен пайплайн бойынша есептеген дұрыс.

Жиілік емес, каналдарды дұрыс толтыру жиі маңыздырақ. Модульдерді симметриялы қою арқылы өткізу қабілетін сақтаңыз — толық емес конфигурациядан өткізу қабілеті төмендеуі мүмкін.

3) GPU: жылдамдатқыш түрі және VRAM

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

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

4) PCIe‑топология: алмасу тар жерге айналмау үшін

Әр GPU‑ның нақты қанша PCIe жол алатынын және желі/ NVMe қайда қосылғанын тексеріңіз. Қате — формальді түрде барлық жылдамдатқыштар бар, бірақ олар «урезанная» шинада отырады немесе жылдам дискілермен жол бөліседі — нәтижесінде деректер жүктелуі және алмасу баяулайды.

5) Локальді дискілер: NVMe scratch және кэш

Жалпы хранилище болғанымен түйінге жылдам локальді қабат керек болады: NVMe scratch, датасет кэші, уақытша файлдар және чекпойнттар. Бір экспериментке қанша орын қажет екенін және жылдам оқуды/жазуды немесе сенімділікті қайсысы жоғары бағалануын алдын ала анықтаңыз. Жақсы пилот түйіні бұл талаптарды нақты тексеріп, конфигурацияны кластерге көшіруге мүмкіндік береді.

Тығыз орнату: қуат, салқындату және стойкалар туралы күтпеген жағдайлар

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

Қуатты паспорттық TDP ғана емес, нақты тұтынуды есептеңіз. GPU‑ларда қысқа уақыттық шыңдар болады, ал CPU, GPU және желіні бір уақытта жүктегенде олар қосылады. Сенімділік пен бюджет үшін блоктар мен стойка желісіне 15–30% резерв қалдыру дұрыс.

Стойка мен PDU тапсырыс бермес бұрын тексеріңіз: түйін мен стойканың шекті шыңды және типтік орташа тұтынуды, PDU мен кіріс автоматында 15–30% резерв бар-жоғын, A/B‑қоректену қажеттігін және залдың бұл талапты көтеретінін, түйіннің ауаға қабылдайтын температура шегін (жоспарға +2–3 °C қосылып кеткендегі әсерін) және шу бойынша шектеулерді.

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

Қызмет көрсетуді да ойлаңыз: стойка әлі қағазда тұрғанда вентиляторды немесе БП‑ны қаншалықты жылдам ауыстыруға болатынын анықтаңыз; қай диск резервінде ұстау керек; түйінді салазкадан шығарып алмастыруға орын бар ма. Техник қауіпсіз түрде түйінді шығарып, 10–15 минут ішінде БП ауыстыра алмаса — тығыздық тым агрессивті таңдалған.

Желi және сақтау: GPU‑лар простауды бастамауы үшін

Түйіндегі GPU өте жылдам болуы мүмкін, бірақ егер деректер кеш келсе, сіз простауды төлейсіз. HPC‑да бұл GPU жүктемесінің төмендеуімен көрінеді: I/O немесе түйіндер арасы алмасуды күту кезінде GPU белсенділігі төмендейді.

Желi: Ethernet не InfiniBand

Егер тапсырмалар тәуелсіз (көп бөлек есептер, рендер, параметрлік прогоны) және деректер жақынырақ орналасса — сапалы Ethernet жеткілікті болуы мүмкін. Ал егер MPI, түйіндер арасындағы тығыз алмасу, бөлінген оқыту немесе жиі синхронизация болса — RDMA маңызды. Бұл InfiniBand немесе RDMA‑қолдайтын жоғары жылдамдықты Ethernet болуы мүмкін — кешігулер мен тұрақтылық шешуші.

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

Leaf‑spine топологиясы масштабтауда тар жерлерді болдырмауға көмектеседі. Порттарды «впритык» жоспарламаңыз: өсу әдетте екінші коммутаторға бюджеттен жылдамырақ келеді.

Сақтау: датасеттер мен нәтижелер қайда тұрады

Егер оқу үлкен ағынмен жүрсе және параллель клиенттер көп болса, параллель файлдық жүйе пайдалы. Қарапайым сценарийде NAS/SAN жетуі мүмкін, бірақ пиковты бірдей уақытта қаншалықты ұстайтынын тексеріңіз.

Практикада гибрид жиі тиімді: түйінде локальді NVMe — жылдам қабат (кэш, scratch) және ортақ хранилище — «шынайылық көзі». Мысал: 32 тапсырма іске қосылады, әрқайсысы 200 ГБ оқиды және 20 ГБ жазады. Егер scratch локальді NVMe болса, желі мен ортақ хранилище тұңшығып қалмайды, ал нәтижелер пакет бойынша сыртқа шығарылады.

Деректердің өмірлік циклін ұмытпаңыз: жобадан кейін нәтижелер қайда кетеді. Архив қабаты мен анық сақтық көшірме ережелері қымбат жылдам сақтау кеңейтуден арзан болуы мүмкін.

ПО және эксплуатация: пилот нәтижесіне әсер ететін факторлар

Пилот HPE Apollo үшін жиі аппараттан емес, ПО мен операциялық жақтан «сұранып» қалады. Типтік жағдай: қуатты GPU түйіні нашар көрсеткіш береді, себебі драйвер нұсқасы кітапханаларға сәйкес келмейді немесе бөліктер GPU‑ға дұрыс байланбаған.

Базалық стек тұрақты болуы керек: ОС, GPU драйверлері, кітапханалар (MPI, math, ML‑фреймворктар) және ортаның пакеттері. Контейнерлер «мында жұмыс істейді, онда істемейді» мәселесін азайтады, бірақ нұсқаларды және іске қосу ережелерін бекіткен жағдайда ғана. Пилотта тұрақты жиынтық таңдап, оны күн сайын өзгертпеңіз.

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

Операцияларды қалай жүргізетіндігіңізді алдын ала келісіңіз: бір «алтын» образ, өзгерістер журналы, техникалық қызмет көрсету терезесі және жылдам оралу жоспары; драйверлер мен кітапханаларды жаңар алдында үйлесімділікті тексеру керек.

Мониторингсіз бағалау сезімге негізделеді. Минимум — CPU/GPU жүктемесі, температуралар мен троттлинг, ECC қателері, жад пайдалануы, желі есептері және планировщик оқиғалары (кезекте күту, нақты жұмыс уақыты). Қауіпсіздік те маңызды: қолжетімділікті сегменттеу, мүмкін жерде MFA, командалар мен кірулер аудиті.

Пилотта қандай метрикалар жинау керек, бюджетті қорғау үшін

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

Инженерлер мен қаржы бөлімі үшін түсінікті метрикалар

Деректерді «тапсырма → түйін → кластер» контекстінде жинаңыз, сонда өсімнің қайдан шыққаны көрінеді.

• Өнімділік: нәтижеге дейінгі уақыт, throughput (тапсырма/сағат), GPU/түйін қосқандағы масштабталу.
• Пайдалану: GPU/CPU жүктемесі, жад тұтыну, I/O‑тан туындаған простаулар, желі, PCIe‑да шек болуы.
• Энергия тиімділігі: бір тапсырмаға ватт, жобаның кВт·сағ, шың тұтыну.
• Тұрақтылық: қателер, қызып кету, троттлинг, қайта жүктеулер, «қате» жүктемелерінің үлесі.
• Қолданушы тәжірибесі: кезекте күту уақыты, тапсырмаларды болдырмау пайызы, орта қашан орта орынға дайын болу уақыты.

Мысал: оқыту 10 сағаттан 4 сағатқа дейін жылдамдаса, бірақ GPU тек 55% жүктемеде болса, пилоттың өзі ғана емес, жоғалтудың себебі — баяу сақтау немесе желі екенін көрсетеді. Бұл паспорттық TFLOPS‑тан гөрі пайдалырақ.

Метрикаларды бюджеттік аргументке қалай аудару

Пилот есебінде қарапайым экономика жасаңыз: есеп сағатының құны (электр + қолдау + амортизация) және 3–5 жылға TCO болжамы жүктеменің өсуімен. Екі сценарий көрсеткен ыңғайлы: «қазіргі жағдай» және «тар жерді жойғаннан кейін».

Сатып алу комиссиясына әдетте жеткілікті: «тапсырмалар/уақыт до/уақыт пилотта/жылдық әсер» кестесі, 2–3 график (уақыт/баға, өнімділік ваттқа шаққанда, масштабталу) және тәуекелдер тізімі (қызу, қуат, сәтсіздіктер) пен оларды жабу жолдары.

Пилотты қалай өткізу: қарапайым жұмыс жоспары мен артефактілер

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

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

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

Өлшеулер қорғалуы үшін ережелерді бірінші іске қосудан бұрын белгілеңіз: 1–2 «жылытқыш» прогон есепке алынбайды; өлшеу үшін кемінде 3 прогоны болуы тиіс және нәтижелердің шашылуын тіркеу; BIOS/firmware, GPU драйверлері, CUDA, MPI және контейнер/ортаның нұсқалары бекітіледі; шарттар бірдей (қуат лимиттері, жиіліктер, бөлменің температурасы).

Шығарылған құжат: конфигурациялар бойынша нәтижелер кестесі, 2–3 график (уақыт/баға, өнімділік/ватт, масштабталу) және нақты сатып алу ұсынысы — қазір не алу және кейін не қосуға болатынын көрсетіңіз.

Тығыз GPU түйіндерін жобалау кезінде жиі кездесетін қателіктер

Бірінші тұзақ — тек TFLOPS‑қа қарау. Шын жұмыс жүктемелерінде түйін көбіне GPU жадында (көлемі мен өткізу қабілеті), CPU‑дан GPU‑ға алмасуда және I/O‑да тіреледі. Нәтижесінде қымбат жылдамдатқыштар 40–60% жүктемеде қалады, қолданушы «баяу» деп шағымданады және тағы GPU сұрайды.

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

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

Пилоттағы бақылау нұсқалары жоқ болуы — жеке бас ауру. Бір «жұмсақ» драйвер жаңартуы немесе кітапхана өзгерісі «до/кейін» салыстыруды жарамсыз қылады.

Сатып алу және масштабтау алдындағы тез чек‑тізім

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

1. Стойканың инженерлік дайындығы: стойкаға пикті есептеп, фазалар мен PDU бойынша таралымды тексеріңіз; суық/ыстық дәліздердің сақталатынын және тығыз GPU‑түйіндерге жеткілікті ауа ағымын растаңыз; кіріс ауа температурасын қайдан және қалай өлшейтініңізді бекітіңіз.

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

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

Мысал сценарий: зертхана HPE Apollo кластерін қалай негіздейді

10–20 зерттеушіден тұратын лаборатория есептер кезегінде тұрып қалды. Екі тип жұмыс бар: GPU‑да оқыту (қысқа, бірақ жиі) және CPU‑симуляциялар (ұзақ, көп жад талап етеді). Сонымен қатар стойкаға электр шегі бар — мысалы 20–30 кВт, және жай ғана серверлер қосып қою мүмкін емес.

Команда екі түйін кандидатын таңдайды: біреуі — GPU‑ға басым (көбірек жылдамдатқыш, орташа CPU), екіншісі — теңгерімді (аздап GPU, көп CPU ядросы мен ОЗУ). Пилот мақсаты — олардың кезегіне және кВт шектеулеріне ең жақсы қайсысының сай келетінін анықтау.

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

Содан кейін цифрларды ақшаға аударады. Мысалы, орташа есеп 12‑ден 8 сағатқа қысқарса, айына 50 тапсырма кезегі 200 сағат үнемдейді. Осы сағаттарды команда шығындары мен грант мерзімдерінің ықпалын есептеп, нақты әсерді көрсетеді. Қателік шығындарын да есептейді: қызып кету, троттлинг немесе жүктеу кезінде құлаған кезде жоғалған күндер.

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

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

Минималды артефакт жинаңыз: 1 бет талап (тапсырмалар, мақсатты уақыттар, деректер мен қолжетімділік шектеулері), 1 бет тәуекелдер (қуат, салқындату, желі, GPU тапшылығы, жеткізу мерзімдері, қауіпсіздік), 2–3 түйін конфигурациясы және өлшеу әдістемесі (ПО нұсқалары, датасеттер, жылытылу және қайталау ережелері). Пилот метрикалары мен 3–5 жылға TCO болжамын және әр тармақпен қандай тәуекел жабылатынын қысқа бюджет файлы ретінде қосыңыз.

Масштабтауды ойлаңыз: көлем екі есеге өссе, әдетте бірінші қайта қаралатындар — стойкадағы қуат пен резерв, салқындату және ыстық нүктелер, порт сыйымдылығы мен латенттілік, сондай‑ақ storage және scratch.

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