VPS वर Nemotron 3.5 Lightning कसे चालवायचे

Nemotron 3.5 Lightning कशासाठी आहे

Nemotron 3.5 Lightning हे NVIDIA चे ऑगस्ट 2026 मध्ये प्रकाशित झालेले open 30B mixture-of-experts मॉडेल आहे. हे एकाच chat window साठी नव्हे, तर अनेक तास चालणाऱ्या agents साठी तयार केले आहे. MoE (mixture of experts) म्हणजे weights अनेक expert sub-networks मध्ये विभागले जातात आणि प्रत्येक token त्यांपैकी काही मोजक्या sub-networks मधून पाठवला जातो. NVIDIA च्या model card नुसार यात एकूण 30 billion parameters असून प्रत्येक token साठी 3 billion parameters सक्रिय असतात. मोठ्या एकूण संख्येसाठी memory लागते. लहान सक्रिय संख्या वेग देते.

तुम्ही भाड्याने घेतलेल्या server साठी हे मॉडेल विचारात घेण्याचे कारण हा trade-off आहे. प्रत्यक्ष काम करणारा agent दिवसभरात हजारो लहान requests पाठवतो. त्यामुळे तो तुमच्या स्वतःच्या box वर चालू शकतो की नाही हे प्रति dollar throughput ठरवतो. प्रत्येक reply साठी 40 seconds लागणारे मॉडेल वापरण्यायोग्य assistant ठरू शकते, पण ते poor agent ठरते. कारण एका task साठी वीस calls होतात आणि प्रत्येक call पूर्ण होईपर्यंत प्रतीक्षा करावी लागते.

NVIDIA या architecture चे वर्णन hybrid म्हणून करते: interleaved Mamba-2 आणि MoE layers, तसेच select attention layers. Model card नुसार maximum context length 1M tokens पर्यंत आहे आणि OpenMDW-1.1 license आहे; त्यात commercial use साठी readiness दर्शवली आहे. Primary languages म्हणून English आणि code दिले आहेत. Spanish, French, German, Italian आणि Japanese यांचाही समावेश आहे.

Artificial Analysis ने ऑगस्ट 2026 मध्ये launch measurements प्रकाशित केली. त्यानुसार pre-release DeepInfra endpoint वर NVFP4 weights पुरवताना जवळपास 670 output tokens per second मिळाले. हा hosted GPU endpoint आहे. याचा अर्थ architecture किती क्षमता देऊ शकते असा घ्या; तुमचा VPS प्रत्यक्षात किती वेग देईल असा घेऊ नका.

कोणत्या VPS साठी कोणता Ollama tag योग्य आहे

Ollama library समान weights चे अनेक builds प्रकाशित करते. त्यांच्यातील मुख्य फरक quantisation मध्ये असतो. प्रत्येक weight साठवण्यासाठी किती bits वापरले जातात, हे quantisation ठरवते. त्यामुळे 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 context असतो. Q8_0 चा आकार 35 GB आहे आणि bf16 चा आकार 66 GB आहे. दोन्हीमध्ये 1M context असतो. 23 GB आकाराचे MLX builds Apple silicon साठी आहेत आणि त्यांची कमाल context क्षमता 256K आहे. त्यामुळे Linux VPS वर ते योग्य पर्याय नाहीत.

हे download sizes आहेत; memory requirement नाहीत. Ollama builds साठी NVIDIA किमान VRAM (video RAM) ची आकडेवारी प्रकाशित करत नाही. त्यामुळे download size ला फक्त किमान अंदाज माना; त्यापेक्षा अधिक निष्कर्ष काढू नका. Weights कुठेतरी memory मध्ये resident असणे आवश्यक आहे. GPU card मध्ये ते बसत असल्यास ते GPU memory मध्ये राहतात; अन्यथा system RAM मध्ये राहतात. याशिवाय KV cache (key/value cache, म्हणजे conversation मधील प्रत्येक token साठी model कडे असलेली memory) जोडली जाते. तुमच्या hardware साठी प्रत्यक्ष संख्या arithmetic मधून नाही, तर command मधून मिळते. ती command खाली दिली आहे. अजून quantisation level निश्चित केले नसेल, तर Q4, Q8 आणि FP16 साठी कोणती किंमत मोजावी लागते या विभागात प्रत्येक पायरीवर काय गमवावे लागते ते स्पष्ट केले आहे.

