ហេដ្ឋារចនាសម្ព័ន្ធ LLM ដែលភ្ជាប់ម៉ូដែលច្រើន៖ វិធីរៀបចំ API gateway, ភាពអាចសង្កេតបាន និងការតាមដានការពិសោធន៍ (LiteLLM, MLflow)

ម៉ោងពីរទៀបភ្លឺ ក្រុមការងារ startup ផ្នែកបំរើអតិថិជន AI មួយបានទទួលសញ្ញាអាសន្ន៖ ការឆ្លើយតបយឺត ហើយអត្រាខុសឆ្គងបានហក់ឡើងខ្ពស់។ វិស្វករបានបើកមើលប្រព័ន្ធខាងក្រោយ ប៉ុន្តែមិនអាចប្រាប់បានទេថាបញ្ហាវាស្ថិតនៅត្រង់ណា—ព្រោះពួកគេបានភ្ជាប់ API របស់ម៉ូឌែលបីផ្សេងគ្នាក្នុងពេលដំណាលគ្នា ខ្លះប្រើប្រាស់របស់ក្រុមហ៊ុនផ្គត់ផ្គង់ A ខ្លះទៀតប្រើប្រាស់របស់ B ឯកូដ (Code) គឺពោរពេញទៅដោយកូដលក្ខខណ្ឌ if-else ក្នុងការប្តូរទៅមក ហើយគ្មានកន្លែងណាដែលអាចឱ្យពួកគេមើលឃើញមួយភ្លែតដឹងថា «ពេលនេះម៉ូឌែលរបស់ក្រុមហ៊ុនណាមួយដែលកំពុងយឺត ក្រុមហ៊ុនណាកំពុងរាយការណ៍ពីកំហុស ឬមួយខែនេះបានចាយប្រាក់អស់ប៉ុន្មាននោះឡើយ»។ ពួកគេមិនមែនសរសេរកូដមិនកើតទេ តែពួកគេខ្វះស្រទាប់ហេដ្ឋារចនាសម្ព័ន្ធ (Infrastructure) មួយកម្រិត។

នេះជាឧបសគ្គដែលក្រុមការងារ AI ជាច្រើនបានជួបប្រទះនៅពាក់កណ្តាលឆ្នាំ 2026៖ ម៉ូឌែលខ្លួនវាគឺមិនពិបាកប្រើនោះទេ អ្វីដែលពិបាកគឺនៅពេលដែលអ្នកត្រូវប្រើម៉ូឌែលជាច្រើនក្នុងពេលដំណាលគ្នា ហើយត្រូវដាក់ឱ្យដំណើរការក្នុងបរិយាកាស Production ស្រទាប់មូលដ្ឋានទាំងមូលនៃ «ការតភ្ជាប់ ការសង្កេត និងការធ្វើពិសោធន៍» គឺជាវិស្វកម្មដ៏ស្មុគស្មាញ។ អត្ថបទនេះនឹងពន្យល់បំបែកហេដ្ឋារចនាសម្ព័ន្ធកម្រិតនេះជាបីផ្នែកឱ្យបានច្បាស់លាស់។

ហេតុអ្វីបានជាបញ្ហานี้មានសារៈសំខាន់នាពេលបច្ចុប្បន្ន

ពីរឆ្នាំមុន កម្មវិធី AI ភាគច្រើនគ្រាន់តែភ្ជាប់ម៉ូឌែលតែមួយ និងតភ្ជាប់ API មួយក៏អាចចាប់ផ្តើមការងារបានបាត់ទៅហើយ។ ប៉ុន្តែក្នុងរយៈពេលពាក់កណ្តាលឆ្នាំកន្លងមកនេះ ក្រុមការងារដែលខ្ញុំបានឃើញគឺស្ទើរតែទាំងអស់បានឈានឆ្ពោះទៅរក «ម៉ូឌែលច្រើន»៖ ការវែកញែកកម្រិតខ្ពស់ប្រើប្រាស់ម៉ូឌែលកម្រិតកំពូល (Flagship) កិច្ចការប្រេកង់ខ្ពស់ដែលងាយស្រួលគឺប្រើប្រាស់ម៉ូឌែលតូចដែលមានតម្លៃថោកនិងលឿន ចំណែកឯសេណារីយ៉ូខ្លះវិញដើម្បីធានាទិន្នន័យក្នុងស្រុកគឺប្រើប្រាស់ម៉ូឌែល Open Source ដែលដាក់ឱ្យដំណើរការដោយខ្លួនឯង។ ខ្ញុំក៏បានរៀបរាប់เรื่องនេះនៅក្នុងអត្ថបទ ទិដ្ឋភាពទូទៅនៃភ្នាក់ងារសរសេរកូដ AI ក្នុងឆ្នាំ 2026 ផងដែរ—ការបែងចែកចរាចរណ៍ម៉ូឌែលច្រើនគឺជាគន្លឹះក្នុងការសន្សំសំចៃថ្លៃដើម។

