AMD သည် ယနေ့အထိ ၎င်း၏ အကြီးမားဆုံး Advancing AI ပွဲကို ကျင်းပခဲ့ပြီး scale ကို အဓိက အကြောင်းအရာအဖြစ် အလေးပေးခဲ့သည်။ ကုမ္ပဏီသည် Instinct MI455X GPU၊ 72-GPU Helios rack နှင့် 6th Generation EPYC Venice CPU များကို မိတ်ဆက်ခဲ့သည်။ MI455X တွင် NVIDIA ၏ B300 သို့မဟုတ် Rubin ထက် 50% ပိုများသော HBM4 432GB ပါရှိပြီး memory bandwidth 23.3TB/s နှင့် MXFP4 compute 40.26 PFLOPS အထိ ပါရှိသည်။ Helios rack အပြည့်အစုံသည် ဤကိန်းဂဏန်းများကို 72 ဖြင့် မြှင့်တင်ပေးပြီး FP4 2.9 exaFLOPS၊ HBM4 31TB၊ memory bandwidth 1.7PB/s၊ scale-up 260TB/s နှင့် datacenter သို့ scale-out bandwidth 43TB/s ရရှိစေသည်။ မက်ထရစ်အားလုံးတွင် AMD သည် လုပ်ငန်းကို ဦးဆောင်ရန် ရည်ရွယ်ထားသည်။ ဤဆောင်းပါးသည် MI455X နှင့် Helios တို့ကို ဆန်းစစ်သည်။ Venice မိတ်ဆက်ပွဲကို သီးခြားခွဲခြမ်းစိတ်ဖြာမှုတွင် ဖော်ပြထားပါသည်။

နောက်ထပ် အဓိကအချက်ကတော့ openness ဖြစ်ပြီး interconnect ကနေစပြီး layer တိုင်းကို ရောက်ရှိပါတယ်။ rack အတွင်းမှာ GPU ၇၂ ခုစလုံးဟာ UALink ပေါ်မှာ memory ကို မျှဝေအသုံးပြုပါတယ်။ ဒီ UALink ဟာ AMD က Ethernet ပေါ်မှာ UALink-over-Ethernet (UALoE) အနေနဲ့ လည်ပတ်တဲ့ open consortium fabric တစ်ခုဖြစ်ပါတယ်။ traffic ဟာ rack ကနေ ထွက်သွားတာနဲ့ Ultra Ethernet Consortium ရဲ့ open scale-out standard ဖြစ်တဲ့ Ultra Ethernet ပေါ်မှာ ရွေ့လျားသွားပါတယ်။ အဲဒီ Instinct ကလည်း stack ထဲမှာ လည်ပတ်ပါတယ်။ low-precision math ဟာ OCP ရဲ့ open MXFP4, MXFP6, နဲ့ MXFP8 data format တွေကို အသုံးပြုထားပြီး အားလုံးကို သိမ်းဆည်းထားတဲ့ rack ကို Open Compute Project ရဲ့ Open Rack Wide ဒီဇိုင်းနဲ့ တည်ဆောက်ထားပါတယ်။ software ကိုတောင် open မှာ တီထွင်ထားပြီး ROCm ရဲ့ compiler, runtime နဲ့ libraries အားလုံးကို source မှာ ရရှိနိုင်ပါတယ်။

stack ထဲက သတ်မှတ်ချက်တိုင်းကို ဒီနေ့ခေတ်မှာ ထုတ်ဝေပြီး ဒေါင်းလုဒ်လုပ်နိုင်တာကြောင့် hyperscaler တစ်ခုဟာ Helios ကို blueprint တစ်ခုလိုသဘောထားပြီး သူ့ရဲ့ကိုယ်ပိုင် facilities တွေနဲ့ workloads တွေနဲ့ ချိန်ညှိထားတဲ့ bespoke version တစ်ခုကို တည်ဆောက်နိုင်သလို networking၊ power delivery ဒါမှမဟုတ် management တွေကိုလည်း ချိန်ညှိနိုင်ပါတယ်။ ဆိုလိုတာက ဒီဆောင်းပါးမှာ ကျွန်တော်တို့ ဖြတ်သန်းသွားတဲ့အရာအားလုံးဟာ AMD တင်ပြထားတဲ့ reference design ပါပဲ။ customer တွေ ဖြန့်ကျက်တဲ့ unit တွေက သိသိသာသာ ကွဲပြားနိုင်ပါတယ်။ user တွေကတော့ စီထားပြီးသားပါ- AMD က OpenAI၊ Meta၊ Anthropic၊ Microsoft ၊ Oracle နဲ့ တခြားကုမ္ပဏီတွေက Helios ကို လက်ခံအသုံးပြုနေကြတယ်လို့ ပြောပါတယ်။

AMD Instinct MI455X: CDNA 5 ၏ ထိပ်တန်း ပရိုဆက်ဆာ

MI455X သည် ထရန်စစ္စတာပေါင်း ၃၂၀ ဘီလီယံပါဝင်သည့် ပထမဆုံး CDNA 5 accelerator ဖြစ်သည်။ MI455X တွင် TSMC ၏ N2 node ပေါ်တွင်တည်ဆောက်ထားသော Accelerator Complex Dies (XCDs) ရှစ်ခု၊ N3 node ပေါ်တွင် I/O Dies နှစ်ခုနှင့် Fabric နှင့် Cache Dies နှစ်ခုအပြင် HBM4 stack ဆယ့်နှစ်ခုပါဝင်သည်။ ၎င်းသည် TSMC ၏ CoWoS-L packaging ပေါ်တွင်တည်ဆောက်ခဲ့သော အကြီးဆုံးချစ်ပ်ဖြစ်သည်။

မန်မိုရီက သတင်းခေါင်းစဉ်တွေထဲက တစ်ခုပါ။ အဲဒီ HBM4 stack ဆယ့်နှစ်ခုမှာ စုစုပေါင်း 432GB ကို 23.3TB/s နဲ့ ရရှိနိုင်ပြီး HBM4 က per-stack interface ကို 2,048 bits အထိ နှစ်ဆတိုးစေပြီး Fabric နဲ့ Cache die နှစ်ခုက 54TB/s နဲ့ လည်ပတ်နေတဲ့ 192MB L2 ကို ထပ်ပေါင်းပေးပါတယ်။

MI455X သည် I/O ကိုလည်း နှောင့်နှေးခြင်းမရှိပါ။ ၎င်းသည် rack ၏ ကျန်အပိုင်းသို့ bidirectional scale-up bandwidth 3.6TB/s အတွက် UALoE 72 lanes၊ ၎င်း၏ host CPU သို့ bidirectional Infinity Fabric 256GB/s နှင့် scale-out အတွက် PCIe Gen6 x16 links နှစ်ခု သို့မဟုတ် AMD AI-NICs သုံးခုကို ရွေးချယ်နိုင်သည်။

၎င်းအစားထိုးထားသော ချစ်ပ်နှင့် NVIDIA ၏ ကမ်းလှမ်းချက်များနှင့် ယှဉ်လျှင် MI455X သည် ဇယားပေါ်ရှိ မက်ထရစ်တိုင်းတွင် ဦးဆောင်နေသည်။

specification	AMD MI455X	NVIDIA ရူဘင်	AMD MI355X	NVIDIA B300
ဗိသုကာအတတ်ပညာ	CDNA ၄	Rubin က	CDNA ၄	Blackwell Ultra
transistors	320B	336B	185B	208B
HBM စွမ်းရည်	432GB HBM4	288GB HBM4	၂၈၈GB HBM3E	၂၈၈GB HBM3E
HBM bandwidth	၃.၆ TB/s	၃.၆ TB/s	၃.၆ TB/s	၃.၆ TB/s
GPU တစ်ခုချင်းစီအလိုက် တိုးချဲ့ခြင်း	၃.၆ TB/s	၃.၆ TB/s	၃.၆ TB/s	၃.၆ TB/s
GPU တစ်ခုချင်းစီ၏ အရွယ်အစား	2,400 Gb / s ကို	1,600 Gb / s ကို	400 Gb / s ကို	800 Gb / s ကို
CPU-GPU ချိတ်ဆက်မှု	တစ်စက္ကန့်လျှင် ၂၅၆GB Infinity Fabric	၁.၈TB/s C2C (၁:၂)	PCIe 5	၉၀၀GB/s C2C (၁:၂)

 

AMD ဦးဆောင်နေတဲ့နေရာကနေ စလိုက်ရအောင်။ 432GB မှာ MI455X ဟာ MI355X၊ B300 ဒါမှမဟုတ် Rubin ထက် HBM ၅၀% ပိုပါဝင်ပြီး အားလုံးက 288GB အထိ ရှိပါတယ်။ ၎င်းရဲ့ memory bandwidth 23.3TB/s ဟာလည်း အုပ်စုထဲမှာ အမြင့်ဆုံးပါ။ scale-out row ကလည်း အတူတူပါပဲ။ GPU တစ်ခုကို 2,400 Gbit/s ရှိပြီး Rubin ကတော့ 1,600 နဲ့ B300 ကတော့ 800 ဖြစ်ပါတယ်။ MI455X တိုင်းဟာ ၎င်းရဲ့ အနီးစပ်ဆုံးပြိုင်ဘက်ထက် network bandwidth ၅၀% ပိုပါတယ်။

AMD ဟာ scale-up မှာလည်း နောက်ဆုံးတော့ အမီလိုက်နိုင်ခဲ့ပါပြီ။ NVLink ဟာ နှစ်ပေါင်းများစွာ ဦးဆောင် GPU fabric တစ်ခုဖြစ်ခဲ့ပြီး မျိုးဆက်နှစ်ခုလုံး WideEP နဲ့ MoE မော်ဒယ်တွေမှာ အကောင်းဆုံးစွမ်းဆောင်ရည်ကို ရရှိဖို့ တစ်ခုတည်းသောနည်းလမ်းဖြစ်ခဲ့ပါတယ်။ UALoE ဟာ မျိုးဆက်တစ်ခုတည်းမှာတင် အဲဒီကွာဟချက်ကို ကျဉ်းမြောင်းစေခဲ့ပါတယ်- 3.6TB/s မှာ MI455X ဟာ Rubin ရဲ့ NVLink 6 နဲ့ တူညီပါတယ်။ NVIDIA ဟာ host link မှာ ပြတ်ပြတ်သားသား ဦးဆောင်နေဆဲပါ။ Vera CPU တစ်ခုက Rubin GPU နှစ်ခုကို 1.8TB/s C2C ပေါ်မှာ ထောက်ပံ့ပေးပြီး MI455X တစ်ခုစီက 256GB/s Infinity Fabric link မှတစ်ဆင့် Venice host နဲ့ ဆက်သွယ်ပါတယ်။ အဲဒီကွာခြားချက်က rack architecture နှစ်ခု ဘယ်လိုကွဲပြားသွားလဲဆိုတာကို ဒီဆောင်းပါးရဲ့ နောက်ပိုင်းမှာ ပုံဖော်ပေးပါတယ်။

raw compute မှာ MI455X က board တစ်ခုလုံးမှာ ဦးဆောင်နေပြီး အောက်ခြေမှတ်ချက်တစ်ခုရှိပါတယ်- AMD ရဲ့ OCP MX formats နဲ့ NVIDIA ရဲ့ NVFP4 တို့က ကွဲပြားစွာ ချိန်ညှိထားတာကြောင့် ဒါတွေကို ကြော်ငြာထားတဲ့ အမြင့်ဆုံးအဆင့်တွေအဖြစ် သဘောထားပါ။ ပေးပို့တဲ့ စွမ်းဆောင်ရည်ကတော့ သီးခြားမေးခွန်းတစ်ခုပါ။

ပုံစံ	AMD MI455X	NVIDIA ရူဘင်	AMD MI355X	NVIDIA B300
MXFP4 / NVFP4	40.26 PF	35 PF	10.1 PF	15 PF
MXFP6 / FP6	20.13 PF	17.5 PF	10.1 PF	5 PF
MXFP8 / FP8	20.13 PF	17.5 PF	5 PF	5 PF
FP၁၆ / BF၁၆	5.03 PF	4 PF	2.5 PF	2.5 PF
FP32	၇၅ တီအက်ဖ်	၇၅ တီအက်ဖ်	၇၅ တီအက်ဖ်	၇၅ တီအက်ဖ်

 

