မျိုးစုံသော မော်ဒယ်များကို ချိတ်ဆက်ပေးသည့် LLM အခြေခံအဆောက်အအုံ- API gateway၊ စောင့်ကြည့်စစ်ဆေးနိုင်စွမ်း၊ စမ်းသပ်မှုခြေရာခံခြင်းတို့ကို မည်သို့တည်ဆောက်မည်နည်း (LiteLLM၊ MLflow)

ညဉ့်နက် ၂ နာရီ၊ AI Customer Service (AI ဖောက်သည်ဝန်ဆောင်မှု) လုပ်နေတဲ့ Startup အဖွဲ့တစ်ဖွဲ့က သတိပေးချက် (Alert) လက်ခံရရှိလိုက်ပါတယ်။ တုံ့ပြန်ချိန် (Response Time) နှေးကွေးလာပြီး အမှားနှုန်း (Error Rate) က အလွန်အမင်း မြင့်တက်လာပါတယ်။ အင်ဂျင်နီယာက Backend ကို ဖွင့်ကြည့်ပေမယ့် ဘယ်နေရာမှာ ပြဿနာရှိနေလဲဆိုတာ မပြောပြနိုင်ပါဘူး။ ဘာကြောင့်လဲဆိုတော့ သူတို့က Model API သုံးခုကို တစ်ပြိုင်နက် ချိတ်ဆက်ထားပြီး တချို့က A Supplier ဆီသွား၊ တချို့က B ဆီသွား, ကုဒ်တွေထဲမှာ Switch လုပ်ဖို့ if-else တွေနဲ့ ပြည့်နေလို့ပါပဲ။ "အခု ဘယ်သူက နှေးနေလဲ၊ ဘယ်သူက Error တက်နေလဲ၊ ဒီလ ဘယ်လောက်ကုန်သွားပြီလဲ" ဆိုတာ တစ်ချက်ကြည့်ရုံနဲ့ သိနိုင်တဲ့ နေရာဆိုလို့ ဘယ်နေရာမှ မရှိပါဘူး။ သူတို့က ကုဒ်မရေးတတ်လို့ မဟုတ်ပါဘူး၊ အခြေခံအဆောက်အအုံ (Infrastructure) တစ်ထပ်စာ လိုအပ်နေလို့ပါ။

ဒါက ၂၀၂६ ပထမနှစ်ဝက်မှာ AI အဖွဲ့အရာတော်တော်များများ ရင်ဆိုင်နေရတဲ့ အခက်အခဲပါပဲ။ Model တွေ ကိုယ်တိုင်က သုံးရတာ မခက်ခဲပါဘူး၊ ခက်တာက Model အများကြီးကို တစ်ပြိုင်နက်သုံးဖို့နဲ့ Production Environment တင်တဲ့အခါ အောက်ခြေက "ချိတ်ဆက်မှု၊ စောင့်ကြည့်လေ့လာမှု၊ စမ်းသပ်မှု" ဆိုတဲ့ အင်ဂျင်နီယာပိုင်းဆိုင်ရာ တစ်စုံလုံးပါပဲ။ ဒီဆောင်းပါးမှာ ဒီအခြေခံအဆောက်အအုံ အပိုင်းသုံးပိုင်းကို ရှင်းရှင်းလင်းလင်း ခွဲထုတ်ပြီး ဆွေးနွေးပေးသွားမှာ ဖြစ်ပါတယ်။

ဒီကိစ္စ ဘာကြောင့် အခု အရေးကြီးလာတာလဲ

