ນຳໂດຍ GPT OSS ທີ່ OpenAI ເປີດຕົວ ຫຼື Launch ພາຍໃຕ້ລິຂະສິດ Apache 2.0, ໂມເດລພາສາແບບ Open-weight ໄດ້ເລີ່ມບັນທຶກຄະແນນ Benchmark ທີ່ທຽບເທົ່າກັບ Cloud API ໃນວຽກງານສະເພາະບາງປະເພດ. ໂດຍສະເພາະ SLM (Small Language Model) ນັ້ນ, ຊ່ອງຫວ່າງດ້ານຄວາມຖືກຕ້ອງລະຫວ່າງ SLM ກັບ Cloud API ກຳລັງຄ່ອຍໆແຄບລົງໃນວຽກງານທີ່ເປັນແບບແຜນ ເຊັ່ນ: ການຈັດໝວດໝູ່, ການສະຫຼຸບ, ແລະ ການດຶງຂໍ້ມູນທີ່ມີໂຄງສ້າງ, ຈຶ່ງໄດ້ຮັບຄວາມສົນໃຈໃນຖານະທາງເລືອກທີ່ສາມາດຮັກສາອຳນາດອະທິປະໄຕຂໍ້ມູນ (Data Sovereignty) ແລະ ເພີ່ມປະສິດທິພາບດ້ານຕົ້ນທຶນໄດ້ພ້ອມກັນ. ບົດຄວາມນີ້ມຸ່ງໄປຫາຜູ້ຮັບຜິດຊອບດ້ານລະບົບຂໍ້ມູນຂ່າວສານ ແລະ ຄວາມປອດໄພໃນຂະແໜງການເງິນ, ການແພດ, ແລະ ການຜະລິດ ທີ່ມີຂໍ້ຈຳກັດໃນການສົ່ງຂໍ້ມູນໄປຍັງ Cloud, ໂດຍຈະປຽບທຽບການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງ Local LLM / SLM ລວມທັງ GPT OSS ກັບ Cloud API ໃນ 3 ມິຕິ ໄດ້ແກ່: ຄວາມຕ້ອງການ GPU, ຄວາມຖືກຕ້ອງຕາມປະເພດວຽກງານ, ແລະ TCO (Total Cost of Ownership). ເມື່ອອ່ານຈົບ, ທ່ານຈະມີຂໍ້ມູນພຽງພໍສຳລັບການຕັດສິນໃຈເລືອກສ່ວນປະສົມຂອງສະຖາປັດຕະຍະກຳ ແລະ ໂມເດລທີ່ເໝາະສົມທີ່ສຸດສຳລັບອົງກອນຂອງທ່ານ.

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

Cloud API ແມ່ນວິທີການສົ່ງ HTTP request ໄປຫາໂມເດລທີ່ໂຮດໄວ້ໂດຍ OpenAI, Anthropic, ແລະ Google. ຂໍ້ດີຄືບໍ່ຕ້ອງຈັດການໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ເອງ, ແຕ່ຂໍ້ເສຍຄືຂໍ້ມູນ input ຈະຜ່ານເຊີບເວີຂອງຜູ້ໃຫ້ບໍລິການ.

Local LLM ໝາຍເຖິງວິທີການລັນໂມເດລພາສາຂະໜາດໃຫຍ່ເທິງເຊີບເວີ ຫຼື workstation ຂອງຕົນເອງ. ໂມເດລຂະໜາດໃຫຍ່ທີ່ຢູ່ໃນປະເພດນີ້ ໄດ້ແກ່ Llama 4 Maverick (400B total parameters, 17B active) ແລະ GPT OSS 120B (117B total parameters, 5.1B active). ໂມເດລຂະໜາດໃຫຍ່ທີ່ອອກມາໃໝ່ໆໃຊ້ສະຖາປັດຕະຍະກຳ MoE (Mixture of Experts), ເຊິ່ງຊ່ວຍຫຼຸດຈຳນວນ active parameters ລົງຢ່າງຫຼວງຫຼາຍເມື່ອທຽບກັບ total parameters ທັງໝົດ, ເຮັດໃຫ້ສາມາດລັນໄດ້ດ້ວຍ GPU ໜ້ອຍກວ່າເດີມ.

SLM (Small Language Model) ແມ່ນໂມເດລຂະໜາດເບົາທີ່ຈຳກັດຈຳນວນ parameters ໄວ້ທີ່ລະດັບຫຼາຍພັນລ້ານ ຫຼື ໜ້ອຍກວ່ານັ້ນ. ຕົວຢ່າງທີ່ເດັ່ນໆ ໄດ້ແກ່ GPT OSS 20B (21B total parameters, 3.6B active), Phi-4 (14B), Gemma 3 (4B / 12B / 27B), Qwen 3 (7B), ແລະ Llama 4 Scout (109B total parameters, 17B active). ຈຸດໂດດເດັ່ນຄືການທີ່ "ຂະໜາດນ້ອຍ ≠ ປະສິດທິພາບຕ່ຳ" ເພາະດ້ວຍການຝຶກດ້ວຍ MoE ແລະຂໍ້ມູນຄຸນນະພາບສູງ, ໂມເດລເຫຼົ່ານີ້ສາມາດໃຫ້ຄວາມຖືກຕ້ອງໃນວຽກງານສະເພາະໃກ້ຄຽງກັບໂມເດລຂະໜາດໃຫຍ່ໄດ້.

ໂດຍສະເພາະ GPT OSS ແມ່ນ open-weight model family ຊຸດທຳອິດທີ່ OpenAI ເປີດຕົວ ຫຼື Launch ພາຍໃຕ້ລິຂະສິດ Apache 2.0, ໂດຍພາຍໃນເວລາພຽງສອງສາມອາທິດຫຼັງຈາກເປີດຕົວ ຫຼື Launch, ຈຳນວນດາວໂຫຼດເທິງ HuggingFace ໄດ້ເກີນ 9 ລ້ານຄັ້ງ. ເນື່ອງຈາກໃຊ້ tokenizer ດຽວກັນກັບ GPT series ຂອງ Cloud API ແລະຮອງຮັບທັງ tool calling ແລະ Chain-of-Thought reasoning, ຈຶ່ງເຮັດໃຫ້ອຸປະສັກໃນການຍ້າຍຈາກ workflow ທີ່ໃຊ້ GPT ຢູ່ແລ້ວມີໜ້ອຍ.

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

