Z.ai เปิดบันทึก: GLM-5.3 สร้างระบบ inference ของตัวเองบนชิปจีน 100,000 ตัว เร็วขึ้น 3 เท่าใน 2 สัปดาห์

วันที่ 17 กันยายน 2026 Z.ai เผยแพร่บทความชื่อ “Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure” ที่เปิดบันทึกภายในอย่างตรงไปตรงมาว่า ระบบ inference ระดับ production ที่ให้บริการ GLM-5.3-Flash อยู่ทุกวันนี้ ไม่ได้ถูกสร้างโดยทีมวิศวกร infra เพียงอย่างเดียว — งานส่วนใหญ่ทำโดย Infra Agent ที่ขับเคลื่อนด้วย GLM-5.3 เอง

ตัวเลขที่บริษัทให้มาคือ: สร้าง production-grade inference service จากศูนย์บนคลัสเตอร์ AI accelerator ผลิตในจีนมากกว่า 100,000 ตัว รองรับสถาปัตยกรรมโมเดลใหม่ คอนเท็กซ์ 1M token และ multimodal request — จากรันสำเร็จครั้งแรกจนถึงพร้อม production ใช้เวลาไม่ถึงสองสัปดาห์ และดัน end-to-end throughput ขึ้นราว 3 เท่า จากเบสไลน์เริ่มต้น บทความยืนยันด้วยว่า GLM-5.3-Flash คือโมเดลที่เคยทดสอบใน OpenCode และ OpenRouter ภายใต้ชื่อนิรนาม Ox-Alpha และภายในหนึ่งสัปดาห์หลังเปิดตัวก็กลายเป็นโมเดลที่ถูกใช้มากที่สุดบนทั้งสองแพลตฟอร์ม ประมวลผลไปกว่า 62 ล้านล้าน token ใน 6 วัน

”Dense feedback” คือแก่นของเรื่อง ไม่ใช่ขนาดโมเดล

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

ทีมอธิบายปัญหาไว้ชัด: codebase ให้แค่ context แบบ static ส่วนความคลาดเคลื่อนเชิงตัวเลข การถดถอยของ performance หรือการพลาดเป้า optimization ในระบบ inference มักเกิดจากปฏิสัมพันธ์แบบ dynamic ข้ามหลายชั้น — kernel, กลยุทธ์ parallelism, พฤติกรรม communication, การจัดการหน่วยความจำ, การ orchestrate การเสิร์ฟ ดังนั้นต่อให้ agent เข้าใจโค้ดทั้งก้อน feedback แบบ “numerical accuracy test failed”, “TTFT เพิ่ม 30%” หรือ “output throughput ลด 20%” ก็ยังบอกไม่ได้ว่าชั้นไหนผิด สมมติฐานปัจจุบันผิดตรงไหน และควรทดสอบอะไรต่อ ตามคำของทีมเอง: “End-to-end metrics can tell an agent that results got worse, but they cannot explain why.”

คำตอบของ Z.ai คือสิ่งที่เรียกว่า dense feedback ซึ่งย้ำว่า “dense” ไม่ได้แปลว่ายัด log และ metric ให้ agent มากที่สุด แต่หมายถึง feedback ที่มีสามคุณสมบัติ:

1. local พอ — ผูกกับ launch parameter, code change, kernel, input condition, thread, ช่วงเวลา execution หรือ code path ที่เจาะจงได้
2. ได้มาถูกและทันเวลา — ทุกครั้งที่ agent ตั้งสมมติฐานหรือแก้โค้ด ต้องมีวิธีตรวจสอบที่เหมาะสมทันที ไม่ใช่รอ deploy เต็มระบบแล้วยิง load test ใหม่ทุกรอบ
3. ตรวจสอบได้อย่างภววิสัย — ยืนยันได้ว่าจริงหรือไม่จริง

ในทางปฏิบัติคือการยัด correctness test, runtime log, execution trace, runtime event, microbenchmark และ end-to-end metric เข้าไปในลูปทำงานของ agent แล้วซอยกระบวนการ optimization ทั้งระบบเป็นขั้นที่สังเกตและตรวจสอบได้ในระดับ local

สามเคสจริงที่ agent แก้ได้เพราะ feedback ไม่ใช่เพราะโมเดลเก่ง

บทความยกสามเคสที่ต่างชั้นกันมาเป็นตัวอย่าง และแต่ละเคสตอบคำถามคนละแบบ:

