Prompt Caching for Multi-Tenant ແມ່ນຫຍັງ? ການອອກແບບເພື່ອຫຼຸດຕົ້ນທຶນການອະນຸມານສຳລັບ B2B SaaS

Prompt Caching for Multi-Tenant ແມ່ນວິທີການອອກແບບເພື່ອຫຼຸດຜ່ອນຕົ້ນທຶນການອະນຸມານ (Inference) ແລະ ຄວາມໜ່ວງ (Latency) ໂດຍການແຄຊ (Cache) ລະບົບ Prompt ຫຼື Context Window ຂອງແຕ່ລະ Tenant ໃນໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງ LLM (Large Language Model) ທີ່ຫຼາຍ Tenant ນຳໃຊ້ຮ່ວມກັນ.

ໃນ B2B SaaS, ເມື່ອຈຳນວນ Tenant ເພີ່ມຂຶ້ນ, ຈຳນວນການເອີ້ນໃຊ້ API ໄປຍັງ LLM ກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ, ເຊິ່ງມັກຈະເຮັດໃຫ້ເກີດບັນຫາຕົ້ນທຶນຂອງ Input Token ກົດດັນຜົນກຳໄລ. ຖ້າອອກແບບ Prompt Caching ຢ່າງເໝາະສົມ, ຈະສາມາດຫຼຸດຜ່ອນຕົ້ນທຶນໃນເວລາອ່ານຂໍ້ມູນຈາກ Cache ໄດ້ຢ່າງຫຼວງຫຼາຍ, ໃນຂະນະດຽວກັນກໍມີຄວາມສ່ຽງໃນເລື່ອງຂໍ້ມູນຂອງແຕ່ລະ Tenant ປົນກັນ.

ໃນບົດຄວາມນີ້, ພວກເຮົາຈະອະທິບາຍເນື້ອຫາຕໍ່ໄປນີ້ຕາມລຳດັບ ເພື່ອໃຫ້ວິສະວະກອນ ແລະ ສະຖາປະນິກໄດ້ເຂົ້າໃຈ:

Prompt Cache ແມ່ນກົນໄກທີ່ຮັກສາສ່ວນໜ້າຂອງ Prompt ຍາວໆທີ່ຖືກສົ່ງທຸກຄັ້ງໃນເວລາຮ້ອງຂໍໄປຍັງ LLM ໄວ້ຢູ່ຝັ່ງເຊີບເວີ ເພື່ອຫຼຸດຜ່ອນຂະບວນການໃນຄັ້ງຕໍ່ໄປ. ໃນ B2B SaaS ທີ່ມີການໃຊ້ System Prompt ຫຼື Context ແບບຄົງທີ່ຊ້ຳໆ, ກົນໄກນີ້ສົ່ງຜົນໂດຍກົງຕໍ່ຕົ້ນທຶນໃນການປະມວນຜົນ (Inference cost).

ຢ່າງໃດກໍຕາມ, ໃນສະພາບແວດລ້ອມ Multi-tenant ເລື່ອງນີ້ບໍ່ໄດ້ງ່າຍດາຍປານນັ້ນ. ຖ້າພະຍາຍາມນຳເອົາ System Prompt ຫຼື ຂໍ້ມູນສິດທິທີ່ແຕກຕ່າງກັນໃນແຕ່ລະ Tenant ໄປໄວ້ໃນ Cache, ບັນຫາເລື່ອງການແຍກຂໍ້ມູນວ່າ "ຈະຮັກສາ Cache ຂອງໃຜໄວ້ບ່ອນໃດ" ກໍຈະເກີດຂຶ້ນ. ຖ້າໃຫ້ຄວາມສຳຄັນກັບການຫຼຸດຕົ້ນທຶນໂດຍການແບ່ງປັນ Cache ຮ່ວມກັນ ກໍຈະເກີດຄວາມສ່ຽງຕໍ່ການຮົ່ວໄຫຼຂອງຂໍ້ມູນ, ແຕ່ຖ້າແຍກ Cache ຢ່າງສົມບູນໃນແຕ່ລະ Tenant ກໍຈະເຮັດໃຫ້ອັດຕາການ Cache Hit ຫຼຸດລົງ ແລະ ປະສິດທິຜົນໃນການຫຼຸດຕົ້ນທຶນກໍຈະໜ້ອຍລົງ.

ໃນທີ່ນີ້, ພວກເຮົາຈະມາຮຽບຮຽງຕັ້ງແຕ່ຫຼັກການເຮັດວຽກພື້ນຖານຂອງ Prompt Cache, ໂຄງສ້າງຕົ້ນທຶນທີ່ເປັນເອກະລັກຂອງ B2B SaaS, ແລະ ເຫດຜົນທີ່ການອອກແບບ Cache ໃນສະພາບແວດລ້ອມ Multi-tenant ມີຄວາມຊັບຊ້ອນຂຶ້ນເລື້ອຍໆ.

Prompt Cache ແມ່ນກົນໄກທີ່ເກັບຮັກສາ "ສ່ວນຫົວທີ່ບໍ່ປ່ຽນແປງ (Prefix)" ຂອງຄຳຮ້ອງຂໍ API ໄປຍັງ LLM ໄວ້ໃນໜ່ວຍຄວາມຈຳຂອງເຊີບເວີອະນຸມານ (Inference Server) ເພື່ອນຳກັບມາໃຊ້ໃໝ່ໃນຄຳຮ້ອງຂໍຄັ້ງຕໍ່ໄປ. ແທນທີ່ຈະຕ້ອງປະມວນຜົນ System Prompt ຫຼື Context ທີ່ມີຄວາມຍາວຫຼາຍຊໍ້າຄືນທຸກຄັ້ງ, ລະບົບຈະອ່ານ Key-Value Tensor ທີ່ຖືກແຄຊໄວ້ແລ້ວ, ເຊິ່ງຊ່ວຍຫຼຸດຕົ້ນທຶນໃນການປະມວນຜົນ Input Token ໄດ້ຢ່າງຫຼວງຫຼາຍ.

ໃນຕອນທຳອິດ, ຫຼາຍຄົນອາດເຂົ້າໃຈຜິດວ່າ "Cache ແມ່ນການບັນທຶກ Response ທັງໝົດໄວ້", ແຕ່ຄວາມເຂົ້າໃຈທີ່ຖືກຕ້ອງແມ່ນການແຄຊສະເພາະ Prefix ຝັ່ງ Input ຂອງ Prompt ເທົ່ານັ້ນ. ເນື່ອງຈາກ Output ຈະຖືກສ້າງຂຶ້ນໃໝ່ທຸກຄັ້ງ, ສິ່ງທີ່ຖືກຫຼຸດຕົ້ນທຶນຈຶ່ງຈຳກັດຢູ່ທີ່ຕົ້ນທຶນການປະມວນຜົນ Input Token ເທົ່ານັ້ນ.

ເມື່ອຈັດລະບຽບກົນໄກການເຮັດວຽກ, ຈະມີຂັ້ນຕອນດັ່ງນີ້:

• ການຂຽນ (Write): ໃນຄຳຮ້ອງຂໍຄັ້ງທຳອິດ, Prefix ຈະຖືກບັນທຶກໄວ້ເປັນ Key-Value Tensor.
• ການອ່ານ (Read): ໃນຄຳຮ້ອງຂໍຕໍ່ໆໄປທີ່ມີ Prefix ດຽວກັນ, ແຄຊຈະຖືກນຳກັບມາໃຊ້ໃໝ່.
• ສ່ວນຕ່າງຂອງຕົ້ນທຶນ: ໃນ Claude ຂອງ Anthropic, ຕົ້ນທຶນການອ່ານແຄຊໂດຍປົກກະຕິຈະຢູ່ທີ່ 0.1 ເທົ່າ ຂອງລາຄາ Input, ໃນຂະນະທີ່ການຂຽນແຄຊຈະຢູ່ທີ່ 1.25 ເທົ່າ (ໃນກໍລະນີ TTL 5 ນາທີ).

ຈຳນວນ Token ຂັ້ນຕໍ່າທີ່ເຮັດໃຫ້ແຄຊມີຜົນນັ້ນຈະແຕກຕ່າງກັນໄປຕາມຜູ້ໃຫ້ບໍລິການ. OpenAI ກຳນົດໄວ້ທີ່ 1,024 Token ຂຶ້ນໄປ, ສ່ວນ Claude Opus ໃນ AWS Bedrock ກຳນົດໄວ້ທີ່ 4,096 Token ຂຶ້ນໄປ.