MI355X နှင့် နှိုင်းယှဉ်ပါက MI455X သည် MXFP4 နှင့် MXFP8 throughput ထက် လေးဆနှင့် FP16/BF16 နှင့် FP32 rates ထက် နှစ်ဆ ပိုမိုပေးစွမ်းနိုင်သည်။ NVIDIA နှင့် နှိုင်းယှဉ်ချက်တွင် အပိုင်းနှစ်ပိုင်း ခွဲခြားနိုင်သည်။ B300 နှင့် နှိုင်းယှဉ်ပါက MI455X သည် FP4 throughput ထက် ၂.၇ ဆ ပိုမိုပေးစွမ်းပြီး FP6 နှင့် FP8 rates ထက် လေးဆ ပိုမိုပေးစွမ်းသည်။ Rubin သည် အဓိပ္ပာယ်ရှိသော benchmark ဖြစ်ပြီး MI455X သည် စဉ်ဆက်မပြတ် အားသာချက်ရှိသည်- FP4 တွင် ၁၅%၊ FP6 နှင့် FP8 တွင် ၁၅% နှင့် FP16/BF16 တွင် ၂၆%။ အကျယ်ဆုံးကွာဟချက်မှာ FP32 တွင် ပေါ်လာပြီး MI455X ၏ 315 TF သည် Rubin ၏ 130 TF ထက် ၂.၄ ဆခန့် ပိုမိုများပြားပြီး B300 ၏ 75 TF ထက် လေးဆကျော် ပိုမိုများပြားသည်။ ထိုကိန်းဂဏန်းသည် Instinct ၏ HPC မျိုးရိုးမှ ဆင်းသက်လာပြီး master weights၊ မြင့်မားသောတိကျမှုစုဆောင်းမှုနှင့် သိပ္ပံဆိုင်ရာ workloads များသည် low-bit formats များထက် ဆက်လက်လည်ပတ်နေသောကြောင့် AI အလုပ်အတွက် အရေးပါနေဆဲဖြစ်သည်။

CDNA 5 အတွင်းပိုင်း

ဗိသုကာပုံစံထဲကို နှစ်ချက်နှိပ်ပြီး ဒီထိပ်တန်းစွမ်းဆောင်ရည်ကို ဘာကတကယ်စွမ်းအားပေးလဲဆိုတာ ကြည့်ရအောင်။

XCD မှ SIMD သို့

CDNA 4 က compute die ကို အလွန်ကွဲပြားစွာ စီစဉ်ပေးထားတဲ့အတွက် package ကနေ hierarchy ကို ငုံ့ကြည့်လိုက်ရင် ဘယ်လောက်ပြန်လည်တည်ဆောက်ထားလဲဆိုတာ ပြသနေပါတယ်။ MI355X မှာ XCD တစ်ခုစီမှာ active Compute Units ၃၂ ခုနဲ့ private 4MB L2 cache တစ်ခုပါဝင်ပြီး Infinity Fabric ကို မရောက်ခင် die ရဲ့ traffic ကို စုစည်းပေးပါတယ်။ CDNA 5 မှာ XCD ရှစ်ခုကို ဆက်ထားပေမယ့် AMD ရဲ့ RDNA graphics line ကနေ structure နဲ့ terminology တွေကို ယူသုံးထားတဲ့အတိုင်း အထဲမှာရှိတာတွေကို ပြန်လည်တည်ဆောက်ထားပါတယ်။ MI455X XCD တစ်ခုစီမှာ Shader Engines နှစ်ခုအဖြစ် ပိုင်းခြားထားပါတယ်။ Shader Engine တစ်ခုစီမှာ Work Group Processors ၁၇ ခု ပါဝင်ပြီး ၁၆ ခုကို enable လုပ်ထားပြီး အပိုတစ်ခုကတော့ yield အတွက်ပါ။ per-XCD L2 ကို လုံးဝဖယ်ရှားပြီး compute die ကနေ မြှောက်ပြီး အောက်က base die တွေထဲကို ပြန်ဆင်းသွားပါတယ်။ memory section က အဲဒီကို ပြန်သွားပါတယ်။

အရေးကြီးတာက မပြောင်းလဲတဲ့အရာက ဂဏန်းသင်္ချာပါ။ XCD တစ်ခုက active unit ၃၂ ခုကို ပံ့ပိုးပေးနေဆဲဖြစ်ပြီး GPU ကတော့ စုစုပေါင်း ၂၅၆ ခု ရှိနေဆဲဖြစ်ပြီး MI355X က Compute Unit အဖြစ် သယ်ဆောင်ထားတဲ့ အရေအတွက်နဲ့ အတူတူပါပဲ။ တိကျမှုနည်းတဲ့ throughput မှာ generational 4× ထဲက ဘယ်ဟာမှ execution unit တွေ ပေါင်းထည့်ခြင်းကနေ မလာပါဘူး။ အားလုံးက WGP တစ်ခုစီက cycle တစ်ခုစီမှာ အလုပ်ပိုလုပ်ခြင်းကနေ လာတာပါ။ WGP ကတော့ ဒီဇိုင်းပြန်လည်ရေးဆွဲတဲ့နေရာမှာ အဓိကထားပါတယ်။

WGP တစ်ခုကို 32-lane SIMD unit လေးခုနှင့် constant cache တစ်ခုကို မျှဝေထားသော scalar unit လေးခုဖြင့် တည်ဆောက်ထားသည်။ အကြီးမားဆုံးပြောင်းလဲမှုမှာ thread များ မည်သို့စီးဆင်းသည်ဆိုသည့်အချက်ဖြစ်သည်- Wave64 မှ Wave32 သို့ ရွေ့လျားခြင်းဖြစ်သည်။ wave ဆိုသည်မှာ SIMD တစ်ခု lockstep တွင် လည်ပတ်သော thread အစုအဝေးဖြစ်သည်။ CDNA 4 သည် Wave64 ကိုအသုံးပြုခဲ့ပြီး 64-thread wave တစ်ခုစီကို 16-lane SIMD တစ်ခုမှတစ်ဆင့် clock cycle လေးခုအတွင်း တွန်းပို့ခဲ့သည်။ CDNA 5 သည် Wave64 support ကို လုံးဝဖယ်ရှားခဲ့ပြီး ထိုသို့ပြုလုပ်သည့် ပထမဆုံး Instinct architecture ဖြစ်ပြီး Wave32 ကို natively လည်ပတ်သည်။ 32-thread wave သည် WGP ၏ 32-lane SIMD unit လေးခုစီတွင် one-to-one map လုပ်ပြီး cycle တစ်ခုတည်းတွင် ထုတ်ပေးပြီး SIMD တစ်ခုစီကို clock တိုင်းတွင် instruction အသစ်တစ်ခုစတင်ခွင့်ပြုသည်။

ပိုကျဉ်းပြီး ပိုမြန်တဲ့ လှိုင်းတွေက စက်ကနေတစ်ဆင့် အလုပ်တွေ ဘယ်လိုရွေ့လျားလဲဆိုတာကို ပြောင်းလဲစေပါတယ်။ လှိုင်းတစ်ခု ပိုမြန်မြန်ပြီးသွားလို့ ညွှန်ကြားချက် latency ကျဆင်းသွားပါတယ်။ taken-or-not split က အခုဆိုရင် thread ၆၄ ခုအစား အများဆုံး ၃၂ ခုမှာ ရပ်တန့်သွားတာကြောင့် Branch divergence ကုန်ကျစရိတ် ပိုသက်သာပါတယ်။ Register pressure လျော့ကျသွားတာကြောင့် wave ပိုများများ ရှိနေပြီး WGP တစ်ခုမှာ ၆၄ ခုအထိ ရှိနေပြီး အရင်ကထက် ထက်ဝက်လောက် ပိုများပါတယ်။ ဒါက scheduler ကို memory latency ကို ဖုံးကွယ်ဖို့ သေးငယ်ပြီး လွတ်လပ်တဲ့ အလုပ်အပိုင်းအစတွေ ပိုရစေပါတယ်။ Wave32 က tensor လုပ်ဆောင်ချက်တွေအတွက် hardware ပေါ်မှာ မတူညီတဲ့ tile အရွယ်အစားတွေကို map လုပ်ရတာ ပိုလွယ်ကူစေပြီး kernel ဖွံ့ဖြိုးတိုးတက်မှုကို ရိုးရှင်းစေပါတယ်။

Single-cycle issue is only the start of the throughput story. The SIMDs co-execute, starting new instructions while earlier multi-cycle operations drain underneath, and packed vector instructions carry 64 threads' worth of work in a single issue, details AMD's architects confirmed in the post-briefing Q&A. The vector pipeline also gains native BF16 support and a set of new data-conversion instructions for moving tensors between formats. The transcendental units double their throughput over the MI355X and add a native tanh instruction, so the softmax and activation math inside attention keeps pace with the tensor hardware around it. That path is becoming a habit: CDNA 4 doubled the transcendental rates to accelerate attention, and CDNA 5 doubles them again.

မှတ်ဉာဏ်အဆင့်ဆင့်

အကောင်အထည်ဖော်မှုယူနစ်များ၏နောက်ကွယ်တွင် အပေါ်မှအောက်သို့ ပြန်လည်တည်ဆောက်ထားသော အဆင့်ဆင့်စနစ်တစ်ခုရှိပြီး ၎င်းကိုမြင်ရန် အရှင်းလင်းဆုံးနည်းလမ်းမှာ MI355X နှင့် အဆင့်လိုက်ယှဉ်ကြည့်ခြင်းဖြစ်သည်။

level	MI455X (CDNA 5)	MI355X (CDNA 4)
ဗက်တာ မှတ်ပုံတင်များ	SIMD တစ်ခုလျှင် 128KB; thread တစ်ခုလျှင် 1,024; 2× bandwidth	SIMD တစ်ခုလျှင် 128KB; thread တစ်ခုလျှင် 256KB
WGP / CU ဒေသခံစတိုးဆိုင်	384KB (320KB LDS + 64KB vector cache); 2× bandwidth	၁၉၂KB (၁၆၀KB LDS + ၃၂KB L1)
ညွှန်ကြားချက် / စဉ်ဆက်မပြတ် ကက်ရှ်	WGP တစ်ခုလျှင် 64KB + 16KB	CU နှစ်ခု + 16KB လျှင် 64KB မျှဝေထားသည်
L2	FCD များတွင် 2 × 96MB; 54TB/s	8 × 4MB၊ XCD တစ်ခုလျှင် တစ်ခု
မှတ်ဉာဏ်ဘက်ခြမ်း ကက်ရှ်	ဖယ်ထုတ်ခံရတယ်။	256MB Infinity Cache
hbm	432GB HBM4; 12 × 2,048-bit stacks; 23.3TB/s	၂၈၈GB HBM3E; ၈ × ၁၀၂၄-bit stack များ; ၈TB/s

 

