၂၀၂၆ စက်တင်ဘာ ၂၂

GPT‑6 အတွက် ပိုကောင်းသော prompt caching

ပိုမြင့်သော cache hit rate များနှင့် tool အသစ်များကြောင့် အမြဲလည်ပတ်နေသော အေးဂျင့်များ ပိုမြန်လာပြီး ကုန်ကျစရိတ် လျော့နည်းလာသည်။

ဖွင့်နေသည်…

GPT‑6 သည် အမြဲလည်ပတ်နေသော အေးဂျင့်များကို codebase များ ပြန်လည်ဖွဲ့စည်းခြင်းမှ စနစ်တကျသုတေသနပြုထားသော စာရွက်စာတမ်းနှင့် တင်ပြချက်များ ဖန်တီးခြင်းအထိ ရှုပ်ထွေးသည့် လုပ်ငန်းများကို နာရီပေါင်းများစွာ လုပ်ဆောင်နိုင်စေသည်။ ဤအေးဂျင့်များကို ပံ့ပိုးသည့် application များသည် ရှေ့တောင်းဆိုချက်ကို အခြေခံသည့် API တောင်းဆိုချက်များ အဆက်မပြတ်ပြုလုပ်ပြီး ယခင်အလှည့်များမှ တူညီသော ညွှန်ကြားချက်များ၊ tool သတ်မှတ်ချက်များနှင့် context ကို မကြာခဏ ဆက်လက်သယ်ဆောင်လာသည်။ OpenAI သည် ထိုမျှဝေထားသော context ကို cache လုပ်၍ တောင်းဆိုချက်များတစ်လျှောက် တွက်ချက်မှုကို ပြန်သုံးသည်။ ထို့ကြောင့် တုံ့ပြန်ချိန် လျော့ကျပြီး developer များက cache လုပ်ထားသော input တိုကင်များအတွက် 90% အထိ လျှော့ဈေးရရှိသည်။

GPT‑6 မိသားစုနှင့်အတူ ပုံမှန်အခြေအနေတွင် cache hit rate ပိုမြင့်စေသော အဆင့်မြှင့် prompt caching စနစ်ကို မိတ်ဆက်ခဲ့သည်။ ယခု မိနစ် 30 အတွင်း ပြန်သုံးသော သတ်မှတ်ချက်နှင့်ကိုက်ညီသည့် မျှဝေထားသော prefix များအတွက် cache လျှော့ဈေး ပေးထားသည်။ developer များက cache စွမ်းဆောင်ရည်ကို စောင့်ကြည့်ရန်၊ miss များကို စစ်ဆေးရန်နှင့် တုံ့ပြန်ညွှန်ကြားချက်၏ မည်မျှကို cache လုပ်မည်ဟု ရွေးချယ်ရန် ကူညီပေးသည့် tool အသစ်များကိုလည်း မိတ်ဆက်ထားသည်။

“OpenAI ၏ prompt caching သည် GitHub Copilot က အကြီးစားအသုံးပြုမှုတွင် မြန်ဆန်ထိရောက်သော အတွေ့အကြုံကို ပေးနိုင်ရန် အဓိကအခန်းကဏ္ဍမှ ပါဝင်သည်။ ပြီးခဲ့သည့် လအနည်းငယ်အတွင်း OpenAI မော်ဒယ်များထံ ပေးပို့သော တောင်းဆိုချက် ဘီလီယံပေါင်းများစွာ၌ အသစ်ပြန်လည်လုပ်ဆောင်ရန် လိုအပ်သည့် တုံ့ပြန်ညွှန်ကြားချက် တိုကင်အချိုးကို ယခင်အခြေခံနှုန်းနှင့်ယှဉ်လျှင် 50% ကျော် လျှော့ချနိုင်ခဲ့သည်။ ရလဒ်အနေဖြင့် inference stack ပိုမိုထိရောက်လာပြီး developer များက ပထမဆုံးတုံ့ပြန်ချက်ကို ပိုမိုမြန်ဆန်စွာ ရရှိလာသည်။”

