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

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

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

ໂດຍທົ່ວໄປແລ້ວ LLM ຈະມີພາຣາມິເຕີຕັ້ງແຕ່ຫຼາຍຮ້ອຍພັນລ້ານຫາຫຼາຍແສນພັນລ້ານຕົວ ເຊິ່ງຕ້ອງອາໄສ GPU ທີ່ມີປະສິດທິພາບສູງ ແລະ VRAM ຄວາມຈຸສູງ. ໃນທາງກົງກັນຂ້າມ, SLM ໂດຍທົ່ວໄປຈະມີຂະໜາດພາຣາມິເຕີປະມານ 1B ຫາ 10B (1 ຕື້ຫາ 10 ຕື້) ຕົວ, ຖ້າຫາກນຳໄປເຮັດ Quantization ກໍສາມາດເຮັດວຽກໄດ້ເທິງ CPU ທົ່ວໄປ, GPU ຂະໜາດນ້ອຍ ຫຼື ໃນບາງກໍລະນີກໍສາມາດເຮັດວຽກເທິງ Single-board computer ໄດ້.

ຄວາມແຕກຕ່າງນີ້ສົ່ງຜົນໂດຍກົງຕໍ່ຄວາມໄວໃນການປະມວນຜົນ (Inference) ແລະ ຕົ້ນທຶນ. Cloud LLM API ຈະມີການເພີ່ມ Overhead ຈາກການຮັບສົ່ງຂໍ້ມູນຜ່ານເຄືອຂ່າຍ ແລະ ການລໍຖ້າໃນຄິວ, ເຮັດໃຫ້ເວລາທີ່ໃຊ້ຕັ້ງແຕ່ເລີ່ມປ້ອນຂໍ້ມູນຈົນຮອດ Token ທຳອິດຖືກສົ່ງກັບມາ (TTFT) ມີຄວາມຜັນຜວນສູງຕາມສະພາບແວດລ້ອມ. ສ່ວນ SLM ທີ່ເຮັດວຽກໃນເຄື່ອງ (Local) ບໍ່ຈຳເປັນຕ້ອງຜ່ານເຄືອຂ່າຍ, ດັ່ງນັ້ນຖ້າ Model ແລະ Hardware ເຂົ້າກັນໄດ້ດີ ກໍຈະເຮັດໃຫ້ການຕອບສະໜອງມີຄວາມສະຖຽນ ແລະ ສາມາດເຮັດວຽກແບບອອບລາຍໄດ້ໂດຍບໍ່ຢຸດສະງັກ.

ຢ່າງໃດກໍຕາມ, ຍິ່ງພາຣາມິເຕີມີຂະໜາດນ້ອຍເທົ່າໃດ, ຄວາມສາມາດໃນການໃຊ້ເຫດຜົນທີ່ຊັບຊ້ອນ, ຄວາມຕໍ່ເນື່ອງຂອງບົດຄວາມຍາວໆ ແລະ ປະສິດທິພາບດ້ານພາສາ ກໍມີແນວໂນ້ມທີ່ຈະຫຼຸດລົງ. "ຄວາມໄວ ແລະ ຄວາມເບົາ" ກັບ "ຄວາມສະຫຼາດ" ແມ່ນ ການແລກປ່ຽນ ຫຼື Trade-off ກັນ, ດັ່ງນັ້ນແນວຄິດໃນການເລືອກ Model ທີ່ມີຂະໜາດນ້ອຍທີ່ສຸດແຕ່ຍັງໃຫ້ຄຸນນະພາບພຽງພໍຕໍ່ການນຳໃຊ້ ຈຶ່ງເປັນຈຸດເລີ່ມຕົ້ນຂອງການນຳໄປໃຊ້ງານທີ່ Edge.

ເຫດຜົນທີ່ SLM ຖືກເລືອກໃຊ້ໃນ Edge ແມ່ນຍ້ອນມີ 3 ຄວາມຕ້ອງການທີ່ LLM ໃນ Cloud ຍາກຈະຕອບສະໜອງໄດ້:

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

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

SLM ຫຼັກໆທີ່ເປີດຕົວ ຫຼື Launch ສໍາລັບ Edge ນັ້ນມີລັກສະນະທີ່ແຕກຕ່າງກັນໄປຕາມຜູ້ພັດທະນາ:

• Phi series ຂອງ Microsoft: ເຖິງວ່າຈະມີຂະໜາດນ້ອຍ ແຕ່ມີຈຸດເດັ່ນໃນດ້ານການອະນຸມານ (Inference) ແລະ ການສ້າງໂຄ້ດ, ຖືກອອກແບບມາເພື່ອໃຫ້ໄດ້ຄຸນນະພາບສູງດ້ວຍຈໍານວນ Parameter ທີ່ຈໍາກັດ.
• Gemma series ຂອງ Google: ມີນໍ້າໜັກເບົາ, ງ່າຍຕໍ່ການນໍາໃຊ້ ແລະ ມີເອກະສານລວມເຖິງເຄື່ອງມືຕ່າງໆທີ່ຮອງຮັບຢ່າງຄົບຖ້ວນ.
• Qwen series ຂອງ Alibaba: ມີຈຸດເດັ່ນໃນການຮອງຮັບຫຼາຍພາສາ (ລວມເຖິງພາສາຍີ່ປຸ່ນ) ແລະ ມີຂະໜາດໃຫ້ເລືອກຫຼາກຫຼາຍ ເຮັດໃຫ້ງ່າຍຕໍ່ການເລືອກຂະໜາດໃຫ້ເໝາະສົມກັບການນໍາໃຊ້.
• Llama series ລຸ້ນຂະໜາດນ້ອຍຂອງ Meta: ມີລະບົບນິເວດ (Ecosystem) ທີ່ໃຫຍ່, ມີການແຈກຢາຍ Model ທີ່ຜ່ານການ Quantization ແລະ ມີການຮອງຮັບເຄື່ອງມືຕ່າງໆຢ່າງວ່ອງໄວ.

ໃນການເລືອກ Model, ນອກຈາກຂະໜາດຂອງ Parameter ແລ້ວ ຕ້ອງກວດສອບໃບອະນຸຍາດ (License) ຈາກແຫຼ່ງຂໍ້ມູນຕົ້ນສະບັບສະເໝີ. ການອະນຸຍາດໃຫ້ໃຊ້ໃນທາງການຄ້າ ແລະ ເງື່ອນໄຂເພີ່ມເຕີມຕາມຂະໜາດການນໍາໃຊ້ນັ້ນຈະແຕກຕ່າງກັນໄປໃນແຕ່ລະ Model ເຊິ່ງອາດຈະກາຍເປັນບັນຫາໃນພາຍຫຼັງໄດ້. ຖ້າຫາກເນັ້ນການນໍາໃຊ້ພາສາຍີ່ປຸ່ນເປັນຫຼັກ, ຄຸນນະພາບກໍຈະຂຶ້ນຢູ່ກັບວ່າ Model ນັ້ນໄດ້ຜ່ານການຝຶກຝົນ ແລະ ປະເມີນຜົນດ້ວຍຂໍ້ມູນພາສາຍີ່ປຸ່ນຫຼືບໍ່.

ກ່ອນຈະເລີ່ມຂະບວນການເປີດຕົວ ຫຼື Launch, ໃຫ້ກວດສອບລາຍການ Hardware, Software ແລະ Network ໃຫ້ຄົບຖ້ວນເສຍກ່ອນ. ຖ້າປ່ອຍໃຫ້ສ່ວນນີ້ບໍ່ຊັດເຈນໃນຂະນະທີ່ດຳເນີນການຕໍ່ໄປ, ບັນຫາໜ່ວຍຄວາມຈຳບໍ່ພຽງພໍ ຫຼື ຂໍ້ຜິດພາດດ້ານຄວາມເຂົ້າກັນໄດ້ອາດຈະເກີດຂຶ້ນໃນຂັ້ນຕອນຫຼັງ, ເຊິ່ງຈະສົ່ງຜົນໃຫ້ຕ້ອງກັບມາແກ້ໄຂໃໝ່.

ຊັບພະຍາກອນທີ່ຈຳເປັນຈະປ່ຽນແປງໄປຢ່າງຫຼວງຫຼາຍຕາມຂະໜາດຂອງໂມເດວ ແລະ ວິທີການ Quantization, ແຕ່ຂໍສະຫຼຸບເປັນແນວທາງດັ່ງນີ້:

• ໜ່ວຍຄວາມຈຳ (RAM/VRAM): ສຳລັບໂມເດວທີ່ຜ່ານການ Quantization ແລ້ວ ຈະຕ້ອງໃຊ້ພື້ນທີ່ເທົ່າກັບ "ຂະໜາດໄຟລ໌ + ໂອເວີເຮດໃນຂະນະປະມວນຜົນ (ເຊັ່ນ: KV Cache)". ຖ້າເປັນໂມເດວຂະໜາດ 3B ທີ່ Quantize ເປັນ INT4 ຈະໃຊ້ພື້ນທີ່ປະມານ 2-3GB, ແລະ ຖ້າເປັນຂະໜາດ 7B ຈະໃຊ້ປະມານ 4-6GB ເປັນມາດຕະຖານ, ແຕ່ຕ້ອງລະວັງວ່າຫາກເພີ່ມຄວາມຍາວຂອງ Context ຈະເຮັດໃຫ້ KV Cache ເພີ່ມຂຶ້ນ.
• CPU/GPU: ເຖິງຈະບໍ່ມີ GPU ກໍສາມາດປະມວນຜົນດ້ວຍ CPU ໄດ້, ແຕ່ຈຳນວນ Core ແລະ Bandwidth ຂອງໜ່ວຍຄວາມຈຳຈະເປັນຕົວຕັດສິນຄວາມໄວ. ປະສົບການການໃຊ້ງານຈະແຕກຕ່າງກັນໄປຕາມການຮອງຮັບຄຳສັ່ງ SIMD ເຊັ່ນ AVX2. ຫາກສາມາດໃຊ້ GPU ຂະໜາດນ້ອຍ ຫຼື NPU ໄດ້ ກໍຄວນນຳມາໃຊ້ງານ.
• ບ່ອນຈັດເກັບຂໍ້ມູນ (Storage): ນອກຈາກໄຟລ໌ໂມເດວແລ້ວ, ຄວນກຽມພື້ນທີ່ໄວ້ປະມານ 2-3 ເທົ່າຂອງຂະໜາດໂມເດວ ເພື່ອຮອງຮັບໄຟລ໌ກາງໃນການແປງ ແລະ ໄຟລ໌ Log ຕ່າງໆ.

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

