Agent លើ Workstation តែមួយ៖ ចំណុចបត់បែននៃ Open-Weight On-Device

សម្រាប់ភាគច្រើននៃយុគ agentic មានបុព្វកថាមួយដែលមិននិយាយ៖ agent សរសេរកូដធ្ងន់ធ្ងរ run លើកុំព្យូទ័ររបស់អ្នកដទៃ។ Model ល្អៗរស់នៅពីក្រោយ cloud API អ្នកជួលពួកវាតាម token ហើយកូដរបស់អ្នក context របស់អ្នក និង prompt របស់អ្នកទាំងអស់ធ្វើដំណើរទៅមកទៅ data center ដែលអ្នកមិនមែនជាម្ចាស់។ បុព្វកថានោះកំពុងបែកបាក់ស្ងាត់ៗ។ Open-weight coding model បានឆ្លងកាត់កម្រិតពីរក្នុងពេលតែមួយ — ល្អគ្រប់គ្រាន់ និងតូចគ្រប់គ្រាន់ — ហើយការផ្សំនេះផ្លាស់ប្ដូរកន្លែងដែល agent អាចរស់នៅ។

ការផ្លាស់ប្ដូរនេះងាយរំលង ព្រោះកម្រិតនីមួយៗតែឯងមិនមែនជាដំណឹងថ្មីទេ។ Open model “ស្ទើរទៅដល់” លើគុណភាពមួយរយៈមកហើយ ហើយ small model តែងតែ run នៅ local។ អ្វីដែលថ្មីក្នុងឆ្នាំ ២០២៦ គឺថា model ដូចគ្នា ឥឡូវនេះជាទាំងពីរ៖ ជិត frontier គ្រប់គ្រាន់លើការវាស់ស្ទង់សរសេរកូដពិតប្រាកដ និងស្រាលគ្រប់គ្រាន់ដើម្បី run លើ hardware ដែលក្រុមតូចមួយមានជាស្រេច។

គម្លាតគុណភាពបានបិទ

ចាប់ផ្ដើមជាមួយសមត្ថភាព ព្រោះអំណះអំណាងទាំងមូលដួលរលំបើ local model អាក្រក់។ វាមិនអាក្រក់ទៀតទេ។

Qwen3-Coder-Next ជាសញ្ញាច្បាស់បំផុត។ វាជា mixture-of-experts model 80-billion-parameter ដែល activate តែ 3 billion parameter នៅ inference ហើយវាដាក់ពិន្ទុ 70.6% លើ SWE-bench Verified ជាមួយ SWE-Agent — 71.1% ជាមួយ MiniSWE-Agent, 71.3% ជាមួយ OpenHands។ ទាំងនោះជា open weight ដែលបង្ហោះលើស 70% លើការវាស់ស្ទង់ដែលរហូតថ្មីៗនេះ ជារបស់ផ្ដាច់មុខនៃ frontier proprietary model។

Devstral Small 2 របស់ Mistral ធ្វើចំណុចដូចគ្នាពីចុងតូច។ នៅត្រឹមតែ 24 billion parameter វាដាក់ពិន្ទុ 68.0% លើ SWE-bench Verified — ហើយ model card ផ្ទាល់របស់ Mistral កត់សម្គាល់ថាវា “ស្មើនឹងកម្រិតដំណើរការ GLM 4.6 និង Qwen 3 Coder Plus ទោះបីប្រើ parameter តិចជាងគួរឱ្យកត់សម្គាល់”។ វាត្រូវបានចេញផ្សាយក្រោម Apache 2.0 license ជាមួយ context window 256k-token។

ការដាក់ស៊ុមដោយស្មោះត្រង់គឺថា model ទាំងនេះនៅតែតាមក្រោយ frontier — 68.0% របស់ Devstral នៅក្រោម Claude Sonnet 4.5 (77.2%) និង GPT 5.1 Codex Max (77.9%) លើការវាស់ស្ទង់ដូចគ្នា។ ប៉ុន្តែគម្លាតឥឡូវនេះប្រហែល ប្រាំបួនពិន្ទុ មិនមែនជារណ្ដៅជ្រៅទេ។ សម្រាប់ផ្នែកធំនៃការងារវិស្វកម្មពិតប្រាកដ — refactor ធម្មតា test ត្រូវសរសេរ bug ត្រូវតាមដាន boilerplate ត្រូវបង្កើត — model ដែលនៅ 60 ខ្ពស់ដល់ 70 ទាបលើ SWE-bench Verified ល្អគ្រប់គ្រាន់ទាំងស្រុង។ សំណួរឈប់ជា “តើ open model មានសមត្ថភាពទេ?” ហើយក្លាយជា “តើប្រាំបួនពិន្ទុចុងក្រោយមានតម្លៃនឹងបោះបង់អ្វីៗទាំងអស់ដែលការ run វានៅ local ផ្ដល់ឱ្យឬទេ?”

