Thuta Learning
Local AI / Local LLM
AdvancedAIbeginner

Local AI လုံခြုံရေး

ဒီခန်းပြီးရင် ဘာတတ်သွားမလဲ

  • Local AI လုံခြုံရေး concept ကို နားလည်ရှင်းပြနိုင်ရန်
  • Diagram ကို ဖတ်ပြီး architecture ထဲမှာ data/request ဘယ်လိုစီးဆင်းသလဲ ခြေရာခံနိုင်ရန်
  • ကိုယ့် hardware/use case အတွက် ဘယ်လို ရွေးချယ်သင့်သလဲ ဆုံးဖြတ်နိုင်ရန်

နားလည်ထားရမယ့် အချက်

'Local' ဆိုတာက inference ဘယ်မှာဖြစ်လဲဆိုတာကို ဖော်ပြတာပါ၊ ပတ်ဝန်းကျင် system တစ်ခုလုံး ဘယ်လောက်ဘေးကင်းလဲဆိုတာ မဟုတ်ပါ။ Local LLM server တစ်ခုက network socket တစ်ခုပေါ်မှာ ဆက်တိုက် listen လုပ်နေတုန်းပါပဲ၊ ဒီ socket မှာ အဓိပ္ပာယ်ရှိရှိ ကွဲပြားတဲ့ exposure level သုံးခုရှိပါတယ်။

Exposure Levelဆိုလိုသည်
localhost (127.0.0.1)Bind လုပ်ထားရင် စက်တူတူပေါ်က process တွေပဲ ဆက်သွယ်နိုင်ပါတယ်။
LAN (0.0.0.0, private network)Bind လုပ်ရင် Wi-Fi ဒါမှမဟုတ် switch တူတူပေါ်က device မည်သည့်ဟာမဆို ဆက်သွယ်နိုင်ပါတယ် — homelab အတွက် အဆင်ပြေပေမယ့် ယခုအခါ ဒီ network ပေါ်က တစ်ယောက်ယောက်စီဟာ potential client ဖြစ်လာပါတယ်။
Public internet (forward/tunnel)ဘယ်နေရာက ဘယ်သူမဆို ဆက်သွယ်နိုင်ပြီး၊ internet-facing service တခြားတွေလိုပဲ defense တွေ လိုအပ်ပါတယ် — port/source ကန့်သတ်တဲ့ firewall rule၊ authentication (request တိုင်းမှာ စစ်ဆေးတဲ့), TLS, ပြီးတော့ model server ရဲ့ built-in protection (အများအားဖြင့် အနည်းငယ်ပဲ) ကိုမှီခိုမနေဘဲ ဒီအလုပ်တွေအားလုံးလုပ်ပေးမယ့် reverse proxy တစ်ခု။

Exposure ဟာ axis တစ်ခုတည်းသာ ဖြစ်ပါတယ်။ System ထဲ ဖြတ်သန်းနေတဲ့ content ကလည်း နောက်တစ်ခုသော security dimension ပါ။

  • Untrusted source တွေက prompt (public form တစ်ခု၊ scrape လုပ်ထားတဲ့ document၊ တခြားသူ ရေးထားတဲ့ RAG chunk) တွေမှာ model ကို manipulate လုပ်ဖို့ ရည်ရွယ်ထားတဲ့ instruction ပါနိုင်ပါတယ် — tool-calling ability ရှိတဲ့ ဘာမဆို prompt က ဘာပြောနေပါစေ ၎င်းနဲ့ သီးခြားဖြစ်တဲ့ permission boundary လိုအပ်ပါတယ်
  • Sensitive files တွေက အကြောင်းမရှိဘဲ agent တစ်ခု ဖတ်နိုင်တဲ့ directory ထဲ ဘယ်တော့မှ မရှိသင့်ပါဘူး
  • Request log တွေမှာ prompt နဲ့ response အပြည့်အစုံ verbatim ပါနေလေ့ရှိပါတယ်၊ log တွေကိုယ်တိုင် debugging convenience တစ်ခုတည်းမက sensitive-data surface တစ်ခုဖြစ်လာစေပါတယ်
  • Model file ကိုယ်တိုင်ကလည်း supply-chain risk တစ်ခုပါ — verify မလုပ်ရသေးတဲ့ source တစ်ခုကနေ weight တွေ download ဆွဲတာက verify မလုပ်ရသေးတဲ့ binary တစ်ခု run သလိုပါပဲ