ເນື່ອງຈາກອຸປະກອນ Edge ມີຄວາມຫຼາກຫຼາຍທັງດ້ານ OS ແລະ ສະຖາປັດຕະຍະກຳ, ໃຫ້ກວດສອບກ່ອນວ່າ Runtime ຮອງຮັບສະພາບແວດລ້ອມເປົ້າໝາຍຫຼືບໍ່.

Runtime ໃນຕະກູນ llama.cpp ສ່ວນຫຼາຍສາມາດ Build ໄດ້ທັງເທິງ Linux, Windows, macOS ລວມເຖິງ Single-board ທີ່ໃຊ້ ARM ແລະ Embedded Linux. ສຳລັບ ONNX Runtime, ເນື່ອງຈາກມີການແຍກ Execution Provider ຕາມປະເພດຂອງ Accelerator (CPU, GPU, NPU) ທີ່ແຕກຕ່າງກັນ, ຈຶ່ງຕ້ອງກວດສອບວ່າ Provider ທີ່ຮອງຮັບ Hardware ທີ່ຕ້ອງການນັ້ນມີຢູ່ຫຼືບໍ່.

ໃນກໍລະນີທີ່ໃຊ້ Python, ຄວາມເຂົ້າກັນໄດ້ລະຫວ່າງເວີຊັນ Python ເທິງອຸປະກອນກັບ Library ທີ່ກ່ຽວຂ້ອງ (ເຊັ່ນ: Library ຄຳນວນຕົວເລກ ຫຼື Binding ຂອງ Runtime) ກໍເປັນຈຸດທີ່ມັກຈະຖືກມອງຂ້າມ. ໃນສະພາບແວດລ້ອມແບບ Embedded, ການບໍ່ຕິດຕັ້ງ Python ແລ້ວຫັນມາໃຊ້ການປະມວນຜົນແບບ Native ດ້ວຍ C/C++ ອາດຈະເຮັດໃຫ້ລະບົບມີຄວາມສະຖຽນຫຼາຍກວ່າ. ການກວດສອບລ່ວງໜ້າດ້ວຍ OS ແລະ ສະຖາປັດຕະຍະກຳດຽວກັນກັບລະບົບທີ່ໃຊ້ງານຈິງ (Production) — ນີ້ຄືທາງລັດທີ່ດີທີ່ສຸດໃນການຫຼີກລ່ຽງບັນຫາຄວາມບໍ່ເຂົ້າກັນຂອງລະບົບ.

ແຮງຈູງໃຈສ່ວນໃຫຍ່ຂອງການນຳໃຊ້ Edge ແມ່ນ "ການບໍ່ນຳຂໍ້ມູນອອກໄປຂ້າງນອກ". ດັ່ງນັ້ນ, ຈຶ່ງຕ້ອງມີການລະບຸເງື່ອນໄຂເບື້ອງຕົ້ນດ້ານເຄືອຂ່າຍ ແລະ ຄວາມປອດໄພໃຫ້ຊັດເຈນ.

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

ນອກຈາກນີ້, ການທີ່ມັນເຮັດວຽກຢູ່ໃນທ້ອງຖິ່ນ (Local) ກໍບໍ່ໄດ້ໝາຍຄວາມວ່າມັນຈະປອດໄພສະເໝີໄປ. ການຄວບຄຸມການເຂົ້າເຖິງ Endpoint ຂອງເຊີບເວີທີ່ໃຊ້ໃນການຄາດຄະເນ (Inference server), ການກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນນຳເຂົ້າ (Sanitize), ແລະ ການກວດຫາການປອມແປງໄຟລ໌ໂມເດວ ແມ່ນສິ່ງທີ່ຈຳເປັນຕ້ອງມີຕ່າງຫາກ. ການປຶກສາຫາລືກັບພາກສ່ວນທີ່ກ່ຽວຂ້ອງຕັ້ງແຕ່ໄລຍະເລີ່ມຕົ້ນ ເພື່ອໃຫ້ແນ່ໃຈວ່າບໍ່ມີຄວາມຂັດແຍ່ງກັບນະໂຍບາຍຄວາມປອດໄພຂອງບໍລິສັດ (ຂອບເຂດຂອງຂໍ້ມູນທີ່ສາມາດນຳອອກໄປໄດ້, ຂໍ້ກຳນົດດ້ານ Audit log) ຈະຊ່ວຍໃຫ້ຂະບວນການອະນຸມັດໃນພາຍຫຼັງບໍ່ເກີດການຕິດຂັດ.

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

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

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

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

