ຄູ່ມືການປັບໃຫ້ເໝາະສົມກັບຕົ້ນທຶນ LLM — ການຫຼຸດຈຳນວນ Token, ການເລືອກ Model ແລະ ການນຳໃຊ້ Cache

ການປັບໃຫ້ເໝາະສົມກັບຕົ້ນທຶນ LLM ແມ່ນຄວາມພະຍາຍາມໃນການຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍ API ແລະຕົ້ນທຶນການອະນຸມານ (Inference) ຢ່າງຕໍ່ເນື່ອງ ໂດຍອີງໃສ່ 3 ແກນຫຼັກ ຄື: ການໃຊ້ງານ Token, ການເລືອກ Model ແລະ ການນຳໃຊ້ Cache ໃຫ້ເກີດປະໂຫຍດສູງສຸດ ໃນຂະນະທີ່ຍັງຮັກສາຄວາມຖືກຕ້ອງ ແລະ ຄຸນນະພາບຂອງລະບົບ Generative AI ໄວ້.

ມີການລາຍງານກໍລະນີທີ່ຄ່າໃຊ້ຈ່າຍລາຍເດືອນເພີ່ມຂຶ້ນຫຼາຍເທົ່າຕົວຈາກທີ່ຄາດໄວ້ ທັນທີທີ່ເລີ່ມນຳໃຊ້ງານຈິງ. ນັ້ນກໍຍ້ອນວ່າການໃຊ້ງານ Token ຢ່າງຟຸ່ມເຟືອຍ, ການເລືອກ ມາດຕະຖານ ຫຼື Specification ຂອງ Model ທີ່ເກີນຄວາມຈຳເປັນ, ແລະ ການຮ້ອງຂໍຊ້ຳຊ້ອນເນື່ອງຈາກບໍ່ໄດ້ນຳໃຊ້ Cache ເຊິ່ງເປັນສິ່ງທີ່ບໍ່ເຫັນໃນຂັ້ນຕອນ PoC, ໄດ້ສະສົມຕົວຂຶ້ນ.

ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອແນະນຳວິສະວະກອນ, ສະຖາປະນິກ ແລະ ຜູ້ຮັບຜິດຊອບດ້ານ LLM FinOps ທີ່ກຳລັງນຳໃຊ້ LLM ໃນການຜະລິດຈິງ ໂດຍຈະອະທິບາຍຢ່າງເປັນລະບົບກ່ຽວກັບ 4 ເສົາຫຼັກ ຄື: ການຫຼຸດຜ່ອນ Token, ການເລືອກ Model, Prompt Cache ແລະ ການອອກແບບ RAG. ທ່ານຈະສາມາດຮຽນຮູ້ຮູບແບບການຈັດຕັ້ງປະຕິບັດເພື່ອຫຼຸດຜ່ອນຕົ້ນທຶນລົງເຄິ່ງໜຶ່ງໂດຍບໍ່ເຮັດໃຫ້ຄວາມຖືກຕ້ອງຫຼຸດລົງໄດ້ໃນແຕ່ລະຂັ້ນຕອນ.

ເມື່ອການນຳໃຊ້ Generative AI ເຂົ້າສູ່ການຜະລິດແທ້ຈິງມີຄວາມໄວເພີ່ມຂຶ້ນ, ຄ່າໃຊ້ຈ່າຍໃນການນຳໃຊ້ LLM (Large Language Model) ກໍມີທ່າອ່ຽງທີ່ຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ໃນຄວາມໄວທີ່ບໍ່ຄາດຄິດ. ມີການລາຍງານກໍລະນີທີ່ປະລິມານການໃຊ້ງານ Token ເຊິ່ງເບິ່ງບໍ່ເຫັນໃນຂັ້ນຕອນການພິສູດແນວຄິດ (PoC), ໄດ້ກາຍເປັນປັດໄຈທີ່ດັນຄ່າໃຊ້ຈ່າຍລາຍເດືອນໃຫ້ສູງຂຶ້ນທັນທີທີ່ຖືກນຳໄປໃຊ້ກັບ Traffic ຂອງຜູ້ໃຊ້ງານຈິງ. ຖ້າຫາກປ່ອຍໃຫ້ການຄຸ້ມຄອງຄ່າໃຊ້ຈ່າຍເປັນເລື່ອງຮອງ, ການຄິດໄລ່ AI ROI (ຜົນຕອບແທນຈາກການລົງທຶນດ້ານ AI) ຈະຜິດພາດ ແລະ ສົ່ງຜົນກະທົບຕໍ່ການຕັດສິນໃຈຂອງຝ່າຍບໍລິຫານ. ໃນພາກນີ້, ພວກເຮົາຈະມາຈັດລະບຽບໂຄງສ້າງຂອງການເພີ່ມຂຶ້ນຂອງຄ່າໃຊ້ຈ່າຍ ແລະ ແນວທາງການເພີ່ມປະສິດທິພາບໂດຍບໍ່ຕ້ອງເສຍຄ່າຄວາມແມ່ນຍຳ.

ຫຼັງຈາກເລີ່ມຕົ້ນການນຳໃຊ້ LLM (Large Language Model) ໃນການປະຕິບັດງານຈິງໄດ້ບໍ່ດົນ, ມີລາຍງານກໍລະນີທີ່ຄ່າໃຊ້ຈ່າຍລາຍເດືອນເພີ່ມຂຶ້ນຫຼາຍເທົ່າຕົວຈາກທີ່ຄາດຄະເນໄວ້. ຖ້າຫາກຍັງສືບຕໍ່ດຳເນີນການໂດຍບໍ່ເຂົ້າໃຈໂຄງສ້າງດັ່ງກ່າວ, ຄ່າໃຊ້ຈ່າຍທີ່ບໍ່ເຄີຍເຫັນໃນຂັ້ນຕອນ PoC (Proof of Concept) ກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ປັດໄຈຫຼັກທີ່ເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍເພີ່ມຂຶ້ນ ສາມາດແບ່ງອອກໄດ້ເປັນ 3 ຊັ້ນດັ່ງນີ້:

① ການບໍລິໂພກ Token ທີ່ຫຼາຍເກີນໄປ

• ມີການສະສົມຄຳອະທິບາຍທີ່ຊ້ຳຊ້ອນ ຫຼື ຕົວຢ່າງທີ່ບໍ່ຈຳເປັນໃນ System Prompt ເຮັດໃຫ້ບໍລິໂພກ Token ຫຼາຍຮ້ອຍເຖິງຫຼາຍພັນ Token ໃນທຸກໆການຮ້ອງຂໍ (Request)
• ມີການນຳຜົນການຄົ້ນຫາຈາກ RAG (Retrieval-Augmented Generation) ໃສ່ລົງໃນ Context Window ໂດຍກົງ ເຮັດໃຫ້ມີການສົ່ງເອກະສານທີ່ບໍ່ກ່ຽວຂ້ອງໄປນຳ
• ໃນການໃຫ້ເຫດຜົນຫຼາຍຂັ້ນຕອນ (Multi-step reasoning) ຫຼື ການຈັດການ Agent, ຂໍ້ມູນດຽວກັນຈະຖືກສົ່ງຊ້ຳໆຕະຫຼອດຫຼາຍຮອບ

