GLM-5.3 ตัด flag “thinking: disabled” ออก ส่งผลให้การเชื่อมต่อ (integration) ใดๆ ที่เคยส่ง {"thinking":{"type":"disabled"}} จะได้รับ error แทนที่จะเป็น response การเปลี่ยนแปลงนี้ทำให้ชุดทดสอบ (test suites) จำนวนมากพังลงเพียงชั่วข้ามคืน และบีบให้เหล่านักพัฒนาต้องเขียนโค้ดใหม่เพียงบรรทัดเดียวเพื่อให้แอปพลิเคชันทำงานต่อไปได้

ทำไมการเปลี่ยนแปลงนี้ถึงสำคัญ

ใน GLM-5.2 ตัว API อนุญาตให้ผู้เรียกใช้งานปิดโหมด thinking สำหรับ prompt ที่ไม่ซับซ้อน ตัวเลือกดังกล่าวเป็นรูปแบบที่ใช้กันทั่วไปในสคริปต์อัตโนมัติ (automation scripts), กระบวนการประมวลผลแบบกลุ่ม (batch-processing pipelines) และบอทที่ต้องการความหน่วงต่ำ (low-latency bots) แต่ GLM-5.3 ได้นำ flag นี้ออกไปโดยสิ้นเชิง และแทนที่ด้วยระดับความพยายาม (effort levels) สามระดับ ได้แก่ low, high และ max โดยกำหนดให้ max เป็นค่าเริ่มต้น โมเดลใหม่จะสร้าง reasoning trace เสมอ และไม่สามารถปิดการทำงานนี้ได้อย่างสมบูรณ์อีกต่อไป

สิ่งที่พังและผลกระทบที่เกิดขึ้น

เมื่อ request body มีค่า "type":"disabled" เซิร์ฟเวอร์จะปฏิเสธ payload และส่งการตอบกลับความล้มเหลวแบบทั่วไป (generic failure response) กลับมา จะไม่มี error เกี่ยวกับการยืนยันตัวตน (authentication) หรือไวยากรณ์ (syntax) ปรากฏขึ้น ทำให้ปัญหาตรวจพบได้ยากจนกว่าจะมีการทำ regression run แบบเต็มรูปแบบ เนื่องจาก flag นี้อยู่ใน helper function ที่นำกลับมาใช้ใหม่ได้ในหลายๆ codebase ผลกระทบจึงแพร่กระจายไปยังทั้งชุดทดสอบขนาดใหญ่และ production endpoints เช่นเดียวกัน

การเปลี่ยนแปลงโค้ดที่ต้องทำ

แทนที่ payload เดิม:

extra_body = {"thinking": {"type": "disabled"}}

ด้วยเวอร์ชันที่รองรับ GLM-5.3:

extra_body = {"thinking": {"type": "enabled", "effort": "low"}}

คีย์ "type":"enabled" จะเป็นการเปิดใช้งาน reasoning engine อีกครั้ง ในขณะที่ "effort":"low" จะช่วยเลียนแบบความเร็วของโหมด disabled เดิมให้ใกล้เคียงที่สุดเท่าที่โมเดลใหม่จะอำนวย

ผลกระทบด้านประสิทธิภาพ

การรัน prompt สำหรับการตรวจทานโค้ด (code-review) ด้วยการตั้งค่า low-effort จะให้ผลลัพธ์ที่ "ใกล้เคียงกับความเร็วเดิม" แต่ไม่เหมือนกันเสียทีเดียว โมเดลยังคงส่ง reasoning trace ออกมา ซึ่งจะเพิ่มจำนวน token อีกเล็กน้อยและทำให้เกิดความหน่วง (latency) เพิ่มขึ้นบ้าง สำหรับงานที่มี throughput สูงหรือต้องการความหน่วงต่ำเป็นพิเศษ คุณควรทำการทดสอบ benchmark ด้วยข้อมูลของคุณเองเพื่อยืนยันว่า overhead ที่เพิ่มขึ้นนั้นอยู่ในระดับที่ยอมรับได้

ทำไมถึงควรย้ายมาใช้ แม้จะมีต้นทุนเพิ่มขึ้น

GLM-5.3 ยังคงใช้สถาปัตยกรรมแบบ 744-billion-parameter เช่นเดียวกับรุ่นก่อนหน้า แต่ปรับจุดเน้นไปที่งานด้านการเขียนโค้ด (coding) และงานด้าน agentic ผลการทดสอบที่เป็นอิสระ (Terminal-Bench 3.0) แสดงให้เห็นถึงคะแนนที่เพิ่มขึ้นอย่างเห็นได้ชัด และการทดสอบภายในรายงานว่าสามารถตรวจจับข้อผิดพลาดทางตรรกะ (logic errors) ในหลายไฟล์ได้ดีขึ้น สำหรับทีมที่ต้องพึ่งพาโมเดลในการวิเคราะห์โค้ดที่ซับซ้อน ประสิทธิภาพที่เพิ่มขึ้นอาจคุ้มค่ากับปริมาณการใช้ token ที่เพิ่มขึ้นเพียงเล็กน้อย

ข้อแลกเปลี่ยนที่คุณไม่สามารถมองข้ามได้

หากแอปพลิเคชันจำเป็นต้องมีการตอบกลับแบบไม่มีการคิด (zero-thinking responses) จริงๆ เช่น บริการ token-completion บริสุทธิ์ ปัจจุบันจะไม่มีตัวเลือกแบบ native ใน GLM-5.3 อีกต่อไป นักพัฒนาจะต้องยอมรับ output ของ reasoning ที่เพิ่มขึ้นมา หรือเปลี่ยนไปใช้โมเดลอื่นที่ยังมีโหมด disabled ให้ใช้งานอยู่

สิ่งที่ควรจับตามองต่อไป

  • การตรวจสอบความหน่วง (Latency monitoring): หลังจากเปลี่ยน payload แล้ว ให้ติดตามเวลาในการตอบกลับและจำนวน token เพื่อตรวจพบปัญหา regression ได้ตั้งแต่เนิ่นๆ
  • การปรับจูนความพยายาม (Effort tuning): งานบางประเภทอาจได้รับประโยชน์จากการตั้งค่า “high” โดยไม่เสียประสิทธิภาพมากนัก ดังนั้นควรทดลองใช้มากกว่าแค่การตั้งค่า low
  • การยกเลิกฟีเจอร์ในอนาคต (Future deprecations): การนำ flag เพียงตัวเดียวออกบ่งชี้ว่า API อาจมีการควบรวมฟีเจอร์อื่นๆ อีก ควรคอยติดตามบันทึกการอัปเดต (release notes) ที่กำลังจะมาถึง

สรุปใจความสำคัญ: การอัปเดต payload ของ thinking เป็น {"type":"enabled","effort":"low"} จะช่วยให้กลับมาใช้งานร่วมกับ GLM-5.3 ได้ ตรวจสอบความหน่วงและการใช้ token ใน pipeline ของคุณ และตัดสินใจว่าความสามารถในการเขียนโค้ดที่ปรับปรุงขึ้นนั้นคุ้มค่ากับ reasoning trace ที่หลีกเลี่ยงไม่ได้หรือไม่

สามารถพูดคุยและรับการสนับสนุนจากชุมชนได้ที่ช่อง GyaanSetu AI Telegram