ဒါတွေအားလုံး Automatic မဟုတ်ပါ

Model က သင့် hardware ပေါ်မှာ run နေလို့ ဒါတွေအားလုံး automatic ဖြစ်လာတာ မဟုတ်ပါဘူး။

text
EXPOSURE LEVELS: SECURITY REQUIREMENT INCREASES
-----------------------------------------------
EXPOSURE LEVELS: SECURITY REQUIREMENT INCREASES
---------------------------------------------------

  localhost only        LAN                public internet
  (127.0.0.1)            (0.0.0.0, private)  (forwarded/tunneled)

    [you]                [you] [device2]     [anyone, anywhere]
      |                    |      |                  |
      v                    v      v                  v
    server               server                    server
    no auth needed       auth recommended          auth REQUIRED
    no TLS needed        TLS recommended           TLS REQUIRED
                                                    firewall + reverse
                                                    proxy + rate limits

  security requirement:  low ---------------------------> high

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

llama.cpp ရဲ့ server, text-generation-webui, Ollama ရဲ့ OLLAMA_HOST လို local inference server အများစုမှာ --host flag ဟာ server ဘယ်လောက် exposed ဖြစ်မလဲဆိုတာကို အဓိက ဆုံးဖြတ်ပေးတဲ့ setting တစ်ခုပါ၊ ရလဒ်ကို သတိမထားမိဘဲ ပြောင်းလိုက်ဖို့ လွယ်ကူပါတယ်။

Flagသက်ရောက်မှု
--host 127.0.0.1Server ရဲ့ socket ကို bind လုပ်ပေးလို့ စက်တူတူပေါ်က process တွေပဲ connection ဖွင့်နိုင်ပါတယ် — Wi-Fi တူတူပေါ်ဖြစ်ရင်တောင် network ပေါ်က ဘာမှ ဆက်သွယ်လို့ မရပါဘူး။
--host 0.0.0.0စက်ရဲ့ network interface အားလုံးကို bind လုပ်ပေးလို့ LAN ပေါ်က device တခြားက reach လုပ်နိုင်ပါတယ်၊ router က port ကို forward လုပ်ရင် public internet ကနေတောင် reach လုပ်နိုင်ပါတယ်။

Default Authentication လုံးဝ မရှိပါ

llama.cpp ရဲ့ built-in server ဒါမှမဟုတ် Ollama ရဲ့ default setup ဟာ authentication ကို default အနေနဲ့ ဖွင့်မထားပါဘူး၊ ဒါကြောင့် reverse proxy မရှိဘဲ 0.0.0.0 bind လုပ်တာက IP နဲ့ port ကို reach လုပ်နိုင်သူတိုင်း inference request ပို့နိုင်၊ server-side embed လုပ်ထားတဲ့ system prompt ဖတ်နိုင်၊ သင့် GPU ကို consume လုပ်နိုင်တယ်လို့ ဆိုလိုပါတယ်။

ဖော်ပြထားတဲ့ firewall rule pattern က LAN exposure ကို subnet တစ်ခုအတွက်ပဲ ကျဉ်းအောင် partial mitigation အနေနဲ့ လုပ်ပေးပေမယ့်၊ authentication နဲ့ TLS ကို တကယ်ထည့်ပေးတဲ့ reverse proxy ကမှ real fix ပါ၊ firewall rule တစ်ခုတည်းတော့ မဟုတ်ပါဘူး — firewall တွေက port ကို ဘယ်သူ reach လုပ်နိုင်လဲဆိုတာကို control လုပ်တာပါ၊ reach လုပ်ပြီးရင် ဘယ်သူ authorized ဖြစ်လဲဆိုတာကို control မလုပ်ပါဘူး။

Local ဆိုတာက လုံခြုံတယ်လို့ မဆိုလိုပါ

Model ကို ကိုယ်ပိုင် hardware ပေါ်မှာ run တာက computation ဘယ်မှာဖြစ်လဲဆိုတာကို control လုပ်ပေးတာပါ — authentication ကို automatic ထည့်ပေးတာ၊ network traffic ကို encrypt လုပ်ပေးတာ၊ model file ဘယ်ကလာလဲ verify လုပ်ပေးတာ၊ ချိတ်ဆက်ထားတဲ့ agent တစ်ခုက ဘာလုပ်နိုင်လဲ ကန့်သတ်ပေးတာ ဒါတွေကို automatic မလုပ်ပေးပါဘူး။ ဒါတွေအားလုံးက သင် ရှင်းရှင်းလင်းလင်း ဆုံးဖြတ်ရဦးမယ့် decision တွေပါ၊ cloud provider မပါဝင်လို့ default အနေနဲ့ ဖြစ်လာတာ မဟုတ်ပါဘူး။

