GLM ช่วยสร้าง inference stack ของตัวเอง: ยังไม่ใช่วงจร self-improvement ปิด

Z.ai รายงานว่า GLM-5.3 agents ช่วยวิเคราะห์ แก้ code และ optimize inference infrastructure ที่ใช้เสิร์ฟ GLM-5.3-Flash จน throughput ดีขึ้นหลายช่วงในเวลาประมาณสิบสามวันครับ นี่เป็นตัวอย่างแรงของ AI-for-AI engineering แต่หัวข้อ “recursive self-improvement” ต้องใช้ด้วยความระวัง เพราะคนยังตั้งเป้าหมาย กำหนด constraints review patch ตัดสิน production risk และควบคุม rollout วงจรจึงยังไม่ปิดเอง

เกิดอะไรขึ้น: สรุป 30 วินาที

ใน รายงานทางการของ Z.ai agent ถูกใช้กับงาน inference stack หลายชั้น ตั้งแต่ kernel/quantization, scheduling, memory/data movement ไปจนถึงการหา bug และปรับ throughput ทีมอธิบายกระบวนการแบบ hypothesis—code—benchmark—diagnose—iterate และอ้างผลสะสมสูงสุดราว 3.22 เท่าจาก baseline W8A8 ในกราฟของกรณีศึกษา

Origins AI สรุปตัวเลขและย้ำข้อจำกัดที่สำคัญว่า Z.ai เองไม่ได้ประกาศว่าบรรลุ recursive self-improvement แบบอัตโนมัติเต็มรูป: มนุษย์ถือ objective, constraints และ production decisions ขณะที่ งานวิจัยเรื่อง AI research agents เสนอกรอบกว้างว่าระบบเริ่มช่วยปรับ training/inference stack ได้ แต่ระดับ autonomy กับ loop closure ต้องวัดเป็นแกน ไม่ใช่ป้าย yes/no

ทำไมเรื่องนี้เกี่ยวกับคุณ

ทีม platform ไม่ต้องสร้าง frontier model ก็เจอ pattern เดียวกัน Agent สามารถอ่าน profiler, เสนอ patch, รัน benchmark และสรุป regression ได้เร็วขึ้น แต่ infrastructure performance เป็นพื้นที่ที่ optimization หนึ่งจุดอาจทำให้ correctness, tail latency, memory pressure หรือ portability แย่ลง การเห็น throughput สูงขึ้นไม่ได้แปลว่าระบบดีขึ้นทุกมิติ

ข่าวนี้จึงเป็นแบบฝึกเรื่อง evidence pipeline หาก agent แก้ code ที่ใช้เสิร์ฟ agent รุ่นถัดไป เราต้องแยกสามอย่าง: capability improvement ของโมเดล, efficiency improvement ของระบบเสิร์ฟ และ process improvement ของทีม ทั้งสามทำให้ผลิตผลดีขึ้นได้ แต่มีความหมายด้าน safety/governance ต่างกัน การเรียกทุกอย่างว่า model self-improves ทำให้เรามองข้ามจุดควบคุมที่คนกับระบบ CI ยังถืออยู่

สำหรับผู้บริหาร ผลกระทบไม่ได้มีแค่ลด GPU ต่อ token ถ้า iteration เร็วขึ้น ทีมอาจทดลองมากขึ้นและส่ง release ถี่ขึ้น ความเสี่ยง supply chain, benchmark gaming และ silent regression ก็เพิ่มตาม ความเร็วที่ไม่มี gate ทำให้ incident มาถึง production เร็วขึ้นเช่นกัน

ทำงานยังไง: วงจร agentic optimization ที่ตรวจสอบได้

เริ่มจาก objective ที่วัดได้ เช่น tokens ต่อวินาทีภายใต้ latency percentile, memory ceiling และ accuracy tolerance ที่ระบุ จากนั้น agent อ่าน trace/profiler สร้าง hypothesis เลือกตำแหน่งแก้ code และรัน microbenchmark Patch ที่ผ่าน microbenchmark ต้องไป integration test กับ model output, workload mix และ hardware หลายแบบ ก่อน canary จริง คนหรือ policy engine ตัดสินว่าหลักฐานครบพอ merge/rollout หรือไม่

