VPS-এ Nemotron 3.5 Lightning চালানোর নিয়ম

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

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

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

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

Artificial Analysis August 2026-এ প্রকাশিত launch measurement-এ প্রতি second-এ প্রায় 670 output token দেখিয়েছে। এই 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-এর আকার 35 GB এবং bf16-এর আকার 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 কোথাও resident থাকতে হবে। GPU card সেগুলো ধারণ করতে পারলে GPU memory-তে থাকবে, না হলে system RAM-এ থাকবে। এর সঙ্গে KV cache (key/value cache, অর্থাৎ model প্রতিটি token-এর জন্য conversation-এর যে 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

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

df -h /usr/share/ollama

কোনো pull মাঝপথে থেমে no space left on device দেখালে তার অর্থ ঠিক সেটিই। আংশিক blob-গুলো আপনি মুছে না দেওয়া পর্যন্ত disk-এ থেকে যায়। এরপর pull হওয়া বিষয়বস্তু যাচাই করুন:

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 দ্বারা গণনা করা হচ্ছে। 65%/35% CPU/GPU-এর মতো বিভাজনের অর্থ, সব layer memory-তে fit করেনি; CPU share আপনার speed নির্ধারণ করে। প্রয়োজনীয়তা অনুমান করবেন না। এটি 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 parameter-এর মধ্যে প্রায় 3 billion parameter-ই ব্যবহৃত হয়। ফলে প্রতি token-এ প্রয়োজনীয় গণনা একটি dense 30B model-এর তুলনায় অনেক কম। 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 এতে চালানোর সিদ্ধান্ত নেওয়ার আগে স্থানীয় LLM-এর প্রতি সেকেন্ডে token মাপার পদ্ধতি ব্যবহার করে গতি মেপে নিন:

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 মূলত এর ওপর নির্ভর করে। প্রত্যাশিত reply-এর দৈর্ঘ্য দিয়ে এটিকে গুণ করুন। ফলাফল আপনার অপেক্ষার ইচ্ছুক সময়ের চেয়ে বেশি হলে, num_predict দিয়ে output সীমাবদ্ধ করা হলো hardware পরিবর্তন না করে একটি single call-এর সময়সীমা নিয়ন্ত্রণের একমাত্র কার্যকর উপায়।

[
  {
    "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-এর সময় যে per-task minute report করেছিল, সেগুলো থেকে এগুলো রূপান্তর করা হয়েছে। পরিমাপটি VPS-এ নয়, hosted GPU endpoint-এ করা হয়েছিল। Nemotron 3.5 Lightning প্রতি task-এ গড়ে প্রায় 30 seconds নিয়েছিল। এর মধ্যে gpt-oss-120b-এর জন্য প্রায় 204 এবং Qwen3.6 35B-এর জন্য প্রায় 210 লেগেছিল। এগুলো hardware-এর নিশ্চয়তা হিসেবে নয়, পার্থক্যের সামগ্রিক মাত্রা বোঝার জন্য ব্যবহার করুন।

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

1M context window বিনামূল্যে নয়

1M tokens হলো model-এর সর্বোচ্চ সীমা, এবং Ollama এটি ডিফল্টভাবে বরাদ্দ করে না। Ollama অনেক ছোট একটি default window ব্যবহার করে এবং conversation এই সীমা অতিক্রম করলে সবচেয়ে পুরোনো tokens বাদ দেয়। এটি ঘটলে কোনো log লেখা হয় না। তাই agent-এর কাছে মনে হয়, model নিজের কাজের শুরুর অংশ ভুলে গেছে।

ইচ্ছাকৃতভাবে 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
}'

window বাড়ালে memory usage বাড়ে, কারণ অনুমোদিত tokens-এর সংখ্যা বাড়ার সঙ্গে KV cache-ও বড় হয়। মান বাড়ান, restart করুন, তারপর আবার ollama ps চালিয়ে reported size বাড়ছে কি না দেখুন। পরিবর্তনের পরে PROCESSOR column যদি 100% GPU থেকে split অবস্থায় পরিবর্তিত হয়, তাহলে KV cache model layers-কে 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-এর 2টি setting গুরুত্বপূর্ণ। OLLAMA_KEEP_ALIVE শেষ request-এর পর model কতক্ষণ memory-তে থাকবে তা নিয়ন্ত্রণ করে। Default setting পাঁচ মিনিট পর 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-এর আড়ালে খুলুন।

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

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

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 চলছে না, অথবা প্রত্যাশিত জায়গায় listening করছে না। 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 তার instruction ভুলে যায়। Conversation context window অতিক্রম করেছিল এবং সবচেয়ে পুরোনো token-গুলো নীরবে বাদ পড়েছে। OLLAMA_CONTEXT_LENGTH বাড়ান। ollama ps দিয়ে নিশ্চিত করুন যে model এখনও fit করে। যদি আর fit না করে, তাহলে সমাধান হলো বড় machine ব্যবহার করা, window ছোট করা নয়।

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

ছোট কাজের জন্য 30B MoE host করা বড় ধরনের ব্যবস্থা। কোনো dense 8B model যদি আপনার কাজ ইতিমধ্যে সামলাতে পারে, তাহলে সেটি চালাতে খরচ অনেক কম হবে এবং কয়েক সেকেন্ডের মধ্যে load হবে। এই সিদ্ধান্তের সরাসরি তুলনার জন্য VPS-এ 8B এবং 27B-তে Qwen 3 দেখুন। কোনো নির্দিষ্ট plan বাস্তবে কোন কোন model ধারণ করতে পারে, সে বিষয়ে বিস্তৃত পর্যালোচনার জন্য কোন কোন AI model আপনি self-host করতে পারেন থেকে শুরু করুন। একটির বদলে একই সময়ে একাধিক agent serve করার পরিকল্পনা থাকলে আগে vLLM-এর সঙ্গে Ollama-এর তুলনা পড়ুন। কারণ production inference server যেভাবে concurrent request batch করে, Ollama সেভাবে করে না। এখানেই 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 maximum context রয়েছে, এবং August 2026 অনুযায়ী latest, 30b ও 30b-a3b tag-ও একই 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 একবার চালান, এবং loaded থাকা অবস্থায় ollama ps-এর output দেখুন। এটি বাস্তবে কত memory দখল করেছে এবং GPU নাকি CPU-তে চলছে, তা দেখায়। Default tag-এর download size 25 GB হলেও এটি কেবল minimum baseline। এর সঙ্গে KV cache যোগ হয় এবং আপনি যে context window নির্ধারণ করেন, তার সঙ্গে এটি বাড়ে। Plan-এর RAM কম হলে 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-এর নির্ধারিত সময়সীমার সঙ্গে তুলনা করুন। রাতভর batch job-এর জন্য এটি প্রায়ই যথেষ্ট। কিন্তু কোনো ব্যক্তি ফলাফলের জন্য অপেক্ষা করলে সাধারণত এটি উপযুক্ত নয়।

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

1M হলো model-এর maximum, Ollama-এর default নয়। Ollama অনেক ছোট window ব্যবহার করে। কোনো conversation এই সীমা ছাড়িয়ে গেলে এটি error না দেখিয়ে পুরোনো token বাদ দেয়। ফলে মনে হয় agent নিজের instructions ভুলে গেছে। 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 করে চালানো weights-এর ক্ষেত্রে এটি প্রযোজ্য। আপনার stack-এর অন্য software-এর ক্ষেত্রে এটি প্রযোজ্য নয়। তাই agent harness এবং এর সঙ্গে সংযুক্ত যেকোনো tool-এর license আলাদাভাবে পরীক্ষা করুন। কোনো contractual কাজে নির্ভর করার আগে বর্তমান model card পড়ুন।