VPS पर Nemotron 3.5 Lightning कैसे चलाएं

Nemotron 3.5 Lightning का उद्देश्य

Nemotron 3.5 Lightning, NVIDIA का 30B mixture-of-experts मॉडल है जिसे अगस्त 2026 में release किया गया था। इसे ऐसे agents के लिए बनाया गया है जो एक chat window के बजाय घंटों तक चलते हैं। MoE (mixture of experts) का अर्थ है कि weights को कई expert sub-networks में विभाजित किया गया है, और प्रत्येक token को उनमें से केवल कुछ के माध्यम से ही route किया जाता है। NVIDIA का model card कुल 30 billion parameters बताता है, जिनमें से प्रति token 3 billion active रहते हैं। आप memory में बड़ी संख्या के लिए भुगतान करते हैं, और बदले में आपको गति के रूप में छोटी संख्या प्राप्त होती है।

यह trade-off ही वह कारण है कि आपको किराए के सर्वर के लिए इस मॉडल पर विचार करना चाहिए। वास्तविक काम करने वाला agent दिन भर में हजारों छोटे requests भेजता है, इसलिए प्रति डॉलर throughput ही यह तय करता है कि क्या वह आपके अपने सर्वर पर चल सकता है। जो मॉडल प्रति reply 40 seconds लेता है, वह एक अच्छा assistant तो हो सकता है लेकिन एक खराब agent, क्योंकि एक कार्य में बीस calls होती हैं और आपको हर एक के लिए प्रतीक्षा करनी पड़ती है।

NVIDIA इस architecture को hybrid बताता है: इसमें Mamba-2 और MoE layers को select attention layers के साथ interleaved किया गया है। model card 1M tokens तक की अधिकतम context length और OpenMDW-1.1 license देता है, जिसे व्यावसायिक उपयोग के लिए तैयार चिह्नित किया गया है। प्राथमिक भाषाएं English और code हैं, साथ ही Spanish, French, German, Italian और Japanese भी सूचीबद्ध हैं।

Artificial Analysis ने अगस्त 2026 में launch के measurements प्रकाशित किए, जिसमें NVFP4 weights को serve करने वाले pre-release DeepInfra endpoint पर लगभग 670 output tokens प्रति second की गति दिखाई गई। यह एक hosted GPU endpoint है। इसे उस क्षमता के रूप में पढ़ें जो architecture प्रदान करता है, न कि उस गति के रूप में जो आपका VPS देगा।

कौन सा Ollama tag किस VPS के लिए उपयुक्त है

Ollama library एक ही weights के कई builds प्रकाशित करती है। इनके बीच मुख्य अंतर quantisation का होता है, यानी प्रत्येक weight को कितने bits में store किया गया है, और इससे download size में काफी बदलाव आता है।

[
  {
    "label": "30b-a3b-q4_K_M",
    "size_gb": 25
  },
  {
    "label": "30b-a3b-q8_0",
    "size_gb": 35
  },
  {
    "label": "30b-a3b-bf16",
    "size_gb": 66
  },
  {
    "label": "30b-a3b-mlx",
    "size_gb": 23
  }
]

latest, 30b और 30b-a3b नाम के tags सभी 30b-a3b-q4_K_M के समान digest पर resolve होते हैं, इसलिए default download 25 GB का four-bit build है जिसमें 1M का full context मिलता है। Q8_0 का आकार 35 GB है और bf16 का आकार 66 GB है, ये दोनों भी 1M context पर हैं। 23 GB वाले MLX builds Apple silicon के लिए हैं और इनकी सीमा 256K context तक है, इसलिए Linux VPS पर इनका उपयोग करना गलत विकल्प है।