ความถูกต้องเชิงตัวเลข (correctness) — ทีมสร้าง mapping จากกลยุทธ์ parallelism ของ inference engine ไปยัง kernel implementation เพื่อแปลง deployment config ระดับระบบให้เป็นงานตรวจ kernel ทีละตัวที่ agent ทำเองได้ จากนั้นให้ agent เทียบผลลัพธ์ระหว่าง execution path ที่แบ่งพาร์ทิชันกับที่ไม่แบ่ง กระบวนการนี้เองที่ทำให้เจอบั๊กความแม่นยำใน KDA kernel บนเส้นทาง Context Parallelism (CP) ซึ่งต้นตออยู่ที่การ merge state ข้าม context shard และ precision ของการคูณเมทริกซ์ (ทางแก้ผูกกับ input_precision="tf32x3")

พฤติกรรมระบบ (system behavior) — วิศวกรตั้งซีนาริโอทดสอบแยกเป็น Prefill อย่างเดียว, Prefill + KV Transfer และ Decode อย่างเดียว พร้อมเกณฑ์รับว่า Prefill + KV Transfer ต้องช้ากว่า Prefill เปล่าไม่เกิน 5% แต่ agent พบว่าบางกรณีห่างเกิน 20% แล้วไล่ timeline จนเจอว่า KV Transfer ฝั่ง Python ไม่เคยทับซ้อนกับช่วง DeepEP dispatch/combine เลย สาเหตุคือ การเข้าโค้ด C++ ไม่ได้ปล่อย GIL อัตโนมัติ ทำให้เธรด Mooncake Transfer ในโปรเซสเดียวกันคว้า GIL ไม่ทัน การ submit งานโอนย้ายจึงถูกหน่วง หลังแก้ให้ปล่อย GIL ในช่วง C++ ที่เกี่ยวข้อง ช่องว่างเหลือ ต่ำกว่า 1%

ประสิทธิภาพ (performance) — ทีมให้ agent ไปเรียนเทคนิคจาก kernel ที่เขียนมือในโปรเจกต์อย่าง SGLang, Flash Linear Attention และ DeepGEMM แล้วกลั่นเป็น “optimization skeletons” ที่บรรจุเงื่อนไขการใช้งาน วิธีแปลง ข้อจำกัดทรัพยากร และหลักฐานการตรวจสอบ ในเคส KDA Decode kernel ตัวอย่าง agent พบว่าโค้ดเดิม tile ตามมิติ V ทำให้การคำนวณ FP32 normalization และ gating ซ้ำสี่รอบ จึงรวม tile เข้าเป็น thread block เดียว เก็บผลลัพธ์กลางไว้ในรีจิสเตอร์ และแทนที่การคำนวณซ้ำด้วย warp-level reduction ครั้งเดียว — ได้ เร็วขึ้น 1.71 เท่า เทียบ v2 (ก่อนหน้านั้น division optimization ลดเวลา v1 ลง 9.6%)

สแต็กที่ได้ออกมาประกอบด้วย intra-node tensor parallelism สำหรับ linear attention และ LM Head, ReplaySSM, quantization W8A8, cache quantization ผสม INT8/FP8/BF16, Layer Split และสถาปัตยกรรม Encode-Prefill-Decode (EPD) disaggregated ซึ่งรวมกันแล้วดัน serving performance ขึ้นราว 3 เท่า และทีมอ้างว่าทั้งประสิทธิภาพการใช้ฮาร์ดแวร์และต้นทุนต่อ token ไปถึงระดับที่เทียบเคียงกับ GPU ของ NVIDIA กระแสหลัก

ยังไม่ใช่ RSI — และบริษัทก็บอกเองว่ายัง

Z.ai ไม่ได้ขายว่านี่คือ recursive self-improvement เต็มรูป บทความปิดท้ายตรง ๆ ว่า “Of course, we have not yet reached recursive self-improvement. Choosing objectives, setting boundaries, and assessing risk remain human responsibilities. We believe humans should continue to hold that line for a long time to come.”

หน้าที่ของวิศวกรที่ระบุไว้ยังมีสามอย่างชัดเจน: กำหนดเป้าหมายและขอบเขตของระบบ, สร้างสภาพแวดล้อม feedback ที่ agent ใช้ได้ตรง ๆ, และรีวิวการเปลี่ยนแปลงสำคัญที่แตะสถาปัตยกรรม ความพร้อมกันแบบอะซิงโครนัส และความเสี่ยงระดับ production