TTL (Time To Live) ກໍເປັນຕົວແປທີ່ສຳຄັນໃນການອອກແບບເຊັ່ນກັນ.

ຄ່າໃຊ້ຈ່າຍໃນການປະມວນຜົນ (Inference cost) ຂອງ B2B SaaS ມີຈຸດພິເສດຄື ມັນບໍ່ໄດ້ເພີ່ມຂຶ້ນຕາມຈຳນວນຜູ້ໃຊ້ ແຕ່ຈະເພີ່ມຂຶ້ນຕາມຜົນຄູນຂອງ ຈຳນວນຜູ້ເຊົ່າ (Tenant) × ຈຳນວນຄຳຮ້ອງຂໍ (Request) × ຈຳນວນ Token. ເນື່ອງຈາກແຕກຕ່າງຈາກການບໍລິການສຳລັບຜູ້ໃຊ້ທົ່ວໄປ (End-user), ການບໍລິການແບບ B2B ຈະຕ້ອງສົ່ງ System Prompt ຫຼື ກົດລະບຽບການເຮັດວຽກສະເພາະຂອງລູກຄ້າແຕ່ລະບໍລິສັດໄປທຸກຄັ້ງ, ເຮັດໃຫ້ຈຳນວນ Input Token ມີຂະໜາດໃຫຍ່ຂຶ້ນຢ່າງຕໍ່ເນື່ອງ.

ເມື່ອແຍກໂຄງສ້າງຕົ້ນທຶນອອກມາ ຈະເຫັນໄດ້ວ່າມີ 3 ຊັ້ນຊ້ອນກັນຢູ່: ຊັ້ນທຳອິດຄື System Prompt Layer ເຊິ່ງລວມເອົາກົດລະບຽບການເຮັດວຽກ, ຂໍ້ຈຳກັດ ແລະ ການກຳນົດຕົວຕົນ (Persona) ຂອງຜູ້ເຊົ່າແຕ່ລະລາຍເຂົ້າໄວ້ດ້ວຍກັນ, ເຊິ່ງບາງຄັ້ງອາດມີຄວາມຍາວເຖິງຫຼາຍຮ້ອຍຫາຫຼາຍພັນ Token. ຕໍ່ມາຄື Context Layer ເຊິ່ງປະກອບດ້ວຍປະຫວັດການສົນທະນາ ຫຼື ຂໍ້ມູນທີ່ໄດ້ມາຈາກ RAG, ເຊິ່ງຂໍ້ມູນເຫຼົ່ານີ້ຈະຖືກສົ່ງໃໝ່ທຸກຄັ້ງທີ່ມີການຮ້ອງຂໍ. ສຸດທ້າຍຄື User Input Layer ຫຼື ຄຳຖາມທີ່ຜູ້ໃຊ້ປ້ອນເຂົ້າໄປແທ້ໆ, ເຊິ່ງມີຈຳນວນ Token ໜ້ອຍກວ່າເມື່ອທຽບກັບສ່ວນອື່ນ.

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

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

"ຖ້າຫາກເຮົາເກັບ Cache ຂອງ System Prompt ຂອງ Tenant A ໄວ້, ມັນຈະເກີດເຫດການທີ່ Request ຂອງ Tenant B ໄປດຶງເອົາ Cache ນັ້ນມາໃຊ້ໂດຍບໍ່ຕັ້ງໃຈຫຼືບໍ່?" — ເມື່ອເລີ່ມພິຈາລະນາເລື່ອງ Prompt Cache ໃນສະພາບແວດລ້ອມ Multi-tenant, ວິສະວະກອນຫຼາຍຄົນມັກຈະປະເຊີນກັບຄວາມກັງວົນນີ້ເປັນອັນດັບທຳອິດ.

ຄວາມກັງວົນນີ້ບໍ່ແມ່ນເລື່ອງທີ່ເກີນຈິງແຕ່ຢ່າງໃດ. ເຫດຜົນຫຼັກທີ່ເຮັດໃຫ້ການຈັດການ Cache ໃນສະພາບແວດລ້ອມ Multi-tenant ມີຄວາມຫຍຸ້ງຍາກ ສາມາດສະຫຼຸບໄດ້ 3 ປະການດັ່ງນີ້:

• ຂໍ້ກຳນົດໃນການແຍກຂໍ້ມູນລະຫວ່າງ Tenant: System Prompt ຂອງແຕ່ລະ Tenant ຈະມີຂໍ້ມູນສະເພາະຕົວ ເຊັ່ນ: ກົດລະບຽບການເຮັດວຽກ, ໂຄງສ້າງລາຄາ, ແລະນະໂຍບາຍຄວາມລັບ. ຫາກອອກແບບ Cache Key ຜິດພາດ ກໍອາດມີຄວາມສ່ຽງທີ່ Request ຂອງ Tenant ອື່ນຈະອ້າງອີງເຖິງ Cache ດຽວກັນ.
• ຄວາມຫຼາກຫຼາຍຂອງໂຄງສ້າງ Prompt: ເນື່ອງຈາກຄວາມຍາວ ແລະ ອົງປະກອບຂອງ System Prompt ແຕກຕ່າງກັນໄປໃນແຕ່ລະ Tenant, ຈຶ່ງເຮັດໃຫ້ Common Prefix ມີໂອກາດສັ້ນລົງ ແລະ ສົ່ງຜົນໃຫ້ອັດຕາການ Cache Hit ຫຼຸດລົງ. ນອກຈາກນີ້, Prompt Cache ຈະບໍ່ຄ່ອຍເຫັນຜົນຫາກບໍ່ມີສ່ວນທີ່ຄືກັນເກີນ 1,024 Token, ເຊິ່ງເປັນຈຸດທີ່ເພີ່ມຄວາມຫຍຸ້ງຍາກໃນການອອກແບບ.
• ຄວາມບໍ່ສອດຄ່ອງກັນລະຫວ່າງ TTL ແລະ Tenant Lifecycle: ເມື່ອ Tenant ມີການປ່ຽນແປງສັນຍາ ຫຼື ອັບເດດແພັກເກດ, ຫາກອາຍຸການໃຊ້ງານຂອງ Cache (TTL) ຍັງເຫຼືອຢູ່ ກໍອາດເຮັດໃຫ້ມີການນຳໃຊ້ການຕັ້ງຄ່າເກົ່າຕໍ່ໄປ. ໃນ Anthropic Claude, ມາດຕະຖານ TTL ຈະຢູ່ທີ່ 5 ນາທີ ແລະ ສາມາດຂະຫຍາຍໄດ້ສູງສຸດ 1 ຊົ່ວໂມງ, ແຕ່ກໍຍັງຈຳເປັນຕ້ອງມີກົນໄກແຍກຕ່າງຫາກເພື່ອຮັກສາຄວາມສົມດຸນລະຫວ່າງຄວາມຖີ່ໃນການປ່ຽນແປງການຕັ້ງຄ່າຂອງ Tenant ກັບ TTL.

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

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

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

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

ມາດຕະຖານ ຫຼື Specification ຂອງຜູ້ໃຫ້ບໍລິການຫຼັກໆ ມີດັ່ງນີ້:

• OpenAI: Cache ຈະມີຜົນນຳໃຊ້ເມື່ອ Prompt ມີຂະໜາດ 1,024 Token ຂຶ້ນໄປ. ທ່ານສາມາດກວດສອບຈຳນວນ Cache hit ໄດ້ຈາກ usage.prompt_tokens_details.cached_tokens ໃນ Response. In-memory Cache ຈະໝົດອາຍຸພາຍໃນ 5-10 ນາທີ ຫາກບໍ່ມີການເຄື່ອນໄຫວ ແລະ ສາມາດຮັກສາໄວ້ໄດ້ສູງສຸດ 1 ຊົ່ວໂມງ. ສ່ວນ Extended ສາມາດຮັກສາໄວ້ໄດ້ສູງສຸດ 24 ຊົ່ວໂມງ. ມີການແນະນຳໃຫ້ຄວບຄຸມ prompt_cache_key ທີ່ມີ Prefix ດຽວກັນໃຫ້ຕໍ່າກວ່າ 15 ຄັ້ງຕໍ່ນາທີ.
• Anthropic (Claude): TTL ເລີ່ມຕົ້ນແມ່ນ 5 ນາທີ. ທາງເລືອກ 1 ຊົ່ວໂມງຈະມີຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມ, ໂດຍຄ່າໃຊ້ຈ່າຍໃນການຂຽນ Cache ຈະເທົ່າກັບ 1.25 ເທົ່າ (ສຳລັບ 5 ນາທີ) ຫຼື 2 ເທົ່າ (ສຳລັບ 1 ຊົ່ວໂມງ) ຂອງລາຄາ Input ພື້ນຖານ, ແລະ ການອ່ານຈະເທົ່າກັບ 0.1 ເທົ່າ.
• AWS Bedrock (Claude Sonnet): ຈຳນວນ Token ຂັ້ນຕໍ່າຂອງ Cache ແມ່ນ 1,024 Token, TTL ເລີ່ມຕົ້ນແມ່ນ 5 ນາທີ. ໃນກໍລະນີຂອງ Claude Opus, ຈຳເປັນຕ້ອງມີຢ່າງໜ້ອຍ 4,096 Token ແລະ ສາມາດຕັ້ງຄ່າ Cache ໄດ້ສູງສຸດ 4 ສ່ວນ.

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