ये केवल download sizes हैं, न कि memory की आवश्यकता। NVIDIA, Ollama builds के लिए न्यूनतम VRAM (video RAM) का आंकड़ा प्रकाशित नहीं करती है, इसलिए download size को केवल एक न्यूनतम आधार (floor) मानें। Weights को कहीं न कहीं resident होना पड़ता है; यदि card में जगह है तो GPU memory में, अन्यथा system RAM में, और इसके ऊपर KV cache (key/value cache, जो conversation के प्रति-token की model memory है) जुड़ जाता है। आपके hardware के लिए वास्तविक संख्या किसी गणना से नहीं, बल्कि नीचे दिए गए command से प्राप्त होती है। यदि आपने अभी तक quantisation level तय नहीं किया है, तो Q4, Q8 और FP16 की लागत क्या है लेख में यह बताया गया है कि प्रत्येक चरण में आप क्या खोते हैं।

सटीक tag का उपयोग करें, latest का नहीं

latest एक बदलता हुआ पॉइंटर है। जब लाइब्रेरी इसे फिर से प्रकाशित करती है, तो आपके एजेंट का व्यवहार अगले pull पर बदल जाता है, और आपके नोट्स में इसका कोई कारण नहीं होता। इसलिए tag का नाम स्पष्ट रूप से लिखें।

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama pull nemotron-3.5-lightning:30b-a3b-q4_K_M

इंस्टॉल स्क्रिप्ट एक systemd सर्विस सेट करती है जो ollama यूजर के रूप में चलती है और मॉडल्स को /usr/share/ollama/.ollama/models के अंतर्गत रखती है। अधिकांश VPS इमेज पर यह पाथ रूट फाइलसिस्टम पर होता है, इसलिए 25 GB की मांग करने से पहले डिस्क स्पेस की जांच कर लें।

df -h /usr/share/ollama

यदि pull बीच में रुक जाता है और no space left on device रिपोर्ट करता है, तो इसका अर्थ बिल्कुल वही है जो लिखा है। आंशिक blobs डिस्क पर तब तक बने रहते हैं जब तक आप उन्हें डिलीट नहीं करते। उसके बाद पुष्टि करें कि क्या डाउनलोड हुआ है:

ollama show nemotron-3.5-lightning:30b-a3b-q4_K_M

ollama show आर्किटेक्चर, पैरामीटर की संख्या, कॉन्टेक्स्ट लेंथ और फाइल में मौजूद क्वांटाइजेशन को प्रिंट करता है। यदि इनमें से कोई भी जानकारी लाइब्रेरी पेज से मेल नहीं खाती है, तो आपने उस tag के बजाय कोई दूसरा tag पुल कर लिया है जिसे आप चाहते थे।

इसे सर्व करें और जाँचें कि यह वास्तव में कहाँ चला

sudo systemctl enable --now ollama
ollama run nemotron-3.5-lightning:30b-a3b-q4_K_M "Reply with one word: ready"

जब मॉडल लोड हो रहा हो, तो एक दूसरे शेल में यह चलाएँ:

ollama ps

यह वह कमांड है जो आपकी मशीन के लिए मेमोरी संबंधी प्रश्न का उत्तर देती है। ollama ps लोड किए गए मॉडल, उसके द्वारा मेमोरी में घेरे गए आकार और एक PROCESSOR कॉलम को प्रिंट करता है। 100% GPU का अर्थ है कि पूरा मॉडल VRAM में है। 100% CPU का अर्थ है कि इसमें से कुछ भी VRAM में नहीं है, और प्रत्येक टोकन सिस्टम RAM का उपयोग करके प्रोसेसर द्वारा कंप्यूट किया जा रहा है। 65%/35% CPU/GPU जैसा विभाजन यह दर्शाता है कि सभी लेयर्स फिट नहीं हो पाईं, और CPU का हिस्सा आपकी गति निर्धारित करता है। आवश्यकता का अनुमान न लगाएँ। इसे लोड करें और इस पंक्ति को पढ़ें।

यदि यह बिल्कुल भी लोड नहीं हो पाता है, तो Ollama क्रैश होने के बजाय स्पष्ट रूप से मना कर देता है:

Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB)

क्या केवल CPU वाला VPS पर्याप्त तेज़ है?