② ການເລືອກ Model ທີ່ບໍ່ມີປະສິດທິພາບ

• ມີການນຳໃຊ້ Dense Model ທີ່ມີປະສິດທິພາບສູງມາໃຊ້ກັບວຽກງານທີ່ເບົາບາງ ເຊັ່ນ: ການຈັດປະເພດ ຫຼື ການສະຫຼຸບເນື້ອຫາ
• Reasoning Model ຈະມີການເພີ່ມຈຳນວນ Output Token ຢ່າງຫຼວງຫຼາຍເນື່ອງຈາກ CoT (Chain of Thought), ດັ່ງນັ້ນການນຳມາໃຊ້ກັບວຽກງານທີ່ງ່າຍດາຍຈຶ່ງມີຄວາມຄຸ້ມຄ່າຕໍ່ຕົ້ນທຶນຕ່ຳ

③ ການບໍ່ນຳໃຊ້ Cache

• ເຖິງແມ່ນວ່າຈະມີການສົ່ງ Prompt ດຽວກັນ ຫຼື ຄ້າຍຄືກັນຊ້ຳໆ ແຕ່ເນື່ອງຈາກບໍ່ໄດ້ຕັ້ງຄ່າ Prompt Cache ຈຶ່ງເຮັດໃຫ້ເກີດການຄິດໄລ່ຄ່າໃຊ້ຈ່າຍເຕັມຈຳນວນທຸກຄັ້ງ

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

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

3 ແກນໃນການຈັດໂຄງສ້າງການແລກປ່ຽນ ຫຼື Trade-off

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

ຖ້າດຳເນີນການປັບປຸງໃຫ້ເໝາະສົມໂດຍບໍ່ໄດ້ຕົກລົງກັນໃນ 3 ແກນນີ້ກ່ອນ, ເກນການປະເມີນຜົນໃນແຕ່ລະມາດຕະການຈະເກີດຄວາມບໍ່ຊັດເຈນ.

ຕົວຢ່າງຂອງເສັ້ນແບ່ງຄວາມອົດທົນຕາມແຕ່ລະໜ້າວຽກ

ຂຶ້ນຢູ່ກັບລັກສະນະຂອງໜ້າວຽກ, ການແລກປ່ຽນ ຫຼື Trade-off ທີ່ສາມາດຍອມຮັບໄດ້ມີທ່າອ່ຽງທີ່ຈະແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍ.

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

ແນວຄວາມຄິດຂອງ "regression budget"

ການກຳນົດຂອບເຂດຄວາມອົດທົນຕໍ່ການຫຼຸດລົງຂອງຄວາມແມ່ນຍຳດ້ວຍຕົວເລກ ເອີ້ນວ່າ "regression budget". ຕົວຢ່າງເຊັ່ນ: ຖ້າກຳນົດໄວ້ວ່າ "ອັດຕາຄວາມຖືກຕ້ອງຫຼຸດລົງບໍ່ເກີນ 2 ຈຸດ", ກໍຈະສາມາດປະເມີນຜົນກະທົບຂອງການປ່ຽນແປງ Model ຫຼື ການບີບອັດ Prompt ໄດ້ຢ່າງເປັນຮູບປະທຳ. ເນື່ອງຈາກ budget ນີ້ຈະຖືກນຳໄປໃຊ້ໃນຂັ້ນຕອນການປະເມີນຜົນຕໍ່ໄປ, ການຕົກລົງເຫັນດີກັບຜູ້ມີສ່ວນກ່ຽວຂ້ອງໃນຂັ້ນຕອນນີ້ຈຶ່ງມີຄວາມສຳຄັນຫຼາຍ.

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

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

ໃນພາກນີ້, ຈະອະທິບາຍກ່ຽວກັບວິທີການສ້າງພື້ນຖານການວັດແທກເພື່ອເຮັດໃຫ້ປະລິມານການໃຊ້ງານ Token ແລະຕົ້ນທຶນສາມາດເບິ່ງເຫັນໄດ້, ລວມເຖິງວິທີການກຳນົດ Baseline ເຊິ່ງເປັນຈຸດເລີ່ມຕົ້ນຂອງການປັບໃຫ້ເໝາະສົມ (Optimization). ໂດຍຈະຈັດລຽງອົງປະກອບທີ່ຈຳເປັນຕໍ່ການນຳໄປໃຊ້ງານ (Implementation) ຕາມລຳດັບ, ນັບຕັ້ງແຕ່ການເລືອກເຄື່ອງມື Observability ໄປຈົນເຖິງການອອກແບບ FinOps tag.

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

ຕົວຊີ້ວັດຂັ້ນຕໍ່າທີ່ຄວນວັດແທກ

• ຈຳນວນ Input Token: ຜົນລວມຂອງ Prompt ທັງໝົດ (System Prompt + User Message + Context)
• ຈຳນວນ Output Token: ຄວາມຍາວຂອງຂໍ້ຄວາມທີ່ Model ສ້າງຂຶ້ນ
• ຈຳນວນ Cache Hit: ຈຳນວນຄັ້ງທີ່ມີການນຳໃຊ້ Prompt Cache ແລະ ປະລິມານ Token ທີ່ປະຢັດໄດ້
• Model Identifier: ໃນກໍລະນີທີ່ໃຊ້ຫຼາຍ Model ພາຍໃນແອັບດຽວກັນ ໃຫ້ລວມຍອດແຍກຕາມແຕ່ລະ Model

ໃນ Response ຂອງແຕ່ລະ API ຈະມີ Object usage ລວມຢູ່, ພຽງແຕ່ບັນທຶກ prompt_tokens ແລະ completion_tokens ໃນທຸກໆ Request ກໍຈະໄດ້ຂໍ້ມູນພື້ນຖານທີ່ຄົບຖ້ວນ. ການເພີ່ມ Middleware ແບບເບົາບາງເພື່ອຂຽນຄ່າເຫຼົ່ານີ້ລົງໃນ Data Store ໄວ້ແຕ່ເນິ່ນໆ ຈະຊ່ວຍໃຫ້ການປັບແຕ່ງໃນຂະບວນການຕໍ່ໄປງ່າຍຂຶ້ນຫຼາຍ.

ເຂົ້າໃຈຄຸນລັກສະນະຂອງ BPE Tokenizer

BPE Tokenizer (Byte-Pair Encoding Tokenizer) ມີແນວໂນ້ມທີ່ຈະປ່ຽນຕົວອັກສອນ Multi-byte ເຊັ່ນ: ພາສາຢີ່ປຸ່ນ ຫຼື ພາສາຈີນ ໃຫ້ເປັນ Token ຫຼາຍກວ່າພາສາອັງກິດ. ເນື່ອງຈາກຕົ້ນທຶນປ່ຽນແປງໄປຕາມພາສາເຖິງແມ່ນວ່າຈະມີປະລິມານຂໍ້ມູນເທົ່າກັນກໍຕາມ, ການລວມຍອດແຍກຕາມພາສາຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້ສຳລັບຜະລິດຕະພັນທີ່ຮອງຮັບຫຼາຍພາສາ.

