ဆင်ဆာမဲ့ Hy3 Model API

"ဘယ်မော်ဒယ်ကို သုံးရမလဲ" argument အများစုသည် လှေကားထစ် ထိပ်ဆုံးအကြောင်း ဖြစ်သည် — ဘယ်ဟာက code အကောင်းဆုံး ရေးသလဲ၊ ဘယ်ဟာက ခက်ခဲဆုံး သင်္ချာကို ဖြေရှင်းသလဲ၊ ဘယ်ဟာက agent run ရှည်ဆုံးကို အနိုင်ရသလဲ။ Structured pipeline များ ထိုသို့ အလုပ်မလုပ်ပါ။ တစ်နေ့လျှင် document တစ်သိန်းမှ field များ ထုတ်ယူသော အလုပ်တစ်ခုသည် တစ်ကြိမ်တည်း ထူးချွန်သော မော်ဒယ်တစ်ခု လိုအပ်ခြင်း မဟုတ်ဘဲ — ကြိမ်တိုင်း ပုံစံတူညီစွာ မှန်ကန်သော၊ JSON object ရှိသင့်သောနေရာတွင် စာပိုဒ်တစ်ခု ဘယ်တော့မှ ပြန်ပေးမည် မဟုတ်သော မော်ဒယ်တစ်ခု လိုအပ်သည်။ ၎င်းသည် Hy3-W8A16 ရှိနေရသည့် ဂုဏ်သတ္တိ ဖြစ်သည်။

01Hy3 ဆိုသည်မှာ ဘာလဲ၊ ဘယ်ကလာသလဲ

Hy3 သည် Tencent ၏ Hunyuan team မှ open-weight reasoning နှင့် agentic မော်ဒယ်တစ်ခု ဖြစ်ပြီး 2026 ခုနှစ် ဇူလိုင် 6 တွင် permissive license အောက် weight အပြည့်အစုံ Hugging Face ပေါ်တွင် ထုတ်ပြန်ခဲ့သည်။ ၎င်းသည် Tencent ၏ ယခင် Hunyuan-Large Mixture-of-Experts အလုပ်၏ မျိုးရိုးကို ဆက်လက် ရှေ့ဆက်သည်။ ဗိသုကာလက်ရာအရ ၎င်းသည် sparse MoE တစ်ခု ဖြစ်သည် — parameter စုစုပေါင်း 295 billion အနက် ခန့်မှန်း 21 billion ကို token တစ်ခုလျှင် expert 192 ခုတစ်လျှောက် top-8 routing မှတဆင့် activate လုပ်ကာ grouped-query attention ပါသော layer 80 ရှိ transformer တစ်ခုပေါ်တွင် ရှိသည်, ထပ်ပေါင်း speculative decoding အတွက် multi-token-prediction layer 3.8B သီးခြား ပါဝင်သည်။ Native context မှာ 256K ဖြစ်ပြီး — ကျွန်ုပ်တို့ ထုတ်ဖော်ထားသော token 262,144 နှင့် အတိအကျ ကိုက်ညီသည်၊ ပိုကြီးသောအရာတစ်ခု၏ ဖြတ်ထုတ်ခြင်း သို့မဟုတ် ပိုသေးငယ်သောအရာတစ်ခု၏ rope-stretched extension မဟုတ်ပါ။

Token တစ်ခုလျှင် ငွေပေးရသူ မည်သူအတွက်မဆို ထို sparsity ratio သည် အရေးကြီးသော ကိန်းဂဏန်း ဖြစ်သည် — Hy3 သည် forward pass တစ်ခုလျှင် 21B ခန့်၏ arithmetic ကို ပြုလုပ်စဉ် 295B မော်ဒယ်တစ်ခု၏ အသိပညာကို သယ်ဆောင်သည်။ ၎င်းက ကျွန်ုပ်တို့ ၎င်းကို ပိုပြင်းထန်စွာ compress လုပ်မည့်အစား 8 bit ၌ ဝန်ဆောင်မှုပေးနိုင်စေသည့် အကြောင်းရင်းလည်း ဖြစ်သည် — ဤ sparse မော်ဒယ်၏ 8-bit build တစ်ခုသည် ကျွန်ုပ်တို့ ကိုယ်ပိုင် GPU ကလပ်စတာပေါ်တွင် ဝင်ကျပြီး မြန်ဆန်စွာ ဆက်လည်ပတ်နေသည်။

Tencent က ဘာမှာ ကောင်းသည်ဟု ဖော်ပြထားသလဲ

Tencent ၏ ထုတ်ဝေထားသော evaluation table များက Hy3 ၏ အားသာချက်များကို raw coding ထက် agentic search, tool orchestration နှင့် context ရှည်လျား retrieval ၌ ဆတိကျ ထားသည်။ ၎င်းတို့ ဖော်ပြထားသော ကိန်းများ —