ທັງ Local LLM ແລະ SLM ຕ່າງກໍ່ບໍ່ໃຫ້ຂໍ້ມູນອອກຈາກສະພາບແວດລ້ອມຂອງບໍລິສັດ. ຄວາມແຕກຕ່າງຢູ່ທີ່ຂະໜາດຂອງ Model ແລະ ຊັບພະຍາກອນທີ່ຕ້ອງການ. ໃນພາກຕໍ່ໄປ, ພວກເຮົາຈະລວບລວມເກນການຕັດສິນໃຈວ່າຄວນເລືອກອັນໃດ.

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

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

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

ຮູບແບບທີ 2: ການວິເຄາະ Log ຂອງສາຍການຜະລິດ (ການຜະລິດ). ໃຫ້ SLM ວິເຄາະ Log ຂອງອຸປະກອນເທິງ Edge Server ຂອງໂຮງງານ ເພື່ອກວດຈັບຮູບແບບຄວາມຜິດປົກກະຕິ. ການໃຊ້ງານຜ່ານ Cloud API ຈະມີຄວາມລ່າຊ້າຈາກການສົ່ງ-ຮັບຂໍ້ມູນຜ່ານເຄືອຂ່າຍ, ໃນຂະນະທີ່ການປະມວນຜົນໃນເຄື່ອງຈະຊ່ວຍຫຼຸດຄວາມລ່າຊ້າດັ່ງກ່າວໄດ້. ຢ່າງໃດກໍ່ຕາມ, ການ Inference ຂອງ SLM ເອງກໍ່ຍັງໃຊ້ເວລາຫຼາຍສິບຫາຫຼາຍຮ້ອຍ Millisecond, ດັ່ງນັ້ນຄວາມໝາຍຂອງ "ແບບ Real-time" ຈຶ່ງຕ້ອງໄດ້ຮັບການກວດສອບໃຫ້ສອດຄ່ອງກັບຄວາມຕ້ອງການທາງທຸລະກິດ.

ຮູບແບບທີ 3: ການຈັດໂຄງສ້າງເວດຊະກຳອີເລັກໂທຣນິກ (ການແພດ). ສາມາດພິຈາລະນາໃຊ້ SLM ໃນການແປງບັນທຶກການວິນິດໄສທີ່ຂຽນໄວ້ໃນຮູບແບບອິດສະລະໃຫ້ເປັນຮູບແບບ SOAP. ເນື່ອງຈາກຂໍ້ມູນຄົນເຈັບບໍ່ຮົ່ວໄຫຼອອກຈາກເຄືອຂ່າຍພາຍໃນໂຮງໝໍ, ຈຶ່ງງ່າຍຕໍ່ການຮັກສາຄວາມສອດຄ່ອງກັບກົດໝາຍຄຸ້ມຄອງຂໍ້ມູນສ່ວນຕົວ ແລະ ແນວທາງຂໍ້ມູນທາງການແພດ. ຢ່າງໃດກໍ່ຕາມ, ເນື່ອງຈາກດ້ານການແພດຈັດຢູ່ໃນໝວດ YMYL (Your Money or Your Life), ການມີລະບົບການກວດທານຜົນລັບໂດຍມະນຸດຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ໃນທາງກົງກັນຂ້າມ, ຖ້າຕົງກັບເງື່ອນໄຂຕໍ່ໄປນີ້, Cloud API ຈະມີຄວາມສົມເຫດສົມຜົນກວ່າ.

• ຂໍ້ມູນທີ່ປະມວນຜົນບໍ່ມີຂໍ້ມູນລັບ (ການສະຫຼຸບຂໍ້ມູນສາທາລະນະ, ການສ້າງ FAQ ພາຍໃນອົງກອນ ເປັນຕົ້ນ)
• ປະລິມານ Token ຕໍ່ເດືອນມີໜ້ອຍ (ອ້າງອີງຈຸດຄຸ້ມທຶນທີ່ຈະກ່າວຕໍ່ໄປ)
• ຕ້ອງການປະສິດທິພາບຂອງ Model ລ່າສຸດຢູ່ສະເໝີ (Cloud API ຈະອັບເດດ Model ໂດຍອັດຕະໂນມັດ)
• ບໍ່ສາມາດຈັດການດ້ານ GPU ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໄດ້ (ບໍ່ມີ ML Engineer ທີ່ຮັບຜິດຊອບໂດຍກົງ)

ໃນກໍລະນີທີ່ "ມີຂໍ້ມູນທີ່ສົ່ງໄປ Cloud ບໍ່ໄດ້" ແລະ "ປະລິມານ Token ຕໍ່ເດືອນມີລະດັບໜຶ່ງ", ການລົງທຶນໃນການປະຕິບັດງານແບບ Local ຈຶ່ງຈະຄຸ້ມຄ່າ.

ສິ່ງທີ່ຕິດຂັດທຳອິດໃນການລັນໂລກັລ (Local) ຄື "ຈະໃຊ້ໂມເດລໃດ ແລະ ລັນໄດ້ດ້ວຍຮາດແວ (Hardware) ໃດ". ດ້ວຍການແຜ່ຫຼາຍຂອງສະຖາປັດຕະຍະກຳ MoE (Mixture of Experts), ຈຳນວນພາຣາມິເຕີ (Parameter) ທັງໝົດພຽງຢ່າງດຽວບໍ່ສາມາດໃຊ້ຕັດສິນຄວາມຕ້ອງການໜ່ວຍຄວາມຈຳໄດ້ອີກຕໍ່ໄປ. ຈຶ່ງຄວນຄຳນວນຍ້ອນກັບຈາກຈຳນວນ Active Parameter ແລະ ລະດັບການ Quantization ເພື່ອໃຫ້ສາມາດຄັດເລືອກໂມເດລໄດ້ຕາມງົບປະມານທີ່ມີ.

ຕາຕະລາງຕໍ່ໄປນີ້ສະຫຼຸບໂມເດລ Open-weight ຫຼັກໆ ໂດຍຈັດລຽງຕາມຄວາມຕ້ອງການໜ່ວຍຄວາມຈຳ GPU. ສິ່ງທີ່ຄວນສັງເກດຄື ໂມເດລ MoE ນັ້ນ ເຖິງແມ່ນຈຳນວນ Parameter ທັງໝົດຈະຫຼາຍ ແຕ່ເນື່ອງຈາກ Active Parameter ມີໜ້ອຍ ຈຶ່ງສາມາດຫຼຸດຄວາມຕ້ອງການໜ່ວຍຄວາມຈຳໄດ້.