ລຳດັບຄວາມສຳຄັນໃນການຈັດຕັ້ງປະຕິບັດ

1. ບັນທຶກ usage ຈາກ API Response ທຸກລາຍການລົງໃນ Log (ຫ້າມ DROP)
2. ເພີ່ມ Tag ຂອງ Endpoint, User ID ແລະ ຊື່ຟັງຊັນ
3. ລວມຍອດຄ່າໃຊ້ຈ່າຍໂດຍອັດຕະໂນມັດເປັນລາຍວັນ ແລະ ລາຍສັບປະດາ ໂດຍຄິດໄລ່ຈາກ: ລາຄາຕໍ່ Token × ປະລິມານການໃຊ້ງານ

ເມື່ອມີພື້ນຖານການວັດແທກທີ່ພ້ອມແລ້ວ ເຮົາຈຶ່ງຈະສາມາດຕັດສິນໄດ້ຢ່າງເປັນຮູບປະທຳວ່າ Endpoint ໃດທີ່ມີ "ຄວາມຄຸ້ມຄ່າຕໍ່ຕົ້ນທຶນຕໍ່າ". Observability Stack ທີ່ຈະແນະນຳໃນພາກຕໍ່ໄປ ຈະເຮັດວຽກໂດຍອີງໃສ່ພື້ນຖານນີ້.

ເມື່ອມີພື້ນຖານການວັດແທກຕົ້ນທຶນທີ່ພ້ອມແລ້ວ, ຂັ້ນຕອນຕໍ່ໄປແມ່ນການນຳເອົາ Observability Stack ເຂົ້າມາໃຊ້ເພື່ອເບິ່ງເຫັນລາຍລະອຽດໃນລະດັບ Request. ເກນໃນການເລືອກເຄື່ອງມືມີດັ່ງນີ້:

• Langfuse: ເນັ້ນ Open Source ແລະ ສາມາດ Hosting ດ້ວຍຕົນເອງໄດ້. ມີການບັນທຶກຈຳນວນ Token, Latency ແລະ ຕົ້ນທຶນໃນລະດັບ Trace, ເໝາະສົມກັບການປຽບທຽບຕົ້ນທຶນລະຫວ່າງທີມ.
• LangSmith: ມີຄວາມເຂົ້າກັນໄດ້ສູງກັບ LangChain Ecosystem ແລະ ສາມາດເບິ່ງເຫັນໄດ້ເຖິງຂັ້ນຕອນກາງຂອງ Agent.
• Helicone: ເປັນຮູບແບບ Proxy ເຮັດໃຫ້ການປ່ຽນແປງ Code ທີ່ມີຢູ່ແລ້ວມີໜ້ອຍທີ່ສຸດ. Dashboard ມີຄວາມລຽບງ່າຍ, ເໝາະກັບທີມຂະໜາດນ້ອຍ.
• OTel GenAI semconv: ເປັນມາດຕະຖານຄວາມໝາຍສຳລັບ Generative AI ຂອງ OpenTelemetry. ເຮັດໃຫ້ Span Attribute ທີ່ເປັນກາງຕໍ່ Vendor (ເຊັ່ນ: gen_ai.usage.input_tokens) ເປັນມາດຕະຖານ ແລະ ງ່າຍຕໍ່ການເຊື່ອມໂຍງເຂົ້າກັບໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ານການສັງເກດການທີ່ມີຢູ່ແລ້ວ (ເຊັ່ນ: Grafana / Datadog).

ສິ່ງທີ່ມັກຈະຖືກມອງຂ້າມຫຼັງຈາກເລືອກເຄື່ອງມືແລ້ວຄື ການອອກແບບ FinOps Tag. ຖ້າບໍ່ມີ Tag, ຈະບໍ່ສາມາດແຍກໄດ້ໃນພາຍຫຼັງວ່າຕົ້ນທຶນນັ້ນມາຈາກ "ທີມໃດ, Use case ໃດ, ຫຼື Model ໃດ". ແນະນຳໃຫ້ກຳນົດ Tag ຢ່າງໜ້ອຍ 4 ແກນດັ່ງນີ້:

ໃຫ້ຝັງ Tag ເປັນ Metadata ໃນເວລາສົ່ງ Request ແລະ ເຮັດການກັ່ນຕອງ (Filtering) ຢູ່ຝັ່ງເຄື່ອງມື Observability. ການເພີ່ມ Tag ໃນພາຍຫຼັງຈະເຮັດໃຫ້ຄວາມຕໍ່ເນື່ອງຂອງ Log ສູນເສຍໄປ, ດັ່ງນັ້ນການອອກແບບຕັ້ງແຕ່ເລີ່ມຕົ້ນໂຄງການຈຶ່ງມີຄວາມສຳຄັນຫຼາຍ. ເມື່ອມີທັງການເບິ່ງເຫັນຂໍ້ມູນ (Visualization) ແລະ Tag ຄົບຖ້ວນແລ້ວ, ຈຶ່ງຈະສາມາດວັດແທກປະສິດທິຜົນຂອງມາດຕະການຫຼຸດຜ່ອນ Token ໃນຂັ້ນຕອນຕໍ່ໄປໄດ້.

ຂັ້ນຕອນທຳອິດຂອງການຫຼຸດຕົ້ນທຶນ ຄືການຫຼຸດຈຳນວນ Token ທີ່ສົ່ງໄປຫາ LLM ໂດຍກົງ. ກ່ອນທີ່ຈະປ່ຽນແປງ Model ຫຼື ກົນລະຍຸດການ Cache, ມີຫຼາຍກໍລະນີທີ່ສາມາດຫຼຸດຕົ້ນທຶນການນຳເຂົ້າ ແລະ ສົ່ງອອກຂໍ້ມູນໄດ້ຢ່າງມະຫາສານ ພຽງແຕ່ການທົບທວນຄືນການອອກແບບ Prompt ເທົ່ານັ້ນ.

ໃນຂັ້ນຕອນນີ້, ພວກເຮົາຈະນຳສະເໜີ 2 ແນວທາງ ຄື: ການຈັດໂຄງສ້າງ System Prompt ແລະ ການບີບອັດບໍລິບົດ (Context) ທີ່ມີຄວາມຍາວ. ທັງສອງວິທີມີຂໍ້ດີຄື ມີຕົ້ນທຶນໃນການນຳໄປໃຊ້ງານຕ່ຳ ແລະ ສາມາດວັດແທກຜົນໄດ້ທັນທີ.

System Prompt ຈະຖືກຄິດໄລ່ຄ່າໃຊ້ຈ່າຍເປັນ Token ໃນທຸກໆຄັ້ງທີ່ມີການຮ້ອງຂໍໄປຍັງ LLM (Large Language Model). ການປ່ອຍໃຫ້ System Prompt ມີຄວາມຍາວເກີນໄປ ມັກຈະສົ່ງຜົນກະທົບຕໍ່ຄ່າໃຊ້ຈ່າຍລາຍເດືອນໃນລະດັບທີ່ບໍ່ສາມາດລະເລີຍໄດ້.

