GPU кластерінің желісі: қашан 25/100GbE жеткілікті

Неге желіні есептеп алған дұрыс, «қорымен» емес

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

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

«Артық төлемсіз» деген желі тұрғысынан — нақты тапсырмаларға байқалатын әсер беретін нәрсені сатып алу және оқытуды шектемейтін жерге ақша жұмсамау. Қымбат болуы мүмкін тек 100GbE порты ғана емес, сонымен қатар оған тиесілі коммутаторлар мен лицензиялар, оптика мен кабельдер (қосалқысы бар), қуат пен салқындату, стойкадағы орын, команда біліктілігі талаптары, үйлесімсіздік тәуекелдері мен ұзақ мәселе шешу үдерістері.

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

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

Дата-орталық деңгейіндегі жобаларда бұл айқынырақ: интегратор ретінде GSE.kz жиі бірдей бюджетпен не "қымбат порттарды", не болжамды кластер жұмысын және өсуге түсінікті резерв алуға болатынын көреді.

GPU-кластердегі қандай жүктемелер желіні толтырады

GPU-кластердегі желі әрдайым жүктелмейді, ол нақты сәттерде және әртүрлі себептермен жүктеледі. Сондықтан алдымен профильді түсіну пайдалы: оқыту ма әлде инференс пе.

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

Таратылған оқытуда негізгі желі тұтынушысы — әртүрлі сервердегі GPU-лар арасындағы алмасу. Бұл коллективтік операциялар (мысалы, all-reduce), модель параметрлері немесе градиенттер үнемі синхрондалады. GPU саны неғұрлым көп және модель неғұрлым үлкен болса, алмасулар соғұрлым жиі және ауыр болады. Егер алмасулар баяу болса, GPU-лар бір-бірін күтіп қалады, және оқыту уақыты қуатты үдеткіштер болса да өседі.

Бөлек оқиға — деректер құбыры (data pipeline). Тіпті оқыту мінсіз бапталған жағдайда да, желі датасетті жеткізуде және алдын ала өңдеу нәтижелерінде шектелуі мүмкін: желілік сақтау жүйесінен оқу, чекпойнттар мен логтарды жазу, деректерді воркерлерге тарату (мәліметтер жүктегіш), кэштер мен тапсырма кезектерімен алмасу, сондай-ақ метрикалар мен эксперименттрекер сияқты «қызметтер айналасы».

Мысал: сіз 8 GPU-да оқыту жүргізесіз, екі серверде орналастырылған, ал датасет желілік сақтау жүйесінде жатыр. Эпоханың басында воркерлер белсенді оқиды, кейін желі градиент синхрондауына ауысады, ал параллельді түрде чекпойнттар жазылады. Мұндай шыңдарда қай жерде тар жер бар екені анық байқалады.

Кластер мен интеграцияны жоспарлағанда маңыздысы — ағымдарды алдын ала бөлу: GPU–GPU алмасуы, сақтау жүйесіне қолжетімділік және қызметтік трафик. Сол кезде қай жерде 25/100GbE жеткілікті, ал қай жерде желі шынымен оқыту жылдамдығын анықтайтыны анық болады.

Өткізу қабілеті мен латенттік: не шын мәнінде оқыту уақытын әсер етеді

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

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

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

"25/100GbE портында" жазылған сандар мен қолданба көретін жылдамдықты шатастырмау маңызды. Қолданба жылдамдығына протоколдардан келетін шығындар, MTU баптаулары, коммутатордағы кезектер, бәсекелес ағындар және оқыту фреймворкы алмасуды қалай жинақтайтыны әсер етеді.

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

Практикалық түрде себептерді ажыратудың тәсілдері:

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

Кластерді жоспарлағанда гигабиттермен қатар латынасты және оның тұрақтылығын да өлшеу пайдалы. Бұл көп жағдайда неге бірдей «100GbE» спецификациядағы жүйелер әртүрлі оқыту уақыты көрсететініне түсінік береді.

Қашан 25GbE жеткілікті, ал қашан 100GbE қажет

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

25GbE жиі жеткілікті болған жағдайлар:

• бір түйінде 1–2 GPU-де немесе аз тораптарда оқыту жүріп, бірнеше түйін қосқанда масштабтау «бұзылмайды";
• модельдер мен батчтар орташа, және GPU саны өскенде итерация уақыты шамалы өзгереді;
• параллель тапсырмалар аз, бір аплинк үшін тұрақты бәсеке жоқ;
• сақтау жүйесіне трафик бөлек жолмен өтеді немесе GPU–GPU трафигімен бірдей аплинкте шатаспайды.