လွန်ခဲ့တဲ့ နှစ်နှစ်ကဆိုရင် AI အပလီကေးရှင်း အများစုက Model တစ်ခုတည်းကိုပဲ ချိတ်ဆက်ပြီး API တစ်ခုတည်းနဲ့ အလုပ်စကြပါတယ်။ ဒါပေမဲ့ ဒီခြောက်လအတွင်း ကျွန်တော်မြင်တွေ့ခဲ့ရတဲ့ အဖွဲ့အရာတွေကတော့ "Model အများအပြား" (Multi-model) ဆီကို ချဉ်းကပ်လာကြပါပြီ - အခက်အခဲကြီးတဲ့ Reasoning (စဉ်းစားတွေးခေါ်မှု) အတွက် Flagship Model ကိုသုံးတယ်၊ အကြိမ်ရေများပြီး ရိုးရှင်းတဲ့ တာဝန်တွေအတွက် ဈေးသက်သာပြီး မြန်ဆန်တဲ့ Small Model ကိုသုံးတယ်၊ အချို့သော Scenario တွေမှာ ဒေတာလုံခြုံရေးအတွက် ကိုယ်တိုင် Host လုပ်ထားတဲ့ Open-source Model ကိုသုံးကြပါတယ်။ ဒီအကြောင်းကို Coding Agents အကြောင်း ဆောင်းပါး မှာလည်း ကျွန်တော် ဖော်ပြခဲ့ပြီးပါပြီ - Model အများအပြား ခွဲဝေသုံးစွဲခြင်းက ကုန်ကျစရိတ် သက်သာစေရေးအတွက် အဓိကသော့ချက် ဖြစ်ပါတယ်။

ဒါပေမဲ့ Model အများအပြား သုံးခြင်းက လက်တွေ့ပြဿနာ သုံးခုကို ယူဆောင်လာပါတယ်။ ပထမအချက်ကတော့ API တစ်ခုချင်းစီရဲ့ Format, Parameter, Error Handling တွေ အားလုံးမတူကြပါဘူး၊ ဒါကြောင့် သင့်ရဲ့ကုဒ်တွေဟာ Switch လုပ်တဲ့ Logic တွေနဲ့ ပြည့်နေပါလိမ့်မယ်။ ဒုတိယအချက်ကတော့ ခြုံုံငုံသုံးသပ်ချက်ကို ရှင်းရှင်းလင်းလင်း မမြင်ရပါဘူး - ဘယ် Request က နှေးလဲ၊ ဘယ်ဟာ Error တက်နေလဲ၊ Token တွေ ဘယ်မှာကုန်သွားလဲ၊ ဒီလ Bill က ဘယ်လိုထွက်လာလဲဆိုတာတွေက Supplier တစ်ခုချင်းစီရဲ့ Backend မှာ ပြန့်ကြဲနေပါတယ်။ တတိယအချက်ကတော့ "Model ပြောင်းလိုက်တာ၊ Prompt ပြောင်းလိုက်တာ ရလဒ် ပိုကောင်းသွားလား၊ ပိုဆိုးသွားလား" ဆိုတာကို သင်မသိနိုင်ပါဘူး၊ ဘာကြောင့်လဲဆိုတော့ စနစ်တကျ မှတ်တမ်းတင်ပြီး နှိုင်းယှဉ်ထားတာ မရှိလို့ပါပဲ။

ဒီပြဿနာ သုံးခုဟာ LLM Infrastructure ရဲ့ အလွှာသုံးခုနဲ့ တိုက်ရိုက်ကိုက်ညီနေပါတယ်: API Gateway (ပေါင်းစည်းချိတ်ဆက်မှု)၊ Observability (ခြုံငုံသုံးသပ်မြင်နိုင်စွမ်း)၊ Experiment Tracking (စမ်းသပ်မှု ခြေရာခံခြင်း) တို့ ဖြစ်ပါတယ်။ အဖွဲ့အစည်း အရွယ်အစား ကြီးလာတာနဲ့အမျှ ဒီအလွှာ သုံးခုစလုံးကို တစ်ချိန်ချိန်မှာ ဖြည့်ဆည်းရပါလိမ့်မယ်။

ပင်မတူးလ်များနှင့် ကွာခြားချက်များ

ဒီအလွှာ သုံးခုအလိုက် ဘာတွေကို ဖြေရှင်းပေးနေလဲနဲ့ ကိုယ်စားပြု Tools တွေက ဘာတွေလဲဆိုတာကို ခွဲခြားပြပါမယ်-

ပထမအလွှာ- API Gateway / ပေါင်းစည်းချိတ်ဆက်မှု
Model အမျိုးမျိုးကို ခေါ်ယူဖို့အတွက် 统一 (တစ်ပြေးညီ) ဖြစ်တဲ့ Interface တစ်ခုကို သုံးနိုင်စေပါတယ်။ Model တစ်ခုချင်းစီအတွက် ကုဒ်အသစ် ရေးနေစရာ မလိုတော့ပါဘူး။