ກ່ອນອື່ນໝົດ, ເພື່ອໃຫ້ເຂົ້າໃຈສະຖານະການປັດຈຸບັນ, ໃຫ້ວັດແທກຈຳນວນ Token ຂອງ System Prompt. ການໃຊ້ BPE Tokenizer (Byte-Pair Encoding Tokenizer) ມັກຈະພົບວ່າພາສາຍີ່ປຸ່ນຈະໃຊ້ປະມານ 1-2 Token ຕໍ່ 1 ຕົວອັກສອນ. ມີລາຍງານກໍລະນີທີ່ Prompt ຍາວ 500 ຕົວອັກສອນ ກາຍເປັນຫຼາຍກວ່າ 700 Token ໃນຄວາມເປັນຈິງ, ດັ່ງນັ້ນການປັບປຸງໃຫ້ເໝາະສົມໂດຍບໍ່ມີການວັດແທກແມ່ນສິ່ງທີ່ຄວນຫຼີກລ່ຽງ.

4 ຂັ້ນຕອນໃນການຈັດໂຄງສ້າງ

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

ຕົວຢ່າງກ່ອນ ແລະ ຫຼັງການປັບປຸງ

ມີລາຍງານວ່າ System Prompt ທີ່ເຄີຍເກີນ 500 Token ກ່ອນການປັບປຸງ ສາມາດຫຼຸດລົງເຫຼືອພຽງ 200-300 Token ໄດ້ດ້ວຍການຈັດລະບຽບດັ່ງກ່າວ. ຖ້າອັດຕາສ່ວນຂອງ System Prompt ທີ່ກວມເອົາ Context Window ທັງໝົດຫຼຸດລົງ, ມັນຍັງຈະສົ່ງຜົນດີທາງອ້ອມທີ່ເຮັດໃຫ້ສາມາດເພີ່ມພື້ນທີ່ສຳລັບການຕອບໂຕ້ຂອງຜູ້ໃຊ້ໄດ້ຫຼາຍຂຶ້ນ.

ນອກຈາກນີ້, ໃນກໍລະນີທີ່ນຳໃຊ້ Prompt Cache (ຈະອະທິບາຍລະອຽດໃນຂັ້ນຕອນຕໍ່ໄປ), ສິ່ງສຳຄັນຄືການ ກຳນົດສ່ວນຕົ້ນ ຂອງ System Prompt ໃຫ້ຄົງທີ່ ເພື່ອເພີ່ມອັດຕາການ Cache Hit. ຖ້າຫາກຄຳນຶງເຖິງການອອກແບບ Cache ໄປພ້ອມກັບການຈັດໂຄງສ້າງ, ປະສິດທິພາບຂອງການປັບປຸງຈະ ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ເມື່ອ Context Window ຍາວຂຶ້ນ, ຈຳນວນ Input Token ຈະເພີ່ມຂຶ້ນຫຼາຍກວ່າເສັ້ນຊື່ ແລະ ມີທ່າອ່ຽງເຮັດໃຫ້ຕົ້ນທຶນເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ໃນກໍລະນີການນຳໃຊ້ທີ່ຫຼີກລ່ຽງການປ້ອນຂໍ້ມູນຍາວໆບໍ່ໄດ້ ເຊັ່ນ: ການສະຫຼຸບເອກະສານ, ການຖາມ-ຕອບແບບຍາວ, ຫຼື ການສົນທະນາຫຼາຍຮອບ, ການບີບອັດບໍລິບົດ (Context Compression) ຈຶ່ງເປັນວິທີການທີ່ມີປະສິດທິພາບ.

ຫໍສະໝຸດ OSS ທີ່ເປັນຕົວແທນໄດ້ແກ່ LLMLingua ແລະ LongLLMLingua. ຫຼັກການໃນການເລືອກໃຊ້ທັງສອງຢ່າງມີດັ່ງນີ້:

• LLMLingua: ໃຊ້ກັບ Prompt ຂະໜາດກາງປະມານຫຼາຍພັນ Token ໂດຍການລຶບ Token ທີ່ມີຄະແນນຄວາມສຳຄັນຕໍ່າອອກ. ມີລາຍງານວ່າໃຫ້ຜົນການບີບອັດທີ່ແນ່ນອນ, ເໝາະສຳລັບວຽກງານການສະຫຼຸບ ຫຼື ການຈັດປະເພດທີ່ມີຄວາມຍາວສັ້ນເຖິງປານກາງ.
• LongLLMLingua: ໃຊ້ກັບຂໍ້ຄວາມຍາວລະດັບຫຼາຍໝື່ນ Token ໂດຍການເລືອກຮັກສາ Chunk ທີ່ມີຄວາມສຳຄັນໂດຍອີງໃສ່ຄວາມກ່ຽວຂ້ອງກັບຄຳຖາມ. ມີປະສິດທິພາບໂດຍສະເພາະໃນກໍລະນີທີ່ຜົນການຄົ້ນຫາຈາກ RAG (Retrieval-Augmented Generation) ມີຈຳນວນຫຼາຍ.

ຢ່າງໃດກໍຕາມ, ການນຳໃຊ້ຈຳເປັນຕ້ອງມີມາດຕະຖານໃນການຕັດສິນໃຈ. ຄວນພິຈາລະນານຳໃຊ້ໃນກໍລະນີທີ່ຕອບສະໜອງເງື່ອນໄຂດັ່ງຕໍ່ໄປນີ້:

1. ສ່ວນສຳຄັນຂອງ Input Token ປະກອບດ້ວຍວະລີທີ່ເປັນຮູບແບບຕາຍຕົວ ຫຼື ຄຳອະທິບາຍພື້ນຫຼັງທີ່ເຍີ່ນເຍີ້.
2. ມີການກຳນົດຂອບເຂດການຫຼຸດລົງຂອງຄວາມຖືກຕ້ອງໃນການຕອບສະໜອງທີ່ຍອມຮັບໄດ້ໄວ້ລ່ວງໜ້າ (ເຊື່ອມໂຍງກັບ regression budget ທີ່ຈະກ່າວເຖິງໃນພາຍຫຼັງ).
3. Latency ຂອງຂະບວນການບີບອັດເອງຢູ່ໃນຂອບເຂດທີ່ຍອມຮັບໄດ້.

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

ແນະນຳໃຫ້ມີການວັດແທກ 3 ຕົວຊີ້ວັດ ຄື: ຈຳນວນ Token, ຄວາມຖືກຕ້ອງ, ແລະ Latency ທັງກ່ອນ ແລະ ຫຼັງການນຳໃຊ້ ເພື່ອຢືນຢັນຜົນປະໂຫຍດໃນການຫຼຸດຕົ້ນທຶນຢ່າງເປັນຮູບປະທຳ.

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

ໃນພາກນີ້, ຈະອະທິບາຍກ່ຽວກັບການເລືອກໂມເດວໂດຍແບ່ງອອກເປັນ 2 ແກນຫຼັກ ຫຼື ຈຸດສຳຄັນ ຄື: ກົນລະຍຸດການ Routing ແລະ ການນຳໃຊ້ Local LLM.