एक सामान्य प्रयोजन वाले VPS में GPU नहीं होता है, इसलिए CPU ही सारा काम करता है और सिस्टम RAM से हर आवश्यक weight को पढ़ता है। यहाँ MoE (Mixture of Experts) सहायक होता है, क्योंकि 30 बिलियन पैरामीटर्स में से प्रति टोकन केवल 3 बिलियन पैरामीटर्स का ही उपयोग होता है, इसलिए प्रति टोकन गणना एक सघन (dense) 30B मॉडल की तुलना में बहुत कम होती है। मेमोरी पर इसका कोई प्रभाव नहीं पड़ता है। सभी 30 बिलियन पैरामीटर्स को RAM में रहना आवश्यक है, क्योंकि राउटर किसी भी टोकन के लिए किसी भी expert को चुन सकता है।

इसलिए, इस मॉडल पर केवल CPU का उपयोग करके inference की गति core की संख्या के बजाय मेमोरी बैंडविड्थ द्वारा सीमित होती है। ऐसे प्लान में vCPU जोड़ने से बहुत कम अंतर पड़ता है जिसमें पहले से ही पर्याप्त संख्या में vCPU मौजूद हों। आपको बस इतनी RAM चाहिए जो weights और आपके KV cache को होल्ड कर सके, और उस प्लान में मिलने वाली सबसे तेज़ मेमोरी की आवश्यकता होती है।

किसी एजेंट को उस पर तैनात करने से पहले, local LLM के लिए टोकन प्रति सेकंड मापना में दी गई विधि का उपयोग करके इसे मापें:

ollama run --verbose nemotron-3.5-lightning:30b-a3b-q4_K_M "Write a 200 word summary of TCP slow start."

अंत में प्रिंट होने वाली eval rate लाइन आपकी generation speed है, जो टोकन प्रति सेकंड में होती है। यह एकमात्र संख्या ही इस प्रश्न का निर्णय करती है, क्योंकि एजेंट का wall-clock समय मुख्य रूप से इसी पर निर्भर करता है।

[
  {
    "label": "Nemotron 3.5 Lightning",
    "sec_per_task": 30
  },
  {
    "label": "gpt-oss-120b",
    "sec_per_task": 204
  },
  {
    "label": "Qwen3.6 35B",
    "sec_per_task": 210
  }
]

ये प्रकाशित तृतीय-पक्ष के आंकड़े हैं, जिन्हें Artificial Analysis द्वारा लॉन्च के समय रिपोर्ट किए गए प्रति-कार्य मिनटों से परिवर्तित किया गया है, और इन्हें VPS के बजाय hosted GPU endpoints पर मापा गया था। Nemotron 3.5 Lightning ने प्रति कार्य औसतन लगभग 30 सेकंड का समय लिया, जहाँ gpt-oss-120b ने लगभग 204 और Qwen3.6 35B ने लगभग 210 समय लिया। इनका उपयोग अंतर के स्वरूप को समझने के लिए करें, न कि अपने हार्डवेयर के प्रदर्शन के वादे के रूप में।

ईमानदार सलाह इस बात पर निर्भर करती है कि प्रतीक्षा कौन कर रहा है। यदि कोई व्यक्ति एजेंट की प्रतीक्षा कर रहा है, या एजेंट लगातार लंबी कॉल चेन बनाता है, तो GPU क्षमता किराए पर लें। यदि यह रात भर शेड्यूल पर चलता है और कोई इसे देख नहीं रहा है, तो अधिक RAM वाला CPU प्लान एक उचित विकल्प है। किसी भी स्थिति में सेटअप समान है, और VPS पर Ollama चलाना प्लान के आकार और GPU इंस्टेंस की तुलना API प्रदाता को प्रति टोकन भुगतान करने से करने के बारे में जानकारी देता है। ब्रेक-ईवन उपयोग (utilisation) का प्रश्न है: एक GPU इंस्टेंस हर घंटे बिल करता है, जबकि API टोकन केवल उपयोग किए जाने पर बिल होते हैं। इसलिए, जो एजेंट दिन भर व्यस्त रहता है, उसके लिए आपका अपना सर्वर बेहतर है, और जो एजेंट घंटे में दो बार चलता है, उसके लिए अक्सर API बेहतर होता है।