តូចគ្រប់គ្រាន់ដើម្បីរស់នៅលើតុរបស់អ្នក

សមត្ថភាពជាពាក់កណ្ដាលនៃរឿង។ ពាក់កណ្ដាលទៀតគឺថាអ្នកពិតជាអាច run ទាំងនេះលើ hardware ដែលអ្នកជាម្ចាស់។

Devstral Small 2 ជាឧទាហរណ៍ស្អាត ព្រោះ Mistral បញ្ជាក់តម្រូវការច្បាស់៖ វា “ស្រាលគ្រប់គ្រាន់ដើម្បី run លើ RTX 4090 តែមួយ ឬ Mac ដែលមាន RAM 32GB ធ្វើឱ្យវាជា model សមរម្យសម្រាប់ local deployment និងការប្រើ on-device។” នោះមិនមែន server rack ទេ។ នោះជា workstation តែមួយ ឬ laptop របស់ developer ម្នាក់។ Model 24-billion-parameter ដែលដាក់ពិន្ទុ 68% លើ SWE-bench Verified run លើ consumer GPU តែមួយ ក្រោម license អនុគ្រោះ — នោះជា agent សរសេរកូដពេញលេញ ឯករាជ្យ ដែលមិនដែលប៉ះ cloud។

Qwen3-Coder-Next ទៅដល់ទីនោះតាមផ្លូវផ្សេង៖ ការរចនា sparse mixture-of-experts។ ការកាន់ parameter 80 billion ប៉ុន្តែ activate តែ 3 billion ក្នុងមួយ token មានន័យថា compute ក្នុងមួយជំហានមធ្យម ទោះបី model ធំ — ស្ថាបត្យកម្មត្រូវបានសាងសង់ដោយច្បាស់ដើម្បីឱ្យ តាមពាក្យក្នុងរបាយការណ៍ “latency, throughput, និង cost ជាដែនកំណត់លំដាប់ទីមួយ”។ Weight ពេញនៅតែត្រូវការស្ថិតនៅ (community quantization ដាក់វាក្នុងថ្នាក់ ~48GB-of-combined-memory ដូច្នេះ workstation high-memory តែមួយ ជាជាង laptop) ប៉ុន្តែគោលការណ៍នៅគង់វង្ស៖ គុណភាពជិត frontier លែងទាមទារម៉ាស៊ីនកម្រិត frontier ទៀតហើយ។

ខ្សែនិន្នាការជាអ្វីដែលសំខាន់។ Sparse activation និង quantization ដែលឆេវឆាវកំពុងទាញ model ដែលមានសមត្ថភាពចុះមកលើ commodity hardware លឿនជាងក្រុមភាគច្រើនបានធ្វើបច្ចុប្បន្នភាពការសន្មតរបស់ខ្លួន។ Cloud API ជាការចាំបាច់ក្នុងឆ្នាំ ២០២៤។ ក្នុងឆ្នាំ ២០២៦ វាកាន់តែជាជម្រើស។

អ្វីដែល on-device ពិតជាផ្ដល់ឱ្យអ្នក

ការ run agent លើ hardware ផ្ទាល់របស់អ្នកមិនមែនជាចំណង់ផ្នែកសោភ័ណភាពទេ។ វាផ្លាស់ប្ដូររឿងបីដែលសំខាន់ចំពោះអាជីវកម្ម។

អធិបតេយ្យភាពទិន្នន័យ។ ពេល model run នៅ local កូដរបស់អ្នក ទិន្នន័យអតិថិជនរបស់អ្នក ឯកសារផ្ទៃក្នុងរបស់អ្នក និង prompt របស់អ្នកមិនដែលចេញពីអគារ។ គ្មានអ្វីត្រូវបានបញ្ជូនទៅ third-party API គ្មានអ្វីត្រូវបាន log លើ server របស់អ្នកដទៃ គ្មានអ្វីស្ថិតក្រោមដែនយុត្តាធិការនៃប្រទេសផ្សេង ឬ retention policy របស់អ្នកលក់។ សម្រាប់ការងារដែលមានបទប្បញ្ញត្តិ — កំណត់ត្រាសុខភាព ទិន្នន័យហិរញ្ញវត្ថុ ប្រព័ន្ធរដ្ឋាភិបាល — នេះជារឿយៗជាភាពខុសគ្នារវាង “យើងអាចប្រើ agent នៅទីនេះ” និង “យើងមិនអាចតាមផ្លូវច្បាប់”។