ການເຮັດ Quantization ແມ່ນເຕັກນິກໃນການຫຼຸດຂະໜາດຂອງ Model ແລະ Memory ໂດຍການປ່ຽນນ້ຳໜັກ (Weights) ຂອງ Model ຈາກ FP16 ຫຼື ຮູບແບບອື່ນໆ ໃຫ້ເປັນ INT8 ຫຼື INT4 ເພື່ອຫຼຸດຈຳນວນບິດລົງ.

ໂດຍລວມແລ້ວ, INT8 ຈະມີຄວາມຜິດພາດໜ້ອຍ ແລະ ມີຄວາມປອດໄພກວ່າ, ສ່ວນ INT4 ສາມາດຫຼຸດຂະໜາດໄດ້ຫຼາຍກວ່າແຕ່ກໍມີໂອກາດເກີດຄວາມຜິດພາດໄດ້ງ່າຍກວ່າ. ໃນຫຼາຍການປະຕິບັດງານ, ວິທີທີ່ມີປະສິດທິພາບຄື "ທົດລອງໃຊ້ INT4 (4bit) ກ່ອນ, ຖ້າຄຸນນະພາບບໍ່ພຽງພໍ ຈຶ່ງປັບຂຶ້ນເປັນ INT8".

ຂັ້ນຕອນການດຳເນີນງານມີດັ່ງນີ້: (1) ດຶງນ້ຳໜັກຂອງ Model ທີ່ຕ້ອງການ, (2) ໃຊ້ເຄື່ອງມື Quantization (ເຊັ່ນ: quantize ຂອງ llama.cpp ຫຼື Library ຕ່າງໆ) ເພື່ອປ່ຽນເປັນ Bit width ທີ່ຕ້ອງການ, ແລະ (3) ປ້ອນຂໍ້ມູນເຂົ້າ (Input) ດຽວກັນທັງກ່ອນ ແລະ ຫຼັງການປ່ຽນແປງ ເພື່ອປຽບທຽບຜົນລັອກ (Output).

ສິ່ງທີ່ສຳຄັນຄື ຕ້ອງປະເມີນຄຸນນະພາບຫຼັງຈາກເຮັດ Quantization ທຸກຄັ້ງ. ລະດັບຄວາມເສື່ອມຖອຍຂອງຄຸນນະພາບຈະຂຶ້ນຢູ່ກັບ Model ແລະ Task ນັ້ນໆ, ເຊິ່ງບໍ່ສາມາດກຳນົດໄດ້ຢ່າງຕາຍຕົວວ່າ "INT4 ຈະຫຼຸດລົງຈັກຈຸດ". ດັ່ງນັ້ນ, ຄວນກວດສອບທຸກຄັ້ງຫຼັງຈາກເຮັດ Quantization ວ່າຜົນລັອກນັ້ນຢູ່ໃນຂອບເຂດທີ່ຍອມຮັບໄດ້ສຳລັບ Task ຂອງບໍລິສັດທ່ານຫຼືບໍ່.

ເພື່ອໃຫ້ສາມາດເຮັດວຽກຢູ່ທີ່ Edge ໄດ້, ຕ້ອງມີການປ່ຽນຮູບແບບການແຈກຢາຍໃຫ້ຢູ່ໃນຮູບແບບທີ່ Runtime ສາມາດອ່ານໄດ້. ຮູບແບບທີ່ເປັນຕົວແທນໄດ້ແກ່ GGUF ແລະ ONNX.

GGUF ແມ່ນຮູບແບບທີ່ຈັດການໂດຍ Runtime ໃນຕະກູນ llama.cpp, ເຊິ່ງລວມເອົາຂໍ້ມູນການ Quantization ໄວ້ໃນໄຟລ໌ດຽວ, ເຮັດໃຫ້ການອະນຸມານ (Inference) ດ້ວຍ CPU ແລະ ການນຳໃຊ້ໃນ Single-board ມີຄວາມສະດວກ. ການປ່ຽນຮູບແບບໂດຍທົ່ວໄປແມ່ນການໃຊ້ສະຄຣິບຂອງ llama.cpp ເພື່ອປ່ຽນ Model ໃຫ້ເປັນ GGUF, ຈາກນັ້ນຈຶ່ງເຮັດການ Quantization ຕໍ່ໄປ.

ONNX ແມ່ນມາດຕະຖານ ຫຼື Specification ທີ່ບໍ່ຂຶ້ນກັບ Framework, ເຊິ່ງສາມາດນຳໄປໃຊ້ກັບ Accelerator ທີ່ຫຼາກຫຼາຍໄດ້ຜ່ານ ONNX Runtime ເຊັ່ນ: CPU, GPU ແລະ NPU. ໃນກໍລະນີທີ່ຕ້ອງການໃຊ້ NPU ຂອງແຕ່ລະບໍລິສັດ, ການຜ່ານ ONNX ມັກຈະເປັນທາງເລືອກທີ່ເປັນໄປໄດ້ຫຼາຍທີ່ສຸດ.