อุปมาเหมือนช่างปรับเครื่องสีข้าว ช่างอาจเปลี่ยนสายพานจนกระสอบออกเร็วขึ้น แต่ต้องชั่งว่าข้าวแตกมากขึ้นไหม มอเตอร์ร้อนเกินหรือไม่ และเครื่องรุ่นอื่นยังใช้ได้ Agent ทำหน้าที่ช่างที่ลองแบบได้เร็ว ส่วน benchmark suite คือเครื่องชั่งและเซนเซอร์ ห้ามให้ช่างเป็นคนตั้งเครื่องชั่งใหม่เพื่อทำให้ผลงานตัวเองผ่านโดยไม่มี review

จุดสำคัญคือ separation of duties Agent ที่แก้ code ไม่ควรแก้ acceptance threshold, golden outputs หรือ telemetry filter ใน change เดียวกัน ถ้าจำเป็นต้องเปลี่ยน benchmark ต้องเปิด change แยก มีเหตุผลและ review จากเจ้าของ metric เก็บ raw results กับ environment fingerprint เช่น GPU/driver/compiler/model commit และ dataset hash เพื่อให้ย้อนวัดได้

สำหรับงาน performance ต้องกัน warm-up, cache state, clock throttling, noisy neighbor และ sampling bias ทำ A/B หลายรอบ สลับลำดับ build และรายงาน distribution ไม่เลือกเฉพาะ best run วัด tail latency กับ error/correctness ควบคู่ throughput เพราะระบบ serving ที่เร็วเฉลี่ยแต่ p99 แย่หรือ output เพี้ยนไม่ใช่ optimization

ขอบเขตของคำว่า recursive self-improvement

วงจรจะ “recursive” เข้มขึ้นเมื่อ output ของระบบช่วยเปลี่ยนความสามารถสร้างระบบรุ่นถัดไป และวงจรนั้นทำซ้ำได้โดยมีการแทรกแซงมนุษย์ลดลง แต่ยังมีหลายระดับ ตั้งแต่ agent ช่วย engineer เขียน patch, agent ออกแบบ experiment, agent เลือก objective ไปจนถึงระบบ deploy รุ่นใหม่และปรับ evaluator เอง กรณี Z.ai ที่เปิดเผยมีหลักฐานชัดในระดับช่วยงานวิศวกรรมและ optimization แต่คนยังถือจุดสำคัญ

Axios รายงานการถกเถียงว่า feedback loop เริ่มใกล้ขึ้นแต่ benchmark ที่อ้างวัด RSI ยังไม่แสดงว่าระบบถึงจุดปิดวงเต็ม นักวิจารณ์มองว่าหลาย milestone คือ coding automation ที่เก่งขึ้น ไม่ใช่โมเดลที่เปลี่ยน objective/evaluator และสืบทอดความสามารถโดยไร้การกำกับ ความแตกต่างนี้สำคัญต่อ policy: เราควรคุมสิทธิ์จริงที่ระบบมี มากกว่าตัดสินจากชื่อใหญ่

เรื่องเงินและผลกระทบ

Inference efficiency มีผลตรงกับต้นทุน GPU, capacity และ latency ถ้า throughput เพิ่มโดยคุณภาพคงเดิม ทีมเสิร์ฟ request มากขึ้นบน hardware เดิมหรือใช้เครื่องน้อยลง แต่กราฟ improvement ต้องแยกว่า gain มาจาก quantization, kernel, batching, scheduling, cache หรือ workload assumption เพราะบาง gain ไม่รวมกันบน traffic จริง และบางเทคนิคเปลี่ยนความแม่นยำ

ต้นทุนอีกส่วนคือ engineering verification Agent อาจสร้าง patch จำนวนมากจน reviewer เป็นคอขวด ถ้า review ทุก patch แบบผิวเผิน ความเร็วรวมดูสูงแต่ defect escape เพิ่ม ควรจำกัด work in progress ให้ agent ส่ง hypothesis พร้อม evidence package ไม่ใช่ diff อย่างเดียว Evidence package ควรมี baseline, change isolation, correctness results, performance distribution, hardware scope และ rollback signal

เมื่อ agent ใช้ model/API ที่รันบน infrastructure เดียวกับระบบที่กำลังปรับ อาจเกิด circular dependency เช่น performance degradation ทำให้ agent ช้าหรือ retry มากขึ้นจน load เพิ่มอีก Control plane สำหรับ evaluation และ rollback ควรแยกจาก serving plane ที่ถูกทดลอง มี quota และ kill switch ที่ไม่พึ่ง component เดียวกัน

ความเสี่ยงด้าน security และ supply chain