ប៉ុន្តែម៉ូឌែលច្រើនបាននាំមកនូវបញ្ហាចំនួនបីក្នុងពេលជាក់ស្តែង។ ទីមួយ ទម្រង់ (Format) ប៉ារ៉ាម៉ែត្រ និងការដោះស្រាយកំហុស (Error handling) របស់ API នីមួយៗគឺសុទ្ធតែខុសគ្នា កូដរបស់អ្នកនឹងត្រូវបំពេញពេញដោយកូដឡូជីខលនៃការប្តូរទៅមក។ ទីពីរ អ្នកមិនអាចមើលឃើញរូបភាពរួមបានច្បាស់លាស់—សំណើ (Request) ណាមួយយឺត មួយណាកំពុងមានកំហុស Token ត្រូវចំណាយលើអ្វី ហើយវិក្កយបត្រខែនេះកើតឡើងពីណា គឺសុទ្ធតែត្រូវបានខ្ចាត់ខ្ចាយនៅតាមប្រព័ន្ធខាងក្រោយរបស់ក្រុមហ៊ុននីមួយៗ។ ទីបី អ្នកមិនដឹងថា «ការប្តូរម៉ូឌែល ឬការកែប្រែ Prompt តើវាធ្វើឱ្យលទ្ធផលកាន់តែល្អឡើង ឬក៏កាន់តែអាក្រក់ទៅៗនោះទេ» ព្រោះគ្មានការកត់ត្រា និងប្រៀបធៀបតាមបែបប្រព័ន្ធ។

បញ្ហាទាំងបីនេះ គឺត្រូវចំទៅនឹងស្រទាប់ទាំងបីនៃហេដ្ឋារចនាសម្ព័ន្ធ LLM៖ API gateway (ការតភ្ជាប់រួបរួម), Observability (ការសង្កេតមើលឃើញរូបភាពរួម), និង Experiment tracking (ការតាមដានការធ្វើពិសោធន៍ដឹងពីគុណវិបត្តិនិងគុណសម្បត្តិនៃការកែប្រែ)។ នៅពេលដែលទំហំរបស់ក្រុមការងាររីកធំឡើង ស្រទាប់ទាំងបីនេះនឹងត្រូវតែបំពេញបន្ថែមមិនខាន។

ឧបករណ៍សំខាន់ៗ និងភាពខុសគ្នា

ខ្ញុំនឹងបែងចែកតាមស្រទាប់ទាំងបីនោះ ដោយប្រាប់អ្នកថាស្រទាប់នីមួយៗកំពុងដោះស្រាយបញ្ហាអ្វី និងមានឧបករណ៍តំណាងអ្វីខ្លះ៖

ស្រទាប់ទី១៖ API gateway / ការតភ្ជាប់រួបរួម
អនុញ្ញាតឱ្យអ្នកប្រើប្រាស់ចំណុចប្រទាក់ (Interface) រួបរួមមួយ ដើម្បីហៅប្រើប្រាស់ម៉ូឌែលពីក្រុមហ៊ុនផ្សេងៗ ដោយមិនចាំបាច់សរសេរកូដមួយឈុតសម្រាប់ក្រុមហ៊ុននីមួយៗឡើយ។

