VPS-এ Ollama দিয়ে Nemotron 3.5 Lightning চালাবেন কীভাবে

Nemotron 3.5 Lightning কী কাজে ব্যবহৃত হয়

Nemotron 3.5 Lightning হলো NVIDIA-এর open 30B mixture-of-experts model। এটি August 2026-এ released হয়েছে। এই মডেল এমন agent-এর জন্য তৈরি, যা একটি chat window-এ সীমাবদ্ধ না থেকে ঘণ্টার পর ঘণ্টা চলে। MoE (mixture of experts) বলতে বোঝায়, weights-গুলোকে একাধিক expert sub-network-এ ভাগ করা হয় এবং প্রতিটি token সেগুলোর মধ্যে অল্প কয়েকটির মধ্য দিয়ে routed হয়। NVIDIA-এর model card অনুযায়ী, এতে মোট 30 billion parameters এবং প্রতি token-এ 3 billion active parameters রয়েছে। Memory-তে বড় সংখ্যাটির খরচ দিতে হয়। Speed-এর ক্ষেত্রে ছোট সংখ্যাটির সুবিধা পাওয়া যায়।

এই trade-off-এর কারণেই আপনি ভাড়া করা server-এ এই মডেল ব্যবহার করার কথা বিবেচনা করতে পারেন। কোনো agent বাস্তব কাজ করার সময় এক দিনে হাজার হাজার ছোট request পাঠায়। তাই প্রতি dollar-এ throughput নির্ধারণ করে, এটি নিজের server-এ চালানো বাস্তবসম্মত কি না। প্রতিটি reply দিতে 40 seconds লাগলে মডেলটি সাধারণ assistant হিসেবে ব্যবহারযোগ্য, কিন্তু agent-এর জন্য দুর্বল। কারণ একটি task-এ 20টি call লাগতে পারে এবং প্রতিটির জন্য অপেক্ষা করতে হয়।

NVIDIA এই architecture-কে hybrid হিসেবে বর্ণনা করেছে। এতে interleaved Mamba-2 ও MoE layer-এর সঙ্গে select attention layer রয়েছে। Model card অনুযায়ী, maximum context length 1M tokens পর্যন্ত এবং license হলো OpenMDW-1.1, যা commercial use-এর জন্য ready হিসেবে চিহ্নিত। প্রধান language হলো English ও code। এছাড়া Spanish, French, German, Italian এবং Japanese-ও তালিকাভুক্ত রয়েছে।

Artificial Analysis August 2026-এ প্রকাশিত launch measurement-এ প্রায় 670 output tokens per second দেখিয়েছে। এই measurement নেওয়া হয়েছিল NVFP4 weights সরবরাহকারী pre-release DeepInfra endpoint-এ। এটি একটি hosted GPU endpoint-এর ফলাফল। এটিকে architecture-এর সম্ভাব্য ক্ষমতা হিসেবে বিবেচনা করুন, আপনার VPS-এ পাওয়া যাবে এমন performance হিসেবে নয়।

কোন VPS-এর জন্য কোন Ollama tag উপযুক্ত

Ollama library একই weights-এর একাধিক build প্রকাশ করে। এগুলোর মধ্যে মূল পার্থক্য হলো quantisation। অর্থাৎ প্রতিটি weight কত bit-এ সংরক্ষিত হয়। এর ফলে 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 নামের tag-গুলো 30b-a3b-q4_K_M-এর একই digest-এ resolve হয়। তাই default download হলো 25 GB-এর four-bit build, যাতে পূর্ণ 1M context থাকে। Q8_0-এর size 35 GB এবং bf16-এর size 66 GB; উভয়টির ক্ষেত্রেও context 1M। 23 GB-এর MLX build-গুলো Apple silicon-এর জন্য এবং সর্বোচ্চ 256K context সমর্থন করে। তাই Linux VPS-এ এগুলো সঠিক পছন্দ নয়।

