LLM Quantization คืออะไร? ลดต้นทุน AI ให้ SME ไทยด้วยการรันโมเดลบนเครื่องตัวเอง

LLM Quantization คือเทคนิคการลดความละเอียดของตัวเลขที่ใช้เก็บน้ำหนักโมเดลภาษาศาสตร์ จากรูปแบบ 16 บิตที่แม่นยำสูงให้เหลือ 8 บิตหรือ 4 บิต ผลลัพธ์คือโมเดลขนาด 70B ที่เคยต้องใช้การ์ดจอหลายใบอาจรันบนเครื่องเดียวได้ และโมเดลขนาด 8B อาจรันบนโน้ตบุ๊กที่มีหน่วยความจำ 16 GB สำหรับ SME ไทยที่ต้องจ่ายค่า API ทุกเดือนและกังวลเรื่องข้อมูลลูกค้าออกจากองค์กร เทคนิคนี้คือทางเลือกที่ทำให้ AI กลายเป็นต้นทุนคงที่ที่ควบคุมได้ แทนที่จะเป็นค่าใช้จ่ายผันแปรที่เพิ่มตามปริมาณการใช้

LLM Quantization ทำงานอย่างไร

โมเดลภาษาศาสตร์สมัยใหม่เก็บค่าตัวเลขหลายพันล้านค่าที่เรียกว่าน้ำหนัก โดยทั่วไปอยู่ในรูปแบบทศนิยม 16 บิต (FP16) ซึ่งแต่ละค่ากินพื้นที่ 2 ไบต์ ตัวเลขเหล่านี้ไม่ได้ต้องใช้ความละเอียดสูงขนาดนั้นเสมอไป เพราะอิทธิพลของแต่ละค่าต่อคำตอบสุดท้ายมีน้อยมากเมื่อเทียบกับค่าอื่นอีกนับพันล้านค่า

Quantization จึงทำการแปลงช่วงค่าที่ต่อเนื่องให้กลายเป็นขั้นบันไดที่มีจำนวนระดับจำกัด เช่น INT8 ที่มี 256 ระดับ หรือ INT4 ที่มีเพียง 16 ระดับ แล้วจับคู่ค่าที่ใกล้ที่สุดเข้าด้วยกัน ขั้นตอนสำคัญคือการหาช่วงค่าที่เหมาะสมต่อกลุ่มน้ำหนักแต่ละกลุ่ม ถ้าช่วงกว้างเกินไปจะเสียความละเอียด ถ้าแคบเกินไปค่าที่อยู่นอกช่วงจะถูกตัดทิ้ง

ผลที่ได้คือไฟล์โมเดลเล็กลงประมาณ 2 เท่าสำหรับ INT8 และประมาณ 4 เท่าสำหรับ INT4 เมื่อเทียบกับ FP16 ยกตัวอย่างโมเดล 8B ที่ปกติกินพื้นที่ราว 16 GB จะเหลือราว 8 GB และ 4 ถึง 5 GB ตามลำดับ ตัวเลขนี้เป็นค่าประมาณจากเอกสารผู้ให้บริการ ผลจริงขึ้นกับบริบทและวิธีที่ใช้อัด ข้อดีอีกอย่างที่มักถูกมองข้ามคือความเร็ว เพราะการอ่านข้อมูลจากหน่วยความจำน้อยลงทำให้โมเดลตอบเร็วขึ้นในงานที่คอขวดอยู่ที่แบนด์วิดท์หน่วยความจำ

ทำไม SME ไทยถึงควรสนใจตอนนี้

ค่าใช้จ่าย AI ในรูปแบบ API คิดตามจำนวนโทเคน แปลว่ายิ่งธุรกิจเติบโตและยิ่งมีลูกค้าทักเข้ามามาก ต้นทุนก็ยิ่งสูงตามแบบไม่มีเพดาน ธุรกิจบริการที่มีแชทลูกค้าหลักล้านโทเคนต่อเดือนอาจพบว่าค่า API แซงค่าจ้างพนักงานไปแล้ว ในขณะที่การรันโมเดลเองมีต้นทุนส่วนเพิ่มใกล้ศูนย์เมื่อฮาร์ดแวร์ลงทุนไปแล้ว

