VPS پر Nemotron 3.5 Lightning کیسے چلائیں؟

Nemotron 3.5 Lightning کس مقصد کے لیے ہے

Nemotron 3.5 Lightning، NVIDIA کا open 30B mixture-of-experts ماڈل ہے، جو August 2026 میں جاری ہوا۔ یہ ایسے agents کے لیے بنایا گیا ہے جو ایک chat window کے بجائے کئی گھنٹے چلتے ہیں۔ MoE (mixture of experts) کا مطلب ہے کہ weights کو متعدد expert sub-networks میں تقسیم کیا جاتا ہے، اور ہر token صرف ان میں سے چند sub-networks سے گزرتا ہے۔ NVIDIA کے model card کے مطابق اس میں کل 30 billion parameters ہیں، جبکہ ہر token کے لیے 3 billion parameters فعال ہوتے ہیں۔ Memory میں آپ کو بڑی تعداد درکار ہوتی ہے، لیکن رفتار کے لحاظ سے چھوٹی تعداد کا فائدہ ملتا ہے۔

یہی trade-off اس ماڈل کو rented server کے لیے قابل غور بناتا ہے۔ حقیقی کام کرنے والا agent دن بھر میں ہزاروں مختصر requests بھیجتا ہے، اس لیے فی dollar throughput یہ طے کرتا ہے کہ اسے اپنے server پر چلانا عملی ہے یا نہیں۔ جو ماڈل ہر reply کے لیے 40 seconds لیتا ہے، وہ ایک قابل استعمال assistant تو ہو سکتا ہے، لیکن اچھا 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 کے لیے موزوں قرار دیا گیا ہے۔ بنیادی languages English اور code ہیں، جبکہ Spanish، French، German، Italian اور Japanese بھی فہرست میں شامل ہیں۔

Artificial Analysis نے August 2026 میں launch measurements شائع کیے۔ ان measurements میں pre-release DeepInfra endpoint پر NVFP4 weights استعمال کرتے ہوئے تقریباً 670 output tokens per second دکھائے گئے۔ یہ hosted GPU endpoint کی کارکردگی ہے۔ اسے architecture کی ممکنہ صلاحیت سمجھیں، نہ کہ اپنی VPS کی متوقع کارکردگی۔

کون سا Ollama tag کس VPS کے لیے موزوں ہے

Ollama library ایک ہی weights کے کئی builds شائع کرتی ہے۔ ان builds کے درمیان فرق quantisation کا ہے، یعنی ہر weight کو کتنے bits میں محفوظ کیا جاتا ہے۔ اس سے 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 کے لیے ہیں اور ان کی حد 256K context ہے۔ اس لیے Linux VPS پر یہ درست انتخاب نہیں ہیں۔

یہ download sizes ہیں، memory requirement نہیں۔ NVIDIA، Ollama builds کے لیے minimum VRAM (video RAM) کی کوئی مقدار شائع نہیں کرتا۔ اس لیے download size کو صرف کم از کم حد سمجھیں، اس سے زیادہ کچھ نہیں۔ Weights کو کسی نہ کسی memory میں موجود رہنا ہوتا ہے۔ اگر GPU card انہیں رکھ سکے تو وہ GPU memory میں رہتے ہیں، ورنہ system RAM میں۔ اس کے علاوہ KV cache (key/value cache، یعنی conversation کی ہر token کے لیے model کی memory) بھی شامل ہوتی ہے۔ آپ کے hardware کے لیے اصل مقدار command سے معلوم ہوتی ہے، حساب سے نہیں، اور وہ نیچے دی گئی ہے۔ اگر آپ نے ابھی تک quantisation level منتخب نہیں کیا تو Q4، Q8 اور FP16 کے انتخاب کی لاگت میں بتایا گیا ہے کہ ہر مرحلے پر کیا چیز قربان ہوتی ہے۔

درست tag حاصل کریں، کبھی latest نہیں

