Kubernetes पर GPU ऑटोस्केलिंग कारपेन्टर, KAI शेड्यूलर, गैंग शेड्यूलिंग
DCGM_FI_DEV_GPU_UTILयह एक कर्तव्य चक्र माप हैः 100% 10 अनुरोध या 100 हो सकता है। vLLM पूर्व आवंटित KV कैश मेमोरी, इसलिए मेमोरी कभी भी स्केल डाउन ट्रिगर नहीं करता है। यह सबक आपको तीन परतों को बनाने और डिफ़ॉल्ट कारपेन्टर से बचने के लिए सिखाता है।WhenEmptyOrUnderutilizedनीति जो मध्य-अवसर GPU कार्य चलाने को समाप्त करता है।Type: Learn
Languages: Python (stdlib, toy queue-depth autoscaler simulator)
Prerequisites: Phase 17 · 02 (Inference Platform Economics), Phase 17 · 04 (Serving Engine Internals)
Time: ~75 minutes
सीखने के लक्ष्य
- तीन ऑटोस्केलिंग परतों (नोड प्रविजनिंग, गैंग शेड्यूलिंग, एप्लिकेशन-लेवल) का चित्रण करें और प्रत्येक परत पर उपयोग किए जाने वाले उपकरण का नाम दें।
- क्यों बताएँ
DCGM_FI_DEV_GPU_UTILvLLM के लिए गलत HPA संकेत है और दो प्रतिस्थापनों का नाम (सूची गहराई, KV कैश उपयोग) । - गैंग शेड्यूलिंग और आंशिक आवंटन विफलता मोड का वर्णन करें जो KAI शेड्यूलर (7 से 8 GPU निष्क्रिय) को रोकता है।
- कार्पेन्टर समेकन नीति का नाम बताइए (
WhenEmptyOrUnderutilized) जो GPU कार्य को समाप्त करता है और 2026 सुरक्षित विकल्प को दर्शाता है।
समस्या
आपकी टीम Kubernetes पर एक LLM सेवा भेजता है. आप HPA स्थापित किया है के साथDCGM_FI_DEV_GPU_UTILयह पहले से ही लगता है कि आप भर रहे हैं. आप एक प्रतिकृति जोड़ने के लिए हाथ से; TTFT गिर जाता है. HPA अभी भी नहीं पैमाने पर है. संकेत झूठ बोल रहा है आप.
अलग से, आप नोड्स के लिए क्लस्टर ऑटोस्केलर का उपयोग करते हैं। 1M-token प्रॉम्प्ट 2 बजे आता है; क्लस्टर 3 मिनट नोड को प्रोविजन करने में बिताता है, और अनुरोध समय समाप्त होता है।
अलग से फिर, आप एक 70B मॉडल तैनात करते हैं जिसमें 2 नोड्स पर 8 GPU की आवश्यकता होती है। क्लस्टर में 7 GPU मुक्त होते हैं और 1 3 नोड्स पर फैला होता है। क्लस्टर ऑटोस्केलर 1 गायब GPU के लिए एक नोड प्रदान करता है। सात नोड्स 4 मिनट के लिए पैसे जलाने का इंतजार करते हैं जबकि कुबेरनेट्स को अंतिम GPU मिलता है।
तीन परतें, तीन अलग-अलग विफलता मोड. जीपीयू-जागरूक ऑटोस्केलिंग 2026 में "एचपीए पर चालू" नहीं है. यह नोड प्रावधान, गैंग शेड्यूलिंग, और आवेदन संकेत ऑटोस्केलिंग की रचना है.
अवधारणा
परत 1 नोड प्रबन्धन (कार्पेन्टर)
कार्पेन्टर ~ 45-60 सेकंड के भीतर लंबित pods और प्रावधान नोड्स को देखता है (सीस्टर ऑटोस्केलर आमतौर पर GPU नोड्स के लिए 90-120 सेकंड लेता है) । यह प्रति इंस्टेंस प्रकारों को गतिशील रूप से चुनता है ।NodePoolप्रतिबंध यदि आपके पोड को 8 H100s की आवश्यकता है और क्लस्टर में कोई मिलान नोड नहीं है, तो कार्पेन्टर मौजूदा समूह को स्केल करने के बजाय सीधे एक प्रदान करता है।
The consolidation trap: कारपेन्टर की डिफ़ॉल्ट consolidationPolicy: WhenEmptyOrUnderutilizedयह GPU पूल के लिए खतरनाक है। यह एक चल रहे GPU नोड को एक सस्ता सही आकार के उदाहरण में स्थानांतरित करने के लिए समाप्त कर देगा। निष्कर्षण कार्यभार के लिए जिसका अर्थ है चल रहे अनुरोधों को निकालना और नए नोड पर 70B मॉडल को फिर से लोड करना। हानि क्षमता के मिनटों के साथ अनुरोध विफलताओं है।
GPU पूल के लिए सुरक्षित सेटिंगः
yamldisruption:
consolidationPolicy: WhenEmpty
consolidateAfter: 1hएक घंटे के बाद कार्पेन्टर को वास्तव में खाली नोड्स को समेकित करने देता है लेकिन कभी भी एक चल रही नौकरी को बाहर नहीं निकाला जाता है।
परत 2 गिरोह अनुसूची (KAI अनुसूचक)
KAI शेड्यूलर (प्रोजेक्ट "कार्प" फिर नामित) वह संभालता है जो डिफ़ॉल्ट kube-scheduler नहीं करता हैः
Gang scheduling सभी या कुछ भी नहीं कार्यक्रम. एक वितरित निष्कर्ष पोड 8 GPUs या तो सभी 8 एक साथ शुरू या कोई नहीं करना चाहते हैं. इसके बिना, आप आंशिक आवंटन जाल मिलता हैः 8 में से 7 पोड शुरू, अनिश्चित काल के लिए प्रतीक्षा, पैसा जला.
Topology awareness जानें कि कौन से GPU NVLink साझा करते हैं, जो एक ही रैक पर बैठते हैं, जिनके बीच InfiniBand है। तदनुसार pods रखें। एक DeepSeek-V3 67B टेन्सर-समान कार्यभार एक NVLink डोमेन पर रहना चाहिए; KAI Scheduler इसका सम्मान करता है।
Hierarchical queues एक ही GPU पूल के लिए कई टीमें प्राथमिकता और कोटा के साथ प्रतिस्पर्धा करती हैं। टीम ए के उत्पादन चिपकने से टीम बी के प्रशिक्षण कार्य केवल तभी आगे बढ़ता है जब प्राथमिकता नियम अनुमति देते हैं।
KAI को एक माध्यमिक शेड्यूलर के रूप में kube-scheduler के साथ तैनात किया जाता है; आप इसका उपयोग करने के लिए वर्कलोड को नोट करते हैं। Ray और vLLM उत्पादन-स्टैक दोनों एकीकृत होते हैं।
परत 3 आवेदन स्तर के संकेत
The HPA trapDCGM_FI_DEV_GPU_UTILयह मापता है कि क्या GPU प्रत्येक नमूनाकरण अंतराल पर काम कर रहा था। 100% उपयोग का मतलब 10 समवर्ती अनुरोध या 100 हो सकता है; GPU किसी भी तरह से व्यस्त था। ड्यूटी चक्र पर स्केलिंग अंधेरे पैमाने पर है।
इससे भी बदतर, vLLM और इसी तरह के इंजन KV कैश मेमोरी को पूर्व आवंटित करते हैं (अप करने के लिए --gpu-memory-utilizationएक अनुरोध पर भी स्मृति का उपयोग 90% के करीब रहता है। स्मृति आधारित एचपीए कभी भी कम नहीं होता है।
2026 replacement signals:
- कतार की गहराई (पूर्व पूर्ति के लिए प्रतीक्षा करने वाले अनुरोधों की संख्या)
- KV कैश उपयोग (ब्लॉक का कितना अंश सक्रिय अनुक्रमों को आवंटित किया जाता है) ।
- प्रति प्रतिकृति P99 TTFT (आपके SLA संकेत) ।
- अच्छा उत्पादन (सभी एसएलओ प्रति सेकंड को पूरा करने के अनुरोध) ।
एनवीआईडीए डायनामो प्लानर और आईएलएम-डी वर्कलोड वेरिएंट ऑटोस्केलर इन सिग्नलों और स्केल प्रतिकृतिओं का उपभोग करते हैं। वे एलएलएम सेवा के लिए एचपीए को पूरी तरह से बदल देते हैं।
कब क्या इस्तेमाल करें
| Scale decision | Tool |
|---|---|
| Add/remove nodes | Karpenter |
| Schedule multi-GPU jobs | KAI Scheduler |
| Add/remove replicas | Dynamo Planner / llm-d WVA (or custom HPA on queue depth) |
| Choose GPU type | Karpenter NodePool |
| Preempt low-priority | KAI Scheduler queues |
विघटित प्रीफिल/डेकोडिंग सब कुछ जटिल बनाता है
यदि आप विघटित प्रीफिल/डेकोड (चरण 17 · 17) चलाते हैं, तो आपके पास दो पॉड क्लास हैं जिनकी स्केलिंग ट्रिगर अलग-अलग हैंः कतार की गहराई पर प्रीफिल पॉड स्केल, केवी कैश दबाव पर डेकोड पॉड स्केल। llm-d इनको अलग-अलग रूप से उजागर करता है Servicesएक ही एचपीए को दोनों के सामने रखने की कोशिश न करें।
यहाँ भी ठंडी शुरुआत मायने रखती है
शीत प्रारंभ में कमी (चरण 17 · 10) वह समय है जब नोड प्रभार समय उपयोगकर्ता के लिए दिखाई देता है। कारपेन्टर के 45-60 सेकंड वार्मिंग प्लस 20GB मॉडल लोड प्लस इंजन init का मतलब है कि शून्य से अनुरोध 2-5 मिनट लेता है। एक गर्म पूल (min_workers=1) के लिए SLO-critical paths, या आवेदन परत पर मॉडल शैली की जांच का उपयोग करें।
संख्याओं को याद रखना चाहिए
- कार्पेन्टर नोड प्रबन्धनः ~ 45-60s बनाम क्लस्टर ऑटोस्केलर ~ 90-120s (जीपीयू नोड) ।
- KAI शेड्यूलर आंशिक आवंटन कचरे के 7 से 8 फंदे को रोकता है।
DCGM_FI_DEV_GPU_UTILएचपीए सिग्नल के रूप मेंः टूट गया; कतार की गहराई या KV उपयोग का उपयोग करें।- कारपेंटर
WhenEmptyOrUnderutilized: GPU कार्य चलाने को समाप्त करता है। उपयोगWhenEmpty + consolidateAfter: 1hनिष्कर्ष के लिए।
इसका प्रयोग करें
code/main.pyएक फटा GPU कार्यभार पर तीन-परत ऑटोस्केलर का अनुकरण करता है। साफ़ HPA (कर्तव्य चक्र), कतार-गहन HPA, और KAI-गैंड-अनुसूचित स्केलिंग की तुलना करता है। अपूर्ण अनुरोधों, निष्क्रिय GPU मिनटों और एक समग्र स्कोर की रिपोर्ट करता है।
इसे भेजें
यह सबक हमें फल देता हैoutputs/skill-gpu-autoscaler-plan.md. क्लस्टर टोपोलॉजी, वर्कलोड आकार और एसएलओ को देखते हुए, यह तीन-परत ऑटोस्केलिंग योजना डिजाइन करता है।
व्यायाम
- दौड़ें
code/main.pyएक फटा काम लोड के तहत, कितने अनुरोधों के लिए भोले कर्तव्य चक्र HPA गिरता है कि कतार गहराई HPA पकड़ता है? यह अंतर कहाँ से आता है? - H100 SXM5 पर Llama 3.3 70B FP8 की सेवा करने वाले क्लस्टर के लिए एक कारपेन्टर नोडपूल डिजाइन करें। निर्दिष्ट करें
capacity-type,disruption.consolidationPolicy,consolidateAfter, और एक धब्बा जो गैर-जीपीयू कार्यभार को इन नोड्स से दूर रखता है। - आपकी टीम रिपोर्ट है कि तैनाती के लिए लंबित हैं क्योंकि "जीपीयू उपलब्ध है लेकिन पोड नहीं निर्धारित करेगा. " निदान यह कारपेन्टर, kube-अनुसूचक, या KAI अनुसूचक है? कौन से माप पुष्टि करते हैं?
- ऑटोस्केल डिस्पैग्रेटेड प्रीफिल pods के लिए एक संकेत चुनें और डिकोड pods के लिए एक अलग संकेत. दोनों को सही ठहराने.
WhenEmptyOrUnderutilized24x7 उत्पादन सेवा पर एक समेकन जाल जो P99 TTFT > 10s पर प्रति दिन 60 अनुरोध ड्रॉप घटनाओं का औसत है।
प्रमुख शर्तें
| Term | What people say | What it actually means |
|---|---|---|
| Karpenter | "the node provisioner" | Kubernetes node autoscaler; sub-minute provisioning |
| Cluster Autoscaler | "the old scaler" | Kubernetes node autoscaler predecessor; slower, group-based |
| KAI Scheduler | "the GPU scheduler" | Secondary scheduler for gang + topology + queues |
| Gang scheduling | "all or nothing" | Schedule N pods atomically or defer all of them |
| Topology awareness | "rack-aware" | Place pods based on NVLink/IB/rack placement |
DCGM_FI_DEV_GPU_UTIL | "GPU utilization" | Duty-cycle metric; NOT a scaling signal for LLMs |
| Queue depth | "waiting requests" | Correct HPA signal for prefill-bound scaling |
| KV cache utilization | "memory pressure" | Correct HPA signal for decode-bound scaling |
| Consolidation | "Karpenter consolidation" | Node termination to cheaper instance type |
WhenEmpty + 1h | "safe consolidation" | Policy that doesn't evict running GPU jobs |
आगे पढ़ना
- KAI Scheduler GitHub डिजाइन डॉक्स और कॉन्फ़िगरेशन उदाहरण।
- Karpenter Disruption Controls समेकन नीति सेमॅटिक और GPU-सुरक्षित डिफ़ॉल्ट।
- NVIDIA — Disaggregated LLM Inference on Kubernetes डायनामो प्लानर स्केलिंग सिग्नल।
- Ray docs — KAI Scheduler for RayClusters रे एकीकरण पैटर्न।
- AWS EKS Compute and Autoscaling Best Practices प्रबंधित-कुबेरनेट्स-विशिष्ट मार्गदर्शन।
- llm-d GitHub वर्कलोड वेरिएंट ऑटोस्केलर डिजाइन।
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.