Егер синхрондау кезінде GPU тұрса және линк жүктемесі шегіне жақындаса, 100GbE нақты әсер беруі мүмкін, тіпті кластерді қайта құрмастан.

100GbE әдетте орынды болған жағдайлар:

• ондаған GPU-ға дейін өсу жоспарланған және түйін қосқанда шынымен жылдамдық өсуін қалайсыз;
• көп түйінді таратылған оқыту және жиі all-reduce сияқты операциялар қолданылады;
• бір коммутаторға көп түйін қосылып, аплинктер басты шектеу болып тұр;
• оқыту трафигін деректер трафигінен бөліп, көп желілерсіз шешкіңіз келеді.

Өсу бағалауын 12–18 айға қарай жасау пайдалы: қанша түйін, түйінге қанша GPU және қанша бір мезгілдегі тапсырма болады. Практикалық тәсіл — «мақсатты конфигурацияны» есептеп, желіні тек орташа жүктемені емес, синхрондау шыңдарын да ұстай алатындай таңдаңыз.

Сақтау жүйесіне баратын трафикті жеке ескеріңіз. Егер data-loader-лар үлкен жиындарды оқып, параллельді чекпойнттар жазылса, аплинк толып қалуы мүмкін, тіпті GPU–GPU алмасу өзі салыстырмалы болса да. Мұнда сақтау үшін бөлек желілік жол бөлу немесе белсенді оқу мен алмасу жүретін түйіндерге 100GbE қолдану көмектеседі.

Қай жерде төмен латенттік шын мәнінде маңызды

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

Ең жиі кездесетін жағдай — көп түйінді таратылған оқытуда синхронизация. All-reduce немесе all-gather сияқты коллективтік операциялар барлық GPU-ларды бір-бірін күтуге мәжбүр етеді. Бір түйін дерек азырақ кеш алса, бүкіл топ тұрып қалады. Нәтижесінде GPU-лар 100% толтырылмаған болуы мүмкін, дегенмен «гигабиттер» бойынша резерв бар.

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

Тағы бір күрделі жағдай — аралас жүктемелер. Сол линктерде оқыту мен инференс немесе деректер оқуы қатар жүруі рейтингілік кезектерге әкеліп, орташа латенттік қалыпты болып көрінсе де, p95–p99 хвосттар күрт өсіп, оқыту қадамы ауытқиды.

Ақырында, «бір баяу линк» барлық топты тежеп тастауы мүмкін. Бұл міндетті түрде сынып қалу емес — порт жылдамдығының қателігі, аплинк шамадан тыс жүктелуі немесе кабель орналастыруының дұрыс еместігі де себеп болуы мүмкін. Латенттік маңызды болғанының типтік белгілері:

• қадам уақыты тұрақсыз, ал GPU мен CPU жүктемесі қалыпты;
• түйін саны өссе тиімділік күткендей кемиді;
• мониторинг бір-екі портта кезектер немесе дроптар көрсетеді;
• бір сервердегі кішкене нашарлау бүкіл пула баптауын баяулатады.

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

Топология және oversubscription: схемаға өнімділікті жоғалтпау

GPU-кластердегі қосылу схемасы порттағы саннан аз маңызды емес. Екі кластерде бірдей 25/100GbE болуы мүмкін, бірақ бірінде желі жақсы құрылған, ал екіншісінде трафик үнемі тар жерлерге тіреледі — олар әртүрлі мінез көрсетеді.

Қандай схема кездеседі және олар неге бөлек

Дата-орталықтарда ең жиі кездесетін нұсқа — spine-leaf: серверлер стойкадағы ToR/leaf коммутаторларына қосылады, ал олар spine-ге қосылады. Мұндай фабрика жақсы масштабталады және өткізу қабілетін болжауы оңай.

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

Oversubscription қарапайым тілмен — «төменге» (серверлерге) порттардың суммарлық жылдамдығы «жоғарыға» (магистральге) қарағанда көп болғанда. Мысалы, 16 сервер 25GbE-ден 400Gbps береді, ал аплинктер тек 200Gbps. Егер трафик локал болса, бұл байқалмайды. Бірақ оқыту немесе инференс торапаралық белсенді алмасуды бастағанда кезектер, жоғалтулар және латенттік секірулері пайда болуы мүмкін.

Қашан неблокирлеуші фабрика қажет, қашан жеңілдетуге болады

Неблокирлеуші (немесе оған жақын) фабрика оқытуда көп GPU-тар арасында бір уақытта алмасу күтілген жерлерде қажет. Қарапайым сценарийлерде орташа oversubscription жеткілікті болуы мүмкін, егер ағындардың көбісі бір стойка ішінде қалса немесе маңызды қызметтер бөлек VLAN немесе фабрикада орналасса.

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