ການປຽບທຽບມາດຕະຖານ ຫຼື Specification ຂອງ GPU (ທາງການ NVIDIA): RTX 5090 ມີ 32GB GDDR7 · Bandwidth 1,792 GB/s (Blackwell Architecture). H200 ມີ 141GB HBM3e · Bandwidth 4.8 TB/s. B200 ມີ 192GB HBM3e · Bandwidth 8 TB/s. Bandwidth ແມ່ນຕົວຊີ້ວັດທີ່ສຳຄັນໂດຍສະເພາະສຳລັບການ Inference LLM ແບບ Memory-bound.

ວິທີອ່ານ: "Q4 VRAM ໂດຍປະມານ" ຂອງໂມເດລ MoE ນັ້ນລວມນ້ຳໜັກຂອງ Expert ທັງໝົດໄວ້ດ້ວຍ. ເຖິງແມ່ນ Active Parameter ຈະໜ້ອຍ ກໍຍັງຕ້ອງໂຫຼດ Expert ທັງໝົດໄວ້ໃນໜ່ວຍຄວາມຈຳ.

ສິ່ງທີ່ໜ້າສົນໃຈຄືປະສິດທິພາບຂອງ GPT OSS 20B. Parameter ທັງໝົດ 21B ແຕ່ Active ມີພຽງ 3.6B. ດ້ວຍການ Quantize ແບບ MXFP4 ໃຊ້ພຽງປະມານ 13GB ຈຶ່ງສາມາດທຳງານໄດ້ຢ່າງສະດວກສະບາຍໃນ RTX 5090 32GB (ສາມາດໃຊ້ກັບ RTX 4090 24GB ໄດ້ດ້ວຍ). ເຖິງຢ່າງນັ້ນ ໃນ Benchmark ທາງການ ກໍຍັງບັນທຶກຄະແນນທຽບເທົ່າ OpenAI o3-mini.

ຫາກຕ້ອງການຄວາມຖືກຕ້ອງສູງສຸດດ້ວຍ RTX 5090 ໜຶ່ງໃບ GPT OSS 20B (MXFP4) ແມ່ນຕົວເລືອກອັນດັບໜຶ່ງ. ເນື່ອງຈາກ Bandwidth ສູງຂຶ້ນ 78% ເມື່ອທຽບກັບ RTX 4090 ຈຶ່ງຄາດວ່າ Inference Throughput ຈະດີຂຶ້ນດ້ວຍ. ດ້ວຍ VRAM 32GB ທີ່ເຫຼືອຢູ່ Gemma 3 27B (Q4, 16GB) ກໍສາມາດທຳງານໄດ້ຢ່າງສະດວກສະບາຍເຊັ່ນກັນ.

ຫາກໃຊ້ H200 ໜຶ່ງໃບ ທັງ GPT OSS 120B ແລະ Llama 4 Scout ຕ່າງກໍເປັນຕົວເລືອກທີ່ເໝາະສົມ. GPT OSS 120B ໃຊ້ MXFP4 ປະມານ 61GB, Llama 4 Scout ໃຊ້ int4 ປະມານ 55GB + KV Cache. ດ້ວຍ VRAM 141GB ຈຶ່ງມີ KV Cache ເຫຼືອພຽງພໍສຳລັບ Context ຍາວ (128K Token) ດ້ວຍ. ຫາກເນັ້ນ Inference ຂໍ້ຄວາມ ໃຫ້ເລືອກ GPT OSS 120B, ຫາກຕ້ອງການ Multimodal (ການເຂົ້າໃຈຮູບພາບ) ໃຫ້ເລືອກ Llama 4 Scout.

ຫາກໃຊ້ B200 ສາມາດພິຈາລະນາ Llama 4 Maverick (Parameter ທັງໝົດ 400B) ໄດ້ດ້ວຍ. ດ້ວຍ HBM3e 192GB ແລະ Bandwidth 8 TB/s ຈຶ່ງສາມາດ Inference ດ້ວຍ Q4 Quantization ໃນ GPU ດຽວໄດ້. ປະສິດທິພາບ Inference ສູງກວ່າ H100 ສູງສຸດເຖິງ 15 ເທົ່າ (ທາງການ NVIDIA).

ການ Quantization ແມ່ນເຕັກນິກການບີບອັດນ້ຳໜັກຂອງໂມເດລໃຫ້ເປັນ bit ຕ່ຳ (4bit / 8bit) ເຊິ່ງສາມາດຫຼຸດ VRAM ທີ່ຕ້ອງການລົງໄດ້ຫຼາຍກວ່າເຄິ່ງໜຶ່ງ. ດ້ວຍການເປີດຕົວ ຫຼື Launch ຂອງ GPT OSS, MXFP4 ໄດ້ກາຍເປັນທາງເລືອກໃໝ່ເພີ່ມເຕີມຈາກຮູບແບບ Quantization ແບບດັ້ງເດີມ.

ກ່ຽວກັບຄວາມສຳພັນລະຫວ່າງລະດັບ Quantization ແລະ ຄວາມຖືກຕ້ອງ, ມີລາຍງານການກວດສອບຈາກຊຸມຊົນສະສົມຢູ່ຫຼາຍ. ໂດຍທົ່ວໄປ, Q8 (8bit) ແทบຈະບໍ່ພົບການຫຼຸດລົງຂອງຄວາມຖືກຕ້ອງເມື່ອທຽບກັບ FP16, Q4 (4bit) ອາດມີການຊຸດໂຊມເລັກນ້ອຍຂຶ້ນກັບ Task, ສ່ວນ Q2 (2bit) ມີລາຍງານວ່າຄຸນນະພາບຫຼຸດລົງຢ່າງຊັດເຈນ. ຢ່າງໃດກໍ່ຕາມ, ລະດັບຂອງການຊຸດໂຊມຈະແຕກຕ່າງກັນໄປຕາມໂມເດລ, Task ແລະ ພາສາ, ດັ່ງນັ້ນການກວດສອບໃນ Use case ຂອງຕົນເອງຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

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

MXFP4 ແມ່ນຮູບແບບ Quantization ທີ່ OpenAI ນຳໃຊ້ໃນ GPT OSS ໂດຍນຳໄປໃຊ້ຢ່າງເລືອກສັນກັບນ້ຳໜັກ Expert ຂອງ MoE. ໃຫ້ Throughput ທີ່ດີທີ່ສຸດໃນ Blackwell Architecture (B200 / RTX 5090) ແລະ Hopper Architecture (H100 / H200).

