NVIDIA ने आज Dynamo Snapshot v1.1.1 ship किया, AI इन्फरेंस वर्कलोड के लिए एक Kubernetes चेकपॉइंट/रिस्टोर सिस्टम, github.com/ai-dynamo/dynamo पर उपलब्ध, snapshot-agent कंटेनर NGC पर। आर्किटेक्चर दो टूल जोड़ता है: CRIU (Checkpoint/Restore in Userspace), लंबे समय से चला आ रहा Linux प्रोसेस फ्रीज़/थॉ मैकेनिज्म, cuda-checkpoint के साथ, CUDA ड्राइवर में एक नई क्षमता जो GPU डिवाइस स्टेट (contexts, streams, device memory, virtual mappings) को CPU मेमोरी में डंप करती है। क्रम मायने रखता है: cuda-checkpoint पहले GPU स्टेट को CPU मेमोरी में ले जाता है, फिर CRIU CPU मेमोरी, थ्रेड्स, फाइल डिस्क्रिप्टर्स और namespaces को स्टोरेज में सीरियलाइज़ करता है। रिस्टोर chain को उल्टा करता है। Kubernetes पर इन्फरेंस वर्कलोड के लिए कोल्ड स्टार्ट लेटेंसी ऐतिहासिक रूप से मिनट रही है, और Dynamo Snapshot रिपोर्ट करता है gpt-oss-120b इनिशियलाइज़ेशन कई मिनटों से 5 सेकंड से नीचे (21x स्पीडअप) गिरता है, Qwen3-8B रिस्टोर 24 सेकंड (अपस्ट्रीम CRIU) से 4.7 सेकंड (5.1x) तक ऑप्टिमाइज़ेशन के बाद।
रुकने योग्य मैकेनिज्म KV cache साइज़ ऑप्टिमाइज़ेशन है। इन्फरेंस वर्कलोड बड़े KV cache रखते हैं जो अन्यथा स्नैपशॉट artifact पर हावी होंगे। Dynamo Snapshot वर्चुअल एड्रेसेज़ को संरक्षित करता है लेकिन कैप्चर से पहले cuMemUnmap और cuMemRelease के माध्यम से फिजिकल मेमोरी को रिलीज़ करता है, B200 पर Qwen3-0.6B के लिए artifact साइज़ को 190 GiB से 6 GiB तक गिराता है। रिस्टोर पर, एड्रेसेज़ पुनर्गठित होते हैं और cache फिर से वार्म होता है। K8s एकीकरण तीन कस्टम संसाधन का उपयोग करता है: एक privileged snapshot-agent DaemonSet, एक DynamoCheckpoint CR जो snapshot करने के लिए मॉडल कॉन्फिग को परिभाषित करता है, और एक DynamoGraphDeployment CR जो रिस्टोर के लिए चेकपॉइंट का संदर्भ देता है। Quiesce और resume हुक्स सिग्नल फाइल्स के माध्यम से इंजन इनिशियलाइज़ेशन और डिस्ट्रिब्यूटेड रनटाइम स्टार्टअप के बीच फायर करते हैं। हार्डवेयर आवश्यकताएँ x86_64 GPU नोड्स NVIDIA ड्राइवर 580.xx या नया (मल्टी-GPU के लिए 590.xx या नया) और क्रॉस-नोड रिस्टोर के लिए ReadWriteMany स्टोरेज हैं। सीमाएँ मायने रखती हैं और NVIDIA उन्हें डिस्क्लोज़ करता है: इस लिमिटेड प्रीव्यू में केवल vLLM बैकएंड, केवल सिंगल-GPU चेकपॉइंट्स के साथ मल्टी-GPU योजनाबद्ध, GMS (समानांतर वेट रिस्टोरेशन के लिए GPU Memory Service) केवल PoC है, AIO और parallel memfd का उपयोग करने वाली CRIU ऑप्टिमाइज़ेशन्स पहले से ship किए जाने के बजाय upstream merge की प्रतीक्षा कर रही हैं, रिस्टोर लाइव TCP socket स्टेट के प्रति संवेदनशील है, और privileged DaemonSet आवश्यकता कुछ क्लस्टर सुरक्षा posture के लिए non-trivial है।
ट्रैक करने योग्य दो इकोसिस्टम थ्रेड्स। पहला, कोल्ड स्टार्ट Kubernetes पर AI इन्फरेंस ऑटोस्केलिंग के विरुद्ध संरचनात्मक तर्क रहा है जब से लोग इसे कर रहे हैं। एक नया pod स्पिन करने में मिनट लगते हैं; डिमांड स्पाइक्स मिनट तक प्रतीक्षा नहीं करते; SLA उल्लंघन के बाद। मानक मिटिगेशन ओवर-प्रोविजनिंग (GPU idle के लिए भुगतान), warm pools (अभी भी GPU idle के लिए भुगतान), और मॉडल स्ट्रीमिंग (तेज़ लेकिन अभी भी 30 से 90 सेकंड) रहे हैं। सब-5-सेकंड रिस्टोर उस math को substantially बदलता है। यदि आपकी वर्कलोड पर reproducible है, यह Kubernetes पर elastic-AI-इन्फरेंस समस्या का पहला credible समाधान है workaround के बजाय। दूसरा, सीमाएँ adoption timing पर substantive पठन हैं। vLLM-only और single-GPU-only का मतलब है कि Dynamo Snapshot वर्तमान में एक विशिष्ट deployment shape (single-GPU vLLM serving) में fit है बजाय एक general K8s क्षमता के। TensorRT-LLM integration, मल्टीमॉडल workers, embedding और diffusion workers, multi-node, multi-GPU सभी roadmap पर हैं लेकिन ship नहीं किए गए। CRIU upstream merges (AIO और parallel memfd) NVIDIA के fork से आगे adoption को व्यापक बनाने का path हैं। प्रोडक्शन के लिए इसका मूल्यांकन करने वाले builders के लिए, सवाल यह है कि क्या आपका stack वर्तमान सीमाओं से मेल खाता है या आप अगले quarter की प्रतीक्षा करते हैं।
सोमवार सुबह, अगर आप single-GPU इन्फरेंस के साथ Kubernetes पर vLLM चला रहे हैं और डिमांड स्पाइक्स अवशोषित करने के लिए warm-pool GPU idle के लिए भुगतान कर रहे हैं: एक गैर-प्रोडक्शन क्लस्टर पर अपने वास्तविक वर्कलोड के विरुद्ध Dynamo Snapshot आज़माएँ। gpt-oss-120b के लिए 21x ऊपरी सीमा है; आपका वास्तविक संख्या स्टोरेज IO (ReadWriteMany मायने रखता है), मॉडल साइज़, और आप KV cache unmap path को कितनी आक्रामक रूप से व्यायाम करते हैं, पर निर्भर करता है। अगर आप आज TensorRT-LLM या multi-GPU पर हैं, वर्तमान विकल्प के रूप में Dynamo Snapshot पर बेट लगाने के बजाय roadmap और CRIU upstream merges की निगरानी करें। अगर आप अधिक व्यापक रूप से इन्फरेंस प्लेटफ़ॉर्म बनाते हैं, two-tool architecture (GPU स्टेट के लिए cuda-checkpoint, CPU और प्रोसेस स्टेट के लिए CRIU, KV cache वर्चुअल एड्रेस संरक्षण के साथ) इंजीनियरिंग पैटर्न है जो अध्ययन योग्य है चाहे आप Dynamo Snapshot स्वयं अपनाएँ या नहीं। और अगर आप क्लस्टर्स ऑपरेट करते हैं जहाँ privileged DaemonSets सुरक्षा कारणों से non-starter हैं, यह अभी आपके लिए समाधान नहीं है; आर्किटेक्चर वर्तमान में host स्तर पर cuda-checkpoint और CRIU को drive करने के लिए privileged container की आवश्यकता है।