latest ایک متحرک pointer ہے۔ جب library اسے دوبارہ publish کرتی ہے تو آپ کے agent کا رویہ اگلی pull پر تبدیل ہو جاتا ہے، اور آپ کی notes میں اس کی وجہ درج نہیں ہوتی۔ 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 رپورٹ کرے تو اس کا مطلب بعینہٖ یہی ہے۔ جزوی blobs اس وقت تک 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"

ماڈل کے load رہنے کے دوران دوسری shell میں:

ollama ps

یہ command آپ کی machine کے لیے memory سے متعلق سوال کا جواب دیتی ہے۔ ollama ps loaded model، memory میں اس کے استعمال کردہ size، اور PROCESSOR column دکھاتا ہے۔ 100% GPU کا مطلب ہے کہ پورا model VRAM میں ہے۔ 100% CPU کا مطلب ہے کہ اس کا کوئی حصہ VRAM میں نہیں، اور ہر token کو system RAM سے processor compute کرتا ہے۔ 65%/35% CPU/GPU جیسی تقسیم کا مطلب ہے کہ تمام layers fit نہیں ہوئیں، اور CPU کا حصہ آپ کی speed متعین کرتا ہے۔ requirement کا اندازہ نہ لگائیں۔ اسے load کریں اور یہ line پڑھیں۔

اگر یہ بالکل load نہ ہو سکے تو Ollama crash ہونے کے بجائے صاف طور پر انکار کرتا ہے:

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

کیا صرف CPU والا VPS کافی تیز ہے؟

عام مقاصد کے لیے VPS میں GPU نہیں ہوتا، اس لیے تمام کام CPU کرتا ہے اور اسے درکار ہر weight system RAM سے پڑھتا ہے۔ MoE اس معاملے میں مدد کرتا ہے، کیونکہ ہر token کے لیے 30 billion parameters میں سے صرف تقریباً 3 billion استعمال ہوتے ہیں۔ اس لیے ہر token کے لیے arithmetic، dense 30B model کے مقابلے میں بہت کم ہوتا ہے۔ Memory کے معاملے میں کوئی فائدہ نہیں ہوتا۔ تمام 30 billion parameters کو memory میں موجود رہنا چاہیے، کیونکہ router کسی بھی token کے لیے کوئی بھی expert منتخب کر سکتا ہے۔

اس لیے اس model پر CPU-only inference کی رفتار core count کے بجائے memory bandwidth محدود کرتی ہے۔ ایسے 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 آپ کی generation speed، یعنی tokens per second، بتاتی ہے۔ یہی ایک عدد اس سوال کا فیصلہ کرتا ہے، کیونکہ 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 کرائے پر لیں۔ اگر یہ رات بھر schedule کے مطابق چلتا ہے اور کوئی اسے دیکھ نہیں رہا، تو بڑی RAM والا CPU plan مناسب انتخاب ہے۔ دونوں صورتوں میں setup ایک جیسا رہتا ہے، اور VPS پر Ollama چلانا plan sizing کے ساتھ یہ بھی بیان کرتا ہے کہ GPU instance کا موازنہ فی token API provider کو ادائیگی سے کیسے کیا جائے۔ Break-even کا تعلق utilisation سے ہے: GPU instance ہر اس گھنٹے کا bill لیتا ہے جس میں وہ موجود ہو، جبکہ API tokens کا bill صرف استعمال کے وقت بنتا ہے۔ اس لیے جو agent دن کے زیادہ حصے میں مصروف رہتا ہو، اس کے لیے اپنا box بہتر ہے؛ لیکن جو agent ایک گھنٹے میں دو بار چلتا ہو، اس کے لیے عموماً ایسا نہیں ہوتا۔

1M context window مفت نہیں ہے