គ្មានវិក្កយបត្រ per-token។ យើងបានសរសេរពីមុនថា វិក្កយបត្រជា bottleneck ថ្មី — ថា agent loop វែងបញ្ជូន context របស់វាឡើងវិញរាល់ជំហាន ហើយ cost ដែលវាស់កើនលឿន។ On-device ត្រឡប់ច្រាសរចនាសម្ព័ន្ធ cost ទាំងស្រុង៖ អ្នកបង់ម្ដងសម្រាប់ hardware ហើយបន្ទាប់មក inference ឥតគិតថ្លៃជាក់ស្ដែងនៅគែម។ Loop ដែលនឹងចំណាយលុយពិតប្រាកដក្នុងមួយ run លើ metered API ចំណាយអគ្គិសនីលើ box ដែលអ្នកបានទិញរួចហើយ។ សម្រាប់ការងារ agentic ដែលមានបរិមាណច្រើន និងដំណើរការយូរ នោះមិនមែនជាការសន្សំតូចទេ — វាជា model សេដ្ឋកិច្ចផ្សេង គឺ capex ជំនួសឱ្យ opex ដែលគ្មានដែនកំណត់។

Offline និង low-latency។ Local model មិនខ្វល់ពីការតភ្ជាប់អ៊ីនធឺណិតរបស់អ្នក API outage rate limit ឬតំបន់ដែលត្រូវកាត់ផ្ដាច់ទេ។ វាឆ្លើយតបនៅ local-network latency រាល់ពេល។ សម្រាប់កន្លែងណាដែលមានការតភ្ជាប់មិនទៀងទាត់ ឬ workflow ណាដែលមិនអាចទ្រាំនឹងភាពពឹងផ្អែកលើ remote service ដែលនៅគង់ ភាពជឿជាក់នោះជាចំណុចទាំងមូល។

ការដោះដូរជាការពិត ប៉ុន្តែវាជា dial មិនមែនជាជញ្ជាំង

វានឹងមិនស្មោះត្រង់ក្នុងការធ្វើពុតថាគ្មាន cost ទេ។ Local model នៅប្រហែលប្រាំបួនពិន្ទុនៅក្រោយ frontier លើ SWE-bench Verified ហើយលើបញ្ហាដែលពិបាកពិតៗ — ការសម្រេចចិត្តស្ថាបត្យកម្មល្អិតល្អន់ bug multi-system ស្មុគស្មាញ — ពិន្ទុទាំងនោះជាការពិត។ ពេលខ្លះអ្នកនឹងចង់បាន model ខ្លាំងបំផុតក្នុងពិភពលោក ហើយ model នោះនៅតែរស់នៅក្នុង data center។

ប៉ុន្តែនេះជា dial មិនមែនជាជញ្ជាំងទេ។ លំនាំជាក់ស្ដែងជា hybrid៖ run ភាគច្រើន នៃការងារ — 80% ដែលមានបរិមាណច្រើន ធម្មតា និងងាយប៉ះពាល់ទិន្នន័យ — លើ local open-weight model ហើយ route តែបញ្ហាដែលពិបាកបំផុត និងមិនងាយប៉ះពាល់ចេញទៅ frontier API ពេលសមត្ថភាពបន្ថែមរកបាន cost និងការប៉ះពាល់ទិន្នន័យរបស់វា។ ជាក់ស្ដែង៖ local agent ព្រាងកូដ សរសេរ test តាមដាន bug ច្បាស់ៗ និងដោះស្រាយអ្វីៗដែលប៉ះទិន្នន័យរសើប ទាំងអស់លើ box ផ្ទាល់របស់អ្នក ឯ frontier model ត្រូវបានបម្រុងទុកសម្រាប់ការសម្រេចចិត្តស្ថាបត្យកម្មម្ដងក្នុងមួយថ្ងៃ ឬ bug ដែលពិតជាយកឈ្នះ local model — ហើយសូម្បីដូច្នេះ តែបើគ្មានទិន្នន័យការពារនៅក្នុង prompt។ ក្រុមភាគច្រើនរកឃើញថាចំណែក local ខ្ពស់ជាងពួកគេរំពឹងទុកច្រើន។ នោះរក្សាវិក្កយបត្រដែលវាស់ឱ្យតូច រក្សាទិន្នន័យរសើបនៅផ្ទះតាមលំនាំដើម ហើយនៅតែផ្ដល់ឱ្យអ្នកនូវសាច់ដុំ frontier សម្រាប់ភារកិច្ចកម្រដែលត្រូវការ។ ការសម្រេចចិត្ត អ្វី run នៅឯណា ជាប្រភេទនៃការវិនិច្ឆ័យវិស្វកម្មពិតប្រាកដដែលយើងតែងតែអះអាងថាជាការងារពិត — ហើយវាជា សមត្ថភាពគ្មាន GPU និងធន់ ដូចគ្នានៃការសម្រេចចិត្តរបៀបផ្សំ loop ដែលអនុវត្តកម្រិតមួយខ្ពស់ជាង៖ ការផ្សំ fleet។