ຜົນປະໂຫຍດຂອງ Quantization ບໍ່ໄດ້ຢູ່ທີ່ການຫຼຸດ VRAM ເທົ່ານັ້ນ. Memory Bandwidth ຂອງ RTX 5090 ທີ່ 1,792 GB/s, H200 ທີ່ 4.8 TB/s ແລະ B200 ທີ່ 8 TB/s ສ້າງຜົນສະທ້ອນເສີມກັນກັບການຫຼຸດຂະໜາດນ້ຳໜັກຈາກ Quantization. ເຖິງແມ່ນຈະເປັນໂມເດລດຽວກັນ, ຫາກໃຊ້ Q4 ປະລິມານການຖ່າຍໂອນນ້ຳໜັກຈະຫຼຸດລົງເຄິ່ງໜຶ່ງ, ຊ່ວຍຜ່ອນຄາຍຄໍຂວດຂອງ Bandwidth ແລະ ເພີ່ມຄວາມໄວໃນການສ້າງ Token.

ການດາວໂຫຼດໄຟລ໌ນ້ຳໜັກຂອງໂມເດລເທົ່ານັ້ນ ບໍ່ສາມາດດຳເນີນການ Inference (ການສ້າງຂໍ້ຄວາມ) ໄດ້. ສິ່ງທີ່ຮັບຜິດຊອບຕໍ່ຂະບວນການ ຫຼື Pipeline ທັງໝົດ ໄດ້ແກ່: ການໂຫຼດໂມເດລໃສ່ GPU, ການໃຊ້ Tokenizer, ການຈັດການ KV Cache, ແລະ ການ Sampling Token ຜົນລັບ ນັ້ນຄື Inference Framework. ການເລືອກ Framework ບໍ່ສົ່ງຜົນຕໍ່ຄວາມຖືກຕ້ອງຂອງໂມເດລ, ແຕ່ສົ່ງຜົນໂດຍກົງຕໍ່ຄວາມໄວໃນການ Inference, ຈຳນວນການປະມວນຜົນພ້ອມກັນ, ແລະ ຄວາມສະດວກໃນການດຳເນີນງານ.

llama.cpp ແມ່ນ Inference Engine ທີ່ຂຽນດ້ວຍ C/C++ ຮອງຮັບຕັ້ງແຕ່ CPU only ຈົນເຖິງ GPU ໄດ້ຢ່າງກວ້າງຂວາງ. ສາມາດໂຫຼດໂມເດລຮູບແບບ GGUF ໄດ້ໂດຍກົງ ແລະ ມີຈຸດເດັ່ນຄືມີ Dependency ໜ້ອຍ ນອກຈາກ Python Environment ແລະ CUDA Driver. GPT OSS ກໍ່ມີເວີຊັນທີ່ແປງເປັນ GGUF ໃຫ້ດາວໂຫຼດໄດ້ ແລະ ສາມາດເລີ່ມໃຊ້ງານດ້ວຍ llama-server -hf ggml-org/gpt-oss-120b-GGUF. ເໝາະສຳລັບການຕິດຕັ້ງໃນສະພາບແວດລ້ອມທີ່ຍາກຕໍ່ການຕັ້ງຄ່າ Python Environment ເຊັ່ນ: Windows PC ຫຼື Edge Device.

vLLM ມີຈຸດເດັ່ນດ້ານການຈັດການໜ່ວຍຄວາມຈຳທີ່ມີປະສິດທິພາບສູງດ້ວຍ PagedAttention. ໃນການ Inference ທົ່ວໄປ, KV Cache ຈະຈອງໜ່ວຍຄວາມຈຳຕໍ່ເນື່ອງສຳລັບແຕ່ລະ Request ເຮັດໃຫ້ VRAM ຕຶງຕັນເມື່ອຈຳນວນ Request ພ້ອມກັນເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. vLLM ຈັດການສິ່ງນີ້ໃນລະດັບ Page ເພື່ອປ້ອງກັນການກະຈັດກະຈາຍຂອງໜ່ວຍຄວາມຈຳ ຊ່ວຍໃຫ້ປະມວນຜົນ Request ຫຼາຍກວ່າໃນ VRAM ດຽວກັນໄດ້ພ້ອມກັນ. GPT OSS ຮອງຮັບ vLLM ຢ່າງເປັນທາງການ ແລະ ສາມາດ Deploy ດ້ວຍ vllm serve openai/gpt-oss-120b --tensor-parallel-size 2. ນີ້ຄືທາງເລືອກອັນດັບໜຶ່ງສຳລັບການໃຫ້ບໍລິການ API Server ພາຍໃນອົງກອນໃຫ້ຫຼາຍພະແນກ.

Ollama ແມ່ນ CLI Tool ທີ່ Wrap llama.cpp ໄວ້ ສາມາດດາວໂຫຼດໂມເດລຈົນເຖິງເລີ່ມໃຊ້ງານໄດ້ດ້ວຍຄຳສັ່ງດຽວ ollama run phi4. ການຈັດການໂມເດລ (ສັບປ່ຽນເວີຊັນ, ລຶບ) ກໍ່ສຳເລັດໄດ້ຜ່ານ CLI ທັງໝົດ ຈຶ່ງເໝາະທີ່ສຸດສຳລັບຂັ້ນຕອນ PoC ຫຼື Prototyping ທີ່ຕ້ອງການ "ລອງໃຊ້ງານກ່ອນ". ຢ່າງໃດກໍ່ຕາມ ເນື່ອງຈາກບໍ່ມີກົນໄກ Request Queuing ຫຼື Monitoring ໃນຕົວ ຈຶ່ງຈຳເປັນຕ້ອງຍ້າຍໄປໃຊ້ vLLM ຫຼືອື່ນໆ ສຳລັບສະພາບແວດລ້ອມ Production.

"ເຂົ້າໃຈແລ້ວວ່າສາມາດໃຊ້ງານໄດ້ໃນເຄື່ອງ Local, ແຕ່ຄວາມຖືກຕ້ອງແມ່ນບໍ່ເປັນຫຍັງບໍ?" — ນີ້ຄືຄຳຖາມທີ່ພົບເຫັນຫຼາຍທີ່ສຸດໃນຂັ້ນຕອນການພິຈາລະນານຳໃຊ້. ການເປີດຕົວ ຫຼື Launch GPT OSS ໄດ້ປ່ຽນແປງຄຳຕອບຂອງຄຳຖາມນີ້ໄປຢ່າງຫຼວງຫຼາຍ.

ຕໍ່ໄປນີ້ແມ່ນການປຽບທຽບຄະແນນທີ່ເປີດຕົວ ຫຼື Launch ຢ່າງເປັນທາງການຂອງ Local Model ແລະ Cloud API ໃນ Benchmark ຫຼັກໆ. MMLU, HumanEval, ແລະ MATH ອ້າງອີງຈາກຄ່າທີ່ປະກາດໂດຍທາງການຂອງແຕ່ລະ Model ຫຼືຜ່ານການກວດສອບຄືນໂດຍພາກສ່ວນທີສາມ.

