เจาะประเด็น
Cloud / AI Infra
Google อวด GKE Pod Snapshots โหลดโมเดล 70B เสร็จใน 37 วิ แต่คำถามจริงคือเรื่องที่ยังไม่มีใครตอบ
ตัวเลขเร็วขึ้น 89% ฟังดูน่าตื่นเต้น แต่ปัญหาที่วิศวกรตัวจริงกำลังถกกันคือเรื่อง invalidation ที่โผล่มาเงียบๆ
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
ทำไมเรื่องนี้ถึงสำคัญ — เพราะความเร็วตอน start ไม่ใช่คอขวดเดียวของ AI infra อีกต่อไป แต่การรู้ว่า snapshot ไหนยังใช้ได้คือคอขวดใหม่ที่เพิ่งโผล่
กoogle ปล่อย benchmark ของฟีเจอร์ GKE Pod snapshots ออกมาแล้ว บอกเลยว่าตัวเลขที่โชว์ไม่ใช่เล่นๆ — startup latency ลดลงได้ถึง 89% และโมเดลขนาด 70B โหลดเสร็จภายใน 37 วินาที ฟังครั้งแรกก็ต้องร้องว่า "จริงดิ" เพราะถ้าใครเคยรอโมเดลใหญ่ๆ บูตบน cluster มาก่อน จะรู้ว่าปกติมันกินเวลาเป็นนาที ไม่ใช่หลักสิบวินาที
แต่เดี๋ยวก่อน ก่อนจะไปหลงตัวเลขสวยๆ มาเข้าใจก่อนว่ามันทำงานยังไง ฟีเจอร์นี้ทำ checkpoint ของ CPU และ GPU memory ผ่าน gVisor แล้วเก็บลง Cloud Storage พูดง่ายๆ คือแทนที่ pod จะต้องเริ่มจากศูนย์ใหม่ทุกครั้ง มันสามารถ "ปลุก" จากสภาพที่ถูกแช่แข็งไว้ได้เลย ซึ่งเป็นแนวคิดที่ไม่ใหม่ในโลก VM แต่การทำกับ pod ที่มี GPU memory อยู่ในนั้นคือคนละระดับความยาก
89% ที่ลดลงคือ startup latency ไม่ใช่เวลาทั้งหมดที่ผู้ใช้รอลดลง 89% นะ อันนี้ต้องแยกให้ชัด ส่วน 37 วินาทีสำหรับโมเดล 70B ก็ต้องดูบริบทว่าคือโมเดลอะไร ฮาร์ดแวร์แบบไหน และวัดจากจุดไหนถึงจุดไหน เพราะในงานจริง latency ของการโหลดโมเดลมักปนกับตัวแปรอื่นเยอะ ทั้ง network, storage tier และ contention บน node
ลด startup latency ได้ถึง 89%
ตัวเลขหลักที่ Google ใช้โปรโมตฟีเจอร์นี้ วัดจากการเทียบกับกรณีที่ pod ต้องเริ่มใหม่จากศูนย์
โมเดล 70B โหลดใน 37 วินาที
ตัวเลขที่ทำให้คนในวงการหันมามอง เพราะปกติใช้เวลาระดับนาที
checkpoint ผ่าน gVisor ลง Cloud Storage
กลไกเบื้องหลังที่ทำให้ pod กลับมาในสภาพเดิมได้ โดยไม่ต้องเริ่มใหม่
ประเด็นที่ practitioners ในวงการถามกลับมา และผมคิดว่าเป็นคำถามที่เฉียบกว่าตัวเลข benchmark เยอะ นั่นคือ "invalidation เป็นปัญหาที่ยากกว่าไหม" เพราะ snapshot ในระบบนี้ match กันด้วย spec hash, machine series และเวอร์ชันของ kernel กับ driver
ลองคิดดู — ถ้า kernel อัปเดต หรือ driver ของ GPU เปลี่ยนเวอร์ชัน snapshot เก่าที่เคยใช้ได้จะยังใช้ได้อยู่ไหม แล้วถ้าใช้ไม่ได้ ต้อง invalidate ยังไง ใครเป็นคนตัดสิน และจะรู้ได้ยังไงว่า snapshot ไหนยัง valid อยู่ ณ เวลาที่ pod กำลังจะบูต นี่คือคำถามที่ตัวเลข 89% ไม่ได้ตอบเลย
พูดตรงๆ ว่าการทำ snapshot ให้เร็วเป็นวิศวกรรมที่แก้ได้ด้วยการ optimize แต่การจัดการ lifecycle ของ snapshot ให้ถูกต้องตลอดเวลาในระบบที่เปลี่ยนตลอดคือ operational nightmare คนละแบบ และมันจะโผล่มาให้เจ็บตอนที่ระบบ scale ขึ้นจริง ไม่ใช่ตอน benchmark บนเครื่องทดสอบ
อีกมุมที่ต้องคิดคือเรื่องค่าใช้จ่าย Cloud Storage ที่ต้องเก็บ snapshot พวกนี้ไว้ ยิ่งเก็บเยอะ ยิ่งต้องจัดการ lifecycle ให้ดี ไม่งั้นค่า storage จะบานปลายแบบไม่รู้ตัว ซึ่งนี่ก็คือเหตุผลว่าทำไมชื่อฟีเจอร์ถึงมีคำว่า "Snapshot Lifecycle Management" อยู่ในนั้น
ตัวเลข 89% กับ 37 วินาทีมันน่าประทับใจก็จริง แต่ benchmark ไม่เคยโกหกเรื่องความเร็ว — มันแค่ไม่เล่าเรื่องความซับซ้อนที่ตามมา ของจริงจะตัดสินกันที่ว่า Google จัดการ invalidation ได้เนียนแค่ไหนตอนที่ทุกอย่างเปลี่ยนพร้อมกัน ไม่ใช่ตอนที่ทุกอย่างนิ่ง
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 6
กำลังโหลดความคิดเห็น...