ຮູບແບບ Silo ເປັນຮູບແບບທີ່ຈັດສັນ LLM endpoint ຫຼື ພື້ນທີ່ Cache ສະເພາະໃຫ້ແຕ່ລະ Tenant. ມີຄວາມສ່ຽງຕໍ່ການປົນເປື້ອນຂອງຂໍ້ມູນຕໍ່າທີ່ສຸດ, ເໝາະສົມກັບ SaaS ໃນກຸ່ມການເງິນ ຫຼື ການແພດທີ່ມີຂໍ້ກຳນົດດ້ານການປະຕິບັດຕາມກົດລະບຽບທີ່ເຄັ່ງຄັດ. ຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກຂອບເຂດການນຳໃຊ້ Cache ຄືນໃໝ່ຖືກຈຳກັດຢູ່ພາຍໃນ Tenant, ຄ່າໃຊ້ຈ່າຍດ້ານໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຈຶ່ງມີທ່າອ່ຽງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຕາມຈຳນວນ Tenant ທີ່ເພີ່ມຂຶ້ນ.

ຮູບແບບ Pool ເປັນຮູບແບບທີ່ຫຼາຍ Tenant ໃຊ້ພື້ນທີ່ Cache ແລະ System Prompt ຮ່ວມກັນ. ອັດຕາການ Cache hit ຂອງ Shared Prefix ຈະສູງຂຶ້ນ, ເຊິ່ງສາມາດຫຼຸດຕົ້ນທຶນການປະມວນຜົນ (Inference cost) ໄດ້ຢ່າງຫຼວງຫຼາຍ. ໃນທາງກັບກັນ, ຖ້າການອອກແບບ Cache key ບໍ່ພຽງພໍ ຈະເຮັດໃຫ້ເກີດຄວາມສ່ຽງຕໍ່ການປົນເປື້ອນຂອງຂໍ້ມູນລະຫວ່າງ Tenant, ດັ່ງນັ້ນການອອກແບບ Cache key ທີ່ຈະກ່າວເຖິງໃນພາຍຫຼັງຈຶ່ງມີຄວາມສຳຄັນ ຫຼື ແກນຫຼັກ ໂດຍສະເພາະ.

ຮູບແບບ Hybrid ເປັນຮູບແບບປະສົມປະສານທີ່ຈັດການສ່ວນທີ່ໃຊ້ຮ່ວມກັນ (System Prompt ທີ່ເປັນມາດຕະຖານຂອງຜະລິດຕະພັນ) ດ້ວຍຮູບແບບ Pool ແລະ ແຍກ Context ສະເພາະຂອງ Tenant ດ້ວຍຮູບແບບ Silo. ເປັນຮູບແບບທີ່ງ່າຍຕໍ່ການຮັກສາຄວາມສົມດຸນລະຫວ່າງປະສິດທິພາບດ້ານຕົ້ນທຶນ ແລະ ຄວາມປອດໄພ, ເໝາະສົມກັບ B2B SaaS ຈຳນວນຫຼາຍ.

ເກນການຕັດສິນໃຈໃນການເລືອກມີດັ່ງນີ້: ຖ້າອະທິປະໄຕຂອງຂໍ້ມູນ (Data sovereignty) ຫຼື ຂໍ້ກຳນົດດ້ານການປະຕິບັດຕາມກົດລະບຽບແຕກຕ່າງກັນໃນແຕ່ລະ Tenant, ຮູບແບບ Silo ຫຼື Hybrid ແມ່ນເໝາະສົມ; ສ່ວນຮູບແບບ Pool ແມ່ນເໝາະສົມໃນກໍລະນີທີ່ຂໍ້ກຳນົດລະຫວ່າງ Tenant ມີຄວາມຄ້າຍຄືກັນ ແລະ ຕ້ອງການໃຫ້ຄວາມສຳຄັນກັບການເພີ່ມປະສິດທິພາບດ້ານຕົ້ນທຶນ.

"ຄວນເຮັດໃຫ້ System Prompt ເປັນມາດຕະຖານຮ່ວມກັນເຖິງຂັ້ນໃດ ແລະ ຄວນເລີ່ມແຍກເປັນສ່ວນສະເພາະຂອງແຕ່ລະ Tenant ເມື່ອໃດ" — ນີ້ແມ່ນສິ່ງທີ່ຫຼາຍທີມງານຍັງສັບສົນໃນການກຳນົດຂອບເຂດ. ແນວທາງການອອກແບບ Context Window ແລະ System Prompt ມີຜົນໂດຍກົງຕໍ່ປະສິດທິພາບຂອງ Cache, ສະນັ້ນຈຶ່ງຈຳເປັນຕ້ອງຈັດລະບຽບໃຫ້ຮຽບຮ້ອຍກ່ອນການລົງມືປະຕິບັດງານ.

ຫຼັກການພື້ນຖານຂອງການອອກແບບຄື "ການລວມສ່ວນທີ່ບໍ່ປ່ຽນແປງໄວ້ທາງດ້ານໜ້າ". Prompt Cache ຂອງ LLM (Large Language Model) ຈະເຮັດການ Cache ຂໍ້ມູນຈາກສ່ວນ Prefix ທີ່ກົງກັນຕັ້ງແຕ່ຕົ້ນຂອງ Prompt. ການຈັດວາງ Context ສ່ວນກາງທີ່ບໍ່ມີການປ່ຽນແປງໄວ້ທາງດ້ານໜ້າ ແລະ ວາງຂໍ້ມູນສະເພາະຂອງ Tenant ໄວ້ທາງດ້ານຫຼັງ ຈະຊ່ວຍເພີ່ມອັດຕາການ Cache Hit ໄດ້ຢ່າງຫຼວງຫຼາຍ.

ການອອກແບບ System Prompt ໃຫ້ມີປະສິດທິພາບຄວນແບ່ງອອກເປັນ 3 ຊັ້ນ ດັ່ງນີ້:

• ຊັ້ນສ່ວນກາງ (Common Layer - ແບ່ງປັນໃຫ້ທຸກ Tenant): ກົດລະບຽບການເຮັດວຽກພື້ນຖານຂອງຜະລິດຕະພັນ, ຮູບແບບການຕອບໂຕ້, ຂໍ້ຫ້າມຕ່າງໆ ແລະ ອື່ນໆ. ຄວນລວມເອົາສ່ວນທີ່ມີຄວາມຍາວຫຼາຍທີ່ສຸດ ແລະ ມີຄວາມຖີ່ໃນການປ່ຽນແປງຕ່ຳໄວ້ໃນສ່ວນນີ້.
• ຊັ້ນແຜນການ (Plan Layer - ແບ່ງປັນຕາມແຜນ ຫຼື ປະເພດທຸລະກິດ): ຄຳອະທິບາຍຟີເຈີສຳລັບລະດັບ Enterprise ຫຼື ແນວທາງປະຕິບັດຕາມປະເພດທຸລະກິດ ເຊິ່ງເປັນ Context ທີ່ Tenant ໃນແຜນດຽວກັນສາມາດນຳໃຊ້ຮ່ວມກັນໄດ້.
• ຊັ້ນສະເພາະຂອງ Tenant (Tenant-specific Layer): ຊື່ Tenant, ການຕັ້ງຄ່າແບບກຳນົດເອງ (Custom), ນະໂຍບາຍສະເພາະ ແລະ ອື່ນໆ. ຄວນອອກແບບໃຫ້ມີຄວາມຍາວສັ້ນທີ່ສຸດ.