এগুলো download size, memory requirement নয়। Ollama build-এর জন্য NVIDIA কোনো minimum VRAM (video RAM) figure প্রকাশ করে না। তাই download size-কে শুধু ন্যূনতম সীমা হিসেবে ধরুন, এর বেশি কিছু নয়। Weights-গুলো কোনো না কোনো memory-তে resident থাকতে হবে। GPU card সেগুলো ধারণ করতে পারলে GPU memory-তে থাকবে, না হলে system RAM-এ থাকবে। এর সঙ্গে KV cache (key/value cache; conversation-এর প্রতি token-এর জন্য model যে memory ব্যবহার করে) অতিরিক্তভাবে যোগ হবে। আপনার hardware-এর প্রকৃত সংখ্যা একটি command চালিয়ে জানা যায়, arithmetic করে নয়; সেই command নিচে আছে। এখনও quantisation level নির্ধারণ না করে থাকলে, Q4, Q8 এবং FP16 বেছে নিলে কী খরচ হয় প্রতিটি ধাপে কী ত্যাগ করতে হয় তা ব্যাখ্যা করে।

নির্দিষ্ট tag সংগ্রহ করুন, কখনও latest নয়

latest একটি পরিবর্তনশীল pointer। library এটি পুনরায় প্রকাশ করলে, আপনার নোটে কারণের কোনো তথ্য না থাকলেও পরবর্তী pull-এ agent-এর আচরণ বদলে যাবে। tag-এর নাম স্পষ্টভাবে উল্লেখ করুন।

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

ইনস্টল script এমন একটি systemd service তৈরি করে, যা ollama user হিসেবে চলে এবং model-গুলো /usr/share/ollama/.ollama/models-এর অধীনে রাখে। অধিকাংশ VPS image-এ এই path root filesystem-এ থাকে। তাই 25 GB চাওয়ার আগে খালি জায়গা আছে কি না পরীক্ষা করুন।

df -h /usr/share/ollama

কোনো pull মাঝপথে থেমে no space left on device দেখালে তার অর্থ ঠিক সেটিই। আংশিক blob-গুলো আপনি মুছে না ফেলা পর্যন্ত 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

এই command-টি আপনার মেশিনে মেমরির প্রশ্নের সরাসরি উত্তর দেয়। ollama ps লোড করা model, এটি মেমরিতে যতটা জায়গা দখল করে, এবং একটি PROCESSOR column দেখায়। 100% GPU-এর অর্থ, পুরো model-টি VRAM-এ আছে। 100% CPU-এর অর্থ, model-এর কোনো অংশ VRAM-এ নেই এবং প্রতিটি token system RAM থেকে processor দ্বারা গণনা করা হচ্ছে। 65%/35% CPU/GPU-এর মতো split-এর অর্থ, সব layer মেমরিতে fit করেনি; CPU-এর অংশ আপনার গতি নির্ধারণ করে। প্রয়োজনীয়তা অনুমান করবেন না। এটি 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 parameter-এর মধ্যে প্রায় 3 billion parameter-ই ব্যবহার করা হয়। ফলে dense 30B model-এর তুলনায় প্রতি token-এ arithmetic কাজ অনেক কম। Memory ব্যবহারে কোনো সুবিধা হয় না। সব 30 billion parameter memory-তে resident রাখতে হয়, কারণ router যেকোনো token-এর জন্য যেকোনো expert বেছে নিতে পারে।

তাই এই model-এ CPU-only inference core count-এর পরিবর্তে memory bandwidth দ্বারা সীমাবদ্ধ। ইতিমধ্যে পর্যাপ্ত vCPU থাকা plan-এ আরও vCPU যোগ করলে সাধারণত খুব কম পরিবর্তন হয়। আপনার দরকার weights এবং KV cache রাখার মতো পর্যাপ্ত RAM, এবং plan-এ দেওয়া দ্রুততম memory।

কোনো agent এতে চালানোর সিদ্ধান্ত নেওয়ার আগে local 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 figure। এগুলো Artificial Analysis launch-এর সময় জানানো প্রতি-task minute থেকে রূপান্তর করা হয়েছে। পরিমাপটি VPS-এ নয়, hosted GPU endpoint-এ করা হয়েছিল। Nemotron 3.5 Lightning প্রতি task-এ গড়ে প্রায় 30 সেকেন্ড নিয়েছে। এর মধ্যে gpt-oss-120b-এ প্রায় 204 সেকেন্ড এবং Qwen3.6 35B-এ প্রায় 210 সেকেন্ড লেগেছে। এগুলো hardware performance-এর ব্যবধান বোঝার জন্য ব্যবহার করুন, আপনার hardware সম্পর্কে নিশ্চয়তা হিসেবে নয়।