ໝາຍເຫດ: ຄະແນນ Benchmark ລາຍ Task ຂອງ GPT OSS 20B ໄດ້ຖືກສະຫຼຸບໃນ Model Card ທາງການວ່າ "ທຽບເທົ່າ o3-mini" ແຕ່ຄະແນນລາຍລະອຽດແຍກຕາມ Task ບາງສ່ວນຍັງບໍ່ທັນໄດ້ເປີດຕົວ ຫຼື Launch. "ທຽບເທົ່າ o3-mini" ທີ່ລະບຸຂ້າງເທິງອ້າງອີງຈາກການປຽບທຽບທາງການຂອງ OpenAI.

ສຳລັບການຈັດປະເພດຂໍ້ຄວາມ, ການສະຫຼຸບປະໂຫຍກສັ້ນ, ການດຶງຂໍ້ມູນທີ່ມີໂຄງສ້າງ, ແລະການແປພາສາຫຼາຍພາສານັ້ນ, Benchmark ສາທາລະນະມາດຕະຖານ ຫຼື Specification ທີ່ຖືກສ້າງຕັ້ງຂຶ້ນຢ່າງເປັນທາງການຍັງບໍ່ທັນມີ, ດັ່ງນັ້ນການປຽບທຽບຄວາມຖືກຕ້ອງລະຫວ່າງ Model ຈຶ່ງຈຳເປັນຕ້ອງໄດ້ກວດສອບດ້ວຍຂໍ້ມູນຂອງຕົນເອງ. ໂດຍທົ່ວໄປ, Task ທີ່ມີ Input/Output ສັ້ນ ແລະ ເປັນຮູບແບບຄົງທີ່ (ເຊັ່ນ: ການຈັດປະເພດ ແລະ ການດຶງຂໍ້ມູນ) ຈະມີຄວາມແຕກຕ່າງລະຫວ່າງ SLM ແລະ Cloud API ໜ້ອຍກວ່າ, ໃນຂະນະທີ່ Task ທີ່ຕ້ອງການ Context ຍາວ ຫຼື ການໃຊ້ເຫດຜົນທີ່ສັບສົນ Cloud API ຈະໄດ້ປຽບກວ່າ.

ການມາຮອດຂອງ GPT OSS ໄດ້ຂະຫຍາຍຂອບເຂດທີ່ Local Model ສາມາດທຽບເທົ່າກັບ Cloud API ໄດ້ໃນ Public Benchmark.

ຂອບເຂດ Benchmark ທີ່ Local Model ມີຄວາມເຂັ້ມແຂງ ໄດ້ແກ່ ການສ້າງ Code (HumanEval) ແລະ ການເອີ້ນໃຊ້ Tool (TauBench). GPT OSS 120B ໄດ້ຄະແນນໃນ TauBench ສູງກວ່າ o3-mini ແລະ ທຽບເທົ່າກັບ o4-mini (OpenAI Official Blog). GPT OSS 20B ກໍ່ຖືກລະບຸວ່າຢູ່ໃນລະດັບດຽວກັນກັບ o3-mini.

ຂອບເຂດທີ່ Cloud API ຍັງຄົງມີຄວາມໄດ້ປຽບ ຄື ການຄິດໄລ່ທີ່ສັບສົນ, ຄະນິດສາດ (MATH Benchmark) ແລະ ວຽກງານຫຼາຍພາສາ. ເຖິງແມ່ນວ່າຈະໃຊ້ "deep mode" (ໂໝດທີ່ໃຊ້ເວລາໃນການ Reasoning ຫຼາຍຂຶ້ນ) ຂອງ GPT OSS 120B ກໍ່ຕາມ, ຄວາມແຕກຕ່າງກັບ Cloud Model ຂະໜາດໃຫຍ່ຍັງຄົງມີຢູ່.

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

ຫາກຄວາມຖືກຕ້ອງທົ່ວໄປຍັງບໍ່ພຽງພໍ, ສາມາດໃຊ້ PEFT (Parameter-Efficient Fine-Tuning) ເພື່ອປັບແຕ່ງໂມເດລໃຫ້ເໝາະສົມກັບຂໍ້ມູນສະເພາະຂອງອົງກອນ ແລະ ຍົກລະດັບຄວາມຖືກຕ້ອງໄດ້.

ໃນດ້ານ License, GPT OSS ໃຊ້ Apache 2.0 ຈຶ່ງບໍ່ມີຂໍ້ຈຳກັດໃນການຟາຍນ໌ທູນນິ້ງ ຫຼື ການນຳໃຊ້ທາງການຄ້າ. ໃນທາງກົງກັນຂ້າມ, Llama 4 Scout ໃຊ້ Llama 4 Community License ເຊິ່ງອົງກອນທີ່ມີຜູ້ໃຊ້ງານຕໍ່ເດືອນເກີນ 700 ລ້ານຄົນຕ້ອງຂໍ License ແຍກຕ່າງຫາກ. ສຳລັບຫຼາຍໆອົງກອນ ຂໍ້ຈຳກັດນີ້ອາດບໍ່ສົ່ງຜົນກະທົບໃນທາງປະຕິບັດ, ແຕ່ຄວນຮັບຮູ້ວ່າເງື່ອນໄຂແຕກຕ່າງຈາກ Apache 2.0.

ໃນບັນດາ PEFT, ສິ່ງທີ່ໃຊ້ຫຼາຍທີ່ສຸດໃນການປະຕິບັດຕົວຈິງຄື LoRA ແລະ QLoRA.

LoRA ແມ່ນວິທີການເພີ່ມ Matrix ອັບເດດ Low-rank ເຂົ້າໃນ Weight Matrix ຂອງໂມເດລ, ໂດຍຮຽນຮູ້ສະເພາະ Parameter ເພີ່ມເຕີມທີ່ຄິດເປັນປະມານ 0.1–1% ຂອງ Parameter ທັງໝົດ. ສາມາດ Fine-tune LoRA ຂອງ Phi-4 14B ໄດ້ດ້ວຍ RTX 4090 ພຽງໜຶ່ງໃບ.

QLoRA ແມ່ນວິທີການທີ່ລວມ LoRA ກັບ Quantization ເຂົ້າດ້ວຍກັນ, ຊ່ວຍຫຼຸດ VRAM ທີ່ຕ້ອງການລົງອີກເຄິ່ງໜຶ່ງ. ເນື່ອງຈາກສາມາດ Fine-tune ໂມເດລ 14B ໄດ້ດ້ວຍ GPU ລະດັບ 16GB, ຈຶ່ງເປັນທາງເລືອກທີ່ດີສຳລັບຜູ້ທີ່ຕ້ອງການຫຼຸດຜ່ອນການລົງທຶນເບື້ອງຕົ້ນ.