ကျွန်ုပ်တို့ တမင် အားနည်းသော bar များကို ပြသထားသည်။ Tencent ကိုယ်တိုင်၏ နှိုင်းယှဉ်ချက်တွင် Hy3 သည် coding ၌ GLM-5.2 ထက် နောက်ကျသည် — SWE-bench Verified တွင် 84.2 နှင့် 78.0၊ DeepSWE တွင် 46.2 နှင့် 28.0။ သင့် workload သည် autonomous multi-file software engineering ဖြစ်လျှင် ဦးစွာ model research အညွှန်း ကျန်ကို ဖတ်ပါ။ ၎င်းသည် စာသား ဖတ်ပြီး ဖွဲ့စည်းပုံ ထုတ်ပေးခြင်း ဖြစ်လျှင်မူ ပရိုဖိုင်သည် ideal နှင့် နီးစပ်သည်။

pipeline အလုပ်အတွက် အရေးကြီးဆုံး ကိန်းမှာ ယုံကြည်စိတ်ချရမှုဆိုင်ရာ ကိန်းတစ်ခု ဖြစ်သည် — Tencent က Hy3 ၏ hallucination rate ကို 5.4% ဟု ဖော်ပြထားပြီး ယခင်မျိုးဆက်ရှိ 12.5% မှ ကျဆင်းလာကာ commonsense error များသည် 25.4% မှ 12.7% သို့ ကျဆင်းလာသည်။ ၎င်းတို့ ဖော်ပြထားသော training principle — အထောက်အထားရှိလျှင် အဖြေပေးပါ၊ မရှိလျှင် ရှင်းရှင်းလင်းလင်း ပြောပါ — သည် ရင်းမြစ်က ဘယ်တော့မှ မမှတ်ခဲ့သော field တစ်ခုအတွက် ယုံကြည်ရလောက်သော တန်ဖိုးတစ်ခု တီထွင်တတ်မည့် extraction မော်ဒယ်တစ်ခုတွင် သင် လိုချင်သော သဘောထား အတိအကျ ဖြစ်သည်။

ဤ section ရှိ ကိန်းဂဏန်းအားလုံးသည် Tencent ၏ ကိုယ်ပိုင် စမ်းသပ်မှုများမှ ဖော်ပြချက်များ ဖြစ်ပြီး ဤဆောင်းပါး ရေးသားချိန်တွင် သီးခြား third-party အတည်ပြုမှု ဆိုင်းငံ့ဆဲ ဖြစ်သည်။ ၎င်းတို့ကို ဦးတည်ချက်အဖြစ်သာ ယူပါ၊ ပြီးပြတ်သောအရာအဖြစ် မယူပါနှင့်။

02W8A16 ဆိုသည်မှာ ဘာကို ဆိုလိုပြီး structured output အတွက် ဘာကြောင့် အရေးကြီးသနည်း

gateway ပေါ်ရှိ မော်ဒယ်တိုင်းသည် quantization နောက်ဆက်တွဲ တစ်ခု ဆောင်ကြသည်။ ၎င်းသည် အလှပြင်ခြင်း မဟုတ်ပါ — ဝန်ဆောင်မှုပေးနေသော weight များသည် laboratory ထုတ်ပြန်ခဲ့သည့် checkpoint နှင့် ဘယ်လောက် ကွာဟနေသလဲ ဖော်ပြထားသည်။

Tier	ဘာလုပ်သလဲ	Fidelity
3BIT-REAP	3-bit weight ထပ် REAP — quantize မလုပ်မီ ရှားရှားပါးပါးသာ route လုပ်ခံရသော MoE expert များကို ဖြုတ်ချသော expert-pruning method တစ်ခု	Compress လုပ်ထားမှု အများဆုံး
W4A16-AUTOROUND-REAP	AutoRound မှတဆင့် 4-bit weight / 16-bit activation — naive round-to-nearest ထက် accuracy ပြန်ရရှိစေသော learned rounding — ထပ် REAP pruning	အလယ်အလတ်
W8A16	8-bit weight / 16-bit activation။ pruning မရှိ၊ learned-rounding ပြင်ဆင်မှု မရှိ — weight များကို precision နှစ်ဆဖြင့် ရိုးရိုး သယ်ဆောင်ထားသည်	အမြင့်ဆုံး

Quantization လွှဲသွားမှုသည် အမှန်တကယ် ဘယ်နေရာမှာ ထိခိုက်စေသလဲ