1M context window मुफ्त नहीं है

1M tokens मॉडल की अधिकतम क्षमता है, और Ollama इसे डिफ़ॉल्ट रूप से आपको नहीं देता है। Ollama बहुत छोटी डिफ़ॉल्ट विंडो का उपयोग करता है और बातचीत के उस सीमा को पार करते ही पुराने tokens को हटा देता है। ऐसा होने पर कोई लॉग दर्ज नहीं होता है, इसलिए एक एजेंट के लिए ऐसा लगता है जैसे मॉडल अपने कार्य की शुरुआत को भूल गया है।

विंडो को जानबूझकर सेट करें। पूरे सर्वर के लिए, सर्विस को एडिट करें:

sudo systemctl edit ollama

इसे जोड़ें, फिर sudo systemctl restart ollama चलाएं:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

प्रति अनुरोध (per request), इसके बजाय options ऑब्जेक्ट में num_ctx भेजें:

curl http://localhost:11434/api/chat -d '{
  "model": "nemotron-3.5-lightning:30b-a3b-q4_K_M",
  "messages": [{"role": "user", "content": "Say ready"}],
  "options": {"num_ctx": 32768},
  "stream": false
}'

प्रत्येक वृद्धि मेमोरी की खपत बढ़ाती है, क्योंकि KV cache आपके द्वारा अनुमति दिए गए tokens की संख्या के साथ बढ़ता है। मान बढ़ाएं, रीस्टार्ट करें, फिर दोबारा ollama ps चलाएं और रिपोर्ट किए गए आकार को बढ़ते हुए देखें। यदि उस बदलाव के बाद PROCESSOR कॉलम 100% GPU से split में बदल जाता है, तो KV cache ने मॉडल लेयर्स को VRAM से बाहर धकेल दिया है और आपकी गति काफी कम हो जाएगी। Ollama में num_ctx चुनना इस ट्रेड-ऑफ पर विस्तार से चर्चा करता है। केवल इसलिए 1000000 सेट न करें क्योंकि मॉडल कार्ड इसकी अनुमति देता है, क्योंकि एलोकेशन पहले ही हो जाता है और लोड विफल हो जाता है।

इसे हमेशा चालू रहने वाले agent के साथ जोड़ना

इस मॉडल के लिए Ollama की launch post एक शॉर्टकट बताती है जो एक समर्थित agent को सीधे इस मॉडल पर पॉइंट करके शुरू कर देता है:

ollama launch claude --model nemotron-3.5-lightning

यह पोस्ट उस स्थान पर claude, opencode, openclaw और hermes का उल्लेख करती है। इस subcommand के लिए एक अपडेटेड Ollama की आवश्यकता होती है, इसलिए पहले ollama --version की जाँच करें। यदि यह मौजूद नहीं है, तो agent को स्वयं API पर पॉइंट करें। Ollama एक OpenAI-compatible endpoint प्रदान करता है, जिसे अधिकांश agent harnesses स्वीकार कर लेते हैं:

export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama

Ollama इस key को अनदेखा कर देता है, लेकिन अधिकांश clients बिना key सेट किए शुरू होने से मना कर देते हैं। इसका harness पक्ष coding agent को Ollama पर पॉइंट करना और अपना खुद का OpenClaw agent बनाना में कवर किया गया है।

जब agent बिना किसी निगरानी के चलता है, तो दो server settings महत्वपूर्ण हो जाती हैं। OLLAMA_KEEP_ALIVE यह नियंत्रित करता है कि अंतिम request के बाद मॉडल कितनी देर तक memory में रहेगा। इसका default मान इसे पाँच मिनट बाद unload कर देता है, जिससे अगली call पर फिर से पूरा load time लगता है। बिना GPU वाले 25 GB की फाइल पर यह pause इतना लंबा होता है कि timeout हो सकता है। इसे memory में बनाए रखने के लिए OLLAMA_KEEP_ALIVE=-1 को सेट करें। OLLAMA_HOST=0.0.0.0:11434 API को अन्य मशीनों से सुलभ बनाता है। इसमें किसी भी प्रकार की authentication नहीं होती है, इसलिए इसे केवल firewall rule या private network के पीछे ही खोलें।