ສຳລັບ Claude ຂອງ Anthropic, ຂະໜາດຂັ້ນຕ່ຳຂອງ Cache ແມ່ນ 1,024 Token. ຖ້າອອກແບບໃຫ້ຊັ້ນສ່ວນກາງມີຄວາມຍາວເກີນຂີດຈຳກັດນີ້, ການຂຽນຂໍ້ມູນລົງ Cache ຈະມີຜົນນຳໃຊ້. ເນື່ອງຈາກ Claude Opus ໃນ AWS Bedrock ຕ້ອງການຂະໜາດຂັ້ນຕ່ຳເຖິງ 4,096 Token, ກະລຸນາປັບປ່ຽນປະລິມານຂອງຊັ້ນສ່ວນກາງໃຫ້ເໝາະສົມກັບແຕ່ລະ Provider.

ສະຫຼຸບ: ຄວາມຜິດພາດໃນການອອກແບບ Cache Key ຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ເກີດການປົນເປື້ອນຂອງຂໍ້ມູນລະຫວ່າງ Tenant ໂດຍກົງ, ດັ່ງນັ້ນການກຳນົດກົດລະບຽບການຕັ້ງຊື່ ແລະ ໂຄງສ້າງການແຍກສ່ວນໃຫ້ຊັດເຈນລ່ວງໜ້າ ຈຶ່ງເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ.

ໃນການອອກແບບ Cache Key ສຳລັບແຕ່ລະ Tenant, ການປະສົມປະສານລະຫວ່າງ Shared Prefix ແລະ Tenant-specific Suffix ລວມເຖິງການຈັດການ TTL ແມ່ນເປັນຫົວໃຈສຳຄັນ.

ຄວາມຜິດພາດທີ່ມັກພົບເລື້ອຍໃນຕອນເລີ່ມຕົ້ນຂອງການອອກແບບ Cache Key ຄືແນວຄວາມຄິດທີ່ວ່າ "ພຽງແຕ່ນຳໃຊ້ User ID ຫຼື Session ID ມາເປັນ Key ກໍພຽງພໍແລ້ວ". ແຕ່ໃນຄວາມເປັນຈິງ, ການວາງ Tenant ID ໄວ້ເປັນ Namespace ຊັ້ນສູງສຸດຢູ່ຕຳແໜ່ງທຳອິດສະເໝີ ຈະຊ່ວຍເພີ່ມທັງຄວາມໝັ້ນຄົງໃນການແຍກຂໍ້ມູນ ແລະ ປະສິດທິພາບຂອງ Cache ໃຫ້ສູງຂຶ້ນ.

ເປັນຫຍັງຕ້ອງວາງໄວ້ຕຳແໜ່ງທຳອິດ? ເນື່ອງຈາກ Prompt Cache ຂອງ LLM Provider ຈະຕັດສິນການ Hit ໂດຍອີງໃສ່ການຈັບຄູ່ຈາກຕຳແໜ່ງທຳອິດຂອງຂໍ້ຄວາມ Prompt (Prefix Match), ດັ່ງນັ້ນໂຄງສ້າງຂອງ Cache Key ຈຶ່ງຈຳເປັນຕ້ອງສອດຄ່ອງກັບລຳດັບຂອງ Prompt. ໂດຍປະຕິບັດຕາມຫຼັກການນີ້, ໂຄງສ້າງ Key ທີ່ແນະນຳມີດັ່ງນີ້:

ສຳລັບ tenant_id ຢູ່ຕຳແໜ່ງທຳອິດ ໃຫ້ໃຊ້ UUID ຫຼື ຄ່າອື່ນໆທີ່ສາມາດລະບຸຕົວຕົນຂອງ Tenant ໄດ້ຢ່າງຊັດເຈນ. ການໃຊ້ຈຸດນີ້ເປັນຈຸດເລີ່ມຕົ້ນ ຈະຊ່ວຍລຶບລ້າງໂອກາດທີ່ Cache ຂອງ Tenant ທີ່ແຕກຕ່າງກັນຈະປົນກັນໄດ້ຕັ້ງແຕ່ຕົ້ນ. ສ່ວນ model_id ທີ່ຕາມມາແມ່ນເພື່ອປ້ອງກັນການທັບຊ້ອນກັນໃນກໍລະນີທີ່ Tenant ດຽວກັນໃຊ້ຫຼາຍ Model, prompt_version ແມ່ນເພື່ອຍົກເລີກການໃຊ້ງານ Cache ເກົ່າໂດຍອັດຕະໂນມັດເມື່ອມີການປ່ຽນແປງ System Prompt, ແລະ context_hash ແມ່ນຄ່າທີ່ຜ່ານການ Hash ດ້ວຍ SHA-256 ຫຼື ວິທີອື່ນໆ ສຳລັບ Context ສະເພາະຂອງຜູ້ໃຊ້.

ທັງນີ້, ສຳລັບ Tenant ID ນັ້ນ ສາມາດນຳໃຊ້ Identifier ທີ່ຈັດການໂດຍຝັ່ງ Application ມາໃຊ້ໄດ້ໂດຍກົງ, ແຕ່ການໃຊ້ Internal UUID ທີ່ບໍ່ເປີດເຜີຍອອກສູ່ພາຍນອກ ຈະຊ່ວຍຫຼຸດຜ່ອນຄວາມສ່ຽງດ້ານຄວາມປອດໄພໄດ້.

ໂຄງສ້າງການແຍກ Prompt ອອກເປັນ "Shared Prefix" ແລະ "Tenant-specific Suffix" ແມ່ນຮູບແບບພື້ນຖານເພື່ອເພີ່ມປະສິດທິພາບຂອງ Cache ໃຫ້ສູງສຸດໃນສະພາບແວດລ້ອມ Multi-tenant.

ໂຄງສ້າງພື້ນຖານຂອງການແຍກສ່ວນ

ປະກອບ Prompt ທັງໝົດອອກເປັນ 3 ຊັ້ນ ດັ່ງນີ້:

• ຊັ້ນ Shared Prefix: System Prompt ທີ່ໃຊ້ຮ່ວມກັນໃນທຸກ Tenant (ຄຳອະທິບາຍຜະລິດຕະພັນ, ນະໂຍບາຍຄວາມປອດໄພ, ຄຳສັ່ງຮູບແບບການສະແດງຜົນ ແລະ ອື່ນໆ)
• ຊັ້ນ Tenant-specific: ການຕັ້ງຄ່າສະເພາະຂອງແຕ່ລະ Tenant (ຊື່ບໍລິສັດ, ປະເພດທຸລະກິດ, ກົດລະບຽບທີ່ກຳນົດເອງ ແລະ ອື່ນໆ)
• ຊັ້ນ User Request: ຂໍ້ມູນນຳເຂົ້າຂອງຜູ້ໃຊ້ໃນແຕ່ລະ Request

ເປົ້າໝາຍຂອງ Cache ແມ່ນ "ຊັ້ນ Shared Prefix" ເປັນຫຼັກ. ເນື່ອງຈາກສ່ວນນີ້ເປັນສ່ວນທີ່ໃຊ້ຮ່ວມກັນໃນທຸກ Request, ອັດຕາການ Cache Hit ຈຶ່ງສູງທີ່ສຸດ.

ການອອກແບບທີ່ແຕກຕ່າງກັນຕາມເງື່ອນໄຂ

ໃນກໍລະນີທີ່ System Prompt ມີສ່ວນທີ່ຄ້າຍຄືກັນຫຼາຍລະຫວ່າງ Tenant, ການກຳນົດໃຫ້ Shared Prefix ມີຄວາມຍາວຫຼາຍຂຶ້ນຈະຊ່ວຍເພີ່ມປະສິດທິພາບຂອງ Cache ໄດ້. ແຕ່ຖ້ານະໂຍບາຍ ຫຼື ການຕັ້ງຄ່າພາສາຂອງແຕ່ລະ Tenant ມີຄວາມແຕກຕ່າງກັນຫຼາຍ, ການອອກແບບໂດຍວາງຊັ້ນ Tenant-specific ໄວ້ທາງໜ້າເພື່ອແຍກ Cache ຕາມແຕ່ລະ Tenant ຈະມີຄວາມເໝາະສົມກວ່າ.

ຕົວຢ່າງການນຳໄປໃຊ້ (ແນວຄວາມຄິດ)

[Shared Prefix: 2,000 Tokens]
ເຈົ້າເປັນ AI Assistant ຂອງແພລັດຟອມ SaaS.
ຜົນລວມແມ່ນພາສາຍີ່ປຸ່ນ.
---

"ຄວນຕັ້ງຄ່າ TTL ຂອງ Cache ໄວ້ເທົ່າໃດດີ?" —— ນີ້ຄືຄຳຖາມທຳອິດທີ່ມັກຈະສັບສົນໃນໜ້າວຽກການປະຕິບັດຕົວຈິງ.