เหตุผลที่สองคือข้อมูล ร้านค้าออนไลน์และคลินิกความงามมักมีข้อความที่ลูกค้าเล่ารายละเอียดส่วนตัว ประวัติการรักษา หรือข้อมูลการชำระเงิน การส่งข้อความเหล่านี้ไปยัง API ภายนอกต้องมีสัญญาประมวลผลข้อมูลและสร้างความมั่นใจให้ลูกค้า ขณะที่การรันบนเครื่องในออฟฟิศทำให้ข้อมูลไม่ต้องออกจากองค์กรเลย ซึ่งลดทั้งความเสี่ยงและภาระด้านเอกสาร

เหตุผลที่สามคือความเป็นอิสระทางเทคนิค ผู้ให้บริการ API อาจเปลี่ยนราคา เปลี่ยนเงื่อนไขการใช้งาน หรือยกเลิกรุ่นโมเดลที่ธุรกิจพึ่งพาอยู่ เมื่อมีโมเดลที่รันเองในองค์กร ธุรกิจยังทำงานต่อได้และสลับกลับไปใช้ API เฉพาะงานที่ยากจริง ๆ ได้ เป็นการกระจายความเสี่ยงที่ไม่ผูกขาดกับผู้ให้บริการรายใดรายหนึ่ง

FP16, INT8 และ INT4 ต่างกันแค่ไหนต่อคุณภาพภาษาไทย

การเทียบตัวเลขในตารางช่วยให้เห็นภาพ แต่สิ่งที่ตัดสินใจจริงคือคุณภาพคำตอบที่ยอมรับได้

ตัวเลขขนาดเป็นค่าประมาณจากเอกสารผู้ให้บริการ ผลจริงขึ้นกับบริบท จำนวนเลเยอร์ และความยาวบริบทที่ใช้งาน

สำหรับภาษาไทยมีจุดที่ต้องระวังเป็นพิเศษ ภาษาไทยไม่มีการเว้นวรรคระหว่างคำ และตัวตัดคำของโมเดลจำนวนมากใช้โทเคนต่อข้อความมากกว่าภาษาอังกฤษเมื่อเทียบเนื้อหาเท่ากัน เมื่อใช้ INT4 ความคลาดเคลื่อนเล็ก ๆ มีโอกาสสะสมจนทำให้คำที่คล้ายกันถูกสลับ หรือทำให้รูปประโยคผิดไวยากรณ์ในจุดที่โมเดล FP16 ไม่ผิด

แนวทางปฏิบัติคือถ้างานนั้นผิดพลาดไม่ได้ เช่น การสรุปสัญญาหรือร่างจดหมายถึงลูกค้า ให้ใช้ INT8 หรือ INT4 ในขนาดโมเดลที่ใหญ่ขึ้นแทนการลดบิตในโมเดลเล็ก เพราะโมเดลใหญ่ที่อัดแน่นมักให้คุณภาพดีกว่า�โมเดลเล็กที่ไม่ผ่านการอัดในราคาหน่วยความจำใกล้กัน

GPTQ, AWQ, GGUF และ bitsandbytes ควรเลือกแบบไหน

GPTQ เป็นวิธีอัดแบบหลังการฝึกที่ได้รับความนิยมบน GPU รองรับใน vLLM และ Hugging Face อย่างกว้างขวาง ให้ไฟล์ขนาด 4 บิตที่รันเร็ว แลกมาด้วยความยุ่งยากในการปรับแต่งพารามิเตอร์ตอนอัด เหมาะกับงานที่ต้องเสิร์ฟผู้ใช้หลายคนบนการ์ดจอ

AWQ ใช้แนวคิดว่าค่าน้ำหนักบางค่าไวต่อคุณภาพมากกว่าค่าอื่น จึงให้น้ำหนักความสำคัญกับช่องทางเหล่านั้นเป็นพิเศษ ผู้ใช้จำนวนมากรายงานว่าคุณภาพภาษาใกล้ต้นฉบับกว่า GPTQ ในระดับบิตเท่ากัน (ผลจริงขึ้นกับบริบทและโมเดล) ถ้าใช้ vLLM เป็นหลัก AWQ มักเป็นตัวเลือกแรกที่ควรลอง

GGUF คือรูปแบบไฟล์ของฝั่ง llama.cpp ที่ออกแบบมาให้รันบน CPU และหน่วยความจำรวมได้ดี รองรับการผสมระหว่าง CPU และ GPU และมีหลายระดับบิตให้เลือก เช่น Q4_K_M หรือ Q5_K_M เหมาะกับ SME ที่ยังไม่มีการ์ดจอแรงและต้องการรันบน Mac หรือเซิร์ฟเวอร์ CPU