REAP နှင့် AutoRound သည် naive compression ဆုံးရှုံးစေသည့်အရာ အများစုကို ပြန်ရရှိစေသည် — သို့သော် "အများစု" ဆိုသည့် စကားလုံးသည် ထို စာကြောင်းထဲတွင် အလုပ်လုပ်နေသည်၊ ကျန်ရှိသော ဒဏ်ရာမှာ တညီတညွတ်တည်း မဟုတ်ပါ။ Bit နည်းသော quantization သည် tail — probability နိမ့်သော, specificity မြင့်သော ဆုံးဖြတ်ချက်များ — ကို ညံ့ဖျင်းစေသည်။ Prose တွင် ၎င်းသည် နီးပါး မမြင်ရ; adjective တစ်ခု ကွဲပြားသော်လည်း ဆက်လက် ကောင်းမွန်သော စာကြောင်းတစ်ခု ဖြစ်နေသည်။ Structured output တွင်ကမူ ၎င်းသည် ကစားနေသော အလုံးစုံ ဖြစ်သည် — schema တစ်ခုသည် တစ်ခုချင်းစီ အတိအကျ မှန်ကန်ရမည့် probability နိမ့်သော ဆုံးဖြတ်ချက် ရှည်လျားသော ကွင်းဆက်တစ်ခု ဖြစ်သောကြောင့်ဖြစ်သည် —

• Token-level syntax။ Closing brace တစ်ခု, comma တစ်ခု, quote character တစ်ခု။ တစ်ခုစီသည် token တစ်ခုဖြစ်ပြီး token တစ်ခု မှားလျှင် response တစ်ခုလုံးကို invalidate စေသည်။
• Enum စည်းကမ်းချက်။ သင့် schema က "status" သည် "open" | "closed" | "pending" တစ်ခု ဖြစ်ရမည် ဆိုသည်; လွှဲသွားသော မော်ဒယ်တစ်ခုသည် "Open" သို့မဟုတ် "pending review" ကို ပြန်ပေးသည် — အနက်အားဖြင့် နီးစပ်သော်လည်း နှစ်ခုစလုံး မှန်ကန်ခြင်း မဟုတ်ပါ။
• Type စည်းကမ်းချက်။ number field တစ်ခုသည် "1,240" အဖြစ် ပြန်ရောက်လာသည်; boolean တစ်ခုသည် "yes" အဖြစ်။ နှစ်ခုစလုံး string များအဖြစ် parse ဖြစ်ပြီး schema ကို မကျော်လွှားနိုင်ပါ။
• Long-tail literal များ။ ရှားပါးသော noun အတည်များ, part number များ, ဓာတုဗေဒ အမည်များ, Latin မဟုတ်သော script များ, တိကျသော ရက်စွဲများ — bit နည်းသော weight များ မှုန်စေသည့် probability နိမ့်သော region အတိအကျ ဖြစ်သည်။

ဤအရာမှ ဘာမျှ 4-bit သို့မဟုတ် 3-bit မော်ဒယ်များကို ညံ့ဖျင်းစေသည် မဟုတ်ပါ; conversational အလုပ်အတွက် fidelity ကွာဟချက်သည် ဈေးနှုန်း ကွာဟချက်ကို မတန်တတ်ပါ။ သို့သော် output ၏ consumer သည် လူသားအစား validator တစ်ခု ဖြစ်သောအခါ tail များ၌ precision သည် parse rate ထဲသို့ တိုက်ရိုက် ပြောင်းလဲသွားပြီး parse rate ကလည်း retry budget နှင့် p99 latency ထဲသို့ ပြောင်းလဲသည်။ W8A16 သည် ထို အခွန်ကို ရပ်တန့်စေသော tier ဖြစ်သည်။

03Structured output — json_schema နှင့် response_format

Hy3 သည် structured-output surface ၏ ထက်ဝက် နှစ်ခုစလုံးကို ထောက်ပံ့သည် — ရှင်းလင်းစွာ ဖော်ပြထိုက်သည် — အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် ကက်တလောက်တစ်ခုလုံးတွင် တညီတည်း မဟုတ်သောကြောင့်ဖြစ်သည် —

Model	response_format	json_schema
Hy3 · W8A16	ရှိသည်	ရှိသည်
MiMo-V2.5-Pro · W8A16	ရှိသည်	ရှိသည်
inkling · W4A16-AUTOROUND-REAP	ရှိသည်	မရှိပါ
Laguna-S-2.1 · W4A16-AUTOROUND-REAP	မရှိပါ	မရှိပါ