• ການ Routing ໄປຫາໂມເດວຂະໜາດນ້ອຍ (Lightweight Model): ການແບ່ງໂມເດວໂດຍອັດຕະໂນມັດຕາມຄວາມຊັບຊ້ອນຂອງວຽກງານ
• ການຕັດສິນໃຈ TCO ຂອງໂຄງສ້າງແບບ Hybrid: ການພິຈາລະນາຈຸດຄຸ້ມທຶນລະຫວ່າງ Cloud ແລະ On-premise

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

ແນວຄິດພື້ນຖານຂອງການຈັດເສັ້ນທາງ (Routing)

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

ມາດຖານການເລືອກເຄື່ອງມືຫຼັກ

RouteLLM ແມ່ນໂຄງຮ່າງ OSS ທີ່ຄິດໄລ່ຄະແນນຄວາມຍາກງ່າຍແບບ Real-time ແລະ ສົ່ງຕໍ່ໄປຍັງໂມເດວລະດັບສູງເມື່ອເກີນເກນທີ່ກຳນົດໄວ້ເທົ່ານັ້ນ. ຈຸດແຂງແມ່ນສາມາດປັບປ່ຽນຕົວເລກ ການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງອັດຕາການຫຼຸດຕົ້ນທຶນ ແລະ ການຫຼຸດລົງຂອງຄຸນນະພາບໄດ້. ເນື່ອງຈາກຈຳເປັນຕ້ອງມີການປັບທຽບ (Calibration) ໃຫ້ເຂົ້າກັບຮູບແບບການຈະລາຈອນຂໍ້ມູນຂອງບໍລິສັດ, ຄວນຄຳນຶງເຖິງຕົ້ນທຶນໃນການຕັ້ງຄ່າເບື້ອງຕົ້ນນຳ.

Martian ແມ່ນ Router ທີ່ໃຫ້ບໍລິການໃນຮູບແບບ Cloud API ເຊິ່ງຈະຈັດໝວດໝູ່ຄຸນລັກສະນະຂອງວຽກງານໂດຍອັດຕະໂນມັດເພື່ອເລືອກໂມເດວ. ເຖິງວ່າຈະໃຊ້ແຮງງານໃນການຕິດຕັ້ງໜ້ອຍ ແຕ່ກໍຕ້ອງພິຈາລະນາເຖິງບັນຫາ Vendor Lock-in ແລະ ຕົ້ນທຶນ API ເພີ່ມເຕີມ.

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

ຂໍ້ຄວນລະວັງໃນການນຳໄປໃຊ້

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

Local LLM (ການໂຮສຕົວແບບ Open Weights ດ້ວຍຕົນເອງ) ສາມາດຫຼີກລ່ຽງຄ່າໃຊ້ຈ່າຍ API ໄດ້, ແຕ່ໃນທາງກັບກັນກໍມີຕົ້ນທຶນແຝງທີ່ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ທັງໃນດ້ານການຈັດຫາ GPU, ການດຳເນີນງານ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure, ແລະ ການອັບເດດຕົວແບບ. ຖ້າບໍ່ຄິດໄລ່ TCO (Total Cost of Ownership) ໃຫ້ຊັດເຈນກ່ອນການນຳໃຊ້, ກໍມີຫຼາຍກໍລະນີທີ່ຄ່າໃຊ້ຈ່າຍສູງກວ່າການໃຊ້ Cloud API.

ລາຍການຕົ້ນທຶນຫຼັກທີ່ຄວນພິຈາລະນາໃນການປຽບທຽບ TCO

• ຝັ່ງ Cloud API: ລາຄາຕໍ່ Token ຂອງການນຳເຂົ້າ-ສົ່ງອອກ × ຈຳນວນຄຳຮ້ອງຂໍຕໍ່ເດືອນ, ຄ່າໃຊ້ຈ່າຍໃນການລອງໃໝ່ (Retry) ເມື່ອເກີນ Latency SLA
• ຝັ່ງ Local LLM: ຄ່າໃຊ້ຈ່າຍ GPU/Instance (On-premise ຫຼື Cloud GPU), ຄ່າແຮງງານໃນການສ້າງ ແລະ ບຳລຸງຮັກສາພື້ນຖານການໃຫ້ບໍລິການຕົວແບບ, ຄ່າໃຊ້ຈ່າຍໃນການປັບແຕ່ງ (Tuning) ດ້ວຍ Quantization ຫຼື LoRA
• ທົ່ວໄປ: ການກວດສອບຄວາມປອດໄພ, ພື້ນຖານການຕິດຕາມ ແລະ ບັນທຶກຂໍ້ມູນ (Logging), ຄ່າຈ້າງວິສະວະກອນທີ່ຮັບຜິດຊອບ

ສະຖານະການທີ່ໂຄງສ້າງແບບ Hybrid ມີປະສິດທິພາບ

ໂຄງສ້າງແບບ Hybrid ທີ່ປະສົມປະສານລະຫວ່າງ Local LLM ແລະ Cloud API ມີແນວໂນ້ມທີ່ຈະມີຄວາມຄຸ້ມຄ່າສູງໃນກໍລະນີທີ່ມີເງື່ອນໄຂດັ່ງຕໍ່ໄປນີ້:

• ມີຄຳຮ້ອງຂໍທີ່ປະກອບດ້ວຍເອກະສານພາຍໃນ ຫຼື ຂໍ້ມູນສ່ວນຕົວຫຼາຍ ເຊິ່ງບໍ່ສາມາດສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Cloud ໄດ້
• ມີຮູບແບບ Prompt ທີ່ຊ້ຳກັນຫຼາຍ ແລະ ມີ Throughput ທີ່ສະໝ່ຳສະເໝີ (ສາມາດຮັກສາອັດຕາການໃຊ້ງານ GPU ໄດ້)
• ວຽກງານທີ່ມີນ້ຳໜັກເບົາຈະຖືກປະມວນຜົນໃນ Local ດ້ວຍ SLM (Small Language Model) ແລະ ຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Cloud API ສະເພາະການອະນຸມານ (Inference) ທີ່ຊັບຊ້ອນເທົ່ານັ້ນ

ມາດຕະຖານໃນການຕັດສິນໃຈ

ໃນກໍລະນີທີ່ຈຳນວນ Token ຕໍ່ເດືອນເກີນຂີດຈຳກັດທີ່ກຳນົດໄວ້ ແລະ ມີຄວາມເປັນໄປໄດ້ທີ່ຈະເຮັດໃຫ້ GPU ເຮັດວຽກໃນລະດັບສູງໄດ້ຕະຫຼອດເວລາ, ຂໍ້ດີດ້ານຕົ້ນທຶນຂອງໂຄງສ້າງແບບ Local ຈະເຫັນໄດ້ຊັດເຈນກວ່າ. ໃນທາງກັບກັນ, ຖ້າຫາກມີການຮ້ອງຂໍແບບກະແຈກກະຈາຍ, ຄ່າໃຊ້ຈ່າຍຂອງ GPU ໃນສະພາວະ Idle ຈະກາຍເປັນພາລະ. ວິທີການທີ່ເປັນຈິງຄືການວັດແທກຄ່າໃຊ້ຈ່າຍຂອງ Cloud API ໃນລະດັບ PoC ກ່ອນ, ຈາກນັ້ນຈຶ່ງນຳຄ່ານັ້ນມາປຽບທຽບກັບ TCO ຂອງໂຄງສ້າງແບບ Local ເພື່ອຕັດສິນໃຈໃນການຍ້າຍລະບົບ.

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

