ความเจ็บปวดจากการปรับขนาดของ Zhipu: ข้อบกพร่องที่ซ่อนอยู่ภายใต้ภาระหนักและแนวทางหลีกเลี่ยงปัญหา

Scaling Pain ของ Zhipu: เปิดโปงบั๊กที่ซ่อนอยู่ภายใต้โหลดสูงและคู่มือหลีกเลี่ยง

Scaling คือความยุติธรรมหรือไม่? Zhipu ทำได้แค่ส่ายหัวอย่างช่วยไม่ได้ — กระบวนการนี้เจ็บปวดอย่างยิ่งและกดดันมหาศาล

บล็อกเทคนิคล่าสุดที่เผยแพร่โดย Zhipu เปลี่ยนโฉมหน้าไปอย่างสิ้นเชิง ไม่ได้นำเสนอเทคโนโลยีเจ๋งๆ เพียงอย่างเดียวอีกต่อไป แต่กลับระบายความยากลำบากอย่างละเอียด เปิดเผยประสบการณ์การสะดุดแปลกๆ ต่างๆ ตั้งแต่ GLM-5 เป็นต้นมา ซึ่งทางบริษัทเรียกสิ่งนี้ว่า 「Scaling Pain」

โครงสร้างพื้นฐานการอนุมานของเรากำลังเผชิญกับแรงกดดันที่ไม่เคยมีมาก่อน โดยต้องจัดการกับการเรียกใช้ Coding Agent หลายร้อยล้านครั้งต่อวัน

ในช่วงไม่กี่สัปดาห์ที่ผ่านมา ผู้ใช้บางรายที่ใช้โมเดลซีรีส์ GLM-5 เพื่อทำงาน Coding Agent ที่ซับซ้อน มักพบความผิดปกติ เช่น ข้อความรหัสเสีย การพูดซ้ำ และการสร้างอักขระหายาก

ที่ยุ่งยากกว่านั้นคือ ปัญหาเหล่านี้ ไม่สามารถจำลองซ้ำได้เลย ในสภาพแวดล้อมการอนุมานมาตรฐาน!!!

หลังจากตรวจสอบเป็นเวลาหลายสัปดาห์ ทีมงานก็สามารถจับตัวการที่อยู่เบื้องหลังได้ในที่สุด และเจาะทะลุบั๊กที่ซ่อนอยู่บนเส้นทางของ Scaling Laws อย่างสมบูรณ์

พวกเขาไม่เพียงแต่สรุปบทเรียนราคาแพงของตัวเองอย่างละเอียด แต่ยังให้ชุดคำแนะนำในการหลีกเลี่ยงที่นำไปปฏิบัติได้จริง

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

ระบุบั๊กสำคัญ

สาเหตุของเรื่องนี้เป็นดังนี้ —

นับตั้งแต่เปิดตัว GLM-5 Zhipu ได้สังเกตเห็นปรากฏการณ์ผิดปกติสามประเภทผ่านกระบวนการอนุมาน Coding Agent ขนาดใหญ่ของผู้ใช้:

• เอาต์พุตรหัสเสีย: เนื้อหายุ่งเหยิงไม่มีความหมาย;
• การสร้างซ้ำ: โมเดลส่งออกเนื้อหาเดียวกันอย่างต่อเนื่อง;
• อักขระหายาก: ปรากฏอักขระผิดปกติ

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

กล่าวอีกนัยหนึ่ง ตัวโมเดลเองไม่ใช่สาเหตุหลัก

หลังจากจำลองสภาพแวดล้อมออนไลน์เพิ่มเติม ทีมงานพยายามปรับอัตราส่วนการแยก PD และเพิ่มโหลดระบบอย่างต่อเนื่อง ในที่สุดความผิดปกติก็สามารถจำลองซ้ำได้ — ประมาณ 3-5 เอาต์พุตที่ผิดปกติต่อทุกๆ 10,000 คำขอ

สิ่งนี้บ่งชี้ว่าปรากฏการณ์ผิดปกติน่าจะเกิดจาก การจัดการสถานะการอนุมานภายใต้โหลดสูง ซึ่งชี้ไปที่ห่วงโซ่การอนุมานพื้นฐาน

แต่สิ่งนี้ก็ทำให้เกิดปัญหาอีกประการหนึ่ง: อัตราการจำลองซ้ำในระบบออฟไลน์ยังคงต่ำกว่าความถี่ของคำติชมออนไลน์ของผู้ใช้ แสดงว่าวิธีการตรวจจับที่มีอยู่มีช่องโหว่ หรือเงื่อนไขการกระตุ้นยังครอบคลุมไม่สมบูรณ์