နည်းလမ်း နှစ်ခုကြား ကွာဟချက်သည် လူများ ထင်ထားသည်ထက် ပိုအရေးကြီးသည်။ response_format: {"type": "json_object"} သည် valid JSON တစ်ခုကိုသာ တောင်းဆိုသည် — မော်ဒယ်က ပုံသဏ္ဌာန်ကို ရွေးချယ်သည်၊ ထို့ကြောင့် call နှစ်ခုသည် {"name": ...} နှင့် {"full_name": ...} ကို ပြန်ပေးနိုင်ပြီး နှစ်ခုစလုံး မှန်ကန်နေသည်။ json_schema ကမူ ပုံသဏ္ဌာန်ကို ကြိုတင် ပေးအပ်သည် — အမည်ပါသော field, type, enum, လိုအပ်သော list, nesting။ ၎င်းသည် သင် code ရေးနိုင်သော ချုပ်ဆိုမှုတစ်ခု ဖြစ်သည်။

OpenAI-compatible dialect ပေါ်ရှိ အနည်းဆုံး call တစ်ခု —

POST /v1/chat/completions

{
  "model": "Hy3-W8A16",
  "messages": [
    {"role": "system", "content": "Extract fields from the incident report. Use null for anything not stated."},
    {"role": "user", "content": "<report text>"}
  ],
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "incident",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "severity":  {"type": "string", "enum": ["low","medium","high","critical"]},
          "component": {"type": "string"},
          "occurred_at": {"type": ["string","null"], "description": "ISO-8601"},
          "affected_users": {"type": ["integer","null"]},
          "indicators": {
            "type": "array",
            "items": {"type": "object", "properties": {
              "kind":  {"type": "string", "enum": ["ip","domain","hash","cve"]},
              "value": {"type": "string"}
            }, "required": ["kind","value"]}
          }
        },
        "required": ["severity","component","occurred_at","affected_users","indicators"]
      }
    }
  }
}

လက်တွေ့ မှတ်ချက်များ

• Field တိုင်းကို လိုအပ်ချက်ဖြစ်စေပြီး null ကို ခွင့်ပြုပါ။ Optional field များသည် တိတ်တဆိတ် ကျဆင်းမှုကို ဖိတ်ခေါ်တတ်သည်; required nullable field တစ်ခုသည် ရှင်းလင်းသော "မပါ" ကို တွန်းအားပေးပြီး ၎င်းသည် သင် ဆောင်ရွက်နိုင်သော အချက်အလက် ဖြစ်သည်။
• Enum က free string ကို အနိုင်ယူသည်။ value set ကို ပိတ်နိုင်လျှင် ပိတ်ပါ — schema ၏ လက်တွေ့ world pass rate ကို အများဆုံး ပြောင်းလဲပေးနိုင်သော ပြောင်းလဲမှု ဖြစ်သည်။
• output token 16,384 ကန့်သတ်ချက်အောက်တွင် ဆက်ထားပါ။ ကန့်သတ်ချက်မရှိသော array တစ်ခုသည် object အလယ်တွင် ဖြတ်ထုတ်သွားမည် ဖြစ်သည်။ array length ကို ကန့်သတ်ပါ၊ သို့မဟုတ် input ကို ခွဲပါ။
• System message ကို ဆက်ထားပါ။ Schema က ပုံသဏ္ဌာန်ကို ကန့်သတ်သည်; prompt ကမူ semantics ကို ဆက်လက် ထိန်းချုပ်သည် — ဘာက "critical" ဖြစ်သလဲ၊ ရက်စွဲနှစ်ခု ပေါ်လာလျှင် ဘယ်ဟာက အနိုင်ရသလဲ၊ unit ကို normalize လုပ်ရမည်လား။
• မည်သို့ပင်ဖြစ်စေ validate လုပ်ပါ။ Schema ထောက်ပံ့ချက်က pass rate ကို မြှင့်တင်ပေးသည်; ၎င်းသည် validator တစ်ခုနှင့် dead-letter queue တစ်ခုကို အစားထိုးမည် မဟုတ်ပါ။

04"ဆင်ဆာမဲ့" သည် content ဂုဏ်သတ္တိတစ်ခုသာမက ယုံကြည်စိတ်ချရမှု ဂုဏ်သတ္တိတစ်ခုလည်း ဘာကြောင့် ဖြစ်သနည်း

gateway ပေါ်ရှိ Hy3 တွင် ငြင်းပယ်မှု အလွှာနှင့် output filtering မရှိပါ။ ပုံမှန် ဖော်ပြချက်မှာ content အကြောင်း ဖြစ်သည် — မော်ဒယ်က သင့်ကိုယ်စား လုပ်ချင်စိတ်မရှိဟု ဆုံးဖြတ်ခြင်း မရှိဘဲ လုံခြုံရေး သုတေသန, malware ခွဲခြမ်းစိတ်ဖြာမှု, exploit write-up, ဆေးဘက်နှင့် တရားရေးဆိုင်ရာ corpus, အရွယ်ရောက်ပြီးသူ ပစ္စည်း, harm-reduction စာရွက်စာတမ်း သို့မဟုတ် ရန်ငြိုးထားသော user transcript များကို သင် ကိုင်တွယ်နိုင်သည်။