ហេតុអ្វីនេះអនុគ្រោះអាស៊ីអាគ្នេយ៍

នេះជាផ្នែកដែលសំខាន់បំផុតសម្រាប់តំបន់នេះ ហើយ on-device អាចជាកំណែមុតស្រួចបំផុតតែមួយនៃអំណះអំណាង។ គ្រប់គុណសម្បត្តិនៃការ run agent នៅ local ផ្គូផ្គងផ្ទាល់ទៅការពិតរចនាសម្ព័ន្ធនៃការសាងសង់ AI នៅអាស៊ីអាគ្នេយ៍។

អធិបតេយ្យភាពមិនមែនអរូបីនៅទីនេះទេ។ ធនាគារកម្ពុជា មន្ទីរពេទ្យវៀតណាម ក្រសួងរដ្ឋាភិបាលកម្ពុជា — ស្ថាប័នទាំងនេះជារឿយៗ មិនអាច បញ្ជូនទិន្នន័យរបស់ខ្លួនទៅ cloud បរទេស សម្រាប់ហេតុផលច្បាប់ បទប្បញ្ញត្តិ ឬយុទ្ធសាស្ត្រ។ Agent ដែលមានសមត្ថភាពដែល run ទាំងស្រុង on-premise ជាកន្លែងដែលឯកសារខ្មែរ និងកំណត់ត្រាក្នុងស្រុកមិនដែលចេញពីប្រទេស មិនមែនជារបស់ល្អ-ដែលគួរមាន វាជាកំណែតែមួយដែលអាច deploy បានសោះ។ Open weight ក្រោម Apache 2.0 ក៏មិនអាចត្រូវ embargo ឡើងថ្លៃ ឬ deprecate ចេញពីក្រោមអ្នកបានទេ — អ្នកកាន់ model។

សេដ្ឋកិច្ចសមនឹងតំបន់ស្រាលដើមទុន។ Workstation តែមួយដែល run open-weight agent មាន cost ថេរ អាចទស្សន៍ទាយបាន ហើយវាមិនបង្ហូរលុបលើរាល់ token ដូច metered frontier API ទេ។ ក្រុមតូចមួយនៅភ្នំពេញ ឬ Da Nang អាច run agentic workflow បរិមាណច្រើនលើ hardware ដែលខ្លួនជាម្ចាស់ នៅ cost ដែលខ្លួនគ្រប់គ្រង ហើយ out-margin គូប្រកួតដែលកំពុងបង់ data center របស់សហរដ្ឋអាមេរិកតាម token។ ហើយ offline resilience សំខាន់នៅកន្លែងដែលការតភ្ជាប់នៅតែមិនស្មើ។

Frontier lab នឹងបន្តលក់ model ដែលមានសមត្ថភាពបំផុតតាម token ហើយសម្រាប់បញ្ហាដែលពិបាកបំផុត វានឹងបន្តមានតម្លៃ។ ប៉ុន្តែចំណុចបត់បែនស្ងាត់ៗនៃឆ្នាំ ២០២៦ គឺថាអ្នកលែង ត្រូវការ data center សម្រាប់ការងារភាគច្រើនទៀតហើយ។ Agent ជិត frontier ឥឡូវនេះសមនឹងម៉ាស៊ីនតែមួយដែលអ្នកជាម្ចាស់ — ហើយការជាម្ចាស់ម៉ាស៊ីន model និងទិន្នន័យ ជាទីតាំងធន់ អធិបតេយ្យ និងសន្សំដើមទុនបំផុតក្នុង agentic stack ទាំងមូល។ សម្រាប់តំបន់នេះ នោះមិនមែនជាភាពងាយស្រួលទេ។ វាជាយុទ្ធសាស្ត្រទាំងមូល។