Discovering the minutiae of backend systems

ကျွန်တော်က ငယ်ငယ်တုန်းက programming ကို တွေ့ရှိခွင့်ရခဲ့တာ ကံကောင်းခဲ့ပြီး အဲဒါကို တခြားအကြောင်းအရာတွေကို စူးစမ်းဖို့ တံခါးပေါက်တစ်ခုအဖြစ် သုံးခဲ့တယ်။ အလယ်တန်းကျောင်းမှာ သူငယ်ချင်းတစ်ယောက်က Texas Instruments calculator တွေနဲ့ ပါလာတဲ့ BASIC programming language အမျိုးအစားတစ်ခုကို မိတ်ဆက်ပေးခဲ့တယ် (program တစ်ခုလျှင် စာလုံးတစ်လုံးတည်း variable ၂၇ ခုသာ သုံးလို့ရတဲ့ ကန့်သတ်ချက်နဲ့ GOTO statement တွေကို အလွန်အကျွံ အားထားရတာကြောင့် ကျွန်တော့် code က ထိန်းသိမ်းရခက်တာ သဘာဝပါပဲ)။ ဒါပေမဲ့ text-based adventure game တွေ၊ calculator ချိတ်ဆက်ပြီး chat app တစ်ခုနဲ့ ပုံမှန် quadratic formula အကူကိရိယာလိုမျိုး ရိုးရှင်းတဲ့ program တချို့ကို ကျွန်တော်တို့ ဖန်တီးခဲ့တယ်။

နောက်ပိုင်းမှာ ပိုရှုပ်ထွေးတဲ့ program တွေကို ရေးခဲ့တယ်။ Newton’s method ကို မြင်သာအောင်ပြဖို့ visual helper တစ်ခုနဲ့ ဂြိုဟ်တွေနဲ့ သူတို့ရဲ့ လတုများ၏ တည်နေရာကို ခန့်မှန်းဖို့ orbit calculator တစ်ခု ရေးခဲ့ပြီး အဲဒါတွေက ကျောင်းရဲ့ Linux club ရဲ့ အာရုံကို ဖမ်းဆွဲနိုင်ခဲ့တယ်။ မကြာခင်မှာပဲ laptop ရဲ့ CardBus အခြေပြု WiFi adapter အလုပ်လုပ်အောင် NDISwrapper နဲ့ အပြင်းအထန်ကြိုးစားနေခဲ့ပြီး desktop window တွေကို Compiz နဲ့ လှုပ်ရှားမီးတောက်သလို လုပ်နေခဲ့တယ်။ code ကတစ်ဆင့် ရှာဖွေတွေ့ရှိမှုဆိုတဲ့ အဲဒီပုံစံက အထက်တန်းကျောင်းကနေ နောက်ပိုင်းအထိ ဆက်လက်ရှိနေခဲ့ပြီး ဒီနေ့ရှိတဲ့ ကျွန်တော့်အင်ဂျင်နီယာ စိတ်ဝင်စားမှုကို ဖြစ်စေခဲ့တယ်။

အရင်အလုပ်မှာ ကျွန်တော်က backend အခန်းကဏ္ဍကနေ full-stack ရာထူးတစ်ခုဆီ ပြောင်းခဲ့ပေမဲ့ frontend အလုပ်နဲ့ UX design ကို မနှစ်သက်တာကို သိလာခဲ့တယ်။ backend စနစ်တွေကို ပိုနီးစပ်တဲ့ အခန်းကဏ္ဍတစ်ခုဆီ ပြန်သွားချင်ခဲ့ပြီး ပညာရေးလောကမှာ နှစ်သက်ခဲ့တဲ့ Linux ပတ်ဝန်းကျင်တွေနဲ့ ထိတွေ့လုပ်ကိုင်ရတာကိုလည်း လွမ်းနေခဲ့တယ်။ OpenAI က ကျွန်တော်ရှာနေတဲ့ အလုပ်အပြောင်းအလဲကို ပေးခဲ့သလို ထိုထက်ပိုပြီးပင် ရခဲ့တယ်။ OpenAI ရဲ့ supercomputing cluster တွေပေါ်မှာ အလုပ်လုပ်ရတာထက် ကျွန်တော်လိုချင်ခဲ့တာနဲ့ ပိုကိုက်ညီတဲ့အရာကို ရှာဖို့ ခက်မယ်။