अचूक tag pull करा, latest कधीही वापरू नका

latest हा सतत बदलणारा pointer आहे. Library तो पुन्हा publish केल्यावर तुमच्या notes मध्ये कारण नोंदलेले नसतानाही पुढील pull वेळी agent चे वर्तन बदलते. Tag चे नाव स्पष्टपणे द्या.

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

Install script systemd service तयार करते. ती सेवा ollama user म्हणून चालते आणि models /usr/share/ollama/.ollama/models अंतर्गत ठेवते. बहुतेक VPS images मध्ये हा path root filesystem वर असतो. त्यामुळे 25 GB मागण्यापूर्वी उपलब्ध जागा तपासा.

df -h /usr/share/ollama

Pull मध्येच थांबून no space left on device असा संदेश मिळाल्यास त्याचा अर्थ नेमका तोच असतो. Partial blobs तुम्ही delete करेपर्यंत disk वर राहतात. त्यानंतर प्रत्यक्षात काय आले ते तपासा:

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

ollama show architecture, parameter count, context length आणि file मध्ये प्रत्यक्ष असलेली quantisation दाखवते. यापैकी कोणतीही माहिती library page शी जुळत नसेल, तर तुम्हाला अपेक्षित असलेल्या tag ऐवजी वेगळा tag pull झाला आहे.

मॉडेल सर्व्ह करा आणि ते प्रत्यक्षात कुठे चालले ते तपासा

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

मॉडेल अद्याप लोड असताना, दुसऱ्या shell मध्ये:

ollama ps

ही तुमच्या मशीनसाठी memory संबंधी प्रश्नाचे उत्तर देणारी command आहे. ollama ps लोड केलेले model, ते memory मध्ये व्यापत असलेला आकार आणि PROCESSOR column दाखवते. 100% GPU म्हणजे model पूर्णपणे VRAM मध्ये आहे. 100% CPU म्हणजे model चा कोणताही भाग VRAM मध्ये नाही आणि प्रत्येक token system RAM मधून processor द्वारे compute केला जातो. 65%/35% CPU/GPU सारख्या split चा अर्थ सर्व layers memory मध्ये बसले नाहीत; CPU share तुमचा वेग ठरवतो. Requirement चा अंदाज लावू नका. Model load करा आणि ही line वाचा.

Model अजिबात load होत नसेल, तर Ollama crash होण्याऐवजी व्यवस्थित नकार देते:

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

CPU-only VPS पुरेसा वेगवान आहे का?

सामान्य वापराच्या VPS मध्ये GPU नसतो. त्यामुळे सर्व काम CPU करतो आणि आवश्यक असलेले प्रत्येक weight system RAM मधून वाचतो. येथे MoE उपयुक्त ठरतो, कारण प्रत्येक token साठी 30 billion पैकी फक्त सुमारे 3 billion parameters वापरले जातात. त्यामुळे dense 30B model च्या तुलनेत प्रत्येक token साठीची गणना बरीच कमी असते. मात्र memory बाबतीत कोणतीही बचत होत नाही. सर्व 30 billion parameters memory मध्ये उपलब्ध ठेवावे लागतात, कारण router कोणत्याही token साठी कोणताही expert निवडू शकतो.

म्हणून या model वरील CPU-only inference ची मर्यादा core count पेक्षा memory bandwidth मुळे ठरते. आधीच पुरेशा vCPUs असलेल्या plan मध्ये आणखी vCPUs जोडल्याने फारसा फरक पडत नाही. Weights आणि तुमचा KV cache ठेवण्यासाठी पुरेशी RAM, तसेच plan मध्ये उपलब्ध असलेली सर्वात वेगवान memory आवश्यक आहे.

Agent त्यावर चालवण्याचा निर्णय घेण्यापूर्वी स्थानिक LLM साठी tokens per second मोजण्याची पद्धत वापरून वेग मोजा:

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

शेवटी छापली जाणारी eval rate line ही tokens per second मधील तुमची generation speed असते. हाच एक आकडा प्रश्नाचे उत्तर ठरवतो, कारण agent ला लागणारा wall-clock time प्रामुख्याने यावर अवलंबून असतो.

[
  {
    "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
  }
]

