AWS Sagemaker Hyperpod жүйесіндегі жоғары өнімді GPU жадымен тасымалдау

Қазіргі терең оқыту инфрақұрылымы жиі машиналар арасындағы GPU-лар арасында үлкен көлемдегі деректерді тасымалдауды қажет етеді. Perplexity компаниясында біз бірегей техникалық міндетке тап болдық: машиналар арасында бір-бірімен тұспа-тұс келмейтін GPU жады аймақтарын мүмкін болғанынша ең жоғары жылдамдықпен тиімді тасымалдау. Біздің мақсатты платформа — AWS p5 инстанстары — 32 желілік карта арқылы 3200 Gbps желі өткізу қабілетін ұсынады. Бұл мақалада біз теориялық өткізу қабілетінің 97,1%-ына қол жеткізетін тапсырыспен жасалған жоғары өнімді желілік шешімді құру жолындағы тәжірибемізбен бөлісеміз.

Техникалық міндет

Біздің қолдану сценарийіміз бірнеше негізгі техникалық талаптарды ұсынды:

• Үзілісті жад блоктарының қашықтағы GPU-лары арасындағы жоғары өткізу қабілетімен тасымалдау
• Жұмыс істеп тұрған операцияларды бұзмай Kubernetes орналастыруларынан түйіндерді динамикалық түрде қосу немесе жою мүмкіндігі
• Peer-to-peer (тең дәрежелі) коммуникация үлгілерін қолдау

NVIDIA NCCL кітапханасы бөлінген терең оқыту үшін нақты стандарт болып табылатынымен, ол біздің қолдану сценарийіміз үшін мінсіз болмады:

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

Заманауи жоғары өнімді желілер

Шешімімізді түсіну үшін, алдымен заманауи жоғары өнімді желілердің дәстүрлі желілерден қалай ерекшеленетінін зерттейік.

Күн сайын қолданатын желілердің көпшілігі TCP/IP хаттамаларына сүйенеді, мұнда қосымшалар операциялық жүйе ядросы арқылы сокеттерді қолдана отырып желілік картамен байланысады. Алайда, жоғары өнімді желілер RDMA (Remote Direct Memory Access) пайдаланады - бұл CPU-ды қатыстырмай машиналар арасында тікелей жадқа қол жеткізуге мүмкіндік беретін мүлдем басқа аппараттық және бағдарламалық стека.

AWS Elastic Fabric Adapter (EFA) ұсынады, бұл Amazon-ның Scalable Reliable Datagram (SRD) деп аталатын арнайы хаттамасын іске қосатын арнайы желілік интерфейс. Деректер пайдаланушы кеңістігі, ядро кеңістігі және желілік буферлер арасында бірнеше рет көшірілуі тиіс дәстүрлі TCP/IP желілерінен айырмашылығы, RDMA бар EFA CPU-ды толығымен айналып өтіп, GPU жады мен желілік карта арасында деректерді тікелей тасымалдауға мүмкіндік береді.

Жоғары өнімді желілік дизайн философиясы

Жоғары өнімді желілік жүйелерді құру бірнеше іргелі болжамдарды қайта қарастыруды талап етеді:

1. Буфер иелігі: Ядро желілік буферлерді басқаратын және пайдаланушы кеңістігі мен ядро кеңістігі арасында көшіруді талап ететін дәстүрлі сокеттерден айырмашылығы, RDMA қолданбалардан өз буферлерін басқаруды талап етеді. Қолданба желілік операцияны бастаған кезде, ол операция аяқталғанға дейін буфер иелігін желілік картаға береді, бұл деректерді көшіру қажеттілігін жояды.
2. Жадты тіркеу: Қолданбалар операциялық жүйе ядросында жад аймақтарын тіркеуі тиіс. Ядро CPU, GPU және желілік карталарға бірдей виртуалды адрестерді түсінуге мүмкіндік беретін виртуалды адрес карталарын орнатады. Бұл тіркеу кейінгі нөлдік көшіру деректер тасымалдауларын қосатын бір реттік операция болып табылады.
3. Басқару жазықтығы және деректер жазықтығы: Жоғары өнімді желілер операцияларды екі санатқа бөледі:
   1. Қауіпсіздікті қамтамасыз ету үшін басқару жазықтығының операциялары (қосылымды орнату және жадты тіркеу сияқты) ядро арқылы өтеді
   2. Деректер жазықтығының операциялары (нақты деректерді тасымалдау) максималды өнімділік үшін ядроны айналып өтеді
4. Тасымалдау алдында қабылдау: Ядро басқаратын буферлерсіз, қолданбалар кіріс деректер қайда орналасуы керектігін көрсете отырып, қабылдау операцияларын алдын ала жариялауы тиіс. Бұл қолданбалар кез келген уақытта деректерді қабылдай алатын сокет моделінен іргелі ауысу болып табылады.
5. Сұрауға негізделген аяқталу: epoll сияқты механизмдер арқылы ядро хабарландыруларын күтудің орнына, қолданбалар аппараттық аяқталу кезектерін тікелей сұрайды. Бұл жүйелік шақыру шығындарын жояды және аяқталған операцияларға дереу реакция жасауға мүмкіндік береді.
6. Аппараттық топология туралы хабардарлық: Максималды өнімділікке қол жеткізу үшін аппараттық топологияны түсіну және оңтайландыру өте маңызды.

Аппараттық топологияны түсіну

AWS p5 даналары күрделі ішкі архитектураға ие. Төменде көрсетілгендей, әрбір дана екі NUMA түйінін құрайтын екі CPU сокетін қамтиды, ал әрбір NUMA түйіні төрт PCIe коммутаторына қосылады:

Ұлғайту

Әрбір PCIe коммутаторының астында біз мыналарды табамыз:

• Төрт 100 Гбит/с EFA желілік картасы
• Бір NVIDIA H100 GPU
• Бір NVMe SSD

TCP/IP және RDMA тасымалдаулары үшін деректер жолдары олардың тәсілдеріндегі іргелі айырмашылықтарды көрсетеді:

Ұлғайту

TCP/IP көмегімен (сол жақ тарап) деректер бірнеше рет көшірілуі тиіс:

1. GPU жадынан пайдаланушы кеңістігіндегі қолданба буферіне
2. Пайдаланушы кеңістігі буферінен ядро буферіне
3. Ядро буферінен желілік картаға
4. Кері процесс қабылдау жағында орын алады

Әрбір көшіру операциясы CPU циклдері мен жад өткізу қабілетін тұтынады. Қолданба сондай-ақ әрбір желілік операция үшін пайдаланушы кеңістігі мен ядро кеңістігі арасында контекстті ауыстыруы керек.

Керісінше, RDMA (оң жақ тарап) нақты нөлдік көшіру деректер тасымалдауын қамтамасыз етеді:

1. Желілік карта GPU жадынан тікелей оқиды
2. Деректер тікелей қашықтағы желілік картаға сапар шегеді
3. Қашықтағы желілік карта тікелей мақсатты GPU жадына жазады
4. Қолданба тасымалдаудың қашан аяқталғанын білу үшін тек пайдаланушы кеңістігіндегі аяқталу кезегін (CQ) тексеруі керек

RDMA және дұрыс аппараттық жұптастыру арқылы екі GPU арасында деректерді тасымалдау тек жергілікті PCIe коммутаторы мен желіні кесіп өтуді талап етеді:

Ұлғайту

Керісінше, TCP/IP тасымалдаулары деректерді негізгі жад арқылы бірнеше рет көшіруі керек, бұл PCIe шинасының айтарлықтай тығындалуын тудырады:

Ұлғайту

libfabric көмегімен құру

Біз libfabric пайдаландық - бұл фабрикалық қызметтер үшін жалпы интерфейсті қамтамасыз ететін фреймворк. Біздің іске асыруымыз RDMA операцияларының екі түрін пайдаланады:

• Жад аймақтары туралы метадеректерді (мысалы, ығысулар мен өлшемдерді) тасымалдайтын басқару хабарлары үшін екі жақты RDMA (SEND/RECV).
• Әрбір WRITE операциясы бір үзіліссіз жад блогын өңдейтін, нақты деректерді тасымалдау үшін бір жақты RDMA WRITE.

Шың өнімділікке жету жолы

Біздің әзірлемеміз бірнеше сатыдан өтті:

1. SEND/RECV көмегімен негізгі бір бағытты хабарлама тасымалдауы іске асырылды
2. Екі бағытты коммуникацияға дейін кеңейтілді
3. Тікелей GPU-дан GPU-ға тасымалдау үшін GPUDirect RDMA WRITE қосылды
4. Бір мезгілдегі бірнеше тасымалдауларды өңдеу үшін кеңейтілді
5. Тұрақтылық үшін операцияларды кезекке қою енгізілді
6. Бір желілік картада 97.4% өткізу қабілетінің қолданылуына қол жеткізілді

32 желілік картаға масштабтаған кезде, біз бірнеше маңызды оңтайландыруларды іске асырдық:

1. Операцияларды кезекке қою: Операцияларды желілік карталарға тікелей жіберудің орнына, біз қолданба деңгейіндегі кезектерді сақтаймыз. Бұл желілік тығындалуға қарсы тұрақтылықты қамтамасыз етеді және бағдарламалау моделін жеңілдетеді.
2. Желіні қыздыру: Қосылымдарды алдын ала орнату іске қосу өнімділігін жақсартты.
3. Көп ағындылық: Әрбір GPU желілік операциялары үшін арнайы тректер.
4. CPU ядросын бекіту: NUMA әсерлерін және кэш жіберіп алуларын болдырмау үшін тректерді арнайы CPU ядроларына байлау.
5. Күйді шардтау: Тректер арасындағы бәсекелестікті азайту.
6. Операцияларды топтау: Бірнеше операцияларды бірге жіберу.
7. Жалқау операцияларды жариялау: Операциялар алдымен қолданбада кезекке қойылады. Аяқталу кезегін сұраудан кейін, біз желілік ресурс тиімді пайдаланылуын қамтамасыз ете отырып, күтіп тұрған операцияларды желілік картаға жіберуге тырысамыз.
8. NUMA-дан хабардар ресурс бөлу: Жадқа қол жеткізу кідірісін азайту үшін дұрыс NUMA түйінінде аяқталу кезектері сияқты libfabric ресурстарын бөлу.

Осы оңтайландырулар арқылы біз 3108 Гбит/с соңғы өнімділікке қол жеткіздік - бұл теориялық максималды өткізу қабілетінің 97.1% құрайды.

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

Қорытынды

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

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

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

Дәйексөз

@online{perplexity2025HighPerformanceGpuMemoryTransferOnAwsSagemakerHyperpod,
  author = {{Perplexity} and Lequn Chen and Phi Hoang},
  title = {{High-performance GPU memory transfer on AWS Sagemaker Hyperpod}},
  date = {2025-02-10},
  url = {https://www.perplexity.ai/hub/blog/high-performance-gpu-memory-transfer-on-aws-sagemaker-hyperpod}
}