cache row တွေက ဗိသုကာပုံစံပြောင်းလဲတဲ့နေရာတွေပါ။ CDNA 4 က အဆင့်သုံးဆင့်ဒီဇိုင်းကို လုပ်ဆောင်ခဲ့ပါတယ်- XCD တစ်ခုစီရဲ့ private 4MB L2 ဟာ Infinity Fabric မရောက်ခင်မှာ အဲဒီ die ရဲ့ traffic ကို ပေါင်းစပ်ခဲ့ပြီး I/O die တွေမှာ မျှဝေထားတဲ့ 256MB Infinity Cache ဟာ HBM controller တွေရဲ့ရှေ့ memory ဘက်မှာ ရှိနေပါတယ်။ CDNA 5 က layer နှစ်ခုလုံးကို ဖျက်ပြီး Fabric နဲ့ Cache Die တစ်ခုစီအတွက် one-megabyte block ၉၆ ခုအဖြစ် တည်ဆောက်ထားတဲ့ သီးခြား 96MB L2 cache နှစ်ခုနဲ့ အစားထိုးပါတယ်။ layout က vertical ဖြစ်ပါတယ်- XCD လေးခု ဒါမှမဟုတ် Shader Engine ရှစ်ခုကို FCD တစ်ခုစီရဲ့အပေါ်မှာ hybrid-bonded လုပ်ထားပြီး HBM4 site ဆယ့်နှစ်ခုထဲက ခြောက်ခုကိုလည်း သိမ်းဆည်းထားပြီး FCD နှစ်ခုဟာ package ရဲ့အလယ်ဗဟိုမှာရှိတဲ့ Infinity Fabric မှာ I/O die တွေက အဆုံးတစ်ဖက်တစ်ချက်စီကို capping လုပ်ထားပါတယ်။ L2 နှစ်ခုစလုံးက GPU ရဲ့ memory မှာ မည်သည့် address ကိုမဆို သိမ်းဆည်းထားနိုင်ပြီး Infinity Fabric က အတွဲကို ညီညွတ်စေပါတယ်။ AMD ရဲ့ ဖော်ပြထားတဲ့ အကြောင်းပြချက်က bandwidth ပါ- ဒီ cache တွေထဲက တစ်ခုဟာ MI355X ရဲ့ Infinity Cache တစ်ခုလုံးရဲ့ စုစုပေါင်း bandwidth ရဲ့ ၁.၅ ဆကို ပို့ဆောင်ပေးပြီး နှစ်ခုစလုံးက သုံးဆ ပို့ဆောင်ပေးတာကြောင့် အဲဒီ traffic တွေထဲက ဘယ်ဟာမှ layout အဟောင်းကို ကန့်သတ်ထားတဲ့ die-to-die bisection ကို ဖြတ်ကျော်စရာမလိုပါဘူး။

cache သည် တာဝန်အသစ်များကိုလည်း ယူဆောင်လာသည်။ ယခင်က fabric တွင် လုပ်ဆောင်ခဲ့သော device-scope atoms များသည် ယခုအခါ L2 အတွင်းပိုင်းတွင် ပိုမိုမြင့်မားသောနှုန်းထားများဖြင့် လည်ပတ်နေပြီး system-scope atoms များမှာမူ ယခင်ကကဲ့သို့ Infinity Fabric တွင် ရှိနေပါသည်။ broadcast arbiter အသစ်တစ်ခုက ၎င်းကို ပြီးမြောက်စေပြီး tensor tiles များကို တူညီသော matrix တွင် ပူးပေါင်းဆောင်ရွက်သည့် WGP တိုင်းသို့ multicasting လုပ်သည်။ ထို့ကြောင့် တစ်ကြိမ်ရယူသော weight သည် ၎င်းတို့အားလုံးကို ဆောင်ရွက်ပေးသောကြောင့် ထိရောက်သော read bandwidth ကို 4x အထိ တိုးမြှင့်ပေးသည်။

အထက်ဖော်ပြပါ အဆင့်များသည် ကိုက်ညီစေရန် ချိန်ညှိထားသည်။ Per-WGP local storage သည် 384KB အထိ နှစ်ဆတိုးလာပြီး LDS 320KB နှင့် vector data cache 64KB အဖြစ် ပိုင်းခြားထားပြီး read bandwidth နှစ်ဆရှိသည်။ ၎င်းသည် FlashAttention အတွက် attention matrix အပြည့်အစုံကို ရေးသားမည့်အစား chip ပေါ်တွင် query များ၊ key များ၊ တန်ဖိုးများနှင့် partial reduction များကို သိမ်းဆည်းရန် နေရာဖြစ်သည်။ ၎င်းသည် routing state နှင့် accumulator များကို ထိန်းသိမ်းထားရန် fused MoE kernels များကိုလည်း ပံ့ပိုးပေးသည်။ vector register file သည် ၎င်း၏ 128KB-per-SIMD စွမ်းရည်ကို ထိန်းသိမ်းထားသော်လည်း Wave32 အတွက် ပြန်လည်စီစဉ်ထားသည်။ ၎င်းသည် wave များကို နှစ်ဆတိုးလာစေပြီး single thread သည် 256 register များအစား 1,024 registers များကို address လုပ်ခွင့်ပြုပြီး ပိုမိုကျယ်ပြန့်သော SIMD များနှင့် ၎င်းတို့၏ co-execution units များကို feed လုပ်ရန် register bandwidth ကို နှစ်ဆတိုးစေသည်။

scalar ဘက်ခြမ်းကို wave တစ်ခုလျှင် scalar registers 128 ခုနှင့် WGP တစ်ခုလျှင် 32KB ဖြင့် ကိုက်ညီအောင် ပြန်လည်တည်ဆောက်ထားသည်။ အခြေခံတွင် HBM4 သည် 1,024-bit stacks ရှစ်ခုမှ 2,048-bit stacks ဆယ့်နှစ်ခုသို့ ရွေ့လျားပြီး 192-channel interface တစ်လျှောက် lifting capacity 50% မှ 432GB အထိနှင့် bandwidth 2.9× မှ 23.3TB/s အထိ ရှိသည်။

၎င်းအားလုံးကို ထောက်ပံ့ပေးသည့် Tensor Data Mover အသစ်တစ်ခုဖြစ်ပြီး WGP တစ်ခုလျှင် တစ်ခုဖြစ်ပြီး tensor tiling ပုံစံများကို dimension ငါးခုအထိ နားလည်ပြီး intermediate register staging မရှိဘဲ DRAM နှင့် local store အကြား tile များကို asynchronously stream လုပ်သည်။ transfer များကို scalar register များမှ load လုပ်ထားသော descriptors များဖြင့် ဖော်ပြထားပြီး လုံခြုံရေးအတွက် hardware တွင် bounds-checked လုပ်ထားသည်။ Multicast load များကို ပံ့ပိုးပေးထားသောကြောင့် SIMD unit များသည် copy လုပ်ခြင်း သို့မဟုတ် burn register များကို staging လုပ်ခြင်းတွင် ဘယ်တော့မှ ရပ်တန့်မနေပါ။ ၎င်းသည် မကြာသေးမီက NVIDIA အစိတ်အပိုင်းများရှိ tensor-memory accelerator များအတွက် CDNA 5 ၏ အဖြေဖြစ်သည်။ utilization feature အစုံသည် စက်၏ ရှေ့မျက်နှာစာကို ပြီးပြည့်စုံစေသည်- workgroup clusters များသည် data-sharing workloads များအတွက် kernel များကို နေရာချထားမှုနှင့် concurrency ကို ရှင်းလင်းစွာ ထိန်းချုပ်နိုင်စေပြီး split နှင့် named barrier များသည် producer အား signal ပြီးစီးမှုနှင့် consumer မှ ဖြေကြားရန် မစောင့်ဘဲ ဆက်လက်လုပ်ဆောင်နိုင်စေပြီး hierarchy stage data ၏ level တစ်ခုစီတွင် prefetcher များကို ၎င်း၏ consumption point သို့ ရောက်ရှိစေပြီး ပြန်လည်ပြုပြင်ထားသော command front end သည် inference ကို လွှမ်းမိုးသော short kernel များအတွက် kernel launch နှင့် dispatch latency ကို လျှော့ချပေးသည်။

DMA စနစ်ကို တူညီတဲ့ အတွေးအခေါ်နဲ့ ပြန်လည်တည်ဆောက်ခဲ့ပါတယ်။ ဆော့ဖ်ဝဲလ်က DMA ရှေ့ပိုင်းတွေကို လွှဲပြောင်းပေးနေချိန်မှာ ရုပ်ပိုင်းဆိုင်ရာ သိရှိနားလည်တဲ့ နောက်ဘက်အပိုင်းတွေက UALoE လင့်ခ်တွေဘေးမှာ ရှိနေတာကြောင့် အလုပ်တစ်ခုချင်းစီကို ပိုင်းခြားပြီး ရရှိနိုင်တဲ့လင့်ခ်တိုင်းတစ်လျှောက်မှာ load-balance လုပ်ကာ မှတ်ဉာဏ်ကနေ buffer တွေကို တန်းဆွဲထုတ်ပါတယ်။ နောက်ဘက်အပိုင်းတွေက scale-up network ကနေ congestion back-pressure ကိုလည်း တုံ့ပြန်ပြီး loaded path တွေမှာ မောင်းနှင်တာကြောင့် communication libraries တွေက အောက်က topology ကို နားမလည်ဘဲ balanced fabric traffic ကို ရရှိပါတယ်။

GPU ကို ပိုင်းခြားခြင်း- NPS နှင့် SR-IOV

နှစ်ခု-L2 ရုပ်ပိုင်းဆိုင်ရာ အပြင်အဆင်သည် GPU ပိုင်းခြားပုံတွင် ဒုတိယအကျိုးကျေးဇူးကို ပေးဆောင်သည်။ NPS1 တွင် ချစ်ပ်တစ်ခုလုံးသည် NUMA domain တစ်ခုဖြစ်သည်- တူညီသော bandwidth အတွက် HBM stack ဆယ့်နှစ်ခုလုံးနှင့် တစ်ဝက်စီတွင် လိပ်စာများ interleave လုပ်ခြင်း၊ porting အတွက် easy mode နှင့် ညီညာစွာပျံ့နှံ့သော access pattern များအတွက်။ NPS2 သည် GPU ကို NUMA domain နှစ်ခုအဖြစ် ပိုင်းခြားပြီး တစ်ခုစီတွင် HBM stack ခြောက်ခု၊ Fabric တစ်ခုနှင့် Cache Die တစ်ခုနှင့် XCD များကို ၎င်းပေါ်တွင် stack လုပ်ထားသည်။ ထို့နောက် memory reference တိုင်းသည် ၎င်း၏ကိုယ်ပိုင်တစ်ဝက်အတွင်းတွင် ရှိနေမည်ဖြစ်ပြီး domain တစ်ခုစီသည် သီးသန့် 96MB L2 ကို ထိရောက်စွာ ရရှိသည်။ ၎င်းသည် ရုပ်ပိုင်းဆိုင်ရာလမ်းကြောင်းကို တိုစေရုံသာမက လုပ်ဆောင်သည်။ တစ်ဝက်စီအကြား cache လိုင်းများ မျှဝေခြင်းမရှိသောကြောင့် L2 နှစ်ခုကြားရှိ Infinity Fabric coherency traffic သည် အများအားဖြင့် ပျောက်ကွယ်သွားပြီး AMD က ရလဒ်အနေဖြင့် latency နည်းပါးပြီး NUMA-aware application များအတွက် ပိုမိုကောင်းမွန်သော စွမ်းဆောင်ရည်ရှိသည်ဟု ပြောကြားခဲ့သည်။ CDNA 4 သည် အလားတူကျယ်ပြန့်သော ကုန်သွယ်မှုကို ပေးဆောင်ခဲ့ပြီး NPS2 သည် I/O die တစ်ခုတည်းအတွင်း traffic ကို ထိန်းသိမ်းထားသော်လည်း CDNA 5 သည် ၎င်းကို ပိုမိုထက်မြက်စေသည်၊ အဘယ်ကြောင့်ဆိုသော် localized လုပ်နေသည့်အရာသည် memory-side buffer ၏ အပိုင်းအစတစ်ခုအစား L2 cache အပြည့်အစုံဖြစ်နေသောကြောင့်ဖြစ်သည်။

အပေါ်ဆုံးမှာ Compute partitioning stack တွေ ပါရှိပါတယ်။ XCD ရှစ်ခုက GPU ကို spatial partition တစ်ခု၊ နှစ်ခု၊ လေးခု ဒါမှမဟုတ် ရှစ်ခုအဖြစ် boot လုပ်ခွင့်ပြုပြီး 432GB HBM ကို 432၊ 216၊ 108 ဒါမှမဟုတ် 54GB ညီညာတဲ့ အပိုင်းလေးတွေအဖြစ် ရှစ်ပိုင်းခွဲပြီး XCD တစ်ခုစီအတွက် ရှစ်ပိုင်းခွဲပါတယ်။ NUMA domain တွေနဲ့ partition တွေကို တွဲချိတ်ခြင်းအားဖြင့် runtime dispatch ကို အလုပ်လုပ်စေပြီး spatial allocations တွေကို နေရာချပေးတာကြောင့် job တစ်ခုဟာ memory နဲ့ အနီးဆုံး XCD တွေပေါ်မှာ ရောက်သွားပါလိမ့်မယ်။ SR-IOV က partition တွေကို hardware-isolated virtual machine ရှစ်ခုအထိ virtualize လုပ်ပါတယ်။ NUMA mode ဘယ်ဟာ run နေလဲ မခွဲခြားဘဲ memory system မှာ isolation ကို enforce လုပ်ပါတယ်။ MI355X က one-to-eight partition option တွေကို ပေးစွမ်းတာကြောင့် granularity က အသစ်အဆန်းတော့ မဟုတ်ပါဘူး။ CDNA 5 က အောက်မှာ ထပ်ထည့်ထားတာက private-L2 behavior ဖြစ်ပြီး အပေါ်မှာတော့ Helios section က လွှမ်းခြုံထားတဲ့ rack-level Virtual Pods တွေ ပါဝင်ပါတယ်။