विफलता के प्रकार और दिखाई देने वाले संदेश

पुल (pull) तुरंत विफल हो जाता है। Error: pull model manifest: file does not exist का अर्थ है कि वह टैग मौजूद नहीं है। टैग के नाम सटीक स्ट्रिंग होते हैं, इसलिए अनुमान लगाने के बजाय लाइब्रेरी पेज से टैग को कॉपी करें।

मॉडल लोड नहीं होगा। Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) का अर्थ है कि कॉन्फ़िगर किए गए प्लान के लिए टैग बहुत बड़ा है। छोटे क्वांटाइज़ेशन (quantisation) का उपयोग करें या OLLAMA_CONTEXT_LENGTH को कम करें, क्योंकि KV कैश की गणना इसी आवश्यकता के अंतर्गत की जाती है।

पोर्ट 11434 पर कोई प्रतिक्रिया नहीं मिल रही है। curl: (7) Failed to connect to localhost port 11434 का अर्थ है कि सर्विस चल नहीं रही है, या जहाँ आप उम्मीद कर रहे हैं वहाँ लिसन (listen) नहीं कर रही है। systemctl status ollama और journalctl -u ollama -n 50 पढ़ें। यदि आपने ollama serve को मैन्युअल रूप से भी शुरू किया है, तो दूसरी कॉपी Error: listen tcp 127.0.0.1:11434: bind: address already in use के साथ बंद हो जाएगी।

यह बहुत धीमी प्रतिक्रिया देता है। कुछ भी बदलने से पहले ollama ps की जाँच करें। GPU मशीन पर PROCESSOR कॉलम में CPU शेयर का मतलब है कि मॉडल का कुछ हिस्सा VRAM से बाहर निकल गया है, इसलिए कॉन्टेक्स्ट को कम करें या छोटा क्वांटाइज़ेशन चुनें। बिना GPU वाली मशीन पर, धीमी गति अपेक्षित परिणाम है और कोई भी सेटिंग इसे ठीक नहीं कर सकती।

एजेंट कार्य के बीच में ही अपने निर्देश भूल जाता है। बातचीत कॉन्टेक्स्ट विंडो से आगे निकल गई है और सबसे पुराने टोकन चुपचाप हटा दिए गए हैं। OLLAMA_CONTEXT_LENGTH को बढ़ाएं, ollama ps के साथ पुष्टि करें कि मॉडल अभी भी फिट बैठता है, और यदि ऐसा नहीं है, तो समाधान छोटी विंडो के बजाय बड़ी मशीन का उपयोग करना है।

यह मॉडल अन्य विकल्पों की तुलना में कहाँ स्थित है

30B MoE एक छोटे कार्य के लिए होस्ट करने हेतु बहुत बड़ा मॉडल है। यदि एक dense 8B मॉडल पहले से ही आपके कार्य को संभाल लेता है, तो उसे चलाना बहुत सस्ता होगा और वह कुछ ही सेकंड में लोड हो जाएगा। इस निर्णय के लिए Qwen 3 at 8B and 27B on a VPS सीधा तुलनात्मक अध्ययन है। किसी दिए गए प्लान में वास्तव में क्या समा सकता है, इसके व्यापक सर्वेक्षण के लिए which AI models you can self-host से शुरुआत करें। यदि आप एक के बजाय एक साथ कई agents को serve करने की योजना बना रहे हैं, तो पहले Ollama compared with vLLM पढ़ें। इसका कारण यह है कि Ollama concurrent requests को उस तरह से batch नहीं करता जैसे एक production inference server करता है, और यहीं पर एक single-user सेटअप की scalability सीमित हो जाती है।