1M tokens ماڈل کی زیادہ سے زیادہ حد ہے، اور 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 استعمال کرتا ہے، کیونکہ KV cache ان tokens کی تعداد کے ساتھ بڑھتا ہے جن کی آپ اجازت دیتے ہیں۔ Value بڑھائیں، پھر restart کریں، اور اس کے بعد دوبارہ ollama ps چلائیں۔ Report ہونے والے size میں اضافے کو monitor کریں۔ اگر اس تبدیلی کے بعد PROCESSOR column 100% GPU سے split پر تبدیل ہو جائے تو KV cache نے model layers کو VRAM سے باہر دھکیل دیا ہے، اور آپ کی speed بہت کم ہو جائے گی۔ Ollama میں num_ctx کا انتخاب اس trade-off کی تفصیل بیان کرتا ہے۔ صرف اس وجہ سے 1000000 مقرر نہ کریں کہ model card اس کی اجازت دیتا ہے، کیونکہ allocation ابتدا ہی میں ہو جاتی ہے اور load ناکام ہو جاتا ہے۔

ہمیشہ فعال agent میں اسے شامل کرنا

Ollama کی اس model سے متعلق launch post میں ایک مختصر طریقہ درج ہے جو پہلے سے supported agent شروع کرتا ہے اور اسے اسی model کے لیے configure کر دیتا ہے:

ollama launch claude --model nemotron-3.5-lightning

اس post میں اسی جگہ claude، opencode، openclaw اور hermes درج ہیں۔ اس subcommand کے لیے موجودہ Ollama درکار ہے، اس لیے پہلے ollama --version چیک کریں۔ اگر یہ موجود نہ ہو تو agent کو خود API پر configure کریں۔ Ollama، OpenAI-compatible endpoint فراہم کرتا ہے جسے زیادہ تر agent harnesses قبول کرتے ہیں:

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

Ollama اس key کو نظرانداز کرتا ہے، لیکن زیادہ تر clients کسی key کے set کیے بغیر شروع نہیں ہوتے۔ harness کی جانب سے اس کی وضاحت coding agent کو Ollama کی طرف بھیجنا اور اپنا OpenClaw agent بنانا میں کی گئی ہے۔

Agent کے unattended طور پر چلنے کے بعد server کی دو settings اہم ہوتی ہیں۔ OLLAMA_KEEP_ALIVE اس مدت کو کنٹرول کرتا ہے جس کے بعد آخری request آنے پر model memory میں رہتا ہے۔ default کے طور پر یہ اسے five minutes بعد unload کر دیتا ہے، اس لیے اگلی call پر مکمل load time دوبارہ درکار ہوتا ہے۔ 25 GB کی file پر، GPU کے بغیر یہ وقفہ timeout توڑنے کے لیے کافی طویل ہو سکتا ہے۔ اسے memory میں برقرار رکھنے کے لیے OLLAMA_KEEP_ALIVE=-1 set کریں۔ 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 کے نام عین اسی string کے مطابق ہوتے ہیں، اس لیے 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 چل نہیں رہی یا متوقع جگہ پر 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 کے ساتھ exit ہو جاتی ہے۔

جواب آتا ہے، لیکن بہت آہستہ۔ کچھ تبدیل کرنے سے پہلے ollama ps دیکھیں۔ GPU والی machine پر PROCESSOR column میں CPU کا کوئی بھی حصہ ظاہر ہو تو اس کا مطلب ہے کہ model کا کچھ حصہ VRAM سے باہر منتقل ہو گیا ہے، اس لیے context کم کریں یا چھوٹی quantisation استعمال کریں۔ ایسی machine پر جس میں GPU نہ ہو، سست رفتار متوقع ہے اور کوئی setting اسے درست نہیں کر سکتی۔

Agent کام کے دوران اپنی ہدایات بھول جاتا ہے۔ Conversation context window سے آگے بڑھ گئی اور قدیم ترین tokens خاموشی سے discard ہو گئے۔ OLLAMA_CONTEXT_LENGTH بڑھائیں، ollama ps سے تصدیق کریں کہ model اب بھی fit ہوتا ہے، اور اگر fit نہ ہو تو حل چھوٹی window نہیں بلکہ بڑی machine ہے۔

یہ ماڈل متبادل ماڈلز کے مقابلے میں کہاں کھڑا ہے