ပိုအရေးကြီးသော ဒုတိယ mechanical အကြောင်းရင်းတစ်ခု ရှိသည်။ ငြင်းပယ်ခြင်းသည် schema violation တစ်ခု ဖြစ်သည်။ ငြင်းပယ်သော filter ပါ မော်ဒယ်တစ်ခုသည် "unavailable" flag ပါသော သင့် object ကို ပြန်ပေးမည့်အစား prose ကို ပြန်ပေးသည်။ "ကျွန်ုပ် ထို တောင်းဆိုချက်ကို ကူညီပေးနိုင်ခြင်း မရှိပါ။" ထို string သည် incident object တစ်ခု မဟုတ်ပါ — ၎င်းသည် သင့် validator ကို မကျော်လွှားနိုင်ဘဲ တကယ့် parse error များအနီးတွင် dead-letter queue ထဲသို့ ရောက်ရှိသွားပြီး ယခုအခါ သင်သည် policy ငြင်းပယ်မှုများကို တကယ့် formatting ချို့ယွင်းချက်များနှင့် ခွဲခြားရမည် ဖြစ်သည်။

ပိုဆိုးသည်မှာ ငြင်းပယ်မှုများသည် ကျပန်း ပျံ့နှံ့ခြင်းအစား content နှင့် ဆက်စပ်နေခြင်း ဖြစ်သည်။ သင့် corpus ၏ 4% သည် လုံခြုံရေး incident report ဖြစ်ပြီး မော်ဒယ်က ၎င်းအများစုကို ငြင်းပယ်လျှင် throughput ၏ 4% ကို တညီတညွတ်တည်း မဆုံးရှုံးခဲ့ပါ — အမျိုးအစားတစ်ခုလုံးကို ဆုံးရှုံးခဲ့ပြီး ထို data ပေါ်တွင် တည်ဆောက်ထားသော dashboard သည် ၎င်း ဖော်ထုတ်ရန် ရှိနေသော အချက်ကိုပင် တိတ်တဆိတ် လျှော့တွက်နေသည်။ အမျိုးအစား ပုံစံရှိသော ပေါက်ကြားမှုများသည် တညီတညွတ်တည်း noise ထက် ပိုကုန်ကျသည် — အဘယ်ကြောင့်ဆိုသော် ၎င်းတို့ပေါ်တွင် ဘာမျှ alert မလုပ်သောကြောင့်ဖြစ်သည်။ ငြင်းပယ်မှု လမ်းကြောင်းကို ဖယ်ရှားလိုက်လျှင် ကျန်ရှိသည့်အရာများ — formatting ချို့ယွင်းချက်များ, ဖြတ်ထုတ်ခြင်းများ, ရှုပ်ထွေးသော စာသားများ — သည် ခေါင်းစဉ်နှင့် ဆက်စပ်မှုမရှိတော့ဘဲ တိုင်းတာနိုင်လာသည်။

05Context, output ကန့်သတ်ချက်နှင့် ၎င်းတို့ကို budget လုပ်နည်း

gateway ပေါ်ရှိ မော်ဒယ်တိုင်းသည် ကန့်သတ်ချက်တူတူ ဝေမျှသည် —

Context သည် ဝေမျှထားသော budget တစ်ခု ဖြစ်သည် — prompt ထပ် output သည် 262,144 အတွင်း အတူတကွ ဝင်ကျရမည်၊ ထို့ကြောင့် call တစ်ခုတွင် လက်တွေ့ input ကန့်သတ်ချက်မှာ ခန့်မှန်း token 245,000 ခန့်ဖြစ်ပြီး ခန့်မှန်း အင်္ဂလိပ်စကားလုံး 180,000 ခန့်ဖြစ်သည်။ Structured အလုပ်အတွက် token 16,384 output cap သည် ပိုခက်ခဲသော ကန့်သတ်ချက်ဖြစ်ပြီး လူများကို အံ့သြစေတတ်သော အချက်ဖြစ်သည် — record တစ်ခုလျှင် object တစ်ခု ထုတ်ပေးသော schema တစ်ခုသည် window ပြည့်မီ ကြာမြင့်စွာ ၎င်းကို ထိရောက်သည်။ ၎င်းကို တွန်းလှန်နိုင်သော ပုံစံနှစ်ခု —

