GLM 5.2 เทียบกับ Opus

 (techstackups.com)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อให้สร้าง เกมแพลตฟอร์ม 3D ด้วย raw WebGL จาก one-shot prompt เดียวกัน Opus ให้ผลลัพธ์ที่เร็วกว่าและสมบูรณ์กว่ามาก ขณะที่ GLM-5.2 มีข้อได้เปรียบด้านต้นทุนต่ำและเป็นโมเดล open weights
  • GLM-5.2 เป็นโมเดล open weights ภายใต้ไลเซนส์ MIT ของ Z.ai พร้อมคอนเท็กซ์ 1M โทเค็นและระดับการคิด High/Max แต่เป็นโมเดลข้อความล้วน จึงมีข้อจำกัดในการตรวจสอบตัวเองด้วยภาพ
  • ค่าใช้จ่ายจริงในการทดสอบคือ GLM-5.2 อยู่ที่ $5.39 ส่วน Opus ราว $21.92 โดยใช้เวลาสร้าง 1 ชั่วโมง 10 นาที 40 วินาที และ 33 นาที 30 วินาทีตามลำดับ ทำให้ต้องเลือกระหว่างความเร็วกับต้นทุน
  • ผลลัพธ์ของ GLM-5.2 มีปัญหาพื้นฐานอย่างเท็กซ์เจอร์หาย สไปก์ใช้งานไม่ได้ ไม่มีเงื่อนไขชนะเกม และยังมีดีบักโอเวอร์เลย์ค้างอยู่ ส่วน Opus สะอาดกว่า แต่ยังมีปัญหาการ判定บนแท่นลอยบางจุดและทริกเกอร์ชนะที่ไกลเกินไป
  • ทั้งในเบนช์มาร์กและการประเมินภายนอก GLM-5.2 ดูเป็นโมเดล open weights ที่แข็งแกร่ง แต่ในงานโค้ดดิ้งและงานเอเจนต์หลายประเภท Opus ยังนำอยู่ โดย ต้นทุน ความเปิดกว้าง และการตัดสินจากภาพ เป็นเกณฑ์หลักในการเลือก

ความแตกต่างที่เห็นจากโจทย์เดียวกัน

  • GLM-5.2 เป็นตัวอย่างล่าสุดที่แสดงศักยภาพของโมเดลเปิด แต่ในโจทย์ใช้งานจริงแบบเดียวกัน Claude Opus 4.8 ให้ผลลัพธ์ที่เร็วกว่าและแม่นยำกว่า
  • การทดสอบใช้วิธีให้ทั้งสองโมเดลรับ one-shot prompt เดียวกัน แล้วสร้าง เกมแพลตฟอร์ม 3D สำหรับเบราว์เซอร์ ด้วย raw WebGL ตั้งแต่ศูนย์ โดยไม่ใช้เกมเอนจินหรือไลบรารีเรนเดอร์ 3D อย่าง Three.js
  • มีการเปิดเผยทั้งผลงานและซอร์สโค้ดของทั้งสองผลลัพธ์
  • ทั้งสองเกมใช้แอสเซ็ตฟรีแบบ CC0 จาก Kenney Platformer Kit

ลักษณะและแนวทางของ GLM-5.2

  • GLM-5.2 คือโมเดลเรือธงล่าสุดของ Z.ai และเปิดให้ใช้งานแบบ open weights ภายใต้ไลเซนส์ MIT
    • ดาวน์โหลดไปรันเองได้ หรือเรียกผ่าน Z.ai API ก็ได้
    • มีการปล่อย weights บน Hugging Face และ ModelScope โดยไม่มีข้อจำกัดตามภูมิภาค
    • สามารถเสิร์ฟแบบโลคัลได้ด้วยเฟรมเวิร์กอย่าง vLLM, SGLang และ Transformers
  • โมเดลนี้มุ่งเป้าไปที่ งานระยะยาว อย่างงานเอเจนต์เขียนโค้ดหลายขั้นตอนที่ใช้เวลานาน
    • รองรับหน้าต่างคอนเท็กซ์ 1M โทเค็น
    • มีระดับการคิด High และ Max โดยการทดสอบนี้ใช้ระดับ High
  • ข้อจำกัดสำคัญคือเป็นโมเดล ข้อความล้วน
    • GLM-5.2 อ่านภาพไม่ได้
    • เวิร์กโฟลว์ที่ต้องดูสกรีนช็อตหรือไดอะแกรมโดยตรงจึงต้องพึ่งโมเดลมัลติโหมดอย่าง Claude Opus

ราคาและต้นทุนการรัน

  • ตามเอกสารของผู้ให้บริการ ราคาต่อ 1M โทเค็นของ GLM-5.2 ต่ำกว่า Opus
    • Claude Opus 4.8: อินพุต $5, cache read $0.50, เอาต์พุต $25
    • GLM-5.2: อินพุต $1.4, cache read $0.26, เอาต์พุต $4.4
  • หากดูเฉพาะโทเค็นเอาต์พุต GLM-5.2 มีราคาต่ำกว่า Opus มากกว่า 5 เท่า
  • แต่ในการทดสอบสร้างเกมจริง ความเร็วกับต้นทุนกลับสวนทางกัน