ການຈະເລືອກແບບໃດນັ້ນ ແມ່ນຂຶ້ນຢູ່ກັບ "Runtime ແລະ Hardware ທີ່ໃຊ້". ຈຸດເລີ່ມຕົ້ນໃນການພິຈາລະນາຄື: ຖ້າເນັ້ນ CPU ຫຼື Single-board ໃຫ້ເລືອກ GGUF, ແຕ່ຖ້າຕ້ອງການນຳໃຊ້ປະສິດທິພາບຂອງ Accelerator ສະເພາະທາງ ໃຫ້ເລືອກ ONNX. ຫຼັງຈາກປ່ຽນຮູບແບບແລ້ວ ຕ້ອງກວດສອບການເຮັດວຽກ ແລະ ຜົນລັອບທີ່ໄດ້ຈາກເຄື່ອງຈິງສະເໝີ, ພ້ອມທັງກວດສອບວ່າຄວາມແມ່ນຍຳ ຫຼື ການຈັດການກັບ Token ພິເສດໃນຂະນະປ່ຽນຮູບແບບນັ້ນບໍ່ຜິດພ້ຽນໄປ.

ເມື່ອມີໂມເດວພ້ອມໃຊ້ງານແລ້ວ, ໃຫ້ຕິດຕັ້ງ Runtime ເພື່ອໃຊ້ງານໂມເດວນັ້ນລົງໃນອຸປະກອນ. ໃນພາກນີ້, ພວກເຮົາຈະກ່າວເຖິງການຕິດຕັ້ງ, ການຮັບປະກັນຄວາມສາມາດໃນການເຮັດຊ້ຳ (Reproducibility) ແລະ ຂໍ້ຄວນລະວັງແຍກຕາມແຕ່ລະສະຖາປັດຕະຍະກຳ (Architecture).

llama.cpp ແມ່ນມີພື້ນຖານມາຈາກການສ້າງ (Build) ຈາກ Source. ໃຫ້ດຶງເອົາ Repository ມາ, ຈາກນັ້ນໃຫ້ຄອມໄພລ໌ (Compile) ໂດຍໃສ່ Build Option ໃຫ້ເໝາະສົມກັບຮາດແວທີ່ໃຊ້ (ເຊັ່ນ: ການເປີດໃຊ້ງານ CPU SIMD, ການລະບຸ GPU/Metal Backend). ຖ້າມີການແຈກຢາຍ Binary ຫຼື Binding ທີ່ສ້າງໄວ້ແລ້ວ, ໃຫ້ໃຊ້ຕົວທີ່ກົງກັບສະຖາປັດຕະຍະກຳ (Architecture) ທີ່ກ່ຽວຂ້ອງ.

ສຳລັບ ONNX Runtime, ໃຫ້ຕິດຕັ້ງ Package ທີ່ຮອງຮັບ Execution Provider (ສຳລັບ CPU, CUDA, ຫຼື NPU ຕ່າງໆ) ທີ່ຕ້ອງການໃຊ້. ຖ້າໃຊ້ Python ໃຫ້ຕິດຕັ້ງ Build ທີ່ກ່ຽວຂ້ອງຜ່ານເຄື່ອງມືຈັດການ Package, ແລະຖ້າໃຊ້ແບບ Native ໃຫ້ເຊື່ອມຕໍ່ (Link) ກັບ Library ທີ່ຮອງຮັບ.

ບໍ່ວ່າຈະເປັນກໍລະນີໃດກໍຕາມ, ຫຼັງຈາກຕິດຕັ້ງແລ້ວ ໃຫ້ທົດລອງ Inference ຕົວຢ່າງຂະໜາດນ້ອຍ 1 ຄັ້ງ ເພື່ອຢືນຢັນວ່າ Runtime ເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງກ່ອນທີ່ຈະດຳເນີນການຕໍ່. ຖ້າຂ້າມຂັ້ນຕອນນີ້ໄປ, ເມື່ອເກີດບັນຫາຂຶ້ນໃນພາຍຫຼັງ ຈະເຮັດໃຫ້ການແຍກແຍະວ່າເປັນບັນຫາຈາກຝັ່ງ Model ຫຼື ຝັ່ງ Runtime ນັ້ນເຮັດໄດ້ຍາກ.

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

ຖ້າທ່ານຫຸ້ມຫໍ່ Runtime, ໄລບຣາຣີທີ່ກ່ຽວຂ້ອງ ແລະ ການຈັດວາງ Model ໄວ້ໃນ Image ດ້ວຍ Docker (ຫຼື Container Runtime ທີ່ເຂົ້າກັນໄດ້), ທ່ານກໍສາມາດນຳ "ສະຖານະທີ່ເຮັດວຽກໄດ້" ນັ້ນໄປໃຊ້ງານຕໍ່ໄດ້ທັນທີ. ໂດຍການກຳນົດເວີຊັນຂອງ Base Image ແລະ ໄລບຣາຣີໃຫ້ຄົງທີ່, ທ່ານສາມາດເລືອກໄດ້ວ່າຈະລວມ Model File ໄວ້ໃນ Image ຫຼື ຈະ Mount ຜ່ານ Volume ຕາມນະໂຍບາຍການດຳເນີນງານ.

