ภาพโต๊ะกลไกสีเขียวเข้มที่มีคันโยกสามระดับส่งชิ้นงานเข้าเลนยาว โดยมีชิ้นงานสีอำพันหนึ่งชิ้นหลุดอยู่นอกเลน
aillmagentsdeepseekcost-optimization

DeepSeek V4 Pro ให้เลือก Reasoning Effort: งานไหนใช้ Low, High หรือ Max

น้องกายEngineering

Agent ที่คิดนานที่สุดไม่ได้คุ้มที่สุดในทุกงานครับ การจัดหมวด ticket, สรุป log และแก้ migration ข้ามหลาย service ต้องการความลึกคนละระดับ DeepSeek V4 Pro เพิ่มตัวเลือก reasoning effort ให้ทีมเลือกแรงคิดตามงาน แทนการส่งทุกอย่างเข้าโหมดหนักสุด

ประกาศ V4 Pro GA วันที่ 13 สิงหาคม 2026 ระบุ effort สามระดับ: low สำหรับงานง่าย, high สำหรับ agent workflow ประจำวัน และ max สำหรับงานซับซ้อน รุ่นนี้รองรับ OpenAI Responses API โดยตรง และชื่อ model ใน API เดิมไม่เปลี่ยน นอกจากนี้ DeepSeek เริ่มราคา peak/off-peak โดยช่วง off-peak ถูกกว่าครึ่งหนึ่งตั้งแต่ 16 สิงหาคม

WHY: Model เดียวก็ต้องมี Routing Policy

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

คำถามจึงไม่ใช่ “max เก่งกว่าไหม” แต่คือ “task class นี้ต้องใช้หลักฐานระดับไหน” เราควรตัดสินจากอัตราสำเร็จ, เวลา, token และความเสี่ยงของความผิดพลาดร่วมกัน

HOW: เริ่มจากสาม Queue ที่อธิบายได้

แบ่งงานชุดแรกเป็นสามกลุ่มง่าย ๆ:

  • low: extraction, classification, rewrite ที่มี schema หรือเกณฑ์ชัด
  • high: coding task ขนาดกลาง, analysis หลายเอกสาร, agent ที่เรียก tools ไม่กี่ขั้น
  • max: migration ข้ามระบบ, debugging ที่สมมติฐานหลายชั้น หรือ decision ที่ต้องตรวจหลักฐานจำนวนมาก

อย่า route จากความยาว prompt อย่างเดียว งานสั้นอาจเสี่ยงสูง และงานยาวอาจเป็น extraction ตรงไปตรงมา ให้เพิ่มตัวแปรอย่าง reversibility, blast radius และ verifier availability ถ้ามี test หรือ schema ตรวจคำตอบได้ เราอาจเริ่ม low แล้ว escalate เมื่อ fail ได้

รูปแบบที่คุมต้นทุนดีคือ low-first with escalation: รัน low, ตรวจด้วย deterministic verifier แล้วส่ง high/max เฉพาะงานที่ไม่ผ่าน วิธีนี้ดีกว่าขอให้ model ประเมินตัวเองเพียงอย่างเดียว เพราะ confidence ของ model ไม่ใช่หลักฐานว่าผลถูก

ใช้ Off-peak กับงานที่รอได้

ราคา off-peak ที่ลด 50% มีประโยชน์กับ batch evaluation, indexing, backlog cleanup และ report รายวัน แต่ไม่ควรย้าย incident response หรือ interactive chat ไปต่อคิวเพียงเพราะถูกกว่า

ตั้ง deadline class ให้ชัด เช่น interactive ภายในวินาที, background ภายในชั่วโมง และ batch ข้ามคืน จากนั้น scheduler จึงเลือกช่วงราคาได้โดยไม่ทำลาย SLO ระวัง timezone ด้วย ประกาศอ้างเวลา UTC การแปลงเป็นเวลาท้องถิ่นควรอยู่ใน config/test ไม่ใช่จำกันในทีม

ต้นทุนจริงต้องวัดต่อ successful task ไม่ใช่ต่อ token หาก low ถูกแต่ต้อง retry สามครั้ง อาจแพงกว่า high ครั้งเดียว เก็บทั้ง input, output, cached tokens, latency, verifier result และจำนวน escalation

สิ่งที่ประกาศยังไม่ได้พิสูจน์แทนเรา

DeepSeek ระบุว่า V4 Pro มี production gains แต่ไม่ได้แปลว่า workload ของเราดีขึ้นตามค่าเฉลี่ย Benchmark และคำอธิบาย vendor เป็นจุดเริ่ม ให้ทำ golden tasks ของภาษาไทย, codebase และ tool schema จริงก่อนเปลี่ยน default

Responses API compatibility ก็ไม่ได้รับประกันว่าพฤติกรรม tool calling, reasoning visibility หรือ error shape จะเหมือน provider เดิมทุกจุด วาง adapter และ contract test ที่ขอบ provider เสมอ

Recap

V4 Pro ทำให้ effort กลายเป็น policy ที่ทีมต้องออกแบบ ใช้ low กับงานตรวจง่าย, high กับ agent งานประจำ และ max กับโจทย์หลายชั้น โดยมี verifier และ escalation เป็นราวกันตก

พรุ่งนี้เลือก golden tasks 20 งาน วัด cost per success ของทั้งสามระดับ แล้วแยก batch ที่ย้ายไป off-peak ได้ เมื่อ routing มาจากหลักฐาน เราจะใช้ความแรงเท่าที่จำเป็นแทนการเปิดสุดทุกครั้งครับ