Edge AI ແມ່ນວິທີການປະມວນຜົນແບບຈຳລອງ AI ຢູ່ທີ່ອຸປະກອນປາຍທາງ (ສະມາດໂຟນ, PC, ກ້ອງຖ່າຍຮູບ, ອຸປະກອນອຸດສາຫະກຳ ແລະ ອື່ນໆ) ແທນທີ່ຈະເປັນການປະມວນຜົນໃນ Cloud, ເຊິ່ງໃນນັ້ນການນຳເອົາ Large Language Model (LLM) ມາເຮັດວຽກຢູ່ເທິງອຸປະກອນໂດຍກົງເອີ້ນວ່າ On-device LLM. ສຳລັບວຽກງານທີ່ມີຂໍ້ຈຳກັດ 3 ປະການຄື: "ຄວາມໜ່ວງຕໍ່າ (Low Latency)", "ບໍ່ສາມາດນຳຂໍ້ມູນອອກໄປນອກໄດ້" ແລະ "ການເຊື່ອມຕໍ່ບໍ່ສະຖຽນ" ເຊິ່ງເປັນເລື່ອງຍາກສຳລັບ Cloud LLM, Edge AI ກຳລັງກາຍເປັນທາງເລືອກທຳອິດທີ່ສາມາດນຳໄປໃຊ້ງານໄດ້ຈິງ.

ບົດຄວາມນີ້ຈະຮວບຮວມຂໍ້ມູນຕັ້ງແຕ່ແນວຄວາມຄິດພື້ນຖານຂອງ Edge AI ແລະ On-device LLM, ຄວາມແຕກຕ່າງຈາກ Cloud LLM, ກອບການຕັດສິນໃຈເມື່ອນຳໄປປັບໃຊ້ໃນວຽກງານ, ໄປຈົນເຖິງຂະບວນການນຳໃຊ້ ເພື່ອໃຫ້ພະແນກລະບົບຂໍ້ມູນຂ່າວສານ ແລະ ຜູ້ຮັບຜິດຊອບດ້ານການຂັບເຄື່ອນ DX ທີ່ກຳລັງພິຈາລະນາເລື່ອງ Business AI ໄດ້ນຳໄປໃຊ້. ເປົ້າໝາຍຂອງບົດຄວາມນີ້ແມ່ນເພື່ອໃຫ້ຜູ້ອ່ານສາມາດແຍກແຍະໄດ້ວ່າ ຄວນເລືອກໃຊ້ Edge, ໃຊ້ Cloud ຢ່າງດຽວກໍພຽງພໍແລ້ວ, ຫຼື ຄວນໃຊ້ແບບປະສົມ (Hybrid) ສຳລັບວຽກງານໃນບໍລິສັດຂອງຕົນເອງ.

Edge AI ແມ່ນແນວຄິດການອອກແບບທີ່ "ນຳເອົາ AI ໄປເຮັດວຽກຢູ່ໃກ້ກັບບ່ອນທີ່ຂໍ້ມູນເກີດຂຶ້ນ". ເມື່ອປຽບທຽບກັບ AI ທີ່ອີງໃສ່ການສົ່ງຂໍ້ມູນໄປຍັງ Cloud, ມັນຈະສະແດງພຶດຕິກຳທີ່ແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງໃນ 3 ດ້ານ ຄື: ຄວາມໜ່ວງ (Latency), ຄ່າໃຊ້ຈ່າຍໃນການສື່ສານ, ແລະ ຄວາມເປັນສ່ວນຕົວ.

ໃນທີ່ນີ້, ກ່ອນອື່ນໝົດພວກເຮົາຈະມາຈັດລະບຽບຄວາມສຳພັນລະຫວ່າງ 2 ຄຳສັບ ຄື Edge AI ແລະ On-device LLM, ພ້ອມທັງກຳນົດຕຳແໜ່ງຂອງມັນໃຫ້ຊັດເຈນເມື່ອທຽບກັບ Cloud LLM. ການມີແຜນຜັງແນວຄິດໄວ້ກ່ອນທີ່ຈະເຂົ້າສູ່ລາຍລະອຽດທາງເຕັກນິກ ຈະຊ່ວຍໃຫ້ເຂົ້າໃຈເຖິງຫຼັກການໃນການຕັດສິນໃຈເລືອກໃຊ້ງານທີ່ຈະປາກົດໃນບົດຕໍ່ໆໄປໄດ້ງ່າຍຂຶ້ນ.

Edge AI ແມ່ນແນວຄວາມຄິດທີ່ລວມເອົາ Edge Computing (ການອອກແບບທີ່ປະມວນຜົນໃກ້ກັບແຫຼ່ງກຳເນີດຂໍ້ມູນ) ເຂົ້າກັບ AI ໂດຍການປະຕິບັດການອະນຸມານ (Inference) ຢູ່ທີ່ອຸປະກອນປາຍທາງ, ອຸປະກອນໜ້າງານ ຫຼື ອຸປະກອນ Gateway ແທນທີ່ຈະເປັນ Cloud. ການຢືນຢັນຕົວຕົນດ້ວຍໃບໜ້າໃນສະມາດໂຟນ, ກ້ອງກວດສອບຄຸນນະພາບໃນໂຮງງານ, ແລະ ການກວດຈັບພຶດຕິກຳອັນຕະລາຍຂອງກ້ອງຕິດໜ້າລົດ ລ້ວນແລ້ວແຕ່ເປັນຕົວຢ່າງທີ່ຊັດເຈນຂອງ Edge AI.

ໃນນັ້ນ, ການນຳເອົາ Large Language Model (LLM) ເຊິ່ງເປັນຕົວຂັບເຄື່ອນກະແສ Generative AI ມາເຮັດວຽກຢູ່ເທິງອຸປະກອນ ເອີ້ນວ່າ On-device LLM. ເດີມທີ LLM ຖືກອອກແບບມາໃຫ້ເຮັດວຽກຢູ່ເທິງ GPU Cluster ຂະໜາດໃຫຍ່ໃນ Cloud, ແຕ່ດ້ວຍການພັດທະນາຂອງເຕັກນິກການບີບອັດໂມເດວ (Quantization) ແລະ ໂມເດວຂະໜາດນ້ອຍ (SLM: Small Language Model), ລວມທັງປະສິດທິພາບທີ່ສູງຂຶ້ນຂອງ NPU (Neural Processing Unit) ທີ່ຕິດຕັ້ງຢູ່ໃນສະມາດໂຟນ ແລະ ແລັບທັອບ, ເຮັດໃຫ້ສາມາດປະຕິບັດໂມເດວທີ່ມີຫຼາຍພັນລ້ານພາຣາມິເຕີໄດ້ໃນອຸປະກອນທີ່ຢູ່ໃນມື.

"Local LLM" ແລະ "On-device LLM" ເປັນແນວຄວາມຄິດທີ່ມີສ່ວນຊ້ອນທັບກັນຫຼາຍ ແຕ່ໃນບົດຄວາມນີ້ຈະແຍກອອກຈາກກັນ. Local LLM ມີຄວາມໝາຍກວ້າງກວ່າ ເຊິ່ງໝາຍເຖິງ "ການນຳ LLM ມາເຮັດວຽກໃນ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ບໍລິສັດຄຸ້ມຄອງເອງ (On-premise server ຫຼື ເຄື່ອງ GPU ພາຍໃນບໍລິສັດ)", ສ່ວນ On-device LLM ຈະໝາຍເຖິງກໍລະນີທີ່ເຮັດວຽກຢູ່ "ອຸປະກອນທີ່ຜູ້ໃຊ້ຖື ຫຼື ອຸປະກອນໜ້າງານໂດຍກົງ". ສຳລັບການປຽບທຽບລາຍລະອຽດຂອງ Local LLM ຝັ່ງ Server ສາມາດເບິ່ງໄດ້ທີ່ ການປຽບທຽບການນຳໃຊ້ Local LLM / SLM, ດັ່ງນັ້ນໃນບົດຄວາມນີ້ຈະເນັ້ນໄປທີ່ການຕັດສິນໃຈອອກແບບທີ່ອີງໃສ່ Edge ເປັນຫຼັກ.