ການເຮັດ Prompt Cache ແລະ ການນຳຜົນລັດກັບມາໃຊ້ໃໝ່ (Result Reuse) ມີ 2 ແນວທາງຫຼັກໆ. ຢ່າງໜຶ່ງແມ່ນຟັງຊັນ Native Cache ທີ່ຜູ້ໃຫ້ບໍລິການຈັດຫາໃຫ້, ແລະ ອີກຢ່າງໜຶ່ງແມ່ນ Semantic Cache ທີ່ນຳໄປປະຕິບັດໃນຊັ້ນ Application. ເນື່ອງຈາກທັງສອງມີກົນໄກ ແລະ ສະຖານະການນຳໃຊ້ທີ່ແຕກຕ່າງກັນ, ການເຂົ້າໃຈມາດຖານໃນການຕັດສິນໃຈເລືອກໃຊ້ຈຶ່ງເປັນເລື່ອງສຳຄັນ.

ໃນຫົວຂໍ້ H3 ຕໍ່ຈາກນີ້, ຈະອະທິບາຍຢ່າງລະອຽດກ່ຽວກັບຄວາມແຕກຕ່າງຂອງມາດຕະຖານ ຫຼື Specification ດ້ານ Cache ຂອງ Anthropic, OpenAI ແລະ Google ລວມເຖິງວິທີການຮັບມືກັບຄວາມສ່ຽງທີ່ເກີດຈາກການຜິດພາດ (False Hit).

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

ການປຽບທຽບມາດຕະຖານຂອງ 3 ບໍລິສັດຫຼັກ

※ ຂໍ້ມູນຂ້າງເທິງເປັນຄ່າອ້າງອີງໃນເວລາທີ່ຂຽນບົດຄວາມນີ້. ກະລຸນາກວດສອບໜ້າເວັບໄຊລາຄາຫຼ້າສຸດ.

ຂັ້ນຕອນການຕັດສິນໃຈນຳໄປໃຊ້ງານ

1. System Prompt ມີໜ້ອຍກວ່າ 1,024 Token ແມ່ນຫຼືບໍ່? → ຖ້າແມ່ນ, ຈະບໍ່ໄດ້ຮັບຜົນປະໂຫຍດຈາກ Cache. ຄວນໃຫ້ຄວາມສຳຄັນກັບການຫຼຸດຈຳນວນ Token ກ່ອນ
2. ຄວາມຖີ່ໃນການຮ້ອງຂໍ (Request) ພຽງພໍຫຼືບໍ່? → ບໍ່ເໝາະສົມກັບການປະມວນຜົນແບບ Batch ທີ່ມີຄວາມຖີ່ຕໍ່າ ເຊິ່ງບໍ່ສາມາດນຳກັບມາໃຊ້ໃໝ່ໄດ້ພາຍໃນໄລຍະເວລາ TTL
3. ສ່ວນຕົ້ນຂອງ Prompt ມີຄວາມຄົງທີ່ຫຼືບໍ່? → Cache ມີເງື່ອນໄຂເບື້ອງຕົ້ນຄືຕ້ອງມີ Prefix ທີ່ກົງກັນ. ຈຶ່ງຈຳເປັນຕ້ອງອອກແບບໂດຍການວາງຕົວປ່ຽນແບບ Dynamic ໄວ້ທາງທ້າຍ
4. ກໍລະນີໃຊ້ Google Gemini → ຕ້ອງເອີ້ນໃຊ້ API cachedContent ຢ່າງຈະແຈ້ງ ແລະ ຕ້ອງລະວັງເລື່ອງຄ່າໃຊ້ຈ່າຍດ້ານ Storage ທີ່ຈະເພີ່ມຂຶ້ນ

ຈຸດສຳຄັນໃນການປະຕິບັດງານເພື່ອເລືອກໃຊ້

• Anthropic ເໝາະສົມກັບການໃຊ້ງານທີ່ມີຄວາມຖີ່ສູງ ແລະ Long Context
• OpenAI ເປັນລະບົບຕາມ Session ຈຶ່ງມີແນວໂນ້ມທີ່ຈະເຫັນຜົນໄດ້ດີໃນກໍລະນີການໃຊ້ງານປະເພດ Chatbot
• Google ສາມາດຕັ້ງຄ່າໄລຍະເວລາຮັກສາ Cache ໄດ້ດົນ ແຕ່ຕ້ອງຄຳນວນຄວາມສົມດຸນກັບຄ່າໃຊ້ຈ່າຍດ້ານ Storage ໃຫ້ດີ

ຄວນຈື່ໄວ້ວ່າແນວຄິດການອອກແບບນັ້ນແຕກຕ່າງຈາກ Semantic Cache ທີ່ຈະກ່າວເຖິງໃນພາກຕໍ່ໄປ.

Semantic Cache ແມ່ນກົນໄກທີ່ປ່ຽນ Input Prompt ໃຫ້ເປັນ Embedding, ຈາກນັ້ນຄົ້ນຫາ Query ທີ່ຄ້າຍຄືກັນໃນ Vector Database ເພື່ອນຳເອົາຄຳຕອບເກົ່າມາໃຊ້ໃໝ່. ເນື່ອງຈາກສາມາດຫຼີກເວັ້ນການໂທ API ໂດຍກົງໄດ້, ຈຶ່ງຄາດຫວັງວ່າຈະສາມາດຫຼຸດຕົ້ນທຶນໄດ້ຫຼາຍກວ່າ Prompt Cache.

ຂະບວນການປະຕິບັດງານພື້ນຖານ

1. ປ່ຽນ User Input ໃຫ້ເປັນ Vector ດ້ວຍ Embedding Model
2. ຄຳນວນຄ່າ Cosine Similarity ໃນ Vector Database (ເຊັ່ນ: Pinecone, Qdrant, Redis VSS, ແລະອື່ນໆ)
3. ຖ້າຄ່າຄວາມຄ້າຍຄືກັນເກີນກວ່າ Threshold (ຕົວຢ່າງ: 0.92 ຂຶ້ນໄປ), ໃຫ້ສົ່ງຄຳຕອບທີ່ Cache ໄວ້ກັບຄືນໄປ
4. ຖ້າຕ່ຳກວ່າ Threshold, ໃຫ້ໂທຫາ LLM ແລະເພີ່ມຜົນລັອກເຂົ້າໄປໃນ Cache

