LLM API များကို ဘယ်လို အသုံးပြုမလဲ: Tokens၊ ကုန်ကျစရိတ်၊ Key များနှင့် သင်၏ ပထမ AI Feature

LLM API ဆိုသည်မှာ သင့် app က စာသားကို GPT model များ၊ Anthropic ၏ Claude သို့မဟုတ် Google ၏ Gemini ကဲ့သို့ large language model သို့ ပို့ပြီး ၎င်း၏ အဖြေကို code ထဲသို့ ပြန်ရယူနိုင်စေသော web service ဖြစ်သည်။ provider တွင် signup လုပ်ပြီး API key ဖန်တီးကာ သင့် app ၏ server က ထို key ဖြင့် request ပို့သည်။ ဝင်သော နှင့် ထွက်သော tokens (စာသားအပိုင်းများ) အရေအတွက်အလိုက် request တစ်ခုချင်းစီအတွက် ငွေပေးရသည်။ "app သို့ AI ထည့်ခြင်း" ဆိုသည်မှာ များသောအားဖြင့် အခြားသူ၏ model သို့ ကောင်းမွန်စွာ ရေးထားသော request တစ်ခုကို သင့် server မှ လုံခြုံစွာ ပို့ခြင်း ဖြစ်သည်။

AI ဖြင့် build လုပ်သည့်အခါ ဘာကြောင့် အရေးကြီးသလဲ

AI-built app တစ်ခုတွင် AI နှစ်မျိုး ရှိပြီး ရောထွေးရလွယ်သည်:

1. သင့် app ကို build လုပ်သော AI — app builder ၏ ကိုယ်ပိုင် agent ဖြစ်ပြီး code ကို ရေးသည်။
2. သင့် app အတွင်းရှိ AI — သင့် အသုံးပြုသူများ သုံးသော feature ဖြစ်သည်၊ ဥပမာ chat assistant၊ "ဒါကို အကျဉ်းချုပ်ပါ" ခလုတ် သို့မဟုတ် အလိုအလျောက် tagging။

ဒုတိယအမျိုးအစားသည် သင့် key ဖြင့် LLM API ကို ခေါ်ပြီး သင့် provider account ကို ငွေနှုတ်သည်။ tokens၊ context နှင့် စျေးနှုန်းကို နားလည်ခြင်းက အလုပ်လုပ်သည်၊ key မပေါက်ကြားသည်နှင့် ငွေစာရင်းတွင် အံ့အားသင့်စရာ မရှိသော feature ကို ဒီဇိုင်းဆွဲနိုင်စေသည်။

နေ့စဉ်ဥပမာ: စကားလုံးလိုက် ငွေပေးရသော အလွန်တော်သည့် freelancer

LLM API ကို အီးမေးလ်ဖြင့် ဆက်သွယ်ပြီး စကားလုံးလိုက် ငွေပေးရသော ထူးချွန်သည့် freelance စာရေးသူတစ်ဦးဟု စဉ်းစားပါ — သင်ပို့သော စကားလုံးနှင့် ၎င်းပြန်ရေးသော စကားလုံး နှစ်ခုလုံးအတွက် (ပြန်ရေးသော စကားလုံးများက ပိုကုန်ကျသည်)။

• အီးမေးလ်များကြား မှတ်ဉာဏ် မရှိပါ။ စကားဝိုင်းကို ဆက်စေချင်လျှင် အီးမေးလ်အသစ်တိုင်းတွင် အရင်စာများကို ပြန်ထည့်ပေးရသည်။
• တစ်ကြိမ်တည်းတွင် ဖတ်နိုင်သော ပမာဏ ကန့်သတ်ထားသည်။ ထိုကန့်သတ်ချက်ကို context window ဟု ခေါ်သည်။
• ညွှန်ကြားချက် ရှင်းလင်းလေ၊ အဖြေ ကောင်းလေ၊ တိုလေ — ထို့ကြောင့် ပိုစျေးပေါ်သည်။

အဓိက သဘောတရားများ

Tokens