• Input ကျယ်ပြန့်၊ output ကျဉ်း။ Contract, filing သို့မဟုတ် log window တစ်ခုလုံးကို context ထဲသို့ တွန်းသွင်းပြီး object ကျစ်လျစ်တစ်ခုကို တောင်းဆိုပါ။ Input token သည် output token ၏ လေးပုံတစ်ပုံသာ ကုန်ကျသောကြောင့် ဈေးနှုန်းက များစွာ ဖတ်ရှုပြီး နည်းနည်းသာ ရေးသားခြင်းကို ဆုချသည်။
• Byte count မဟုတ်ဘဲ record boundary ပေါ်တွင် chunk ခွဲပါ။ မော်ဒယ်က seam ကို မြင်နိုင်သည့်နေရာတွင် ခွဲပါ။ စာကြောင်း အလယ်တွင် ဖြတ်ချထားသော record တစ်ခုသည် ထင်ရှားသော failure တစ်ခုအစား ယုံကြည်စွာ မှားနေသော object တစ်ခုကို ထုတ်ပေးသည်။

Hy3 ၏ ဖော်ပြထားသော context ရှည်လျား retrieval အားသာချက် — AA-LCR တွင် 73.4 နှင့် MRCR long-dialogue recall တွင် 42.9% မှ 75.1% သို့ ခုန်တက်လာမှု — သည် ပထမ ပုံစံ မှီခိုနေသည့် စွမ်းရည် အတိအကျဖြစ်ပြီး ကောင်းစွာ ရေးသားခြင်းနှင့် ကွဲပြားသော စွမ်းရည် ဖြစ်သည်။

06အနိမ့်ဆုံးနှုန်းနှင့် တကယ့် pipeline တစ်ခု၏ ဂဏန်းသင်္ချာ

Hy3 သည် 1M input token လျှင် $0.50၊ 1M output token လျှင် $2.00 — ကက်တလောက် အနိမ့်ဆုံးနှုန်း၌ ရှိပြီး MiMo-V2.5, MiMo-V2.5-Pro, DeepSeek-V4-Flash-0731 နှင့် MiniMax-M3 တို့နှင့် ဝေမျှသည်။ ကိုယ်စားပြု load များဖြင့် တွက်ချက်ကြည့်လျှင် —

Workload	Call တစ်ခုလျှင် Input	Call တစ်ခုလျှင် Output	Call တစ်ခုလျှင် ကုန်ကျစရိတ်	Call 1M လျှင်
Field extraction	1,200	300	$0.0012	$1,200
Document classification	3,000	120	$0.0018	$1,800
Long-doc summary to schema	40,000	900	$0.0218	$21,800
Window အပြည့် ခွဲခြမ်းစိတ်ဖြာမှု	240,000	2,000	$0.1240	$124,000

ဆုံးဖြတ်ချက်ကို ပြောင်းလဲစေသော ကိန်းမှာ headline နှုန်း မဟုတ်ဘဲ retry ပြီးနောက် effective နှုန်း ဖြစ်သည်။ မော်ဒယ်နှစ်ခု ဈေးနှုန်းတူပြီး တစ်ခုက call ၏ 6% ၌ validation ကို ရှုံးနိမ့်ပြီး နောက်တစ်ခုက 1.5% ၌ ရှုံးနိမ့်လျှင် drift ပိုများသော မော်ဒယ်သည် ခန့်မှန်း call 4.5% ပိုများစွာ run လုပ်သည် — ခံနိုင်ရည်ရှိသေးသည်။ ဆိုးဝါးမှုသည် tail ၌ ရှိသည် — retry ခံရသော call များသည် နှစ်ဆ ကြာသောကြောင့် traffic ၏ မြင်သာသော အစိတ်အပိုင်းတစ်ခုအတွက် p99 latency သည် ခန့်မှန်း နှစ်ဆ ဖြစ်ကာ ကြိမ်နှစ်ခါ ရှုံးနိမ့်သည့်အရာသည် လက်တွေ့ လုပ်ငန်းအဖြစ် ပြောင်းသွားသည်။ တစ်နေ့လျှင် call တစ်သန်း၌ ၎င်းသည် တစ်စုံတစ်ဦးက ဖတ်ရမည့် record ထောင်ချီ ဖြစ်သည်။

ထို့ကြောင့် အနိမ့်ဆုံးနှုန်း၌ 8-bit tier ဆီသို့ argument ရှိသည် — ဤနေရာတွင် fidelity အတွက် premium ငွေပေးနေခြင်း မဟုတ်ဘဲ retry ဂဏန်းသင်္ချာသည် အခမဲ့ ငွေ ဖြစ်နေသည်။ 3-bit မော်ဒယ်တစ်ခု ဈေးသက်သာခဲ့လျှင် ချိန်ညှိစရာ ကုန်သွယ်မှု တကယ် ရှိမည် — Hy3 သည် ကက်တလောက်ထဲရှိ ဈေးသက်သာဆုံးအရာနှင့် ဈေးနှုန်းတူညီစွာ ကုန်ကျသည်။

07API dialect သုံးမျိုး၊ မော်ဒယ်တစ်ခု