ข้อควรระวังสำหรับผู้อ่าน: นี่เป็นบล็อกของผู้ผลิตเอง ตัวเลข 3 เท่า สองสัปดาห์ และ “เทียบเท่า NVIDIA” ยังไม่มีการตรวจสอบจากภายนอก และบทความไม่ได้ระบุยี่ห้อ/รุ่นของ accelerator จีนที่ใช้ กราฟประกอบ (Figure 1–4) ก็เป็นข้อมูลภายในทั้งหมด

มุมมอง AI Curator

เรื่องนี้ถูกอ่านเป็นข่าว “AI สร้าง AI” ได้ง่าย แต่สิ่งที่ควรเอากลับบ้านจริง ๆ อยู่คนละที่

บทเรียนที่ใช้ได้กับทุกทีมคือ ปัญหาของ coding agent ในงานระบบไม่ใช่ปัญหาโมเดล แต่เป็นปัญหา observability เราเห็นทีมไทยหลายทีมเสียเวลาไปกับการหาโมเดลที่ “ฉลาดกว่า” มาแก้บั๊กใน service ที่ไม่มี trace ไม่มี microbenchmark ไม่มี kernel-level test — ซึ่งก็คือการส่ง agent เข้าไปเดาในความมืด สิ่งที่ Z.ai ทำจริง ๆ คือลงทุนสร้าง “ห้องแล็บ” ให้ agent ก่อน แล้วค่อยปล่อยมันเข้าไปทดลอง คำถามที่ควรถามตัวเองจึงไม่ใช่ “ใช้โมเดลไหนดี” แต่คือ “ระบบของเราตอบคำถาม ‘เวลาหายไปไหน’ ให้ agent ได้ในกี่วินาที และถูกกว่าการ deploy ใหม่หรือเปล่า”

มิติที่สองที่คนมักมองข้ามคือ ภูมิรัฐศาสตร์ของชิป ตัวเลขที่น่าสนใจที่สุดในบทความไม่ใช่ “3 เท่า” แต่คือ “100,000 accelerator ผลิตในจีน” กับเงื่อนไขที่ทีมบรรยายไว้ว่า memory และ bandwidth จำกัด ecosystem ยังไม่สุก kernel support ไม่ครบ และเอกสารที่ควรมีต้อง “เดาเอา” — นั่นคือคำอธิบายว่าทำไม agent ถึงคุ้ม: เมื่อไม่มีเอกสารและไม่มี Stack Overflow ให้พึ่ง การทดลองซ้ำ ๆ ด้วยต้นทุนต่ำกลายเป็นวิธีที่ได้เปรียบกว่าประสบการณ์มนุษย์ แปลว่าข้อจำกัดด้านการส่งออกชิปกำลังผลักจีนไปลงทุนกับ automated systems engineering แทนที่จะรอฮาร์ดแวร์ที่ดีกว่า ซึ่งเป็นความสามารถที่ย้ายไปใช้กับฮาร์ดแวร์รุ่นถัดไปได้ทันที

สำหรับ SEA มีนัยเชิงต้นทุนที่จับต้องได้: ถ้าต้นทุนต่อ token ของ GLM-5.3-Flash ไปถึงระดับ NVIDIA จริงบนฮาร์ดแวร์ที่ไม่ติดข้อจำกัดการส่งออก โมเดลเปิดจากจีนจะยิ่งกดราคา inference ในภูมิภาคลงอีก และตัวเลข “62 ล้านล้าน token ใน 6 วันบน OpenRouter” บอกว่านักพัฒนาจำนวนมากก็เลือกตามราคาอยู่แล้ว — โดยไม่รู้ด้วยซ้ำว่าตอนทดสอบมันชื่อ Ox-Alpha

สุดท้าย ประโยคที่ควรอ่านซ้ำคือประโยคที่ทีมเขียนเองว่า GLM “is moving steadily toward replacing us” — พูดโดยทีมที่สร้างมันขึ้นมา และยังบอกในย่อหน้าเดียวกันว่ามนุษย์ควรถือเส้นนั้นไว้ต่อไปอีกนาน ความย้อนแย้งนั้นแหละคือสถานะจริงของอุตสาหกรรมตอนนี้

แหล่งข่าว

• Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure — Z.ai Blog (17 ก.ย. 2026)
• How GLM built its own inference infrastructure — Hacker News discussion
• GLM-5.3-Flash open weights (MIT) — รายงานก่อนหน้าของเรา
• Ox-Alpha โมเดลนิรนามบน OpenRouter — รายงานก่อนหน้าของเรา