ดังนั้นทีม Zhipu จึงปรับปรุงวิธีการตรวจจับเอาต์พุตที่ผิดปกติต่อไป พวกเขาพบว่าตัวบ่งชี้ Speculative Decoding สามารถใช้เป็นข้อมูลอ้างอิงสำคัญสำหรับการตรวจจับความผิดปกติ

Speculative Decoding เดิมใช้เพื่อปรับปรุงประสิทธิภาพการอนุมานของโมเดล: ขั้นแรก โมเดลขนาดเล็กจะสร้าง draft tokens จากนั้นโมเดลขนาดใหญ่จะตรวจสอบว่าโทเค็นเหล่านี้ได้รับการยอมรับหรือไม่ ในที่สุดก็เพิ่มประสิทธิภาพการถอดรหัสโดยไม่เปลี่ยนการกระจายเอาต์พุต

ในความผิดปกติสามประเภทของ GLM-5 ค่า spec_accept_length ของรหัสเสียและอักขระหายากต่ำมาก แสดงว่าสถานะ KV cache ของโมเดลเป้าหมายไม่ตรงกับโมเดล draft อย่างชัดเจน

ส่วนการพูดซ้ำมีค่า spec_accept_length สูงเกินไป แสดงว่า KV cache ที่เสียหายอาจทำให้รูปแบบความสนใจเสื่อมลง ผลักดันกระบวนการสร้างให้เข้าสู่วงจรการทำซ้ำที่มีความมั่นใจสูง

จากการสังเกตข้างต้น Zhipu สรุปชุด กลยุทธ์การตรวจสอบความผิดปกติออนไลน์:

เมื่อ spec_accept_length ต่ำกว่า 1.4 อย่างต่อเนื่องและความยาวการสร้างเกิน 128 โทเค็น หรือ spec_accept_rate เกิน 0.96 ระบบจะหยุดการสร้างปัจจุบันโดยอัตโนมัติ และส่งคำขอกลับไปยังตัวปรับสมดุลโหลด

จากนั้น Zhipu เริ่มวิเคราะห์สาเหตุของความผิดปกติเพิ่มเติม:

การแข่งขัน KV Cache ภายใต้สถาปัตยกรรมการแยก PD

ทีมงานวิเคราะห์วงจรชีวิตของคำขอและลำดับเวลาการดำเนินการแยก PD ในเอ็นจินการอนุมาน และระบุสาเหตุว่าเป็น ความไม่สอดคล้องกันระหว่างวงจรชีวิตของคำขอและลำดับเวลาการคืนค่าและนำ KV Cache กลับมาใช้ใหม่ ซึ่งทำให้เกิดความขัดแย้งในการนำ KV Cache กลับมาใช้ใหม่

เพื่อกำจัดสถานการณ์การแข่งขันนี้ นักวิจัยได้นำข้อจำกัดด้านลำดับเวลาที่เข้มงวดมากขึ้นมาใช้ในเอ็นจินการอนุมาน โดยสร้าง การซิงโครไนซ์อย่างชัดเจน ระหว่างการยุติคำขอและการเขียน KV Cache เสร็จสมบูรณ์

โดยเฉพาะ หลังจากออกคำสั่งหยุด เฟสถอดรหัสจะส่งการแจ้งเตือนไปยังเฟสเติมล่วงหน้า เฟสเติมล่วงหน้าจะส่งสัญญาณการคืนค่าที่ปลอดภัยก็ต่อเมื่อตรงตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้: ไม่ได้เริ่มการเขียน RDMA ใดๆ หรือการเขียนทั้งหมดที่ออกก่อนหน้านี้เสร็จสมบูรณ์แล้ว และเฟสถอดรหัสจะคืนค่าและนำช่อง KV Cache ที่เกี่ยวข้องกลับมาใช้ใหม่หลังจากได้รับการยืนยันนี้เท่านั้น

กลไกนี้ช่วยให้แน่ใจว่าการเขียน KV Cache จะไม่ข้ามขอบเขตการใช้หน่วยความจำซ้ำ จึงหลีกเลี่ยงความเสียหายของ KV Cache ข้ามคำขอ

หลังจากแก้ไขบั๊กนี้ในที่สุด อัตราการเกิดเอาต์พุตที่ผิดปกติลดลงจากประมาณ 0.1% เหลือต่ำกว่า 0.03%

การขาดลำดับเวลาการโหลด HiCache