Практикалық нұсқа: алдымен тораптар арасындағы east-west трафиктің қанша болатынын шешіп алыңыз, содан кейін топология мен oversubscription коэффициентін осы профильге сай таңдаңыз, «қормен» емес.

Құрал ретінде: сатып алудан бұрын желі талаптарын қалай анықтау керек

Бастысы — сізге ең жылдам желі емес, нақты тапсырмаларды тежемейтін және қажетсіз төлемдерден сақтайтын желі қажет.

1) Сценарийлерді сипаттап, олардың «желілік профилін» анықтаңыз

3–4 типтік сценарий жинап, деректермен не болатынын жазып шығыңыз. Мысалы: көп түйінді оқыту (GPU-аралық көп алмасу), инференс (тұрақтылық маңызды), ETL және датасеттерді дайындау (сақтау жүктемесі басым), деректерді жүктеу және чекпойнттар (трафик шыңдары).

Осыны келісімді ету үшін қысқа тізім жасаңыз:

• қай тапсырмаларды жиі іске қосасыз және олардың қанша уақытқа созылатыны;
• бір тапсырмада қанша GPU және қанша түйінде;
• деректер қайдан оқылады (локальды, NAS, объектілік сақтау);
• чекпойнттар қаншалықты жиі жазылады және олардың көлемі қандай;
• не бастырақ: модельді тезірек оқыту ма әлде бюджетке сыйу ма.

2) Негізгі метрикаларды жинап, мақсат қойыңыз

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

Содан кейін 6–12 айға мақсатты масштабты бекітіңіз: қанша түйін және GPU жоспарланған, және масштабтау кезінде оқыту уақыты қаншаға өссе рұқсат етіледі. Мысал: қазір 4 түйін, бір жылдан кейін 12, және оқыту уақыты масштабтағанда 15–20% артық болмауы керек.

3) Линк жылдамдықтарын және өсу жоспарын таңдаңыз

Бұлдан кейін 25GbE немесе 100GbE шешімін қабылдау оңайырақ: сіз вакуумдағы жылдамдықты емес, нақты шыңдарға (түйіндер арасындағы алмасу, чекпойнттар, датасетті оқу) сәйкес жылдамдықты таңдайсыз. Өсуге резерв қалдырыңыз, бірақ толық ауыстырусыз жаңартуға жол ойластырыңыз: порттар апгрейдке лайықты болсын, оптика мен кабельдерге запас, spine-leaf кеңею жолы анық болсын.

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

Сатып алудан бұрын стресс-тестерлер: желіні практикалық тексеру

Желіні «көзбен» алу қауіпті: 25GbE жететін жерге 100GbE сатып алып, керісінше де болуы мүмкін. Нагрузочные тесттер әңгімені сандарға айналдырады: нақты қанша трафик өтетіні, латенттік қалай мінез көрсететіні және бір мезгілдегі ағындарда не болатынын көрсетеді.

Нені өлшеу керек

Маңыздысы тек шектік мәндер емес, болашаққа ұқсас жүктеме астындағы мінезі:

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

Тест стендін қалай жинау

Көбіне 2–8 түйін жеткілікті, тіпті кластер одан үлкен болса да. Маңыздысы — типтік трафикті қайталау: түйіндер арасында «барлығы бәрімен» және сақтау жүйесіне бөлек ағын.

Практикалық тесттер: iperf3 throughput үшін (бірнеше параллель ағындар), ping негізгі латенттілік үшін, ал RDMA болса — қарапайым RDMA тесттері, CPU-ға және латенттік хвосттарға әсерін көру үшін.

Пайдалы тест — «қолма-қол»: түйіндер арасында алмасуды бір уақытта іске қосып (мысалы, 4–8 жұп ағын), параллель түрде сақтау жүйесіне ағын жасаңыз. Көп жағдайда бөлек болғанда бәрі "жасыл", ал бірге болғанда жоғалтулар мен латенттік секірулері пайда болады.

Нәтижелерді "күту vs факт" деген қарапайым кестеде тіркеңіз: мақсатталған Gb/s, рұқсат етілген латенттік, рұқсат етілген жоғалтулар (әдетте 0), нақты мәндер және тест шарттары (ағын саны, уақыт, пакет өлшемі). Осылай 25GbE мен 100GbE-ні сатып алмас бұрын салыстыру оңай болады.

Тест нәтижелерін қалай интерпретациялау және қателеспеу

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

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

Нақты жағдайды өзгерте алатын баптаулар

MTU, порт кезектері және NIC драйверлері сияқты бірнеше параметрлер шын мәнінде нәтижені өзгертеді:

• MTU: MTU ұлғайса тұрақты жылдамдық өсіп, CPU жүктемесі азайса — жақсы белгі. Егер жоғалулар немесе «ұсақталу» пайда болса, артқа қайтарып, қадамдап тексеріңіз.
• Кезектер мен RSS: бір ағын бір CPU ядросына бекітілсе, тест «жаман желі» көрсетеді, ал мәселе хостта болуы мүмкін.
• Драйверлер мен прошивка: жаңарту кейін латенттілік тұрақтылығы өзгеруі мүмкін, орташа жылдамдық сол болғанымен.

Қандай сигналдар алаңдатарлық

Әдетте ұйғарым емес, қайталанатын белгілер алаңдатады:

• сол шарттарда 20–30% және одан да көп жылдамдық төмендеуі;
• латенттіліктің тұрақсыздығы (қадамдарда бірнеше есе секіру), әсіресе фондық трафикпен;
• пакеттер жоғалту, TCP ретрансмиттері немесе UDP-де «тесіктер";
• бағыттар арасында қатты айырмашылық (бір бағытта жақсы, кері бағытта жаман).

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

Амалда нәтижелерді екі режимде тіркеу ыңғайлы: «желі как есть» және «реал өмірдегі» (параллельді тапсырмалармен). Осылай 25/100GbE жеткілікті ме, әлде мәселе өткізу қабілетінде емес, тұрақтылықта мен баптауларда ма — анық көрінеді.

GPU-кластер үшін желіні таңдау кезінде жиі кездесетін қателіктер

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

Типтік жағдайлар:

• Барлығына 100GbE алу, ал шын шектеу түйіндердің сақтауынан, CPU-дан немесе стек баптауынан болуы. Мысал: 8 GPU бар түйіндер деректерді 10GbE арқылы алады, сондықтан түйіндер арасындағы желіні жылдамдату_epochs нәтижені айтарлықтай өзгертпейді.
• Өте жоғары oversubscription жасап, кездейсоқ тар жерлер пайда болады. Қағазда суммарлы полоса жақсы көрінеді, бірақ шыңда бірнеше түйін бір «бутылкаға» түседі.
• Тек орташа латенттікке қарап, джиттер мен жоғалтуларды елемеу. Тіпті сирек микропотерялар синхрондауда ұзақ хвосттар береді және GPU-да кенет паузалар пайда болады.
• Өсуге дайындықсыз болу. 4–8 түйін қосқанда east-west трафигі өзгеріп, желі күтпеген мінез көрсетеді.
• Синтетиканы емес, нақты сценарийді тестілмеу. Iperf-тің бір ағыны немесе қысқа «түнгі» тест сіздің батч өлшемі мен GPU саны бар нақты жүктемені көрсетпейді.

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

Бұл сатып алудан бұрын тәртіп арқылы шешіледі: 1–2 типтік жаттығу тапсырмасын бекітіп, оларды тест стендінде өткізесіз және тек жылдамдыққа ғана емес, тұрақтылыққа қарайсыз. Егер кластер интегратор арқылы құрылады, қабылдау жоспарына осындай «тірі» тексерулерді қосқан дұрыс, тек коммутатор паспорты көрсеткіштерімен шектелмей.

Қысқа чек-лист және келесі қадамдар

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

Қысқа чек, артық нәрсені алып тастап, маңыздысын ұмытпауға көмектеседі:

• Жылдамдықтар: трафиктің қанша бөлігі east-west (түйндер арасында) және north-south (сақтауға) құрайды.
• 25GbE немесе 100GbE: шыңдағы бір уақытта қанша ағын болады. Бір ауыр job бір аплинкті тез бітіріп жіберуі мүмкін.
• Латенттік: қай тапсырмалар микролатенттікке сезімтал. Таратылған оқыту үшін орташа мәннен бөлек p95/p99 маңызды.
• Топология spine-leaf және oversubscription: аплинктердегі рұқсат етілген коэффициент қандай.
• Нагрузочное тестілеу: өткізу қабілеті, латенттік және жоғалтуларды параллельдік жүктеме астында тексеру (бір iperf емес, бірнеше ағын және фондық сақтау жүктемесі).

Талаптарды тендерге және қабылдауға жарамды ету үшін оларды өлшенетін критерийлер ретінде сипаттаңыз: N параллель ағын кезінде түйіндер арасындағы мақсатты өткізу, X көлемдегі хабарлама үшін рұқсат етілген p95/p99 латенттік, берілген жүктеме кезінде пакет жоғалтулар болмауы, сондай-ақ расталған схема (leaf/spine саны, порттар жылдамдығы, oversubscription коэффициенті).

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