NVIDIA Dynamo Snapshot: เร่งสปีดการเริ่มต้น Inference Workloads บน Kubernetes

NVIDIA Dynamo Snapshot: เร่งสปีดการเริ่มต้น Inference Workloads บน Kubernetesในโลกของการพัฒนา AI ที่เติบโตอย่างรวดเร็ว การนำโมเดลไปใช้งานจริง (Production Inference) เป็นหัวใจสำคัญ แต่บ่อยครั้งที่ระบบต้องเผชิญกับความต้องการที่ผันผวน ทำให้ต้องมีการปรับขนาด (Scale) ระบบ Inference Replica ให้ยืดหยุ่นตามไปด้วย ปัญหาที่มักพบเจอคือ "Cold Start" หรือการเริ่มต้นระบบ Inference ใหม่ ซึ่งอาจใช้เวลานานหลายนาทีบน Kubernetes ทำให้ GPU ว่างเปล่า ไม่สามารถตอบสนองคำขอได้ทันเวลา ส่งผลกระทบต่อข้อตกลงระดับการให้บริการ (SLA)NVIDIA Dynamo Snapshot คือโซลูชันที่เข้ามาแก้ปัญหานี้ โดยใช้เทคนิค Checkpoint/Restore เพื่อให้การเริ่มต้นระบบ Inference ทำได้เร็วขึ้นอย่างไม่น่าเชื่อ ใกล้เคียงกับ "ความเร็วแสง" สำหรับ Single-GPU Workloads เรามาทำความเข้าใจเบื้องหลังการออกแบบและเทคนิคการปรับปรุงประสิทธิภาพของ Dynamo Snapshot กันปัญหา Cold Start คืออะไร?เมื่อเกิดความต้องการใช้งาน AI สูงขึ้นอย่างกะทันหัน ระบบ Inference จำเป็นต้องเพิ่มจำนวน Replica อย่างรวดเร็ว แต่การเริ่มต้น Instance ใหม่ (Cold Start) บน Kubernetes นั้นใช้เวลานาน ซึ่งช่วงเวลานี้ GPU จะถูกจัดสรรไปแต่ยังไม่ได้ประมวลผลใดๆ ทำให้เกิดความล่าช้า และอาจทำให้ไม่สามารถตอบสนองความต้องการได้ทันเวลาสำหรับ vLLM (v0.20.0) Single-GPU Workload เดียว การเริ่มต้นระบบแบบ Cold Start อาจใช้เวลานานหลายนาที ซึ่งกินเวลาไปกับ:การจัดสรรทรัพยากรการโหลดโมเดลการคอมไพล์ Kernelการตั้งค่าต่างๆเพื่อลดเวลาเริ่มต้นระบบให้เหลือน้อยที่สุด NVIDIA Dynamo Snapshot จึงถูกพัฒนาขึ้นมาหัวใจหลัก: CRIU และ cuda-checkpointDynamo Snapshot ทำงานโดยการบันทึกสถานะของ Inference Worker ที่กำลังทำงานอยู่ ซึ่งประกอบด้วย 2 ส่วนหลัก:สถานะฝั่ง GPU (Device State): รวมถึง CUDA contexts, streams, หน่วยความจำ GPU (Device Memory), การแมป Address เสมือน และอื่นๆ ที่มองไม่เห็นจากฝั่ง Host โดยใช้ความสามารถของ CUDA Driver ผ่านเครื่องมือ cuda-checkpoint เพื่อบันทึกสถานะเหล่านี้ไปยังหน่วยความจำ CPU ของ Process ที่เป็นเจ้าของ CUDA Context นั้นๆสถานะฝั่ง Host (Host State): รวมถึงหน่วยความจำ CPU, Threads, File Descriptors, Namespaces และอื่นๆ ระบบ Linux มีกลไกในการบันทึกสถานะเหล่านี้อยู่แล้ว โดยใช้เครื่องมือโอเพนซอร์สอย่าง CRIU (Checkpoint/Restore in Userspace) เพื่อบันทึกสถานะของ Process Tree ทั้งหมดไปยัง Diskเมื่อรวมเครื่องมือทั้งสองนี้เข้าด้วยกัน จะสามารถทำการ Checkpoint และ Restore สถานะของ Inference Worker ได้อย่างสมบูรณ์ขั้นตอนการทำงาน:Checkpoint:cuda-checkpoint บันทึกสถานะ GPU ลงในหน่วยความจำ CPUCRIU บันทึกสถานะ Host-side ของ Process Tree ลงในโฟลเดอร์บน StorageRestore:CRIU กู้คืน Process Tree จากสถานะที่บันทึกไว้บน Storage (เช่น NFS/SMB) ทำให้สามารถดึง Artifact จาก Node อื่นได้cuda-checkpoint กู้คืนสถานะ GPU จากข้อมูลที่บันทึกไว้ในหน่วยความจำ CPU ลงบน GPU ใหม่CRIU ทำงานแบบ "Freeze-and-Thaw" คือหยุดการทำงานของ Process ชั่วคราวเพื่อบันทึกสถานะ และเมื่อ Restore กลับมา การทำงานจะกลับมาดำเนินต่อจากจุดที่หยุดไปทันที โดยที่ Process ไม่รู้ตัวว่ามีการ Checkpoint หรือ Restore เกิดขึ้นDynamo Snapshot ในสภาพแวดล้อม Kubernetesใน Kubernetes Workloads จะทำงานภายใน Container ซึ่งอยู่ภายใน Pod การ Checkpoint ที่ระดับ Container จะทำให้สถานะของ Process Tree และ Filesystem เดินทางไปด้วยกันDynamo Snapshot มีการติดตั้งผ่าน Helm Chart โดยใช้ snapshot-agent ซึ่งเป็น Privileged DaemonSet ที่จะทำงานบนทุก Node เพื่อจัดการการ Checkpoint และ Restore สำหรับ Container ที่จัดการโดย runc โดยไม่ต้องแก้ไข runc เองเมื่อ Checkpoint: Agent จะรอจนกว่า Workload จะพร้อม (Readiness Probe) จากนั้นจึงเรียกใช้ cuda-checkpoint และ CRIU จากฝั่ง Host ก่อนที่จะเขียน Artifact ไปยัง Shared Storageเมื่อ Restore: Agent จะเปิดใช้งาน Placeholder Pod, กู้คืน Filesystem และกู้คืน Checkpoint ของ CRIU/CUDA เข้าไปใน Namespaces ของ Pod ใหม่ จากนั้น Worker ที่กู้คืนมาจะเข้ามารับช่วงการทำงานต่อAgent แต่ละตัวทำงานบน Node ของตนเอง ทำให้การ Checkpoint และ Restore สามารถทำงานแบบ Parallel ทั่วทั้ง Cluster ได้Dynamo Snapshot และ WorkloadInference Worker ของ Dynamo จะเริ่มต้นทำงานเป็น 2 ระยะ:การเริ่มต้น Inference Engine: ตั้งค่า Engine, โหลด Weights, Compile Kernels, Warm up จนพร้อมใช้งาน แต่ยังไม่สามารถถูกค้นพบจากภายนอก Pod ได้การเริ่มต้น Distributed Runtime: Worker จะเชื่อมต่อไปยัง Control Plane ของ Dynamo และลงทะเบียนตัวเอง เพื่อให้ Router และส่วนประกอบอื่นๆ ค้นพบได้ Worker จึงจะ "Live" อย่างสมบูรณ์หากทำการ Checkpoint/Restore แบบพื้นฐานโดยไม่คำนึงถึงสถานะการทำงานของ Workload จะเกิดปัญหา เพราะ Readiness Probe ของ Checkpoint Job จะตรงกับสถานะที่ Worker ถูกลงทะเบียนกับ Discovery Plane แล้ว ซึ่งหมายถึงมีการเชื่อมต่อ TCP ที่เปิดอยู่ ซึ่ง CRIU ไม่สามารถจับภาพได้Quiesce/Resume Hooks คือทางออก:กลไกนี้ช่วยให้ Workload เข้าสู่สถานะ "สงบ" (Quiescent State) ก่อนการ Checkpoint และจะกลับมาทำงานต่อ (Resume) เมื่อการ Restore เสร็จสมบูรณ์ ซึ่งมีประโยชน์ดังนี้:ลดขนาด Checkpoint: Workload สามารถล้างทรัพยากรที่ไม่จำเป็นก่อน Checkpoint ได้สร้างทรัพยากรที่ไม่สามารถ Checkpoint ได้: สำหรับ Multi-GPU/Multi-Node การเชื่อมต่อ RPC หรือสถานะ NIC ที่ต้องถูกสร้างขึ้นใหม่หลัง RestoreDynamo Snapshot ใช้ Hooks เหล่านี้โดยกำหนดให้ Readiness Probe คือการปรากฏของไฟล์สัญญาณ "ready for checkpoint" ซึ่ง Worker จะเขียนไฟล์นี้หลังจาก Engine เริ่มต้นเสร็จสมบูรณ์ แต่ก่อนการเริ่มต้น Distributed Runtime จากนั้น Worker จะเข้าสู่ Loop รอรับสัญญาณ "restore complete" ในขณะที่ Agent ทำการ Checkpoint ภายนอกการปรับปรุงประสิทธิภาพ (Optimizations)1. การยกเลิกการแมป KV Cache (KV Cache Unmap and Release)หนึ่งในการลดขนาด Checkpoint คือการคืนหน่วยความจำ KV Cache ที่ไม่ได้ใช้งานก่อน Checkpoint เนื่องจาก Checkpoint ถูกทำในขณะที่ Worker ยังไม่เคยประมวลผลคำขอใดๆ KV Cache จึงยังว่างเปล่า แต่ต้องรักษา Address เสมือนของ KV Cache ให้คงเดิมด้วยการใช้ API ของ CUDA Virtual Memory Management (cuMemCreate และ cuMemMap) การยกเลิกการจัดสรรหน่วยความจำจริง (cuMemUnmap และ cuMemRelease) ในขณะที่ยังคง Address เสมือนไว้เป็นเรื่องง่าย ทำให้ขนาด Artifact ลดลงอย่างมาก ตัวอย่างเช่น Qwen3-0.6B บน B200 ลดขนาดจาก ~190 GiB เหลือเพียง ~6 GiB2. เร่งความเร็ว CRIU (Speeding up CRIU)แม้จะมีการปรับปรุงข้างต้น เวลา Restore ก็ยังอาจนานเกินไป โดยเฉพาะอย่างยิ่งสำหรับโมเดลขนาดใหญ่2.1 การ Restore แบบ Parallel ด้วย memfd:vLLM และ SGLang มีกลไกย้าย GPU Allocation ที่เกี่ยวข้องกับ Weights ไปยัง CPU Shadow Buffer ซึ่ง CUDA ใช้ Shared Anonymous Memory ในการรองรับ และจะปรากฏใน Linux Kernel เป็น memfds (Anonymous, RAM-backed files)CRIU แบบเดิมจะ Restore memfds เหล่านี้แบบ Serial คือสร้าง Object, ปรับขนาด, Map, อ่านข้อมูล แล้วค่อยไป Object ถัดไปการปรับปรุง CRIU จะทำการ Enumerate shmem-backed objects ที่ไม่ซ้ำกันทั้งหมด จากนั้นใช้ Thread Pool เพื่อ Restore แบบ Parallel ทำให้การ Restore ใช้ประโยชน์จาก Bandwidth ของ Storage และ CPU Parallelism ได้เต็มที่2.2 Linux Native AIO สำหรับ Anonymous Memory:หลังจาก CRIU กู้คืนทรัพยากรที่แชร์กันแล้ว (Files, Sockets, shmem objects, memfds) ขั้นตอนต่อไปคือการเติมข้อมูลให้กับ Process Memory ของแต่ละ Process ซึ่งเป็นส่วนสำคัญที่ต้องใช้ความเร็วในการดำเนินการผลลัพธ์ที่น่าทึ่งผลการทดลองแสดงให้เห็นว่า Dynamo Snapshot สามารถลดเวลา Startup ได้สูงสุดถึง 21 เท่า สำหรับโมเดลขนาดใหญ่ เช่น gpt-oss-120b โดยใช้เวลา Restore ที่ใกล้เคียงกับ "ความเร็วแสง" ซึ่งดีกว่า Cold Start แบบดั้งเดิมอย่างมีนัยสำคัญเทคโนโลยีนี้ปูทางไปสู่การรองรับ Multi-GPU/Multi-Node ในอนาคต รวมถึงการผสานรวมกับ TensorRT-LLM เพื่อมอบประสิทธิภาพสูงสุดในการใช้งาน AI Inference Workloads บน Kubernetes#คำถามที่พบบ่อยDynamo Snapshot แตกต่างจาก Kubernetes Native Checkpoint/Restore อย่างไร?Dynamo Snapshot ใช้ DaemonSet ที่ทำงานบนทุก Node และควบคุม CRIU ได้อย่างใกล้ชิดสำหรับการปรับแต่งประสิทธิภาพ รวมถึงสามารถจัดเก็บ Checkpoint Artifact ไว้ใน Storage Backend ที่ยืดหยุ่นได้ ต่างจาก Kubernetes Native ที่อาจมีข้อจำกัดมากกว่าQuiesce/Resume Hooks สำคัญอย่างไร?Hooks เหล่านี้ช่วยให้ Workload สามารถจัดการทรัพยากรได้อย่างเหมาะสมก่อน Checkpoint และสร้างทรัพยากรที่จำเป็นใหม่หลัง Restore ทำให้การทำงานราบรื่นและมีประสิทธิภาพ โดยเฉพาะอย่างยิ่งสำหรับระบบที่ซับซ้อนการปรับปรุง CRIU มีผลต่อการ Restore อย่างไร?การ Restore แบบ Parallel ด้วย memfd และการใช้ Linux Native AIO สำหรับ Anonymous Memory ช่วยลดคอขวดในการกู้คืนข้อมูล ทำให้เวลา Restore เร็วขึ้นอย่างมาก โดยเฉพาะกับโมเดลขนาดใหญ่https://developer.nvidia.com/blog/nvidia-dynamo-snapshot-fast-startup-for-inference-workloads-on-kubernetes/