Cloud LLM ແລະ Edge AI (On-device LLM) ເຖິງວ່າຈະມີຈຸດປະສົງໃນການ "ໃຊ້ຕົວແບບພາສາ" ຄືກັນ, ແຕ່ການໄຫຼວຽນຂອງຂໍ້ມູນ ແລະ ທີ່ຕັ້ງຂອງ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ນັ້ນມີຄວາມແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງ.

Cloud LLM ມີຈຸດແຂງທີ່ສຸດຄື "ສາມາດເຂົ້າເຖິງຕົວແບບຂະໜາດໃຫຍ່ລ່າສຸດໄດ້ທັນທີ" ເຊິ່ງມີຄວາມໄວໃນການ ເປີດຕົວ ຫຼື Launch ທີ່ບໍ່ສາມາດປຽບທຽບໄດ້. ໃນທາງກົງກັນຂ້າມ, Edge AI ມີຄຸນລັກສະນະທີ່ Cloud ບໍ່ສາມາດເຮັດຕາມໄດ້ໃນທາງໂຄງສ້າງ ຄື "ຂໍ້ມູນບໍ່ອອກຈາກອຸປະກອນ", "ບໍ່ຂຶ້ນກັບສະພາບເຄືອຂ່າຍ" ແລະ "ບໍ່ມີຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມເມື່ອໃຊ້ງານຫຼາຍຂຶ້ນ".

ສິ່ງທີ່ສຳຄັນຄື ທັງສອງຢ່າງນີ້ບໍ່ແມ່ນການເລືອກຢ່າງໃດຢ່າງໜຶ່ງ, ແຕ່ ການປະສົມປະສານທີ່ເໝາະສົມຈະປ່ຽນແປງໄປຕາມຄວາມຕ້ອງການຂອງທຸລະກິດ. ໃນກອບການເຮັດວຽກທີ່ຈະສະແດງໃຫ້ເຫັນໃນຕອນທ້າຍຂອງບົດຄວາມນີ້, ພວກເຮົາຈະຈັດລະບຽບວ່າ ວຽກໃດທີ່ຕົກຢູ່ໃນ 3 ເງື່ອນໄຂນີ້ຄວນເລືອກໃຊ້ Edge ເປັນທາງເລືອກທຳອິດ, ຖ້າບໍ່ດັ່ງນັ້ນໃຫ້ໃຊ້ Cloud LLM, ແລະ ຖ້າການຕັດສິນໃຈຍັງກ້ຳກິ່ງກໍໃຫ້ໃຊ້ໂຄງສ້າງແບບ Hybrid.

ການສົນທະນາເລື່ອງ Edge AI ມີມາຢ່າງຍາວນານ, ແຕ່ໃນໄລຍະ 1-2 ປີມານີ້ ສະຖານະການໄດ້ປ່ຽນແປງໄປຈົນສາມາດເວົ້າໄດ້ວ່າ "On-device LLM ໄດ້ກາຍເປັນທາງອອກທີ່ແທ້ຈິງສຳລັບການນຳໃຊ້ໃນວຽກງານແລ້ວ". ເບື້ອງຫຼັງຂອງເລື່ອງນີ້ມີການປ່ຽນແປງທາງໂຄງສ້າງ 2 ປະການ.

ຢ່າງໜຶ່ງແມ່ນ ການແຜ່ຫຼາຍຢ່າງເຕັມຮູບແບບຂອງ Cloud LLM ເຮັດໃຫ້ບໍລິສັດຕ່າງໆຫັນມາປະເມີນຄ່າ "ຕົ້ນທຶນ, ຄວາມໜ່ວງ (Latency) ແລະ ຄວາມເປັນສ່ວນຕົວ" ໃໝ່ໃນມຸມມອງຂອງການເຮັດວຽກ. ອີກຢ່າງໜຶ່ງແມ່ນ ຄວາມກ້າວໜ້າຂອງການເຮັດ Quantization ແລະ ແບບຈຳລອງຂະໜາດນ້ອຍ (Small Models) ເຮັດໃຫ້ການປະມວນຜົນທີ່ເມື່ອສອງສາມປີກ່ອນຕ້ອງໃຊ້ເຊີບເວີທີ່ມີປະສິດທິພາບສູງ, ປັດຈຸບັນສາມາດເຮັດວຽກໄດ້ເທິງຄອມພິວເຕີໂນດບຸກ ແລະ ສະມາດໂຟນທີ່ມີວາງຈຳໜ່າຍທົ່ວໄປແລ້ວ.

ບໍລິສັດທີ່ນຳເອົາ Cloud LLM ມາປະຍຸກໃຊ້ໃນການດຳເນີນງານ ມັກຈະປະເຊີນກັບ "ອຸປະສັກທີ່ບໍ່ໄດ້ຄາດຄິດ" ຫຼັງຈາກເລີ່ມນຳໃຊ້. ໃນຫຼາຍກໍລະນີ, ອຸປະສັກເຫຼົ່ານັ້ນແມ່ນເລື່ອງຂອງຕົ້ນທຶນ, Latency, ຄວາມເປັນສ່ວນຕົວ ຫຼື ການປະສົມປະສານຂອງປັດໄຈເຫຼົ່ານີ້.

ຕົ້ນທຶນ (Cost): ສຳລັບ Chatbot ພາຍໃນອົງກອນ ຫຼື ລະບົບສະຫຼຸບຂໍ້ມູນແບບ Batch, ໃນຂັ້ນຕອນ PoC ອາດຈະມີຄ່າໃຊ້ຈ່າຍພຽງຫຼັກໝື່ນເຢນຕໍ່ເດືອນ, ແຕ່ເມື່ອຂະຫຍາຍການນຳໃຊ້ໄປສູ່ລະດັບພະນັກງານ 1,000 ຄົນ ແລະ ຕ້ອງປ້ອນຂໍ້ມູນ Log ທັງໝົດເຂົ້າໃນ Model ທຸກຄັ້ງ, ຄ່າໃຊ້ຈ່າຍຕາມຈຳນວນ Token ອາດຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ສຳລັບຝ່າຍບັນຊີທີ່ຕ້ອງການຄວບຄຸມຄ່າໃຊ້ຈ່າຍໃຫ້ຄົງທີ່, ໃບແຈ້ງໜີ້ຄ່າ API ທີ່ອາດຈະເພີ່ມຂຶ້ນເຖິງ 5 ເທົ່າໃນບາງເດືອນນັ້ນ ເປັນເລື່ອງທີ່ໜ້າປວດຫົວໃນການຈັດການງົບປະມານ. ວິທີການເພີ່ມປະສິດທິພາບດ້ານຕົ້ນທຶນ LLM ໂດຍລວມ ສາມາດອ່ານເພີ່ມເຕີມໄດ້ທີ່ ຄູ່ມືການເພີ່ມປະສິດທິພາບຕົ້ນທຶນ LLM.

Latency: Cloud API ຈະມີການເພີ່ມ Overhead ຈາກການສົ່ງຂໍ້ມູນໄປ-ກັບຜ່ານເຄືອຂ່າຍ, ການລໍຖ້າໃນ Queue ແລະ ການປະມວນຜົນແບບ Batch ຢູ່ຝ່າຍ Server. ຖ້າເປັນການນຳໃຊ້ທີ່ຍອມຮັບຄວາມຊ້າໃນລະດັບວິນາທີໄດ້ກໍບໍ່ມີບັນຫາ, ແຕ່ສຳລັບການນຳໃຊ້ເຊັ່ນ: "ການກວດສອບທັນທີທີ່ເຫັນຄົນຜ່ານກ້ອງ" ຫຼື "ການກວດຫາສຽງຜິດປົກກະຕິໃນສາຍການຜະລິດແບບ Real-time", ຄວາມຊ້າໃນລະດັບຫຼາຍຮ້ອຍມິນລີວິນາທີອາດສົ່ງຜົນເສຍຫາຍຮ້າຍແຮງຕໍ່ການດຳເນີນງານ.

