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

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

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

तुम्ही भाड्याने घेतलेल्या server साठी या मॉडेलचा विचार करण्याचे कारण हा trade-off आहे. प्रत्यक्ष काम करणारा agent दिवसभरात हजारो short requests पाठवतो. त्यामुळे तो तुमच्या स्वतःच्या box वर चालू शकतो की नाही हे throughput per dollar ठरवते. प्रत्येक reply साठी 40 seconds लागणारे मॉडेल वापरण्यायोग्य assistant असू शकते, पण ते poor agent ठरते. कारण एका task साठी 20 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 साठी तयार असल्याचे नमूद केले आहे. Primary languages English आणि code आहेत. Spanish, French, German, Italian आणि Japanese यांचाही उल्लेख आहे.

Artificial Analysis ने August 2026 मध्ये launch measurements प्रकाशित केली. NVFP4 weights देणाऱ्या pre-release DeepInfra endpoint वर जवळपास 670 output tokens per second वेग नोंदवला गेला. हा hosted GPU endpoint आहे. हा वेग architecture कशाला सक्षम आहे याचे मोजमाप म्हणून पाहा; तुमचा VPS प्रत्यक्षात एवढा वेग देईल असे समजू नका.

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

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, म्हणजे model कडे संभाषणातील प्रत्येक token साठी असलेली memory) देखील लागतो. तुमच्या hardware साठी प्रत्यक्ष संख्या arithmetic करून नाही, तर command चालवून मिळते. ती command खाली दिली आहे. तुम्ही quantisation level अद्याप ठरवला नसेल, तर Q4, Q8 आणि FP16 मध्ये प्रत्येकासाठी कोणती किंमत मोजावी लागते येथे प्रत्येक टप्प्यावर काय गमवावे लागते हे स्पष्ट केले आहे.

नेमका tag pull करा, latest कधीही वापरू नका

latest हा बदलता pointer आहे. Library तो पुन्हा प्रकाशित केल्यावर तुमच्या 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 तयार करते. ही service ollama user म्हणून चालते आणि models /usr/share/ollama/.ollama/models अंतर्गत ठेवते. बहुतेक VPS images मध्ये हा path root filesystem वर असतो. त्यामुळे 25 GB मागण्यापूर्वी उपलब्ध जागा तपासा. त्या filesystem मध्ये जागा कमी असल्यास, pull करण्यापूर्वी Ollama त्याचे models कुठे साठवते आणि ते कसे हलवायचे हे वाचणे उपयुक्त ठरेल. Disk भरल्यानंतर हे तपासण्यापेक्षा आधीच माहिती घेणे योग्य आहे.

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 म्हणजे त्यातील काहीही VRAM मध्ये नाही आणि प्रत्येक token system RAM मधून processor द्वारे compute केला जातो. 65%/35% CPU/GPU सारखा split म्हणजे सर्व layers memory मध्ये बसले नाहीत आणि CPU share मुळे तुमचा वेग ठरतो. आवश्यकता अंदाजाने ठरवू नका. Model load करा आणि ही line वाचा.

ते अजिबात 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 वापरले जातात. त्यामुळे प्रत्येक token साठी लागणारी गणना dense 30B model पेक्षा खूपच कमी असते. मात्र 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 प्रामुख्याने त्यावर अवलंबून असतो. अपेक्षित reply ची लांबी या वेगाने गुणा. मिळणारा वेळ तुम्ही प्रतीक्षा करण्यास तयार असलेल्या वेळेपेक्षा जास्त असल्यास, hardware न बदलता एका call ची मर्यादा ठरवण्यासाठी num_predict ने output मर्यादित करणे हा एकमेव थेट उपाय आहे.

