LLM 14 ตัว เงินก้อนเดียว แบ่งงานยังไง ให้ถูกตัว

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

พอไล่ดูว่าเงินก้อนนั้นเลี้ยงอะไรอยู่บ้าง ก็เจอความจริงที่ขำไม่ออก ในระบบของเรามีโมเดลภาษาที่เกี่ยวข้องอยู่ 14 ตัว ตั้งแต่โมเดลเรือธงที่คุยด้วยทุกวัน ไปจนถึงโมเดลจิ๋ว 0.6B ที่รันเงียบ ๆ บนเซิร์ฟเวอร์ราคาถูก บางตัวทำงานหนักทุกวัน บางตัวถูกตั้งค่าไว้แล้วไม่เคยถูกเรียกเลยสักครั้ง เหมือนบ้านที่เปิดไฟทิ้งไว้ทุกดวง แต่บิลค่าไฟมาใบเดียว ไม่มีทางรู้เลยว่าดวงไหนกินไฟ ถ้าไม่ไล่ดูทีละดวง

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

ช่วงที่ 1ใช้ LLM กี่ตัว แล้วแต่ละตัวทำหน้าที่อะไร

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

ในชั้นเหมาจ่าย แต่ละระดับของ Claude ก็แบ่งงานกันอีกที ตัวท็อปสุด (Fable ซึ่งเป็นระดับที่อยู่เหนือ Opus) รับบท orchestrator คือเป็นหัวหน้าทีมที่วางแผน แตกงาน และเรียบเรียงผลรวม ระดับรองลงมา (Opus) รับโจทย์ที่ต้องคิดลึกเป็นจุด ๆ ระดับกลาง (Sonnet) คือแรงงานหลักที่ทำงานตามสั่งได้เร็ว และระดับเล็กสุด (Haiku) รับงานกวาดตรวจซ้ำ ๆ ที่วนมาทุกไม่กี่ชั่วโมง ส่วน Codex รับบทเพื่อนร่วมทีมสายถึก คืองานเขียนโค้ดยาว ๆ ที่กินเวลาเป็นชั่วโมง โยนให้มันทำแล้วค่อยกลับมารีวิว

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

ช่วงที่ 2งานแบบไหนควรลงโมเดลไหน

ตอบสั้นที่สุด งานที่ถึงมือคนอ่านลงโมเดลคุณภาพสูงสุด งานที่เครื่องคุยกันเองลงโมเดลกลาง งานปริมาณมากที่พลาดได้ลงโมเดลฟรี ที่เหลือคือรายละเอียดของกติกาสามข้อ

ข้อ 1 งานถึงมือคน ห้ามลดเกรด

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

ข้อ 2 เรียงบันไดจากของที่จ่ายแล้ว

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

ข้อ 3 มีตัวสำรองที่สลับเองได้ และต้องเคยเห็นมันทำงานจริง

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

ช่วงที่ 3สามบทเรียนจากการรื้อระบบจริง

บทเรียน 1 ค่าที่ตั้งไว้ ไม่เท่ากับค่าที่รันจริง

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

บทเรียน 2 ตัวเผาเงินคือบริบท ไม่ใช่จำนวนครั้ง

ก่อนรื้อ เรานึกว่าจะไปลดจำนวนครั้งที่เรียกโมเดล พอวัดจริงเจ็ดวัน (เรียกทั้งหมด 440 ครั้ง) กลับพบว่า token ฝั่งอ่านบริบทซ้ำมากกว่าฝั่งเขียนคำตอบราว 80 เท่า เพราะบทสนทนาที่เปิดค้างไว้ยาว ทุกข้อความใหม่ต้องอ่านประวัติทั้งก้อนซ้ำอีกรอบ ยิ่งคุยยาว ยิ่งแพงขึ้นเรื่อย ๆ แบบเงียบ ๆ ทางแก้ที่ได้ผลจึงไม่ใช่เปลี่ยนโมเดล แต่คือตัดรอบบทสนทนาให้สั้นลง จากเพดาน 30 ข้อความต่อรอบเหลือ 12 แล้วให้ระบบเริ่มรอบใหม่โดยสรุปเรื่องเดิมติดมือมาด้วย แลกความจำยาวกับต้นทุนที่คุมได้

บทเรียน 3 วัดก่อนตัด เพราะตัวที่คิดว่าผิด มักไม่ใช่

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

ช่วงที่ 4เริ่มกับระบบของคุณยังไง

ไม่ต้องมี 14 โมเดลถึงจะเริ่มได้ มีสองตัวก็เริ่มได้แล้ว ลำดับที่แนะนำเป็นแบบนี้

1. ทำทะเบียนโมเดล ลิสต์ทุกโมเดลและทุกบริการ AI ที่จ่ายเงินหรือรันอยู่ ใส่สามคอลัมน์ ชื่อ ที่มาของเงิน และงานที่มันรับ ตัวไหนตอบคอลัมน์สามไม่ได้ นั่นคือผู้ต้องสงสัยรายแรก
2. วัดการใช้จริงสักหนึ่งสัปดาห์ ก่อนเปลี่ยนอะไรทั้งนั้น ดูว่า token หมดไปกับอะไร ของเราคำตอบคือการอ่านบริบทซ้ำ ของคุณอาจเป็นอย่างอื่น แต่ต้องรู้จากตัวเลข ไม่ใช่จากความรู้สึก
3. ขีดเส้นคุณภาพ เขียนให้ชัดว่างานประเภทไหนห้ามลดเกรดเด็ดขาด แล้วงานที่เหลือค่อยหาโมเดลที่ถูกลงมารับ
4. เปลี่ยนทีละอย่าง และพิสูจน์ว่าสวิตช์ทำงานจริง ทุกครั้งที่ย้ายงานลงโมเดลใหม่หรือเพิ่มตัวสำรอง ทดสอบให้เห็นว่ามันถูกเรียกใช้จริง อย่าเชื่อไฟล์ตั้งค่า (บทเรียน 1 รออยู่)

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