• LiteLLM៖ ជាដំណោះស្រាយ Open Source ដែលត្រូវបានគេនិយាយถึงញឹកញាប់បំផុតក្នុងស្រទាប់នេះ។ វាជួយអ្នកភ្ជាប់ទៅកាន់អ្នកផ្គត់ផ្គង់ម៉ូឌែលជាច្រើនដោយប្រើទម្រង់ដូចគ្នា ហើយថែមទាំងអាចធ្វើ Load balancing កំណត់ Backup (ពេលក្រុមហ៊ុនណាមួយដាច់ គឺស្វ័យប្រវត្តិប្តូរទៅក្រុមហ៊ុនផ្សេង) ក៏ដូចជាគ្រប់គ្រងការប្រើប្រាស់ និងថវិកាសម្រាប់ប្របម្រុងគម្រោងនីមួយៗផងដែរ។ ប្រសិនបើអ្នកចانបធ្វើការបែងចែកម៉ូឌែលច្រើន វាជាទូទៅគឺជាគ្រឹះស្ថានដ៏សំខាន់។

ស្រទាប់ទី២៖ Observability (ការសង្កេត)
អនុញ្ញាតឱ្យអ្នកមើលឃើញច្បាស់នូវអ្វីដែលបានកើតឡើងលើសំណើ (Request) នីមួយៗ—ភាពយឺតយ៉ាវ (Latency) កំហុស (Errors) Token តម្លៃចំណាយ និងសូម្បីតែ Prompt និង Response ក្នុងជំហាននីមួយៗ។

• Langfuse៖ ជាវេទិកាសង្កេតដែលត្រូវបានរចនាឡើងជាពិសេសសម្រាប់កម្មវិធី LLM ដែលអាចតាមដានខ្សែសង្វាក់នៃការហៅប្រើប្រាស់ពេញលេញ កត់ត្រា Prompt និង Response រាប់ស្ថិតិថ្លៃដើម និងអាចតាមដានរកមើលកំហុសដល់ជំហានដែលមានបញ្ហាពេលមានរឿងកើតឡើង។
• Helicone៖ ក៏ផ្តោតលើការត្រួតពិនិត្យ និងការវិភាគថ្លៃដើមផងដែរ ដែលល្បីល្បាញដោយសារភាពងាយស្រួលក្នុងការតភ្ជាប់ សាកសមសម្រាប់ក្រុមការងារដែលចង់បំប្លែងភាព «មើលមិនឃើញ» ឱ្យទៅជា «មើលឃើញ» យ៉ាងឆាប់រហ័ស។

ស្រទាប់ទី៣៖ Experiment tracking (ការតាមដានការធ្វើពិសោធន៍)
អនុញ្ញាតឱ្យអ្នកកត់ត្រាតាមបែបប្រព័ន្ធថា «តើលើកនេះខ្ញុំបានកែប្រែអ្វីខ្លះ និងលទ្ធផលយ៉ាងណាដែរ» ជាជាងការវិនិច្ឆ័យល្អអាក្រក់ដោយផ្អែកលើការចងចាំ។

• MLflow៖ ជាឧបករណ៍ចាស់វស្សាក្នុងវិស័យម៉ាស៊ីនរៀន (Machine Learning) ដែលក្នុងរយៈពេលពីរឆ្នាំនេះបានពង្រឹងយ៉ាងខ្លាំងក្លាលើការគាំទ្រ LLM និង GenAI ដែលអាចតាមដានការពិសោធន៍ គ្រប់គ្រង Version និងវាយតម្លៃលទ្ធផល។ ប្រសិនបើក្រុមការងាររបស់អ្នកមានផ្ទៃខាងក្រោយផ្នែក ML ស្រាប់ នោះវាជាការបន្តវេនធម្មជាតិមួយ។
• Weights & Biases៖ ក៏ជាជម្រើសដ៏ពេញនិយមសម្រាប់ការតាមដាន និងការវាយតម្លៃការពិសោធន៍ផងដែរ ដែលមានមុខងារ Visualization ល្អ និងងាយស្រួលក្នុងការចែករំលែកលទ្ធផលពេលក្រុមការងារសហការគ្នា។

สิ่งที่ត្រូវរំលឹកគឺថា ដែនកំណត់នៃស្រទាប់ទាំងបីនេះកាន់តែព្រិលទៅៗនៅក្នុងឆ្នាំ 2026—ឧបករណ៍ជាច្រើនបានចាប់ផ្តើមចូលទៅកាន់ទឹកដីរបស់គ្នាទៅវិញទៅមក ដោយវេទិកាเดียวធ្វើទាំងការសង្កេត និងការធ្វើពិសោធន៍ក្នុងពេលតែមួយ។ ដូច្នេះកុំសូវប្រកាន់ពេកលើការចាត់ថ្នាក់ សូមស្គាល់ខ្លួនឯងសិនថាខ្វះផ្នែកណា។