• LiteLLM: ဒီအလွှာမှာ အမေးအများဆုံး Open-source ဖြေရှင်းချက် ဖြစ်ပါတယ်။ တသမတ်တည်းဖြစ်တဲ့ Format နဲ့ Model Supplier အများအပြားကို ချိတ်ဆက်ပေးနိုင်ပြီး Load Balancing လုပ်ပေးနိုင်တယ်၊ Backup သတ်မှတ်ပေးနိုင်တယ် (တစ်ခုခုပျက်သွားရင် အလိုအလျောက် ပြောင်းသွားတာ)၊ Project တစ်ခုချင်းစီရဲ့ သုံးစွဲမှုနဲ့ Budget ကို ထိန်းချုပ်ပေးနိုင်ပါတယ်။ Multi-model Shunting (မော်ဒယ်ပေါင်းစုံ ခွဲဝေသုံးစွဲခြင်း) လုပ်ချင်ရင် ဒါက အခြေခံအုတ်မြစ်ပါပဲ။

ဒုတိယအလွှာ- Observability (စောင့်ကြည့်လေ့လာနိုင်စွမ်း)
Request တစ်ခုချင်းစီမှာ ဘာတွေဖြစ်ပျက်နေလဲ - Latency (ကြန့်ကြာမှု)၊ Error၊ Token၊ ကုန်ကျစရိတ်၊ Prompt နဲ့ Response အဆင့်ဆင့်အထိ အားလုံးကို ရှင်းရှင်းလင်းလင်း မြင်တွေ့စေပါတယ်။

• Langfuse: LLM အပလီကေးရှင်းများအတွက် သီးသန့်ဒီဇိုင်းထုတ်ထားတဲ့ Observability Platform ဖြစ်ပြီး முழு (အပြည့်အစုံ) Call Chain ကို ခြေရာခံနိုင်ခြင်း၊ Prompt နဲ့ Response တွေကို မှတ်တမ်းတင်နိုင်ခြင်း၊ ကုန်ကျစရိတ် စာရင်းဇယားထုတ်ပေးနိုင်ခြင်းတို့ လုပ်ဆောင်နိုင်ပြီး ပြဿနာတက်တဲ့အခါ ဘယ်အဆင့်မှာ မှားသွားလဲဆိုတာကို အစအဆုံး လိုက်လံစစ်ဆေးနိုင်ပါတယ်။
• Helicone: Monitor လုပ်ခြင်းနဲ့ ကုန်ကျစရိတ် ခွဲခြမ်းစိတ်ဖြာခြင်းကို အဓိကထားပြီး ချိတ်ဆက်ရလွယ်ကူခြင်းကြောင့် နာမည်ကြီးပါတယ်။ "မမြင်ရတာ" ကို "မြင်ရအောင်" အမြန်လုပ်ချင်တဲ့ အဖွဲ့တွေအတွက် သင့်လျော်ပါတယ်။

တတိယအလွှာ- Experiment Tracking (စမ်းသပ်မှု ခြေရာခံခြင်း)
"ငါ ဒီတစ်ခါ ဘာတွေပြောင်းလိုက်လဲ၊ ရလဒ်က ဘယ်လိုလဲ" ဆိုတာကို အမှတ်တရနဲ့ မဆုံးဖြတ်ဘဲ စနစ်တကျ မှတ်တမ်းတင်ပေးနိုင်ပါတယ်။

• MLflow: Machine Learning နယ်ပယ်က နာမည်ကြီး Tool တစ်ခုဖြစ်ပြီး လွန်ခဲ့တဲ့ နှစ်နှစ်အတွင်း LLM နဲ့ GenAI အတွက် Support ပေးမှုကို အကြီးစား ဖြည့်တင်းခဲ့ပါတယ်။ Experiment တွေကို ခြေရာခံနိုင်ခြင်း၊ Version တွေကို စီမံခန့်ခွဲနိုင်ခြင်း၊ ရလဒ်တွေကို အကဲဖြတ်နိုင်ခြင်းတို့ လုပ်ဆောင်နိုင်ပါတယ်။ သင့်အဖွဲ့မှာ ML Background ရှိပြီးသားဆိုရင် ဒါက သဘာဝကျကျ ဆက်စပ်သွားမယ့် Tool ဖြစ်ပါတယ်။
• Weights & Biases: Experiment Tracking နဲ့ Evaluation အတွက် အဓိက ရွေးချယ်စရာတစ်ခု ဖြစ်ပြီး Visualisation (မြင်ကွင်းပေါ်တင်ပြမှု) ကောင်းမွန်တဲ့အတွက် အဖွဲ့လိုက် ပူးပေါင်းဆောင်ရွက်တဲ့အခါ ရလဒ်တွေကို မျှဝေဖို့ အလွန်အဆင်ပြေပါတယ်။

