เลือกรุ่น AI ให้ถูกงาน: คุมต้นทุน LLM โดยไม่ลดคุณภาพ

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

ทำไมต้นทุน LLM บานง่ายเมื่อเริ่ม automate

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

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

สิ่งที่ดันต้นทุนให้บานมีไม่กี่อย่าง รู้ไว้แล้วคุมง่ายขึ้นมาก:

• จำนวนครั้งที่เรียกโมเดลต่อหนึ่งรอบงาน (ยิ่ง automate ยิ่งเยอะ)
• ขนาด context ที่ส่งเข้าไปทุกครั้ง (ประวัติยาว ไฟล์ใหญ่)
• การเลือกรุ่นแพงกับทุกขั้นตอนแบบไม่แยกความยากของงาน

หลักเลือกรุ่นตามความยากของงาน: Haiku → Sonnet → Opus

หลักที่ผมยึดง่ายมาก — เริ่มจากรุ่นเล็กที่สุดที่ทำงานนั้นได้ แล้วค่อยขยับขึ้นเมื่อจำเป็นจริง ๆ ไม่ใช่เริ่มจากรุ่นใหญ่แล้วค่อยลด เพราะทิศทางประหยัดต้นทุนคือ Opus → Sonnet → Haiku โดย Haiku ถูกที่สุด

แบ่งงานคร่าว ๆ ตามนี้ก็ครอบคลุมเกือบหมด:

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

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

ความเข้าใจผิด "รุ่นแพง = ดีเสมอ" และเรื่องของ Fable

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

จุดที่ต้องระวังเป็นพิเศษคือ Fable หลายคนเดาจากชื่อว่ามันเป็นรุ่นทางเลือกราคาประหยัด แต่ในความเป็นจริง Fable เป็นรุ่น พรีเมียม ที่แพงกว่าตระกูล Opus ด้วยซ้ำ มันถูกออกแบบมาสำหรับงานที่ยากและยาวที่สุด ไม่ใช่ตัวลดต้นทุน ถ้าใครแนะนำให้สลับไปใช้ Fable เพื่อ "ประหยัด" นั่นคือเข้าใจผิดชัด ๆ — ทิศทางประหยัดยังคงเป็นไล่ลงไปทาง Haiku เสมอ

สรุปหลักคิดสั้น ๆ ที่ผมใช้:

• เลือกรุ่นให้ "เหมาะกับงาน" ไม่ใช่ "เหมาแพงไว้ก่อน"
• รุ่นแพงคุ้มเฉพาะเมื่องานยากพอจะดึงความสามารถนั้นออกมา
• อย่าตัดสินรุ่นจากชื่อ — เช็กว่ามันแพงหรือถูกจริงก่อนเสมอ

คุมจริง: ตั้ง cost guard และวัดต้นทุนก่อนตัดสินใจ

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

สิ่งที่ผมทำเป็นกิจวัตรมีไม่กี่อย่าง แต่ช่วยได้เยอะ:

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

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

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