AMD Helios

MI455X တစ်လုံးတည်းနဲ့ မြန်ပါတယ်။ ဒါပေမယ့် ဒီမိတ်ဆက်ပွဲနဲ့အတူ AMD ဟာ rack-scale နဲ့ large-scale-up domain club ထဲကို ဝင်ရောက်လာပါတယ်။

ရုပ်ပိုင်းဆိုင်ရာအရ Helios သည် ရိုးရာ ၁၉ လက်မနှင့် ၂၁ လက်မ rack များကို ဖြုတ်ချပြီး Open Rack Wide အဖြစ် ပြောင်းလဲခဲ့သည်။ ၎င်းသည် AMD မှ Meta နှင့်အတူ OCP တွင် တီထွင်ခဲ့သော ပုံစံဖြစ်သည်။ အကျယ် ၁.၂ မီတာနှင့် အနက် ၁.၃ မီတာရှိသော cabinet တစ်ခုနှင့် ဒေါင်လိုက်နေရာ ၄၄ OU ရှိသည်။ အတွင်းပိုင်းတွင် GPU ၇၂ ခုကို compute tray ကိုးခုပါသော bank နှစ်ခုတွင် switch tray ခြောက်ခုကို ၎င်းတို့အကြားတွင် အထပ်လိုက်စီထားပြီး GPU-to-switch link တိုင်းသည် နောက်ဘက်ရှိ blind-mate cable cartridge လေးခုမှတစ်ဆင့် ကြေးနီဖြင့် သွယ်တန်းထားသောကြောင့် tray များသည် လက်ဖြင့် ကြိုးဖြုတ်ရန်မလိုဘဲ ဝန်ဆောင်မှုအတွက် လျှောကျသွားသည်။

rack တစ်ခုလုံးသည် workload ပေါ်မူတည်၍ 225 မှ 245kW အထိ ထုတ်ယူပြီး 50V အရည်အအေးပေး bus bar မှတစ်ဆင့် ပို့ဆောင်ပေးကာ နောက်ဘက် manifolds များသည် facility loop မှ တစ်မိနစ်လျှင် အအေးခံရည် 385 လီတာခန့်ကို တွန်းထုတ်ပေးပါသည်။ ဗန်းများကိုယ်တိုင်က အရေးပါသော hardware များဖြစ်သည်- တစ်ခုစီသည် ပေါင် 170 ခန့်ရှိပြီး switch tray ၏ differential-pair ချိတ်ဆက်မှု 1,728 ခုကို တပ်ဆင်ရန် ထည့်သွင်းအား ပေါင် 690 ခန့် လိုအပ်သောကြောင့် ၎င်း၏ cam လက်ကိုင်များသည် ဗန်း၏ အကျယ်နီးပါးကို လည်ပတ်စေသည်။

ဆောက်တုံး

ကွန်ပျူတာဗန်း

reference design မှာ compute tray တစ်ခုစီဟာ MI455X module ၄ ခုနဲ့ 5GHz အထိ boost လုပ်နိုင်တဲ့ high-frequency 96-core Venice SP7 CPU တို့နဲ့ တည်ဆောက်ထားတဲ့ self-contained node တစ်ခု ဖြစ်ပါတယ်။ ၎င်းရဲ့ DIMM socket ၁၆ ခုမှာ 16 × 64GB DDR5 ECC RDIMM တွေအနေနဲ့ DRAM 1TB ပါဝင်ပြီး CPU မှာ E1.S NVMe slot ၅ ခု ပါဝင်ပါတယ်။ ဒီ platform ကို အဆင့်သတ်မှတ်ချက် အများကြီး ပေးထားတယ်- Venice ရဲ့ memory channel ၁၆ ခုဟာ bandwidth 16TB/s အထိ ထောက်ပံ့ပေးပြီး ဒီနေ့ခေတ် DDR5 range ရဲ့ အမြင့်ဆုံးမှာ 256GB RDIMM တွေရှိတာကြောင့် channel တစ်ခုလျှင် DIMM ၁ ခုရှိတဲ့ 16-channel socket တစ်ခုဟာ 4TB အထိ အမြင့်ဆုံး ရရှိနိုင်ပါတယ်။

NVIDIA ရဲ့ခြေရာကို လိုက်လျှောက်ပြီး CPU ဟာ GPU တွေရဲ့နောက်မှာ ရိုးရိုး PCIe host အနေနဲ့ထိုင်မယ့်အစား Infinity Fabric ပေါ်က coherent memory domain နဲ့ ချိတ်ဆက်ထားပါတယ်။ AMD ကတော့ 1:4 CPU-to-GPU ratio ဟာ ရည်ရွယ်ချက်ရှိရှိလုပ်ဆောင်တာလို့ ငြင်းခုံပါတယ်။ core ကိုယ်တိုင်က ပြိုင်ဘက်တွေထက် သာလွန်ပါတယ်။ AMD ရဲ့ apples-to-apples ခန့်မှန်းချက်အရ 5GHz Zen 6 core ဟာ NVIDIA ရဲ့ Vera ထက် per-core စွမ်းဆောင်ရည် ၂၀% လောက် သာလွန်ပါတယ်။ socket ဟာ standard SP7 ဖြစ်တာကြောင့် host compute ပိုလိုချင်တဲ့ customer တွေဟာ 256-core flagship အထိ Venice SKU တိုင်းကို ထည့်သွင်းနိုင်ပါတယ်။ Venice socket တစ်ခုဟာ LPDDR host design ထက် DDR5 capacity အများကြီးပိုပါဝင်ပြီး ၎င်းရဲ့ memory bandwidth ဟာ Infinity Fabric link တွေတစ်လျှောက် GPU ၄ ခုလုံးအတွက် အပြည့်အဝရှိပါတယ်။

အဲဒီ Infinity Fabric ချိတ်ဆက်မှုကို အနီးကပ်လေ့လာကြည့်သင့်ပါတယ်။ Chips and Cheese မှ George Cozma နဲ့ Venice-to-MI455X ချိတ်ဆက်မှုအကြောင်း ဆွေးနွေးတဲ့အခါ EPYC က သူ့ရဲ့ xGMI socket link တွေကို PCIe PHY တွေပေါ်မှာ နှစ်ပေါင်းများစွာ သယ်ဆောင်လာခဲ့သလိုပဲ coherent link ဟာ CPU ရဲ့ PCIe လမ်းကြောင်းတွေပေါ်မှာ စီးဆင်းနေတယ်လို့ အကြံပြုခဲ့ပါတယ်။ ကိန်းဂဏန်းတွေက အဲဒီသီအိုရီကို ထောက်ခံပါတယ်။ PCIe Gen 6 က တစ်လမ်းကြောင်းကို 64 Gb/s နဲ့ signal ပေးစွမ်းနိုင်ပြီး အဲဒီနှုန်းနဲ့ x16 link က တစ်လမ်းကြောင်းကို 128GB/s နဲ့ အလုပ်လုပ်ပြီး AMD က GPU တစ်ခုချင်းစီမှာ ကိုးကားထားတဲ့ 256GB/s bidirectional ကိန်းဂဏန်းနဲ့ တစ်ထပ်တည်းကျပါတယ်။ CDNA 5 whitepaper ရဲ့ ကိုယ်ပိုင် block diagram မှာ host Infinity Fabric interface ကို တစ်လမ်းကြောင်းကို 64 Gb/s နဲ့ တံဆိပ်ကပ်ထားပြီး Gen 6 signaling rate အတိအကျပါပဲ။ ဒီသီအိုရီက Venice SKU တစ်ခုခု ဘာကြောင့် ကျဆင်းသွားတယ်ဆိုတာကိုလည်း ရှင်းပြပါတယ်- GPU ၄ ခုက CPU ရဲ့ Gen 6 လမ်းကြောင်း ၁၂၈ ခုထဲက ၆၄ ခုကို အသုံးပြုပြီး ကျန်တာတွေကို DPU၊ storage နဲ့ အခြား system လိုအပ်ချက်တွေအတွက် အလကားထားခဲ့ပါတယ်။

သီးခြားကွန်ရက်သုံးခုသည် compute tray တစ်ခုစီမှ ဖြတ်သန်းသွားပြီး တစ်ခုစီသည် မတူညီသောအလုပ်အတွက် တည်ရှိနေပါသည်။ အရိုးရှင်းဆုံးမှာ front end ဖြစ်သည်- Pensando Salina 400G DPU တစ်ခုတည်းသည် node ကို ပုံမှန် datacenter ကွန်ရက်သို့ ချိတ်ဆက်ပေးပြီး နောက်ပိုင်းတွင် အသေးစိတ်လေ့လာပါမည်။

ဒုတိယအချက်ကတော့ scale-out ပါ၊ rack တွေကို cluster တွေအဖြစ် ချိတ်ဆက်ပေးတဲ့ network ဖြစ်ပြီး အဲဒါကို နားလည်ဖို့ အရှင်းလင်းဆုံးနည်းလမ်းကတော့ SerDess ကို count လုပ်တာပါပဲ။ MI455X ရဲ့ scale-out ဟာ PCIe Gen 6 ကို တစ်လမ်းကို 64 Gb/s ဒါမှမဟုတ် UALink128 ကို 128 Gb/s နဲ့ အသုံးပြုနိုင်ပြီး Vulcano 800 NIC ဟာ သူ့ရဲ့ 800 GbE port ကို fed လုပ်ထားဖို့အတွက် တစ်လမ်းစီမှာ attachment 128 Gb/s လောက် လိုအပ်ပါတယ်။ Gen 6 rates မှာဆိုရင် NIC တစ်ခုစီမှာ x16 link အပြည့်ယူရတာကြောင့် GPU က NIC ၂ ခု သယ်ဆောင်ပေးပါတယ်။ UALink128 ရဲ့ double signaling rate မှာဆိုရင် x8 link က SerDes တစ်ဝက်မှာ အတူတူပဲ အလုပ်လုပ်တာကြောင့် GPU က Helios က ပို့ပေးတဲ့ configuration ၃ ခုကို သယ်ဆောင်ပေးပါတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ် UALink128 hop က GPU နဲ့ NIC အကြားက private wire တစ်ခုထက် မပိုပါဘူး။ network ကိုယ်တိုင်က Vulcano မှာ စတင်ပါတယ်။ NIC တစ်ခုစီသည် AMD နှင့် အခြားလုပ်ဖော်ကိုင်ဖက်များနှင့်အတူ တီထွင်ထားသော multipath protocol MRC အပါအဝင် UEC နှင့် ကိုက်ညီသော transports များကို လုပ်ဆောင်သည့် 800GbE port တစ်ခုကို မောင်းနှင်သည်။ ရုပ်ပိုင်းဆိုင်ရာအရ NIC များသည် tray တစ်ခုလျှင် custom board ၂ ခုပေါ်တွင် Vulcano ASIC ၄ ခု သို့မဟုတ် ၆ ခုစီ ပါဝင်ပြီး GPU တစ်ခုလျှင် ၂ ခုနှင့် GPU တစ်ခုလျှင် ၃ ခု configuration များနှင့် ကိုက်ညီသည်။ အပြည့်အဝကိုက်ညီမှုအရ tray တစ်ခုလျှင် NIC ၁၂ ခုနှင့် GPU တစ်ခုလျှင် scale-out bandwidth 2,400 Gb/s ဖြစ်သည်။ ထို့အပြင် NIC များကို GPU များနှင့် ချိတ်ဆက်ထားသောကြောင့် CPU သည် path တွင် မည်သည့်နေရာတွင်မျှ မရှိသောကြောင့် rack-to-rack traffic သည် host link ကို ဘယ်တော့မှ မထိပါ။