ຢ່າງໃດກໍຕາມ, Container ມີ Overhead ເລັກນ້ອຍ ແລະ ໃນກໍລະນີທີ່ໃຊ້ GPU/NPU, ຈະຕ້ອງມີການຕັ້ງຄ່າການເຊື່ອມຕໍ່ກັບ Driver ຝັ່ງ Host. ໃນສະພາບແວດລ້ອມ Embedded ທີ່ມີຊັບພະຍາກອນຈຳກັດຫຼາຍ, ອາດມີການຕັດສິນໃຈທີ່ຈະບໍ່ໃຊ້ Container ແຕ່ຈະຫຸ້ມຫໍ່ແບບ Native ແທນ. ທ່ານຄວນເລືອກໂດຍອີງໃສ່ການຕັດສິນໃຈວ່າຈະໃຫ້ຄວາມສຳຄັນກັບຄວາມສາມາດໃນການຈຳລອງສະພາບແວດລ້ອມຄືນໃໝ່ ຫຼື ຄວາມເບົາບາງຂອງລະບົບ.

ອຸປະກອນ Edge ມີທັງ ARM (Single board, Embedded, ແລະ Server ບາງປະເພດ) ແລະ x86 ປະປົນກັນ. ຖ້າສະຖາປັດຕະຍະກຳແຕກຕ່າງກັນ, ຜົນລວມຂອງການ Build ແລະ ການປັບແຕ່ງ (Tuning) ກໍຈະປ່ຽນໄປ.

ສຳລັບ x86, ການເປີດໃຊ້ຄຳສັ່ງ SIMD ເຊັ່ນ AVX2 ຫຼື AVX-512 ໃນຂະນະ Build ຈະຊ່ວຍໃຫ້ການປະມວນຜົນ Inference ໄວຂຶ້ນ. ສ່ວນ ARM, ການຮອງຮັບ NEON ແລະ ການນຳໃຊ້ NPU Accelerator ໃນບາງ Board ຈະເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ.

ຂໍ້ຄວນລະວັງແມ່ນ ການນຳເອົາ Binary ຫຼື Container image ທີ່ Build ຈາກ x86 ໄປໃຊ້ໃນ ARM ໂດຍກົງ. ຖ້າສະຖາປັດຕະຍະກຳບໍ່ກົງກັນ ກໍຈະບໍ່ສາມາດເປີດໃຊ້ງານໄດ້. ໃນກໍລະນີທີ່ໃຊ້ Container, ຄວນກຽມ Image ທີ່ຮອງຮັບຫຼາຍສະຖາປັດຕະຍະກຳ (Multi-architecture) ຫຼື Build ໂດຍກົງເທິງສະຖາປັດຕະຍະກຳເປົ້າໝາຍ. ຖ້າປະຕິບັດຕາມຫຼັກການ "Build ແລະ ກວດສອບດ້ວຍສະຖາປັດຕະຍະກຳດຽວກັນກັບລະບົບທີ່ໃຊ້ງານຈິງ" ຢ່າງເຄັ່ງຄັດ, ບັນຫາປະເພດນີ້ກໍຈະສາມາດປ້ອງກັນໄດ້ເກືອບທັງໝົດ.

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

SLM ມີຄວາມຍາວຂອງບໍລິບົດ (Context length) ທີ່ສັ້ນ, ຖ້າຍັດເນື້ອຫາທີ່ຍາວເກີນໄປຈະເຮັດໃຫ້ທັງຄວາມໄວ ແລະ ໜ່ວຍຄວາມຈຳຫຼຸດລົງ. ດັ່ງນັ້ນ, ພື້ນຖານຂອງການອອກແບບ Prompt ຄື "ສັ້ນ ແລະ ມີໂຄງສ້າງ".

ແຕ່ລະໂມເດວຈະມີ Chat template (ວິທີການແບ່ງແຍກລະຫວ່າງ System, User ແລະ Assistant) ທີ່ຖືກກຳນົດໄວ້, ຖ້າບໍ່ໃຊ້ໃຫ້ຖືກຕ້ອງຈະບໍ່ສາມາດດຶງປະສິດທິພາບອອກມາໄດ້. ຂັ້ນຕອນທຳອິດແມ່ນຕ້ອງປັບໃຫ້ເຂົ້າກັບ Template ທີ່ແນະນຳຂອງໂມເດວນັ້ນໆ.

ນອກຈາກນີ້, ຕ້ອງຄຳນຶງເຖິງຈຳນວນ Input token ຢູ່ສະເໝີ. ໃຫ້ຕັດຄຳນຳທີ່ບໍ່ຈຳເປັນ ຫຼື ຄຳສັ່ງທີ່ຊ້ຳຊ້ອນອອກ, ແລະຖ້າຈຳເປັນໃຫ້ສະຫຼຸບ ຫຼື ແບ່ງຂໍ້ມູນ Input ກ່ອນສົ່ງຂໍ້ມູນຕໍ່ໃຫ້. ເຖິງແມ່ນວ່າຈະເພີ່ມຄວາມຮູ້ພາຍນອກດ້ວຍ RAG, ການເລືອກສະເພາະສ່ວນທີ່ມີຄວາມກ່ຽວຂ້ອງສູງເທົ່ານັ້ນ ຈະຊ່ວຍປ້ອງກັນບັນຫາ Token ເກີນ ແລະ ການຫຼຸດລົງຂອງຄວາມແມ່ນຍຳທີ່ເກີດຈາກສຽງລົບກວນ (Noise) ໄດ້ໃນເວລາດຽວກັນ. ເນື່ອງຈາກຈຳນວນ Token ໃນສ່ວນຂອງ "Input + Output + KV cache" ເປັນປັດໄຈທີ່ກິນໜ່ວຍຄວາມຈຳ, ຈຶ່ງຄວນກຳນົດຂີດຈຳກັດໄວ້ຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບ.