သတိပေးချင်တာကတော့ ၂၀२६ မှာ ဒီအလွှာ သုံးခုရဲ့ နယ်နိမိတ်တွေက ပိုပြီး ဝိုးတဝါ ဖြစ်လာပါပြီ - Tool တော်တော်များများက တစ်ခုနဲ့တစ်ခုရဲ့ နယ်မြေထဲကို ဝင်ရောက်လာကြပြီး Platform တစ်ခုတည်းနဲ့ Observability ရော Experiment ပါ လုပ်ဆောင်လာကြပါပြီ။ ဒါကြောင့် အမျိုးအစားခွဲခြားမှုကို အရမ်းကြီး အာရုံမစိုက်ဘဲ ကိုယ့်အဖွဲ့မှာ ဘာလိုနေလဲဆိုတာကို အရင်သိအောင် လုပ်ပါ။

လက်တွေ့ဘယ်လိုသုံးမလဲ (တဖြည်းဖြည်းချင်း တည်ဆောက်နည်း)

အဖွဲ့တိုင်းက အစပိုင်းမှာ Full Set (အစုံလိုက်) သုံးဖို့ မလိုပါဘူး။ နာကျင်မှု (Pain Point) အလိုက် တဖြည်းဖြည်းချင်း တိုးချဲ့သွားဖို့ အကြံပြုလိုပါတယ်-

1. Model တစ်ခု (သို့) နှစ်ခုပဲရှိသေးတယ်၊ Traffic က မများသေးဘူး: Infrastructure ကို အစောကြီး မစနဲ့ဦး။ လက်နဲ့လုပ်၊ ကိုယ်တိုင်မှတ်တမ်းတင်၊ လုံလောက်ရင် ရပါပြီ၊ Over-engineering (လွန်ကဲတဲ့အင်ဂျင်နီယာလုပ်ငန်း) မလုပ်ပါနဲ့။
2. Model အများအပြား ခွဲဝေသုံးဖို့ စတင်ပြီ: ဒီအချိန်မှာ API Gateway ကို စတင်သုံးပါ။ LiteLLM ကိုသုံးပြီး Model ခေါ်ယူမှုအားလုံးကို Interface တစ်ခုတည်းအောက် ပေါင်းထည့်လိုက်ပါ။ နောင် Model ပြောင်းတာ၊ Backup ထည့်တာတွေကို နေရာတိုင်းမှာ ကုဒ်လိုက်မပြင်ရဘဲ တစ်နေရာတည်းမှာပဲ ပြင်လို့ရပါပြီ။
3. Production တင်ပြီ၊ တကယ့် User တွေ စတင်သုံးလာပြီ: Observability ကို ဖြည့်စွက်ပါ။ Request တစ်ခုချင်းစီရဲ့ Latency၊ Error၊ ကုန်ကျစရိတ်တွေကို မှတ်တမ်းတင်ထားပါ၊ ပြဿနာတက်တဲ့အခါ ခြေရာခံဖို့ ရှိနေပါလိမ့်မယ်။ ညဉ့်နက် ၂ နာရီမှာ အခေါ်ခံရတဲ့အခါ ဒီအလွှာအတွက် ကျေးဇူးတင်မိပါလိမ့်မယ်။
4. စွမ်းဆောင်ရည်ကို သေချာ Tuning လုပ်တော့မယ်: Experiment Tracking ကို ဖြည့်စွက်ပါ။ Prompt ပြောင်းတိုင်း၊ Model ပြောင်းတိုင်း၊ Parameter ချိန်တိုင်းမှာ စနစ်တကျ မှတ်တမ်းတင်ပြီး နှိုင်းယှဉ်ပါ။ MLflow (သို့) Weights & Biases ကိုသုံးပြီး "ခံစားချက်နဲ့" ဆိုတာကို "ဒေတာအချက်အလက်နဲ့" ဆိုတဲ့ဘက်ကို ပြောင်းလိုက်ပါ။
5. အလွှာ သုံးခုကို ပြန်ပြီး ချိတ်ဆက်မယ်: ရင့်ကျက်တဲ့ အဆင့်မှာ Gateway ရဲ့ Call တွေမှာ Observability ပါ အလိုအလျောက် ပါလာအောင် လုပ်ပါ၊ Experiment ရလဒ်တွေကို Online Performance နဲ့ နှိုင်းယှဉ်လို့ရအောင် လုပ်ပြီး Closed-loop တစ်ခု တည်ဆောက်ပါ။

