ModelExpress (MX): เร่งการกระจายโมเดล AI ให้เร็วขึ้น

ModelExpress (MX): เร่งการกระจายโมเดล AI ให้เร็วขึ้นการย้ายข้อมูลแต่ละไบต์มีค่าใช้จ่าย โดยเฉพาะอย่างยิ่งเมื่อโมเดล AI มีขนาดใหญ่หลายร้อยกิกะไบต์ หรืออาจถึงเทราไบต์ การเคลื่อนย้ายข้อมูลน้ำหนักโมเดล (model weights) ไปมาระหว่างเซิร์ฟเวอร์ในคลัสเตอร์เป็นเรื่องที่เกิดขึ้นบ่อยครั้ง ไม่ว่าจะเป็นการโหลดโมเดลครั้งแรก (cold start) การปรับขนาดอัตโนมัติ (autoscaling) การอัปเดตโมเดล (rolling updates) หรือการฝึกอบรมหลังการปรับใช้ (RL post-training) กระบวนการเหล่านี้ล้วนใช้เวลาไปกับการย้ายข้อมูลก่อนที่โมเดลจะเริ่มทำงานจริง NVIDIA ModelExpress (MX) ถูกพัฒนาขึ้นเพื่อแก้ปัญหานี้ โดยการเร่งวงจรชีวิตของน้ำหนักโมเดลให้มีประสิทธิภาพสูงสุด ด้วยการเลือกเส้นทางการถ่ายโอนที่เร็วที่สุดModelExpress (MX) คืออะไร?MX คือแพลตฟอร์มที่ออกแบบมาเพื่อเพิ่มความเร็วในการจัดการน้ำหนักโมเดล AI โดยมีแนวคิดหลักคือ "ก่อนที่จะโหลดโมเดล ให้ตรวจสอบก่อนว่ามีสำเนาที่เข้ากันได้ของน้ำหนักโมเดลอยู่ที่ใด" แทนที่จะปฏิบัติต่อทุกการทำงานใหม่เหมือนการเริ่มต้นจากศูนย์ MX จะเลือกแหล่งที่มาและเส้นทางการถ่ายโอนที่เร็วที่สุดที่มีอยู่เมื่อเซิร์ฟเวอร์ที่ให้บริการ (serving peer) มีน้ำหนักโมเดลที่เข้ากันได้อยู่ในหน่วยความจำ GPU อยู่แล้ว MX จะทำการถ่ายโอนข้อมูลโดยตรงจาก GPU ไปยัง GPU ผ่าน P2P RDMA โดยใช้ NVIDIA Inference Xfer Library (NIXL) ซึ่งจะข้ามขั้นตอนการเข้าถึงที่ซ้ำซ้อนไปยังที่จัดเก็บข้อมูลแบบอ็อบเจกต์ (object storage) หน่วยความจำโฮสต์ (host memory) หรือดิสก์ในเครื่อง ทำให้ลดเวลาการเริ่มต้นระบบลงได้อย่างมากการเร่งความเร็วในทุกขั้นตอน: จากที่จัดเก็บระยะไกลสู่หน่วยความจำ GPUการเริ่มต้นทำงานของแต่ละเวิร์กเกอร์ใหม่จำเป็นต้องได้รับน้ำหนักโมเดลจากสามแหล่งหลัก:ที่จัดเก็บข้อมูลระยะไกล (Remote storage): เช่น Hugging Face หรือ S3ที่จัดเก็บข้อมูลในเครื่อง (Local storage): ฮาร์ดดิสก์หรือ SSD ในเซิร์ฟเวอร์เวิร์กเกอร์อื่นที่กำลังให้บริการโมเดลอยู่แล้ว (Serving peer):สำหรับเวิร์กเกอร์ตัวแรกที่ยังไม่มี peer ที่ให้บริการ MX จะเริ่มต้นจากเส้นทางที่เร็วที่สุดเท่าที่ระบบรองรับ โดยสามารถสตรีมข้อมูลจาก object store โดยตรงไปยัง GPU โดยไม่ต้องบันทึกลงดิสก์ในเครื่อง หรือโหลดจากที่จัดเก็บในเครื่องโดยตรงเข้าสู่หน่วยความจำ GPUการเริ่มต้นเวิร์กเกอร์ตัวแรก: บูตสตราปจากที่จัดเก็บข้อมูลจาก Remote Object Storage สู่ GPU: หลีกเลี่ยงการใช้ดิสก์ในเครื่องเมื่อโมเดลถูกเก็บไว้ในคลาวด์บัคเก็ต และคุณไม่ต้องการจัดการแคชบนดิสก์ MX จะใช้ Model Streamer ดึงข้อมูล safetensors ผ่านบัฟเฟอร์ CPU ชั่วคราวที่สามารถนำกลับมาใช้ใหม่ได้ แล้วส่งเข้าสู่ GPU โดยตรง โมเดลจะไม่ถูกบันทึกลงดิสก์ในเครื่อง ลดขั้นตอนการดาวน์โหลด การโหลดซ้ำ และการใช้พื้นที่จัดเก็บModel Streamer ใช้เทรดหลายตัวเพื่ออ่านข้อมูลเทนเซอร์ (tensor) แบบขนานจาก shard ต่างๆ ของโมเดล เมื่อข้อมูลมาถึง ระบบจะส่งต่อข้อมูลไปยังเอนจิ้นการอนุมาน (inference engine) ในขณะที่เทนเซอร์ส่วนที่เหลือยังคงกำลังถูกดึงมา วิธีนี้ช่วยให้เส้นทางการอ่านจากที่จัดเก็บ เครือข่าย และการคัดลอกไปยัง GPU ทำงานอย่างต่อเนื่อง โดยใช้หน่วยความจำโฮสต์ในปริมาณที่จำกัดการนำเข้าข้อมูลสู่คลัสเตอร์: ดาวน์โหลดครั้งเดียว ไม่ใช่ N ครั้งหากคลัสเตอร์มีการใช้งานแคชบนดิสก์ร่วมกัน (เช่น persistent volumes ใน Kubernetes) MX จะรับประกันว่าทั้งฟลีตจะดาวน์โหลดข้อมูลเพียงครั้งเดียวเท่านั้น หากมี 10 เวิร์กเกอร์ที่ต้องการดึงโมเดล DeepSeek-V4 Pro ขนาด 806 GiB พร้อมกัน ซึ่งต้องดึงข้อมูลประมาณ 8 TiB ผ่านเครือข่าย MX Model Cache Service จะรวมคำขอเหล่านั้นให้เป็นการดาวน์โหลดที่ประสานงานกันเพียงครั้งเดียว โดยการเคลมแบบอะตอมมิกใน Metadata Store จะเลือกดาวน์โหลดเดอร์หนึ่งตัว และเวิร์กเกอร์ที่เหลือจะติดตามความคืบหน้าและนำแคชที่สร้างขึ้นมาใช้ซ้ำจาก Local Storage สู่ GPU: ข้ามการใช้ Host Memoryหากระบบรองรับ GPUDirect Storage (GDS) MX จะอ่านไฟล์เช็คพอยต์โดยตรงจากที่จัดเก็บในเครื่องเข้าสู่หน่วยความจำ GPU ผ่านแบ็กเอนด์ GDS แบบมัลติเธรดของ NIXL โดย NIXL จะดำเนินการอ่านเทนเซอร์แบบแบทช์พร้อมกันโดยตรงไปยังหน่วยความจำ GPU ซึ่งข้าม Host Memory และขั้นตอนการคัดลอกชั่วคราวที่จำเป็นสำหรับโหลดเดอร์ทั่วไป ผู้ใช้ไม่จำเป็นต้องเปิดใช้งาน GDS อย่างชัดเจน MX จะตรวจจับความสามารถนี้โดยอัตโนมัติและจะเปลี่ยนไปใช้วิธีการโหลดอื่นหาก GDS ไม่พร้อมใช้งานการเริ่มต้นเวิร์กเกอร์ทุกตัวหลังตัวแรก: ดึงข้อมูลจาก Serving Peerนี่คือคุณสมบัติหลักของ MX เมื่อมี replica ตัวอื่นกำลังให้บริการโมเดลเดียวกันอยู่แล้ว น้ำหนักโมเดลส่วนใหญ่ได้เดินทางมาถึงปลายทางแล้ว: อยู่ในหน่วยความจำ GPU ประมวลผลเบื้องต้น และจัดเตรียมไว้สำหรับเอนจิ้นการอนุมาน MX จะถือว่า replica นั้นเป็นแหล่งข้อมูลน้ำหนักที่มีชีวิต หลังจากยืนยันความเข้ากันได้แล้ว ระบบจะถ่ายโอนเทนเซอร์โดยตรงจาก GPU ต้นทางไปยัง GPU ปลายทาง เมื่อโหลดน้ำหนักเสร็จสิ้น เวิร์กเกอร์ใหม่จะเข้าร่วมกลุ่มแหล่งข้อมูล ทำให้เวิร์กเกอร์ถัดไปมี peer เพิ่มขึ้นสำหรับการโหลดการปรับปรุงประสิทธิภาพการลงทะเบียนหน่วยความจำ NIXLก่อนที่ NIXL จะสามารถทำการ RDMA เทนเซอร์ได้ หน่วยความจำ GPU ที่รองรับจะต้องได้รับการลงทะเบียน การลงทะเบียนแต่ละเทนเซอร์อาจใช้เวลานาน โดยเฉพาะอย่างยิ่งกับโมเดลขนาดใหญ่ MX เสนอกลลยุทธ์การตั้งค่าแบบเลือกได้สองแบบเพื่อลดต้นทุนการลงทะเบียนนี้:Pool Registration: ลงทะเบียนการจัดสรรหน่วยความจำ cudaMalloc แต่ละครั้งเพียงครั้งเดียว แทนที่จะลงทะเบียนทุกเทนเซอร์ ซึ่งช่วยลดจำนวนการลงทะเบียนลงอย่างมากVMM Arena Registration: ใช้ CUDAPluggableAllocator เพื่อรวมการจัดสรรหน่วยความจำทั้งหมดเข้าเป็น "arena" เดียว จากนั้นลงทะเบียนช่วงที่ใช้งานทั้งหมดเป็นภูมิภาคหน่วยความจำเดียว ซึ่งช่วยลดการลงทะเบียนจากหนึ่งครั้งต่อเทนเซอร์ เหลือเพียงครั้งเดียวสำหรับโมเดลทั้งหมดการเลือกเส้นทางการทำงานและกลไกสำรองที่ปลอดภัยเมื่อเริ่มต้นทำงาน MX จะตรวจสอบความสามารถของระบบที่มีอยู่ และจะข้ามเส้นทางใดๆ ที่สภาพแวดล้อมไม่รองรับโดยอัตโนมัติ MX จะจัดลำดับความสำคัญของเส้นทางดังนี้: P2P RDMA -> ModelStreamer -> GDS -> โหลดเดอร์เริ่มต้น (POSIX I/O ผ่าน Host Staging) หากเส้นทางใดเส้นทางหนึ่งไม่พร้อมใช้งานหรือล้มเหลวก่อนที่จะเริ่มแก้ไขสถานะของโมเดล MX จะเปลี่ยนไปใช้เส้นทางถัดไปโดยอัตโนมัติ หากเกิดความล้มเหลวหลังจากเริ่มโหลดน้ำหนักแล้ว ระบบจะเริ่มต้นโมเดลใหม่ก่อนดำเนินการต่อ เพื่อให้แน่ใจว่าน้ำหนักที่เขียนไม่สมบูรณ์จะไม่ถูกนำไปใช้การอุ่นเครื่องโมเดล: การรับ Kernel ที่คอมไพล์แล้วมาใช้นอกจากการโหลดน้ำหนักโมเดลแล้ว การที่โมเดลพร้อมให้บริการยังต้องผ่านกระบวนการ JIT-compilation และ autotuning kernels ซึ่งอาจใช้เวลาหลายนาที MX มี Artifact Transfer API ที่สามารถแพ็กเกจเคอร์เนลที่คอมไพล์แล้วเหล่านี้ และถ่ายโอนโดยตรงระหว่างบัฟเฟอร์หน่วยความจำโฮสต์ที่ลงทะเบียนไว้ผ่าน NIXL's CPU-to-CPU RDMA ช่วยลดความจำเป็นในการใช้ shared ReadWriteMany (RWX) volume ใน Kubernetes และป้องกันการนำไปใช้ซ้ำกับ replica ที่ไม่เข้ากันเมื่อน้ำหนักโมเดลเปลี่ยนแปลงทุกขั้นตอน: การฝึกอบรม RLสำหรับกรณีที่น้ำหนักโมเดลมีการเปลี่ยนแปลงตลอดเวลา เช่น ในระหว่างการฝึกอบรม Reinforcement Learning (RL) MX ก็มีโซลูชันเช่นกัน โดยสามารถจัดการกับการถ่ายโอนน้ำหนักที่อัปเดตจากเทรนเนอร์ไปยังเวิร์กเกอร์ได้อย่างมีประสิทธิภาพ ทำให้การอัปเดตโมเดลเป็นไปอย่างรวดเร็วและราบรื่น#AI #NVIDIA #ModelExpress #MachineLearning #DeepLearninghttps://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light/