វិធីប្រើប្រាស់ជាក់ស្តែង (វិធីសាស្រ្តតំឡើងបន្តបន្ទាប់គ្នា)

មិនមែនគ្រប់ក្រុមការងារទាំងអស់សុទ្ធតែត្រូវប្រើប្រាស់គ្រប់ឈុតតាំងពីដំបូងឡើយ។ យោបល់របស់ខ្ញុំគឺត្រូវបន្ថែមតាមកម្រិតនៃការឈឺចាប់៖

1. មានម៉ូឌែលត្រឹមតែមួយ ឬពីរ និងមិនទាន់មានបរិមាណច្រើន៖ កុំទាន់ប្រញាប់ដាក់ហេដ្ឋារចនាសម្ព័ន្ធ។ ប្រើវិធីសាស្រ្តដោះស្រាយដោយដៃ និងកត់ត្រាដោយខ្លួនឯង ល្មមប្រើបានហើយ កុំធ្វើវិស្វកម្មលើសហេតុផល (Over-engineering)។
2. ចាប់ផ្តើមត្រូវបែងចែកចរាចរណ៍ម៉ូឌែលច្រើន៖ ពេលនេះត្រូវដាក់ API gateway មុន។ ប្រើ LiteLLM ដើម្បីបង្រួបបង្រួមការហៅប្រើប្រាស់ម៉ូឌែលទាំងអស់ទៅជាចំណុចប្រទាក់តែមួយ បន្ទាប់មកពេលប្តូរម៉ូឌែល ឬបន្ថែម Backup គឺគ្រាន់តែកែប្រែកន្លែងតែមួយ មិនចាំបាច់ប៉ះពាល់ដល់កូដគ្រប់កន្លែងនោះទេ។
3. ដាក់ឱ្យដំណើរការក្នុង Production និងចាប់ផ្តើមមានអ្នកប្រើប្រាស់ពិតប្រាកដ៖ បំពេញបន្ថែមនូវមុខងារ Observability។ កត់ត្រាភាពយឺតយ៉ាវ កំហុស និងតម្លៃចំណាយនៃសំណើ (Request) នីមួយៗ ដើម្បីឱ្យមានតម្រុយតាមដានពេលមានបញ្ហា។ នៅពេលដែលអ្នកត្រូវបានគេទូរស័ព្ទហៅក្រោកនៅម៉ោងពីរទៀបភ្លឺ អ្នកនឹងថ្លែងអំណរគុណដល់ស្រទាប់នេះ។
4. ចាប់ផ្តើមសិក្សាស្រាវជ្រាវបែបស៊ីជម្រៅដើម្បីកែសម្រួលប្រសិទ្ធភាព៖ បំពេញបន្ថែម Experiment tracking។ រាល់ពេលដែលកែប្រែ Prompt ប្តូរម៉ូឌែល ឬកែសម្រួលប៉ារ៉ាម៉ែត្រ គឺត្រូវកត់ត្រា និងប្រៀបធៀបតាមប្រព័ន្ធ ដោយប្រើ MLflow ឬ Weights & Biases ដើម្បីបំប្លែងភាព «ផ្អែកលើអារម្មណ៍» ឱ្យទៅជា «មានទិន្នន័យច្បាស់លាស់»។
5. ងាកមកភ្ជាប់ស្រទាប់ទាំងបីចូលគ្នា៖ ក្នុងដំណាក់កាល முதிរភាព (Mature) ត្រូវអនុញ្ញាតឱ្យការហៅប្រើប្រាស់របស់ Gateway នាំយកការសង្កេតមកជាមួយដោយស្វ័យប្រវត្តិ និងអនុញ្ញាតឱ្យលទ្ធផលនៃការពិសោធន៍អាចប្រៀបធៀបជាមួយដំណើរការលើប្រព័ន្ធអនឡាញ ដើម្បីបង្កើតជា vòng khép kín (Closed-loop)។