Hy3 ကို gateway dialect သုံးမျိုးလုံးတွင် streaming နှင့်အတူ ချိတ်ဆက်နိုင်သည်။ မော်ဒယ်တူ၊ weight တူ၊ ကန့်သတ်ချက်တူ — သင့်ရှိပြီးသား SDK နှင့် ကိုက်ညီသောတစ်ခုကို ရွေးချယ်ပါ။

Endpoint	Dialect	ဘယ်အချိန် သုံးရမလဲ
/v1/chat/completions	OpenAI	OpenAI SDK, LangChain သို့မဟုတ် LlamaIndex ရှိလျှင်။ base URL ကို ဤနေရာသို့ ညွှန်းပြီး model id ကို ပြောင်းပါ။
/v1/messages	Anthropic	Anthropic SDK ပေါ်တွင် ရှိပြီး translation layer မလိုဘဲ content block များ လိုချင်လျှင်။
/v1/responses	Responses	typed output နှင့် server-side state ပါသော newer request ပုံစံ လိုချင်လျှင်။

Hy3 သည် reasoning_effort အပါအဝင် tool calling နှင့် reasoning ကိုလည်း ထောက်ပံ့သည်။ Extraction အလုပ်အတွက် အသုံးဝင်သော လှုပ်ရှားမှုမှာ ပုံမှန်အားဖြင့် reasoning ကို လျှော့ချခြင်း ဖြစ်သည် — ရှင်းလင်းစွာ သတ်မှတ်ထားသော schema တစ်ခုသည် သန့်ရှင်းသော စာသားပေါ်တွင် ရှိနေလျှင် thinking token များသည် သင် ငွေပေးရသော output token နှင့် သင် စောင့်ရသော latency ဖြစ်ပြီး အနည်းငယ်သာ အကျိုးရှိသည်။ ရှင်းလင်းစွာ ရှုပ်ထွေးနေသော input အတွက်သာ effort budget ကို သုံးစွဲပါ။

Request နှင့် response reference အပြည့်အစုံ, parameter စာရင်းများ, streaming semantics နှင့် interactive playground တစ်ခုကို API documentation တွင် ကြည့်ရှုနိုင်သည်။

08W8A16 မော်ဒယ် သုံးခုအနက် ရွေးချယ်ခြင်း

Fidelity အမြင့်ဆုံး tier ပေါ်တွင် မော်ဒယ် သုံးခု ရှိပြီး အားလုံးသည် အနိမ့်ဆုံးနှုန်း၌ ရှိသည်။ ရွေးချယ်မှုသည် modality ပေါ်တွင် အများစု မူတည်သည် —

Model	Vision	json_schema	Price in / out	ဘာအတွက် ရွေးချယ်ရသလဲ
Hy3 · W8A16	မရှိပါ	ရှိသည်	$0.50 / $2.00	စာသားသာ structured pipeline များ, tool orchestration, context ရှည်လျား retrieval
MiMo-V2.5-Pro · W8A16	မရှိပါ	ရှိသည်	$0.50 / $2.00	MiMo line ၏ Pro tuning ကို လိုချင်သော စာသားသာ အလုပ်
MiMo-V2.5 · W8A16	ရှိသည်	ရှိသည်	$0.50 / $2.00	ရုပ်ပုံပါဝင်သော မည်သည့်အရာမဆို — scan ပြုလုပ်ထားသော document, screenshot, ဓာတ်ပုံများ

သင့် input တစ်စိတ်တစ်ပိုင်းမျှသည် ရုပ်ပုံတစ်ခု ဖြစ်လျှင် ဆုံးဖြတ်ချက်ကို သင့်အတွက် လုပ်ပြီးသား ဖြစ်သည် — Hy3 သည် စာသားသာ ဖြစ်သည် — scan ပြုလုပ်ထားသော PDF, screenshot နှင့် ဓာတ်ပုံများကို MiMo-V2.5 ဆီသို့ ပို့ပါ။ input သည် တကယ့် စာသား ဖြစ်လျှင် Hy3 ၏ agentic tool use, context ရှည်လျား recall နှင့် hallucination ဖော်ပြထားချက် နည်းမှုသည် pipeline အလုပ်နှင့် အတိုက်ရိုက်ဆုံး ကိုက်ညီသည်။ သုံးခုစလုံး ဈေးနှုန်းတူညီသောကြောင့် သင့် schema ကို ၎င်းတို့ထဲမှ နှစ်ခုအပေါ် record တကယ့် အရေအတွက်ရာနှင့်ချီ၌ run ကြည့်ပြီး parse rate ကို နှိုင်းယှဉ်ပါ; ၎င်းသည် ဇယားတစ်ခုခုထက် — ဤဇယားပါ အပါအဝင် — ပိုကောင်းစွာ ဆုံးဖြတ်ပေးမည် ဖြစ်သည်။