ການຕັ້ງຄ່າ TTL ແມ່ນຖືກກຳນົດໂດຍ ການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງປະສິດທິພາບການຫຼຸດຕົ້ນທຶນ ແລະ ຄວາມສົດໃໝ່ຂອງຂໍ້ມູນ. ເມື່ອພິຈາລະນາຕາມ ມາດຕະຖານ ຫຼື Specification ຂອງຜູ້ໃຫ້ບໍລິການຫຼັກໆ, ສາມາດສະຫຼຸບໄດ້ດັ່ງນີ້:

TTL ເລີ່ມຕົ້ນຂອງຜູ້ໃຫ້ບໍລິການຫຼັກ

• Anthropic (Claude): ເລີ່ມຕົ້ນ 5 ນາທີ, ເລືອກໄດ້ສູງສຸດ 1 ຊົ່ວໂມງ (ມີຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມ)
• AWS Bedrock (Claude Sonnet): ເລີ່ມຕົ້ນ 5 ນາທີ
• AWS Bedrock (Claude Opus): ສາມາດເລືອກໄດ້ລະຫວ່າງ 5 ນາທີ ຫຼື 1 ຊົ່ວໂມງ
• OpenAI: ໝົດອາຍຸພາຍໃນ 5-10 ນາທີເມື່ອບໍ່ມີການເຄື່ອນໄຫວ, ສູງສຸດ 1 ຊົ່ວໂມງ (Extended ສູງສຸດ 24 ຊົ່ວໂມງ)

ແກນການຕັດສິນໃຈໃນການເລືອກ TTL

ການກຳນົດ TTL ທີ່ໃຊ້ໄດ້ຈິງຄວນອີງໃສ່ 2 ແກນຫຼັກ ຄື "ຄວາມຖີ່ໃນການອັບເດດ System Prompt" ແລະ "ຄວາມໜາແໜ້ນຂອງການຮ້ອງຂໍ (Request density)".

• ກໍລະນີທີ່ຄວາມຖີ່ໃນການອັບເດດຕ່ຳ ແລະ ມີຊ່ວງເວລາທີ່ການຮ້ອງຂໍເຂົ້າມາຢ່າງໜາແໜ້ນ: ຄວນໃຊ້ TTL 1 ຊົ່ວໂມງ ເພື່ອໃຫ້ງ່າຍຕໍ່ການຄືນທຶນຄ່າຂຽນ Cache
• ກໍລະນີທີ່ System Prompt ມີການປ່ຽນແປງເລື້ອຍໆໃນແຕ່ລະ Tenant: ຄວນໃຊ້ TTL 5 ນາທີ ເພື່ອຮັກສາຄວາມສົດໃໝ່ຂອງຂໍ້ມູນ ພ້ອມທັງຫວັງຜົນໃນການຫຼຸດຕົ້ນທຶນໃນຊ່ວງທີ່ມີການຮ້ອງຂໍເຂົ້າມາຢ່າງກະທັນຫັນ (Burst)

ໃນໂຄງສ້າງລາຄາຂອງ Anthropic, ຄ່າໃຊ້ຈ່າຍໃນການຂຽນ Cache 1 ຊົ່ວໂມງ ແມ່ນເທົ່າກັບ 2 ເທົ່າຂອງລາຄາ Input ພື້ນຖານ ແລະ ຄ່າອ່ານແມ່ນ 0.1 ເທົ່າ. ການຈະຄືນທຶນຄ່າຂຽນ 1 ຄັ້ງນັ້ນ ຈຳເປັນຕ້ອງມີການ Hit Cache ອັນດຽວກັນໃຫ້ໄດ້ຫຼາຍຄັ້ງພາຍໃນໄລຍະເວລາ TTL.

ສະຫຼຸບ: ເມື່ອແນວທາງການອອກແບບມີຄວາມຊັດເຈນແລ້ວ, ໃຫ້ດຳເນີນການຈັດຕັ້ງປະຕິບັດຕາມ 3 ຂັ້ນຕອນ ຄື: ການສ້າງ Template, ການສ້າງ Cache layer ແລະ ການວັດແທກຜົນ.

ເລີ່ມຕົ້ນຈາກການສ້າງ Template ຂອງ System prompt, ຈາກນັ້ນນຳ Cache layer ມາໃຊ້ ແລະ ດຳເນີນການວັດແທກອັດຕາ Hit rate ຕາມລຳດັບ. ລາຍລະອຽດຂອງແຕ່ລະຂັ້ນຕອນຈະຖືກອະທິບາຍໃນຫົວຂໍ້ H3 ຕໍ່ໄປນີ້.

ໃນຕອນທຳອິດ ເຮົາມັກຈະຄິດວ່າ "ການກະກຽມລະບົບ Prompt ທີ່ແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງໃຫ້ແຕ່ລະ Tenant ແມ່ນວິທີທີ່ດີ", ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ໂຄງສ້າງ Template ທີ່ແຍກສ່ວນທີ່ຄືກັນ ແລະ ສ່ວນທີ່ແຕກຕ່າງອອກຈາກກັນຢ່າງຊັດເຈນນັ້ນ ມີປະສິດທິຜົນຫຼາຍກວ່າທັງໃນດ້ານອັດຕາການ Cache Hit ແລະ ການຮັກສາລະບົບ (Maintainability).

ຫຼັກການພື້ນຖານຂອງການເຮັດ Template ຄືການແບ່ງ Prompt ອອກເປັນ 2 ຊັ້ນ ຄື "ຊັ້ນ Prefix ທີ່ໃຊ້ຮ່ວມກັນ" ແລະ "ຊັ້ນສະເພາະຂອງ Tenant".

ຊັ້ນ Prefix ທີ່ໃຊ້ຮ່ວມກັນ (ເປົ້າໝາຍໃນການ Cache)

• ກົດລະບຽບທີ່ບໍ່ປ່ຽນແປງ ເຊັ່ນ: ການກຳນົດບົດບາດຂອງ AI, ຄຳສັ່ງກ່ຽວກັບຮູບແບບຜົນລວມ, ແລະ ຂໍ້ຫ້າມຕ່າງໆ
• ຕັກກະທາງທຸລະກິດ ແລະ ແນວທາງປະຕິບັດທີ່ໃຊ້ຮ່ວມກັນໃນທຸກ Tenant
• ໃນກໍລະນີຂອງ OpenAI ຕ້ອງໃຊ້ຢ່າງໜ້ອຍ 1,024 Token ຂຶ້ນໄປ ແລະ ໃນກໍລະນີຂອງ Anthropic (Claude) ກໍເຊັ່ນດຽວກັນ ດັ່ງນັ້ນຈຶ່ງຄວນອອກແບບສ່ວນທີ່ໃຊ້ຮ່ວມກັນໃຫ້ມີຂະໜາດເກີນກວ່າເກນນີ້

ຊັ້ນສະເພາະຂອງ Tenant (ບໍ່ແມ່ນເປົ້າໝາຍໃນການ Cache)

• ພາຣາມິເຕີແບບເຄື່ອນໄຫວ (Dynamic parameters) ເຊັ່ນ: ຊື່ Tenant, ແຜນສັນຍາ, ແລະ Flag ຂອງຟັງຊັນທີ່ເປີດໃຊ້ງານ
• ການກຳນົດໂທນສຽງ ຫຼື ແນວທາງດ້ານແບຣນສະເພາະຂອງ Tenant ນັ້ນໆ

ໃນການນຳໄປໃຊ້ງານຈິງ ວິທີການທົ່ວໄປຄືການນຳໃຊ້ Template Engine ເຊັ່ນ Jinja2 ແລະ ຈັດການ Prefix ທີ່ໃຊ້ຮ່ວມກັນເປັນສະຕຣິງແບບຄົງທີ່ (Static string). ສ່ວນພາຣາມິເຕີສະເພາະຂອງ Tenant ຈະຖືກວາງໄວ້ທາງຫຼັງໂດຍໃຊ້ Placeholder ເຊັ່ນ {{ tenant_name }} ແລະ ອອກແບບໃຫ້ໄບຕ໌ (Byte) ຂອງສ່ວນ Prefix ບໍ່ມີການປ່ຽນແປງຫຼັງຈາກການ Rendering.

ຂໍ້ຄວນລະວັງຄື ຖ້າມີການປົນເປື້ອນຂອງການຂຶ້ນແຖວໃໝ່ ຫຼື ຊ່ອງຫວ່າງຢູ່ທ້າຍຂອງ Prefix ທີ່ໃຊ້ຮ່ວມກັນ ອາດຈະເຮັດໃຫ້ທາງ Provider ຕັດສິນວ່າ Cache Key ນັ້ນເປັນຄົນລະອັນກັນໄດ້.