ឧបសគ្គទូទៅ និងយោបល់

• ការធ្វើវិស្វកម្មលើសហេតុផល គឺជាការខ្ជះខ្ជាយដ៏ធំបំផុត៖ ប្រសិនបើអ្នកនៅតែកំពុងផ្ទៀងផ្ទាត់ទិសដៅផលិតផល និងមានបរិមាណសំណើត្រឹមតែពីរខ្ទង់ក្នុងមួយថ្ងៃ ប៉ុន្តែប្រញាប់ប្រញាលដាក់ហេដ្ឋារចនាសម្ព័ន្ធពេញលេញ វាគឺជាការរកការងារបន្ថែមឱ្យខ្លួនឯងសុទ្ធសាធ។ ហេដ្ឋារចនាសម្ព័ន្ធត្រូវតែលូតលាស់តាមកម្រិតនៃការឈឺចាប់ មិនមែនកាន់តែលឿនកាន់តែดีនោះទេ។
• Gateway នឹងក្លាយជាចំណុចខ្សោយតែមួយ (Single point of failure)៖ ចរាចរណ៍ទាំងអស់ឆ្លងកាត់ស្រទាប់នេះ បើវាដាច់ គឺដាច់ទាំងអស់គ្នា។ ប្រសិនបើអ្នកសាងសង់ដោយខ្លួនឯង អ្នកត្រូវតែធានាភាពអាចរកបានខ្ពស់ (High availability) របស់វាដោយខ្លួនឯង កុំផ្ញើជីវិតរបស់អ្នកទៅលើ Node ដែលគ្មាន Backup ឱ្យសោះ។
• ទិន្នន័យសង្កេតលាក់បាំងនូវព័ត៌មានផ្ទាល់ខ្លួន (PII)៖ នៅពេលដែលអ្នកកត់ត្រា Prompt និង Response ពេញលេញ អ្នកប្រហែលជាបានរក្សាទុកទិន្នន័យរសើបរបស់អ្នកប្រើប្រាស់ជាមួយផងដែរ។ មុនពេលកត់ត្រា សូមគិតឱ្យបានច្បាស់ថាតើត្រូវបិទបាំងវាដែរឬទេ ជាពិសេសនៅក្នុងឧស្សាហកម្មដែលមានបទប្បញ្ញត្តិគ្រប់គ្រងតឹងរ៉ឹង។
• ការសង្កេតតម្លៃចំណាយត្រូវធ្វើឱ្យបានឆាប់៖ អ្វីដែលងាយនឹងធ្លាក់ចេញពីការគ្រប់គ្រងបំផុតសម្រាប់ម៉ូឌែលច្រើនគឺវិក្កយបត្រ។ ប្រសិនបើអ្នករង់ចាំរហូតដល់ទទួលបានវិក្កយបត្រទើបដឹងថាការចាយប្រាក់ហួសហេតុពេក គឺវាអាចយឺតពេលទៅហើយ ដូច្នេះត្រូវដាក់បញ្ចូលតម្លៃចំណាយទៅក្នុង Observability ចាប់ពីថ្ងៃដំបូង។
• កុំឱ្យ «ឧបករណ៍ ML របស់ក្រុមហ៊ុនធំៗ» ធ្វើឱ្យអ្នកភ័យខ្លាច៖ ឧបករណ៍ដូចជា MLflow ស្តាប់ទៅហាក់ដូចជាធ្ងន់ធ្ងរ ប៉ុន្តែអ្នកអាចប្រើប្រាស់ត្រឹមតែផ្នែកដែលអ្នកត្រូវការបានហើយ មិនចាំបាច់យកមកដាក់ទាំងមូលនោះទេ។

ទស្សនវិស័យពី TheAI學院