တတိယအချက်ကတော့ Helios ကို စစ်မှန်တဲ့ rack-scale စနစ်တစ်ခုဖြစ်စေတဲ့ fabric ဖြစ်ပြီး scale-up ပါ။ GPU တစ်ခုစီမှာ UALoE link ၃၆ ခုပါဝင်ပြီး ESUN Ethernet မှတစ်ဆင့် UALink ရဲ့ memory semantics ကို လုပ်ဆောင်ပေးပါတယ်။ link တစ်ခုစီဟာ 400 Gb/s အတွက် ကောင်းမွန်ပြီး GPU တစ်ခုလျှင် bidirectional bandwidth 36TB/s အထိ ပေါင်းထည့်ပေးပါတယ်။ အဲဒီ link တွေဟာ tray ရဲ့နောက်ဘက်ကနေ switch tray တွေဆီကို ထွက်သွားပြီး GPU ၇၂ ခုကို shared-memory pod တစ်ခုတည်းအဖြစ် ပေါင်းစပ်ပေးတဲ့ load-store traffic ကို သယ်ဆောင်ပေးပါတယ်။

ခလုတ်ဗန်း

နောက်တစ်ခုကတော့ switch trays တွေဖြစ်ပြီး သူတို့နဲ့ ပတ်သက်ပြီး အထင်ရှားဆုံးအချက်ကတော့ သူတို့ရဲ့ silicon က ဘယ်လောက်တောင် သာမန်လဲဆိုတာပါပဲ။ tray ၆ ခုစီမှာ Broadcom Tomahawk 6 ASIC ၂ ခု ပါဝင်ပြီး အဲဒီ merchant Ethernet switch chips hyperscalers တွေက သူတို့ရဲ့ leaf-spine networks တွေမှာ ဖြန့်ကျက်အသုံးပြုကြပြီး တစ်ခုစီမှာ 200G ရဲ့ 512 lanes တွေ ပါရှိပါတယ်။

GPU တစ်ခုစီသည် UALoE link ၃ ခု (UALoE link တစ်ခုစီသည် 2x 200G လမ်းကြောင်းများဖြစ်သည်) ကို switch ၁၂ ခုအနက် တစ်ခုစီသို့ ပေးပို့ပြီး link ၁၄၄ ခုသည် compute tray တစ်ခုစီကို နောက်ဘက် cable cartridge များမှတစ်ဆင့် ထွက်ခွာသွားသည်။ ထို့ကြောင့် Tomahawk တစ်ခုစီသည် 400 Gb/s ဖြင့် link ၂၁၆ ခုကို အဆုံးသတ်ပြီး bidirectional bandwidth 216TB/s ကို ရွေ့လျားစေပြီး GPU တစ်ခုစီသည် ၎င်း၏ full 36 links (72x 200G လမ်းကြောင်းများ) နှင့် 3.6TB/s ကို ထိန်းသိမ်းထားပေးသည်။ switch များသည် ၎င်းကို လုပ်ဆောင်ရန် ထူးခြားဆန်းပြားသောအရာများ မလိုအပ်ပါ- UALoE ၏ encapsulation သည် ရိုးရိုး L2 protocol တစ်ခုဖြစ်ပြီး forwarding သည် Ethernet silicon မှ ဆယ်စုနှစ်နှစ်ခုကြာ ပေးဆောင်ခဲ့သော static MAC programming ပေါ်တွင် မှီခိုနေရပြီး flow control သည် စံ priority flow control ဖြစ်သည်။

အဆင့်တစ်ခုတည်းနဲ့ဆိုရင် datacenter ပိတ်ဆို့မှုပြဿနာတွေ အတန်းအစားတစ်ခုလုံး ဘယ်တော့မှ မပေါ်ပေါက်ပါဘူး- multi-tier incast မရှိတော့ဘဲ GPU တိုင်းဟာ တစ်ခုနဲ့တစ်ခု fixed-latency hop တစ်ခုတည်းမှာပဲ ရှိနေမှာပါ။ direct mesh နဲ့ နှိုင်းယှဉ်ရင် switched approach က workload တစ်ခု လိုအပ်တဲ့အခါ single flow က path ရဲ့ bandwidth တစ်ခုလုံးကို claim လုပ်နိုင်ပြီး GPU တိုင်းကို အကွာအဝေးတူညီအောင် ထိန်းထားပေးပါတယ်။ ဒါကြောင့် scheduling က locality ကို ဘယ်တော့မှ မစဉ်းစားဘဲ link တိုင်းကို တူညီတဲ့ fault protection ပေးပါတယ်။

အမှားသည်းခံစိတ်

Helios သည် hardware ချို့ယွင်းမှုကို ဒီဇိုင်းထည့်သွင်းမှုတစ်ခုအဖြစ် သဘောထားသည်။ ဤအတိုင်းအတာတွင် တစ်စုံတစ်ခုသည် အမြဲတမ်း ကျိုးပဲ့နေသည်- ပြတ်တောက်နေသော cable၊ ပြုတ်ကျနေသော packet၊ firmware update အတွက် ဆွဲထုတ်ထားသော switch၊ လုံးဝပျက်စီးသွားသော compute tray။ ထိုဖြစ်ရပ်များထဲမှ မည်သည့်အလုပ်မျှ မပျက်စီးစေရန် fabric ကို တည်ဆောက်ထားသည်။ ပြုတ်ကျနေသော packet များကို ပြန်လည်ထုတ်လွှင့်ခြင်းဖြင့် ပြန်လည်ရယူပြီး link၊ cable သို့မဟုတ် switch တစ်ခု ပျက်ကွက်သွားသောအခါ၊ traffic သည် ခဏတာ ရပ်တန့်ပြီးနောက် ၎င်းပတ်လည်တွင် အလိုအလျောက် ပြန်လည်လမ်းကြောင်းပြောင်းသွားပြီး checkpoint မှ ပြန်လည်စတင်မည့်အစား ကျန်ရှိနေသော bandwidth တွင် workload ဆက်လက်လုပ်ဆောင်သည်။

12-plane topology က degradation ကို ချောမွေ့စေပြီး 3-way striping က step size ကို သတ်မှတ်ပေးပါတယ်။ GPU တစ်ခု switch တစ်ခုနဲ့ ချိတ်ဆက်ထားတဲ့ link ၃ ခုထဲက ၁ ခုကို ဆုံးရှုံးသွားရင် အဲဒီ plane က သူ့ရဲ့ bandwidth ရဲ့ သုံးပုံနှစ်ပုံကို ထိန်းထားပေးပါတယ်။ Tomahawk တစ်ခုလုံး ဆုံးရှုံးသွားရင် GPU တစ်ခုစီက သူ့ရဲ့ scale-up bandwidth ရဲ့ ၁/၁၂ ကို ဆုံးရှုံးသွားပြီး all-to-all က ကျန်တဲ့ plane ၁၁ ခုမှာ အလုပ်လုပ်နေမှာပါ။ switch tray တစ်ခုလုံး၊ switch tray ၁၂ ခုထဲက ၂ ခု ဆုံးရှုံးရင်တောင် GPU တစ်ခုစီက ချိတ်ဆက်မှုကို မထိခိုက်စေဘဲ bandwidth ရဲ့ ခြောက်ပုံတစ်ပုံကို ကုန်ကျပါတယ်၊ ဘာလို့လဲဆိုတော့ GPU တစ်ခုမှ switch တစ်ခုပေါ် မူတည်ပြီး တခြားတစ်ခုကို မရောက်ရှိနိုင်လို့ပါ။ နှိုင်းယှဉ်ကြည့်မယ်ဆိုရင် Vera Rubin NVL72 က GPU တစ်ခုစီကို tray ၉ ခုမှာ NVSwitch 6 ASICs ၃၆ ခုမှာ ဖြန့်ကျက်ထားတာကြောင့် switch-tray ချို့ယွင်းမှုတစ်ခုဟာ ကိုးပုံတစ်ပုံလောက် ကုန်ကျပါတယ်။ NVIDIA က switch ASIC ၃ ဆ ပိုများတဲ့ degradation step တွေကို ဝယ်ယူပါတယ်။ AMD က higher-radix switch ၁၂ ခုက components, cables နဲ့ connectors တွေ ချို့ယွင်းမှု နည်းစေတယ်လို့ တန်ပြန်ပါတယ်။ ရက်သတ္တပတ်များဖြင့် တိုင်းတာသော လေ့ကျင့်မှုတစ်ခုအတွက်၊ fabric bandwidth ၏ ခြောက်ပုံတစ်ပုံ ဆုံးရှုံးခြင်းနှင့် အလုပ်ဆုံးရှုံးခြင်းကြား ကွာခြားချက်မှာ rack ၏ စီးပွားရေးတစ်ခုလုံးဖြစ်သည်။

Virtual Pod များ

ချို့ယွင်းချက်တွေကြားက fabric ကို ပိုင်းခြားပေးတဲ့ ယန္တရားတစ်ခုတည်းကပဲ ရည်ရွယ်ချက်ရှိရှိ ပိုင်းခြားနိုင်ပါတယ်။ AMD က construct Virtual Pods ဒါမှမဟုတ် vPods လို့ ခေါ်ပြီး unit က compute node ပါ- rack ရဲ့ 18 4-GPU node တွေရဲ့ ပေါင်းစပ်မှုတိုင်းကို သီးခြား pod တစ်ခုအဖြစ် ပိုင်းခြားနိုင်ပါတယ်၊ tenant အသေးစားအတွက် node တစ်ခုကနေ rack အများစုအတွက် training job အကြီးစားအတွက် node တစ်ခုအထိပါ။ သီးခြားခွဲထားမှုကို scheduler ဆုံးဖြတ်တဲ့ မည်သည့်အရာမှ မပါဘဲ fabric hardware မှာ ပြဌာန်းထားပါတယ်။ vPod တစ်ခုကို သူ့ရဲ့ tenant နဲ့ ချိတ်ဆက်ထားပါတယ်။ တခြား pod တွေဟာ သူ့ရဲ့ memory ဒါမှမဟုတ် သူ့ရဲ့ traffic ကို ဝင်ရောက်ခွင့် မရှိပါဘူး၊ ပြီးတော့ UALoE link တိုင်းမှာ line-rate AES-256-GCM encryption က customer-owned cluster keys တွေကို support လုပ်တာကြောင့် tenant တစ်ယောက်ရဲ့ tensors တွေကို နောက်တစ်ယောက်ဆီ မမြင်ရစေပါဘူး။ GPU အများအပြားပါဝင်တဲ့ guest VM မှာ သူ့ရဲ့ security domain ကို host OS ကို ယုံကြည်ဖို့ မလိုအပ်ဘဲ ပွင့်လင်းမြင်သာစွာ တိုးချဲ့ထားပါတယ်။ NVIDIA က သူ့ရဲ့ NVL72 rack တွေမှာလည်း အလားတူပြဿနာကို ဖြေရှင်းပေးပါတယ်၊ IMEX service brokering နဲ့ NVLink domain ကို partitions တွေအဖြစ် ပိုင်းခြားပြီး node တွေက memory ကို တစ်ခုနဲ့တစ်ခု export နဲ့ import လုပ်နိုင်ပါတယ်။ vPod များသည် UALoE ကမ္ဘာ့အဆင့်မီ ကွန်ရက်များဖြစ်သောကြောင့် GB200 သို့မဟုတ် GB300 ယာဉ်စုများမှ လာသော အော်ပရေတာများသည် ဤသဘောတရားကို ရင်းနှီးပြီးသား ဖြစ်ပါလိမ့်မည်။

compute tray တစ်ခု crash ဖြစ်သွားရင် blast radius ဟာ သူ့ရဲ့ vPod မှာ ရပ်တန့်သွားပါတယ်။ အဲဒီ workload ဟာ checkpoint ကနေ restart လုပ်နေချိန်မှာ တခြား pod တိုင်းက untouched မှာ run နေပြီး tenant boundary က failure boundary အနေနဲ့ နှစ်ဆတိုးလာပါတယ်။ partitioning story ကလည်း အောက်ဘက်အထိ ရောက်သွားပါတယ်၊ ဘာလို့လဲဆိုတော့ MI455X တစ်ခုတည်းက SR-IOV virtual machine ၈ ခုအထိ ပိုင်းခြားနိုင်လို့ rack တစ်ခုတည်းက GPU ၇၂ ခုလုံးကို pod တစ်ခုတည်းအဖြစ် run နေတဲ့ customer ၁ ယောက် ဒါမှမဟုတ် GPU-slice tenant ၅၇၆ ခုအထိ run နေတဲ့ customer ၁ ယောက်ကို pod တစ်ခုတည်းအဖြစ် ဒါမှမဟုတ် hardware isolation နဲ့ အဲဒီ hierarchy ရဲ့ level တိုင်းမှာ ရှိနေပါတယ်။