ການຕັ້ງຄ່າ Threshold ມີຜົນຕໍ່ຄຸນນະພາບການດຳເນີນງານ. ຖ້າຕັ້ງຕ່ຳເກີນໄປ ຈະເຮັດໃຫ້ເກີດ False positive ເພີ່ມຂຶ້ນ ແລະມີຄວາມສ່ຽງທີ່ຈະສົ່ງຄຳຕອບທີ່ຜິດພາດໃຫ້ກັບຄຳຖາມທີ່ມີຄວາມໝາຍແຕກຕ່າງກັນ. ຖ້າຕັ້ງສູງເກີນໄປ ອັດຕາການ Hit Cache ຈະຫຼຸດລົງ ແລະປະສິດທິຜົນໃນການຫຼຸດຕົ້ນທຶນຈະໜ້ອຍລົງ.

ຮູບແບບທີ່ມັກເກີດ False positive

• Query ທີ່ມີໂຄງສ້າງຄ້າຍຄືກັນແຕ່ຄຳຕອບຕ່າງກັນ ເຊັ່ນ: "ອາກາດຢູ່ໂຕກຽວເປັນແນວໃດ?" ແລະ "ອາກາດຢູ່ໂອຊາກ້າເປັນແນວໃດ?"
• ກໍລະນີທີ່ຕົວເລກ ຫຼື ຊື່ສະເພາະແຕກຕ່າງກັນ ແຕ່ບໍລິບົດຄ້າຍຄືກັນ (ເຊັ່ນ: "ຍອດຂາຍປີ 2023" vs "ຍອດຂາຍປີ 2024")
• ຄຳຖາມທີ່ຕ້ອງການການປັບແຕ່ງສະເພາະບຸກຄົນ (Personalization)

ມາດຕະການປະຕິບັດເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງ

• Metadata Filtering: ເພີ່ມ User ID, Tenant ID, ຫຼື ວັນທີ ເຂົ້າໄປໃນເງື່ອນໄຂການກັ່ນຕອງ ເພື່ອຈຳກັດຂອບເຂດ
• ການຕັ້ງຄ່າ TTL ຂອງ Entry: ສຳລັບຂໍ້ມູນທີ່ຄວາມສົດໃໝ່ມີຄວາມສຳຄັນ ໃຫ້ຕັ້ງອາຍຸການໃຊ້ງານທີ່ສັ້ນ ເພື່ອປ້ອງກັນການນຳເອົາຄຳຕອບທີ່ລ້າສະໄໝມາໃຊ້ໃໝ່
• ການເກັບ Log ຂອງຊັ້ນ Cache: ສົ່ງຄູ່ Input/Output ໃນເວລາທີ່ເກີດ Hit ໄປຍັງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ານ AI Observability ເພື່ອດຳເນີນການທົບທວນຄຸນນະພາບເປັນໄລຍະ

ເຖິງແມ່ນວ່າ Semantic Cache ຈະມີປະສິດທິພາບສູງ ແຕ່ກໍມີຄວາມສ່ຽງດ້ານຄວາມຖືກຕ້ອງທີ່ຫຼຸດລົງ. ດັ່ງນັ້ນ, ການອອກແບບການດຳເນີນງານທີ່ປະສົມປະສານກັບ Dataset ການປະເມີນຜົນທີ່ຈະກ່າວເຖິງໃນພາກຕໍ່ໄປ ເພື່ອຕິດຕາມທັງອັດຕາການ Hit ແລະຄຸນນະພາບ ຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

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

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

ຫຼັກການການສ້າງຊຸດຂໍ້ມູນການປະເມີນຜົນ

• Golden Set: ຄູ່ຂໍ້ມູນເຂົ້າ-ອອກທີ່ເປັນຕົວແທນ ເຊິ່ງສະກັດມາຈາກບັນທຶກການໃຊ້ງານຈິງ (Production log). ຄວນເກັບກຳຂໍ້ມູນຢ່າງໜ້ອຍ 100-300 ລາຍການ.
• Edge Case Set: ບັນຈຸກໍລະນີທີ່ມີການລາຍງານວ່າຕອບຜິດ ແລະ ເງື່ອນໄຂຂອບເຂດ (Boundary conditions) ໂດຍເຈດຕະນາ.
• ການແບ່ງຕາມປະເພດວຽກ: ແຍກຕົວຊີ້ວັດການປະເມີນຕາມປະເພດວຽກ ເຊັ່ນ: ການສະຫຼຸບຄວາມ, ການຈັດໝວດໝູ່, ການສ້າງເນື້ອຫາ (ຕົວຢ່າງ: ການຈັດໝວດໝູ່ໃຊ້ F1, ການສະຫຼຸບຄວາມໃຊ້ BERTScore).

ຊຸດຂໍ້ມູນບໍ່ຄວນເປັນສິ່ງທີ່ "ສ້າງຄັ້ງດຽວແລ້ວຈົບ". ການດຳເນີນງານທີ່ສຳຄັນຄື ເມື່ອພົບຮູບແບບຄວາມຜິດພາດໃໝ່ໃນລະບົບຈິງ, ຕ້ອງເພີ່ມເຂົ້າໃນຊຸດຂໍ້ມູນທຸກຄັ້ງ.

ວິທີການອອກແບບ regression budget

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

• ຕົວຢ່າງ: ຮັກສາອັດຕາຄວາມຖືກຕ້ອງຂອງວຽກຫຼັກໃຫ້ຢູ່ໃນລະດັບ ±2%, ບໍ່ໃຫ້ອັດຕາການເກີດ Hallucination ແຍ່ລົງກວ່າລະດັບປັດຈຸບັນ, ແລະ ອື່ນໆ.
• ຄວນຈັດການໂດຍໃຊ້ແນວຄວາມຄິດຂອງການໃຊ້ budget ໃນແຕ່ລະມາດຕະການ, ແລະ ຄວນມີກົນໄກທີ່ສັ່ງ Rollback ໂດຍອັດຕະໂນມັດຫາກເກີນຂອບເຂດທີ່ກຳນົດໄວ້.

ການລວມເຂົ້າໃນ CI/CD

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

ໃນພາກສະໜາມການປັບແຕ່ງຕົ້ນທຶນ LLM ໃຫ້ເໝາະສົມ, ມີການລາຍງານກໍລະນີທີ່ຕົກຢູ່ໃນຂຸມພາງດຽວກັນຊ້ຳໆ. ຂໍສະຫຼຸບ Anti-pattern ທີ່ພົບເຫັນເລື້ອຍໆດັ່ງນີ້:

Q1. "ເມື່ອປ່ຽນມາໃຊ້ໂມເດວທີ່ລາຄາຖືກກວ່າ ແລ້ວຄວາມແມ່ນຍຳກໍຫຼຸດລົງ"

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

Q2. "ເປີດໃຊ້ງານ Prompt Cache ແລ້ວ ແຕ່ຕົ້ນທຶນບໍ່ຫຼຸດລົງ"

ສາເຫດທີ່ພົບເລື້ອຍມີ 3 ປະການດັ່ງນີ້:

• Prefix ທີ່ເປັນເປົ້າໝາຍໃນການ Cache ມີການປ່ຽນແປງໃນທຸກໆການສົນທະນາ
• ມີການປົນເປື້ອນຂອງ Timestamp ຫຼື ຕົວແປແບບໄດນາມິກຢູ່ທ້າຍ System Prompt
• Prompt ສັ້ນເກີນໄປ ເຊິ່ງບໍ່ເຖິງຈຳນວນ Token ຂັ້ນຕ່ຳ (Anthropic ກຳນົດໄວ້ທີ່ 1,024 Token)