সৎ সিদ্ধান্তটি নির্ভর করে কে অপেক্ষা করছে তার ওপর। কোনো ব্যক্তি agent-এর ফলাফলের জন্য অপেক্ষা করলে, অথবা agent পরপর দীর্ঘ call chain চালালে, GPU capacity ভাড়া নিন। agent যদি রাতের schedule-এ চলে এবং কেউ তা পর্যবেক্ষণ না করে, তাহলে বেশি RAM-সহ CPU plan যুক্তিসঙ্গত পছন্দ। উভয় ক্ষেত্রেই setup একই। VPS-এ Ollama চালানো অংশে plan sizing এবং API provider-কে প্রতি token অনুযায়ী অর্থ দেওয়ার তুলনায় GPU instance কেমন তা ব্যাখ্যা করা হয়েছে। Break-even utilisation-এর ওপর নির্ভর করে। GPU instance চালু থাকা প্রতিটি ঘণ্টার জন্য bill হয়। API token ব্যবহারের সময়ই bill হয়। তাই দিনের বেশিরভাগ সময় ব্যস্ত থাকা agent-এর জন্য নিজের box সুবিধাজনক। আর প্রতি ঘণ্টায় দুবার চালু হওয়া agent-এর ক্ষেত্রে সাধারণত তা সুবিধাজনক নয়।

1M token-এর context window বিনামূল্যে নয়

1M token হলো মডেলের সর্বোচ্চ সীমা। Ollama এটি ডিফল্টভাবে আপনাকে দেয় না। Ollama অনেক ছোট একটি default window ব্যবহার করে। কোনো conversation সেই সীমা অতিক্রম করলে এটি পুরোনো token বাদ দিতে থাকে। এ ঘটনা ঘটলে কোনো log লেখা হয় না। তাই agent-এর কাছে মনে হয়, মডেলটি নিজের 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 খরচ বাড়ায়। কারণ আপনি যত token অনুমোদন করেন, KV cache তত বড় হয়। মান বাড়ান, restart করুন, তারপর আবার ollama ps চালান এবং প্রদর্শিত size বাড়ছে কি না monitor করুন। পরিবর্তনের পরে PROCESSOR column যদি 100% GPU থেকে split অবস্থায় পরিবর্তিত হয়, তাহলে KV cache মডেলের layer-গুলোকে VRAM-এর বাইরে ঠেলে দিয়েছে এবং আপনার speed অনেক কমে যাবে। Ollama-তে num_ctx নির্বাচন করা এই trade-off বিস্তারিতভাবে ব্যাখ্যা করে। শুধু model card-এ অনুমোদিত আছে বলে 1000000 সেট করবেন না। কারণ allocation শুরুতেই করা হয় এবং load সরাসরি ব্যর্থ হয়।

সর্বদা চালু থাকা agent-এ সংযুক্ত করা

এই model-এর জন্য Ollama-এর launch post-এ একটি shortcut দেখানো হয়েছে, যা model-টির দিকে নির্দেশ করা একটি supported agent চালু করে:

ollama launch claude --model nemotron-3.5-lightning

এই অবস্থানে post-টিতে claude, opencode, openclaw এবং hermes নথিবদ্ধ করা হয়েছে। এই subcommand-এর জন্য বর্তমান Ollama প্রয়োজন। তাই প্রথমে ollama --version পরীক্ষা করুন। এটি না থাকলে agent-কে নিজে API-এর দিকে নির্দেশ করুন। Ollama একটি OpenAI-compatible endpoint প্রকাশ করে, যা বেশির ভাগ agent harness গ্রহণ করে:

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

Ollama key-টি উপেক্ষা করে। তবে অধিকাংশ client key সেট না থাকলে চালু হতে অস্বীকার করে। এই harness-সংক্রান্ত বিষয়টি Ollama-এর দিকে coding agent নির্দেশ করা এবং নিজস্ব OpenClaw agent তৈরি করা অংশে ব্যাখ্যা করা হয়েছে।