စူးစမ်းလေ့လာရေး AI workflow တွေက မူလအားဖြင့် အရှိန်မြန်တဲ့ သဘောရှိပါတယ်။ သုတေသီတွေက arXiv က preprint တစ်စောင်ကို ယူပြီး သူတို့ရဲ့ code ကို run မယ့် platform ရဲ့ အနှောင့်အယှက်မရှိဘဲ နည်းလမ်းအသစ်တွေကို စမ်းသပ်နိုင်ချင်ကြတယ်။ ထို့အပြင် ဒီအရာတွေက အလွန်ရှုပ်ထွေးလှပြီး သုတေသီတွေက သင်္ချာပညာရှင်တွေလိုပဲ ကိုယ်ရဲ့ အသက်မွေးဝမ်းကျောင်းတစ်လျှောက် တည်ဆောက်လာတဲ့ intuition ကို အားကိုးကာ ဒီအပတ် သူတို့စိတ်ဝင်စားမိတဲ့ မည်သည့်ပြဿနာကိုမဆို ဖြေရှင်းဖို့ အဖြေတစ်ခုကို ဒီဇိုင်းဆွဲကြတယ်။ ဒီ runtime တွေက ကမ္ဘာ့အကြီးဆုံး supercomputer တချို့ပေါ်မှာ လည်ပတ်နေတယ်ဆိုတဲ့အချက်က ရှုပ်ထွေးမှုအလွှာတစ်ခု ထပ်ပေါင်းပေးပြီး အဲဒီ နောက်ဆုံးမတိုင်မီ အလွှာကို ကိုင်တွယ်တာက ကျွန်တော်တို့အဖွဲ့ ပါဝင်တဲ့နေရာပါ။ သုတေသနတိုးတက်မှုကို တားဆီးမသွားခင် သုတေသနလိုအပ်ချက်တွေကို ကြိုတင်ခန့်မှန်း ဖြေရှင်းဖို့ လုပ်ကြပြီး မဖြစ်မနေလာတဲ့အခါ သုတေသနအဖွဲ့တွေနဲ့ ပူးပေါင်းကာ bottleneck တွေကို ခွဲခြားသတ်မှတ်ပြီး workaround တွေကို အမြန်ဆုံး အကောင်အထည်ဖော်ပါတယ်။

ကျွန်တော်တို့ လုပ်ကိုင်နေတဲ့ အရွယ်အစားပမာဏက တကယ်ကို အံ့ဩဖို့ကောင်းပါတယ်။ Third-party hardware vendor တွေက သူတို့ အရင်က မမြင်ဖူးသေးတဲ့ ပြဿနာတွေကို ကျွန်တော်တို့ ကြုံတွေ့နေတယ်လို့ ပုံမှန် ပြောပြတတ်ကြတယ်။ အများအားဖြင့်တော့ သူတို့ရဲ့ အခြားဖောက်သည်တွေထက် hardware ပိုများများကို တစ်ဆက်တစ်စပ်တည်း supercomputer တစ်လုံးထဲ ထည့်သွင်းထားတာကြောင့်ပဲ ဖြစ်တတ်ပေမဲ့ တခါတရံမှာ ကျွန်တော်တို့ရဲ့ performance မျှော်မှန်းချက်တွေကြောင့်လည်း ဖြစ်တတ်ပါတယ်။ မော်ဒယ်လေ့ကျင့်ရေး နည်းလမ်းအများစုရဲ့ synchronized သဘောသဘာဝကြောင့် cluster တစ်ခုလုံးက အနှေးဆုံး ဆုံမှတ်ရဲ့ အမြန်နှုန်းနဲ့ ထိရောက်စွာ လည်ပတ်သလို ဖြစ်စေပါတယ်။