ຄວາມເປັນສ່ວນຕົວ / ອະທິປະໄຕຂອງຂໍ້ມູນ (Data Sovereignty): ມີຂໍ້ມູນຫຼາຍຢ່າງທີ່ການສົ່ງຂໍ້ມູນອອກໄປພາຍນອກຖືກຈຳກັດໂດຍກົດລະບຽບ, ສັນຍາ ຫຼື ກົດໝາຍ ເຊັ່ນ: ບັນທຶກທາງການແພດຂອງຄົນເຈັບ, ເອກະສານກູ້ຢືມ, ແບບແຜນການອອກແບບ, ຫຼື ວິດີໂອຈາກສະຖານທີ່ກໍ່ສ້າງທີ່ກຳລັງດຳເນີນງານຢູ່. ໃນບາງກໍລະນີ, ການເຂົ້າລະຫັດຂໍ້ມູນຂອງຜູ້ໃຫ້ບໍລິການ Cloud ຫຼື ສັນຍາການກຳນົດ Region ອາດຈະບໍ່ພຽງພໍທີ່ຈະເຮັດໃຫ້ຜູ້ຮັບຜິດຊອບດ້ານທຳນຽມປະຕິບັດຂໍ້ມູນ (Data Governance) ພາຍໃນອົງກອນຍອມຮັບໄດ້.

Edge AI ຈະມີປະສິດທິຜົນສູງສຸດໃນວຽກງານທີ່ມີຂໍ້ຈຳກັດຢ່າງເຂັ້ມງວດໃນ 3 ດ້ານນີ້. ໃນທາງກັບກັນ, ຖ້າວຽກງານໃດບໍ່ມີຂໍ້ຈຳກັດທີ່ຊັດເຈນໃນທັງ 3 ດ້ານ, ການເລືອກໃຊ້ Cloud LLM ຈະຊ່ວຍໃຫ້ເລີ່ມຕົ້ນໄດ້ໄວຂຶ້ນ.

ສິ່ງທີ່ສະໜັບສະໜູນ On-device LLM ທີ່ເຮັດວຽກໃນວຽກງານທຸລະກິດ ຄືວິວັດທະນາການ 2 ຢ່າງທາງດ້ານຕົວແບບ (Model).

ຢ່າງທີໜຶ່ງ ຄື Quantization. ເປັນເທັກໂນໂລຍີທີ່ບີບອັດນ້ຳໜັກຂອງຕົວແບບຈາກ 16bit ໃຫ້ມີຄວາມລະອຽດຕ່ຳລົງເຫຼືອ 8bit ຫຼື 4bit ເຊິ່ງສາມາດຫຼຸດຜ່ອນ VRAM ແລະ Memory Bandwidth ທີ່ຈຳເປັນໄດ້ຢ່າງຫຼວງຫຼາຍ. ຕາມແນວໂນ້ມທົ່ວໄປ, ການກວດສອບໂດຍຊຸມຊົນລາຍງານວ່າ Q8 (8bit) ແທບບໍ່ພົບການຫຼຸດລົງຂອງຄວາມແມ່ນຍຳເມື່ອທຽບກັບ FP16 ແລະ Q4 (4bit) ກໍຍັງຢູ່ໃນຂອບເຂດທີ່ນຳໄປໃຊ້ງານໄດ້ຈິງໃນບາງໜ້າວຽກ (ເນື່ອງຈາກຂຶ້ນຢູ່ກັບໜ້າວຽກ ແລະ ຂໍ້ມູນ, ຈຶ່ງຈຳເປັນຕ້ອງມີການກວດສອບຊ້ຳໃນວຽກງານຂອງບໍລິສັດຕົນເອງ). ດ້ວຍເຫດນີ້, ຕົວແບບທີ່ເດີມຈຳເປັນຕ້ອງໃຊ້ GPU ຈຶ່ງສາມາດເຮັດວຽກໄດ້ເທິງ CPU, ເຮັດໃຫ້ຂອບເຂດການປະມວນຜົນຂະຫຍາຍໄປເຖິງ Laptop, ສະມາດໂຟນ ແລະ ອຸປະກອນຝັງຕົວ (Embedded devices).

ຢ່າງທີສອງ ຄືການປັບປຸງຄຸນນະພາບຢ່າງວ່ອງໄວຂອງ SLM (Small Language Model). ບໍ່ວ່າຈະເປັນຊຸດ Phi ຂອງ Microsoft, Gemma ຂອງ Google, Llama 3.2 1B / 3B ຂອງ Meta, ຫຼື On-Device Foundation Models ຂອງ Apple, ແຕ່ລະບໍລິສັດຕ່າງກໍພາກັນເປີດຕົວ ຫຼື Launch ຕົວແບບທີ່ຕັ້ງເປົ້າໝາຍວ່າ "ເຖິງຈະມີພຽງຫຼັກພັນລ້ານພາຣາມິເຕີ ແຕ່ກໍມີຄຸນນະພາບທີ່ໃຊ້ງານໄດ້ຈິງໃນໜ້າວຽກສະເພາະ". ສ່ວນຫຼາຍຕົວແບບເຫຼົ່ານີ້ຖືກແຈກຢາຍໃນຮູບແບບ Open-weight model ເຊິ່ງສາມາດນຳໄປ Fine-tuning ໃຫ້ເໝາະສົມກັບວຽກງານຂອງບໍລິສັດໄດ້.

ໃນຄວາມເປັນຈິງ, ສຳລັບສະມາດໂຟນນັ້ນ ໄດ້ກ້າວເຂົ້າສູ່ຂັ້ນຕອນທີ່ On-device LLM ມາດຕະຖານຂອງ OS ເລີ່ມເຮັດວຽກແລ້ວ ເຊັ່ນ: Apple Intelligence ແລະ Gemini Nano ຂອງ Google. ສົມມຸດຕິຖານທີ່ວ່າ "LLM ຈະເຮັດວຽກໄດ້ພຽງແຕ່ເທິງ Cloud ເທົ່ານັ້ນ" ກຳລັງກາຍເປັນເລື່ອງຂອງອະດີດໄປແລ້ວ.

ໃນບົດກ່ອນໜ້ານີ້, ພວກເຮົາໄດ້ເບິ່ງເຖິງ "ເຫດຜົນທີ່ໄດ້ຮັບຄວາມສົນໃຈ" ໂດຍຜ່ານ 3 ແກນຫຼັກ ຄື: ຕົ້ນທຶນ, ຄວາມໜ່ວງ (Latency) ແລະ ຄວາມເປັນສ່ວນຕົວ. ໃນບົດນີ້, ພວກເຮົາຈະເຈາະເລິກລົງໄປອີກຂັ້ນໜຶ່ງ ໂດຍການເຮັດໃຫ້ຄວາມແຕກຕ່າງຂອງທັງສອງຢ່າງມີຄວາມຊັດເຈນຂຶ້ນ ໂດຍຜ່ານ 2 ມຸມມອງ ຄື: "ໂຄງສ້າງຕົ້ນທຶນ ແລະ ຄວາມໜ່ວງ (Latency)" ແລະ "ການດຳເນີນງານ ແລະ ການເຮັດວຽກແບບອອບລາຍ".

ໃນການຕັດສິນໃຈນຳໄປໃຊ້ໃນວຽກງານ, ການຕັດສິນໃຈໂດຍອີງໃສ່ຄວາມເຂົ້າໃຈກ່ຽວກັບຄວາມແຕກຕ່າງໃນດ້ານການດຳເນີນງານເຫຼົ່ານີ້ ມັກຈະເປັນປັດໄຈຕັດສິນຫຼາຍກວ່າຄວາມແຕກຕ່າງທາງດ້ານແນວຄິດ.