นอกจากนี้ เมื่อการสลับ KV Cache ทับซ้อนกับการคำนวณ การใช้งานปัจจุบันไม่สามารถรับประกันได้ว่าข้อมูลจะถูกโหลดเสร็จก่อนการใช้งาน ทำให้เกิดสถานการณ์ที่ KV Cache ที่ยังไม่พร้อมถูกเข้าถึง

เพื่อแก้ไขปัญหานี้ ทีมงาน ปรับโครงสร้างกระบวนการอ่าน HiCache และนำข้อจำกัดการซิงโครไนซ์อย่างชัดเจนระหว่างการโหลดข้อมูลและการคำนวณมาใช้

ก่อนเริ่มตัวดำเนินการ Indexer ให้แทรกจุดซิงโครไนซ์ Load Stream ก่อนเพื่อให้แน่ใจว่าแคช Indexer ในระดับที่เกี่ยวข้องถูกโหลดอย่างสมบูรณ์ Forward Stream จะทำการคำนวณหลังจากข้อมูลพร้อมแล้วเท่านั้น จึงขจัดปัญหา read-before-ready

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

การเพิ่มประสิทธิภาพด้าน Prefill

ในความเป็นจริง บั๊กทั้งสองประเภทนี้ชี้ไปที่คอขวดของระบบทั่วไปเดียวกัน:

ในงาน Coding Agent Serving ที่มีบริบทยาว เฟส Prefill กลายเป็นปัจจัยหลักที่ส่งผลต่อประสิทธิภาพของระบบ

ดังนั้น เพื่อบรรเทาแรงกดดันด้านหน่วยความจำและแบนด์วิดท์ของเฟส Prefill ภายใต้การทำงานพร้อมกันสูง ทีมงานได้ออกแบบแผนการจัดเก็บ KV Cache แบบหลายชั้นเพิ่มเติม — LayerSplit

ในแผนนี้ แต่ละ GPU จะจัดเก็บเฉพาะ KV Cache ของบางชั้น ซึ่งช่วยลดการใช้หน่วยความจำของ GPU แต่ละตัวลงอย่างมาก จากนั้นก่อนดำเนินการคำนวณ Attention จะกระจาย KV Cache ของชั้นที่เกี่ยวข้องไปยัง rank อื่นๆ ที่เกี่ยวข้อง

เพื่อลดค่าใช้จ่ายในการสื่อสาร ทีมงานยังได้ออกแบบกลไกการทับซ้อนระหว่างการกระจาย KV Cache และการคำนวณ Indexer โดยซ่อนเวลาแฝงของการสื่อสารไว้ในกระบวนการคำนวณ ดังนั้นค่าใช้จ่ายในการสื่อสารเพิ่มเติมเพียงอย่างเดียวมาจากการกระจาย Indexer Cache ซึ่งมีขนาดเพียงหนึ่งในแปดของ KV Cache ทำให้ต้นทุนการสื่อสารโดยรวมแทบจะละเลยได้

ทีมงานรวม LayerSplit เข้ากับ GLM-5.1 และพบว่าเมื่ออัตราการ命中แคชถึง 90% และความยาวคำขออยู่ในช่วง 40k ถึง 120k ปริมาณงานของระบบเพิ่มขึ้น 10% ถึง 132% และเมื่อความยาวบริบทเพิ่มขึ้น ผลประโยชน์ก็เพิ่มขึ้นตามไปด้วย

โดยรวมแล้ว การเพิ่มประสิทธิภาพนี้ช่วยเพิ่มความสามารถในการประมวลผลของระบบในสถานการณ์ Coding Agent ได้อย่างมีนัยสำคัญ

ในขณะเดียวกัน Zhipu ยังเชื่อว่าเมื่อ AI เข้าสู่สถานการณ์ Coding Agent ที่มีการทำงานพร้อมกันสูงและบริบทยาวอย่างแท้จริง การรักษาคุณภาพเอาต์พุตของโครงสร้างพื้นฐานการอนุมานกลายเป็นสิ่งสำคัญยิ่ง สิ่งที่ AI ขนาดใหญ่ต้องการในอนาคตไม่ใช่แค่การเติบโตของความสามารถที่ขับเคลื่อนโดย Scaling Law แต่ยังต้องมีการสนับสนุนทางวิศวกรรมระบบในระดับที่เท่าเทียมกัน

ลิงก์อ้างอิง:
[1]https://z.ai/blog/scaling-pain
[2]https://www.zhipuai.cn/zh/research/159