हे प्रकाशित केलेले third-party आकडे आहेत. ते launch वेळी Artificial Analysis ने नोंदवलेल्या प्रत्येक task साठीच्या minutes मधून रूपांतरित केले आहेत. हे आकडे VPS वर नव्हे, तर hosted GPU endpoints वर मोजले गेले. Nemotron 3.5 Lightning साठी प्रत्येक task ला सरासरी सुमारे 30 seconds लागले. त्यापैकी gpt-oss-120b ला साधारण 204 लागले, तर Qwen3.6 35B ला साधारण 210 लागले. हे आकडे तुमच्या hardware बाबत हमी म्हणून नव्हे, तर वेगातील फरकाची दिशा समजण्यासाठी वापरा.

कोण वाट पाहत आहे यानुसार योग्य मार्ग बदलतो. एखादी व्यक्ती agent च्या उत्तराची वाट पाहत असेल किंवा agent सलग अनेक calls करत असेल, तर GPU capacity भाड्याने घ्या. Agent overnight schedule वर चालत असेल आणि कोणीही त्याचे निरीक्षण करत नसेल, तर मोठ्या RAM असलेला CPU plan योग्य पर्याय आहे. दोन्ही बाबतीत setup समान राहतो. VPS वर Ollama चालवणे या विभागात plan sizing आणि GPU instance वापरणे विरुद्ध API provider ला प्रति token पैसे देणे यांची तुलना दिली आहे. Break-even हा utilisation चा प्रश्न आहे: GPU instance अस्तित्वात असलेल्या प्रत्येक तासासाठी billing करतो, तर API tokens वापर झाल्यावरच bill होतात. त्यामुळे दिवसभर व्यस्त असलेल्या agent साठी स्वतःचा box अधिक फायदेशीर ठरतो; मात्र तासाला दोनदा चालणाऱ्या agent साठी तो सहसा फायदेशीर ठरत नाही.

1M context window विनामूल्य नाही

1M tokens ही model ची कमाल मर्यादा आहे. Ollama ती मर्यादा default ने उपलब्ध करून देत नाही. Ollama खूपच लहान default window वापरतो आणि conversation ही मर्यादा ओलांडल्यावर सर्वात जुने tokens काढून टाकतो. असे झाल्यावर कोणतीही नोंद केली जात नाही. त्यामुळे agent ला model स्वतःच्या task ची सुरुवात विसरल्यासारखे दिसते.

Window जाणीवपूर्वक सेट करा. संपूर्ण server साठी service संपादित करा:

sudo systemctl edit ollama

हे जोडा आणि नंतर sudo systemctl restart ollama चालवा:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

प्रत्येक request साठी त्याऐवजी options object मध्ये 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
}'

प्रत्येक वाढीसाठी अधिक memory लागते, कारण तुम्ही अनुमती दिलेल्या tokens च्या संख्येनुसार KV cache वाढतो. Value वाढवा, restart करा, नंतर पुन्हा ollama ps चालवा आणि reported size वाढताना monitor करा. त्या बदलानंतर PROCESSOR column 100% GPU वरून split मध्ये बदलल्यास, KV cache मुळे model layers VRAM मधून बाहेर ढकलले गेले आहेत आणि तुमची speed मोठ्या प्रमाणात कमी होईल. Ollama मध्ये num_ctx निवडणे या trade-off चे सविस्तर स्पष्टीकरण देते. Model card मध्ये परवानगी असली तरी केवळ त्यावरून 1000000 सेट करू नका, कारण allocation सुरुवातीलाच होते आणि load थेट fail होते.

सतत चालू असलेल्या agent मध्ये त्याची जोडणी

Ollama च्या या model साठीच्या launch post मध्ये तो model वापरण्यासाठी आधीच configure केलेला समर्थित agent सुरू करणारी shortcut दिली आहे:

ollama launch claude --model nemotron-3.5-lightning

त्या post मध्ये त्या ठिकाणी claude, opencode, openclaw आणि hermes यांचे वर्णन केले आहे. या subcommand साठी सध्याचा Ollama आवश्यक आहे. त्यामुळे आधी ollama --version तपासा. ते उपलब्ध नसेल, तर agent ला स्वतः API कडे निर्देशित करा. Ollama OpenAI-compatible endpoint उपलब्ध करून देतो. बहुतेक agent harnesses हा endpoint स्वीकारतात:

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