ວິທີການຕອບໂຕ້ຄວນເລືອກໃຊ້ໃຫ້ເໝາະສົມກັບຈຸດປະສົງ.

ການຕອບໂຕ້ແບບສະຕຣີມມິງ (Streaming) ແມ່ນວິທີການສົ່ງຄືນໂທເຄັນທີ່ສ້າງຂຶ້ນມາແບບຕໍ່ເນື່ອງ ເໝາະສົມກັບສະຖານະການທີ່ຕ້ອງການຫຼຸດ "ຄວາມຮູ້ສຶກໃນການລໍຖ້າ" ເຊັ່ນ: UI ການສົນທະນາ. ເນື່ອງຈາກໂທເຄັນທຳອິດຈະອອກມາຢ່າງວ່ອງໄວ, ເຖິງແມ່ນວ່າເວລາໃນການສ້າງທັງໝົດຈະເທົ່າກັນ ແຕ່ປະສົບການການໃຊ້ງານຕົວຈິງຈະດີຂຶ້ນຢ່າງຫຼວງຫຼາຍ.

ການປະມວນຜົນແບບແບັດຊ໌ (Batch processing) ແມ່ນວິທີການປະມວນຜົນຂໍ້ມູນຂາເຂົ້າຫຼາຍອັນພ້ອມກັນ ເໝາະສົມກັບສະຖານະການທີ່ "ປະລິມານການປະມວນຜົນລວມ" ມີຄວາມສຳຄັນຫຼາຍກວ່າການໂຕ້ຕອບແບບທັນທີ ເຊັ່ນ: ການຈັດໝວດໝູ່ຂໍ້ມູນໃນຕອນກາງຄືນ ຫຼື ການສະຫຼຸບເອກະສານຈຳນວນຫຼາຍ.

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

ເພື່ອໃຫ້ການດຳເນີນງານມີຄວາມສະຖຽນໃນສະພາບແວດລ້ອມທີ່ມີໜ່ວຍຄວາມຈຳຈຳກັດ, ການອອກແບບ Cache ແມ່ນມີຄວາມສຳຄັນຫຼາຍ.

• KV Cache: ເປັນກົນໄກໃນການຮັກສາສະຖານະລະຫວ່າງກາງໃນຂະນະທີ່ກຳລັງສ້າງຂໍ້ມູນ ເຊິ່ງຈະມີຂະໜາດໃຫຍ່ຂຶ້ນຕາມຄວາມຍາວຂອງບໍລິບົດ (Context). ສາມາດຄວບຄຸມໜ່ວຍຄວາມຈຳໄດ້ໂດຍການຈຳກັດຄວາມຍາວຂອງບໍລິບົດສູງສຸດໃຫ້ຢູ່ໃນຂອບເຂດທີ່ຈຳເປັນຕໍ່ການໃຊ້ງານ ຫຼື ການໃຊ້ KV Cache ທີ່ຮອງຮັບການເຮັດ Quantization.
• ການຮັກສາຕົວແບບໄວ້ໃນໜ່ວຍຄວາມຈຳ (Model Residency): ເນື່ອງຈາກການໂຫຼດຕົວແບບ (Model) ໃຊ້ຊັບພະຍາກອນສູງ, ຈຶ່ງບໍ່ຄວນໂຫຼດໃໝ່ໃນທຸກໆຄັ້ງທີ່ມີການຮ້ອງຂໍ ແຕ່ຄວນໂຫຼດໄວ້ຄັ້ງດຽວເພື່ອໃຫ້ຕົວແບບຄົງຄ້າງຢູ່ໃນໜ່ວຍຄວາມຈຳ. ຢ່າງໃດກໍຕາມ, ການຮັກສາຫຼາຍຕົວແບບໄວ້ພ້ອມກັນຈະເຮັດໃຫ້ໜ່ວຍຄວາມຈຳຖືກກົດດັນ, ຈຶ່ງຄວນຈຳກັດຈຳນວນຕົວແບບທີ່ໂຫຼດໄວ້ໃນເວລາດຽວກັນ.
• Response Cache: ຖ້າມີການປ້ອນຂໍ້ມູນທີ່ຄືກັນ ຫຼື ໃກ້ຄຽງກັນຊ້ຳໆ, ການເກັບຜົນລັອກໄວ້ໃນ Cache ແລ້ວນຳກັບມາໃຊ້ໃໝ່ຈະຊ່ວຍຫຼີກລ່ຽງຂະບວນການອະນຸມານ (Inference) ໄດ້.

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

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