—Mario Rodriguez၊ ထုတ်ကုန်အရာရှိချုပ်

Caching ကို စောင့်ကြည့်ပြီး cache miss များကို စစ်ဆေးပါ

Prompt Caching Dashboard⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) အသစ်သည် သင့် application ၏ input မည်မျှကို cache မှ ပံ့ပိုးပေးနေကြောင်း ပြသသည်။ အချိန်နှင့်အမျှ hit rate ကို ခြေရာခံပြီး cache လုပ်ထားသော တိုကင်များနှင့် မလုပ်ထားသော တိုကင်များကို နှိုင်းယှဉ်ရန် input ဖွဲ့စည်းပုံဇယားကို အသုံးပြုပါ။ ဤမြင်ကွင်းများက cache hit ကျဆင်းမှုကို ရှာဖွေရန်နှင့် သင့် application ပြောင်းလဲမှုများက caching စွမ်းဆောင်ရည်ကို မည်သို့သက်ရောက်ကြောင်း အကဲဖြတ်ရန် ကူညီပေးသည်။

cache hit rate၊ အချိန်နှင့်အမျှ cache စွမ်းဆောင်ရည်နှင့် input တိုကင်ဖွဲ့စည်းပုံတို့ကို ပြသထားသော prompt caching dashboard။

မမျှော်လင့်သော cache miss တွေ့ပါက ဖြစ်ပျက်ခဲ့သည့်အရာကို နားလည်ရန် prompt caching စစ်ဆေးရေးကိရိယာ⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်)ကို အသုံးပြုပါ။ ပြန်သုံး၍မရအောင် တားဆီးခဲ့သည့် မော်ဒယ်၊ tool၊ setting သို့မဟုတ် input ပြောင်းလဲမှုများကို ဖော်ထုတ်ရန် တောင်းဆိုချက်တစ်ခုကို မကြာသေးမီက တုံ့ပြန်ချက်နှင့် နှိုင်းယှဉ်ပါ။ သက်ရောက်မှုရှိနိုင်သည့် ခန့်မှန်းတိုကင်အရေအတွက်က အကျိုးသက်ရောက်မှုပမာဏကို အကဲဖြတ်ရန်နှင့် cache hit rate အမြင့်ဆုံးရရှိအောင် သင့် integration ကို မည်သို့အကောင်းဆုံးပြင်ဆင်မည်ဟု ဆုံးဖြတ်ရန် ကူညီပေးသည်။

{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

သင့် application အတွက် caching ကို အကောင်းဆုံးပြင်ဆင်ပါ

Cache လုပ်မည့်အရာကို ရွေးချယ်ပါ။ သတ်မှတ်ထားသော cache breakpoint များက ပြန်သုံးမည့် တုံ့ပြန်ညွှန်ကြားချက်၏ ရှေ့ပိုင်းများကို ရွေးချယ်နိုင်စေသည်။ မွမ်းမံထားသော prompt caching လမ်းညွှန်⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်)တွင် ၎င်းတို့ကို အသုံးပြုပုံ၊ cache လုပ်ထားသော prefix များ သတ်မှတ်ချက်နှင့် ကိုက်ညီနေမည့်ကြာချိန်နှင့် tool၊ input ပြောင်းလဲမှုများက ပြန်သုံးခြင်းအပေါ် သက်ရောက်ပုံတို့ကို ရှင်းပြထားသည်။