ຂະບວນການ ຫຼື Pipeline ທົ່ວໄປຂອງການ Customize ມີດັ່ງນີ້:

1. ເລືອກ Base Model: ເລືອກໂມເດລທີ່ເໝາະສົມກັບ Hardware ຈາກຕາຕະລາງການເລືອກຂ້າງເທິງ
2. ກຽມຂໍ້ມູນ: ສ້າງຂໍ້ມູນຝຶກສອນ 500–5,000 ລາຍການຈາກຂໍ້ມູນການດຳເນີນງານ (ຄູ່ Input–Output)
3. Fine-tune ດ້ວຍ QLoRA: ເວລາຝຶກສອນຂຶ້ນກັບປະລິມານຂໍ້ມູນ, LoRA rank ແລະ ຈຳນວນ Epoch. ເປັນຕົວຢ່າງ, ດ້ວຍເງື່ອນໄຂ 1,000 ລາຍການ, rank 16, 3 Epoch ເທິງ RTX 4090 ໃຊ້ເວລາປະມານສອງສາມຊົ່ວໂມງ
4. ປະເມີນຜົນ: ກວດສອບຄວາມຖືກຕ້ອງດ້ວຍ Test Set ພາຍໃນ ແລະ ຢືນຢັນຄວາມແຕກຕ່າງຈາກ Base Model
5. Deploy: ນຳໂມເດລທີ່ລວມ ຫຼື Merge ແລ້ວໄປຕິດຕັ້ງໃນ llama.cpp / vLLM

ລະດັບການປັບປຸງຄວາມຖືກຕ້ອງຈາກການ Fine-tune ສະເພາະໂດເມນນັ້ນຂຶ້ນກັບຄວາມສາມາດທົ່ວໄປຂອງ Base Model, ຄຸນນະພາບ ແລະ ປະລິມານຂໍ້ມູນຝຶກສອນ, ລວມທັງລັກສະນະຂອງ Task ເປັນຫຼັກ. ແນະນຳໃຫ້ກວດສອບປະສິດທິຜົນດ້ວຍການທົດສອບຂະໜາດນ້ອຍ (100–200 ລາຍການ) ກ່ອນ, ແລ້ວຈຶ່ງດຳເນີນການກຽມຂໍ້ມູນຢ່າງເຕັມຮູບແບບ.

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

ໝາຍເຫດ: ລາຄາຮາດແວອາດມີການປ່ຽນແປງຢ່າງຫຼວງຫຼາຍຕາມສະພາບຕະຫຼາດ. ມີລາຍງານວ່າ RTX 5090 ຖືກຊື້ຂາຍໃນລາຄາທີ່ສູງກວ່າ MSRP ($1,999) ຢ່າງຫຼວງຫຼາຍ ເນື່ອງຈາກຜົນກະທົບຂອງການຂາດແຄນ DRAM. ໃນເວລາພິຈາລະນານໍາໃຊ້ງານ ຄວນກວດສອບລາຄາຕະຫຼາດລ່າສຸດ.

ຄວາມຄຸ້ມຄ່າດ້ານຕົ້ນທຶນຂອງ RTX 5090 ໄດ້ຮັບຄວາມສົນໃຈ. ການທີ່ GPT OSS 20B (ທຽບເທົ່າ o3-mini ຕາມ Benchmark ທາງການ) ສາມາດເຮັດວຽກໄດ້ເທິງ GPU ສໍາລັບຜູ້ບໍລິໂພກຂະໜາດ 32GB ນັ້ນ ເປັນປັດໄຈທີ່ຊ່ວຍຫຼຸດຈຸດຄຸ້ມທຶນຂອງ Local AI ລົງ.

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

ສຳລັບເຊີບເວີ RTX 5090 (ສົມມຸດວ່າລົງທຶນເບື້ອງຕົ້ນ 80〜100 ໝື່ນເຢນ, ຄ່າດຳເນີນງານລາຍເດືອນ 3〜5 ໝື່ນເຢນ, ລາຄາເປັນຄ່າອ້າງອີງ), ຈຸດຄຸ້ມທຶນເມື່ອທຽບກັບ Cloud API ຂຶ້ນຢູ່ກັບປະລິມານ Token ຕໍ່ເດືອນ. RTX 5090 ມີ VRAM ເພີ່ມຂຶ້ນຈາກ 24GB ເປັນ 32GB ເມື່ອທຽບກັບ RTX 4090 ແລະ Memory Bandwidth ກໍ່ດີຂຶ້ນ 78%, ຈຶ່ງສາມາດຮອງຮັບໂມເດລ MoE ຢ່າງ GPT OSS 20B ໄດ້ຢ່າງສະດວກສະບາຍຍິ່ງຂຶ້ນ.

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

RTX 5090 ມີຄ່າລົງທຶນເບື້ອງຕົ້ນສູງກວ່າ RTX 4090, ແຕ່ດ້ວຍ VRAM 32GB ກໍ່ສາມາດຮອງຮັບ Gemma 3 27B (Q4, 16GB) ໄດ້ຢ່າງສະດວກ ແລະ ເປີດທາງເລືອກໂມເດລໄດ້ກວ້າງຂຶ້ນ. ການຕັດສິນໃຈວ່າຄ່າລົງທຶນທີ່ເພີ່ມຂຶ້ນນັ້ນຄຸ້ມຄ່າຫຼືບໍ່ ຂຶ້ນຢູ່ກັບຂະໜາດໂມເດລທີ່ຕ້ອງການ ແລະ ປະລິມານການປະມວນຜົນ.

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

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

ມີກໍລະນີທີ່ພະຍາຍາມບັງຄັບໃຊ້ໂມເດລ 70B ໂດຍການ Quantization ຫຼາຍເກີນໄປ (Q2) ຈົນເຮັດໃຫ້ຄຸນນະພາບຫຼຸດລົງ. ໃນຫຼາຍກໍລະນີ, ການໃຊ້ໂມເດລ 14B ດ້ວຍ Q4 ໃຫ້ຄວາມຖືກຕ້ອງສູງກວ່າການໃຊ້ໂມເດລ 70B ດ້ວຍ Q2. ການເລືອກໃຊ້ໂມເດລທີ່ມີຂະໜາດເໝາະສົມກັບ Hardware ໂດຍໃຊ້ Q4 ຂຶ້ນໄປ ຈະເຮັດໃຫ້ທັງຄວາມຖືກຕ້ອງ ແລະ ຕົ້ນທຶນໄດ້ຮັບການ Optimize ໃນທີ່ສຸດ.