မသိသေးသော Model တစ်ခု Run မခင်

အတူတူ စမ်းရေးကြည့်မယ်

bash
# Bind only to localhost -- reachable only from this machine
python -m llama_cpp.server --host 127.0.0.1 --port 8080 --model ./model.gguf

# Bind to all interfaces -- reachable from any device on the LAN
# (or the public internet, if the port is forwarded on your router)
python -m llama_cpp.server --host 0.0.0.0 --port 8080 --model ./model.gguf

# Safer LAN exposure: bind to the LAN interface explicitly, then put a
# reverse proxy in front for TLS + auth, and firewall the raw port
python -m llama_cpp.server --host 192.168.1.50 --port 8080 --model ./model.gguf
sudo ufw allow from 192.168.1.0/24 to any port 8080 proto tcp
sudo ufw deny 8080
You should see
Command နှစ်ခုစလုံးက ချက်ချင်း start ပြီး listen နေတဲ့ address နှင့်အတူ startup banner ကို print ပေးပါတယ် — ပြသဖို့ ဂဏန်း benchmark output ဘာမှ မရှိပါဘူး။ လက်တွေ့ ကွာခြားချက်ကို တခြား စက်ကနေမှသာ သိနိုင်ပါတယ် — 127.0.0.1 bind နဲ့ဆိုရင် network ပေါ်က တခြား device တစ်ခုကနေ curl request ပို့ရင် connect မရပါဘူး (connection refused)၊ OS က စက်ပြင်ပက incoming connection ကို ဒီ socket ပေါ်မှာ လက်မခံလို့ပါ။ 0.0.0.0 bind နဲ့ဆိုရင်တော့ LAN ပေါ်က device တခြားကနေ curl request တူတူပဲ ပို့ရင် အောင်မြင်ပြီး model ဆီရောက်ပါတယ်၊ socket က loopback interface ချည်းသာမက စက်ရဲ့ real network interface ပေါ်မှာ listen နေလို့ပါ။ ufw rule တွေက ဒါကို subnet အတိအကျတစ်ခုအတွက်ပဲ ထပ်ကျဉ်းပေးပေမယ့် authentication ထပ်ထည့်မပေးပါဘူး — allowed subnet ထဲက device တစ်ခုက raw inference API ကို authentication မလိုဘဲ access ရနေဆဲပါ။

၅ မိနစ် စမ်းကြည့်

သင်ထိန်းချုပ်ထားတဲ့ စက်တစ်လုံးမှာ 127.0.0.1 ကို bind လုပ်ထားတဲ့ local inference server တစ်ခု start လုပ်ပြီး network တူတူပေါ်က device ဒုတိယတစ်ခုကနေ curl နဲ့ ဆက်သွယ်ကြည့်ပါ — connection refused ဖြစ်တယ်ဆိုတာ သေချာအောင်လုပ်ပါ။ ပြီးရင် (ရှင်းလင်းတဲ့အတွက် 0.0.0.0 မဟုတ်ဘဲ) သင့်စက်ရဲ့ LAN IP ကို bind လုပ်ပြီး ပြန် start လုပ်ကာ device ဒုတိယတစ်ခုကနေ curl ကို ထပ်လုပ်ကြည့်ပါ။ ကွာခြားချက်ကို မှတ်သားပြီး၊ သင့် subnet ကိုပဲ ခွင့်ပြုတဲ့ firewall rule တစ်ခု run နေဆဲအခြေအနေမှာ ထပ်ထည့်ပါ။

သတိလေးတစ်ချက်

'ဖုန်းကနေ test လုပ်ဖို့ပဲ' ဆိုပြီး 0.0.0.0 ကို bind လုပ်ပြီး ပိတ်ဖို့ မေ့သွားခြင်း — local model server အများစုမှာ default authentication မရှိတာကြောင့် ဒါက model ကို LAN တစ်ခုလုံးအတွက် တိတ်တဆိတ် ဖွင့်ထားသလို ဖြစ်သွားပါတယ်။

