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

Nemotron 3.5 Lightning کس کام کے لیے ہے

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

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

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

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

Ollama library ایک ہی weights کے کئی 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 کا size 35 GB اور bf16 کا size 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 میں موجود رہنا ہوتا ہے۔ اگر graphics card انہیں رکھ سکتا ہو تو وہ GPU memory میں رہتے ہیں، ورنہ system RAM میں۔ اس کے علاوہ KV cache بھی شامل ہوتی ہے۔ 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 درکار ہونے سے پہلے خالی جگہ چیک کریں۔ اگر اس filesystem میں جگہ کم ہو تو pull سے پہلے Ollama اپنے models کہاں محفوظ کرتا ہے اور انہیں منتقل کرنے کا طریقہ پڑھ لینا بہتر ہے، بجائے اس کے کہ disk بھرنے کے بعد یہ کام کیا جائے۔

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"

جب model ابھی loaded ہو، تو دوسرے 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 share آپ کی 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 سسٹم RAM سے پڑھتا ہے۔ یہاں MoE مدد کرتا ہے، کیونکہ ہر token پر 30 billion parameters میں سے صرف تقریباً 3 billion parameters استعمال ہوتے ہیں۔ اس لیے ہر token کے لیے درکار arithmetic، dense 30B model کے مقابلے میں بہت کم ہوتا ہے۔ Memory کے معاملے میں کوئی فائدہ نہیں ہوتا۔ تمام 30 billion parameters کو memory میں موجود رہنا چاہیے، کیونکہ router کسی بھی token کے لیے کوئی بھی expert منتخب کر سکتا ہے۔

اس لیے اس model پر CPU-only inference، core count کے بجائے memory bandwidth سے محدود ہوتا ہے۔ جس plan میں پہلے ہی مناسب تعداد میں vCPUs ہوں، اس میں مزید vCPUs شامل کرنے سے بہت کم فرق پڑتا ہے۔ آپ کو اتنی RAM درکار ہے کہ weights اور آپ کا KV cache اس میں سما سکیں، اور 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 زیادہ تر اسی پر منحصر ہوتا ہے۔ اسے متوقع reply کی length سے ضرب دیں۔ اگر نتیجہ آپ کے قابلِ انتظار وقت سے زیادہ ہو تو num_predict کے ذریعے output محدود کرنا وہ واحد اختیار ہے جو hardware تبدیل کیے بغیر ایک 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 اعداد و شمار ہیں۔ انہیں Artificial Analysis کی launch کے وقت رپورٹ کردہ ہر task کے minutes سے تبدیل کیا گیا ہے، اور ان کی پیمائش VPS کے بجائے hosted GPU endpoints پر کی گئی تھی۔ Nemotron 3.5 Lightning نے فی task اوسطاً تقریباً 30 seconds لیے۔ ان میں gpt-oss-120b کو تقریباً 204 اور Qwen3.6 35B کو تقریباً 210 لگے۔ انہیں فرق کی عمومی صورت سمجھنے کے لیے استعمال کریں، اپنے hardware کی ضمانت کے طور پر نہیں۔

درست رہنمائی اس بات پر منحصر ہے کہ انتظار کون کر رہا ہے۔ اگر کوئی شخص agent کے جواب کا انتظار کر رہا ہے، یا agent مسلسل طویل call chains چلا رہا ہے، تو GPU capacity کرائے پر لیں۔ اگر یہ رات کے وقت schedule کے مطابق چلتا ہے اور کوئی اسے دیکھ نہیں رہا، تو بڑی RAM والا CPU plan مناسب انتخاب ہے۔ دونوں صورتوں میں setup ایک جیسا رہتا ہے، اور VPS پر Ollama چلانا plan sizing اور اس تقابل کی وضاحت کرتا ہے کہ GPU instance استعمال کرنا API provider کو فی token ادائیگی کے مقابلے میں کیسے مختلف ہے۔ Break-even کا تعلق utilisation سے ہے: GPU instance موجود رہنے کے ہر گھنٹے کا bill لیتا ہے، جبکہ API tokens کا bill صرف استعمال کے وقت آتا ہے۔ اس لیے جو agent دن کے بیشتر حصے میں مصروف رہتا ہو، اس کے لیے اپنا server بہتر رہتا ہے؛ لیکن جو agent ایک گھنٹے میں صرف دو بار چلتا ہو، عموماً ایسا نہیں ہوتا۔

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

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

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

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

ollama launch claude --model nemotron-3.5-lightning

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

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

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

Agent کے unattended چلنے کے بعد server کی 2 settings اہم ہوتی ہیں۔ OLLAMA_KEEP_ALIVE یہ کنٹرول کرتا ہے کہ آخری request کے بعد model کتنی دیر memory میں موجود رہے گا۔ default اسے 5 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 سے reachable بناتا ہے۔ اس میں کسی بھی قسم کی 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 کے ساتھ exit ہو جاتی ہے۔

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

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

متبادل اختیارات کے مقابلے میں اس ماڈل کی پوزیشن

چھوٹے کام کے لیے 30B MoE کو host کرنا ایک بڑا انتظامی بوجھ ہے۔ اگر dense 8B ماڈل پہلے ہی آپ کا کام سنبھال لیتا ہے تو اسے چلانے اور load کرنے کی لاگت بہت کم ہوگی، اور یہ چند سیکنڈ میں load ہو جائے گا۔ اس فیصلے کے براہِ راست تقابل کے لیے VPS پر Qwen 3 کے 8B اور 27B ماڈلز دیکھیں۔ کسی مخصوص plan میں عملی طور پر کون سے ماڈلز آ سکتے ہیں، اس کے وسیع جائزے کے لیے آپ کون سے AI ماڈلز self-host کر سکتے ہیں سے شروع کریں۔ اگر آپ ایک agent کے بجائے بیک وقت کئی agents کو serve کرنا چاہتے ہیں تو پہلے Ollama کا vLLM سے تقابل پڑھیں، کیونکہ Ollama concurrent requests کو اس طرح batch نہیں کرتا جیسے production inference server کرتا ہے، اور یہی وہ مقام ہے جہاں 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 تک یہی 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 پر load ہوا ہے یا CPU پر۔ Default tag کا download size 25 GB ہے، لیکن یہ صرف کم از کم مقدار ہے، کیونکہ KV cache اس کے علاوہ شامل ہوتا ہے اور آپ کے مقرر کردہ context window کے ساتھ بڑھتا ہے۔ اگر plan بہت چھوٹا ہو تو Ollama model requires more system memory کے ساتھ انکار کرتا ہے اور دونوں numbers بتاتا ہے۔

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

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

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

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