ໃຫ້ກັບໄປເບິ່ງຕາຕະລາງການເລືອກໂມເດລຕາມຄວາມຕ້ອງການ GPU ທີ່ກ່າວໄວ້ຂ້າງເທິງ, ແລ້ວເລືອກ "ໂມເດລທີ່ໃຫຍ່ທີ່ສຸດທີ່ສາມາດໃຊ້ Q4 ຂຶ້ນໄປໄດ້" ຕາມ GPU Memory ຂອງອົງກອນຕົນເອງ — ນີ້ຄືຄຳຕອບທີ່ຖືກຕ້ອງໃນທາງປະຕິບັດ.

ອີກຈຸດໜຶ່ງທີ່ມັກຖືກມອງຂ້າມຄືການໃຊ້ໜ່ວຍຄວາມຈຳຂອງ KV Cache ໃນຊ່ວງການ Inference. ເຖິງແມ່ນວ່າໂມເດລຫຼັກຈະໃຊ້ພຽງ 8GB ແຕ່ຫາກປະມວນຜົນ Prompt ທີ່ຍາວ (ເກີນ 4,000 Token) KV Cache ກໍຈະໃຊ້ໜ່ວຍຄວາມຈຳເພີ່ມຂຶ້ນອີກ 2〜4GB. ເຖິງແມ່ນ RTX 4090 ທີ່ມີ VRAM 24GB ກໍອາດໃຊ້ໜ່ວຍຄວາມຈຳຮອດ 18〜20GB ຈາກການລວມກັນຂອງ 14B Model (Q4, 8GB) + KV Cache + OS.

ມີ 2 ວິທີແກ້ໄຂ. ວິທີທຳອິດຄືການຈຳກັດຄວາມຍາວ Context ໃຫ້ຢູ່ໃນລະດັບຕ່ຳສຸດທີ່ຈຳເປັນສຳລັບການໃຊ້ງານຕົວຈິງ (ຖ້າ 4,096 ພໍໃຊ້ ກໍບໍ່ຈຳເປັນຕ້ອງຕັ້ງເປັນ 8,192). ວິທີທີສອງຄືການໃຊ້ PagedAttention ຂອງ vLLM ເພື່ອຈັດການ KV Cache ໃຫ້ມີປະສິດທິພາບຫຼາຍຂຶ້ນ.

ມີກໍລະນີທີ່ PoC ໃນຕອນເລີ່ມຕົ້ນນຳໃຊ້ປະສົບຜົນສຳເລັດ ແຕ່ກັບຖືກປະລະໄວ້ໃນໄລຍະການດຳເນີນງານຕົວຈິງ. ໂມເດລ Open-weight ນັ້ນຈະມີເວີຊັນໃໝ່ເປີດຕົວ ຫຼື Launch ທຸກໆສອງສາມເດືອນ. ດັ່ງທີ່ເຫັນໄດ້ຈາກ Phi-3 → Phi-4 ແລະ Gemma 2 → Gemma 3 ເມື່ອຍ້າຍຂ້າມລຸ້ນ ຄວາມຖືກຕ້ອງກໍ່ຈະດີຂຶ້ນຢ່າງຫຼວງຫຼາຍ ເຖິງແມ່ນຈຳນວນ Parameter ຈະເທົ່າກັນກໍ່ຕາມ.

ໃນຖານະເປັນລະບົບການດຳເນີນງານຂັ້ນຕ່ຳສຸດ ແນະນຳໃຫ້ລວມເອົາການປະເມີນການອັບເດດໂມເດລທຸກໄຕມາດ ພ້ອມທັງການຕິດຕາມກວດສອບຄວາມໄວໃນການ Inference ແລະອັດຕາຄວາມຜິດພາດຢ່າງເປັນປົກກະຕິ. ນີ້ແມ່ນລະດັບຂອງວຽກງານທີ່ເຈົ້າໜ້າທີ່ລະບົບຂໍ້ມູນຂ່າວສານ (情シス) ສາມາດເຮັດໃຫ້ເປັນລະບົບອັດຕະໂນມັດດ້ວຍ Script ໄດ້ ໂດຍບໍ່ຈຳເປັນຕ້ອງມີ ML Engineer ທີ່ຮັບຜິດຊອບໂດຍກົງ.

ຖ້າສາມາດສົ່ງຂໍ້ມູນອອກສູ່ພາຍນອກໄດ້, Cloud API ຈະສະດວກກວ່າ. ຄວນເລືອກໃຊ້ GPT OSS ໃນກໍລະນີທີ່ມີຂໍ້ຈຳກັດດ້ານ Data Sovereignty, ຕ້ອງການຄົງຄ່າຕົ້ນທຶນ API ໃຫ້ເປັນຄ່າໃຊ້ຈ່າຍຄົງທີ່, ຫຼືຕ້ອງການໃຊ້ງານໃນສະພາບແວດລ້ອມ Offline. ຈາກ Benchmark ທາງການຂອງ OpenAI, GPT OSS 20B ບັນທຶກຄະແນນທີ່ທຽບເທົ່າກັບ o3-mini ໃນດ້ານ MMLU, HumanEval, TauBench ແລະອື່ນໆ, ໃນຂະນະທີ່ 120B ບັນທຶກຄະແນນທີ່ທຽບເທົ່າກັບ o4-mini. ຢ່າງໃດກໍ່ຕາມ, ເນື່ອງຈາກຄະແນນ Benchmark ບໍ່ໄດ້ຮັບປະກັນຄວາມຖືກຕ້ອງໃນວຽກງານທຸລະກິດຕົວຈິງ, ການກວດສອບ PoC ດ້ວຍ Task ຂອງອົງກອນຕົນເອງຈຶ່ງເປັນສິ່ງຈຳເປັນ.

ສາມາດໃຊ້ງານໄດ້. RAG (Retrieval-Augmented Generation) ແມ່ນວິທີການຝັງເອກະສານທີ່ດຶງມາຈາກການຄົ້ນຫາລົງໃນ prompt ດັ່ງນັ້ນຈຶ່ງບໍ່ຂຶ້ນກັບຂະໜາດຂອງ model. ດ້ວຍການປະສົມປະສານລະຫວ່າງ GPT OSS 20B ຫຼື Phi-4 + vector DB (Qdrant, pgvector ເປັນຕົ້ນ) ສາມາດສ້າງຂະບວນການ ຫຼື Pipeline ສຳລັບການຄົ້ນຫາເອກະສານພາຍໃນອົງກອນ + ການສ້າງຄຳຕອບໄດ້. ເນື່ອງຈາກ GPT OSS ມີ context length 128K ແລະ Llama 4 Scout ມີ context length ສູງສຸດເຖິງ 10M token ຈຶ່ງມີຄວາມຍືດຫຍຸ່ນໃນການອອກແບບ chunk size ຂອງ RAG ໄດ້ຢ່າງສະດວກ.