ເມື່ອພິຈາລະນາຈາກໂຄງສ້າງຕົ້ນທຶນ, Cloud LLM ມີຄຸນລັກສະນະທີ່ກົງກັນຂ້າມກັບ Edge AI ໂດຍ Cloud LLM ແມ່ນ "ບໍ່ມີການລົງທຶນເບື້ອງຕົ້ນ / ຈ່າຍຕາມການໃຊ້ງານຈິງ", ສ່ວນ Edge AI ແມ່ນ "ມີການລົງທຶນເບື້ອງຕົ້ນ / ຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມມີພຽງແຕ່ຄ່າໄຟຟ້າເທົ່ານັ້ນ".

ໃນຂະນະທີ່ຍັງບໍ່ສາມາດຄາດຄະເນປະລິມານການໃຊ້ງານໄດ້, ການຈ່າຍຕາມການໃຊ້ງານຂອງ Cloud ຈະໄດ້ປຽບຢ່າງເຫັນໄດ້ຊັດ, ແຕ່ເມື່ອການໃຊ້ງານມີຄວາມສະຖຽນແລະມີປະລິມານຫຼາຍຂຶ້ນ, ເມື່ອຮອດຈຸດໃດໜຶ່ງທາງຝັ່ງ Edge ຈະມີ TCO (Total Cost of Ownership) ທີ່ຄຸ້ມຄ່າກວ່າ. ສຳລັບຈຸດຄຸ້ມທຶນທາງຝັ່ງເຊີບເວີ, ໄດ້ມີການອະທິບາຍຢ່າງລະອຽດໄວ້ໃນ ການປຽບທຽບການນຳໃຊ້ Local LLM / SLM.

ສຳລັບ Latency, ທາງຝັ່ງ Edge ຈະໄດ້ປຽບໃນດ້ານຄວາມໄວການຕອບສະໜອງ ເນື່ອງຈາກບໍ່ຈຳເປັນຕ້ອງມີການສົ່ງຂໍ້ມູນໄປ-ກັບຜ່ານເຄືອຂ່າຍ. Cloud API ອາດມີຄວາມລ່າຊ້າ (Overhead) ເພີ່ມຂຶ້ນຫຼາຍຮ້ອຍມິນລິວິນາທີ ເຖິງແມ່ນວ່າຈະຜ່ານ Tokyo Region ກໍຕາມ, ເຊິ່ງເປັນຄວາມແຕກຕ່າງທີ່ຕັດສິນໄດ້ສຳລັບວຽກງານທີ່ຕ້ອງການຄວາມໄວແບບ Real-time. ໃນທາງກົງກັນຂ້າມ, ສຳລັບວຽກງານທີ່ບໍ່ມີບັນຫາຫາກການຕອບສະໜອງໃຊ້ເວລາຫຼາຍວິນາທີ (ເຊັ່ນ: ການສະຫຼຸບກອງປະຊຸມໃນຮູບແບບ Batch ໃນຕອນກາງຄືນ), ຄວາມແຕກຕ່າງຂອງ Latency ຈະບໍ່ແມ່ນປັດໄຈໃນການຕັດສິນໃຈ.

ໃນດ້ານການປະຕິບັດງານ, ຂໍ້ໄດ້ປຽບທີ່ໃຫຍ່ທີ່ສຸດຂອງ Cloud LLM ຄື "ການອັບເດດໂມເດວຈະເກີດຂຶ້ນໂດຍອັດຕະໂນມັດ". ຖ້າຜູ້ໃຫ້ບໍລິການປ່ຽນໂມເດວໃນສ່ວນ Back-end, ຜູ້ໃຊ້ງານກໍສາມາດໄດ້ຮັບປະສິດທິພາບໃໝ່ໆໂດຍບໍ່ຕ້ອງເຮັດຫຍັງເລີຍ. ສຳລັບກໍລະນີການນຳໃຊ້ທີ່ຕ້ອງການໃຊ້ໂມເດວລ່າສຸດຢູ່ສະເໝີ, ນີ້ຖືເປັນຄຸນລັກສະນະທີ່ຊົງພະລັງ.

ໃນທາງກົງກັນຂ້າມ, ສຳລັບ Edge AI, ຈຳເປັນຕ້ອງໄດ້ແຈກຢາຍນ້ຳໜັກໂມເດວ (Model weights) ໃໝ່ໃຫ້ກັບອຸປະກອນປາຍທາງທັງໝົດທີ່ຕິດຕັ້ງໄວ້. ຖ້າເປັນແອັບພລິເຄຊັນໃນສະມາດໂຟນ ກໍຕ້ອງຜ່ານການອັບເດດທາງ App Store / Google Play, ຖ້າເປັນອຸປະກອນ IoT ໃນອຸດສາຫະກຳ ກໍຕ້ອງມີກົນໄກການອັບເດດແບບ OTA (Over-The-Air), ຫຼືຖ້າເປັນໂນດບຸກທີ່ແຈກຢາຍພາຍໃນບໍລິສັດ ກໍຕ້ອງຜ່ານການ Rollout ໂດຍ MDM (Mobile Device Management) ເຊິ່ງການອອກແບບ MLOps ເພື່ອການແຈກຢາຍນັ້ນຖືເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ການເຮັດວຽກແບບ Offline ເປັນ "ຈຸດແຂງທີ່ Cloud ບໍ່ມີ" ຂອງ Edge AI ທີ່ຢາກໃຫ້ເນັ້ນຢ້ຳເປັນຢ່າງສຸດທ້າຍ:

• ສາມາດເຮັດວຽກໄດ້ຢ່າງຕໍ່ເນື່ອງເຖິງແມ່ນຢູ່ໃນສະຖານທີ່ທີ່ສັນຍານບໍ່ສະຖຽນ (ຊັ້ນໃຕ້ດິນ, ເຂດພູດອຍ, ສະຖານທີ່ກໍ່ສ້າງ, ຫຼືພື້ນທີ່ໃນຕ່າງປະເທດທີ່ຄຸນນະພາບສັນຍານບໍ່ຄົງທີ່)
• ສາມາດດຳເນີນທຸລະກິດໄດ້ຢ່າງຕໍ່ເນື່ອງໃນເວລາເກີດໄພພິບັດ ຫຼື ເກີດບັນຫາລະບົບເຄືອຂ່າຍຂັດຂ້ອງ
• ບໍ່ເພີ່ມຊ່ອງທາງການບຸກລຸກຜ່ານເຄືອຂ່າຍ ແລະ ສາມາດຈຳກັດພື້ນທີ່ການໂຈມຕີໄວ້ພາຍໃນຕົວອຸປະກອນໄດ້

ສຳລັບກໍລະນີຂອງ Cloud LLM, ຖ້າເກີດບັນຫາກັບຜູ້ໃຫ້ບໍລິການ API ກໍມີຄວາມສ່ຽງທີ່ການດຳເນີນງານທັງໝົດຈະຢຸດສະງັກ. ເຖິງແມ່ນວ່າຈະມີການເຮັດສັນຍາ SLA ແຕ່ສ່ວນຫຼາຍກໍບໍ່ສາມາດຊົດເຊີຍຄວາມເສຍຫາຍຂອງທຸລະກິດຜູ້ໃຊ້ງານໄດ້, ດັ່ງນັ້ນໃນວຽກງານທີ່ "ຄວາມບໍ່ຢຸດສະງັກ" ມີຄຸນຄ່າໃນຕົວມັນເອງ, ການເຮັດ Redundancy ໄວ້ທີ່ຝັ່ງ Edge ຈຶ່ງເປັນຄຳຕອບທີ່ເປັນຈິງຫຼາຍທີ່ສຸດ.