ບັນຫາທີ່ພົບຫຼາຍທີ່ສຸດແມ່ນ ຄວາມຈຳບໍ່ພຽງພໍ (OOM) ໃນຂະນະເປີດໃຊ້ງານ ຫຼື ໃນຂະນະໂຫຼດຂໍ້ມູນ. ສາເຫດສ່ວນຫຼາຍມັກເກີດຈາກ "ການຄາດຄະເນຂະໜາດຂອງ Model ຜິດພາດ" ຫຼື "ການເບິ່ງຂ້າມ Overhead ໃນຂະນະປະມວນຜົນ".

ການແກ້ໄຂບັນຫາຄວນເຮັດເປັນຂັ້ນຕອນ: (1) ເຮັດໃຫ້ Model ມີຂະໜາດນ້ອຍລົງດ້ວຍການເຮັດ Quantization ທີ່ມີບິດຕ່ຳກວ່າເກົ່າ (INT8→INT4), (2) ຫຼຸດຄວາມຍາວຂອງ Context ສູງສຸດເພື່ອຫຼຸດ KV Cache, (3) ຫຼຸດຈຳນວນ Model ທີ່ເປີດຄ້າງໄວ້ ຫຼື ຈຳນວນການປະມວນຜົນພ້ອມກັນ, (4) ຖ້າຫາກຍັງບໍ່ພຽງພໍ, ໃຫ້ປ່ຽນໄປໃຊ້ Model ທີ່ມີຂະໜາດນ້ອຍກວ່າ.

ເຄັດລັບໃນການແຍກບັນຫາຄື: ໃຫ້ລອງຕັ້ງຄ່າຄວາມຍາວຂອງ Context ໃຫ້ໜ້ອຍທີ່ສຸດ ແລ້ວລອງສົ່ງພຽງ 1 Request ເຂົ້າໄປ. ຖ້າຫາກສາມາດເຮັດວຽກໄດ້ ສະແດງວ່າເປັນບັນຫາທີ່ການອອກແບບໜ່ວຍຄວາມຈຳ (ຄວາມຍາວຂອງ Context/ການປະມວນຜົນພ້ອມກັນ), ແຕ່ຖ້າຍັງເກີດບັນຫາຂັດຂ້ອງຢູ່ ສະແດງວ່າ Model ນັ້ນມີຂະໜາດໃຫຍ່ເກີນໄປສຳລັບ Hardware ດັ່ງກ່າວ.

ຖ້າ "ເຮັດວຽກຊ້າ" ໃຫ້ແຍກສ່ວນປະກອບເພື່ອລະບຸວ່າເວລາຖືກໃຊ້ໄປກັບສ່ວນໃດ.

ກ່ອນອື່ນ ໃຫ້ວັດແທກແຍກລະຫວ່າງ TTFT (ເວລາຈົນກວ່າຈະໄດ້ Token ທຳອິດ) ແລະ ຄວາມໄວໃນການສ້າງ Token (tokens/sec). ຖ້າ TTFT ຍາວ ມັກຈະມີຄວາມເປັນໄປໄດ້ວ່າ Prompt ຍາວເກີນໄປ ຫຼື ການປະມວນຜົນກ່ອນໜ້ານັ້ນໜັກເກີນໄປ, ແລະຖ້າຄວາມໄວໃນການສ້າງຊ້າ ໃຫ້ສົງໄສກ່ຽວກັບ Memory Bandwidth ຂອງ Hardware ຫຼື ປະສິດທິພາບການຄຳນວນ, ລວມເຖິງການຕັ້ງຄ່າ Quantization ຫຼື Build.

ລຳດັບການກວດສອບໂດຍປະມານແມ່ນ: (1) ຄຳສັ່ງ SIMD ຫຼື GPU/NPU Backend ຖືກເປີດໃຊ້ງານຢູ່ຫຼືບໍ່ (ກວດສອບການຕັ້ງຄ່າ Build), (2) ຖ້າເປັນການອະນຸມານ (Inference) ດ້ວຍ CPU ຈຳນວນ Thread ເໝາະສົມຫຼືບໍ່, (3) ຄວາມຍາວຂອງ Context ຍາວເກີນຄວາມຈຳເປັນຫຼືບໍ່, (4) Process ອື່ນກຳລັງແຍ່ງ CPU ຫຼື Memory Bandwidth ຢູ່ຫຼືບໍ່.

ສຳລັບ Edge, ບໍ່ແມ່ນເລື່ອງແປກທີ່ຄວາມຜິດພາດໃນການຕັ້ງຄ່າດ້ານ Software (Backend ບໍ່ໄດ້ເປີດໃຊ້ງານ, ຈຳນວນ Thread ຫຼາຍ ຫຼື ໜ້ອຍເກີນໄປ) ຈະເຮັດໃຫ້ປະສິດທິພາບຕ່າງກັນຫຼາຍເທົ່າ. ກ່ອນທີ່ຈະເພີ່ມປະສິດທິພາບ Hardware, ການທົບທວນຄືນການຕັ້ງຄ່າກ່ອນຈະມີຄວາມຄຸ້ມຄ່າຫຼາຍກວ່າ.