ພຽງແຕ່ສົ່ງ System Prompt ທີ່ເປັນ Template ໄປໃຫ້ API ໂດຍກົງນັ້ນ ຈະບໍ່ສາມາດໄດ້ຮັບຜົນປະໂຫຍດຈາກການ Cache ຢ່າງໝັ້ນຄົງ. ການສ້າງ Cache layer ແຍກຕ່າງຫາກ ແລະ ບໍລິຫານຈັດການແບບລວມສູນດ້ວຍ "Prompt Hash" ແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້ສຳລັບການດຳເນີນງານທີ່ໝັ້ນຄົງໃນສະພາບແວດລ້ອມ Multi-tenant.

ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ພື້ນຖານຂອງ Cache layer

ໂຄງສ້າງທີ່ນິຍົມໃຊ້ກັນທົ່ວໄປຄືການວາງ Cache proxy ບາງໆໄວ້ລະຫວ່າງ Application layer ແລະ LLM API. ຂະບວນການ ຫຼື Pipeline ການເຮັດວຽກມີດັ່ງນີ້:

1. ນຳ Tenant ID ແລະ ເລກເວີຊັນຂອງ System Prompt ມາລວມກັນ, ຈາກນັ້ນສ້າງຄ່າ Hash ດ້ວຍ SHA-256 ຫຼື ອື່ນໆ.
2. ລົງທະບຽນ Cache entry ໄວ້ໃນ In-memory store ເຊັ່ນ Redis ໂດຍໃຊ້ຄ່າ Hash ເປັນ Key.
3. ໃນກໍລະນີທີ່ມີ Request ທີ່ມີ Hash ດຽວກັນເຂົ້າມາ ຈະສົ່ງຂໍ້ມູນຄືນຈາກ Cache ແລະ ຂ້າມການຮຽກໃຊ້ LLM API ໄປ.

ຫຼັກການຕັດສິນໃຈໃນການຈັດການ Prompt Hash

ສຳລັບ Tenant ທີ່ມີປະລິມານ Request ຫຼາຍ, ການຈັດການ Hash ໄວ້ໃນ In-memory (Redis) ເພື່ອຫຼຸດ Latency ໃຫ້ເຫຼືອໜ້ອຍທີ່ສຸດແມ່ນເໝາະສົມ, ສ່ວນ Tenant ທີ່ມີຄວາມຖີ່ຂອງ Request ຕ່ຳ, ການອອກແບບໂດຍເນັ້ນຄ່າໃຊ້ຈ່າຍເປັນຫຼັກດ້ວຍການເກັບ Hash ໄວ້ໃນຖານຂໍ້ມູນແບບຖາວອນຈະເໝາະສົມກວ່າ.

ການຮ່ວມມືກັບຝ່າຍ LLM Provider

ເນື່ອງຈາກຄ່າໃຊ້ຈ່າຍໃນການອ່ານ Cache ຂອງ Anthropic ແມ່ນ 0.1 ເທົ່າຂອງລາຄາ Input ພື້ນຖານ, ຖ້າ Hash ກົງກັນ ແລະ Cache ຂອງຝ່າຍ Provider ເຮັດວຽກ (Hit) ກໍຈະໄດ້ຮັບການຫຼຸດຕົ້ນທຶນສອງຕໍ່. ຄ່າໃຊ້ຈ່າຍໃນການຂຽນ Cache ແມ່ນ 1. (ສຳລັບ TTL 5 ນາທີ).

ສະຖານະການທີ່ວ່າ "ໄດ້ນຳໃຊ້ Cache ເຂົ້າໄປແລ້ວ ແຕ່ບໍ່ສາມາດຢືນຢັນໄດ້ວ່າເກີດການ Hit ຕົວຈິງຫຼືບໍ່" ເປັນສິ່ງທີ່ມັກເກີດຂຶ້ນຢູ່ໜ້າງານ. ເນື່ອງຈາກຫາກບໍ່ມີການວັດແທກ ກໍຈະບໍ່ເຫັນຊ່ອງວ່າງໃນການປັບໃຫ້ເໝາະສົມ (Optimization), ດັ່ງນັ້ນການຕັ້ງຄ່າ AI Observability ຈຶ່ງມີຄວາມສຳຄັນທີ່ຕ້ອງດຳເນີນການໄປພ້ອມກັບການ Implement.

ຈຸດເລີ່ມຕົ້ນຂອງການວັດແທກແມ່ນຟິວ (field) usage.prompt_tokens_details.cached_tokens ຂອງ API Response. ໃຫ້ດຶງຂໍ້ມູນຈຳນວນ Cache Hit ຈາກຟິວນີ້ ແລະບັນທຶກຕົວຊີ້ວັດຕໍ່ໄປນີ້ຢ່າງຕໍ່ເນື່ອງ:

• ອັດຕາການ Cache Hit: ຄຳນວນຈາກ cached_tokens ÷ total_prompt_tokens
• ອັດຕາການ Hit ແຍກຕາມ Tenant: ລວມຍອດແຍກຕາມ Tenant ID ເພື່ອລະບຸ Tenant ທີ່ມີອັດຕາການ Hit ຕ່ຳ
• ຈຳນວນຄັ້ງທີ່ TTL ໝົດອາຍຸ: ບັນທຶກຄວາມແຕກຕ່າງຂອງເວລາລະຫວ່າງການຂຽນ Cache ແລະການ Hit ເພື່ອໃຊ້ເປັນຂໍ້ມູນໃນການຕັດສິນໃຈວ່າ TTL 5 ນາທີ ຫຼື 1 ຊົ່ວໂມງ ແບບໃດຈຶ່ງເໝາະສົມກວ່າ

ເມຕຣິກເຫຼົ່ານີ້ເປັນວິທີການທົ່ວໄປໃນການສົ່ງຂໍ້ມູນໄປຍັງແພລດຟອມ Observability ເຊັ່ນ Datadog ຫຼື Grafana ເພື່ອສະແດງຜົນໃນ Dashboard. ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນ ວິທີການວັດແທກຜົນຫຼັງຈາກນຳໃຊ້ AI Agent｜ຈາກການອອກແບບ KPI ຈົນເຖິງການປັບປຸງຢ່າງຕໍ່ເນື່ອງ, ການກຳນົດ KPI ໄວ້ລ່ວງໜ້າຈະຊ່ວຍໃຫ້ການໝູນວຽນວົງຈອນການປັບປຸງເຮັດໄດ້ງ່າຍຂຶ້ນ.

ການຕັ້ງຄ່າ Alert ກໍເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້. ຕົວຢ່າງຂອງຄ່າ Threshold ທີ່ແນະນຳມີດັ່ງນີ້:

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

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

ເມື່ອລວມເອົາ Privacy by Isolation ເຂົ້າໃນການອອກແບບ Cache, ຈຸດເລີ່ມຕົ້ນແມ່ນການກຳນົດໃຫ້ຊັດເຈນກ່ອນວ່າ "ຈະແຍກສ່ວນໃດ".

ໂດຍສະເພາະ, ໃຫ້ອອກແບບການແຍກສ່ວນອອກເປັນ 3 ຊັ້ນ ດັ່ງນີ້:

• ຊັ້ນ Cache Storage: ຕ້ອງກຳນົດ Tenant ID ເປັນ Namespace ຂອງ Cache Key ສະເໝີ ເພື່ອໃຫ້ໂຄງສ້າງຂອງ Key ໃນ Redis ຫຼື Memcached ບໍ່ເກີດການຊ້ຳຊ້ອນກັບ Tenant ອື່ນ.
• ຊັ້ນໂຄງສ້າງ Prompt: ແຍກການຈັດການລະຫວ່າງ System Prompt ທີ່ໃຊ້ຮ່ວມກັນທຸກ Tenant (Shared Prefix) ແລະ Context ສະເພາະຂອງແຕ່ລະ Tenant (Suffix) ອອກຈາກກັນທາງກາຍະພາບ.
• ຊັ້ນການຮຽກໃຊ້ API: ກ່ອນຈະຕັດສິນວ່າ Cache Hit ຫຼືບໍ່, ຕ້ອງກວດສອບໃຫ້ແນ່ໃຈວ່າ Tenant ID ຂອງຜູ້ຮ້ອງຂໍ ແລະ Namespace ຂອງ Cache Key ທີ່ພະຍາຍາມດຶງຂໍ້ມູນນັ້ນກົງກັນ.