ການຕັດສິນໃຈນຳໃຊ້ Edge AI ຄວນເລີ່ມຕົ້ນຈາກການຄິດໄລ່ຍ້ອນກັບຈາກ "ຄວາມຕ້ອງການທາງທຸລະກິດ" ບໍ່ແມ່ນຈາກຄວາມສາມາດທາງດ້ານເຕັກນິກ ຫຼື ກະແສນິຍົມ. ຖ້າເອົາຄວາມຮູ້ສຶກທີ່ວ່າ "ຢາກລອງເຮັດ" ເປັນທີ່ຕັ້ງ, ມັກຈະເກີດກໍລະນີທີ່ຫຼັງຈາກລົງທຶນໃນການຕິດຕັ້ງເຊີບເວີ ແລະ ການພັດທະນາໂມເດວແລ້ວ ຈຶ່ງມາຮູ້ສຶກຕົວວ່າ "ໃຊ້ Cloud LLM ກໍພຽງພໍແລ້ວບໍ່ແມ່ນບໍ".

ໃນທີ່ນີ້, ຈະຂໍສະເໜີ 3 ເງື່ອນໄຂທີ່ເຮັດໃຫ້ Edge ເປັນທາງເລືອກທຳອິດ ແລະ ມຸມມອງໃນການແຍກແຍະກໍລະນີທີ່ Cloud LLM ພຽງພໍແລ້ວ. ໃນຂັ້ນຕອນທຳອິດຂອງການພິຈາລະນານຳໃຊ້, ຂໍໃຫ້ທ່ານລອງພິຈາລະນາການດຳເນີນງານຂອງບໍລິສັດທ່ານຈາກທັງສອງດ້ານນີ້ໃຫ້ດີ.

ການຕັດສິນໃຈວ່າວຽກງານໃດຄວນຈັດເປັນທາງເລືອກທຳອິດຂອງ Edge AI ຫຼືບໍ່, ວິທີປະຕິບັດທີ່ເໝາະສົມທີ່ສຸດແມ່ນການພິຈາລະນາວ່າ ມີຢ່າງໜ້ອຍ 1 ເງື່ອນໄຂ ຈາກ 3 ເງື່ອນໄຂລຸ່ມນີ້ທີ່ສາມາດນຳໃຊ້ໄດ້ຢ່າງຊັດເຈນ. ຖ້າວຽກງານໃດບໍ່ເຂົ້າເງື່ອນໄຂເຫຼົ່ານີ້ເລີຍ, ການຝືນນຳໄປໃຊ້ໃນ Edge ຈະຂາດຄວາມສົມເຫດສົມຜົນທາງເສດຖະກິດ.

ຕົວຢ່າງເຊັ່ນ: ໃນວຽກງານທີ່ໃຊ້ກ້ອງຂະໜາດນ້ອຍພາຍໃນຮ້ານຄ້າ ເພື່ອ "ແຈ້ງເຕືອນດ້ວຍສຽງທັນທີທີ່ເດັກນ້ອຍຍ່າງເຂົ້າໃກ້ຊັ້ນວາງສິນຄ້າ", ຈຳເປັນຕ້ອງເຮັດໃຫ້ຂະບວນການຕັ້ງແຕ່ການຈັບພາບໄປຈົນເຖິງການສັງເຄາະສຽງສຳເລັດພາຍໃນ 1 ວິນາທີ. ຖ້າຫາກຕ້ອງສົ່ງຂໍ້ມູນຜ່ານ Cloud, ນອກຈາກຈະບໍ່ທັນເວລາຂຶ້ນຢູ່ກັບຄຸນນະພາບຂອງການສື່ສານແລ້ວ, ການສົ່ງພາບໃບໜ້າຂອງເດັກອອກໄປພາຍນອກຍັງກໍ່ໃຫ້ເກີດບັນຫາດ້ານຄວາມເປັນສ່ວນຕົວອີກດ້ວຍ. ເນື່ອງຈາກເງື່ອນໄຂ 3 ຢ່າງນີ້ເກີດຂຶ້ນພ້ອມກັນເຖິງ 2 ຢ່າງ, ຈຶ່ງສາມາດຕັດສິນໄດ້ຢ່າງຊັດເຈນວ່າ Edge ແມ່ນທາງເລືອກທຳອິດ.

ໃນທາງກົງກັນຂ້າມ, ສຳລັບວຽກງານການສະຫຼຸບເນື້ອຫາການປະຊຸມພາຍໃນຂອງມື້ກ່ອນໜ້າດ້ວຍລະບົບ Batch ໃນຕອນກາງຄືນ, ຄວາມໜ່ວງ (Latency) ບໍ່ແມ່ນເລື່ອງສຳຄັນ ແລະ ສາມາດເຮັດໃຫ້ສຳເລັດໄດ້ພຽງແຕ່ສົ່ງຂໍ້ມູນຈາກສູນຂໍ້ມູນພາຍໃນໄປຫາ Cloud API ແລ້ວຮັບຜົນກັບຄືນມາເທົ່ານັ້ນ. ສະນັ້ນ, ເຫດຜົນທາງເສດຖະກິດທີ່ຈະລົງທຶນໃນ Edge AI ຈຶ່ງມີໜ້ອຍ.

ການໃຊ້ເງື່ອນໄຂທັງ 3 ຢ່າງນີ້ເປັນລາຍການກວດສອບ (Checklist) ຈະຊ່ວຍຫຼຸດຜ່ອນຄວາມຜິດພາດໃນການຕັດສິນໃຈ. ໃນຂັ້ນຕອນການສະເໜີໂຄງການ, ຖ້າສາມາດຂຽນໃຫ້ຊັດເຈນໃນ 1 ບັນທັດໄດ້ວ່າ "ໂຄງການຂອງພວກເຮົາຕົກຢູ່ໃນເງື່ອນໄຂໃດ?" ຫຼື "ຖ້າມີຫຼາຍເງື່ອນໄຂ, ອັນໃດມີຄວາມສຳຄັນກວ່າ?", ມັນຈະຊ່ວຍໃຫ້ການຕັດສິນໃຈໃນພາຍຫຼັງມີຄວາມສອດຄ່ອງກັນ.

ໃນທາງກົງກັນຂ້າມ, ສໍາລັບວຽກງານທີ່ເຂົ້າຂ່າຍເງື່ອນໄຂລຸ່ມນີ້ ການເລືອກໃຊ້ Cloud LLM ມັກຈະເປັນທາງເລືອກທີ່ສົມເຫດສົມຜົນກວ່າ:

• ຂໍ້ມູນທີ່ນໍາເຂົ້າສ່ວນໃຫຍ່ເປັນຂໍ້ມູນທີ່ບໍ່ມີຄວາມລັບ, ເປັນຂໍ້ມູນທີ່ເປີດຕົວ ຫຼື Launch ສູ່ສາທາລະນະ ຫຼື ຂໍ້ມູນເວັບໄຊທ໌ສາທາລະນະ
• ປະລິມານການນໍາໃຊ້ຕໍ່ເດືອນຍັງບໍ່ສາມາດຄາດຄະເນໄດ້ ແລະ ຕ້ອງການເລັ່ງການພັດທະນາໃນຂັ້ນຕອນ PoC ຫຼື ການທົດລອງ
• ຄວາມຮູ້ ແລະ ຄວາມສາມາດໃນການວິເຄາະຂອງ Model ຂະໜາດໃຫຍ່ລຸ້ນຫຼ້າສຸດ (ເຊັ່ນ: GPT-5 series, Claude, Gemini Pro) ແມ່ນມີຄວາມຈໍາເປັນ
• ຍາກທີ່ຈະມີທີມວິສະວະກອນ ML ຫຼື ທີມງານດູແລຮັກສາໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໂດຍສະເພາະ

ສິ່ງທີ່ສຳຄັນໃນທີ່ນີ້ຄື ການອອກແບບທີ່ບໍ່ຈຳເປັນຕ້ອງເລືອກຢ່າງໃດຢ່າງໜຶ່ງລະຫວ່າງ "3 ເງື່ອນໄຂ vs ເໝາະກັບ Cloud". ໃນ ໂຄງສ້າງແບບ Hybrid, ເຮົາສາມາດດຳເນີນການປະມວນຜົນເບື້ອງຕົ້ນທີ່ມີຄວາມລະອຽດອ່ອນ (ເຊັ່ນ: ການປິດບັງຂໍ້ມູນສ່ວນຕົວ, ການສະຫຼຸບເອກະສານພາຍໃນ, ການກັ່ນຕອງຂໍ້ມູນທີ່ຕ້ອງການຄົ້ນຫາ) ໄວ້ທີ່ຝັ່ງ Edge, ແລ້ວສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Cloud LLM ເພື່ອໃຫ້ມັນວິເຄາະຂັ້ນສູງ. ວິທີນີ້ເຮັດໃຫ້ເຮົາສາມາດນຳໃຊ້ຄວາມສະຫຼາດຂອງ Cloud ໄດ້ ໂດຍທີ່ບໍ່ຈຳເປັນຕ້ອງສົ່ງຂໍ້ມູນດິບອອກໄປພາຍນອກ.

ຂັ້ນຕອນການຕັດສິນໃຈສາມາດສະຫຼຸບເປັນ Flow ງ່າຍໆໄດ້ດັ່ງນີ້:

1. ມີຂໍ້ໃດຂໍ້ໜຶ່ງໃນ 3 ເງື່ອນໄຂນັ້ນເກີດຂຶ້ນ ຫຼື ບໍ່?
   • ແມ່ນ → ໃຫ້ເລືອກ Edge ເປັນທາງເລືອກທຳອິດໃນການອອກແບບ PoC
   • ບໍ່ແມ່ນ → ໄປທີ່ຂໍ້ 2
2. ຄວາມໄວໃນການເລີ່ມຕົ້ນ ຫຼື ຄວາມສະຫຼາດຂອງ Model ລຸ້ນຫຼ້າສຸດ ແມ່ນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການຕັດສິນໃຈແມ່ນບໍ່?
   • ແມ່ນ → ດຳເນີນການດ້ວຍ Cloud LLM
   • ບໍ່ແມ່ນ → ໄປທີ່ຂໍ້ 3
3. ມີພຽງບາງສ່ວນຂອງຂໍ້ມູນທີ່ລະອຽດອ່ອນ ຫຼື ໂຄງສ້າງມີຕົ້ນທຶນສູງຂຶ້ນຕາມປະລິມານຂໍ້ມູນທີ່ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ແມ່ນບໍ່?
   • ແມ່ນ → ໃຊ້ໂຄງສ້າງແບບ Hybrid (ປະມວນຜົນສ່ວນທີ່ລະອຽດອ່ອນທີ່ Edge, ສ່ວນທີ່ຕ້ອງການຄວາມສະຫຼາດໃຫ້ໃຊ້ Cloud)
   • ບໍ່ແມ່ນ → Cloud LLM ກໍພຽງພໍແລ້ວ

ການຄິດໄລ່ຕາມລຳດັບນີ້ ຈະຊ່ວຍໃຫ້ຫຼີກລ່ຽງຄວາມຜິດພາດທັງການລົງທຶນເກີນຄວາມຈຳເປັນ ແລະ ການລົງທຶນທີ່ບໍ່ພຽງພໍໄດ້ງ່າຍຂຶ້ນ.

ມາຮອດນີ້, ພວກເຮົາໄດ້ຈັດລະບຽບເຫດຜົນໃນການເລືອກ Edge AI ແລະ ມາດຕະຖານໃນການຕັດສິນຄວາມເໝາະສົມກັບວຽກງານແລ້ວ. ໃນຂັ້ນຕອນການດຳເນີນການຕິດຕັ້ງຕົວຈິງ, ຄວນເລີ່ມຈາກການຄັດເລືອກກໍລະນີການນຳໃຊ້ (Use Case) ໄປຈົນເຖິງການອອກແບບຕົວແບບ (Model), ຮາດແວ ແລະ ການດຳເນີນງານຢ່າງເປັນຂັ້ນຕອນ ເພື່ອຄວາມປອດໄພ.

ເນື່ອງຈາກການຕັ້ງເປົ້າໝາຍເພື່ອ Deploy ໃຊ້ງານຈິງຕັ້ງແຕ່ຕົ້ນຈະເຮັດໃຫ້ການຕັດສິນໃຈດ້ານການລົງທຶນມີຄວາມສ່ຽງສູງເກີນໄປ, ຈຶ່ງແນະນຳໃຫ້ໃຊ້ວິທີການເລີ່ມຕົ້ນດ້ວຍ PoC (Proof of Concept) ໂດຍເນັ້ນໃສ່ວຽກງານດຽວເພື່ອຢືນຢັນເຖິງປະສິດທິຜົນ ແລະ ພາລະໃນການດຳເນີນງານ.

ໃນການເລືອກກໍລະນີການນຳໃຊ້ (Use Case), ສິ່ງທີ່ຄວນເຮັດເປັນອັນດັບທຳອິດຄືການໃຫ້ຄະແນນວຽກງານທີ່ສະເໜີເຂົ້າມາພາຍໃນບໍລິສັດ ໂດຍອີງຕາມ 3 ແກນຫຼັກຄື: "ລະດັບຄວາມສອດຄ່ອງກັບ 3 ເງື່ອນໄຂ", "ສາມາດວັດແທກຜົນໄດ້ຢ່າງເປັນຮູບປະທຳ", ແລະ "ຂະໜາດຂອງ PoC ທີ່ສາມາດດຳເນີນການໄດ້ພາຍໃນ 2-3 ເດືອນ" ແລ້ວຈຶ່ງຄັດເລືອກເອົາພຽງ 1 ວຽກທີ່ໄດ້ຄະແນນສູງສຸດ. ຖ້າຫາກພະຍາຍາມດຳເນີນການຫຼາຍຢ່າງໄປພ້ອມໆກັນ, ຄວາມຮູ້ໃນການດຳເນີນງານດ້ານ Edge ຈະກະຈັດກະຈາຍ ແລະ ມັກຈະເຮັດໃຫ້ທຸກຢ່າງບໍ່ສຳເລັດຜົນຢ່າງເຕັມທີ່.

ໃນການອອກແບບ PoC, ຖ້າຫາກບັນທຶກລາຍການຕໍ່ໄປນີ້ໄວ້ເປັນເອກະສານຕັ້ງແຕ່ຕົ້ນ ຈະຊ່ວຍໃຫ້ການຕັດສິນໃຈໃນພາຍຫຼັງມີຄວາມເປັນເອກະພາບກັນ.

ໃນຂັ້ນຕອນຂອງ PoC, ແນະນຳວ່າບໍ່ຄວນເລີ່ມຕົ້ນດ້ວຍການ Fine-tuning ຂໍ້ມູນຂອງບໍລິສັດໂດຍທັນທີ. ກ່ອນອື່ນໃຫ້ລອງນຳ Model ທີ່ເປີດຕົວ ຫຼື Launch ມາໃຊ້ໃນອຸປະກອນໂດຍກົງ, ແລ້ວວັດແທກຄວາມຖືກຕ້ອງ, ຄວາມໄວ ແລະ ການບໍລິໂພກຊັບພະຍາກອນຂອງອຸປະກອນດ້ວຍຕົວຢ່າງວຽກງານຂອງບໍລິສັດ. ຖ້າຫາກໄດ້ຜົນຕາມຄວາມຄາດຫວັງເຖິງ 80%, ກໍສາມາດໃຊ້ວິທີການເພີ່ມຄວາມຖືກຕ້ອງດ້ວຍ PEFT ຫຼື LoRA ໄດ້.

ໃນທາງກັບກັນ, ໃນ PoC ອາດຈະພົບວ່າ "Cloud LLM ມີຄວາມຖືກຕ້ອງສູງກວ່າຢ່າງເຫັນໄດ້ຊັດ ແລະ ຂໍ້ຈຳກັດຂອງ 3 ເງື່ອນໄຂນັ້ນກໍບໍ່ໄດ້ຮຸນແຮງປານໃດ". PoC ທີ່ສາມາດຕັດສິນໃຈຖອນຕົວໄດ້ນັ້ນເອງ ຄື PoC ທີ່ມີຄຸນຄ່າ.