စီမံခန့်ခွဲမှုလေယာဉ်

ဤအရာအားလုံးကို လုပ်ဆောင်ခြင်းသည် hardware ကဲ့သို့ openness thesis ကို လိုက်နာသော dedicated software stack တစ်ခုဖြစ်သည်။ AMD Fabric Manager (AFM) သည် control plane ဖြစ်သည်- ၎င်းသည် 72-GPU fabric ကို zero-touch bring-up ဖြင့် ရှာဖွေတွေ့ရှိပြီး ပံ့ပိုးပေးသောကြောင့် rack ကိုဖွင့်ထားခြင်းသည် GPU ၇၂ ခုလုံး ပေါ်လာရန် လုံလောက်သည်၊ ထို့နောက် cable-cartridge wiring ကို assembly အမှားများနှင့် ကိုက်ညီစွာ အတည်ပြုသည်၊ rack ကို vPods များအဖြစ် ထွင်းထုသည်၊ နှင့် အထက်တွင်ဖော်ပြထားသော rerouting နှင့် recovery ကို ညှိနှိုင်းပေးသည်။ dedicated management tray မရှိပါ။ AFM သည် switch trays ၏ကိုယ်ပိုင် management processors များပေါ်တွင် redundant instance ၃ ခုအဖြစ် trays ၆ ခုတွင် ဖြန့်ကျက်ထားပြီး ၎င်းတို့အကြားတွင် distributed database တစ်ခုဖြင့် လည်ပတ်သည်၊ ထို့ကြောင့် switch tray တစ်ခုဆုံးရှုံးခြင်းသည် control plane ကို ဘာမှမလုပ်ဆောင်ပါ၊ ထို့အပြင် northbound REST API သည် fabric ကို rack များစွာကို စီမံခန့်ခွဲသော cluster controllers များနှင့် ထိတွေ့စေသည်။

အတွင်းပိုင်းမှာ AFM ဟာ cloud-native ကမ္ဘာကနေ သူ့ရဲ့ plumbing ကို ငှားရမ်းအသုံးပြုထားပြီး tray တစ်ခုချင်းစီမှာ agent တွေပါတဲ့ standard Kubernetes-style controllers တွေပေါ်မှာ တည်ဆောက်ထားပါတယ်။ UALink က GPU တစ်ခုချင်းစီကို ကိုင်တွယ်ဖြေရှင်းဖို့ အသုံးပြုတဲ့ accelerator ID တွေကို သတ်မှတ်ပေးတာအထိ user တွေ မမြင်ချင်တဲ့ fabric အသေးစိတ်အချက်အလက်တွေကို ကိုင်တွယ်ပါတယ်။ ဒါဟာ rack ရဲ့ observability layer လည်း ဖြစ်ပါတယ်။ single dashboard က GPU နဲ့ fabric utilization၊ link health နဲ့ failure events တွေကို ခြေရာခံပါတယ်။ တစ်ခုခု ပျက်သွားတဲ့အခါ ပြုပြင်ဆဲအခြေအနေကို ပြသပြီး operator တွေက သူတို့ရဲ့ tooling ထဲကို wire ချိတ်နိုင်တဲ့ alerts တွေ ထုတ်ပေးပါလိမ့်မယ်။ အပေါ်က screenshot က AFM က AMD ရဲ့ ကိုယ်ပိုင် lab တွေမှာ Helios cluster ကို စောင့်ကြည့်နေတာပါ။ Management က in-band ဒါမှမဟုတ် out-of-band နဲ့ အလုပ်လုပ်တာကြောင့် diagnostics နဲ့ configuration တွေက workload တွေကို ဘယ်တော့မှ မနှောင့်ယှက်ပါဘူး။ AFM အောက်က switch တွေက SONiC၊ open-source NOS ပေါ်မှာ တည်ဆောက်ထားတဲ့ network OS ကို လည်ပတ်ပြီး AMD က သူ့ရဲ့ UALoE additions တွေကို standard gNMI APIs တွေကနေတစ်ဆင့် upstream လုပ်ပြီး exposed လုပ်မယ်လို့ ပြောပါတယ်။ Rack အထက်တွင် Rack Infrastructure Manager သည် node နှင့် switch ၏ သက်တမ်းစက်ဝန်း၊ ပါဝါနှင့် ယိုစိမ့်မှုရှာဖွေခြင်းတို့ကို လွှမ်းခြုံထားပြီး Cluster Controller သည် Helios ကို Kubernetes နှင့် Slurm တို့တွင် အချိန်ဇယားဆွဲရန်အတွက် ချိတ်ဆက်ပေးသည်။

Helios နှင့် NVIDIA Vera Rubin NVL72

ဒါကြောင့် Helios က ဈေးကွက်ထဲမှာ တကယ်တွေ့ရမယ့် NVIDIA ကမ်းလှမ်းချက်ဖြစ်တဲ့ Vera Rubin NVL72 နဲ့ ဘယ်လိုနှိုင်းယှဉ်ကြည့်မလဲဆိုတာ ကြည့်ကြရအောင်။

ရက်ခ် မက်ထရစ်	AMD Helios	ဗီရာ ရူဘင် NVL72
အဆင့်မြင့်ထိပ်တန်း	၇၂ MI၄၅၅X	၇၂ ရူဘင်
CPU များ	18 ဗင်းနစ်	၃၆ ဗီရာ
HBM စွမ်းရည်	31TB	20.7TB
HBM bandwidth	၁.၅၈ ပီဘီ/စက္ကန့်	၁.၅၈ ပီဘီ/စက္ကန့်
GPU တစ်ခုချင်းစီအလိုက် တိုးချဲ့ခြင်း	၃.၆ TB/s	၃.၆ TB/s
သိုလှောင်ရုံ အရွယ်အစား မြှင့်တင်ခြင်း	၃.၆ TB/s	၃.၆ TB/s
GPU တစ်ခုချင်းစီ၏ အရွယ်အစား	2,400 Gb / s ကို	1,600 Gb / s ကို
ချဲ့ထွင်ခလုတ်များ	၁၂ တိုမာဟော့ခ် ၆	၃၆ NVSwitch ၆
သိုလှောင်မှုပုံစံ	နှစ်ထပ်ကျယ် ORW	MGX တစ်လုံးထိုး

စာရွက်ပေါ်မှာတော့ scorecard က AMD ရဲ့လမ်းကြောင်းကို စောင်းသွားစေတယ်။ HBM ၅၀% ပိုများတယ်၊ switch ASIC သုံးပုံတစ်ပုံထက် GPU တစ်ခုချင်းစီရဲ့ scale-up 3.6TB/s တူညီတယ်၊ GPU တစ်ခုချင်းစီရဲ့ scale-out bandwidth ၅၀% ပိုများတယ်။ AMD ရဲ့ internal tests တွေက အဲဒီ specs တွေကို performance claim အဖြစ် ပြောင်းလဲပေးပြီး Kimi K2 Thinking မှာ GPU တစ်ခုချင်းစီရဲ့ second တစ်ခုကို token ၁၀ ကနေ ၁၅% အထိ ပိုများပြီး တစ်ဒေါ်လာကို token ၃၀% အထိ ပိုများတယ်။ ဒါတွေက AMD ရဲ့ ကိန်းဂဏန်းတွေနဲ့ NVIDIA ရဲ့ ထုတ်ဝေထားတဲ့ ကိန်းဂဏန်းတွေနဲ့ နှိုင်းယှဉ်ထားတာဖြစ်ပြီး လွတ်လပ်တဲ့ တိုင်းတာမှုတွေ မဟုတ်ပါဘူး၊ ဒါပေမယ့် AMD က ဘယ်လို အကဲဖြတ်မယ်လို့ မျှော်လင့်ထားလဲဆိုတာကို သတ်မှတ်ပေးပါတယ်။ ပိုပြီးစိတ်ဝင်စားစရာကောင်းတဲ့ ကွာခြားချက်တွေက ဒီဇိုင်းတစ်ခုချင်းစီရဲ့ GPU တွေကို ပြင်ပကမ္ဘာနဲ့ ဘယ်လိုချိတ်ဆက်ပေးလဲဆိုတာမှာ ပုန်းအောင်းနေပါတယ်။

scale-out ကနေစပါ။ MI455X ရဲ့ NIC တွေဟာ GPU ကနေ တိုက်ရိုက်ချိတ်ဆက်ထားပါတယ်။ SemiAnalysis ရဲ့ အဆိုအရ Rubin ရဲ့ NIC တွေက ဒီလိုမလုပ်ပါဘူး။ SemiAnalysis ရဲ့ အဆိုအရ package မှာ ConnectX-9 NIC နှစ်ခုလုံးကို feed လုပ်ဖို့ PCIe မပါဝင်တာကြောင့် Vera CPU ကနေ ချိတ်ဆက်ရပြီး GPU traffic က အရမ်းဝေးပါတယ်- Rubin ကနေ NVLink-C2C ကနေ Vera ကနေ PCIe ကနေ ConnectX-9 ကို ချိတ်ဆက်ရပါတယ်။ ဒီ detour က latency ကို လျှော့ချပေးပြီး C2C link ကို double duty ဖြစ်စေပါတယ်။ compute၊ host traffic နဲ့ network အားလုံးကို တစ်ပြိုင်နက် ချိတ်ဆက်ထားတဲ့အခါ Vera ရဲ့ C2C bandwidth ရဲ့ တစ်စိတ်တစ်ပိုင်းဟာ NIC payload ကို သယ်ဆောင်ဖို့အတွက် သွားပြီး GPU က မြင်တွေ့ရတဲ့ effective host bandwidth က 1.8TB/s အောက်ကို ကျဆင်းသွားပါတယ်။

bandwidth သင်္ချာက ဒါကို ပေါင်းစပ်ပေးပါတယ်။ MI455X တစ်ခုစီက Rubin's 1,600 အထိ scale-out 2,400 Gbit/s ကို တွန်းပို့ပေးတဲ့အတွက် Helios က FLOP တစ်ခုစီမှာ network ပိုသယ်ဆောင်ပါတယ်။ AMD ရဲ့ 8,000-GPU လေ့ကျင့်မှု simulation တွေက တတိယ NIC ဟာ အလုပ်ပြီးမြောက်မှု ၁၃% ခန့် ပိုမြန်တယ်လို့ အသိအမှတ်ပြုပါတယ်။

Rubin က storage ကို ပြန်လည်ထိုးဖောက်ခဲ့ပြီး အကြောင်းရင်းကတော့ NIC နေရာမှာ ရှိနေလို့ပါ။ ConnectX-9 မှာ built-in PCIe switch ပါဝင်တာကြောင့် NVMe ဟာ NIC ကနေ တိုက်ရိုက် hang လုပ်နိုင်ပြီး GPU ဟာ CPU ကို မထိဘဲ GPUDirect Storage ကနေ data တွေကို ဆွဲယူနိုင်ပါတယ်။ MI455X မှာ ညီမျှတဲ့အရာ မရှိပါဘူး။ သူ့ရဲ့ storage ဟာ Venice host ကနေ hang လုပ်ထားတဲ့အတွက် GPUDirect ပုံစံရှိတဲ့ မည်သည့်အရာမဆို CPU ကို ဖြတ်ကျော်ပြီး Infinity Fabric link ကနေ ပြန်လာပါတယ်။ AMD က network path ကို optimize လုပ်ပြီး storage path မှာ ငွေပေးချေခဲ့ပြီး NVIDIA ကတော့ ပြောင်းပြန်အရောင်းအဝယ် လုပ်ခဲ့ပါတယ်။ ဘယ်ဟာက ပိုအရေးကြီးတာက workload ဟာ GPU တွေကြား activation တွေကို ရွှေ့ပြောင်းဖို့ ဒါမှမဟုတ် disk ကနေ streaming data တွေနဲ့ ချိတ်ဆက်ထားဖို့လားဆိုတာပေါ်မှာ မူတည်ပါတယ်။