ตัวชี้วัด GLM-5.2 (Pi/OpenRouter) Opus (Claude Code)
เวลาสร้างจริงตามนาฬิกา 1 ชั่วโมง 10 นาที 40 วินาที 33 นาที 30 วินาที
โทเค็นเอาต์พุต 131,000 216,809
การใช้คอนเท็กซ์สูงสุด 16% ของ 1M 19% ของ 1M
การเรียกใช้เครื่องมือ 128 153
ต้นทุน $5.39 ที่ถูกเรียกเก็บจริง ราว $21.92 โดยประมาณ
  • Opus ใช้เวลาเพียงประมาณครึ่งหนึ่ง ขณะที่ GLM-5.2 ทำงานเสร็จด้วยต้นทุนที่ต่ำกว่ามาก

โจทย์ทดสอบ: เกมแพลตฟอร์ม 3D ด้วย raw WebGL

  • โจทย์นี้มีโครงสร้างซับซ้อนกว่าการสร้างหน้า landing page ธรรมดา
    • ตัวแยกวิเคราะห์โมเดล GLB
    • คณิตศาสตร์เมทริกซ์และเวกเตอร์
    • GLSL shader
    • แอนิเมชันกระดูกแบบ skinned
    • ลูป fixed timestep
    • การจัดการการชน
    • กล้องติดตาม
  • ทั้งสองโมเดลได้รับ prompt เดียวกัน แอสเซ็ตเดียวกัน และให้ลองเพียงครั้งเดียวโดยไม่มีคำใบ้
  • เงื่อนไขของงานที่ต้องทำให้สำเร็จมีดังนี้
    • เอนจิน 3D และ renderer แบบ raw WebGL
    • ตัวโหลดโมเดลตัวละคร 3D และโมเดลโลกที่ให้มา
    • การเคลื่อนที่และการกระโดดของตัวละครพร้อมแรงโน้มถ่วงและการชน
    • กล้องติดตามและการควบคุมด้วยคีย์บอร์ด
    • เกมที่รันได้ในเบราว์เซอร์ด้วยคำสั่งเดียว
  • ทั้งสองโมเดลต่างลงมือเขียนตัวแยกวิเคราะห์ GLB แบบไบนารี คณิตศาสตร์เมทริกซ์/ควอเทอร์เนียน WebGL2 renderer, GLSL skinned shader และการชนแบบ substep AABB เองเป็นส่วนใหญ่
  • มีการเปิดเผยบันทึกการสร้างด้วย

ผลการเล่นและบั๊กที่ยังเหลือ

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

  • ผลลัพธ์ของ GLM-5.2

    • เกมของ GLM-5.2 โดยรวมมี ความเนี้ยบค่อนข้างหยาบ
    • วัสดุบางส่วนของตัวละครหายไป และตัวละครเดินโดยหันสวนกับทิศทางการเคลื่อนที่
    • กับดักสไปก์ไม่ทำให้ตัวละครตายหรือรีเซ็ต และเมื่อไปถึงธงก็ไม่เกิดเงื่อนไขชนะ
    • เมื่อกล้องเคลื่อน หัวของตัวละครหายไป และยังมีดีบักโอเวอร์เลย์ค้างอยู่
    • ส่วนที่เหยียบสปริงแล้วตัวละครเด้งขึ้นไปยังแพลตฟอร์มถัดไปทำงานได้ดี
    • โมเดลของ Kenney อ้างอิงพาเลตสีร่วมจากไฟล์แยกต่างหาก แต่ renderer ของ GLM-5.2 ไม่โหลดไฟล์นี้ จึงแทนที่ด้วย สีแบนเรียบ

  • ผลลัพธ์ของ Opus

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

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

  • ทั้งสองโมเดลได้รับคำสั่งให้ตรวจสอบผลลัพธ์ก่อนจบงาน
  • Opus เป็นโมเดลมัลติโหมด จึงสามารถเรนเดอร์เกมแล้ว ตรวจดูสกรีนช็อตโดยตรง
    • มันเห็นตัวบ่งชี้ดีบักที่ยังค้างบนหน้าจอและลบออกก่อนปิดงาน
    • ในฉากสุดท้าย มันตรวจสอบบล็อก บันได เหรียญ อัญมณี สไปก์ ธง ตัวละคร คะแนน HUD แสง และเรขาคณิต
  • GLM-5.2 อ่านภาพไม่ได้ จึงไม่สามารถดูสกรีนช็อตโดยตรง
    • จึงใช้วิธีอ้อมโดยอ่านข้อมูลพิกเซลดิบและตรวจว่าค่าสีใกล้เคียงค่าที่คาดไว้หรือไม่
    • มันตรวจเงื่อนไขสีในภาพที่บันทึกไว้ เช่น grass green, dirt brown, coin gold, flag red, character bluish, half-Lambert lit, no black
  • วิธีนี้ทำให้พลาดปัญหาที่ปรากฏจริงบนหน้าจอ
    • ตัวละครดูเป็นสีเทาและอยู่ในสภาพเท็กซ์เจอร์หาย
    • ดีบักโอเวอร์เลย์ยังคงค้างอยู่บนหน้าจอ
  • ในงานที่ผลลัพธ์เชิงภาพมีความสำคัญ การตรวจสอบแบบมัลติโหมด ที่เข้าใจภาพได้จึงแปรไปเป็นความต่างของคุณภาพจริง