[
  {
    "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 आकडेवारी आहे. ती Artificial Analysis ने launch वेळी दिलेल्या प्रत्येक task साठीच्या मिनिटांमधून रूपांतरित केली आहे. हे मोजमाप VPS वर नव्हे, तर hosted GPU endpoints वर करण्यात आले होते. Nemotron 3.5 Lightning ने प्रत्येक task साठी सरासरी 30 सेकंद घेतले. त्यापैकी gpt-oss-120b साठी अंदाजे 204 सेकंद आणि Qwen3.6 35B साठी अंदाजे 210 सेकंद लागले. तुमच्या hardware बाबत हमी समजण्याऐवजी, फरकाचा अंदाज समजण्यासाठी हे आकडे वापरा.

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

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

1M tokens ही model ची कमाल मर्यादा आहे. Ollama ती मर्यादा default ने उपलब्ध करून देत नाही. Ollama खूपच लहान default window वापरते आणि conversation त्यापेक्षा मोठी झाल्यावर सर्वात जुने tokens काढून टाकते. असे झाल्यावर कोणतेही log नोंदवले जात नाही. त्यामुळे 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 चालवा आणि दर्शविलेला 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 मध्ये त्याची जोडणी

या model साठीच्या Ollama च्या launch post मध्ये, त्याकडे आधीच निर्देशित केलेला समर्थित agent सुरू करणारा shortcut दिला आहे:

ollama launch claude --model nemotron-3.5-lightning

त्या ठिकाणी या post मध्ये claude, opencode, openclaw आणि hermes यांचे दस्तऐवजीकरण केले आहे. या subcommand साठी अद्ययावत Ollama आवश्यक आहे. त्यामुळे प्रथम ollama --version तपासा. ते उपलब्ध नसेल, तर agent ला API कडे स्वतः निर्देशित करा. Ollama OpenAI-सुसंगत 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 unattended पद्धतीने चालू झाल्यावर दोन server settings महत्त्वाच्या ठरतात. OLLAMA_KEEP_ALIVE शेवटच्या request नंतर model किती वेळ memory मध्ये ठेवायचा हे नियंत्रित करते. तिची default value model पाच मिनिटांनंतर unload करते. त्यामुळे पुढील call साठी पुन्हा पूर्ण load time लागतो. GPU नसलेल्या 25 GB file वर हा विलंब timeout होण्यासाठी पुरेसा मोठा असतो. Model memory मध्ये ठेवण्यासाठी OLLAMA_KEEP_ALIVE=-1 सेट करा. OLLAMA_HOST=0.0.0.0:11434 मुळे API इतर machines वरून पोहोचण्यायोग्य होते. त्यात कोणत्याही प्रकारचे authentication नसते. त्यामुळे ते फक्त firewall rule किंवा private network च्या मागेच उघडा.

अपयशाची कारणे आणि दिसणारे संदेश

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

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

Port 11434 वर कोणतेही उत्तर मिळत नाही. curl: (7) Failed to connect to localhost port 11434 याचा अर्थ service चालू नाही किंवा तुम्ही अपेक्षा केलेल्या ठिकाणी ती listen करत नाही. 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 share दिसत असेल, तर model चा काही भाग VRAM बाहेर spill झाला आहे. त्यामुळे context कमी करा किंवा लहान quantisation वापरा. GPU नसलेल्या machine वर धीमेपणा अपेक्षित असतो आणि कोणतीही setting तो दुरुस्त करू शकत नाही.

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

पर्यायांच्या तुलनेत हे मॉडेल कुठे बसते

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

FAQ

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

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

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

Ollama builds साठी NVIDIA किमान memory चे प्रमाण प्रकाशित करत नाही. त्यामुळे अंदाज न लावता प्रत्यक्ष मोजणी करा. Tag pull करा, model एकदा चालवा आणि तो loaded असताना ollama ps वाचा. यात प्रत्यक्ष व्यापलेली size आणि 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 चालवता येईल का?

होय, जर plan मध्ये weights ठेवण्यासाठी पुरेशी RAM असेल. MoE रचनेमुळेही मदत होते, कारण प्रत्येक token साठी 30 billion parameters पैकी फक्त सुमारे 3 parameters वर computation होते. मात्र 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 काढून टाकते. त्यामुळे agent स्वतःच्या instructions विसरल्यासारखे दिसते. systemd service वर OLLAMA_CONTEXT_LENGTH सेट करा किंवा प्रत्येक request साठी num_ctx pass करा. हे टप्प्याटप्प्याने वाढवा आणि प्रत्येक वेळी 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 चे licences स्वतंत्रपणे तपासा. तसेच कोणत्याही contractual वापरावर अवलंबून राहण्यापूर्वी सध्याचे model card वाचा.