ဖောက်သည်များ ပြောင်းလဲနိုင်သည့်အရာများ

အတိုချုပ်ပြောရရင် အထက်ဖော်ပြပါအရာအားလုံးဟာ AMD ရဲ့ reference design ကိုဖော်ပြထားပြီး ဂဏန်းအတော်များများဟာ customer တွေတည်ဆောက်နိုင်တဲ့ အထပ်တွေပါ။ အထင်ရှားဆုံးကိစ္စကတော့ host CPU ပါ။ Rubin ရဲ့ Vera ဟာ fixed configuration တစ်ခုတည်းနဲ့ ရောက်ရှိလာပါတယ်။ Helios tray ထဲက Venice ဟာ standard socketed SP7 အပိုင်းဖြစ်ပြီး AMD က Helios-specific customization မပါဘဲ Venice SKU တွေ ရောက်ရှိလာမယ်လို့ အတည်ပြုခဲ့ပါတယ်။ reference tray မှာ single-threaded speed က GPU တွေကို ထောက်ပံ့ပေးထားလို့ 96-core 5GHz အပိုင်းကို အသုံးပြုပါတယ်။ ဒါပေမယ့် customer တွေအနေနဲ့ သူတို့ရဲ့ version ကို 256-core flagship ဒါမှမဟုတ် cache-hungry preprocessing အတွက် 1,152MB stacked L3 နဲ့ Venice-X နဲ့ configure လုပ်တာကို ဘာမှမတားဆီးနိုင်ပါဘူး။

မှတ်ဉာဏ်နှင့် ကွန်ရက်ချိတ်ဆက်မှုသည် တူညီသော socket-and-slot logic ကို လိုက်နာသည်။ DRAM ၏ reference 1TB သည် 64GB RDIMM ၁၆ ခုဖြစ်ပြီး သိပ်သည်းသော DIMM များသည် tray တစ်ခုကို 4TB အထိ ယူဆောင်လာပြီး MRDIMM-12800 သည် Venice ၏ 16TB/s အပြည့်အဝကို လော့ခ်ဖွင့်ပေးသည်။ ကွန်ရက်ဘက်တွင်၊ build တစ်ခုသည် GPU တစ်ခုလျှင် NIC ၃ ခုမှ ရိုးရိုး PCIe Gen 6 တွင် ၂ ခုအထိ ကျဆင်းနိုင်သည်။ Vulcano port တစ်ခုစီသည် Tomahawk 5 သို့မဟုတ် Tomahawk 6 fabrics များနှင့် ယှဉ်လျှင် 1x800G၊ 2x400G၊ 4x200G သို့မဟုတ် 8x100G အဖြစ် လည်ပတ်နိုင်ပြီး P4 pipeline သည် transport၊ RoCEv2၊ MRC သို့မဟုတ် proprietary တစ်ခုခုကို operator ၏ call အဖြစ် ထားခဲ့သည်။ switch NOS သည် open-source SONiC ဖြစ်ပြီး AFM သည် ၎င်း၏ northbound API မှတစ်ဆင့် fabric တစ်ခုလုံးကို ဖော်ထုတ်သောကြောင့် management plane ကိုပင် swappable လုပ်နိုင်သည်။

ပါဝါဘတ်ဂျက်ကလည်း socket အတိုင်းပါပဲ။ NVIDIA ရဲ့ superchips တွေမှာ တူညီတဲ့ envelope တစ်ခုရှိပါတယ်- Vera က 450W အစိတ်အပိုင်းတစ်ခုဖြစ်ပြီး capted slice ပါရှိပြီး မကြာသေးခင်က မျိုးဆက်တွေက load အောက်က GPU တွေဆီကို ပါဝါကို လျှော့ချပေးပါတယ်။ AMD က reference design က host power ကို ကန့်သတ်တာလား ဒါမှမဟုတ် ပြောင်းလဲတာလားဆိုတာကို မပြောခဲ့ပေမယ့် AMD ရဲ့ ဒီဇိုင်းနဲ့ဆိုရင် မေးခွန်းက customer ရဲ့တာဝန်ဖြစ်ပြီး power slitting မရှိဘဲ system ကို ပါဝါပိုမိုသုံးစွဲမှုနဲ့ customer စိတ်ကြိုက်ပြင်ဆင်နိုင်ပါတယ်။

compute tray အပိုင်းမှာ ပြန်ဖြည်လိုက်တဲ့အခါ host link ရဲ့ PCIe underpinnings တွေက နောက်ဆုံးတံခါးတစ်ချပ်ကို ဖွင့်ပေးလိုက်သလိုပါပဲ။ Venice က 2P configuration တွေကို support လုပ်ပါတယ်။ ရွေးချယ်ထားတဲ့ AI host platform တွေက inter-socket xGMI width ကို I/O အတွက် လဲလှယ်ခြင်းအားဖြင့် အသုံးပြုနိုင်တဲ့ PCIe lanes ၁၆၀ အထိနဲ့ 2P ကို ​​run နိုင်ပါတယ်။ customer တစ်ယောက်ဟာ NVIDIA ရဲ့ 1:2 CPU-to-GPU ratio နဲ့ ကိုက်ညီအောင် two-socket tray တစ်ခုကို တည်ဆောက်နိုင်သလို xGMI links တွေကို ထိရောက်တဲ့ CPU-to-GPU bandwidth ကို မြှင့်တင်ဖို့ ပြန်လည်ချိန်ညှိနိုင်ပါတယ်။ ဒီနေ့ခေတ်မှာ ဘယ်သူမှ အဲဒါကို တည်ဆောက်နေတယ်လို့ မဆိုလိုပါဘူး။ ဘယ်ဟာမှ NVLink-C2C ကို 1.8TB/s နဲ့ ကွာဟချက်ကို မပိတ်နိုင်ပါဘူး။ တကယ့်အချက်ကတော့ ဘယ်သူက pen ကို ကိုင်ထားလဲဆိုတာပါပဲ။ Helios မှာ host၊ memory၊ power နဲ့ topology တွေက customer ရဲ့ ဆုံးဖြတ်ချက်တွေပါ။ NVIDIA ရဲ့ superchip က customer ကို pen လုံးဝမပေးပါဘူး။

ဆာလီနာ DPU

အခု ကျွန်တော်တို့ အစောပိုင်းက ရွှေ့ဆိုင်းထားတဲ့ front-end network ကို ပြန်သွားရအောင်။ AMD ရဲ့ တတိယမျိုးဆက် Pensando DPU ဖြစ်တဲ့ Salina ဟာ P4-programmable data path ပါတဲ့ 400G card တစ်ခုဖြစ်ပြီး encapsulation အသစ်၊ telemetry hook ဒါမှမဟုတ် transport ဆိုတာ firmware update တစ်ခုဖြစ်ပြီး traffic ကျဆင်းခြင်းမရှိဘဲ live apply လုပ်ပါတယ်။ shipping service တွေမှာ front-end checklist တွေ ပါဝင်ပြီးသားပါ- VXLAN ဒါမှမဟုတ် NVGRE ပါတဲ့ SDN၊ stateful firewall၊ line-rate IPsec၊ PSP၊ DTLS ဒါမှမဟုတ် custom encryption၊ NAT နဲ့ load balancing တို့ပါ။ ဒါဟာ rack ထဲမှာ အစမ်းသပ်ခံရဆုံး silicon လည်း ဖြစ်ပါတယ်။ Pensando DPU တွေဟာ ၂၀၁၉ ခုနှစ်ကတည်းက hyperscalers တွေကို အသုံးပြုခဲ့ပြီး Salina ဟာ ဒီနေ့ခေတ်မှာ Microsoft၊ Oracle နဲ့ IBM တို့မှာ deployments တွေကို ဦးဆောင်နေပါတယ်။ Oracle က ဒီ line ကို 5× SDN gain နဲ့ ဂုဏ်ပြုပြီး hyperscaler တစ်ခုက server တစ်ခုစီကို CPU cores ၂၂ ခုကို I/O offload လုပ်ခြင်းဖြင့် ပြန်လည်ရယူခဲ့ပါတယ်။

Storage က ဒုတိယအဆင့်ပါ။ Salina က NVMe-over-Fabrics devices တွေကို host ဆီ ထုတ်ဖော်ပြသပြီး encryption၊ digests နဲ့ compression တွေနဲ့ TCP ဒါမှမဟုတ် RDMA ပေါ်မှာ remote SSD pools တွေကို virtualize လုပ်ပါတယ်။ Helios မှာ agentic-era trick တစ်ခုကို ထပ်ထည့်ပါတယ်- context-memory engine က emulated KV device တစ်ခုကို ပြသတာကြောင့် overflowing KV cache ဟာ CPU DRAM၊ local SSD ဒါမှမဟုတ် remote storage ဆီကို လျှံကျပြီး ပြန်လည်တွက်ချက်မယ့်အစား line rate နဲ့ HBM ထဲကို ပြန်စီးဆင်းပါတယ်။ Rubin နှိုင်းယှဉ်ချက်မှာ ဖော်ပြထားတဲ့အတိုင်း MI455X မှာ GPUDirect Storage မပါဝင်ပါဘူး။ ဒီ KV offload က traffic serving မှာ အများဆုံးဂရုစိုက်ရတဲ့ AMD ရဲ့ တစ်စိတ်တစ်ပိုင်းအဖြေပါ။

ဒါက ကျွန်တော်တို့ရဲ့ ကြိုတင်စိုးရိမ်မှုတွေ ရှိနေတဲ့နေရာလည်း ဖြစ်ပါတယ်။ bandwidth gap က ရိုးရှင်းပါတယ်- Salina က 400G card တစ်ခုဖြစ်ပြီး BlueField-4 က Vera Rubin rack တွေထဲကို ပို့ဆောင်ပေးတာက 64-core Grace CPU နဲ့ co-packaged ConnectX-9 ပါဝင်တဲ့ 800G နဲ့ နှစ်ဆတိုးလာပါတယ်။ software gap က ပိုပြီး အငြင်းပွားစရာရှိပေမယ့် တကယ်ရှိပါတယ်။ NVIDIA ရဲ့ DOCA က developer တွေကို containerized၊ prebuilt service တွေကို ordinary C နဲ့ C++ မှာ programmable လုပ်နိုင်အောင် လုပ်ပေးပါတယ်။ P4 က အဖွဲ့အများစု မထိတွေ့ဖူးတဲ့ specialized dataplane language တစ်ခုပါ။ Salina က သူ့ရဲ့ အဓိက service တွေကို အပြည့်အစုံ ပို့ဆောင်ပေးပြီး deploy လုပ်တဲ့ hyperscaler တွေက P4 က MRC လို protocol အသစ်တွေကို firmware မှာ ဘယ်သူ့ရဲ့ silicon cycle ထက်မဆို အရင်ထည့်သွင်းနိုင်စေလို့ ဒီနှိုင်းယှဉ်မှုက ရွေးချယ်ခဲ့တာပါ။ တကယ့်ခြားနားချက်က programmability က ဘယ်သူ့ကို ဝန်ဆောင်မှုပေးသလဲဆိုတာပါပဲ။ Salina ရဲ့ ပြောင်းလွယ်ပြင်လွယ်ရှိမှုက AMD နဲ့ P4-fluent hyperscale အဖွဲ့တွေအတွက် လက်နက်တစ်ခုပါပဲ။ DOCA က သာမန် enterprise developer တွေ ရယူနိုင်တဲ့အရာပါ။ ကျယ်ပြန့်တဲ့ ဈေးကွက်အတွက် NVIDIA ရဲ့ software on-ramp က ပိုလွယ်ကူပြီး AMD က ဒါကို သိပါတယ်။

ROCm.AI