အဖြစ်များသော အမှားများနှင့် အကြံပြုချက်များ

• Over-engineering က အကြီးမားဆုံး အလေအလွင့်ပါပဲ: Product ရဲ့ Direction ကို စမ်းသပ်ဆဲဖြစ်ပြီး နေ့စဉ် Request က နှစ်လုံးပေါက်ပဲ ရှိသေးချိန်မှာ Infrastructure အစုံလိုက် အမြန်လုပ်တာက ကိုယ့်ဘာသာ အလုပ်ရှာတာပါပဲ။ Infrastructure ဆိုတာ နာကျင်မှုနဲ့အတူ ကြီးထွားလာရတာပါ၊ စောလေကောင်းလေ မဟုတ်ပါဘူး။
• Gateway က Single Point of Failure ဖြစ်သွားနိုင်တယ်: Traffic အားလုံးက ဒီအလွှာကို ဖြတ်ရတာကြောင့် ဒါပျက်ရင် အားလုံးပျက်ပါမယ်။ ကိုယ်တိုင် Host လုပ်မယ်ဆိုရင် High Availability ကို သေချာလုပ်ထားပါ၊ အရေးကြီးတဲ့ အသက်သွေးကြောကို Backup မပါတဲ့ Node တစ်ခုတည်းပေါ်မှာ မတင်ထားပါနဲ့။
• Observability ဒေတာတွေထဲမှာ ကိုယ်ရေးကိုယ်တာ အချက်အလက်တွေ ပါနေတတ်တယ်: Prompt နဲ့ Response အပြည့်အစုံကို မှတ်တမ်းတင်တဲ့အခါ User ရဲ့ Sensitive Data တွေပါ အတူတူ သိမ်းမိသွားနိုင်ပါတယ်။ မမှတ်တမ်းတင်ခင် Mask လုပ်သင့်လား မလုပ်သင့်လား သေချာစဉ်းစားပါ၊ အထူးသဖြင့် စည်းမျဉ်းစည်းကမ်း တင်းကျပ်တဲ့ လုပ်ငန်းတွေမှာ ပိုအရေးကြီးပါတယ်။
• ကုန်ကျစရိတ် (Cost) ကို စောစောစီးစီး စောင့်ကြည့်ပါ: Model အများအပြားသုံးတဲ့အခါ အလွယ်ဆုံး ထိန်းမရဖြစ်သွားတာက Bill ပါပဲ။ Bill ရောက်လာမှ ငွေတွေ အများကြီး ကုန်သွားမှန်း သိရရင် နောက်ကျသွားပါပြီ၊ ပထမနေ့ကတည်းက ကုန်ကျစရိတ်ကို Observability ထဲ ထည့်သွင်းပါ။
• "Big Tech ရဲ့ ML Tools တွေ" ကို ကြောက်မနေပါနဲ့: MLflow လို Tools တွေက နာမည်ကြီးပြီး လေးလံပုံပေါ်ပေမယ့် သင်လိုအပ်တဲ့ အစိတ်အပိုင်းလေးကိုပဲ သုံးလို့ရပါတယ်။ တစ်ခုလုံးကို အလကားနေရင်း ဆွဲထည့်စရာ မလိုပါဘူး။

TheAIacademy အမြင်