bitsandbytes เน้นความสะดวก ตั้งค่าน้อยและทำงานร่วมกับ Hugging Face Transformers ได้ทันที มักใช้ในงาน QLoRA ซึ่งเป็นการปรับจูนโมเดลแบบประหยัดหน่วยความจำ ข้อจำกัดคือ throughput ต่ำกว่า GPTQ และ AWQ เมื่อต้องรับผู้ใช้พร้อมกันมาก

หลักเลือกแบบง่ายคือ เริ่มด้วย GGUF ถ้ารันบนคอมพิวเตอร์ทั่วไปหรือ Mac, เลือก AWQ หรือ GPTQ ถ้าเสิร์ฟบน GPU ด้วย vLLM, และใช้ bitsandbytes เมื่อต้องการปรับจูนโมเดลให้เชี่ยวชาญงานเฉพาะ

ฮาร์ดแวร์และงบประมาณที่เหมาะกับ SME ไทย

เครื่องที่ใช้ชิป Apple M-series เป็นทางเลือกที่คุ้มค่าสำหรับ SME เพราะใช้หน่วยความจำรวมที่ทั้ง CPU และ GPU เข้าถึงได้ รุ่นที่มีหน่วยความจำ 16 GB รันโมเดล 7B ถึง 8B แบบ INT4 ได้สบาย รุ่น 32 GB ขึ้นไปเริ่มรันโมเดล 14B ถึง 30B ได้ และรุ่น 64 GB เปิดทางให้ลองโมเดลขนาดใหญ่ขึ้น จุดเด่นคือกินไฟต่ำและเงียบ เหมาะกับออฟฟิศขนาดเล็ก

ฝั่งการ์ดจอแยกอย่าง NVIDIA การ์ดหน่วยความจำ 12 GB รันโมเดล 8B INT4 ได้ การ์ด 24 GB รองรับโมเดล 14B ถึง 30B แบบ INT4 และเหมาะกับการรับผู้ใช้พร้อมกันหลายคนผ่าน vLLM ข้อควรระวังคือเครื่องที่ประกอบเองต้องมี RAM และ power supply ที่เพียงพอ และค่าไฟของเซิร์ฟเวอร์ที่เปิดตลอดวันต้องถูกคิดเข้าไปในต้นทุนจริง

NPU ในชิปโน้ตบุ๊กรุ่นใหม่กำลังพัฒนาอย่างรวดเร็วและช่วยเร่งงาน AI ได้ดีในบางสถานการณ์ แต่ระบบนิเวศของเครื่องมือยังไม่กว้างเท่า GPU และการรองรับโมเดลภาษาไทยยังต้องทดสอบเป็นรายกรณี ถ้าเป้าหมายคือเริ่มใช้งานจริงเร็ว ควรเลือกเส้นทาง GGUF บน Mac หรือการ์ดจอ NVIDIA ที่ชุมชนใหญ่และแก้ปัญหาง่ายกว่า

อีกทางเลือกที่ควรพิจารณาคือ GPU บนคลาวด์ แบบเช่าตามชั่วโมง เหมาะกับช่วงทดลองหรือโปรเจกต์ที่มีโหลดไม่สม่ำเสมอ ช่วยให้ทดสอบขนาดโมเดลต่าง ๆ ได้โดยไม่ต้องซื้อฮาร์ดแวร์ แต่ถ้าองค์กรมีข้อกำหนดว่าข้อมูลต้องไม่ออกนอกสถานที่ ทางนี้จะใช้ไม่ได้กับงานที่แตะข้อมูลลูกค้า

เริ่มต้นใช้งานจริงกับ Ollama และ vLLM

Ollama เป็นจุดเริ่มต้นที่เร็วที่สุดในการทดลอง หลังติดตั้งแล้วสามารถดึงโมเดลแบบ GGUF มาทดสอบได้ทันที

ollama pull llama3.1:8b-instruct-q4_K_M
ollama run llama3.1:8b-instruct-q4_K_M