Agent ที่มี shell, compiler, profiler, package manager และ cluster access มีสิทธิ์สูง Prompt injection อาจมาจาก issue, log, benchmark output, source comment หรือ dependency metadata ไม่ใช่แค่ข้อความผู้ใช้ ให้ treat ข้อมูลเหล่านี้เป็น untrusted data แยกคำสั่ง control จาก evidence และไม่ให้ agent เปลี่ยน credential/network scope ตามข้อความที่อ่าน

ใช้ ephemeral workspace, read-only production telemetry, dependency lock, offline build เมื่อทำได้ และ egress allowlist เก็บ secret ออกจาก environment ที่ tool child process เห็น การ deploy ต้องผ่าน signed artifact, provenance และ policy เดิมไม่ว่าผู้เขียน patch เป็นคนหรือ agent ห้าม bypass review เพราะ benchmark ดี และห้าม agent push main หรือแก้ production ตรง

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ตัวเลข 3.22 เท่าเป็นผลจากกรณีศึกษาและ baseline ที่ Z.ai เลือก ยังไม่ใช่ independent benchmark ครบทุก workload/hardware รายละเอียดบางส่วนของ production stack, failure runs และจำนวนข้อเสนอที่ไม่ผ่านไม่ได้เผยครบ จึงคำนวณ success rate ของ agent หรือ engineering-hours saved อย่างเป็นกลางไม่ได้

คำว่า “built its own infrastructure” ใน headline เน้นบทบาท GLM แต่รายงานละเอียดมี human direction และ production ownership Origins AI ช่วยใส่บริบทนี้ ส่วนบทความอภิปราย RSI บางแห่งใช้กรณีนี้เป็นสัญญาณทางไปสู่ self-improvement ที่กว้างกว่า ทั้งสองมุมพูดถึงคนละระดับ ผู้อ่านควรเก็บความสำเร็จเชิงวิศวกรรมไว้โดยไม่ขยายเป็นข้ออ้างว่าโมเดลปรับตัวเองอิสระแล้ว

ยังไม่ชัดว่าผล transfer ไปทีมขนาดเล็กหรือ model อื่นเพียงใด Z.ai มี access ต่อ source, experts, compute และ telemetry ที่ลึกกว่าผู้ใช้ทั่วไป Tooling กับ harness อาจมีส่วนมากพอ ๆ กับตัว model การลอก prompt โดยไม่มี benchmark discipline และ sandbox เดียวกันไม่น่าทำซ้ำผล

แล้วเราควรทำอะไร

เริ่ม pilot กับ component ที่ rollback ง่ายและ correctness ตรวจชัด เช่น serialization path หรือ kernel ที่มี golden tests ห้ามเริ่มจาก scheduler production ทั้งระบบ เขียน metric contract ก่อนเปิด agent: throughput, p95/p99, memory, output parity, supported hardware และ regression budget ระบุว่า agent แก้ source ได้แต่แก้ metric/test threshold ไม่ได้

ให้ agent ส่ง hypothesis หนึ่งเรื่องต่อ change รัน benchmark ใน isolated runner แล้วสร้าง evidence bundle คน review ทั้งกลไกและผล ถ้าผ่านให้ canary บน traffic จำลองก่อน production canary ใช้ automatic rollback จาก signal ที่กำหนดล่วงหน้า และต้องมี manual kill switch นอก agent control

หลังหลายสิบรอบ วัด acceptance rate, false improvements, reviewer time, escaped regressions และ net cost ไม่ใช่นับจำนวน patch ถ้า agent เสนอของซ้ำหรือ optimize benchmark มากกว่าระบบจริง ให้ปรับ context/tooling/evaluator ก่อนเพิ่ม autonomy สิทธิ์ควรขยายจากประวัติหลักฐาน ไม่ใช่จาก demo ที่ดีที่สุด

Recap

• แยก model capability, serving efficiency และ team process ให้ชัด
• ตั้ง metric contract ก่อน agent เห็น code
• ห้าม change เดียวแก้ implementation กับเกณฑ์ผ่าน
• วัด correctness, tail latency, memory และหลาย hardware พร้อม throughput
• ใช้ ephemeral workspace, locked dependencies และ read-only telemetry
• deploy ด้วย provenance, canary, rollback และ human gate เดิม
• เรียกกรณีนี้ว่า agent-assisted infrastructure improvement จนกว่าวงจร autonomy จะมีหลักฐานมากกว่าเดิม