agent unattended অবস্থায় চললে server-এর দুটি setting গুরুত্বপূর্ণ। OLLAMA_KEEP_ALIVE শেষ request-এর পর model কতক্ষণ memory-তে থাকবে তা নিয়ন্ত্রণ করে। Default হিসেবে পাঁচ মিনিট পর model unload হয়। ফলে পরের call-এ আবার সম্পূর্ণ load time লাগে। GPU ছাড়া 25 GB file-এর ক্ষেত্রে এই বিরতি timeout অতিক্রম করে কাজ ব্যর্থ করার জন্য যথেষ্ট দীর্ঘ হতে পারে। model-টিকে memory-তে ধরে রাখতে OLLAMA_KEEP_ALIVE=-1 সেট করুন। OLLAMA_HOST=0.0.0.0:11434 API-টিকে অন্য machine থেকেও reachable করে। এতে কোনো authentication থাকে না। তাই এটি কেবল firewall rule বা private network-এর আড়ালে খুলুন।

ব্যর্থতার ধরন এবং যে স্ট্রিংগুলো আপনি দেখতে পাবেন

Pull সঙ্গে সঙ্গে ব্যর্থ হয়। Error: pull model manifest: file does not exist বোঝায় যে ওই tag বিদ্যমান নেই। Tag-এর নাম হুবহু নির্দিষ্ট string, তাই quantisation suffix অনুমান না করে library page থেকে একটি নাম কপি করুন।

Model load হয় না। Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) বোঝায় যে বর্তমান configuration অনুযায়ী এই plan-এর জন্য tag-টি খুব বড়। ছোট quantisation বেছে নিন অথবা OLLAMA_CONTEXT_LENGTH কমান, কারণ KV cache-ও এই requirement-এর মধ্যে গণনা করা হয়।

Port 11434-এ কোনো response পাওয়া যায় না। curl: (7) Failed to connect to localhost port 11434 বোঝায় যে service চলছে না অথবা প্রত্যাশিত জায়গায় listen করছে না। systemctl status ollama এবং journalctl -u ollama -n 50 পড়ুন। আপনি যদি হাতে ollama serve-ও start করে থাকেন, তাহলে দ্বিতীয় copy Error: listen tcp 127.0.0.1:11434: bind: address already in use সহ exit করবে।

Response পাওয়া যায়, কিন্তু খুব ধীর। কোনো পরিবর্তন করার আগে ollama ps পরীক্ষা করুন। GPU-যুক্ত machine-এ PROCESSOR column-এ CPU share দেখা গেলে বুঝতে হবে model-এর একটি অংশ VRAM-এর বাইরে চলে গেছে। তাই context কমান অথবা ছোট quantisation নিন। GPU ছাড়া machine-এ ধীর গতি প্রত্যাশিত, এবং কোনো setting দিয়ে এটি ঠিক করা যায় না।

Task-এর মাঝপথে agent তার instructions ভুলে যায়। Conversation context window অতিক্রম করেছে এবং সবচেয়ে পুরোনো token-গুলো নীরবে বাদ পড়েছে। OLLAMA_CONTEXT_LENGTH বাড়ান। ollama ps দিয়ে নিশ্চিত করুন যে model এখনও fit করছে। আর fit না করলে সমাধান হলো বড় machine ব্যবহার করা, window ছোট করা নয়।

বিকল্পগুলোর তুলনায় এই মডেলের অবস্থান

ছোট কোনো কাজের জন্য 30B MoE host করা বড় ধরনের deployment। কোনো dense 8B model আপনার কাজ ইতিমধ্যে সামলাতে পারলে সেটি চালানো ও load করতে অনেক কম খরচ হবে এবং কয়েক সেকেন্ডেই প্রস্তুত হবে। এই সিদ্ধান্তের সরাসরি তুলনার জন্য VPS-এ 8B ও 27B-তে Qwen 3 দেখুন। কোনো নির্দিষ্ট plan বাস্তবে কোন কোন model ধারণ করতে পারে, তা বিস্তৃতভাবে জানতে কোন কোন AI model self-host করা যায় থেকে শুরু করুন। একসঙ্গে একটি agent-এর বদলে একাধিক agent serve করার পরিকল্পনা থাকলে আগে vLLM-এর সঙ্গে Ollama-এর তুলনা পড়ুন। কারণ production inference server-এর মতো Ollama concurrent request batch করে না। এই সীমাবদ্ধতার কারণেই 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 অনুযায়ী latest, 30b ও 30b-a3b tag যে একই digest নির্দেশ করে, এটিও সেই একই digest নির্দেশ করে। latest pull না করে tag-টির নাম স্পষ্টভাবে উল্লেখ করুন। এতে ভবিষ্যতে ওই pointer republish হলেও আপনি না জানা পর্যন্ত আপনার agent-এর আচরণ পরিবর্তিত হবে না। mlx tag-গুলো Apple silicon build, তাই Linux-এ এগুলো আপনার কাজে আসবে না।