เมื่อทดสอบแล้วพอใจ สามารถเปิดเป็น API ให้ระบบหลังบ้านเรียกใช้ได้ด้วยคำสั่ง ollama serve ซึ่งจะเปิด endpoint ที่พอร์ต 8000 ในเครื่อง และเรียกผ่าน HTTP ได้จากแอปภายในองค์กร

สำหรับการใช้งานจริงในระดับที่ต้องรับผู้ใช้พร้อมกันหลายคน vLLM ให้ throughput ที่สูงกว่าอย่างชัดเจน เพราะมี continuous batching และ PagedAttention ที่จัดการหน่วยความจำของ KV Cache ได้มีประสิทธิภาพ

pip install vllm
vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \\
  --quantization awq \\
  --max-model-len 8192 \\
  --gpu-memory-utilization 0.90

จุดสำคัญที่ต้องตั้งให้ถูกคือความยาวบริบทสูงสุด เพราะยิ่งตั้งสูง หน่วยความจำที่เหลือให้ผู้ใช้พร้อมกันจะยิ่งน้อยลง และต้องทดสอบว่าคุณภาพภาษาไทยยังอยู่ในเกณฑ์ที่ยอมรับได้หลังสลับมาใช้เวอร์ชัน Quantized

ข้อควรระวังด้านคุณภาพ การอัปเดต และ PDPA

คุณภาพที่ลดลงแบบไม่ชัดเจน เป็นความเสี่ยงที่อันตรายที่สุด เพราะโมเดลอาจตอบถูกในภาพรวมแต่ผิดรายละเอียด เช่น ตัวเลขในใบเสนอราคาหรือชื่อยา ควรมีขั้นตอนตรวจทานสำหรับงานที่กระทบเงินหรือความปลอดภัย และเก็บชุดคำถามทดสอบไว้ใช้ซ้ำทุกครั้งที่เปลี่ยนโมเดล

การอัปเดต ควรทำเป็นรอบ มีเวอร์ชันคู่ขนาน และเก็บผลการทดสอบก่อนและหลังเปลี่ยน เพื่อไม่ให้คุณภาพตกลงโดยไม่มีใครรู้ และควรจดบันทึกว่ารุ่นไหนใช้วิธีอัดแบบใด เพราะการเปลี่ยนวิธีอัดอาจให้ผลต่างกันแม้ใช้โมเดลต้นทางเดียวกัน

ด้าน PDPA การรันบนเครื่องตัวเองช่วยลดความเสี่ยงจากการส่งข้อมูลออกนอกองค์กร แต่ไม่ได้ยกเว้นหน้าที่ตามกฎหมาย องค์กรยังต้องมีมาตรการรักษาความมั่นคงปลอดภัย จำกัดสิทธิ์การเข้าถึง บันทึกการใช้งาน กำหนดระยะเวลาเก็บรักษา และลบข้อมูลเมื่อหมดความจำเป็น รวมถึงแจ้งวัตถุประสงค์การประมวลผลต่อเจ้าของข้อมูลอย่างชัดเจน

สุดท้ายคือ ต้นทุนแฝง ทั้งค่าไฟ ค่าเสื่อมฮาร์ดแวร์ เวลาของทีม IT ในการดูแลระบบ และเวลาที่ใช้ทดสอบคุณภาพ ต้นทุนเหล่านี้มักถูกมองข้ามตอนเปรียบเทียบกับค่า API แต่เป็นส่วนที่ทำให้การประเมินจุดคุ้มทุนแม่นยำขึ้นมาก

สรุป

LLM Quantization ทำให้ SME ไทยมีทางเลือกที่ไม่ต้องพึ่ง API ภายนอกตลอดไป โดยเริ่มจากทดลองโมเดล 8B แบบ INT4 บนเครื่องที่มีอยู่ก่อน แล้ววัดผลด้วยชุดคำถามภาษาไทยของธุรกิจเอง ถ้าคุณภาพผ่านเกณฑ์จึงค่อยขยายไปยังโมเดลใหญ่ขึ้นหรือลงทุนฮาร์ดแวร์เพิ่ม วิธีที่ปลอดภัยที่สุดคือทำเวอร์ชันคู่ขนานระหว่าง API กับโมเดลในองค์กร แล้วทยอยย้ายงานที่มั่นใจก่อน เพื่อให้ได้ทั้งการลดต้นทุนและการควบคุมข้อมูลโดยไม่แลกกับคุณภาพที่ลูกค้ารู้สึกได้