چھوٹے کام کے لیے 30B MoE کو host کرنا ایک بڑا انتظامی بوجھ ہے۔ اگر dense 8B ماڈل پہلے ہی آپ کا کام سنبھال لیتا ہے تو اسے چلانے کی لاگت بہت کم ہوگی اور یہ چند سیکنڈ میں load ہو جائے گا۔ اس فیصلے کے لیے VPS پر 8B اور 27B کا Qwen 3 براہِ راست موازنہ پیش کرتا ہے۔ کسی plan میں عملی طور پر کون سے ماڈلز سما سکتے ہیں، اس کا وسیع جائزہ لینے کے لیے کون سے AI ماڈلز آپ self-host کر سکتے ہیں سے شروع کریں۔ اگر آپ ایک وقت میں ایک agent کے بجائے متعدد agents serve کرنا چاہتے ہیں تو پہلے Ollama کا vLLM سے موازنہ پڑھیں، کیونکہ Ollama concurrent requests کو اس طرح batch نہیں کرتا جیسے production inference server کرتا ہے۔ یہی وہ مقام ہے جہاں single-user setup کی scalability ختم ہونے لگتی ہے۔

FAQ

Linux VPS پر کون سا Nemotron 3.5 Lightning tag pull کرنا چاہیے؟

nemotron-3.5-lightning:30b-a3b-q4_K_M استعمال کریں۔ اس کا حجم 25 GB ہے، اس میں مکمل 1M maximum context شامل ہے، اور August 2026 تک یہی وہ digest ہے جس کی طرف latest، 30b اور 30b-a3b tags اشارہ کرتے ہیں۔ اسے واضح طور پر نامزد کریں، latest pull نہ کریں، تاکہ مستقبل میں اس pointer کو دوبارہ publish کرنے سے آپ کے agent کا رویہ آپ کے علم کے بغیر تبدیل نہ ہو۔ mlx tags Apple silicon builds ہیں اور Linux پر آپ کے لیے مفید نہیں ہوں گے۔

Nemotron 3.5 Lightning کو کتنی RAM درکار ہے؟

NVIDIA نے Ollama builds کے لیے minimum 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 کے ساتھ failure ظاہر کرتا ہے اور دونوں اعداد بتاتا ہے۔

کیا GPU کے بغیر VPS پر Nemotron 3.5 Lightning چلایا جا سکتا ہے؟

ہاں، بشرطیکہ plan میں weights رکھنے کے لیے کافی RAM ہو۔ MoE design بھی مدد کرتا ہے، کیونکہ ہر token کے لیے 30 billion parameters میں سے صرف تقریباً 3 compute کیے جاتے ہیں۔ اصل مسئلہ رفتار ہے۔ GPU کے بغیر model memory bandwidth سے محدود ہوتا ہے، اس لیے vCPUs بڑھانے سے نتیجہ بہت کم بہتر ہوتا ہے۔ مقررہ prompt کے ساتھ ollama run --verbose چلائیں، eval rate line پڑھیں، اور اس عدد کا موازنہ اپنے agent کی deadline سے کریں۔ رات بھر چلنے والے batch job کے لیے یہ اکثر کافی ہوتا ہے۔ جس کام کے نتیجے کا کوئی شخص انتظار کر رہا ہو، اس کے لیے عموماً کافی نہیں ہوتا۔

Ollama مجھے مکمل 1M context window کیوں نہیں دیتا؟

1M model کی maximum حد ہے، Ollama کی default حد نہیں۔ Ollama اس سے کہیں چھوٹی window استعمال کرتا ہے اور conversation کے اس حد سے تجاوز کرنے پر پرانے tokens حذف کر دیتا ہے۔ کوئی error بھی ظاہر نہیں ہوتا، جس سے ایسا محسوس ہوتا ہے کہ agent اپنی ہدایات بھول گیا ہے۔ 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 کے لیے تیار قرار دیا گیا ہے۔ یہ ان weights پر لاگو ہوتا ہے جنہیں آپ خود download کر کے چلاتے ہیں۔ اس میں آپ کے stack کے دوسرے software شامل نہیں ہیں، اس لیے agent harness اور اس سے منسلک tools کے licenses الگ سے چیک کریں۔ کسی contractual کام کے لیے اس پر انحصار کرنے سے پہلے موجودہ model card بھی پڑھیں۔