ตำแหน่งที่เห็นจากเบนช์มาร์ก

  • ในเบนช์มาร์กบน model card ของ Z.ai, GLM-5.2 อยู่ใกล้กับโมเดลปิดระดับท็อปในหลายรายการ และในบางเบนช์มาร์กด้านการให้เหตุผลก็ทำได้ดีกว่า
  • ตัวเลขหลักมีดังนี้
    • HLE: GLM-5.2 40.5, Opus 4.8 49.8
    • HLE with tools: GLM-5.2 54.7, Opus 4.8 57.9
    • AIME 2026: GLM-5.2 99.2, Opus 4.8 95.7
    • IMOAnswerBench: GLM-5.2 91.0, Opus 4.8 83.5
    • SWE-bench Pro: GLM-5.2 62.1, Opus 4.8 69.2
    • NL2Repo: GLM-5.2 48.9, Opus 4.8 69.7
    • ProgramBench: GLM-5.2 63.7, Opus 4.8 71.9
    • SWE-Marathon: GLM-5.2 13.0, Opus 4.8 26.0
    • MCP-Atlas public: GLM-5.2 76.8, Opus 4.8 77.8
    • Tool-Decathlon: GLM-5.2 48.2, Opus 4.8 59.9
  • ผลรันอิสระของ ArtificialAnalysis ก็ประเมิน GLM-5.2 ว่าเป็นโมเดล open weights ที่แข็งแกร่ง
    • คะแนน Intelligence Index v4.1 อยู่ที่ 51
    • สูงกว่า MiniMax-M3 44, DeepSeek V4 Pro 44 และ Kimi K2.6 43
    • TerminalBench v2.1 ได้ 78% โดยใช้ harness คนละชุดกับตัวเลข 81 หรือ 82.7 ใน model card
    • จำนวนโทเค็นเอาต์พุตต่อหนึ่งงานอยู่ที่ราว 43k มากกว่า 26k ของ GLM-5.1
  • ภาพรวมของเบนช์มาร์กสอดคล้องกับการทดสอบใช้งานจริง
    • GLM-5.2 อยู่ในกลุ่มนำของโมเดล open weights และยังมีความสามารถในการให้เหตุผลที่แข่งขันได้ในบางด้าน
    • Opus นำหน้าในเบนช์มาร์กสายโค้ดดิ้งและเอเจนต์จำนวนมาก

ปฏิกิริยาจากภายนอก

  • Simon Willison ประเมิน GLM-5.2 ว่าเป็น “LLM แบบ open weights ที่ทรงพลังที่สุดในสายข้อความล้วนเท่าที่เคยมีมา”
    • ในการทดสอบ SVG ของเขา GLM-5.2 สร้างภาพนกกระทุงขี่จักรยานแบบแอนิเมชันเต็มรูปแบบได้โดยไม่มีส่วนที่พัง
    • แต่การทดสอบตัวโอพอสซัมขี่สกู๊ตเตอร์กลับออกมาแย่กว่า GLM-5.1 ก่อนหน้า จึงสะท้อนว่าประสิทธิภาพยังไม่สม่ำเสมอ
  • Artificial Analysis ประเมิน GLM-5.2 ให้เป็น โมเดล open weights อันดับนำ ใน Intelligence Index ของตน
    • มองว่าเป็นโมเดลที่ถูกที่สุดในระดับเดียวกัน และอยู่บนเส้นพรมแดนด้านความคุ้มค่าระหว่างต้นทุนกับความฉลาด
    • แต่ก็ระบุว่าเป็นโมเดลที่กินโทเค็นมาก โดยใช้เอาต์พุตราว 43k ต่อหนึ่งงาน
  • Nathan Lambert มองว่าจากลีดเดอร์บอร์ด LMArena แล้ว GLM-5.2 อาจถือเป็นเอเจนต์ที่ดีกว่า Gemini ได้ด้วยซ้ำ และสำหรับโมเดลเปิดภายใต้ไลเซนส์ MIT นี่ถือเป็น “serious accomplishment”
    • เขาย้ำว่าโมเดลสหรัฐระดับท็อปยังคงนำโดยรวมอยู่ แต่สถาบันวิจัยจากจีนกำลังไปถึงคะแนนสูงได้ด้วยคอมพิวต์ที่น้อยกว่า