Cache မပျက်ဘဲ ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးသော အားထုတ်မှုပမာဏကို ချိန်ညှိပါ။ GPT‑6 မော်ဒယ်များတွင် cache မပျက်စေဘဲ တုံ့ပြန်ချက်များကြား၌ ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးသော အားထုတ်မှုပမာဏကို ပြောင်းလဲ⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်)နိုင်ပြီဖြစ်သည်။ တောင်းဆိုချက်အဆင့် ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးသော အားထုတ်မှုပမာဏကို မပြောင်းဘဲ configuration_update ကို ထပ်ဖြည့်ခြင်းဖြင့် ခက်ခဲသောလုပ်ငန်းအတွက် အားထုတ်မှုကို မြှင့်ပါ သို့မဟုတ် ပုံမှန်နောက်ဆက်တွဲအတွက် လျှော့ပါ။ ထို့ကြောင့် ပြန်သုံးနိုင်သော context ကို ထိန်းသိမ်းရင်း လုပ်ငန်းတစ်ခုအတွက် လိုအပ်သည့် ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးသော ပမာဏကို ချိန်ညှိနိုင်သည်။

Tool နှင့် ညွှန်ကြားချက်များ ပြောင်းလဲချိန်တွင် cache ကို ထိန်းသိမ်းပါ။ သင့်အေးဂျင့်၏ tool အသုံးပြုမှုလိုအပ်ချက်များ ပြောင်းလဲလာသည့်အခါ ယခင် context ကို ပြန်သုံးနိုင်စေရန် tool သတ်မှတ်ချက်များ၊ schema များနှင့် အစီအစဉ်ကို တည်ငြိမ်အောင်ထားပါ။ သတ်မှတ်ချက်များကို ဖယ်ရှားမည့်အစား သက်ဆိုင်ရာ tool များကိုသာ ခေါ်သုံးနိုင်စေရန် allowed_tools ကို အသုံးပြုပါ သို့မဟုတ် tool မလိုအပ်ပါက tool_choice ကို none ဟု သတ်မှတ်ပါ။ အဟောင်းများကို အစားထိုးရန် ညွှန်ကြားချက်အသစ်များကို context အဆုံးပိုင်း၌ ထပ်ဖြည့်နိုင်ရန် developer message အသစ်များကို အသုံးပြုပါ။ ကျွန်ုပ်တို့၏ tool ပြောင်းလဲမှုများ စီမံခန့်ခွဲရေး လမ်းညွှန်ချက်⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်)ကို ကြည့်ပါ။

ကြန့်ကြာချိန်လျှော့ရန် cache ကို ကြိုတင်အသင့်ပြင်ပါ။ ကြိုတင်အသင့်ပြင်ခြင်း⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်)သည် သိရှိထားသော context ကို ကြိုတင်ပြင်ဆင်ပေးသောကြောင့် တောင်းဆိုချက်ရောက်လာချိန်တွင် မော်ဒယ်က ပိုမိုလျင်မြန်စွာ စတင်တုံ့ပြန်နိုင်သည်။ ဥပမာအားဖြင့် အသုံးပြုသူက ပထမဆုံးမေးခွန်း မမေးမီ application စတင်ချိန်၌ မျှဝေထားသော ညွှန်ကြားချက်များ၊ tool သတ်မှတ်ချက်များ သို့မဟုတ် ကိုးကားစရာအကြောင်းအရာများကို ကြိုတင်အသင့်ပြင်နိုင်သည်။ ထို့ကြောင့် အသုံးပြုသူ၏ စောင့်ဆိုင်းချိန်အတွင်း လုပ်ဆောင်ရမည့်အရာကို ကြိုတင်လုပ်ဆောင်ထားနိုင်သည်။

ဤရွေးချယ်အသုံးပြုနိုင်သော ထိန်းချုပ်မှုများသည် engine ၏ မူလစွမ်းဆောင်ရည်ကို အခြေခံ၍ သင့် workload နှင့်ကိုက်ညီအောင် caching ကို ပြင်ဆင်နိုင်စေသည်။

3အနက် 1