ဒီအပိုင်းက ဆွဲဆောင်မှုမရှိပါဘူး၊ တောက်ပြောင်တဲ့ Demo လည်း မရှိပါဘူး။ ဒါပေမဲ့ သင့်ရဲ့ AI Product တစ်ခု Production Environment မှာ တည်ငြိမ်စွာ အသက်ရှင်ရပ်တည်နိုင်မလားဆိုတာကို ဒါက ဆုံးဖြတ်ပေးပါတယ်။ Model နဲ့ Prompt တွေမှာ အပင်ပန်းခံကြပေမယ့် "အွန်လိုင်းတင်ပြီးမှ ဘာကြောင့်ဖြစ်မှန်းမသိဖြစ်တာ၊ Bill ရောက်လာမှ Budget ကုန်သွားမှန်းသိရတာ" လိုမျိုး Infrastructure ရဲ့ အပေါက်ပြဲတွေကြောင့် လဲကျသွားတဲ့ အဖွဲ့အရာတွေအများကြီးကို ကျွန်တော် မြင်ဖူးပါတယ်။

မှတ်ချက် - Model က အင်ဂျင်ဖြစ်ပြီး၊ Infrastructure က Dashboard နဲ့ ဆီတိုင်ကီဖြစ်ပါတယ် - ဒါမပါဘဲနဲ့ ဘယ်လောက်ပဲ မြန်မြန်မောင်းနေပါစေ၊ ဆီဘလောက်ကျန်သေးလဲ မသိဘဲ ပြေးလွှားနေတာနဲ့ အတူတူပါပဲ။

Taiwan ဖတ်ရှုသူတွေအတွက် လက်တွေ့ကျတဲ့ အကြံပြုချက် - တစ်ခါတည်းနဲ့ အစုံလိုက် မလုပ်ပါနဲ့၊ နာကျင်မှုအလိုက် တဖြည်းဖြည်းချင်း ဖြည့်ပါ။ သင်ဟာ တစ်ဦးတည်း (သို့) အဖွဲ့ငယ်လေးနဲ့ စမ်းသပ်နေတယ်ဆိုရင် ဒီအလွှာ သုံးခုစလုံးကို ခဏမထိနဲ့ဦး။ Model အများအပြားကို တစ်ပြိုင်နက် သုံးရတော့မယ်ဆိုရင်တော့ ပထမအခြေအနေမှာ LiteLLM လို Gateway မျိုးကို အရင်စတင်သုံးပါ။ ဒါက နောင် Model ပြောင်းဖို့နဲ့ ကုန်ကျစရိတ် ထိန်းချုပ်ဖို့အတွက် အများကြီး ပိုလွယ်ကူစေပါလိမ့်မယ်။ User တွေ စတင်ရှိလာပြီး ညဉ့်နက်ပိုင်း ပြဿနာတက်မှာကို စိုးရိမ်လာပြီဆိုမှ Observability ကို ဖြည့်စွက်ပါ။ ဒီ Infrastructure တွေဟာ အာမခံကြေးလိုပါပဲ - သာမန်အချိန်မှာ မသိသာပေမဲ့ ပြဿနာတက်တဲ့အခါ သင့်အသက်ကို ကယ်တင်ပေးပါလိမ့်မယ်။ ဒီ Model တွေကို Coding နဲ့ Review လုပ်တဲ့ Scenario တွေမှာ ဘယ်လိုသုံးမလဲဆိုတာကို သိချင်ရင် Coding Agents ခြုံငုံသုံးသပ်ချက် လက်စွဲ နဲ့ AI ကုဒ်စစ်ဆေးရေး Tools လမ်းညွှန် တို့ကို ပြန်လည်ဖတ်ရှုနိုင်ပါတယ်။

ကိုးကားချက်များ

• LiteLLM တရားဝင် စာရွက်စာတမ်း: https://docs.litellm.ai
• MLflow တရားဝင် ဝက်ဘ်ဆိုက်: https://mlflow.org

ဤဆောင်းပါးသည် Tool အမျိုးအစားများနှင့် Architecture တည်ဆောက်ပုံများကို စုစည်းဖော်ပြထားခြင်း ဖြစ်ပါသည်။ Tool များ၏ လုပ်ဆောင်ချက်များ အမြန်နှုန်းဖြင့် ပြောင်းလဲနေသဖြင့် လက်တွေ့လုပ်ဆောင်နိုင်စွမ်းနှင့် ဈေးနှုန်းများကို တရားဝင် နောက်ဆုံးထုတ်ပြန်ချက်များတွင် အတည်ပြုပါ။