FAQ

Linux VPS पर मुझे कौन सा Nemotron 3.5 Lightning tag pull करना चाहिए?

nemotron-3.5-lightning:30b-a3b-q4_K_M का उपयोग करें। यह 25 GB का है, इसमें 1M की अधिकतम context क्षमता है, और यह वही digest है जिस पर अगस्त 2026 तक latest, 30b और 30b-a3b tags point करते हैं। latest को pull करने के बजाय इसका नाम स्पष्ट रूप से लिखें, ताकि भविष्य में उस pointer के republish होने पर आपके agent का व्यवहार आपकी जानकारी के बिना न बदले। mlx tags Apple silicon builds हैं और ये Linux पर काम नहीं करेंगे।

Nemotron 3.5 Lightning को कितनी RAM की आवश्यकता होती है?

NVIDIA ने Ollama builds के लिए न्यूनतम memory का कोई आंकड़ा जारी नहीं किया है, इसलिए अनुमान लगाने के बजाय मापें। Tag को pull करें, model को एक बार run करें, और load होने के दौरान ollama ps को पढ़ें: यह वास्तविक रूप से occupy की गई size को print करता है और यह भी बताता है कि यह GPU पर load हुआ है या CPU पर। Download size, जो default tag के लिए 25 GB है, एक न्यूनतम सीमा है, क्योंकि KV cache इसके ऊपर जुड़ता है और आपके द्वारा set किए गए context window के साथ बढ़ता है। यदि plan बहुत छोटा है, तो Ollama model requires more system memory error के साथ मना कर देता है और दोनों आंकड़े बताता है।

क्या मैं बिना GPU वाले VPS पर Nemotron 3.5 Lightning चला सकता हूँ?

हाँ, यदि plan में weights को रखने के लिए पर्याप्त RAM है। MoE design इसमें मदद करता है क्योंकि 30 billion parameters में से प्रति token केवल 3 के आसपास ही compute किए जाते हैं। समस्या गति की है। GPU के बिना model memory bandwidth तक सीमित रहता है, इसलिए vCPUs बढ़ाने से परिणाम में कोई खास सुधार नहीं होता। ollama run --verbose को एक fixed prompt के साथ run करें, eval rate line को पढ़ें, और उस संख्या की तुलना अपने agent की समय-सीमा से करें। रात भर चलने वाले batch job के लिए यह अक्सर ठीक रहता है। किसी ऐसे काम के लिए जिसका इंतज़ार कोई व्यक्ति कर रहा हो, यह आमतौर पर उपयुक्त नहीं है।

Ollama मुझे पूरा 1M context window क्यों नहीं देता है?

1M model की अधिकतम क्षमता है, Ollama का default नहीं। Ollama बहुत छोटा window लागू करता है और conversation के उससे अधिक होने पर सबसे पुराने tokens को हटा देता है, बिना कोई error दिए। इससे ऐसा लगता है कि agent अपने निर्देश भूल गया है। Systemd service पर OLLAMA_CONTEXT_LENGTH set करें, या प्रति request num_ctx पास करें। इसे चरणों में बढ़ाएं और हर बार ollama ps की जाँच करें, क्योंकि KV cache memory window के साथ scale होती है और model layers को GPU से बाहर धकेल सकती है।

क्या Nemotron 3.5 Lightning व्यावसायिक उपयोग के लिए मुफ्त है?

NVIDIA का model card इस model को OpenMDW-1.1 license के अंतर्गत रखता है और इसे व्यावसायिक उपयोग के लिए तैयार बताता है। यह उन weights पर लागू होता है जिन्हें आप download करके स्वयं run करते हैं। यह आपके stack के अन्य software के बारे में कुछ नहीं कहता, इसलिए agent harness और उससे जुड़े किसी भी tool के license की अलग से जाँच करें, और किसी भी अनुबंध संबंधी कार्य के लिए इस पर निर्भर होने से पहले वर्तमान model card को पढ़ें।