ຂຶ້ນຢູ່ກັບຮາດແວ, ມີບາງກໍລະນີທີ່ Local ໄວກວ່າໃນດ້ານ Latency ຂອງ Request ດຽວ. ນັ້ນກໍ່ຍ້ອນວ່າ Cloud API ມີ Overhead ຈາກການສົ່ງຂໍ້ມູນຜ່ານເຄືອຂ່າຍໄປ-ກັບ ແລະ ການລໍຖ້າໃນ Queue ເພີ່ມເຕີມ. ສຳລັບ GPT OSS 20B ທີ່ໃຊ້ງານບົນ RTX 4090, ເນື່ອງຈາກ Active Parameter ຂອງ MoE ມີພຽງ 3.6B ເທົ່ານັ້ນ, ຈຶ່ງມີຄວາມເປັນໄປໄດ້ທີ່ຈະເລີ່ມສ້າງ Token ໄດ້ໄວກວ່າ Dense 14B Model. ຢ່າງໃດກໍ່ຕາມ, ເມື່ອຈຳນວນ Request ພ້ອມກັນເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ, GPU ຈະກາຍເປັນ Bottleneck, ດັ່ງນັ້ນຈຶ່ງຈຳເປັນຕ້ອງອອກແບບໂດຍໃຊ້ Batch Inference Framework ເຊັ່ນ vLLM ເພື່ອຮັບປະກັນ Throughput. ເນື່ອງຈາກ Latency ຕົວຈິງຈະປ່ຽນແປງຢ່າງຫຼວງຫຼາຍຕາມ Model, Quantization, ຄວາມຍາວຂອງ Prompt ແລະ Batch Size, ຈຶ່ງແນະນຳໃຫ້ວັດແທກໃນສະພາບແວດລ້ອມຂອງຕົນເອງ ແທນທີ່ຈະອ້າງອີງຄ່າ Benchmark.

ບັນທຶກຜົນງານຈາກການໃຊ້ງານຕົວຈິງກຳລັງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຜ່ານລາຍງານກໍລະນີສຶກສາຈາກຊຸມຊົນ Open Source ແລະ ຜູ້ໃຫ້ບໍລິການ Cloud. ຂໍ້ຄວນລະວັງຫຼັກໆ ໃນການນຳ SLM ທີ່ຜ່ານການ Fine-tuning ດ້ວຍ QLoRA ໄປໃຊ້ງານຕົວຈິງມີຢູ່ 2 ຂໍ້. ຂໍ້ທຳອິດຄືການຄຸ້ມຄອງຄຸນນະພາບຂອງຂໍ້ມູນຝຶກສອນ ເນື່ອງຈາກການຝຶກດ້ວຍຂໍ້ມູນທີ່ມີ Noise ຫຼາຍອາດເຮັດໃຫ້ເກີດ "Catastrophic Forgetting" ຊຶ່ງເປັນສະພາວະທີ່ປະສິດທິພາບທົ່ວໄປຂອງໂມເດລຊຸດລົງ. ຂໍ້ທີສອງຄືການຈັດການ Version ຂອງ LoRA Adapter ອາແດັບເຕີ ຫຼື ສ່ວນເສີມ ເນື່ອງຈາກເມື່ອມີການອັບເດດ Base Model ຈະຕ້ອງທຳການຝຶກ Adapter ໃໝ່ອີກຄັ້ງ. ລາຍລະອຽດທາງເທັກນິກຂອງການ Fine-tuning ໄດ້ອະທິບາຍໄວ້ໃນ ບົດຄວາມແນະນຳ PEFT.

ການຕັດສິນໃຈນຳໃຊ້ Local LLM / SLM ຂຶ້ນຢູ່ກັບ 3 ປັດໃຈຫຼັກ ຄື: "ຂໍ້ກຳນົດດ້ານອຳນາດອະທິປະໄຕຂໍ້ມູນ", "ປະລິມານ Token ຕໍ່ເດືອນ", ແລະ "ຄວາມຊັບຊ້ອນຂອງວຽກງານ". ການປາກົດຕົວຂອງ GPT OSS ເຮັດໃຫ້ການຕັດສິນໃຈນີ້ງ່າຍດາຍຂຶ້ນອີກຂັ້ນໜຶ່ງ. ຫາກມີຂໍ້ຈຳກັດທີ່ບໍ່ສາມາດສົ່ງຂໍ້ມູນໄປຍັງ Cloud ໄດ້ ແລະ ຕ້ອງການປະມວນຜົນ Token ຫຼາຍກວ່າ 5 ລ້ານຕໍ່ເດືອນ, ກໍ່ສາມາດໃຊ້ GPT OSS 20B (RTX 4090) ຫຼື GPT OSS 120B (H100) ເພື່ອໃຫ້ໄດ້ຄວາມແມ່ນຍຳທຽບເທົ່າ o3-mini / o4-mini ຂອງ Cloud API ໃນລະດັບ Local ໄດ້.

ໃຫ້ເລີ່ມຕົ້ນທົດສອບໃນຂະໜາດນ້ອຍດ້ວຍ Ollama + GPT OSS 20B ກ່ອນ, ຫາກພໍໃຈກັບຄວາມແມ່ນຍຳແລ້ວ ຈຶ່ງໃຊ້ QLoRA ເພື່ອ Fine-tune ໃຫ້ເໝາະສົມກັບຂໍ້ມູນຂອງອົງກອນ, ຈາກນັ້ນຈຶ່ງນຳໄປໃຫ້ບໍລິການຜ່ານ vLLM. ການດຳເນີນຕາມຂັ້ນຕອນນີ້ຈະຊ່ວຍໃຫ້ສາມາດຮັກສາອຳນາດອະທິປະໄຕຂໍ້ມູນ ແລະ ເພີ່ມປະສິດທິພາບດ້ານຕົ້ນທຶນໄດ້ພ້ອມກັນ ໂດຍຮັກສາການລົງທຶນເບື້ອງຕົ້ນໃຫ້ຢູ່ໃນລະດັບຕ່ຳທີ່ສຸດ.