Model များသည် စာသားကို tokens ဖြင့် ဖတ်ပြီး ရေးသည်။ Anthropic ၏ pricing စာတမ်းအရ ၂၀၂၆ ခုနှစ် စက်တင်ဘာလ အထိ token တစ်ခုလျှင် စာလုံး ၄ လုံး သို့မဟုတ် အင်္ဂလိပ်စကားလုံး ၀.၇၅ ခန့်ဟု ခန့်မှန်းထားသည်။ model နှင့် ဘာသာစကားအလိုက် token ခွဲပုံ ကွဲပြားသဖြင့် ၎င်းကို ခန့်မှန်းချက်အဖြစ်သာ သတ်မှတ်ပါ။ အရာအားလုံး ရေတွက်သည် — သင့်ညွှန်ကြားချက်များ၊ အသုံးပြုသူ၏ message၊ ထည့်သွင်းသော document များ၊ ယခင် စကားဝိုင်းနှင့် အဖြေ။

Input နှင့် output

Input tokens သည် သင်ပို့သောအရာဖြစ်သည်။ Output tokens သည် model ရေးသောအရာဖြစ်သည်။ OpenAI၊ Anthropic နှင့် Google ၏ pricing စာမျက်နှာများအရ ၂၀၂၆ ခုနှစ် စက်တင်ဘာလ အထိ model တူတူအတွက် output tokens သည် input tokens ထက် နှစ်ဆ အများကြီး ပိုကုန်ကျသည်။ Google Gemini ၏ pricing တွင် model ၏ အတွင်းပိုင်း "thinking" ကိုလည်း output အဖြစ် ရေတွက်ကြောင်း ဖော်ပြထားသည်။

Context window

တစ်ကြိမ် request တစ်ခုတည်းတွင် model လက်ခံနိုင်သော tokens အမြင့်ဆုံး အရေအတွက် ဖြစ်ပြီး အဖြေပါ ပါဝင်သည်။ ခေတ်မီ model များသည် input ရှည်ရှည်ကို လက်ခံနိုင်သည် — ဥပမာ Anthropic ၏ လက်ရှိ model အချို့သည် tokens တစ်သန်းအထိ လက်ခံသည်။ သို့သော် input ရှည်လျှင် ပိုကုန်ကျပြီး ပိုကြာသည်၊ ထို့ကြောင့် အလုပ်အတွက် လိုအပ်သည့်အရာကိုသာ ပို့ပါ။

State မရှိသော request များ

chat-style API အများစုတွင် request တစ်ခုချင်းစီသည် default အားဖြင့် သီးခြားရပ်တည်သည်။ chat ကို "မှတ်မိ" စေရန် သင့် app သည် message အသစ်တိုင်းတွင် ယခင် message များကို ပြန်ပို့ရသည်။ ထို့ကြောင့် စကားဝိုင်းရှည်သည် တိုသော စကားဝိုင်းထက် message တစ်ခုလျှင် ပိုကုန်ကျသည်။

System prompt

request တိုင်းအတွက် model ၏ အခန်းကဏ္ဍနှင့် စည်းမျဉ်းများကို သတ်မှတ်သော ညွှန်ကြားချက်များ — ဥပမာ "support ticket များကို အချက် ၃ ချက်ဖြင့် အကျဉ်းချုပ်ပါ။ customer email လိပ်စာများ ဘယ်တော့မှ မထည့်ပါနှင့်။" အသုံးပြုသူများ မမြင်ရသော်လည်း အဖြေတိုင်းကို ပုံဖော်ပေးသည်။

Streaming

အဖြေ အပြည့်ကို စောင့်မနေဘဲ API က စာသားကို ထုတ်လုပ်စဉ် ပို့နိုင်သည်၊ ထို့ကြောင့် အသုံးပြုသူများက စကားလုံးများ ချက်ချင်း ပေါ်လာသည်ကို မြင်ရသည်။ chat interface များကို အလွန်မြန်သလို ခံစားစေသည်။

စျေးနှုန်း အလုပ်လုပ်ပုံ

၂၀၂၆ ခုနှစ် စက်တင်ဘာလ အထိ provider များ၏ ကိုယ်ပိုင် pricing စာမျက်နှာများပေါ်တွင် စစ်ဆေးထားသည်:

provider အချို့က ငွေမပေးမီ စမ်းသုံးနိုင်ရန်လည်း ပေးသည်။ Anthropic က အသုံးပြုသူသစ်များကို အခမဲ့ credit အနည်းငယ် ပေးသည်၊ Google Gemini API တွင် model အချို့အတွက် free tier ရှိပြီး ထို tier တွင် ပို့သော content ကို Google ၏ ထုတ်ကုန်များ တိုးတက်စေရန် အသုံးပြုနိုင်ကြောင်း သတိပြုပါ။