ເມື່ອເຫັນເສັ້ນທາງທີ່ຊັດເຈນຈາກການເຮັດ PoC ແລ້ວ, ໃຫ້ເລືອກ 3 ອົງປະກອບຫຼັກຄື: ແບບຈຳລອງ (Model), ຮາດແວ (Hardware), ແລະ MLOps ເພື່ອກ້າວໄປສູ່ການນຳໃຊ້ຈິງ.

ແບບຈຳລອງ (Model): ຕ້ອງພິຈາລະນາສຳລັບວຽກງານຕ່າງໆວ່າ "ການໃຊ້ SLM ທີ່ສະເພາະເຈາະຈົງກັບວຽກນັ້ນໆພຽງພໍແລ້ວ ຫຼື ຈຳເປັນຕ້ອງໃຊ້ LLM ແບບທົ່ວໄປ". ຖ້າເປັນວຽກງານທີ່ຈຳກັດ ເຊັ່ນ: ການສະຫຼຸບເອກະສານ, ການຈັດໝວດໝູ່, ການສະກັດຂໍ້ມູນ ຫຼື ການຮັບຮູ້ເອກະລັກຂອງຂໍ້ມູນ (Named Entity Recognition), SLM ໃນລະດັບ Phi-4, Gemma 3, Llama 3.2 1B / 3B ແມ່ນຕົວເລືອກທີ່ເປັນໄປໄດ້. ຖ້າຫາກຕ້ອງການການວິເຄາະຫາເຫດຜົນຫຼາຍຂັ້ນຕອນ ຫຼື ການສົນທະນາທີ່ຍາວນານ, ຈຳເປັນຕ້ອງໃຊ້ແບບຈຳລອງທີ່ມີຂະໜາດໃຫຍ່ກວ່າ. ທັງນີ້, ໃບອະນຸຍາດຂອງແບບຈຳລອງມີຄວາມແຕກຕ່າງກັນຫຼາຍໃນແຕ່ລະຕົວ (ເຊັ່ນ: Apache 2.0, Llama Community License, Gemma Terms of Use, ແລະ ອື່ນໆ), ດັ່ງນັ້ນກ່ອນການນຳໃຊ້ທາງການຄ້າ ຕ້ອງກວດສອບໃບອະນຸຍາດຢ່າງເປັນທາງການໂດຍກົງສະເໝີ.

ຮາດແວ (Hardware): ທາງເລືອກໃນຝັ່ງຂອງອຸປະກອນປາຍທາງຈະແບ່ງອອກຕາມການນຳໃຊ້ຢ່າງຊັດເຈນ.

MLOps: ຈຳເປັນຕ້ອງມີການອອກແບບການດຳເນີນງານທີ່ສະເພາະສຳລັບ Edge ເຊິ່ງບໍ່ຈຳເປັນໃນ Cloud LLM. ໂດຍສະເພາະແມ່ນ ຂະບວນການ ຫຼື Pipeline ໃນການສົ່ງແບບຈຳລອງ (ການສົ່ງແບບ A/B, ການປ່ອຍແບບເປັນຂັ້ນຕອນ, ການຍົກເລີກການອັບເດດ), ການເກັບຮັກສາ ແລະ ຕິດຕາມບັນທຶກການວິເຄາະ (Inference log), ລວມເຖິງການປະເມີນຜົນການອັບເດດແບບຈຳລອງຢ່າງສະໝໍ່າສະເໝີ. ສຳລັບອົງກອນທີ່ຍາກຈະມີວິສະວະກອນ ML ໂດຍສະເພາະ, ການຈຳກັດຂອບເຂດວຽກງານ ແລະ ການອອກແບບໃຫ້ມີພາລະໃນການດຳເນີນງານໜ້ອຍທີ່ສຸດແມ່ນທາງເລືອກທີ່ເປັນຈິງທີ່ສຸດ. ນອກຈາກນີ້, ໃນວຽກງານທີ່ກ່ຽວຂ້ອງກັບການຄົ້ນຫາເອກະສານ ຍັງມີວິທີການສ້າງ RAG ໄວ້ໃນອຸປະກອນໂດຍກົງ (Local) ອີກດ້ວຍ.

ໃນບັນດາຄຳຖາມທີ່ມັກພົບເລື້ອຍໃນການພິຈາລະນານຳໃຊ້ Edge AI ແລະ On-device LLM, ຂໍເສີມຕື່ມອີກ 2 ຄຳຖາມທີ່ຍັງບໍ່ທັນໄດ້ກ່າວເຖິງໃນເນື້ອໃນຫຼັກ.

ຖ້າຈຳກັດຂອບເຂດຂອງວຽກງານ, ກໍລະນີທີ່ສາມາດນຳໄປໃຊ້ງານໄດ້ຈິງນັ້ນມີຢູ່ຫຼາຍ. ການເຄື່ອນໄຫວໃນການນຳເອົາ On-device LLM ມາລວມເຂົ້າໃນລະດັບ OS ເຊັ່ນ Apple Intelligence ຫຼື Gemini Nano ຂອງ Google ກຳລັງກ້າວໜ້າໄປ, ແລະການອອກແບບໃຫ້ວຽກງານທີ່ມີນ້ຳໜັກເບົາ ເຊັ່ນ: ການກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ຄວາມ, ການສະຫຼຸບຄວາມ, ການແປປະໂຫຍກສັ້ນໆ ແລະ ການຕັດສິນຄວາມສຳຄັນຂອງການແຈ້ງເຕືອນ ສາມາດສຳເລັດໄດ້ຢູ່ທີ່ຕົວອຸປະກອນນັ້ນ ກຳລັງກາຍເປັນເລື່ອງທົ່ວໄປ.

ຢ່າງໃດກໍຕາມ, ຖ້າຕ້ອງການ "ຄວາມຮູ້ ແລະ ຄວາມສາມາດໃນການວິເຄາະທີ່ທຽບເທົ່າກັບ Model ຂະໜາດໃຫຍ່ລຸ້ນຫຼ້າສຸດເທິງ Cloud" ນັ້ນ, ໃນປັດຈຸບັນຍັງມີຊ່ອງວ່າງຢູ່. ການກຳນົດຂອບເຂດຂອງວຽກງານ, ຈາກນັ້ນເສີມຄວາມແມ່ນຍຳດ້ວຍ Fine-tuning ຫຼື RAG ຖ້າຈຳເປັນ, ແມ່ນວິທີການທີ່ເປັນຈິງທີ່ສຸດ. ຖ້າເບິ່ງວ່າເປັນເຄື່ອງມືທີ່ເນັ້ນໃສ່ວຽກງານສະເພາະທາງ ແທນທີ່ຈະເປັນການທົດແທນດ້ວຍປັນຍາປະດິດແບບອະເນກປະສົງ (General-purpose AI), ກໍຈະຊ່ວຍໃຫ້ການຕັດສິນໃຈບໍ່ຜິດພາດ.

ມັນເປັນໄປໄດ້ ແລະ ໃນທາງປະຕິບັດແລ້ວ ການໃຊ້ແບບປະສົມ (Hybrid) ມັກຈະເປັນທາງອອກທີ່ເໝາະສົມທີ່ສຸດສຳລັບຫຼາຍວຽກງານ. ຮູບແບບທີ່ເປັນຕົວຢ່າງທີ່ຊັດເຈນຄື ການແບ່ງໜ້າທີ່ກັນລະຫວ່າງ "ການປະມວນຜົນຂໍ້ມູນທີ່ລະອຽດອ່ອນຢູ່ທີ່ Edge ແລະ ການປະມວນຜົນທີ່ຊັບຊ້ອນຢູ່ທີ່ Cloud".