ကျွန်တော်တို့ရဲ့ အထင်ရှားဆုံး မော်ဒယ်တွေကို ဒေါ်လာဘီလီယံချီ တန်ဖိုးရှိတဲ့ supercomputer တွေပေါ်မှာ လေ့ကျင့်ထားတာကြောင့် တခြားသူအများစု လျစ်လျူရှုမယ့် performance ကျဆင်းမှုတွေကို ကျွန်တော်တို့ လိုက်လံဖြေရှင်းရတတ်တယ်။ mainline kernel ထဲကို စာကြောင်းတစ်ကြောင်းပြောင်းလဲမှုတစ်ခု ဝင်သွားတာကို မြင်ရတာ စိတ်လှုပ်ရှားစရာကောင်းပြီး အဲဒါက ကျွန်တော်တို့ fleet တစ်လျှောက် တစ်ပတ်ကို compute အချိန် ~6 ရက် သက်သာစေမယ်ဆိုတာ သိရတယ်။ ဒါမှမဟုတ် driver release အသစ်တစ်ခုရဲ့ line item တစ်ခုကို မြင်ရင်း အခု upstream ထည့်သွင်းပြီးသား fix ဖြစ်လာစေခဲ့တာက ကျွန်တော်တို့ ရှာဖွေတွေ့ရှိမှုတစ်ခု ဖြစ်ခဲ့တယ်ဆိုတာ သိရတာလည်း အလွန်စိတ်လှုပ်ရှားစရာပါ။

ကျွန်တော့်ရဲ့ နေ့စဉ်အလုပ်တွေက ယေဘုယျအားဖြင့် code ရေးတာ၊ ပြဿနာတွေ စုံစမ်းစစ်ဆေးတာနဲ့ အစည်းအဝေးတက်တာတို့ကို ပေါင်းစပ်ထားတာပါ။ အစည်းအဝေးတွေက အင်္ဂါနေ့တွေကို အများအားဖြင့် အုပ်စိုးထားတတ်ပြီး (ကံကောင်းစွာနဲ့ အများအားဖြင့် အင်္ဂါနေ့တစ်နေ့တည်း) ကျန်တဲ့အပတ်ရက်တွေကို debugging နဲ့ coding ကြား ခွဲဝေထားတယ်။ သတ်မှတ်တွေ့ရှိတဲ့ ပြဿနာတွေက ယေဘုယျအားဖြင့် coding အလုပ်အဖြစ် ပြောင်းသွားတတ်တယ်။ ဥပမာ design doc ရေးတာ၊ PR branch တစ်ခုပေါ်ကို အမြန် hotfix တင်တာ ဒါမှမဟုတ် မှားယွင်းတဲ့ hardware တွေကို cluster ထဲကနေ ဖယ်ထားနိုင်ဖို့ passive health check logic ထည့်တာမျိုးပါ။

ပြဿနာတွေထဲကို တူးဖော်ရတာမှာ စုံထောက်ဆန်တဲ့ အလုပ်အနည်းငယ် လိုအပ်တယ်။ သုတေသနဘက်က သက်ရောက်မှုက မရှင်းမလင်း (“ကျွန်တော့်အလုပ်က မနေ့ကထက် နှေးသွားသလိုပဲ”) ကနေ စိုးရိမ်ဖွယ်ကောင်းလောက်အောင် တိကျတဲ့ (“Ethernet NIC ပေါ်ကနေ 30Gbps ကျော် တင်လိုက်ရင် kernel panic ဖြစ်စေတာ ထင်တယ်?”) အထိ ကွာခြားတတ်တယ်။ ဒီအရောအနှောက လူများအတွက်လည်း ရင်းနှီးနေမယ်ထင်ပါတယ်။ မျှော်လင့်ထားသလို သွားတဲ့နေ့တွေမှာ ထိရောက်ပြီး မျှော်လင့်ထားတာ ပျက်သွားချိန်မှာတော့ အသစ်တစ်ခုကို သင်ယူခွင့်ရလို့ စိတ်လှုပ်ရှားစရာ ဖြစ်တတ်ပါတယ်။

ကျွန်တော်က အလုပ်အတွက် လုပ်စရာ တစ်ခုခုကို စိတ်ထဲထိပ်ဆုံးမှာ မထားဘဲ အလုပ်လာတာ ရှားတယ်။ ပြီးတော့ အလုပ်တစ်ခုကို အချိန်မီ ပြီးမြောက်စေခြင်းက အကျိုးရှိစေမယ့် သီးခြားအဖွဲ့၊ ပရောဂျက်နဲ့ သုတေသီတွေကိုလည်း ယေဘုယျအားဖြင့် သိထားတယ်။ OpenAI က ကျွန်တော် အလုပ်လုပ်ဖူးသမျှထဲမှာ အကြီးဆုံး အလုပ်ရှင်ဖြစ်ပြီး ကျွန်တော့်အလုပ်ရဲ့ အကျိုးသက်ရောက်မှုကို ချက်ချင်း သဘောပေါက်နိုင်ခြင်းက နေ့စဉ်လှုံ့ဆော်မှုအတွက် အလွန်အရေးကြီးတယ်။ ထို့အပြင် စနစ်တွေရဲ့ အသေးစိတ်အချက်အလက်တွေကို ရှာဖွေတွေ့ရှိရတာကိုလည်း ကျွန်တော် အလွန်နှစ်သက်တယ်။ OpenAI က backend စနစ်တွေအတွက် ကျွန်တော် အလုပ်လုပ်ဖူးတဲ့ ပထမဆုံး အလုပ်ရှင် မဟုတ်ပေမဲ့ HPC နယ်ပယ်မှာ အလုပ်လုပ်ရတာကတော့ ပထမဆုံးအကြိမ်ပါ။