“OpenAI ၏ prompt caching စစ်ဆေးရေးကိရိယာများနှင့် dashboard ကြောင့် cache hit rate ကို ရာခိုင်နှုန်းအနည်းငယ် မြှင့်တင်နိုင်ခဲ့ပြီး ကုန်ကျစရိတ်ကို 20% လျှော့ချနိုင်ခဲ့သည်။ ယခု caching မမျှော်လင့်ဘဲ ပျက်သွားပါက သတိပေးချက်များ ရရှိပြီး အရင်းခံအကြောင်းရင်းကို ရှာဖွေရန် Codex အေးဂျင့်များကို အသုံးပြုသည်။ သတ်မှတ်ထားသော breakpoint များက မကြာခဏပြောင်းလဲသည့် အကြောင်းအရာကို တုံ့ပြန်ညွှန်ကြားချက်၏ အဆုံးတွင်ထားပြီး တည်ငြိမ်သော context ကို cache လုပ်နိုင်စေသည်။ ထို့ကြောင့် မျှဝေထားသော context အားလုံးနီးပါးကို ပြန်သုံးရင်း နောက်ခံလုပ်ငန်းများအတွက် စကားဝိုင်းများကို မူကွဲဖန်တီးခြင်းသည် ကုန်ကျစရိတ်အရ လက်တွေ့ကျလာသည်။”

—Arian Hanifi၊ နည်းပညာအရာရှိချုပ်

“Manus ကဲ့သို့ အချိန်ကြာမြင့်စွာ လည်ပတ်သည့် အေးဂျင့်များအတွက် ယုံကြည်စိတ်ချရသော caching သည် စီးပွားရေးတွက်ခြေကိုက်ရန် အခြေခံအကျဆုံးဖြစ်သည်။ OpenAI အင်ဂျင်နီယာအဖွဲ့နှင့် ပူးပေါင်း၍ cache breakpoint နေရာချထားမှုကို မွမ်းမံခဲ့ပြီး သတ်မှတ် caching နှင့် အလိုအလျောက် caching ကို ပေါင်းစပ်ကာ မမျှော်လင့်သော cache miss များကို ရှာဖွေရန် လက်တွေ့တောင်းဆိုချက်များကို အသုံးပြုခဲ့သည်။ တစ်ပတ်မပြည့်မီ ကျွန်ုပ်တို့၏ OpenAI မော်ဒယ် cache hit rate သည် 85% ခန့်မှ 90% အထက်သို့ တည်ငြိမ်စွာ မြင့်တက်လာပြီး production ရှိ inference ကုန်ကျစရိတ်ကို ထပ်မံလျှော့ချနိုင်ခဲ့သည်။ အဖွဲ့နှစ်ဖွဲ့စလုံးက လုပ်ငန်းစဉ်တစ်လျှောက် ရလဒ်များကို အတည်ပြုရင်း ပစ်မှတ်ထားသော တိုးတက်မှုများကို အဆင့်ဆင့်ပြုလုပ်ခဲ့သဖြင့် ဤတိုးတက်မှု ရရှိခဲ့သည်။”

—Bin Fan၊ အေးဂျင့်အဖွဲ့ခေါင်းဆောင်

“OpenAI နှင့် ပူးပေါင်းပြီး ကျွန်ုပ်တို့၏ session အေးဂျင့်များကို သတ်မှတ်ထားသော cache breakpoint များသို့ ပြောင်းရွှေ့ခဲ့သည်။ တစ်ပတ်မပြည့်မီ ကျွန်ုပ်တို့၏ အကဲဖြတ်မှုများတွင် cache hit rate သည် 83% မှ 91% သို့ မြင့်တက်လာခဲ့သည်။ ထို့ကြောင့် တူညီသော workload ဖြင့် cache write အရေအတွက်နှင့် inference ကုန်ကျစရိတ် နှစ်ခုစလုံး လျော့ကျခဲ့သည်။ cache write သည် သုံးပုံနှစ်ပုံခန့် လျော့ကျပြီး inference ကုန်ကျစရိတ်မှာ 36% လျော့ကျခဲ့သည်။”

—Eugene Mikhantyev၊ AI အင်ဂျင်နီယာ