ຕົວຢ່າງເຊັ່ນ: ໃນການສ້າງບົດສະຫຼຸບການຊັກປະຫວັດຄົນເຈັບໃນສະຖານພະຍາບານ, LLM ທີ່ຕິດຕັ້ງຢູ່ເທິງອຸປະກອນ (On-device LLM) ຈະເຮັດໜ້າທີ່ປິດບັງຂໍ້ມູນສ່ວນບຸກຄົນ ແລະ ສະຫຼຸບເນື້ອຫາຈາກການສົນທະນາຂອງຄົນເຈັບ, ຈາກນັ້ນຈຶ່ງສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Cloud LLM ສະເພາະຂໍ້ຄວາມທີ່ປິດບັງຂໍ້ມູນແລ້ວເທົ່ານັ້ນ ເພື່ອໃຫ້ມັນຊ່ວຍສະຫຼຸບເນື້ອຫາຂັ້ນສູງ ຫຼື ສະເໜີທາງເລືອກໃນການວິນິດໄສ. ຂໍ້ມູນດິບຈະຖືກເກັບຮັກສາໄວ້ພາຍໃນໂຮງໝໍ ໃນຂະນະທີ່ຍັງສາມາດນຳໃຊ້ພະລັງການປະມວນຜົນຂອງ Cloud ໄດ້. ໂຄງສ້າງດັ່ງກ່າວສາມາດນຳໄປປະຍຸກໃຊ້ກັບການສະໜັບສະໜູນການຕັດສິນໃຈດ້ານສິນເຊື່ອໃນວຽກງານການເງິນ ຫຼື ແຊັດບັອດພາຍໃນອົງກອນໄດ້ເຊັ່ນກັນ.

ໃນໂຄງສ້າງແບບປະສົມ, ການກຳນົດວ່າຈະວາງຂອບເຂດລະຫວ່າງ Edge ແລະ Cloud ໄວ້ບ່ອນໃດນັ້ນ ຄື ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການອອກແບບ. ຖ້າຂອບເຂດຕື້ນເກີນໄປ ກໍຈະກາຍເປັນວ່າ "ສຸດທ້າຍກໍຕ້ອງສົ່ງຂໍ້ມູນເກືອບທັງໝົດໄປທີ່ Cloud" ແລະ ຖ້າເລິກເກີນໄປ ກໍຈະເກີດສະພາວະທີ່ "ຮຽກຮ້ອງຄວາມສາມາດໃນການປະມວນຜົນຈາກອຸປະກອນຫຼາຍເກີນໄປ ຈົນເຮັດໃຫ້ປະສິດທິພາບການເຮັດວຽກຫຼຸດລົງ". ຫຼັກການໃນທາງປະຕິບັດຄື ການພິຈາລະນາວ່າເງື່ອນໄຂໃດໃນ 3 ເງື່ອນໄຂທີ່ມີນ້ຳໜັກຫຼາຍທີ່ສຸດ ເພື່ອນຳມາເປັນມາດຕະຖານໃນການກຳນົດຂອບເຂດທີ່ຕື້ນທີ່ສຸດທີ່ຍັງສາມາດຕອບໂຈດຂໍ້ຈຳກັດເຫຼົ່ານັ້ນໄດ້.

Edge AI ແລະ On-device LLM ແມ່ນວິທີການທີ່ສະໜອງພື້ນທີ່ໃນການອອກແບບ ເພື່ອແກ້ໄຂ 3 ຂໍ້ຈຳກັດທີ່ Cloud LLM ຍາກທີ່ຈະແກ້ໄຂໄດ້ທາງໂຄງສ້າງ ຄື: "ຄວາມໜ່ວງຕ່ຳ (Low latency)", "ບໍ່ສາມາດນຳຂໍ້ມູນອອກໄປນອກໄດ້" ແລະ "ການເຊື່ອມຕໍ່ບໍ່ສະຖຽນ". ເຖິງວ່າທາງດ້ານເຕັກນິກຈະຍັງຢູ່ໃນລະຫວ່າງການພັດທະນາ, ແຕ່ດ້ວຍການພັດທະນາຂອງການເຮັດ Quantization ແລະ SLM ລວມເຖິງການແຜ່ຫຼາຍຂອງ NPU ໃນອຸປະກອນ, ເຮັດໃຫ້ຂັ້ນຕອນການນຳໄປໃຊ້ໃນວຽກງານຕົວຈິງເລີ່ມກວ້າງຂວາງຂຶ້ນ.

ຂໍສະຫຼຸບຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ 4 ປະການໃນການຕັດສິນໃຈນຳມາໃຊ້ງານ:

• Edge AI ບໍ່ແມ່ນສິ່ງທີ່ຈະມາແທນທີ່ Cloud LLM, ແຕ່ໃຫ້ເບິ່ງວ່າເປັນ ທາງເລືອກໃນການເລືອກໃຊ້ຕາມຄວາມເໝາະສົມຂອງວຽກງານ
• ປະສິດທິພາບຂອງ Edge ຈະເຫັນໄດ້ຊັດເຈນທີ່ສຸດໃນວຽກງານທີ່ມີ "3 ເງື່ອນໄຂ (ຄວາມໜ່ວງຕ່ຳ / ບໍ່ສາມາດນຳຂໍ້ມູນອອກໄປນອກໄດ້ / ການເຊື່ອມຕໍ່ບໍ່ສະຖຽນ)" ຢ່າງໃດຢ່າງໜຶ່ງຢ່າງຈະແຈ້ງ
• ວຽກງານທີ່ຕ້ອງການຄວາມໄວໃນການເລີ່ມຕົ້ນ ຫຼື ຄວາມສະຫຼາດຂອງ Model ລຸ້ນໃໝ່ຫຼ້າສຸດ ຄວນໃຊ້ Cloud LLM ຈະມີຄວາມສົມເຫດສົມຜົນກວ່າ
• ບໍ່ແມ່ນການເລືອກຢ່າງໃດຢ່າງໜຶ່ງ ແຕ່ລວມເຖິງການອອກແບບແບບ Hybrid, ຄວນຢຸດພິຈາລະນາ ແລະ ອອກແບບວ່າ "ຈະວາງຂອບເຂດວຽກງານຂອງບໍລິສັດໄວ້ທີ່ຈຸດໃດ"

ສຳລັບການປຽບທຽບລະອຽດຂອງ Local LLM / SLM ທາງຝັ່ງ Server, ມາດຕະຖານ ຫຼື Specification ຂອງ GPU, ແລະ ຈຸດຄຸ້ມທຶນ (Break-even point) ໃຫ້ອ້າງອີງທີ່ ການປຽບທຽບການນຳໃຊ້ Local LLM / SLM ແລະ ສຳລັບການເພີ່ມປະສິດທິພາບດ້ານຕົ້ນທຶນ Token ໃນໄລຍະການດຳເນີນງານ ໃຫ້ອ້າງອີງທີ່ ຄູ່ມືການເພີ່ມປະສິດທິພາບຕົ້ນທຶນ LLM ປະກອບກັນ.

ໃນໜ້າວຽກຂອງ Business AI, ລະຫວ່າງ "ສົ່ງທຸກຢ່າງໃຫ້ Cloud" ກັບ "ຈັດການເອງທັງໝົດພາຍໃນບໍລິສັດ" ນັ້ນ ມີພື້ນທີ່ການອອກແບບທີ່ຫຼາກຫຼາຍເຊິ່ງລວມເຖິງ Edge AI ຢູ່. ຂໍໃຫ້ໃຊ້ບົດຄວາມນີ້ເປັນຂໍ້ມູນປະກອບໃນການຄິດວິເຄາະວ່າ ຄວນຈະເລືອກຈຸດໃດໃນພື້ນທີ່ດັ່ງກ່າວໃຫ້ເໝາະສົມທີ່ສຸດ ໂດຍເລີ່ມຕົ້ນຈາກຂໍ້ຈຳກັດໃນວຽກງານຂອງບໍລິສັດທ່ານເອງ.