provider ၏ သေးငယ်သော၊ မြန်ဆန်သော model များနှင့် အကြီးဆုံး model များကြား စျေးနှုန်း အလွန်ကွာခြားပြီး မကြာခဏ ပြောင်းလဲသဖြင့် ဤနေရာတွင် မဖော်ပြပါ။ feature တစ်ခုအတွက် ရိုးရှင်းသော ခန့်မှန်းနည်းမှာ: (input tokens × input စျေး + output tokens × output စျေး) × တစ်လလျှင် request အရေအတွက် ဖြစ်သည်။ ထို့နောက် margin ထည့်ပြီး provider ၏ dashboard တွင် လစဉ် ငွေသုံးစွဲမှု ကန့်သတ်ချက် သတ်မှတ်ပါ။

လက်တွေ့ ဥပမာ: "ဒီ ticket ကို အကျဉ်းချုပ်ပါ" ခလုတ်

အသေးစား support အဖွဲ့တစ်ခုသည် ရှည်လျားသော customer email thread ကို အချက် ၃ ချက်နှင့် အကြံပြု အဖြေတစ်ခု ဖြစ်စေသော ခလုတ်တစ်ခု လိုချင်သည်။

1. Key ရယူပါ။ provider တစ်ခုတွင် account ဖွင့်ပြီး API key ဖန်တီးပါ။ လစဉ် ငွေသုံးစွဲမှု ကန့်သတ်ချက်ကို နည်းနည်းထားပါ။
2. Key ကို secret အဖြစ် သိမ်းပါ သင့် server တွင် ANTHROPIC_API_KEY သို့မဟုတ် OPENAI_API_KEY ကဲ့သို့ အမည်ဖြင့် — စာမျက်နှာ code ထဲ ဘယ်တော့မှ မထည့်ပါနှင့်။ environment variables နှင့် secrets ကို ကြည့်ပါ။
3. Server route တစ်ခု ထည့်ပါ၊ POST /api/summarise၊ ၎င်းသည်:
   • လူက login ဝင်ထားပြီး support အဖွဲ့ဝင် ဖြစ်မဖြစ် စစ်ဆေးသည်၊
   • database မှ ticket ကို ဖတ်သည်၊
   • provider သို့ system prompt ("အချက် ၃ ချက်ဖြင့် အကျဉ်းချုပ်ပြီး ယဉ်ကျေးသော အဖြေ ရေးပါ; order နံပါတ်များကို မတီထွင်ပါနှင့်") နှင့် ticket စာသားကို ပို့သည်၊
   • အမြင့်ဆုံး output tokens ဆက်တင်ဖြင့် အဖြေအရှည်ကို ကန့်သတ်သည်၊
   • ရလဒ်ကို ပြန်ပေးပြီး အသုံးပြုခဲ့သော tokens အရေအတွက်ကို မှတ်တမ်းတင်သည်။
4. ခလုတ်က provider ကို မဟုတ်ဘဲ သင့် route ကို ခေါ်သည်၊ အကျဉ်းချုပ်ကို stream ဖြင့် ပေါ်လာသည်အထိ ပြသသည်။
5. ပျက်ကွက်မှုကို ကိုင်တွယ်ပါ။ provider နှေးလျှင် သို့မဟုတ် error ပြန်ပေးလျှင် "ယခု အကျဉ်းချုပ်၍ မရပါ" ဟု ပြပြီး ticket ကို ဆက်သုံးနိုင်အောင် ထားပါ။
6. တိုင်းတာပါ။ တစ်ပတ်ပြီးနောက် tokens မှတ်တမ်းကို ကြည့်ပါ။ ကုန်ကျစရိတ် အများစုက ရှည်သော email thread များဖြစ်လျှင် ပို့မီ ကိုးကားထားသော ယခင်စာများကို ဖြတ်ပါ။

ဘာ မပါဝင်သလဲ သတိပြုပါ: model training မရှိ၊ အထူး infrastructure မရှိ။ key တစ်ခု၊ server route တစ်ခု၊ ကောင်းမွန်စွာ ရေးထားသော prompt တစ်ခုသာ။