ແນວທາງການປະຕິບັດຈະປ່ຽນແປງໄປຕາມຮູບແບບການແຍກ Tenant. ໃນກໍລະນີແບບ Silo (ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ແຍກຕ່າງຫາກສຳລັບແຕ່ລະ Tenant), ການຈັດການຈະງ່າຍຂຶ້ນເພາະສາມາດແຍກ Cache Storage ອອກຈາກກັນໄດ້ເລີຍ. ແຕ່ໃນກໍລະນີແບບ Pool (ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຮ່ວມກັນ), ການຈັດການ Namespace ຂອງ Key ໃນຊັ້ນ Application ແລະ ການກວດສອບຄວາມເປັນເຈົ້າຂອງກ່ອນດຶງຂໍ້ມູນແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ນອກຈາກນີ້, ຍັງຕ້ອງລະມັດລະວັງກ່ຽວກັບເນື້ອຫາທີ່ຈະຂຽນລົງໃນ Cache. ຫຼັກການແມ່ນໃຫ້ຫຼີກລ່ຽງການນຳເອົາຂໍ້ມູນສ່ວນຕົວ ຫຼື ຂໍ້ມູນລັບສະເພາະຂອງ Tenant ໄປໃສ່ໃນ Prompt ທີ່ເປັນເປົ້າໝາຍຂອງ Cache, ແລະ ຄວນຈຳກັດໃຫ້ Cache ເກັບສະເພາະ Context ທີ່ເປັນແບບ Static ຫຼື Semi-static ເທົ່ານັ້ນ ເຊັ່ນ: "ການຕັ້ງຄ່າ Tenant, ການກຳນົດ Role, ແລະ ຄວາມຮູ້ທົ່ວໄປ".

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

ການເກີດ Cache key ຕຳກັນ ແລະ ຄວາມຄາດເຄື່ອນຂອງເວລາໃນການຍົກເລີກ Cache (Cache invalidation) ແມ່ນບັນຫາທີ່ມັກເກີດຂຶ້ນໂດຍສະເພາະໃນສະພາບແວດລ້ອມແບບ Multi-tenant. ຕໍ່ໄປນີ້ແມ່ນການສະຫຼຸບສາເຫດ ແລະ ວິທີການຫຼີກລ່ຽງບັນຫາດັ່ງກ່າວ.

ການເກີດ Cache Key ຕຳກັນ ກໍປຽບເໝືອນການທີ່ຈົດໝາຍຂອງຜູ້ຢູ່ອາໄສທີ່ແຕກຕ່າງກັນຖືກສົ່ງໄປຍັງຕູ້ໄປສະນີດຽວກັນ. ຖ້າ System Prompt ຂອງ Tenant A ຖືກສົ່ງກັບໄປຍັງຄຳຮ້ອງຂໍຂອງ Tenant B, ມັນຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ການຮົ່ວໄຫຼຂອງຂໍ້ມູນລັບໂດຍກົງ.

ສາເຫດທົ່ວໄປທີ່ເຮັດໃຫ້ເກີດບັນຫານີ້ແມ່ນການອອກແບບ Cache Key ທີ່ບໍ່ພຽງພໍ. ຕົວຢ່າງເຊັ່ນ: ໃນກໍລະນີທີ່ໃຊ້ພຽງແຕ່ເນື້ອໃນຂອງ Prompt ມາເຮັດ Hash ເພື່ອເປັນ Key, ຖ້າ Tenant ທີ່ແຕກຕ່າງກັນບັງເອີນໃຊ້ຂໍ້ຄວາມ System Prompt ດຽວກັນ, Key ທີ່ສ້າງຂຶ້ນກໍຈະຄືກັນ. ຜົນກໍຄື Context ຂອງ Tenant ທີ່ຂຽນ Cache ລົງໄປກ່ອນ ອາດຈະຖືກສົ່ງກັບໄປໃຫ້ Tenant ອື່ນ.

ຮູບແບບການຕຳກັນມີຢູ່ 3 ຢ່າງໃຫຍ່ໆ: ຢ່າງທຳອິດແມ່ນກໍລະນີທີ່ໃຊ້ພຽງແຕ່ເນື້ອໃນຂອງ Prompt ມາເຮັດ Key, ເນື່ອງຈາກບໍ່ໄດ້ລວມ Tenant ID ເຂົ້າໄປໃນ Key ຈຶ່ງເຮັດໃຫ້ເກີດການຕຳກັນໃນຂໍ້ຄວາມດຽວກັນ. ສິ່ງນີ້ສາມາດປ້ອງກັນໄດ້ໂດຍການເຮັດໃຫ້ Key ເປັນຮູບແບບ {tenant_id}:{prompt_hash}. ຢ່າງທີສອງແມ່ນກໍລະນີທີ່ມີການໃຊ້ Cache Namespace ສ່ວນກາງຮ່ວມກັນລະຫວ່າງ Tenant. ໃນກໍລະນີທີ່ໃຊ້ Redis ຫຼື ສິ່ງທີ່ຄ້າຍຄືກັນ, ຖ້າບໍ່ໄດ້ແຍກ Cache Store ອອກຈາກກັນ ກໍຈະເກີດການປົນເປື້ອນໃນລະດັບ Namespace, ດັ່ງນັ້ນຈຶ່ງຈຳເປັນຕ້ອງແຍກ Key Prefix ຫຼື ເລກ DB ຂອງແຕ່ລະ Tenant. ຢ່າງທີສາມແມ່ນກໍລະນີທີ່ມີການຄຳນວນ Hash ກ່ອນການຂະຫຍາຍ Template Variable, ຖ້າໃຊ້ Template ສ່ວນກາງມາເປັນ Key ໂດຍກົງ, ເຖິງແມ່ນວ່າເນື້ອໃນຫຼັງຈາກຂະຫຍາຍແລ້ວຈະແຕກຕ່າງກັນ ແຕ່ກໍຈະຖືກສ້າງເປັນ Key ດຽວກັນ. ກະລຸນາຄຳນວນ Hash ຈາກຂໍ້ຄວາມ Prompt ຫຼັງຈາກຂະຫຍາຍຕົວປ່ຽນແລ້ວເທົ່ານັ້ນ.

ການຍົກເລີກ Cache ມັກຈະຖືກຄິດວ່າ "ຖ້າມີການອັບເດດ ກໍພຽງແຕ່ລຶບຖິ້ມ (Purge) ທັນທີກໍພໍ" ແຕ່ຖ້າກຳນົດເວລາໃນການຍົກເລີກຜິດພາດ ກໍງ່າຍທີ່ຈະເກີດຜົນກະທົບທາງລົບ ເຊັ່ນ: ຕົ້ນທຶນໃນການຂຽນຂໍ້ມູນໃໝ່ເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ.

ໃນໂຄງສ້າງລາຄາຂອງ Anthropic, ການຂຽນ Cache 5 ນາທີຈະມີລາຄາ 1.25 ເທົ່າຂອງລາຄາ Input ພື້ນຖານ ແລະ Cache 1 ຊົ່ວໂມງຈະມີລາຄາ 2 ເທົ່າ. ຖ້າ Prompt ມີການປ່ຽນແປງເລື້ອຍໆ Cache ຈະຖືກສ້າງໃໝ່ ແລະ ຈະເກີດວົງຈອນທີ່ TTL ໝົດອາຍຸກ່ອນທີ່ຈະໄດ້ຮັບຜົນປະໂຫຍດຈາກການອ່ານ (0.1 ເທົ່າ). ສຳລັບຜູ້ໃຫ້ບໍລິການທີ່ມີຄ່າ Default TTL ຢູ່ທີ່ 5 ນາທີ ຖ້າບໍ່ມີການຮ້ອງຂໍຈາກ Tenant ດຽວກັນເຂົ້າມາພາຍໃນ 5 ນາທີ ອັດຕາການ Cache Hit ກໍຈະເກືອບເປັນສູນ. ຍິ່ງໄປກວ່ານັ້ນ, ທຸກຄັ້ງທີ່ມີການປ່ຽນແປງການຕັ້ງຄ່າໃນໜ້າຈໍຈັດການ ຖ້າຫາກຍົກເລີກ Cache ຂອງທຸກ Tenant ພ້ອມກັນ ອັດຕາການ Hit ຈະຫຼຸດລົງຢ່າງກະທັນຫັນໃນໄລຍະສັ້ນ ແລະ ເຮັດໃຫ້ຕົ້ນທຶນພຸ່ງສູງຂຶ້ນ.