Firewall rule တစ်ခုကို authentication နဲ့ တူညီတယ်လို့ ယူဆခြင်း — firewall က request တစ်ခု ဘယ် network ကနေ လာနိုင်လဲဆိုတာကို control လုပ်တာပါ၊ network ထဲရောက်ပြီးရင် request ကိုယ်တိုင် authorized ဖြစ်မဖြစ်ကို မဟုတ်ပါဘူး။

Hugging Face Hub — SecurityLocal AI / Local LLM

ဒီနေရာမှာ လူအများမှားတတ်တယ်

  • 'ဖုန်းကနေ test လုပ်ဖို့ပဲ' ဆိုပြီး 0.0.0.0 ကို bind လုပ်ပြီး ပိတ်ဖို့ မေ့သွားခြင်း — local model server အများစုမှာ default authentication မရှိတာကြောင့် ဒါက model ကို LAN တစ်ခုလုံးအတွက် တိတ်တဆိတ် ဖွင့်ထားသလို ဖြစ်သွားပါတယ်။
  • Firewall rule တစ်ခုကို authentication နဲ့ တူညီတယ်လို့ ယူဆခြင်း — firewall က request တစ်ခု ဘယ် network ကနေ လာနိုင်လဲဆိုတာကို control လုပ်တာပါ၊ network ထဲရောက်ပြီးရင် request ကိုယ်တိုင် authorized ဖြစ်မဖြစ်ကို မဟုတ်ပါဘူး။
  • Model (သို့) tool အသစ်တစ်ခုကို production/daily-use workflow ထဲ တိုက်ရိုက်မထည့်ခင် သေးငယ်တဲ့ scale နဲ့ အရင်စမ်းကြည့်ပါ။

လေ့ကျင့်ခန်း

သင်ထိန်းချုပ်ထားတဲ့ စက်တစ်လုံးမှာ 127.0.0.1 ကို bind လုပ်ထားတဲ့ local inference server တစ်ခု start လုပ်ပြီး network တူတူပေါ်က device ဒုတိယတစ်ခုကနေ curl နဲ့ ဆက်သွယ်ကြည့်ပါ — connection refused ဖြစ်တယ်ဆိုတာ သေချာအောင်လုပ်ပါ။ ပြီးရင် (ရှင်းလင်းတဲ့အတွက် 0.0.0.0 မဟုတ်ဘဲ) သင့်စက်ရဲ့ LAN IP ကို bind လုပ်ပြီး ပြန် start လုပ်ကာ device ဒုတိယတစ်ခုကနေ curl ကို ထပ်လုပ်ကြည့်ပါ။ ကွာခြားချက်ကို မှတ်သားပြီး၊ သင့် subnet ကိုပဲ ခွင့်ပြုတဲ့ firewall rule တစ်ခု run နေဆဲအခြေအနေမှာ ထပ်ထည့်ပါ။

You'll know it worked when: Command နှစ်ခုစလုံးက ချက်ချင်း start ပြီး listen နေတဲ့ address နှင့်အတူ startup banner ကို print ပေးပါတယ် — ပြသဖို့ ဂဏန်း benchmark output ဘာမှ မရှိပါဘူး။ လက်တွေ့ ကွာခြားချက်ကို တခြား စက်ကနေမှသာ သိနိုင်ပါတယ် — 127.0.0.1 bind နဲ့ဆိုရင် network ပေါ်က တခြား device တစ်ခုကနေ curl request ပို့ရင် connect မရပါဘူး (connection refused)၊ OS က စက်ပြင်ပက incoming connection ကို ဒီ socket ပေါ်မှာ လက်မခံလို့ပါ။ 0.0.0.0 bind နဲ့ဆိုရင်တော့ LAN ပေါ်က device တခြားကနေ curl request တူတူပဲ ပို့ရင် အောင်မြင်ပြီး model ဆီရောက်ပါတယ်၊ socket က loopback interface ချည်းသာမက စက်ရဲ့ real network interface ပေါ်မှာ listen နေလို့ပါ။ ufw rule တွေက ဒါကို subnet အတိအကျတစ်ခုအတွက်ပဲ ထပ်ကျဉ်းပေးပေမယ့် authentication ထပ်ထည့်မပေးပါဘူး — allowed subnet ထဲက device တစ်ခုက raw inference API ကို authentication မလိုဘဲ access ရနေဆဲပါ။

Local AI လုံခြုံရေး | Thuta Learning