Nemotron 3.5 Lightning-এর কত RAM প্রয়োজন?

Ollama build-গুলোর জন্য NVIDIA কোনো minimum memory figure প্রকাশ করে না। তাই অনুমান না করে মেপে দেখুন। Tag pull করুন, model একবার চালান, এবং load থাকা অবস্থায় ollama ps পড়ুন। এটি বাস্তবে কত memory দখল করেছে এবং GPU না CPU-তে model load হয়েছে, তা দেখায়। Default tag-এর download size 25 GB হলেও এটি কেবল ন্যূনতম হিসাব। এর সঙ্গে KV cache যোগ হয় এবং আপনি যে context window সেট করেন, তার সঙ্গে এটি বাড়ে। Plan-এর memory কম হলে Ollama model requires more system memory দিয়ে ব্যর্থ হবে এবং উভয় সংখ্যা দেখাবে।

GPU ছাড়া VPS-এ Nemotron 3.5 Lightning চালানো যাবে?

হ্যাঁ, যদি plan-এ weights ধরে রাখার মতো RAM থাকে। MoE design-ও সহায়তা করে, কারণ প্রতি token-এর জন্য 30 billion parameter-এর মধ্যে প্রায় 3টি গণনা করা হয়। তবে গতি সীমাবদ্ধতা তৈরি করবে। GPU না থাকলে model memory bandwidth দ্বারা সীমাবদ্ধ থাকে, তাই vCPU বাড়ালেও ফলাফলে সামান্যই পরিবর্তন হয়। নির্দিষ্ট prompt ব্যবহার করে ollama run --verbose চালান, eval rate line পড়ুন, এবং আপনার agent-এর deadline-এর সঙ্গে ওই সংখ্যাটি তুলনা করুন। রাতভর batch job-এর জন্য এটি প্রায়ই যথেষ্ট। কোনো ব্যক্তি ফলাফলের জন্য অপেক্ষা করলে সাধারণত এটি যথেষ্ট নয়।

Ollama আমাকে সম্পূর্ণ 1M context window দেয় না কেন?

1M হলো model-এর maximum, Ollama-র default নয়। Ollama অনেক ছোট একটি window প্রয়োগ করে। Conversation ওই সীমা ছাড়িয়ে গেলে এটি কোনো error না দেখিয়ে সবচেয়ে পুরোনো token বাদ দেয়। ফলে agent নিজের instruction ভুলে যাচ্ছে বলে মনে হয়। systemd service-এ OLLAMA_CONTEXT_LENGTH সেট করুন, অথবা প্রতি request-এ num_ctx পাঠান। ধাপে ধাপে মান বাড়ান এবং প্রতিবার ollama ps আবার পরীক্ষা করুন। কারণ KV cache-এর memory ব্যবহার window-এর সঙ্গে বাড়ে এবং এতে model layer GPU থেকে সরিয়ে দিতে হতে পারে।

Nemotron 3.5 Lightning বাণিজ্যিকভাবে বিনামূল্যে ব্যবহার করা যায়?

NVIDIA-র model card অনুযায়ী model-টি OpenMDW-1.1 license-এর অধীনে এবং commercial use-এর জন্য প্রস্তুত। আপনি নিজে download ও run করা weights-এর ক্ষেত্রে এটি প্রযোজ্য। আপনার stack-এর অন্যান্য software সম্পর্কে এতে কিছু বলা নেই। তাই agent harness এবং এর সঙ্গে সংযুক্ত যেকোনো tool-এর license আলাদাভাবে পরীক্ষা করুন। কোনো contractual কাজে এর ওপর নির্ভর করার আগে বর্তমান model card পড়ুন।