ໂດຍພື້ນຖານແລ້ວ, ຄວນລວມອົງປະກອບທີ່ເປັນໄດນາມິກໄວ້ທ້າຍ Prompt ແລະ ເຮັດໃຫ້ສ່ວນທີ່ເປັນ Static ຢູ່ທາງໜ້າຄົງທີ່.

Q3. "ໄດ້ຮັບຄຳຕອບທີ່ຜິດພາດຈາກ Semantic Cache"

ຫາກຕັ້ງຄ່າ Threshold ຂອງຄວາມຄ້າຍຄືກັນຕ່ຳເກີນໄປ, ຈະເກີດການ Hit ທີ່ຜິດພາດ ເຊິ່ງສົ່ງຜົນໃຫ້ມີການຕອບຄຳຖາມເກົ່າກັບຄຳຖາມທີ່ມີຄວາມໝາຍແຕກຕ່າງກັນ. ແນະນຳໃຫ້ເລີ່ມຕົ້ນຕັ້ງຄ່າ Threshold ໄວ້ທີ່ປະມານ 0.95 ແລ້ວປັບປ່ຽນໃຫ້ເໝາະສົມກັບຄຸນລັກສະນະຂອງຄຳສັບໃນ Domain ນັ້ນໆ.

Q4. "ເມື່ອນຳມາດຕະການຫຼຸດຕົ້ນທຶນມາໃຊ້ ແລ້ວຕົວເລກບໍ່ກົງກັບລາຍງານປະຈຳເດືອນ"

ເປັນກໍລະນີທີ່ການອອກແບບ FinOps Tag ບໍ່ພຽງພໍ ເຮັດໃຫ້ຕົ້ນທຶນແຍກຕາມໂມເດວ ແລະ ຕາມຟັງຊັນປົນເປກັນ. ຫາກບໍ່ກຳນົດລະບົບ Tag ຕັ້ງແຕ່ຕອນເລີ່ມຕົ້ນໂຄງການ, ການແຍກຂໍ້ມູນໃນພາຍຫຼັງມັກຈະເຮັດໄດ້ຍາກ.

ບົດຮຽນຮ່ວມ: ການປັບແຕ່ງໂດຍບໍ່ມີການວັດແທກມັກຈະກາຍເປັນການເຮັດໃຫ້ລະບົບແຍ່ລົງ. ການປ່ຽນແປງຄວນເຮັດເທື່ອລະຢ່າງ ແລະ ຕ້ອງສ້າງນິໄສໃນການກວດສອບຜົນລັັບດ້ວຍ A/B Test ສະເໝີ.

ການປັບໃຫ້ເໝາະສົມກັບຕົ້ນທຶນຂອງ LLM ບໍ່ແມ່ນມາດຕະການທີ່ເຮັດຄັ້ງດຽວແລ້ວຈົບ. ການປະສົມປະສານ 4 ເສົາຫຼັກ ຄື: ການຫຼຸດຈຳນວນ Token, ການເລືອກ Model, ການເຮັດ Prompt Caching ແລະ ການອອກແບບ RAG ເພື່ອສ້າງວົງຈອນການປັບປຸງຢ່າງຕໍ່ເນື່ອງນັ້ນແມ່ນສິ່ງສຳຄັນ.

ເມື່ອຈັດລະບຽບວິທີການທີ່ໄດ້ອະທິບາຍໄວ້ໃນບົດຄວາມນີ້, ຈະເຫັນລຳດັບຄວາມສຳຄັນດັ່ງນີ້:

• ເລີ່ມຈາກການເຮັດໃຫ້ເຫັນພາບ (Visualization): ການປັບໃຫ້ເໝາະສົມຈະບໍ່ເລີ່ມຕົ້ນຖ້າບໍ່ມີພື້ນຖານການວັດແທກຕົ້ນທຶນ. ການເຂົ້າໃຈພື້ນຖານການບໍລິໂພກ Token ດ້ວຍເຄື່ອງມື AI Observability ແມ່ນຈຸດເລີ່ມຕົ້ນ.
• ຕໍ່ມາແມ່ນການຫຼຸດຈຳນວນ Token: ການຈັດໂຄງສ້າງ System Prompt ແລະ ການບີບອັດ Context ແມ່ນມີປະສິດທິຜົນສູງ ແລະ ບໍ່ຈຳເປັນຕ້ອງໃຊ້ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ເພີ່ມເຕີມ.
• ການອອກແບບລຳດັບຊັ້ນຂອງ Model: ຢ່າລວມສູນທຸກຄຳຮ້ອງຂໍ (Request) ໄວ້ທີ່ Model ປະສິດທິພາບສູງ, ແຕ່ໃຫ້ Routing ໄປຫາ SLM ຫຼື Local LLM ຕາມຄວາມຊັບຊ້ອນຂອງວຽກ.
• ການກຳຈັດຂໍ້ມູນຊ້ຳຊ້ອນດ້ວຍ Cache: ການປະສົມປະສານລະຫວ່າງ Prompt Caching ແລະ Semantic Caching ສາມາດຫຼຸດຕົ້ນທຶນຂອງການປະມວນຜົນຊ້ຳໆໄດ້ຢ່າງມະຫາສານ.

ຄວາມແມ່ນຍຳ ແລະ ຕົ້ນທຶນ ບໍ່ແມ່ນ ການແລກປ່ຽນ ຫຼື Trade-off ແຕ່ສາມາດເຮັດໃຫ້ໄປຄຽງຄູ່ກັນໄດ້ຂຶ້ນຢູ່ກັບການອອກແບບ. ການກຳນົດ Dataset ສຳລັບການປະເມີນຜົນ ແລະ Regression Budget ແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້ ເພື່ອຕິດຕາມກວດກາຢ່າງເປັນປະລິມານວ່າການຫຼຸດຕົ້ນທຶນນັ້ນບໍ່ໄດ້ສົ່ງຜົນໃຫ້ຄຸນນະພາບຫຼຸດລົງ.

LLM FinOps ເປັນຂົງເຂດທີ່ຈະສືບຕໍ່ພັດທະນາໃນອະນາຄົດ, ຈຶ່ງຈຳເປັນຕ້ອງມີທັດສະນະຄະຕິໃນການທົບທວນຍຸດທະສາດການ Routing ໃຫ້ສອດຄ່ອງກັບການປ່ຽນແປງສະເປັກຂອງຜູ້ໃຫ້ບໍລິການແຕ່ລະລາຍ ແລະ ການປະກົດຕົວຂອງ Model ໃໝ່ໆ. ຫວັງວ່າທ່ານຈະສາມາດສ້າງແຜນທີ່ນຳທາງ (Roadmap) ໃນການປັບໃຫ້ເໝາະສົມທີ່ເໝາະສົມກັບ Use Case ຂອງບໍລິສັດທ່ານ ໂດຍອີງໃສ່ກອບວຽກ (Framework) ຈາກບົດຄວາມນີ້.