Ollama या key कडे दुर्लक्ष करतो. मात्र बहुतेक clients key सेट केल्याशिवाय सुरू होण्यास नकार देतात. Harness च्या बाजूची माहिती coding agent ला Ollama कडे निर्देशित करणे आणि स्वतःचा OpenClaw agent तयार करणे येथे दिली आहे.

Agent unattended पद्धतीने चालू झाल्यावर server वरील दोन settings महत्त्वाच्या ठरतात. OLLAMA_KEEP_ALIVE शेवटच्या request नंतर model किती वेळ memory मध्ये ठेवायचा हे नियंत्रित करते. Default मुळे तो पाच मिनिटांनंतर unload होतो. त्यामुळे पुढील call वेळी पुन्हा पूर्ण load time लागतो. GPU नसलेल्या 25 GB file साठी हा विलंब timeout होण्यासाठी पुरेसा मोठा असतो. Model memory मध्येच ठेवण्यासाठी OLLAMA_KEEP_ALIVE=-1 सेट करा. OLLAMA_HOST=0.0.0.0:11434 मुळे इतर machines वरून API उपलब्ध होते. या API मध्ये कोणत्याही प्रकारचे authentication नसते. त्यामुळे ती केवळ firewall rule किंवा private network मागेच उघडा.

यंत्रणेत दिसणाऱ्या त्रुटी आणि त्यांच्याशी संबंधित संदेश

Pull त्वरित अयशस्वी होते. Error: pull model manifest: file does not exist याचा अर्थ तो tag अस्तित्वात नाही. Tag ची नावे अचूक strings असतात. त्यामुळे quantisation suffix चा अंदाज लावण्याऐवजी library page मधून एक tag कॉपी करा.

Model load होत नाही. Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) याचा अर्थ सध्याच्या configuration नुसार हा tag या plan साठी खूप मोठा आहे. कमी quantisation वापरा किंवा OLLAMA_CONTEXT_LENGTH कमी करा, कारण KV cache या requirement मध्येच मोजला जातो.

Port 11434 वर कोणताही प्रतिसाद मिळत नाही. curl: (7) Failed to connect to localhost port 11434 याचा अर्थ service चालू नाही किंवा अपेक्षित ठिकाणी listening करत नाही. systemctl status ollama आणि journalctl -u ollama -n 50 तपासा. तुम्ही ollama serve हातानेही सुरू केले असेल, तर दुसरी copy Error: listen tcp 127.0.0.1:11434: bind: address already in use सह बंद होते.

प्रतिसाद मिळतो, पण तो अतिशय संथ असतो. कोणताही बदल करण्यापूर्वी ollama ps तपासा. GPU असलेल्या machine वर PROCESSOR column मध्ये CPU चा कोणताही वापर दिसत असेल, तर model चा काही भाग VRAM बाहेर गेला आहे. त्यामुळे context कमी करा किंवा कमी quantisation वापरा. GPU नसलेल्या machine वर संथपणा अपेक्षित असतो आणि कोणतीही setting तो दूर करू शकत नाही.

Task च्या मध्ये agent आपल्या सूचना विसरतो. Conversation ने context window ची मर्यादा ओलांडली आणि सर्वात जुने tokens शांतपणे discard झाले. OLLAMA_CONTEXT_LENGTH वाढवा. ollama ps वापरून model अजूनही memory मध्ये बसतो का ते पडताळा. तो बसत नसेल, तर उपाय म्हणजे मोठी machine वापरणे; context window लहान करणे नाही.

ही रचना उपलब्ध पर्यायांच्या तुलनेत कुठे बसते

लहान कामासाठी 30B MoE होस्ट करणे मोठे काम आहे. घन 8B मॉडेल तुमचे काम आधीच हाताळत असेल, तर ते चालवणे आणि लोड करणे खूप कमी खर्चाचे असेल आणि ते काही सेकंदांत लोड होईल. या निर्णयासाठी VPS वर 8B आणि 27B मधील Qwen 3 ही थेट तुलना आहे. एखाद्या योजनेत प्रत्यक्षात कोणती मॉडेल्स ठेवता येतील याचा व्यापक आढावा हवा असल्यास, तुम्ही कोणती AI मॉडेल्स self-host करू शकता इथून सुरुवात करा. एकाच वेळी एका एजंटऐवजी अनेक एजंट्सना सेवा देण्याची योजना असल्यास, आधी Ollama ची vLLM शी तुलना वाचा. कारण production inference server प्रमाणे Ollama समांतर विनंत्यांचे batching करत नाही. याच ठिकाणी single-user setup ची scaling मर्यादा येते.