រឿងនេះមិនមែនជាការទាក់ទាញភ្នែក គ្មាន Demo ស្រស់ស្អាតនោះទេ ប៉ុន្តែវាជាកត្តាកំណត់ថាតើផលិតផល AI របស់អ្នកអាចរស់រានមានជីវិតយ៉ាងស្ថិតស្ថេរក្នុងបរិយាកាស Production បានដែរឬទេ។ ខ្ញុំធ្លាប់បានឃើញក្រុមការងារជាច្រើនបានខិតខំប្រឹងប្រែងយ៉ាងខ្លាំងលើម៉ូឌែល និង Prompt ប៉ុន្តែត្រូវធ្លាក់ខ្លួនដួលរលំដោយសារតែប្រហោងនៃហេដ្ឋារចនាសម្ព័ន្ធ ដូចជា «ពេលដាក់ឱ្យប្រើប្រាស់ហើយមានបញ្តើកើតឡើងតែមិនដឹងមូលហេតុ» ឬ «ពេលវិក្កយបត្រមកដល់ទើបដឹងថាថវិកាត្រូវដុតបំផ្លាញអស់រលីង» ជាដើម។

មតិយោបល់៖ ម៉ូឌែលគឺជាម៉ាស៊ីន ឯហេដ្ឋារចនាសម្ព័ន្ធគឺជា לוח 仪表盤 (Dashboards) និងធុងប្រេង—បើគ្មានវាទេ ទោះបីជាអ្នករត់លឿនប៉ុណ្ណាក៏ដោយ ក៏អ្នកគ្រាន់តែជាការរត់ប្រណាំងក្នុងស្ថានភាពដែលមិនដឹងថាប្រេងនៅសល់ប៉ុន្មាននោះដែរ។

យោបល់ជាក់ស្តែងសម្រាប់អ្នកអានជនជាតិតៃវ៉ាន់៖ កុំដាក់ឱ្យប្រើប្រាស់ពេញឈុតក្នុងពេលតែមួយ សូមបំពេញបន្ថែមតាមកម្រិតនៃការឈឺចាប់។ ប្រសិនបើអ្នកគ្រាន់តែជាបុគ្គល ឬក្រុមការងារខ្នាតតូចដែលកំពុងធ្វើពិសោធន៍ ស្រទាប់ទាំងបីនេះអាចត្រូវបានគេមិនអើពើជាបណ្តោះអាសន្ន ប៉ុន្តែនៅពេលដែលអ្នកត្រូវ «ប្រើប្រាស់ម៉ូឌែលជាច្រើនក្នុងពេលដំណាលគ្នា» ជំហានដំបូងគឺត្រូវដាក់ LiteLLM ជាស្រទាប់ Gateway ដែលវាអាចធ្វើឱ្យអ្នកប្តូរម៉ូឌែល និងគ្រប់គ្រងថ្លៃដើមនៅពេលក្រោយមានភាពងាយស្រួលជាងមុន។ នៅពេលដែលអ្នកមានអ្នកប្រើប្រាស់ពិតប្រាកដ និងចាប់ផ្តើមព្រួយបារម្ភអំពីបញ្ហាកើតឡើងនៅពាក់កណ្តាលអធ្រាត្រ ค่อย补上 Observability (បន្ថែមមុខងារសង្កេត)។ សូមគិតថាហេដ្ឋារចនាសម្ព័ន្ធឈុតនេះគឺជាការធានារ៉ាប់រង—ធម្មតាមិនសូវមានអារម្មណ៍ថាត្រូវការវាទេ ប៉ុន្តែវាអាចសង្គ្រោះជីវិតអ្នកបានពេលមានអាសន្ន។ ប្រសិនបើអ្នកចង់ឃើញពីរបៀបដែលម៉ូឌែលទាំងនេះត្រូវបានគេប្រើប្រាស់ក្នុងសេណារីយ៉ូនៃការសរសេរកូដ និងការពិនិត្យឡើងវិញ សូមអានអត្ថបទ ទិដ្ឋភាពទូទៅនៃភ្នាក់ងារសរសេរកូដ AI និង មគ្គុទ្ទេសក៍ឧបករណ៍ពិនិត្យកូដ AI របស់យើងម្តងទៀត។

ប្រភពទិន្នន័យ

• ឯកសារផ្លូវការរបស់ LiteLLM៖ https://docs.litellm.ai
• គេហទំព័រផ្លូវការរបស់ MLflow៖ https://mlflow.org

អត្ថបទនេះគឺជាការពន្យល់សង្ខេបស្តីពីប្រភេទឧបករណ៍ និងវិធីសាស្ត្ររចនាសម្ព័ន្ធ។ ការអាប់ដេតមុខងាររបស់ឧបករណ៍នីមួយៗគឺមានល