09Hy3 ဘယ်နေရာမှာ ကောင်းသလဲ

• Volume များသော field extraction။ Contract, filing, incident report, transcript, ဆေးဘက်ဆိုင်ရာ မှတ်စုများ, တရားရုံး record များ — document တိုင်းအတွက် typed object တစ်ခု ရလဒ်ဖြစ်ပြီး volume က retry ကို စျေးကြီးစေသည့် မည်သည့်နေရာမဆို။
• Scale ကြီးသော classification နှင့် routing။ Enum output ပိတ်ထားသည့်နေရာများ — မော်ဒယ်၏ တန်ဖိုးအားလုံးသည် အမျိုးအစားအသစ် ဘယ်တော့မှ ဖန်တီးမည် မဟုတ်ခြင်း ဖြစ်သည်။
• လုံခြုံရေးနှင့် threat-intel corpus များ။ Malware write-up, exploit disclosure နှင့် phishing နမူနာများ — filter ပါသော မော်ဒယ်များကို ငြင်းပယ်စေတတ်သော ပစ္စည်းများနှင့် အမျိုးအစား ပုံစံရှိသော ပေါက်ကြားမှုတစ်ခုက ရည်ရွယ်ချက်ကို ရှုံးနိမ့်စေသည့်နေရာ။
• ရပ်တန့်နေခြင်း ဆက်လက် မဖြစ်ရသော tool-calling agent များ။ 8-bit argument fidelity ဆိုသည်မှာ သင့် function များထံသို့ ပေးအပ်သော JSON သည် parse ဖြစ်ခြင်း ဆိုလိုသည်; ချို့ယွင်းနေသော tool call တစ်ခုသည် အနည်းငယ် ညံ့ဖျင်းသော အဖြေတစ်ခု မဟုတ်ဘဲ ရပ်တန့်နေသော agent တစ်ခု ဖြစ်သည်။
• Document ရှည်များကို ဖွဲ့စည်းပုံအဖြစ် ခွဲခြမ်းစိတ်ဖြာခြင်း။ filing တစ်ခုလုံး ဝင်၍ object ကျစ်လျစ်တစ်ခု ထွက်သည်။
• Content moderation နှင့် policy သုတေသန။ filter ပါသော မော်ဒယ်တစ်ခု ဖတ်ရန် ငြင်းပယ်သည့် ပစ္စည်းကို label ချခြင်းသည် ရပ်တည်နေသော trust-and-safety ပြဿနာတစ်ခု ဖြစ်ပြီး; strict schema ပါသော filter မပါသော မော်ဒယ်တစ်ခုက ၎င်းကို တိုက်ရိုက် ဖြေရှင်းပေးသည်။

ကိုက်ညီမည် မဟုတ်သည့်နေရာ — ရုပ်ပုံပါသော မည်သည့်အရာမဆို (MiMo-V2.5 ကို သုံးပါ)၊ ထို့ပြင် Tencent ကိုယ်တိုင်၏ ဇယားက Hy3 ကို SWE-bench Verified ၌ GLM-5.2 ထက် နောက်ကျစေပြီး DeepSWE ၌ အများကြီး နောက်ကျစေသော autonomous multi-file software engineering။

Benchmark ကိန်းဂဏန်းများသည် ယှဉ်ပြိုင်ဘက် ကိန်းများ အပါအဝင် Tencent ဖော်ပြချက်များ ဖြစ်ပြီး ဤဆောင်းပါး ရေးသားချိန်တွင် သီးခြား အတည်ပြုမှု ဆိုင်းငံ့ဆဲ ဖြစ်သည်။ ကုန်ကျစရိတ် ကိန်းများသည် ကျွန်ုပ်တို့ ထုတ်ဝေထားသော $0.50 / $2.00 နှုန်းများမှ တွက်ချက်ထားသည်။ ဤစာမျက်နှာရှိ ကိန်းဂဏန်း မည်သည်မှ Shannon-run benchmark သို့မဟုတ် ခန့်မှန်းချက် မဟုတ်ပါ။

10မေးလေ့ရှိသော မေးခွန်းများ

---

Sources: Tencent Hunyuan model cards · Hy3 repository · Hunyuan-Large: An Open-Source MoE Model (arXiv 2411.02265) · VentureBeat coverage of the Hy3 release။ Foundation benchmark များသည် Tencent ဖော်ပြချက်များ ဖြစ်ပြီး သီးခြား အတည်ပြုမှု ဆိုင်းငံ့ဆဲ ဖြစ်သည်။ Shannon AI ကို Shannon Lab LLC, New Mexico, USA က လည်ပတ်ထားသည်။