ວິທີແກ້ໄຂບັນຫານີ້ໃນທາງປະຕິບັດຄື ການຍົກເລີກແບບຊັກຊ້າ (Lazy Invalidation). ໂດຍການເຮັດ Version Control ໃຫ້ກັບການປ່ຽນແປງ Prompt ແລະ ບໍ່ລຶບຖິ້ມ (Purge) ທັນທີ ແຕ່ປ່ຽນໄປໃຊ້ Version ໃໝ່ໃນການຮ້ອງຂໍຄັ້ງຕໍ່ໄປ ເຊິ່ງວິທີນີ້ຈະຊ່ວຍຢັບຢັ້ງການເພີ່ມຂຶ້ນຂອງຕົ້ນທຶນການຂຽນຂໍ້ມູນທີ່ເກີດຂຶ້ນຢ່າງຕໍ່ເນື່ອງໄດ້.

Q1. Prompt Caching ສາມາດໃຊ້ໄດ້ກັບທຸກ LLM provider ບໍ?

ຜູ້ໃຫ້ບໍລິການຫຼັກໆໄດ້ມີການຮອງຮັບແລ້ວ ແຕ່ເງື່ອນໄຂຈະແຕກຕ່າງກັນໄປຕາມຮຸ່ນຂອງ Model ແລະ ແຜນສັນຍາ. OpenAI ຕ້ອງການ 1,024 token ຂຶ້ນໄປເພື່ອເປີດໃຊ້ງານ Cache ແລະ in-memory cache ຈະໝົດອາຍຸພາຍໃນ 5-10 ນາທີ. Anthropic (Claude) ມີຄ່າ Default TTL ຢູ່ທີ່ 5 ນາທີ ແລະ ສາມາດເລືອກທາງເລືອກ 1 ຊົ່ວໂມງໄດ້. ສ່ວນ AWS Bedrock, Claude Opus 4.5 ຕ້ອງການຂັ້ນຕໍ່າ 4,096 token ເຊິ່ງເກນເຫຼົ່ານີ້ຈະແຕກຕ່າງກັນໄປໃນແຕ່ລະ Model. ແນະນຳໃຫ້ກວດສອບ Model ທີ່ຮອງຮັບ ແລະ ຂໍ້ກຳນົດຈຳນວນ token ຂັ້ນຕໍ່າໃນເອກະສານທາງການຂອງຜູ້ໃຫ້ບໍລິການແຕ່ລະແຫ່ງກ່ອນການນຳໃຊ້.

Q2. ການໃຊ້ Cache ໃນສະພາບແວດລ້ອມ Multi-tenant ມີຄວາມສ່ຽງທີ່ຂໍ້ມູນຈະປົນກັນລະຫວ່າງ Tenant ບໍ?

ຫາກອອກແບບ Cache key ຜິດພາດ ອາດມີຄວາມສ່ຽງທີ່ Context ຂອງ Tenant ທີ່ແຕກຕ່າງກັນຈະໄປຜູກມັດກັບ Cache entry ດຽວກັນ. ວິທີປ້ອງກັນທີ່ມີປະສິດທິພາບຄື ການໃສ່ Tenant ID ລົງໃນ Cache key ສະເໝີ ແລະ ອອກແບບໃຫ້ System prompt ສະເພາະຂອງ Tenant ແຍກອອກຈາກ Shared prefix ຢ່າງຊັດເຈນ. ການນຳໃຊ້ແນວຄິດ Privacy-by-isolation ແລະ ການອອກແບບບໍ່ໃຫ້ເກີດການອ້າງອີງ Cache ຂ້າມ Tenant ທາງໂຄງສ້າງແມ່ນສິ່ງສຳຄັນ. ນອກຈາກການວັດແທກອັດຕາ Cache hit ແລ້ວ ຍັງແນະນຳໃຫ້ກວດສອບ Audit log ຂອງຂອບເຂດ Tenant ຢ່າງສະໝໍ່າສະເໝີ.

Q3. ຄວນຕັ້ງຄ່າ TTL ຂອງ Cache ແນວໃດເພື່ອໃຫ້ມີຄວາມຄຸ້ມຄ່າດ້ານຕົ້ນທຶນ?

ຄ່າທີ່ເໝາະສົມທີ່ສຸດຂອງ TTL ຈະປ່ຽນແປງໄປຕາມຄວາມຖີ່ຂອງການ Request ແລະ ຄວາມຖີ່ໃນການອັບເດດ System prompt. ໃນໂຄງສ້າງລາຄາຂອງ Anthropic, ຕົ້ນທຶນການຂຽນ Cache ຈະຢູ່ທີ່ 1.25 ເທົ່າ (TTL 5 ນາທີ) ຫຼື 2 ເທົ່າ (TTL 1 ຊົ່ວໂມງ) ຂອງລາຄາ Input ພື້ນຖານ ແຕ່ຕົ້ນທຶນການອ່ານ Cache ຈະຫຼຸດລົງເຫຼືອພຽງ 0.1 ເທົ່າ. ສຳລັບ Tenant ທີ່ມີການ Request ເຂົ້າມາເລື້ອຍໆ TTL 1 ຊົ່ວໂມງຈະໄດ້ປຽບກວ່າ, ສ່ວນ Tenant ທີ່ມີຄວາມຖີ່ຕໍ່າ TTL 5 ນາທີມັກຈະເໝາະສົມກວ່າໃນດ້ານຕົ້ນທຶນ. ການເລືອກ TTL ໂດຍອີງໃສ່ຄ່າການວັດແທກອັດຕາ Cache hit ຕົວຈິງຈະໃຫ້ຜົນດີ.

Q4. ຫາກມີ Tenant ທີ່ອັບເດດ System prompt ຢູ່ເລື້ອຍໆ ຄວນຈັດການກັບ Cache ແນວໃດ?

ເມື່ອ System prompt ຖືກປ່ຽນແປງ ຈຳເປັນຕ້ອງຍົກເລີກ Cache entry ທີ່ກ່ຽວຂ້ອງ. ການອອກແບບໂດຍນຳຄ່າ Hash ຂອງ Prompt ມາລວມເປັນສ່ວນໜຶ່ງຂອງ Cache key ຈະຊ່ວຍໃຫ້ລະບົບສ້າງ Cache entry ໃໝ່ໂດຍອັດຕະໂນມັດເມື່ອມີການປ່ຽນແປງ Prompt ແລະ ປ້ອງກັນການອ້າງອີງໄປຍັງ Entry ເກົ່າ. Tenant ທີ່ມີຄວາມຖີ່ໃນການອັບເດດສູງມັກຈະມີອັດຕາ Cache hit ຫຼຸດລົງ, ສະນັ້ນແນະນຳໃຫ້ຕິດຕາມອັດຕາ Hit ຂອງແຕ່ລະ Tenant ຜ່ານ Dashboard ຂອງ AI Observability ແລະ ປັບການຕັ້ງຄ່າ TTL ຫຼື ກົນລະຍຸດ Cache ແຍກຕ່າງຫາກ.

Q5. ຈະປະເມີນຜົນກະທົບຂອງ Prompt Caching ຢ່າງເປັນຮູບປະທຳໄດ້ແນວໃດ?

ໃນກໍລະນີຂອງ OpenAI, ທ່ານສາມາດກວດສອບຈຳນວນ Token ທີ່ Cache hit ໄດ້ຈາກ Field usage.prompt_tokens_details.cached_tokens ໃນ API response. ການເກັບຂໍ້ມູນນີ້ໄວ້ຈະຊ່ວຍໃຫ້ຄິດໄລ່ອັດຕາ Cache hit ແລະ ຈຳນວນ Token ທີ່ຫຼຸດລົງຂອງແຕ່ລະ Tenant ໄດ້. ສຳລັບດັດຊະນີການປະເມີນຜົນ ການນຳໃຊ້ "ອັດຕາ Cache hit", "ຈຳນວນ Token ທີ່ຫຼຸດລົງ" ແລະ "ລະດັບການປັບປຸງ Latency" ມາລວມກັນຖືວ່າເປັນວິທີທີ່ນຳໄປປະຕິບັດໄດ້ຈິງ. ທ່ານສາມາດອ້າງອີງ ວິທີການວັດແທກຜົນຫຼັງຈາກນຳໃຊ້ AI Agent｜ຈາກການອອກແບບ KPI ສູ່ການປັບປຸງຢ່າງຕໍ່ເນື່ອງ ແລະ ກຳນົດຮອບວຽນການວັດແທກຢ່າງສະໝໍ່າສະເໝີ ເພື່ອເຊື່ອມໂຍງໄປສູ່ການປັບປຸງຕົ້ນທຶນໃຫ້ເໝາະສົມຢ່າງຕໍ່ເນື່ອງ.