အဓိက ဝေါဟာရများ

• API key: သင့် account ကို provider ထံ ဖော်ပြသော လျှို့ဝှက်ချက်။ ၎င်းကို ရှိသူတိုင်းက သင့်ငွေကို သုံးနိုင်သည်။
• Model: သင် ခေါ်သော LLM တိကျသည့်တစ်ခု။ provider များသည် စျေးနှုန်းနှင့် အမြန်နှုန်း ကွဲပြားသော အရွယ်အစားများစွာ ပေးသည်။
• Temperature: အဖြေများ မည်မျှ ကွဲပြားမလဲ ထိန်းသော ဆက်တင်။ နိမ့်လေ ခန့်မှန်းနိုင်လေ ဖြစ်သည်။
• Max tokens: အဖြေအရှည်ကို ကန့်သတ်ချက်ဖြစ်ပြီး ကုန်ကျစရိတ်ကိုလည်း ကန့်သတ်သည်။
• Rate limit: သင့် account က တစ်မိနစ်လျှင် request သို့မဟုတ် tokens ဘယ်လောက် သုံးခွင့်ရှိသလဲ။
• Embeddings: စာသား၏ အဓိပ္ပာယ်ကို ကိုယ်စားပြုသော ဂဏန်းများ၊ သင့်ကိုယ်ပိုင် document များအပေါ် ရှာဖွေရာတွင် သုံးသည်။
• RAG (retrieval-augmented generation): သင့်ကိုယ်ပိုင် data မှ သက်ဆိုင်သော အပိုင်းများကို ရှာပြီး prompt ထဲ ထည့်ခြင်း၊ ထို့ကြောင့် model က သင့်အကြောင်းအရာမှ ဖြေသည်။
• Tool use / function calling: model က သင့် app ကို တိကျသော function တစ်ခု run ရန် တောင်းဆိုခွင့် ပေးခြင်း၊ ဥပမာ "order အခြေအနေ ကြည့်ပါ"။

အဖြစ်များသော အမှားများနှင့် အယူအဆမှားများ

• Key ကို frontend code ထဲ ထည့်ခြင်း။ အလွန်ကုန်ကျသော အမှား။ browser code သည် လူတိုင်းမြင်နိုင်သည်။ အမြဲ server မှ ခေါ်ပါ။ AI-built app များအတွက် security checklist တွင် ၎င်းနှင့် အခြား launch စစ်ဆေးချက်များ ပါဝင်သည်။
• ငွေသုံးစွဲမှု ကန့်သတ်ချက် မရှိခြင်း သို့မဟုတ် အသုံးပြုသူတစ်ဦးချင်းစီ ကန့်သတ်ချက် မရှိခြင်း။ bug၊ loop သို့မဟုတ် အလွဲသုံးစားပြုသော အသုံးပြုသူတစ်ဦးက ကုန်ကျစရိတ်ကို မြန်မြန် တက်စေနိုင်သည်။ provider ကန့်သတ်ချက် သတ်မှတ်ပြီး app တွင် အသုံးပြုသူတစ်ဦးချင်းစီ request ကို ကန့်သတ်ပါ။
• အချိန်တိုင်း အရာအားလုံး ပို့ခြင်း။ document တစ်ခုလုံးနှင့် chat မှတ်တမ်းတစ်ခုလုံးက input tokens ကို မြှောက်ပေးသည်။ ဖြတ်ပါ၊ အဟောင်း message များကို အကျဉ်းချုပ်ပါ၊ သို့မဟုတ် သက်ဆိုင်သော အပိုင်းများကိုသာ ရှာပါ။
• Output ကို မေးမြန်းခြင်းမရှိဘဲ ယုံခြင်း။ model များက မှားသော အချက်များကို ယုံကြည်မှုအပြည့်ဖြင့် ပြောနိုင်သည်။ အချက်အလက်၊ စျေးနှုန်း သို့မဟုတ် ဥပဒေ သို့မဟုတ် ဆေးဘက်ဆိုင်ရာ အရာများအတွက် အဖြေများကို သင့်ကိုယ်ပိုင် data ဖြင့် အခြေခံပြီး ရင်းမြစ်များ ပြပါ၊ သို့မဟုတ် လူတစ်ဦးက စစ်ဆေးစေပါ။
• အသုံးပြုသူ input က သင့်စည်းမျဉ်းများကို ကျော်ခွင့်ပေးခြင်း။ အသုံးပြုသူများက "သင့်ညွှန်ကြားချက်များကို လျစ်လျူရှုပါ" ဟု ရိုက်နိုင်သည်။ ခွင့်ပြုချက်များနှင့် အရေးကြီးသော လုပ်ဆောင်ချက်များကို prompt တွင်သာ မဟုတ်ဘဲ သင့် server code တွင် ထားပါ။
• အကြီးဆုံး model ဖြင့် စခြင်း။ သေးငယ်ပြီး ပေါ့သော model ဖြင့် အရင်စမ်းပါ၊ အရည်အသွေး လိုအပ်မှသာ အဆင့်မြှင့်ပါ။
• ကိုယ်ရေးကိုယ်တာ data ကို အမှတ်မထားဘဲ ပို့ခြင်း။ provider ၏ data အသုံးပြုမှု စည်းမျဉ်းများကို စစ်ပါ၊ အထူးသဖြင့် အခမဲ့ tier များတွင်၊ feature လိုအပ်သည့်အရာကိုသာ ပို့ပါ။