ကျွန်တော်တို့ လုပ်ကိုင်ရတဲ့ နည်းပညာတွေက များသောအားဖြင့် ဒီနယ်ပယ်အတွက် သီးသန့်ဖြစ်တဲ့ performance စိုးရိမ်မှုတွေကြောင့်သာ ရှိနေတတ်တယ်။ အရင်အလုပ်ရှင်တွေမှာ ကျွန်တော်တို့ hardware ရဲ့ physical topology ကို စိုးရိမ်ဖို့ မလိုခဲ့ဘူး။ ဥပမာ communication က NUMA domain တူတူအတွင်းမှာ ဖြစ်နေတာကို သေချာစေဖို့၊ GPU က Nvidia ရဲ့ GPUDirect မှတစ်ဆင့် အနီးတည်ရှိတဲ့ NVME သို့မဟုတ် InfiniBand device ကို အသုံးပြုနေတာကို သေချာစေဖို့၊ သို့မဟုတ် system process တွေကို သုတေသန runtime တွေနဲ့ noisy neighbor conflict မဖြစ်စေဖို့ သီးသန့် CPU တွေမှာ pinned လုပ်ထားတာမျိုးပါ။ OpenAI က တခြားနေရာတွေမှာ လျစ်လျူရှုထားတဲ့ ကွန်ပျူတာနည်းပညာ အပိုင်းများကို နက်နက်ရှိုင်းရှိုင်း လေ့လာနိုင်မယ့် အခွင့်အရေးကို ပေးတဲ့အတွက် ကျွန်တော့်ကို လက်ရှိလုပ်ငန်းပေါ် စိတ်ဝင်စားမှု ရှိနေစေပါတယ်။

ကျွန်တော်တို့ရဲ့ သုတေသနအဖွဲ့တွေက သူတို့ရဲ့ မော်ဒယ်တွေကို ပိုကောင်းအောင်လုပ်ရာမှာ တိုးတက်မှုရှိလာတာကို ကြည့်ရတာထက် လှုံ့ဆော်မှုပေးတာ မရှိသလောက်ပါပဲ။ အဖွဲ့အများအပြားက Slack bot တွေ ဒါမှမဟုတ် ဖွံ့ဖြိုးဆဲ မော်ဒယ်တွေကို အပြန်အလှန်အသုံးပြုပြီး စမ်းသပ်နိုင်မယ့် ရိုးရှင်းတဲ့ playground တွေကို ပြုလုပ်ထားတာကြောင့် လေ့ကျင့်မှု ဆက်လက်လုပ်နေစဉ်အတွင်း မော်ဒယ်တွေ တိုးတက်လာပုံကို မျက်မြင်ကြည့်နိုင်ပါတယ်!

ကျွန်တော်ကလည်း ကျွန်တော်တို့ရဲ့ Slack channel မျိုးစုံထဲက လှုံ့ဆော်ပေးတဲ့ သို့မဟုတ် စိတ်အားတက်ကြွစေတဲ့ အကြောင်းအရာတွေကို မှတ်သားဖို့ လူကြိုက်များတဲ့ :meow_party: Slackmoji ကို သုံးပါတယ်။ 2020 ခုနှစ် အလယ်ပိုင်းမှာ ကျွန်တော် ဝင်ရောက်ပြီးကတည်းက :meow_party: tag လုပ်ထားတဲ့ post ပေါင်း 400 ကျော် ရှိပြီး တစ်ပတ်လျှင် ပျမ်းမျှ 4 ခုနီးပါး ရှိပါတယ်!