FAQ

Nemotron 3.5 Lightning साठी Linux VPS वर कोणता tag pull करावा?

nemotron-3.5-lightning:30b-a3b-q4_K_M वापरा. याचा आकार 25 GB आहे. यामध्ये पूर्ण 1M कमाल context उपलब्ध आहे. August 2026 पर्यंत latest, 30b आणि 30b-a3b हे tags याच digest कडे निर्देश करतात. latest pull करण्याऐवजी हे नाव स्पष्टपणे द्या. त्यामुळे भविष्यात तो pointer पुन्हा publish झाल्यास, तुमच्या agent चे वर्तन तुमच्या लक्षात न येता बदलणार नाही. mlx tags हे Apple silicon builds आहेत. Linux वर त्यांचा उपयोग होणार नाही.

Nemotron 3.5 Lightning साठी किती RAM आवश्यक आहे?

Ollama builds साठी NVIDIA किमान memory किती असावी हे प्रकाशित करत नाही. त्यामुळे अंदाज न लावता प्रत्यक्ष मोजमाप करा. tag pull करा, model एकदा चालवा आणि तो loaded असताना ollama ps वाचा. यामध्ये प्रत्यक्ष वापरलेला आकार आणि model GPU वर चालला की CPU वर, हे दिसते. Default tag चा download size 25 GB आहे. ही किमान मर्यादा समजा, कारण KV cache त्यावर अतिरिक्त असतो आणि तुम्ही सेट केलेल्या context window नुसार वाढतो. Plan अपुरा असल्यास, Ollama model requires more system memory सह नकार देते आणि दोन्ही संख्या दाखवते.

GPU नसलेल्या VPS वर Nemotron 3.5 Lightning चालवता येईल का?

होय, परंतु weights ठेवण्यासाठी plan मध्ये पुरेशी RAM असणे आवश्यक आहे. MoE design मुळे हे अधिक व्यवहार्य होते, कारण प्रत्येक token साठी 30 billion parameters पैकी फक्त सुमारे 3 billion parameters compute केले जातात. अडचण speed ची आहे. GPU नसताना model memory bandwidth मुळे मर्यादित राहतो. त्यामुळे vCPUs वाढवल्याने परिणामात फारसा फरक पडत नाही. निश्चित prompt सह ollama run --verbose चालवा, eval rate ओळ वाचा आणि तो आकडा तुमच्या agent च्या deadline शी तुलना करा. रात्री चालणाऱ्या batch job साठी हे अनेकदा पुरेसे असते. एखादी व्यक्ती उत्तराची वाट पाहत असेल, तर हे सहसा पुरेसे नसते.

Ollama मला पूर्ण 1M context window का देत नाही?

1M ही model ची कमाल मर्यादा आहे; ती Ollama ची default setting नाही. Ollama यापेक्षा खूप छोटी window लागू करते. Conversation तिच्यापेक्षा मोठी झाल्यावर ती error न दाखवता सर्वात जुने tokens discard करते. त्यामुळे agent स्वतःच्या instructions विसरल्यासारखे दिसते. systemd service वर OLLAMA_CONTEXT_LENGTH सेट करा किंवा प्रत्येक request साठी num_ctx पास करा. हे टप्प्याटप्प्याने वाढवा आणि प्रत्येक वेळी ollama ps पुन्हा तपासा. KV cache memory window च्या आकारानुसार वाढते आणि त्यामुळे model layers GPU बाहेर जाऊ शकतात.

Nemotron 3.5 Lightning व्यावसायिक वापरासाठी विनामूल्य आहे का?

NVIDIA च्या model card नुसार model OpenMDW-1.1 license अंतर्गत उपलब्ध आहे आणि commercial use साठी तयार आहे. हे तुम्ही स्वतः download करून चालवता त्या weights साठी लागू होते. तुमच्या stack मधील इतर software बद्दल त्यात काहीही सांगितलेले नाही. त्यामुळे agent harness आणि त्याच्याशी जोडलेल्या tools चे licenses स्वतंत्रपणे तपासा. कोणत्याही कराराशी संबंधित वापरावर अवलंबून राहण्यापूर्वी सध्याचे model card वाचा.