ဆော့ဖ်ဝဲလ်အကြောင်းပြောရရင် AMD က သူ့ရဲ့ ကြီးမားတဲ့ ကြေငြာချက်တစ်ခုကို stack အတွက်ပဲ သိမ်းထားခဲ့ပါတယ်။ သြဂုတ်လမှာ ရောက်ရှိလာမယ့် ROCm.AI ဟာ GPU platform ကို အောက်ခြေကနေစပြီး agent အဖြစ် ပြောင်းလဲဖို့ AMD ရဲ့ ကြိုးပမ်းမှုပါ။ AI Skills က ROCm ကို coding agent developer တွေသုံးနေတဲ့ Claude, Codex, Cursor နဲ့ Gemini တွေနဲ့ ချိတ်ဆက်ပေးတာကြောင့် Instinct မှာ install လုပ်တာ၊ serve လုပ်တာနဲ့ debug လုပ်တာတွေကို ရိုးရိုးရှင်းရှင်းပြောရရင် လုပ်ဆောင်ပါတယ်။ Hyperloom က ပိုပြီး ရဲရင့်တဲ့ အပိုင်းပါ။ workload တစ်ခုကို profile လုပ်တဲ့၊ serving configuration ကို tune လုပ်တဲ့၊ GPU kernel တွေကို rewrite လုပ်တဲ့၊ operator အိပ်နေချိန်မှာ ရလဒ်တွေကို validate လုပ်တဲ့ no-human-in-the-loop optimizer တစ်ခုပါ။ AMD က ဒီနေ့ model ၁၄၀၀၀ လောက်ကို အဆက်မပြတ် optimize လုပ်နေတယ်လို့ ပြောပြီး live demo က MiniMax M3 ကနေ throughput ၃၈% ပိုရစေတယ်လို့ ပြောပါတယ်။ agent တွေအောက်မှာ FlyDSL က Python ကို near-assembly control ယူဆောင်လာပြီး ROCm က ၆ ပတ် release cadence ကို fixed ဖြစ်အောင် ရွှေ့ပြီး ROCm.AI က hardware တူတူပေါ်မှာ ROCm 7 ထက် ပျမ်းမျှ 3.3× inference နဲ့ 2.4× training gain ကို ပေးစွမ်းနိုင်တယ်လို့ AMD က ပြောပါတယ်။ ROCm 7 သည် အမှန်တကယ်တိုးတက်မှုကို အမှတ်အသားပြုပြီးဖြစ်သည်။ ယခုအခါ AMD သည် အရှိန်မြှင့်တင်ရန် AI ကို လောင်းကြေးထပ်နေသည်။

software session ရဲ့ အရေးအကြီးဆုံး slide က hardware အကြောင်းလို့ ဆိုနိုင်ပါတယ်။ AMD က MI455X silicon ဟာ ဒီနေ့ ROCm အောက်မှာ မြန်ဆန်စွာ အလုပ်လုပ်နေတယ်ဆိုတဲ့ အဓိပ္ပာယ်နဲ့ ဂဏန်းတိုင်းကို တိုင်းတာခဲ့တယ်လို့ အလေးပေးပြောကြားခဲ့ပါတယ်။ ကိန်းဂဏန်းတွေကတော့ - FP8 MLA decode မှာ 20TB/s၊ FP4 compute ရဲ့ 20 PFLOPS၊ scale-up bandwidth 3.2TB/s နဲ့ scale-out 190GB/s တို့ပဲ ဖြစ်ပါတယ်။ Q&A မှာ AMD က FP4 ရလဒ်ဟာ device ကို အလိုက်ဖက်ဆုံး matrix shape မှာ လုပ်ဆောင်တဲ့ max-achievable-matmul-FLOPS (MAMF) တိုင်းတာမှုဖြစ်တယ်လို့ ဝန်ခံခဲ့ပြီး ဒါက ဒီ benchmark အမျိုးအစားအတွက် စံသတ်မှတ်ချက်တစ်ခု ဖြစ်ပါတယ်။ ဒါ့အပြင် MI455X ဟာ သူ့ရဲ့ 40.26 PFLOPS peak MXFP4 rating ရဲ့ 50% လောက်ကို ထိန်းသိမ်းထားနိုင်တယ်လို့ AMD က ပွင့်ပွင့်လင်းလင်း ဝန်ခံထားပြီး vendor အများစုက ဒီဂဏန်းကို လျစ်လျူရှုထားကြပါတယ်။

AMD က ဒါကို ဈေးကွက်ထဲက accelerator တွေထဲမှာ အမြင့်ဆုံး သရုပ်ပြ compute လို့ ခေါ်ပြီး အဲဒါကပဲ အရေးပါတာပါ။ AMD ရဲ့ FP4 က OCP MXFP4 ဖြစ်ပြီး NVIDIA ကတော့ NVFP4 ပါ။ သူတို့က ကွဲပြားတဲ့ ချက်နည်းတွေပါ။ NVFP4 က 16-element block တိုင်းအတွက် fractional FP8 scale ကို အပေါ်မှာ tensor-level scale တစ်ခုနဲ့ အသုံးချပြီး baseline MXFP4 က elements ၃၂ ခုအတွက် coarser power-of-two scale ကို အသုံးပြုတာကြောင့် NVFP4 FLOP က MXFP4 FLOP ထက် အလုပ်ပိုလုပ်ပါတယ်။ CDNA 5 က MXFP4 မှာ fractional scaling ကို အသုံးချနိုင်ပေမယ့် AMD က ဘယ်ချက်နည်းကို တိုင်းတာခဲ့တယ်ဆိုတာ မပြောခဲ့ပါဘူး။ Rubin MAMF run နဲ့ MI455X MAMF run တို့ဟာ တူညီတဲ့ သင်္ချာကို မတိုင်းတာတဲ့အတွက် cross-vendor FP4 နှိုင်းယှဉ်မှုတွေက application level မှာပဲ ရှိပါတယ်- matched accuracy မှာ တစ်စက္ကန့်ကို tokens တွေနဲ့ တွက်ချက်ပါတယ်။ တိုင်းတာထားတဲ့ beats တွေကို ခန့်မှန်းထားပေမယ့် ဒီကိန်းဂဏန်းတွေက AMD ရဲ့ ယခင်မျိုးဆက်နဲ့ အနီးစပ်ဆုံး နှိုင်းယှဉ်ဖော်ပြထားပြီး 3× မှ 4× gains တွေက ရှင်းလင်းပါတယ်။

AMD အတွက်လည်း တန်ပြန်အကျိုးသက်ရောက်မှုရှိပါတယ်။ ဒါတွေက အသစ်စက်စက် ဆီလီကွန်ပေါ်က အစောပိုင်း ROCm.AI ရလဒ်တွေဖြစ်လို့ လက်ဖြင့်ချိန်ညှိထားတဲ့ ထုတ်လုပ်မှု ဖြန့်ကျက်မှုက ဘယ်လောက်အထိ အကျိုးသက်ရောက်မလဲဆိုတာကို သူတို့ လျှော့တွက်ထားကြပါတယ်။ ဒီ rack တွေ hyperscaler ကြမ်းပြင်ပေါ် ရောက်တဲ့အခါ တကယ့်ဆုံးဖြတ်ချက် ရောက်လာပါလိမ့်မယ်။

ပိတ် Thoughts

Helios ဟာ AMD တင်ပို့ဖူးသမျှထဲမှာ အပြည့်စုံဆုံးစနစ်ဖြစ်ပြီး chip by chip အစား rack scale မှာ NVIDIA နဲ့ ထိပ်တိုက်တွေ့ဆုံတဲ့ ပထမဆုံးစနစ်လည်း ဖြစ်ပါတယ်။ scorecard က ဒီနေ့ခေတ် AI စွမ်းရည်ကို ဆုံးဖြတ်ပေးတဲ့ နေရာတွေမှာ AMD ရဲ့ နည်းလမ်းကို ဖတ်ရှုပါတယ်- GPU တစ်ခုလျှင် HBM ၅၀% ပိုများခြင်း၊ Rubin နဲ့ scale-up parity၊ scale-out bandwidth ၅၀% ပိုများခြင်း၊ နဲ့ AMD ရဲ့ ကိုယ်ပိုင် modeling အရ တစ်ဒေါ်လာလျှင် token ၃၀% အထိ ပိုများခြင်း။ အရေးကြီးတာက ဘယ်လိုရောက်လာတာလဲ- merchant Tomahawk switch တွေ၊ number format တွေကနေ cabinet အထိ open standard တွေ၊ နောက်ဆုံး configuration ကို customer တွေရဲ့ လက်ထဲမှာ ထားရှိတဲ့ socketed host ပါ။ NVIDIA ဟာ C2C host link၊ DPU နဲ့ software on-ramp မှာ စစ်မှန်တဲ့ အားသာချက်တွေကို ထိန်းသိမ်းထားပေမယ့် ပထမဆုံးအကြိမ်အဖြစ် hardware ဆိုင်ရာ အငြင်းပွားမှုက AMD ကို ထောက်ခံပါတယ်။

ဝယ်သူတွေလည်း သဘောတူကြပါတယ်။ OpenAI၊ Meta၊ Anthropic၊ Microsoft နဲ့ Oracle တို့ဟာ AMD က Helios ကို လက်ခံအသုံးပြုနေတယ်လို့ ပြောတဲ့ ကုမ္ပဏီတွေထဲမှာ ပါဝင်ပြီး၊ AMD က rack တွေကို ဒီနေ့မှာ ထုတ်လုပ်နေပြီဆိုတာကို အလေးပေးပြောကြားခဲ့ပါတယ်။ NVIDIA ရဲ့ ခြေရာကို လိုက်လျှောက်ပြီး လမ်းပြမြေပုံဟာ အခုဆိုရင် နှစ်စဉ် လည်ပတ်နေတဲ့ လမ်းကြောင်းတစ်ခု ဖြစ်လာပါပြီ- CDNA 6-based MI500 series ဟာ ၂၀၂၇ ခုနှစ်မှာ next generation HBM plus copper နဲ့ optical interconnect နဲ့အတူ ရောက်ရှိလာမှာဖြစ်ပြီး MI600 series ကတော့ ၂၀၂၈ ခုနှစ်အတွက် တီထွင်နေပြီ ဖြစ်ပါတယ်။

ဆော့ဖ်ဝဲလ်ကို ချန်ထားခဲ့ပြီး နှစ်ပေါင်းများစွာအတွင်း ပထမဆုံးအကြိမ်အဖြစ် AMD GPU ဇာတ်လမ်းကို အဲဒီသတိပေးချက်နဲ့ အဆုံးသတ်လိုက်တာ မဟုတ်ပါဘူး။ ROCm 7 က တကယ့်ကွာဟချက်တွေကို ပိတ်လိုက်ပြီး ROCm.AI က သြဂုတ်လမှာ တိုင်းတာထားတဲ့ တိုးတက်မှုတွေနဲ့ ရောက်ရှိလာပြီး ဖြန့်ချိမှု cadence က အခုဆိုရင် ခြောက်ပတ်တိတိ ဖြစ်သွားပါပြီ။ ဘယ်သူက ဝယ်ယူနေလဲဆိုတာလည်း အရေးကြီးပါတယ်။ ဒီသဘောတူညီချက်တွေကို လက်မှတ်ရေးထိုးတဲ့ lab တွေနဲ့ hyperscaler တွေက AMD နဲ့ ပူးတွဲဒီဇိုင်းဆွဲပြီး သူတို့ကြုံတွေ့ရတဲ့ ပြဿနာတွေကို ဖြေရှင်းဖို့ လုံလောက်တဲ့ အင်ဂျင်နီယာတွေကို ငှားရမ်းကြပါတယ်။ turnkey stack လိုအပ်နေတဲ့ Enterprise တွေကတော့ ဇာတ်လမ်းကွဲပြားပြီး အဲဒီဈေးကွက်က NVIDIA ရဲ့ ဈေးကွက်အဖြစ် လောလောဆယ်မှာ ရှိနေဦးမှာပါ။ ဒါပေမယ့် Helios ကို hyperscaler တွေနဲ့ AI lab တွေအတွက် တည်ဆောက်ထားပြီး သူတို့အတွက် hardware အဆင်သင့်ဖြစ်နေပြီး software က အရှိန်အဟုန်နဲ့ လိုက်လျောညီထွေဖြစ်အောင် လုပ်ဆောင်နေပြီး rack တွေကလည်း တင်ပို့ရောင်းချနေပါပြီ။ AMD ဟာ ဘယ်တုန်းကမှ ဒီလောက်အားကောင်းတဲ့ အနေအထားမှာ မရှိခဲ့ဖူးပါဘူး။