သင့် AI builder ကို ဘာတောင်းဆိုရမလဲ

ticket စာမျက်နှာပေါ်တွင် "Summarise" ခလုတ် ထည့်ပါ။ ၎င်းသည် OPENAI_API_KEY secret ကို အသုံးပြုသော server route ကို ခေါ်ပါ (browser သို့ ဘယ်တော့မှ မပေါ်စေပါနှင့်)၊ အသုံးပြုသူ login ဝင်ထားကြောင်း စစ်ပါ၊ ticket စာသားကို ဤ system prompt ဖြင့် ပို့ပါ: […], အဖြေကို ၃၀၀ tokens အထိ ကန့်သတ်ပါ၊ အဖြေကို စာမျက်နှာသို့ stream လုပ်ပါ၊ ခေါ်ဆိုမှု မအောင်မြင်ပါက ဖော်ရွေသော error ပြပါ။ request တစ်ခုချင်းစီ အသုံးပြုသော tokens ကို မှတ်တမ်းတင်ပြီး အသုံးပြုသူတစ်ဦးလျှင် တစ်နာရီအတွင်း အကျဉ်းချုပ် ၃၀ ခုသို့ ကန့်သတ်ပါ။

chat အပြည့်အစုံ အတွေ့အကြုံအတွက် AI chatbot app တည်ဆောက်နည်း ကို ကြည့်ပါ၊ အခြား အိုင်ဒီယာများအတွက် သင့် app သို့ AI feature များ ထည့်နည်း ကို ကြည့်ပါ။ API များ အသစ်ဖြစ်ပါက API ဆိုတာ ဘာလဲ ဖြင့် စတင်ပါ။

Mythex ဖြင့် build လုပ်ထားသော app များတွင် LLM API များ

Mythex ဖြင့် build လုပ်သည့်အခါ သင့် app အတွင်းရှိ AI သည် သင့်ကိုယ်ပိုင် provider key ကို အသုံးပြုသည်။ ၎င်းကို project secret အဖြစ် ထည့်ပါ၊ သို့မဟုတ် လိုအပ်သောအခါ Mythex က chat တွင် ပြသသော secrets card မှတစ်ဆင့် ထည့်ပြီး agent ကို server တွင် ခေါ်ဆိုစေရန် တောင်းဆိုပါ။ provider အသုံးပြုမှုကို Mythex build credits ထက် သင့် provider account သို့ ငွေနှုတ်သည်။ Mythex သည် သင့် app ၏ အသုံးပြုသူများအတွက် tokens သို့မဟုတ် built-in knowledge-base product ကို မပါဝင်စေပါ၊ rate limits နှင့် ကုန်ကျစရိတ် ထိန်းချုပ်မှုများကို သင်ဒီဇိုင်းဆွဲပြီး စမ်းသပ်ရမည်။ docs ၏ သင့်ကိုယ်ပိုင် API key များဖြင့် AI feature များ ထည့်ခြင်း တွင် starter prompt ရှိပြီး AI app builder စာမျက်နှာတွင် စတင်ရမည့်နေရာကို ပြသသည်။

မေးခွန်းများ