โมเดลที่เก่งสุด มักเป็นตัวที่ผิดงาน

ตอนเราจะเอา local LLM มารันเองสักตัว คำถามแรกที่ผุดขึ้นมาคือ "ตัวไหนเก่งสุด" เปิดตาราง benchmark ดู คะแนน coding ใครสูงก็เล็งตัวนั้นไว้ก่อน

แต่พอลงมือเทสต์จริง ตัวที่ benchmark สวยกลับไม่ใช่ตัวที่ใช้ได้ งานที่เราจะให้มันทำคือคุยภาษาไทยกับคนในทีม ไม่ใช่เขียน LeetCode คะแนน coding สูงลิ่วเลยแทบไม่ได้บอกอะไรเลยว่ามันจะคุยไทยรู้เรื่องไหม

ตรงนี้แหละที่ทำให้เก็ตว่า เราถามผิดข้อมาตั้งแต่ต้น คำถามไม่ใช่ "ตัวไหนเก่งสุด" แต่เป็น "งานเราคืออะไร แล้วตัวไหนตรงงานนั้น"

ช่วงที่ 1เลือกตามงาน ไม่ใช่ตาม benchmark

benchmark ตอบได้แค่ "เก่งอะไร" แต่ตอบไม่ได้ว่า "ตรงงานเราไหม" สองอันนี้คนละเรื่อง โมเดลที่ทำคะแนน coding สูง อาจอ่อนภาษาไทย ส่วนโมเดลที่ generalist เก่ง อาจ tool-calling ไม่แม่น

ก่อนจะดูว่าตัวไหนเก่ง ลองตอบ 4 ข้อนี้ก่อน

1. งานคืออะไร เขียนโค้ด คุยกับคนแบบมีบุคลิกคงที่ หรือ reasoning ยาว ๆ
2. ภาษาอะไร ถ้างานเป็นไทย ตรงนี้สำคัญกว่าคะแนน coding เพราะ benchmark ส่วนใหญ่วัดด้วยอังกฤษ ไม่ได้บอกเลยว่าไทยจะรู้เรื่องแค่ไหน
3. ข้อมูลออก cloud ได้ไหม ถ้าข้อมูลอ่อนไหว ออกไม่ได้ ก็เหลือทาง local อย่างเดียว privacy เลยเป็นเกณฑ์ ไม่ใช่ของแถม
4. failure แบบไหนที่เรารับได้ บางโมเดลแม่นตอนป้อน fact ให้ แต่มั่วตอนให้เดาเอง ถ้างานเรามี fact ป้อนให้อยู่แล้ว จุดอ่อนนั้นก็ไม่ใช่ปัญหา

พอเรียงคำถามแบบนี้ "ตัวเก่งสุด" มักร่วงตั้งแต่ข้อ 2 หรือ 3

ช่วงที่ 2ของจริงที่เทียบ: Qwen กับ Gemma

ตอนเลือกจริง เราเหลือสองตัวมาวัดกัน Qwen3.6 กับ Gemma 4 ทั้งคู่ขนาดกลาง รันบนเครื่องตัวเองได้ license เปิดเหมือนกัน (Apache 2.0)

เคสเรา งานคือผู้ช่วย AI ประจำทีมที่คุยกันเป็นภาษาไทย เกณฑ์เลยมีสามอย่าง คุยไทยให้เป็นธรรมชาติ รักษาบุคลิกให้คงเส้นคงวา (โทนและวิธีพูดที่สม่ำเสมอ ฝรั่งเรียก persona) และ ข้อมูลในแชตทีมเป็นเรื่องภายใน ไม่อยากส่งออก cloud พอวัดด้วยสามข้อนี้ Qwen ชนะ ไม่ใช่เพราะ coding (ทั้งคู่ก็พอใช้) แต่เพราะภาษาเอเชีย Qwen ทำได้ดีกว่าชัด ทั้งที่ถ้าดูแค่ตาราง benchmark รวม ๆ สองตัวสูสีกันมาก

อันนี้คือบทเรียนทั้งหมดในประโยคเดียว benchmark สูสี แต่พอผูกกับงานจริง ตัวที่ตรงงานชนะขาด

ส่วนพวก flagship อย่าง GLM-5.2 หรือ Kimi K2.7 เก่ง coding ระดับโลกก็จริง แต่ตัวใหญ่หลักร้อยถึงพันพันล้านพารามิเตอร์ รันเองบนเครื่องทั่วไปไม่ไหว แล้วถ้าไปใช้ผ่าน cloud ก็เสีย privacy ที่เป็นเหตุผลตั้งต้นของการทำ local ตั้งแต่แรก เก่งสุดในโลก แต่ผิดงานที่ต้องอยู่บนเครื่องเราต่างหาก

ช่วงที่ 3ศัพท์ที่เจอ แปลว่าอะไรตอนใช้จริง

เวลาอ่าน spec จะเจอคำพวกนี้เต็มไปหมด ขอแปลเป็นภาษาคนทีละคำ เพราะแต่ละคำผูกกับข้อจำกัดเครื่องคนละแบบ

QAT: ฝึกมาให้ทนการบีบ