ควรเลือกโมเดลไหน

  • GLM-5.2 เป็นโมเดล open weights ที่ให้สมรรถนะสูงด้วยต้นทุนเพียงบางส่วนของราคา Opus
    • เหมาะเมื่อให้ความสำคัญกับต้นทุนและความเปิดกว้าง และงานส่วนใหญ่เน้นข้อความกับตรรกะ
    • weights ที่ดาวน์โหลดได้จะไม่ถูกปลดระวางหรือจำกัดการเข้าถึงแบบฉับพลันเหมือนโมเดลปิด
  • Opus ให้ผลลัพธ์ที่เร็วกว่า สะอาดกว่า และแม่นยำกว่าจากการทดสอบนี้
    • สามารถมองเห็นและตรวจสอบผลลัพธ์เชิงภาพได้โดยตรง
    • เหมาะกับงานที่ความแม่นยำ ความเนี้ยบ และการตัดสินจากภาพสำคัญ และยอมรับต้นทุนที่สูงกว่าได้
  • GLM-5.2 จึงดูเหมาะจะเป็นโมเดลเสริมที่ทรงพลัง ราคาถูก และเข้าถึงได้เสมอ มากกว่าจะเป็นโมเดลหลักที่มาแทน Opus

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • ไม่เข้าใจจริง ๆ ว่าทำไม one-shot prompting ถึงกลายเป็นเรื่องใหญ่ขนาดนี้
    ตามนิยามแล้ว พรอมป์เดียวไม่สามารถบรรจุความซับซ้อนของโปรเจ็กต์ซอฟต์แวร์ได้ทั้งหมดอยู่แล้ว สุดท้ายโมเดลก็แค่ตั้งสมมติฐานหลายอย่างจากโค้ดที่มีอยู่ในชุดข้อมูลฝึกแล้วให้ผลลัพธ์ออกมา
    ถ้าให้เลือก อยากเห็น coding agent ที่ทำตาม ขั้นตอนในไฟล์แผนงาน อย่างแม่นยำ พร้อมยึด guardrail ของสเปกที่มีคนตรวจทานแล้วและ coding convention มากกว่า และก็ควรตรวจสอบด้วยว่า agent loop จะไม่หลุดออกนอก guardrail และไม่แกว่งไปมาจนกว่าจะทำเป้าหมายที่มนุษย์กำหนดไว้สำเร็จ
    อีกทั้งความสามารถในการเข้าใจบริบทของ use case ที่กำลังสร้าง ค้นหาบั๊กหรือโอกาสในการปรับปรุงประสิทธิภาพในโค้ดเดิม และเสนอการรีแฟกเตอร์ ก็เป็นตัวชี้วัดที่มีคุณค่ากว่ามาก

    • ในแง่ที่ว่าการทดลองนี้พยายามดูว่าโมเดลสามารถสร้างผลลัพธ์ที่ถูกประเมินแบบอัตวิสัยว่า ดี ได้หรือไม่ แม้จะมีสเปกที่ค่อนข้างกำกวมและเปิดกว้าง ก็ถือว่าน่าสนใจ
      มันใกล้เคียงกับการดูว่าผลลัพธ์มีความสอดคล้องกันภายในหรือไม่ มากกว่าจะเป็นเบนช์มาร์กที่ตรวจว่าเอาต์พุตตรงกับอินพุตหรือเปล่า ถ้าเป็นเกมก็ประมาณว่าดูว่าเมื่อถึงเป้าหมายแล้วเกมจบไหม แตะหนามแล้วตายไหม และมีเคสขอบแปลก ๆ ตอนเคลื่อนไหวหรือไม่
      แต่ก็คิดว่าควรใช้ environment เดิมแล้วทำการทดลองซ้ำหลาย ๆ ครั้งเพื่อดูความแปรปรวนของผลลัพธ์ด้วย
    • ปัญหาไม่ได้อยู่ที่ one-shot เอง แต่เป็นสถานการณ์แบบ greenfield ที่เริ่มจากโปรเจ็กต์ว่างเปล่า
      สมัยก่อนชอบแซววิศวกรที่ลอง framework จาก README บนโปรเจ็กต์ว่าง แล้วก็บอกว่า “framework นี้ดีที่สุดสำหรับ production app อายุ 10 ปีของเรา” วิธีคิดแบบ greenfield เป็นทั้งคำตอบของทุกปัญหา และเป็นปัญหาของทุกคำตอบ
      ความสามารถแบบ one-shot ก็ยังเป็นตัวชี้วัด self-measurement ที่สำคัญและควรวัดอยู่ดี แต่ควรวัดกับ codebase ขนาดใหญ่ ที่ใช้งานจริงแล้ว
    • ตอนนี้ยังไม่มีใครพยายามทำงานจริงจังด้วย one-shot ทันทีหรอก แต่ก็ยังเป็นตัวชี้วัดที่สำคัญ
      ที่ Claude Code กับ Opus ถูกพูดถึงมาก ก็เพราะ execution environment ดีขึ้นจนสามารถแก้ความผิดพลาดจำนวนมากได้เองโดยไม่ต้องให้ผู้ใช้ป้อนข้อมูลเพิ่ม ในระยะยาวคิดว่าการพัฒนาใหญ่ที่สุดน่าจะมาจากความสามารถในการทำงานอัตโนมัติเป็นเวลาหลายชั่วโมงและการแก้ไขตัวเอง
    • one-shot มีคุณค่าพอที่จะทดสอบ แต่จะมีความหมายก็ต่อเมื่อเป็น พรอมป์ขนาดใหญ่มาก อย่าง “สร้างสิ่งนี้ตามสเปกนี้” เท่านั้น
      ถ้าใช้อินพุตไม่กี่โทเค็นแล้วให้สร้างผลลัพธ์เป็นล้านโทเค็น ผมมองว่ามันสื่อความหมายได้ไม่มาก
    • ถ้าโมเดลสามารถรับคำสั่งที่ซับซ้อนขึ้นเรื่อย ๆ และตอบโจทย์ความต้องการได้โดยไม่ต้องมีมนุษย์แทรกแซง ก็สามารถตัดสินสมรรถนะโดยรวมได้ค่อนข้างง่าย
      ถ้าจะประเมินโมเดลที่ดีกว่าเดิม ก็แค่เพิ่ม requirement เข้าไปในงานนั้น คิดว่าเป็นวิธีที่มีประโยชน์ แม้อาจไม่ใช่ use case ที่สมจริงนัก
      แน่นอนว่าถ้ามีวิศวกรซอฟต์แวร์คอยบังคับ โมเดลจะให้ผลลัพธ์ที่ดีกว่ามากได้ และก็อาจแย่ลงได้เหมือนกัน ขึ้นอยู่กับวิศวกร

  • การรันแบบ one-shot เดี่ยวในทำนองว่า “เอาพรอมป์ one-shot เดียวกันไปดวล Claude Opus 4.8 แบบตัวต่อตัว: สร้างเกมแพลตฟอร์ม 3D ด้วย WebGL แบบดิบ ๆ ตั้งแต่ศูนย์” นั้น ไม่ใช่ เบนช์มาร์ก และก็ไม่ได้เป็นตัวแทนการใช้งานจริง
    การใช้งาน agent ส่วนใหญ่เป็นแบบร่วมมือกัน ดังนั้นควรทดสอบทั้ง ความน่าเชื่อถือ เช่น มอบหมายงานแล้วมันทำเสร็จโดยไม่กุผลทดสอบ และความสามารถในการควบคุม ว่ามันทำตามคำสั่งของฉันหรือทำไปตามความคิดของตัวเอง

    • ผมเป็นคนเขียนเองและเห็นด้วยเต็มที่ ครั้งนี้ทำเป็น vibe test ไม่ใช่เบนช์มาร์ก และผมก็แยก list ของเบนช์มาร์กจริงไว้อีกต่างหาก
      การทดสอบนี้แสดงให้เห็นว่าเมื่อให้ทั้งสองโมเดลทำงาน one-shot ที่กินเวลานานและยากในเชิงเทคนิค พวกมันทำอะไรได้บ้าง
      รูปแบบที่ดูเรื่องการทำงานร่วมกัน การมอบหมายงาน การทำให้เสร็จ การพัฒนาแบบ test-driven และความสามารถในการควบคุม เป็นการทดสอบที่ดีและควรลองในอนาคต
    • ในทางกลับกัน ผมเพิ่งเอา GPT 5.5 ไปต่อกับ Raspberry Pi agent แล้วปล่อยให้ทำงานระยะยาวที่นิยามชัดเจนข้ามคืน ตอนนี้รันมาแล้วราว 10 ชั่วโมงและเกือบเสร็จแล้ว use case แบบนี้ก็ใช้ได้เหมือนกัน
      พอมาคิดดู งาน agent ที่ผมทำส่วนใหญ่ก็คือ sub-agent ที่รันด้วยพรอมป์ของตัวเองอยู่ใน main session และสิ่งเหล่านี้ก็มองได้ว่าเป็นเวอร์ชันสั้นของงานอัตโนมัติเต็มรูปแบบ
    • เพราะงั้นควรดูผสมกันทั้งเบนช์มาร์กทางการ การวิเคราะห์ยาว ๆ แบบเทียบข้างกัน และการประเมินจากหลายคนที่เราเชื่อถือ
      ในบทความก็พูดถึงเรื่องพวกนี้ และไม่ได้ตั้งใจให้สิ่งนี้เป็นเบนช์มาร์กอย่างเป็นทางการอยู่แล้ว เบนช์มาร์กทางการมีมากพอแล้ว

  • Anthropic โยน 529 Overloaded มาเรื่อย ๆ เลยไปสมัคร GLM 5.2 มาใช้เมื่อวาน
    ชอบนะ แต่แค่เซสชันเดียวที่ใส่พรอมป์ 2 ครั้งบน xhigh ของ GLM 5.2 ก็กินโควตาไป 22% ของ light plan ในหน้าต่างรีเซ็ต 5 ชั่วโมงแล้ว
    ผลลัพธ์น่าพอใจและคุณภาพก็ดี อยากใช้ทั้งสองตัว เลยอยากให้มี แพ็กเกจสมัครสมาชิกแบบรวม ที่ใช้ Anthropic กับ GLM ได้ด้วยกัน

  • จากที่ลองใช้ GLM 5.2 กับบางโปรเจ็กต์ ความรู้สึกคือมันใช้เวลาค่อนข้างนานกว่าจะเริ่มเขียนโค้ด และไม่ใช่โมเดลที่เร็วเลย
    ช่วงสำรวจและวางแผนมันออกนอกทางบ่อย แต่หลังจากนั้นก็ดึงกลับมาได้ และควบคุมไม่ง่ายนัก เพราะชอบหลอนสิ่งที่ตัวเองจะไม่ทำตามในภายหลัง ถึงอย่างนั้นคุณภาพของผลลัพธ์ก็ค่อนข้างดี
    อย่างเช่นผมเคย optimize rendering ใน codebase ที่เป็น Swift+Zig แล้วติดคอขวดอยู่ที่ข้อมูล 5,000 รายการ GLM 5.2 ใช้เวลา 20 นาทีในการสร้างเบนช์มาร์กและดึงข้อมูลออกมา ผมหงุดหงิดเลยปิดสิทธิ์เข้าถึงเครื่องมืออื่นนอกจากการแก้ไขแล้วเดินออกไป ประมาณ 30 นาทีต่อมากลับมา มันก็ optimize คอขวด 3 จุดไว้แล้วโดยอิงจากเบนช์มาร์กที่ทำไว้กับ “ข้อสรุป” บางอย่าง และยังบอกด้วยว่าต้องการข้อมูลเพิ่มเพราะยังยืนยันข้อสงสัยไม่ได้
    งานที่ทำใช้งานได้ดี เป็นไปตามแนวทางของภาษา และไม่รุกล้ำมากเกินไป พูดได้ด้วยว่ามีความเป็นไปตามแนวปฏิบัติมากกว่าผลลัพธ์ที่ GPT 5.5 สร้างในรีโพเดียวกัน อยากใช้ต่ออีก แต่ GPT มักทำคำขอเดียวกันเสร็จเร็วกว่า 5 เท่า
    GLM 5.2 ยังทำให้ผมเตรียมชุดการทำงานที่รันหลายตัวแบบขนานในคอนเทนเนอร์แยกและ JJ workspace ด้วย

    • ไม่นานมานี้ผมใช้มันกับงานที่ความสำคัญต่ำ ซึ่งโมเดลอื่นแก้ไม่ได้ และผมก็ไม่อยากเผาโควตา Opus 4.8
      เป็นปัญหาเรื่องดักจับ left click บน macOS menu bar แล้วทำให้ Ctrl+click หรือ right click เปิดเมนูเหมือน left click เดิม แต่ให้ทำงานแบบมีเงื่อนไข
      กลางเซสชันแก้ปัญหาผมสลับโมเดลไปเป็น GLM-5.2 ทั้งที่ไม่ได้ป้อนพรอมป์ใหม่เลย เปลี่ยนระหว่างที่มันกำลังคิดด้วยซ้ำ แล้วไม่กี่นาทีต่อมาปัญหาก็ถูกแก้ ใช้ผ่านโควตาแบบสมัครสมาชิกของ OpenCode Go และปัญหาแนวนี้อาจกินโควตา Opus หมดทั้งหน้าต่าง 5 ชั่วโมง หรือแม้แต่ลิมิตรายสัปดาห์ได้เลย
    • อีกอย่างที่ชอบคือสามารถดู trace การอนุมาน ทั้งหมดได้
      เราจะเห็นได้ว่าโมเดลเริ่มหลุดจากเส้นทางเมื่อไร หรือเจอส่วนที่มันค้นพบเองโดยที่เราไม่ได้บอก ก็หยุดแล้วแก้ได้ หรือจะใช้เพื่อเรียนรู้ว่าทำไมมันถึงเลือกแบบนั้นก็ได้ ทำให้ภายหลังต้องตั้งคำถามน้อยลง

  • ประสบการณ์ของผมก็คล้ายกัน ใช้อยู่บน Pi ซึ่งมันฉลาดและผลลัพธ์ก็ดี แต่กระบวนการกว่าจะไปถึงจุดนั้น ไม่ได้มีประสิทธิภาพนัก

    • ราคาก็เป็นปัญหาเหมือนกัน อยากลองใช้ แต่ถ้าถูกกว่า Opus แค่ราว 30% แบบนี้ ขณะที่ยังมีปัญหาเหล่านี้อยู่ ก็คงไม่เลือก

  • มีข้อความว่า “GLM-5.2 อ่านภาพไม่ได้ เลยเกิดปัญหาตรงนี้ เพราะมันไม่ใช่มัลติโหมดัล ดังนั้นแทนที่จะดูสกรีนช็อต จึงใช้วิธีเขียนสคริปต์อ่านข้อมูลพิกเซลดิบแล้วตรวจว่าสีออกมาใกล้เคียงตามคาดหรือไม่” แต่วิธีที่ดีกว่าคือใช้ https://github.com/openbmb/MiniCPM-V

    • ใช่เลย ถ้าให้สิทธิ์เข้าถึง เอเจนต์เฉพาะด้านการมองเห็น แก่ text LLM ปัญหานั้นก็จะแก้ได้
      ถ้าอยากจริง ๆ จะให้มันเรียก Opus มาดูภาพก็ได้ และถึงอย่างนั้นก็น่าจะยังประหยัดค่าใช้จ่าย

  • สมัคร Ollama เพื่อทดลองโมเดลโอเพนซอร์ส
    ตลอด 3 เดือนที่ผ่านมา ยังอยู่ในระดับลองไปเรื่อย ๆ และใช้งานบ้าง แต่ GLM เป็นโมเดลแรกที่ใช้ทุกวันร่วมกับ Claude กับงานเขียนโค้ดจริงจัง ค่อนข้างดีจนใช้โควตา Ollama เต็มทุกวัน

    • น่าสนใจ อยากรู้ว่าคุณใช้ GLM กับงานประเภทไหนบ้าง และมีโมเดลอื่นอะไรที่รู้สึกว่ามีประโยชน์ผ่าน Ollama อีก

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

    • Opus กับ GPT 5.5 เก่งมากในการปรับระดับการคิดและความเข้มของการให้เหตุผลตามลักษณะงาน และรู้สึกว่าโมเดล open weights ยังทำตรงนี้ได้ไม่ดีเท่า
      นอกจากนี้ โมเดล open weights บางตัวอย่าง GLM 5.2 หรือ DeepSeek v4 Pro ก็สร้างโทเคนได้ช้ากว่ามาก เลยส่งผลต่อความหน่วงที่รับรู้ได้ ถึงอย่างนั้นก็เรียก GLM 5.2 ว่าเป็นโมเดลช้าได้ไม่เต็มปาก และตัวอย่างเช่นตอนนี้ใน Notion มันก็เป็นหนึ่งในโมเดลที่เร็วที่สุด
    • ปัจจัยที่น่าจะมีผลมากที่สุดอาจเป็น ดาต้าเซ็นเตอร์ ที่รันโมเดลอยู่
      อีกความเป็นไปได้คือ Opus อาจใช้แนวทางอย่าง Mixture of Experts ทำให้ส่วนของโมเดลที่ต้องโหลดเข้าเมมโมรีในแต่ละครั้งเล็กกว่า GLM
    • อาจเป็นเรื่องโครงสร้างพื้นฐาน Anthropic น่าจะพร้อมกว่ามาก

  • GLM 5.2 มีปัญหาใหญ่ข้อหนึ่งที่จำกัดความสำเร็จอย่างมีนัยสำคัญ คือเรื่องความคุ้มค่าของ subscription สำหรับงานโค้ดดิ้ง
    ถ้าดูเฉพาะราคา API แล้ว GLM 5.2 ชนะคู่แข่ง แต่การใช้แบบคิดเงินตาม API สำหรับงานโค้ดดิ้งนั้นมีแต่บริษัทใหญ่ ๆ เป็นหลัก และในกลุ่มนี้สินค้ารูปแบบ subscription ที่อุดหนุนราคาอย่างหนักก็กำลังค่อย ๆ หายไป
    ขณะเดียวกัน บริษัทเหล่านี้ก็คงไม่ยอมให้พนักงานใช้ API จากจีน
    สำหรับบุคคลทั่วไปและทีมเล็ก ๆ subscription สำหรับงานโค้ดของ Z.ai ยังสู้ Anthropic และ OpenAI ไม่ได้ อาจได้ปริมาณการใช้งานใกล้กับ Claude แต่ Codex ให้ปริมาณการใช้งานต่อเงินที่จ่ายมากกว่าอย่างชัดเจน
    จะเถียงกันได้ว่า Z.ai ไล่ GPT5.5 และ Opus 4.8 ทันมากแค่ไหน แต่ถ้าอยู่ในโลกที่ทุกอย่างราคาเท่ากันและเลือกได้อิสระ ผมคงไม่เลือก GLM
    ดังนั้นคำถามสำคัญคือ สินค้าของ Z.ai จะดีขึ้นแค่ไหนใน GLM 5.3 หรือ 6 และ OpenAI กับ Anthropic จะจำกัดสินค้าปัจจุบันมากแค่ไหนในอนาคตอันใกล้

    • ถ้ามองจากนอกสหรัฐฯ ภาพจะต่างออกไป บริษัทในยุโรปถูก Fable พรากไปเพราะมาตรการควบคุมการส่งออกของสหรัฐฯ และก่อนหน้านั้น Anthropic ก็ประกาศว่าจะเก็บข้อมูลไว้ 30 วัน
      การสร้างโครงสร้างพื้นฐานโดยมี AI ที่จะไม่ถูกยึดคืนไปได้ทุกเมื่อเป็นแกนกลาง มีคุณค่าในทันทีสำหรับบริษัทแบบนี้ ประเทศอื่นนอกยุโรปก็อ่อนไหวต่อราคามากกว่า และไม่ได้กลัวการมีความสัมพันธ์กับบริษัทจีนในระดับเดียวกัน
    • คนที่ใช้การคิดเงินแบบ API ไม่ได้มีแค่บริษัทใหญ่ แต่รวมถึงคนที่ใช้สภาพแวดล้อมรันของ third-party อย่าง OpenCode ด้วย
      พร้อมกันนั้น ถ้า “บริษัทเหล่านี้จะไม่ยอมให้พนักงานใช้ API จากจีน” ก็ชวนสงสัยว่า Amazon Bedrock ที่ให้บริการ GLM ตั้งเป้ากลุ่มไหนกันแน่
      คนทั่วไปก็น่าจะเลือกผู้ให้บริการสหรัฐฯ ที่ถูกกว่าอย่าง DeepInfra มากกว่า อินพุตแบบแคชของ GLM อยู่ที่ $0.18 ต่อ 1 ล้านโทเคน ขณะที่ Opus อยู่ที่ $0.50 และ Fireworks AI ก็เป็นอีกทางเลือก
    • ผมมองว่า subscription สำหรับบุคคลทั่วไปเป็นเหยื่อล่อที่ยอมขาดทุน รายได้จริงมาจาก สัญญาโทเคนระดับองค์กร
      เมื่อพนักงานและนักศึกษาคุ้นชินกับการเขียนโค้ดโดยใช้โทเคนมูลค่าหลายพันดอลลาร์บนแพลน 20 หรือ 100 ดอลลาร์ พวกเขาก็จะผลักดันให้บริษัทเพิ่มงบใช้จ่าย
      การมีโมเดลจีนที่แข่งขันได้อาจไม่ทำให้การใช้จ่ายระดับองค์กรนี้ถูกแทนที่ แต่โมเดลเปิดที่โฮสต์ในสหรัฐฯ หรือ EU อาจทำได้
      การมีอยู่ของ GLM 5.2 ช่วยสร้างเพดานให้กับราคาที่ OpenAI และ Anthropic จะตั้งกับการเข้าถึง API ได้
    • เป็นประเด็นสำคัญ ผมคิดว่าโมเดลราคาแบบ API อาจหายไปในที่สุด เหมือนกับการจ่ายเงินให้ MMS ที่หายไปแล้ว มันเป็นโมเดลเก่า
      ผมเดาว่างานส่วนใหญ่น่าจะเกิดขึ้นบน แพลนสำหรับโค้ดดิ้ง
      แต่ก็หงุดหงิดที่แพลนนอกจากจะมีลิมิตการใช้งานแล้วยังจำกัดอย่างอื่นมากเกินไป เข้าใจได้แต่ไม่สะดวก ในทางปฏิบัติดูเหมือนจะมีแค่ Anthropic และอาจรวม Google ที่เข้มงวดจริง ๆ
      Anthropic เคยทำให้คนกลัวด้วยนโยบายที่บอกว่า ถ้ามองว่าการใช้งานไม่ตรงตามข้อกำหนด ก็อาจมาเรียกเก็บตามอัตรา API ย้อนหลังได้ อาจเป็นความกังวลเกินเหตุ แต่ก็ให้ความรู้สึกว่าเขาน่าจะทำจริง เลยทำให้ผมเลี่ยง
    • ผมมีบัญชีและยอดคงเหลือใน OpenRouter ก็เลยลองทดสอบ GLM 5.2 แล้วตั้งใจจะไปดู subscription ของ z.ai โดยหวังว่าเงื่อนไขจะดีกว่า
      แต่โครงสร้างพื้นฐานฝั่งนั้นชัดเจนว่าโหลดเกิน จนคำขอแชต 5.2 timeout 100% ถ้าเมื่อไรโครงสร้างพื้นฐานตามประสิทธิภาพโมเดลทัน ค่อยกลับมาลองใหม่ แล้วตอนนั้นถึงจะตัดสินได้ว่าคุ้มกับ subscription ไหม

  • วันนี้ประหลาดใจที่ GLM-5.2 ทำงานด้านสุนทรียะและงาน UI ได้ดีกว่า GPT-5.5 มาก
    ช่วงนี้คงยังใช้ชุด Claude/Codex ผ่าน Conductor ต่อไป แต่เพราะโมเดลนี้เลยไปตั้งค่า OpenCode และดาวน์โหลดแอปเดสก์ท็อป จนวันนี้งานส่วนใหญ่ไปทำที่นั่น

  • พอเห็นประโยคอย่าง “GLM-5.2 มีค่าใช้จ่ายน้อยกว่ามาก Opus ทำเสร็จในครึ่งเวลาและได้เกมที่เนี้ยบกว่า” ก็รู้สึกถึง สำนวนแบบ LLM ขึ้นมาทันที
    เหมือนโมเดลทั้งหมดกำลังลู่เข้าหาสไตล์การเขียนแบบนี้ และถึงประสิทธิภาพจะดีขึ้น ส่วนนี้ก็ดูไม่ค่อยเปลี่ยน

    • เป็นฟีดแบ็กที่ดี สำนวนแบบ LLM นี้เป็นปัญหาที่เรากำลังเจอและพยายามปรับปรุงอยู่ตอนนี้

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

  • ดูเหมือนว่าผู้คนจริง ๆ จะเริ่มยอมรับ สำนวนแบบ LLM กันมากขึ้นแล้ว
  • ใช่ มันน่ารำคาญจริง ๆ ตอนนี้งานเขียนใหม่ประมาณครึ่งหนึ่งฟังดูเหมือนใช้ “เสียง” เดียวกันหมด