โมเดลก็คือก้อนตัวเลข (เรียกว่า weight) จำนวนมหาศาลที่เก็บไว้แบบละเอียด ก้อนเลยใหญ่ การ "บีบ" (quantize) คือลดความละเอียดของตัวเลขพวกนี้ลง เช่นจาก 16-bit เหลือ 4-bit ไฟล์โมเดลเลยเล็กลงจนรันบนเครื่องเล็กได้ วิธีเดิมคือเทรนโมเดลจนเสร็จก่อน แล้วค่อยบีบทีหลัง คุณภาพเลยหล่นลงหน่อยเพราะโมเดลไม่เคยชินกับการถูกบีบ ส่วน QAT (quantization-aware training) จำลองการบีบนี้เข้าไปตั้งแต่ตอนเทรน โมเดลเลยเรียนรู้ที่จะทนการบีบไปด้วย พอบีบจริงคุณภาพเลยใกล้ของเต็ม ในขนาดไฟล์ที่เล็กพอ ๆ กัน (Google)

MTP: ทำนายหลายคำพร้อมกัน

เวลาโมเดลสร้างข้อความ มันทำนายทีละคำ และคำถัดไปต้องรอให้คำก่อนหน้าออกมาก่อนเสมอ เพราะมันเดาคำต่อไปจากคำที่ออกมาแล้ว การไล่ทีละคำต่อกันเป็นทอด ๆ แบบนี้แหละคือคอขวดของความเร็ว MTP (multi-token prediction) เทรนให้โมเดลทำนายหลายคำล่วงหน้าพร้อมกัน แล้วค่อยตรวจทีเดียวว่าเดาถูกกี่คำ ผลคือสร้างข้อความได้เร็วขึ้นโดยความแม่นไม่ตก แต่มีกับดัก ความเร็วของ MTP มาจากการเดาเผื่อหลายคำแล้วตรวจพร้อมกันทีเดียว ซึ่ง GPU ทำได้แทบฟรีเพราะมันถนัดคำนวณขนานทีละมาก ๆ ส่วน CPU ทำงานแบบไล่ทีละชิ้น ต่อให้เดาเผื่อมาก็ต้องมานั่งตรวจทีละคำอยู่ดี ประโยชน์เลยแทบหาย พูดง่าย ๆ คือ MTP คุ้มก็ต่อเมื่อมี GPU (Gloeckle et al., 2024)

dense กับ MoE: active params กับ total params

ก่อนอื่น พารามิเตอร์ (parameter) ก็คือ weight ก้อนตัวเลขในโมเดลที่พูดถึงไปเมื่อกี้ ยิ่งมีเยอะโมเดลยิ่งเก่ง แต่ก็ยิ่งกินทรัพยากร ทีนี้มีสองวิธีจัดการมัน แบบ dense คือทุกครั้งที่โมเดลออกหนึ่งคำ มันใช้พารามิเตอร์ทุกตัวที่มี ส่วนแบบ MoE (mixture of experts) แบ่งพารามิเตอร์เป็นกลุ่มผู้เชี่ยวชาญหลายกลุ่ม แต่ละคำเรียกใช้แค่บางกลุ่ม ตัวที่รวมกันได้ 671B เลยใช้จริงแค่ 37B ต่อคำ จุดที่คนเข้าใจผิดบ่อยคือ active params (ที่ใช้จริงต่อคำ) = ความเร็วและแรงประมวลผล แต่ total params (ทั้งหมด) = RAM ที่ต้องโหลด เพราะ MoE ต้องโหลด weight ทั้งก้อนเข้าเครื่องไว้ก่อน ถึงเวลาใช้จะหยิบแค่บางกลุ่ม ก็ยังกิน RAM เท่าตัวเต็มอยู่ดี (Mixtral · HuggingFace)

ช่วงที่ 4GPU กับ RAM เป็นด่านสุดท้าย

พอรู้ว่างานต้องการตัวไหนแล้ว ค่อยเอาข้อจำกัดของเครื่องมากรอง ว่า RAM พอไหม มี GPU ไหม ต้องบีบระดับไหนถึงจะลงเครื่องได้

ลำดับนี้สำคัญ ถ้าเริ่มจากเครื่องก่อน ("เรามี RAM เท่านี้ เอาตัวที่ลงได้") เราจะตัดตัวที่ตรงงานทิ้งไปโดยไม่ทันคิด แต่ถ้าเริ่มจากงานก่อน เครื่องเป็นแค่ตัวบอกว่า "เวอร์ชันไหน บีบแค่ไหน" ของโมเดลที่เลือกไว้แล้ว ไม่ใช่ตัวเลือกโมเดลแทนเรา

เพดานเครื่องกำหนดขนาดที่รันได้จริง แต่ไม่ควรกำหนดว่างานเราคืออะไร

สรุปหลักคิดสั้น ๆ เอาไปใช้ได้เลย เวลาจะเลือก local LLM อย่าเปิด benchmark เป็นอย่างแรก เปิดคำถามว่า "งานคืออะไร ภาษาอะไร ข้อมูลออก cloud ได้ไหม รับ failure แบบไหนได้" สี่ข้อนี้ตอบก่อน แล้วค่อยเอา benchmark กับข้อจำกัดเครื่องมากรองทีหลัง

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