اوپن سورس LLMs: آپ کا لیپ ٹاپ، آپ کا سرور/کلسٹر اور کلاؤڈ
ایک ماڈل خاندان، اسے چلانے کے تین طریقے۔ اپنے لیپ ٹاپ پر Ollama کے ساتھ۔ vLLM والی طاقتور مشین پر، جو بیک وقت 50 افراد کو جواب دیتی ہے۔ یا OpenRouter کے ذریعے کلاؤڈ میں، جہاں سب سے بڑے اوپن ماڈلز دستیاب ہیں۔ وہی ٹولز، وہی خیال، تین پیمانے۔

آپ پہلے AI استعمال کر چکے ہیں۔ آپ نے ایک خانے میں لکھا اور اس نے جواب دیا۔ وہ AI آپ کے کمپیوٹر پر نہیں بلکہ کسی کمپنی کی دور موجود بڑی مشینوں پر چلتا تھا۔ آپ اس کے وقت کا ایک چھوٹا حصہ کرائے پر لے رہے تھے۔
یہ کورس آپ کو دستیاب انتخاب کی پوری حد سکھاتا ہے۔ اوپن سورس ماڈلز نے صورت بدل دی: ماڈل کے weights مفت ڈاؤن لوڈ کیے جا سکتے ہیں اور کوئی بھی انہیں چلا سکتا ہے۔ لیکن "کوئی بھی چلا سکتا ہے" ایک اصل سوال چھپاتا ہے: انہیں کہاں چلائیں؟ اپنے لیپ ٹاپ پر؟ طاقتور گرافکس کارڈ والی کرائے کی مشین پر؟ یا کسی اور کے کلسٹر پر، کیونکہ ماڈل اتنا بڑا ہے کہ آپ کے ممکنہ ہارڈویئر میں سما نہیں سکتا؟
یہی اس کورس کے تین درجے ہیں اور ہر درجے کا اپنا حصہ ہے:
| حصہ | درجہ | سروس پرت | پیمانہ | آپ کیا کریں گے |
|---|---|---|---|---|
| 1 | مقامی | Ollama | ایک شخص, ایک لیپ ٹاپ | اپنے کمپیوٹر پر ماڈل run کر کے کوڈنگ ایجنٹ کو اس سے جوڑیں گے |
| 2 | Server/Cluster | vLLM | کئی صارفین, ایک مشین یا آپ کا کلسٹر | اسی Qwen3 8B کو 50 concurrent درخواستوں پر serve کر کے تبدیلی measure کریں گے |
| 3 | کلاؤڈ | OpenRouter (gateway) | فرنٹیئر ماڈلز جنہیں تقریباً کوئی host نہیں کر سکتا | انہیں کوڈنگ ایجنٹس سے Kimi K3 اور DeepSeek V4 Pro چلائیں گے |
تین درجے, تین پتے, تین بلز۔ لیپ ٹاپ: http://localhost:11434 پر Ollama, کوئی لاگت نہیں۔ سرور: http://localhost:8000 پر vLLM, GPU کرایہ کی لاگت; provider کے مطابق 24 GB card کے لیے تقریباً $0.50 سے $2 فی گھنٹہ۔ کلاؤڈ: https://openrouter.ai/api پر OpenRouter, ٹوکن کے حساب سے لاگت; یہ صفحہ لکھتے وقت فی million input ٹوکنز تقریباً $0.44 (DeepSeek V4 Pro) سے فی million output ٹوکنز $15 (Kimi K3) تک۔ نیچے آپ سیکھیں گے کہ ہر پتہ کب درست انتخاب ہے۔ قیمتیں اور کرائے بدلتے ہیں, اس لیے بجٹ بنانے سے پہلے live check کریں۔
پورے کورس کے لیے ایک تصویر کام کرتی ہے۔ ہر AI ٹول کے دو حصے ہوتے ہیں۔ ایک حصہ آپ کی مشین پر رہتا ہے اور عملی کام کرتا ہے: ہارنس۔ دوسرا حصہ سوچنے والا برین ہے: ماڈل۔ ہارنس ایک پتہ پر برین تک پہنچتا ہے۔ حصہ 1 میں پتہ آپ کا لیپ ٹاپ ہے۔ حصہ 2 میں وہ حقیقی گرافکس کارڈ والی آپ کے control کی مشین ہے۔ حصہ 3 میں وہ trillions of parameters والے ماڈلز کے آگے کھڑی کلاؤڈ service ہے۔ ہارنس کبھی نہیں بدلتا۔ صرف پتہ بدلتا ہے۔ اسے ایک بار سمجھیں اور تینوں درجے ایک ہی move بن جاتے ہیں۔

یہ General Agents میں آپ کا پہلا stop ہے, جہاں آپ وہ AI چنتے ہیں جسے باقی کتاب میں چلائیں گے۔ آپ برین کو own کرنے سے شروع کرتے ہیں, کیونکہ اس سے section کا اہم خیال پہلے دن سے حقیقی بنتا ہے: agent ایک ہارنس اور بدل سکنے والے برین کا میل ہے۔ اس کے بعد agent کو اچھی طرح چلانا (Agentic Coding), لکھی ہوئی spec سے اسے direction دینا (Spec-Driven Development) اور اسے آپ کے بغیر run ہونے والا loop دینا (Loop Engineering) سیکھیں گے۔
اب سیدھی زبان میں honest promise اور honest limit۔ حصہ 1 کسی بھی مشین پر حقیقی, مفت اور private ہے, حالانکہ عام لیپ ٹاپ پر بھاری coding کام بہت آہستہ چلتا ہے۔ یہ slowness کورس کا bug نہیں ہے۔ اسے دیکھنا اور وجہ سمجھنا حصہ 1 کی اہم lesson ہے۔ حصہ 2 کے لیے NVIDIA گرافکس کارڈ والی مشین چاہیے, جسے زیادہ تر طلبہ کچھ ڈالر میں گھنٹہ کے حساب سے rent کرتے ہیں۔ حصہ 3 کے لیے کچھ ڈالر credit والا OpenRouter اکاؤنٹ چاہیے۔ ہر حصہ الگ ہے۔ آج حصہ 1 کریں اور تیار ہونے پر باقی حصے کے لیے لوٹیں۔
- حصہ 1, مقامی ماڈل سے chat: صرف مفت Ollama install۔ کوئی بھی کر سکتا ہے۔
- حصہ 1 کا coding half اور حصے 2 و 3: پہلے سے installed کوڈنگ ایجنٹ (Claude Code یا OpenCode)۔ ابھی نہیں ہے? Agentic Coding crash کورس اسے setup کراتا ہے۔ وہ کورس اس کے پہلے یا بعد میں کر سکتے ہیں۔
- صرف حصہ 2: NVIDIA GPU والی Linux مشین تک access: standard build کے لیے تقریباً 24 GB GPU memory یا compatible ہارڈویئر پر compressed build کے لیے تقریباً 16 GB (حصہ 2 دونوں paths دکھاتا ہے)۔ کلاؤڈ GPU provider سے ایک دو گھنٹے کے لیے rent کرنا عام اور سستا ہے۔
- صرف حصہ 3: مفت OpenRouter اکاؤنٹ اور کچھ ڈالر credit۔
پہلے مرحلہ سے اپنے کمپیوٹر پر ساتھ چل سکتے ہیں۔ اس صفحہ کے کمانڈز Bash میں ہیں, جو macOS, Linux اور WSL کے ذریعے ونڈوز پر کام کرتے ہیں۔ PowerShell use کرنے پر ہر ٹول کے live docs میں matching form دیکھیں۔ Coding-agent والے ہر مرحلہ میں چھوٹے throwaway git folder کے اندر کام کریں, تاکہ agent آپ کی کسی اہم چیز کو touch نہ کر سکے۔ صرف پڑھی تین limits کے مقابلے میں خود ملی ایک limit زیادہ سکھاتی ہے۔
آسان زبان میں key words
اسے ابھی ایک بار پڑھیں۔ کوئی word unclear لگے, تو واپس آئیں۔ نیچے ہر تصور انہیں سیاق میں پھر سکھاتا ہے, اس لیے یہاں یاد کرنے کی ضرورت نہیں۔
| Term | آسان مطلب |
|---|---|
| ماڈل / برین | اصل سوچ کرنے والا AI۔ آپ words بھیجتے ہیں اور وہ words لوٹاتا ہے۔ |
| Ollama | مفت پروگرام جو AI ماڈل download کر کے آپ کے کمپیوٹر پر run کرتا ہے۔ ایک شخص کے لیے بنا ہے۔ |
| vLLM | مفت پروگرام جو AI ماڈل کو کئی صارفین کے لیے ایک ساتھ serve کرتا ہے۔ Shared مشین کے لیے بنا ہے۔ |
| سروس پرت | ماڈل load کر کے درخواستوں کا جواب دینے والا سافٹ ویئر۔ Ollama اور vLLM دونوں سروس پرتیں ہیں۔ |
| OpenRouter | کلاؤڈ gateway جو سیکڑوں ماڈلز کو ایک پتہ کے پیچھے رکھتا ہے۔ پیچھے کے hosts سروس پرتیں چلاتے ہیں۔ |
| ہارنس / ٹول | برین کے چاروں طرف پروگرام۔ وہ آپ کی فائلیں پڑھتا, کمانڈز run کرتا اور changes دکھاتا ہے۔ Claude Code ایک ہارنس ہے۔ |
| کوڈنگ ایجنٹ | ہارنس جو آپ کے لیے code لکھتا اور edit کرتا ہے: Claude Code یا OpenCode۔ |
localhost | ایسا پتہ جس کا مطلب "یہی کمپیوٹر" ہے۔ آپ کی مشین خود سے بات کرتی ہے, اس لیے internet کی ضرورت نہیں۔ |
| پتہ / base URL | ٹول اپنا کام جہاں بھیجتا ہے۔ اسے localhost پر point کریں اور کام آپ کی مشین پر رہتا ہے۔ |
| ٹول کال | چھوٹا exact message جس سے ماڈل کہتا ہے "اس فائل کو edit کریں" یا "یہ کمانڈ run کریں"۔ یہ ڈیٹا ہے, sentence نہیں۔ |
| ٹوکن | ماڈل کے پڑھنے اور billing کی اکائی: word کا ایک حصہ, English کے تقریباً تین سے چار letters۔ |
| سیاق کھڑکی | ماڈل ایک بار میں کتنے ٹوکنز رکھ سکتا ہے۔ بہت چھوٹا ہو, تو کام کا آغاز بھول جاتا ہے۔ |
num_ctx | سیاق کھڑکی کے لیے Ollama کی سیٹنگ۔ Default آپ کی مشین پر منحصر ہے اور کوڈنگ ایجنٹس کے لیے اکثر بہت چھوٹا ہوتا ہے۔ |
| دو رکاوٹیں | مقامی coding setup کو دو چیزیں پار کرنی ہیں: کافی مضبوط ماڈل اور کافی تیز ہارڈویئر۔ |
| Concurrency | ایک وقت پر آنے والی درخواستیں کی تعداد۔ ایک صارف کی concurrency 1 ہے۔ کلاس کی concurrency 50 ہے۔ |
| تھروپٹ | فی second کل useful کام, یہاں تمام صارفین کے مجموعی ٹوکنز per second میں measured۔ |
| مسلسل بیچنگ | vLLM کی تکنیک: کئی درخواستوں کو GPU میں ساتھ بھیجنا اور درمیان میں نئی درخواستوں کو خالی slots میں ڈالنا۔ |
| اوپن ویٹ ماڈل | ایسا ماڈل جس کے trained weights download کئے جا سکتے ہیں۔ Formal مطلب میں ہمیشہ "اوپن سورس" نہیں: training ڈیٹا اور کچھ terms بند رہ سکتے ہیں۔ |
| فرنٹیئر open ماڈل | Charts کے top پر اوپن ویٹ ماڈل, جو اتنا بڑا ہے کہ صرف کلسٹرز اسے serve کر سکتے ہیں۔ Kimi K3 ایک example ہے۔ |
| API key | Secret string جو ثابت کرتی ہے کہ اکاؤنٹ آپ کا ہے۔ کلاؤڈ درجہ میں billing بھی اسی سے ہوتی ہے۔ |
اس کورس میں دو پرتیں ساتھ چلتی ہیں اور بہت الگ speed سے پرانی ہوتی ہیں۔ پہلی یاد رکھیں۔ دوسری lookup کریں۔
- پائیدار پرت۔ ماڈل تین پیمانے پر رہ سکتا ہے: آپ کی مشین, آپ کے control کی مشین یا کرائے کی کلسٹر۔ ٹول بدل سکنے والے پتے پر اس تک پہنچتا ہے۔ ایک صارف کے لیے بنی سروس پرت load میں queue بناتی ہے, کئی صارفین والی نہیں۔ درست درجہ رازداری, ہارڈویئر اور لاگت پر منحصر کرتا ہے, جنہیں آپ پہلے محسوس اور پھر نام دیں گے۔ نیچے کے ہر کمانڈ کے بدلنے کے بعد بھی یہ سچ رہے گا۔
- مشینی پرت۔ ہر version number, flag, ماڈل name, قیمت اور سیٹنگ۔ Ollama, vLLM, OpenRouter اور coding ٹولز تیزی سے بدلتے ہیں۔ اس لیے ہر کمانڈ کو live docs کا pointer مانیں, یاد رکھنے قابل fact نہیں۔ کورس اور current docs میں disagreement ہو, تو docs درست ہیں۔
یہ کورس کیا cover کرتا ہے
| تصور | حصہ | آپ کیا کریں گے |
|---|---|---|
| 1 | 1 | تقریباً دو منٹ میں اپنے کمپیوٹر پر ماڈل run کر کے اس سے chat کریں گے |
| 2 | 1 | وہ ایک خیال سیکھیں گے جو سب چلاتا ہے: برین صرف ایک پتہ ہے |
| 3 | 1 | ماڈل سے کام کروائیں گے: ایک کمانڈ سے کوڈنگ ایجنٹ کو اس سے جوڑیں گے |
| 4 | 1 | حقیقی coding کام دے کر محسوس کریں گے کہ مقامی برین کہاں ٹکتا یا ٹوٹتا ہے |
| 5 | 1 | دو رکاوٹیں سمجھیں گے: کافی مضبوط ماڈل اور کافی تیز ہارڈویئر |
| 6 | 1 | حقیقی ٹول کال کے اندر دیکھیں گے, جسے weak ماڈل غلط کرتا ہے |
| 7 | 1 | طے کریں گے کہ برین own کرنا کب درست ہے |
| 8 | 2 | دیکھیں گے Ollama one-person کچن کیوں ہے: 50 درخواستیں بھیج کر queue بنتے دیکھیں گے |
| 9 | 2 | اسی Qwen3 8B کو vLLM سے serve کر کے continuous batching کا مطلب سیکھیں گے |
| 10 | 2 | وہی 50 درخواستیں vLLM کو بھیج کر دونوں curves plot اور difference پڑھیں گے |
| 11 | 2 | Claude Code اور OpenCode کو vLLM سرور سے جوڑیں گے, translator کی ضرورت نہیں |
| 12 | 2 | طے کریں گے کہ سرور درجہ کب درست ہے |
| 13 | 3 | فرنٹیئر اوپن ماڈلز جانیں گے جنہیں تقریباً کوئی self-host نہیں کر سکتا: Kimi K3, DeepSeek V4 Pro |
| 14 | 3 | OpenRouter کے ذریعے دونوں کو Claude Code اور OpenCode سے چلائیں گے |
| 15 | 3 | کارکردگی اور قیمت میں چن کر ہر کام کے لیے درست درجہ طے کریں گے |
| 16 | 3 | تینوں درجے کے آگے ایک router رکھ کر درجہ policy کو config میں بدلیں گے |
| A | ضمیمہ | حصہ 2 سرور کو keys, بجٹس اور ایک menu والی shared service میں بدلیں گے |
📚 تدریسی معاونت
پوری presentation دیکھیں: Open Source LLMs: آپ کا لیپ ٹاپ, آپ کا Server/Cluster اور کلاؤڈ
حصہ 1: مقامی درجہ۔ آپ کے لیپ ٹاپ پر ماڈل (Ollama)
اس حصے کی سروس پرت Ollama ہے اور پیمانہ ایک شخص, ایک مشین ہے۔ یہاں سب مفت اور private ہے۔
1. اپنے کمپیوٹر پر برین: یہاں سے شروع کریں
اسے سمجھنے کا سب سے تیز طریقہ ایک بار کرنا ہے۔ اس لیے theory سے پہلے اپنے کمپیوٹر پر ماڈل run کر کے اس سے بات کریں۔ اس حصے کے لیے code لکھنے کی ضرورت نہیں۔ کوئی بھی اسے کر سکتا ہے۔
یہ کرنے والا مفت پروگرام Ollama ہے۔ وہ AI ماڈل download کر کے آپ کے کمپیوٹر پر run کرتا ہے۔ اپنی مشین والا طریقہ چنیں۔
- ایپ (Mac یا ونڈوز)
- Terminal (Linux سہت کوئی کمپیوٹر)
- ollama.com/download پر جائیں اور عام طریقے سے Ollama install کریں۔ اس میں چھوٹی chat ایپ شامل ہے۔
- Ollama ایپ کھولیں۔ وہ Mac کے menu bar یا ونڈوز system tray میں رہتی ہے۔
- اوپر selector سے ماڈل چنیں۔
gemma3:4bجیسے چھوٹے ماڈل سے شروع کریں۔ پہلی بار چننے پر کچھ GB download ہوں گے, جس میں کچھ منٹ لگیں گے۔ - Box میں سوال type کر کے Enter دبائیں۔
بس اتنا ہی۔ جواب آپ کے کمپیوٹر پر run ہو رہے ماڈل سے آیا۔
ٹرمینل کھولکر ایک کمانڈ run کریں۔ وہ پہلی بار ماڈل download کرتی ہے, پھر chat کھول دیتی ہے:
ollama run gemma3:4b
سوال type کر کے Enter دبائیں۔ Chat چھوڑنے کے لیے /bye type کریں۔
یہاں Ollama ابھی نہیں ہے, تو پہلے ollama.com/download سے install کریں اور پھر اوپر والا کمانڈ run کریں۔
کون سا ماڈل چنیں? چھوٹے سے شروع کریں۔ چھوٹا ماڈل تیز جواب دیتا ہے اور عام مشین میں fit ہوتا ہے۔ بعد میں بڑے ماڈلز try کر سکتے ہیں۔
| ماڈل | Approximate download | Comfortable RAM | کس کے لئے اچھا ہے |
|---|---|---|---|
gemma3:1b | 1 GB سے کم | تقریباً 4 GB | چھوٹا اور تیز, لیکن weak جوابات |
llama3.2:3b | تقریباً 2 GB | تقریباً 8 GB | ایک solid, چھوٹی first chat |
gemma3:4b | تقریباً 3 GB | تقریباً 8 GB | مضبوط چھوٹا ماڈل, اچھا default |
qwen3:8b | تقریباً 5 GB | تقریباً 16 GB | بہتر جوابات, زیادہ memory چاہیے |
جدول کا ایک ماڈل اس حصے سے آگے بھی important ہے: qwen3:8b۔ کورس حصہ 1 اور حصہ 2 میں اسے constant رکھتا ہے, تاکہ تبدیلی ہونے پر وجہ واضح ہو۔ مشین میں fit ہوتا ہے, تو ابھی pull کریں۔ نہیں, تو یہاں چھوٹا ماڈل use کریں اور حصہ 2 میں ہارڈویئر rent کریں۔
ماڈلز update ہونے پر اوپر کے exact names اور sizes بدلتے ہیں۔ کسی tag پر منحصر ہونے سے پہلے ollama.com/library پر check کریں۔ Live source check کرنے کی عادت ہی "look it up" پرت کو لاگو کرتی ہے۔
تصور 1 تب done ہے جب: آپ نے سوال پوچھا اور اپنے کمپیوٹر پر run ہو رہے ماڈل نے جواب دیا۔ Wifi off کر کے پھر پوچھیں۔ وہ پھر بھی کام کرتا ہے۔ کچھ بھی کمپیوٹر سے باہر نہیں گیا۔
آخری بات پر کچھ دیر رکنا درست ہے۔ ماڈل آپ کی مشین پر چھوٹے پروگرام کی طرح run ہوتا ہے اور localhost نام والے پتے پر listen کرتا ہے۔ اس کا مطلب "یہی کمپیوٹر" ہے۔ آپ کی مشین خود سے بات کر رہی ہے۔ اس لیے internet off ہونے پر بھی کام چلتا ہے۔
اگر آپ صرف اپنے کمپیوٹر پر private AI چاہتے تھے, تو وہ مل گیا۔ اسے کبھی بھی offline اور مفت run کر سکتے ہیں; type کیا کچھ بھی کمپیوٹر سے باہر نہیں جاتا۔ صرف یہ جاننا بھی مفید ہے۔
باقی کورس اسی مقامی ماڈل سے کام کرواتا ہے: فائلیں پڑھنا, code لکھنا اور آپ کے لیے edit کرنا۔ یہ interesting لگے, تو آگے پڑھیں۔ نہیں, تو بھی win مل چکی ہے۔
2. سب چلانے والا ایک خیال: برین صرف ایک پتہ ہے
آپ نے ابھی اسے کر لیا۔ اب جو ہوا اس کا نام رکھیں, کیونکہ یہ خیال آپ کے ہر AI ٹول اور کورس کے تینوں درجے کے نیچے ہے۔ اسے آہستہ سمجھنا درست ہے۔
آپ کے AI ٹول کے دو حصے ہیں:
- ہارنس: آپ کی مشین کا پروگرام۔ وہ فائلیں پڑھتا, کمانڈز run کرتا اور تبدیلی دکھاتا ہے۔ Claude Code ایک ہارنس ہے۔ Ollama chat ایپ اس سے سادہ ہارنس ہے۔
- برین: وہ ماڈل جو سب پڑھ کر طے کرتا ہے کہ کیا کہنا یا کرنا ہے۔
ہارنس اسی طرح پتہ سے برین تک پہنچتا ہے جیسے browser website تک پہنچتا ہے۔ اسے phone number سمجھیں۔ ہارنس number dial کرتا ہے اور دوسری طرف جواب دینے والا سوچتا ہے۔
عام طور پر یہ number دور کمپنی کی مشینیں کی طرف جاتا ہے۔ لیکن یہ صرف سیٹنگ ہے۔ Number بدلیں اور وہی ہارنس اب دوسرے برین سے بات کرتا ہے۔ تصور 1 میں نیا number localhost تھا: آپ کی اپنی مشین۔ اس لیے جواب دینے والا برین آپ کے لیپ ٹاپ والا تھا۔
کھانا پہنچانے والی ایپ کا تصور کریں۔ فون کی ایپ ہر دن وہی رہتی ہے۔ ریستوراں کا پتہ بدلیں تو وہی ایپ دوسری کچن سے آرڈر کرتی ہے۔ آپ کا AI ٹول ایپ ہے، پتہ فون نمبر ہے، اور اس پتے والی کچن میں ماڈل جواب بناتا ہے۔
یہ حصہ آسانی سے غلط سمجھا جاتا ہے اور آگے important ہوگا۔ مقامی برین پہلے والے برین کی چھوٹی copy نہیں ہے۔ وہ الگ برین ہے اور بہت weak ہو سکتا ہے۔ App وہی, کچن دوسری, جہاں cook کم skilled ہو سکتا ہے۔ اسے یاد رکھیں۔ یہ براہ راست تصور 5 تک جاتا ہے۔
کچن والی تصویر یاد رکھیں, کیونکہ کورس تین کچنز جاتا ہے۔ حصہ 1 آپ کے گھر کی کچن ہے۔ حصہ 2 آپ کی چلائی industrial کچن ہے, جو پورے ریستوراں کو serve کرنے کے لیے بنی ہے۔ حصہ 3 دنیا کے best restaurants سے order کرنا ہے, کیونکہ ان کی کچن کسی گھر میں نہیں آ سکتی۔ App پورے وقت وہی رہتی ہے۔ صرف پتہ بدلتا ہے۔
آپ نے ایک پتہ بدلا اور اپنے کمپیوٹر کے ماڈل نے جواب دیا۔ AI ٹول کا کون سا حصہ بدلا اور کون سا وہی رہا? برین بدلا: اب words آپ کے کمپیوٹر والے ماڈل کو جاتے ہیں۔ ہارنس وہی رہا: ایپ, buttons اور اس سے بات کرنے کا طریقہ۔ آپ نے صرف dial ہونے والا پتہ بدلا۔جواب دیکھیں
3. اس سے کام کروائیں: مقامی برین پر کوڈنگ ایجنٹ
مقامی ماڈل سے chat اچھی آغاز ہے۔ لیکن agent صرف chat نہیں کرتا۔ وہ فائلیں پڑھتا, code لکھتا اور آپ کے لیے کمانڈز run کرتا ہے۔ اس لیے کوڈنگ ایجنٹ کو اسی مقامی برین سے جوڑیں۔
یہ مرحلہ کوڈنگ ایجنٹ کو مقامی ماڈل سے جوڑتا ہے۔ اس لیے Claude Code یا OpenCode پہلے سے installed چاہیے۔ کوئی ایک ہے, تو ready ہیں۔ نہیں, تو پہلے install کریں; Agentic Coding crash کورس پورا process دکھاتا ہے۔ نیچے والا کمانڈ اسے connect اور launch کرتا ہے۔ وہ agent install نہیں کرتا۔
یہ کرنے کے دو طریقے ہیں۔ آسان طریقہ ایک کمانڈ ہے۔ Manual طریقہ نیچے کی wiring دکھاتا ہے, جسے ایک بار دیکھنا مفید ہے۔ Tab چنیں۔
- بس run کریں
- ہاتھ سے setup کریں
یہاں Ollama کے recent versions سیٹنگز edit کئے بغیر کوڈنگ ایجنٹ connect اور launch کر سکتے ہیں۔ ایک کمانڈ:
ollama launch claude
یہ Claude Code کو مقامی ماڈل use کرنے کے لیے setup کر کے start کرتا ہے۔ وہ ماڈل پوچھے گا یا پہلے pull کیا ماڈل name دے سکتے ہیں:
ollama launch claude --model qwen3:8b
دوسرے ٹول کے لیے matching کمانڈ ہے: ollama launch opencode۔
unknown command "launch" دکھےollama launch کے لیے recent Ollama, version 0.15 یا نیا چاہیے۔ Error دکھے, تو Ollama update کریں: ollama.com/download سے installer پھر run کریں یا ایپ سے update کریں۔ Version ollama --version سے check کریں۔
چھوٹی companion skill پورا setup کرتی ہے اور وقت لگانے سے پہلے ہارڈویئر کی سچائی بتاتی ہے۔ Agent اسے پڑھ کر کام کرتا ہے۔ Install کریں, پھر عام words میں کہیں:
npx skills add panaversity/local-llm-agentic-coding --agent claude-code opencode -y
مجھے مقامی ماڈل پر کوڈنگ ایجنٹ چلانے کے لیے setup کریں۔ پہلے ہارڈویئر کو honestly check کریں, پھر مرحلہ by مرحلہ guide کریں اور کسی بڑے action سے پہلے approval کے لیے رکیں۔
انسٹالر نامعلوم name کو خاموشی سے skip کر سکتا ہے, اس لیے پہلے npx skills add panaversity/local-llm-agentic-coding --list سے preview کر سکتے ہیں۔
اوپر والا کمانڈ کچھ سیٹنگز بھرتا ہے۔ اب دیکھیں کہ وہ کیا بھرتا ہے, تاکہ wiring سمجھیں اور کہیں بھی کر سکیں۔ دونوں ٹولز اسی مقامی ماڈل سے تھوڑے الگ طریقے سے بات کرتے ہیں۔
- Claude Code
- OpenCode
یہاں Claude Code مقامی ماڈل سے ایسے بات کرتا ہے جیسے Anthropic سے کر رہا ہو۔ اسے مقامی پتے پر point کریں، placeholder ٹوکن دیں اور یقینی بنائیں کہ حقیقی API key set نہیں ہے:
export ANTHROPIC_BASE_URL=http://localhost:11434 # the local address, bare host, no /v1
export ANTHROPIC_AUTH_TOKEN=ollama # any non-empty word; it is sent as "Bearer ollama"
export ANTHROPIC_API_KEY= # must be empty, or it overrides the line above
claude --model qwen3:8b # use a model tag you have pulled
کچھ چھوٹے notes پریشانی بچاتے ہیں:
- پتہ bare ہے, صرف host اور port۔ Claude Code باقی path خود جوڑتا ہے۔
/v1نہ جوڑیں۔ - حوالہ: Ollama ماڈل کو
--modelسے نام دینا ہوگا, ورنہ Claude Code ایسے ماڈل names تلاش کرے گا جو مقامی مشین میں نہیں ہیں۔ - ونڈوز پر
localhostغلط جگہ point کر سکتا ہے, اس لیے کئی لوگhttp://127.0.0.1:11434use کرتے ہیں۔ یہ official docs کے بجائے صارفین دوارا widely reported ہے۔
ہر session میں سیٹنگز رکھنے کے لیے انہیں ہر بار type کرنے کے بجائے env block میں ~/.claude/settings.json کے اندر رکھیں:
{
"env": {
"ANTHROPIC_BASE_URL": "http://localhost:11434",
"ANTHROPIC_AUTH_TOKEN": "ollama",
"ANTHROPIC_API_KEY": ""
}
}
یہاں OpenCode مقامی ماڈل سے ایسے بات کرتا ہے جیسے OpenAI سے کر رہا ہو۔ وہ مقامی ماڈلز کو باقاعدہ support کرتا ہے۔ تجویز کردہ طریقہ مقامی سرور کو opencode.json فائل میں بیان کرنا ہے۔ اسے ایک بار ہاتھ سے کرنا مفید ہے، کیونکہ پتہ اور ماڈل mapping سامنے دکھتے ہیں۔ آخر میں /v1 دیکھیں۔ یہاں یہ لازمی ہے اور Claude Code کے پتے سے واحد فرق ہے:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama (local)",
"options": { "baseURL": "http://localhost:11434/v1" },
"models": { "qwen3:8b": { "name": "Qwen3 8B (local)" } }
}
},
"model": "ollama/qwen3:8b"
}
اسے project کے opencode.json میں یا سب projects کے لیے ~/.config/opencode/opencode.json میں رکھیں۔ models کے نیچے ماڈل name ایسا tag ہونا چاہیے جسے آپ نے سچ میں pull کیا ہے۔ ونڈوز پر 127.0.0.1 use کریں, localhost نہیں۔
دونوں ٹول tabs پڑھ کر shape دیکھیں۔ وہی ماڈل, وہی مشین, وہی port۔ Claude Code bare پتہ dial کرتا ہے۔ OpenCode اسی پتہ کے آخر میں /v1 لگاتا ہے۔ مقامی ماڈلز کے لیے دونوں میں بس یہی difference ہے۔ یہ contrast سیکھ لیں, پھر کسی ٹول کو کسی مقامی برین سے جوڑ سکتے ہیں۔ حصے 2 اور 3 میں اسے بغیر تبدیلی پھر use کریں گے۔
تصور 3 تب done ہے جب: کوڈنگ ایجنٹ شروع ہو گیا اور اس کا ماڈل آپ کے کمپیوٹر والا ہے۔ اس سے چھوٹا سوال پوچھیں۔ جواب آپ کے لیپ ٹاپ سے آیا, دور کمپنی سے نہیں۔
یہ تصور 2 کو حقیقی بناتا ہے۔ آپ نے پتہ کو localhost کیا اور وہی کوڈنگ ایجنٹ اب کام آپ کے کمپیوٹر کے برین کو بھیجتا ہے۔
4. اب push کریں: حقیقی کام دیں اور دیکھیں
مقامی ماڈل کا سوال جواب کرنا چھوٹا first مرحلہ ہے۔ مقامی ماڈل کا حقیقی coding کام کرنا اصل test ہے۔ اس لیے اسے run کریں۔
تھوڑا حقیقی code والی چھوٹی throwaway git folder میں کام کریں, چاہے صرف ایک script ہو۔ Agent کو مقامی برین پر point کر کے ایسا prompt paste کریں:
اس folder کو دیکھیں۔ ایک چھوٹا safe improvement تلاش کریں, change کریں اور دکھائیں کہ کیا بدلا۔
اب غور سے دیکھیں۔ دو میں سے ایک بات ہوگی اور دونوں lesson ہیں۔
مضبوط مشین پر, یعنی اچھے گرافکس کارڈ اور mid-size ماڈل کے ساتھ, یہ کام کرتا ہے۔ مقامی برین فائلیں پڑھتا, plan بناتا, edit کرتا اور clean change دکھاتا ہے۔ اس پل مفت, offline اور private حقیقی بنتے ہیں۔ یہ آپ کا setup ہے اور کام کر رہا ہے۔
عام لیپ ٹاپ پر, یعنی گرافکس کارڈ کے بغیر چھوٹے ماڈل کے ساتھ, رکاوٹ محسوس ہوتی ہے۔ ہر مرحلہ میں منٹ لگ سکتے ہیں, کیونکہ مشین بہت سارا text آہستہ پڑھتی ہے۔ یا run درمیان میں bad ٹول کال error کے ساتھ رک سکتا ہے۔ برین نے "اس فائل کو edit کریں" کہنا چاہا, لیکن format غلط کر دیا۔
ابھی کچھ fix نہ کریں۔ بس دیکھیں کہ کیا ہوا اور کیسا لگا۔ تیز اور clean? یا آہستہ یا broken? وہی feeling اگلے تصور کا raw material ہے۔
کام آہستہ چلا یا ٹوٹا, تو کچھ غلط نہیں ہوا۔ آپ نے چھوٹی مشین پر بڑا ماڈل run کرنے کی honest limit دیکھی۔ Money یا time لگانے سے پہلے یہ جاننا حقیقی اور useful ہے۔ اگلا تصور وہی feeling سمجھاتا ہے۔
تصور 4 تب done ہے جب: آپ نے مقامی برین سے حقیقی code change مانگا اور result دیکھا, چاہے clean edit, لمبا wait یا broken run ملا۔
5. وہ کیوں ٹکا یا ٹوٹا: دو رکاوٹیں
اب explanation, کیونکہ آپ نے وہ چیز محسوس کر لی جسے یہ سمجھاتا ہے۔ حصہ 1 کا سب سے important خیال واضح زبان میں سمجھیں۔
مقامی کوڈنگ ایجنٹ کو دو الگ رکاوٹیں پار کرنی ہوتی ہیں۔ وہ ایک رکاوٹ نہیں ہیں اور ایک کا fix دوسرے کے لیے کچھ نہیں کرتا۔
پہلی رکاوٹ صلاحیت ہے۔ جب ماڈل act کرتا ہے, اور coding کام میں تقریباً ہر turn پر کرتا ہے, تو اسے valid ٹول کال لکھنی ہوتی ہے۔ یعنی "اس فائل کو edit کریں, اس line کو اس line سے بدلیں" اس exact strict format میں کہنا جسے ہارنس expect کرتا ہے۔ چھوٹے ماڈلز اکثر اسے غلط کرتے ہیں۔ ٹول skip کر دیتے ہیں یا format بگاڑ دیتے ہیں, پھر run رک جاتا ہے۔ ٹول use کے لیے trained مضبوط ماڈل عام طور پر اسے fix کرتا ہے۔ Faster ہارڈویئر نہیں: تیز مشین پر tiny ماڈل پھر بھی broken ٹول کالز لکھتا ہے۔
دوسری رکاوٹ تھروپٹ ہے۔ ہر turn میں ہارنس آپ کے کام کے شروع ہونے سے پہلے ماڈل کو لمبی instruction بھیجتا ہے, جس میں ٹول rules اور وہ جو کر سکتا ہے ان کی definitions ہوتی ہیں۔ مشین کو سب تیزی سے پڑھنا پڑتا ہے۔ Graphics card کے ساتھ ایک moment لگتا ہے۔ اس کے بغیر صرف processor پر ہر turn منٹ لے سکتا ہے۔ Graphics card اسے fix کرتا ہے۔ Smarter ماڈل نہیں: آہستہ مشین پر brilliant ماڈل بھی بہت آہستہ ہے۔
| Wall | کیا چاہیے | کس سے fix ہوتی ہے | کس سے fix نہیں ہوتی |
|---|---|---|---|
| صلاحیت | Act کرتے وقت درست ٹول کال | ٹول use trained مضبوط ماڈل | صرف faster ہارڈویئر |
| تھروپٹ | لمبی instruction کو سیکنڈ میں پڑھنا | Graphics card (GPU) | Smarter, smaller ماڈل |
نیچے کی جدول سے پہلے size پر honest note: reliable ٹول use کے لیے universal parameter-count floor نہیں ہے۔ Tool-use training, chat template اور ہارنس fit raw size جتنے important ہیں۔ اچھی طرح trained چھوٹا ماڈل خراب trained بڑے ماڈل کو ہرا سکتا ہے۔ پھر بھی آج کے common مقامی ماڈلز میں rough pattern ہے کہ بڑے ماڈلز multi-step ٹول use کو زیادہ reliably handle کرتے ہیں۔ اس صفحہ کی جدول وہی pattern بتاتی ہیں۔
سستا مشینیں دونوں رکاوٹیں ایک ساتھ miss کرتی ہیں۔ اس لیے عام لیپ ٹاپ ماڈل سے chat کے لیے ٹھیک ہے, کوڈنگ ایجنٹ run کرنے کے لیے نہیں: wiring درست ہے, لیکن کوئی رکاوٹ clear نہیں ہوئی۔
تصور 2 کی کچن کے اندر zoom کریں۔ Meal دو چیزیں طے کرتی ہیں: cook اور stove۔ Cook ماڈل ہے۔ Stove مشین ہے۔ صلاحیت پوچھتی ہے کہ cook ہر بار درست order بنانے کے لیے skilled ہے یا نہیں۔ تھروپٹ پوچھتی ہے کہ stove منٹ کے بجائے سیکنڈ میں serve کرنے جتنا تیز ہے یا نہیں۔ آہستہ stove پر great cook پھر بھی wait کراتا ہے۔ تیز stove پر clumsy cook dish پھر بھی خراب کرتا ہے۔ دونوں چاہیے۔
ہارڈویئر پر ایک honest sentence یاد رکھیں۔ اس صفحہ کی ہر چیز گرافکس کارڈ والی کرائے کی کلاؤڈ مشین پر وہی ہے: wiring, سیٹنگز, دو رکاوٹیں۔ صرف speed بدلتی ہے۔ تقریباً 16 سے 24 GB memory والا گرافکس کارڈ مقامی setup کو سچ میں usable کوڈنگ ایجنٹ بنا دیتا ہے۔ یہی حصہ 2 کا doorway ہے, جہاں ویسی مشین rent کر کے وہ کریں گے جو لیپ ٹاپ کبھی نہیں کر سکتا۔
کون سا ماڈل کس مشین میں fit ہوتا ہے, اس کی rough guide:
| ماڈل | Size | ضروری memory | Coding کام کے لیے ready? |
|---|---|---|---|
llama3.2:3b | 3B | تقریباً 8 GB | نہیں۔ Chat کے لیے اچھا, ٹول کالز خراب کرتا ہے۔ |
qwen3:8b | 8B | تقریباً 16 GB | Simple کام کے لیے ٹھیک |
phi4:14b | 14B | تقریباً 12 GB | اس lineup میں practical floor کے آسپاس |
qwen3:30b-a3b | 30B mix | تقریباً 20 سے 24 GB | Best balance: مضبوط جوابات, پھر بھی quick |
qwen3:32b | 32B | تقریباً 24 GB | مضبوط, اوپر والے mix سے تھوڑا آہستہ |
کام run ہوا, لیکن ہر turn میں four منٹ لگے۔ اسی لیپ ٹاپ پر بہت smarter ماڈل لگا دیتے ہیں۔ کیا وہ تیز ہوگا? نہیں۔ آہستہ turn تھروپٹ رکاوٹ ہے اور smarter ماڈل اسے نہیں بدلتا۔ Smarter ماڈل بڑا ہونے کی وجہ اور آہستہ بھی ہو سکتا ہے۔ تھروپٹ گرافکس کارڈ سے fix ہوتی ہے, ماڈل انتخاب سے نہیں۔ دونوں رکاوٹیں کو ملانا وہی غلطی ہے جسے یہ تصور روکتا ہے۔جواب دیکھیں
6. اندر دیکھیں: ٹول کال اصل میں کیا ہے
تصور 5 نے کہا weak ماڈل "ٹول کالز خراب کرتا ہے"۔ یہ vague لگتا ہے۔ حقیقی ٹول کال دیکھیں, کیونکہ اسے دیکھ کر پوری بات واضح ہوتی ہے۔
درست ٹول کال عام writing نہیں ہے۔ یہ structured ڈیٹا کا چھوٹا piece, exact instruction ہے جسے ہارنس execute کر سکتا ہے۔ وہ ایسی دکھتی ہے:
{
"type": "tool_use",
"name": "edit_file",
"input": { "path": "README.md", "old": "Hello", "new": "Hello, world" }
}
ہارنس اسے پڑھ کر فائل edit کرتا ہے۔ ماڈل نے change خود نہیں لکھا۔ اس نے precise instruction بھیجی اور ہارنس نے کام کیا۔ "ماڈل ٹولز use کرتا ہے" کا اصل مطلب یہی ہے۔ اسی moment chat ماڈل chat box سے act کرنے والی چیز بنتا ہے۔
اب دیکھیں کہ بہت weak ماڈل کیا کرتا ہے۔ وہ input کو حقیقی object کے بجائے text blob کی طرح بھیجتا ہے اور ہارنس اسے ایسے validation error سے reject کرتا ہے:
invalid tool arguments: expected object, got string
اصل wording ہارنس کے مطابق بدلتی ہے۔ Failure کا shape important ہے: arguments غلط structure میں آئے, اس لیے ہارنس ان پر act کرنے سے منع کرتا ہے۔
یہ رن رک جاتا ہے۔ کچھ edit نہیں ہوتا۔ یہی ایک بگڑا message اکثر تصور 4 والا run ختم کرتا ہے۔ یہ صلاحیت رکاوٹ کو پاس سے دیکھنا ہے۔
ایک اور چیز طے کرتی ہے کہ یہ کام کرے گا یا نہیں: سیاق کھڑکی۔ یہ ماڈل کے ایک بار میں رکھنے والے ٹوکنز کی تعداد ہے; ٹوکن word کا piece اور ماڈلز کی اصل counting unit ہے۔ Ollama میں اسے num_ctx set کرتا ہے۔ ہارنس ہر turn لمبی instruction بھیجتا ہے اور Ollama آپ کی مشین کی graphics memory سے default کھڑکی چنتا ہے۔ زیادہ تر لیپ ٹاپس میں 24 GiB سے کم VRAM ہونے پر default صرف 4,096 ٹوکنز ہے۔ اتنی چھوٹی کھڑکی زیادہ تر instruction کو خاموشی سے کاٹ دیتی ہے۔ Trap یہ ہے: کوئی error نہیں آتا۔ Ollama instruction trim کر کے پھر بھی جواب دیتا ہے۔ Chat ٹھیک لگتا ہے, لیکن coding کام confusing طریقے سے fail ہوتے ہیں, کیونکہ ماڈل نے tool-call format بتانے والا حصہ دیکھا ہی نہیں۔ Truncated کھڑکی اس pattern کا سب سے common cause ہے, پر اکیلا نہیں۔ اس لیے پہلے اسے check کریں, assume نہیں۔
حل کھڑکی بڑی کرنا ہے۔ Agents اور coding ٹولز کے لیے Ollama کی current guidance کم از کم 64,000 ٹوکنز ہے۔ Agent run ہونے پر اس سے بس کہ سکتے ہیں:
سیاق کھڑکی بہت چھوٹی لگ رہی ہے اور ٹول کالز توڑ رہی ہے۔ اسے کم از کم 64,000 پر set کر کے کام پھر try کریں۔
گہرائی سے: چھوٹی کھڑکی بغیر warning چیزیں کیوں توڑتی ہے
سیاق کھڑکی کو 64,000 ٹوکنز یا زیادہ کرنا "میرا مقامی کوڈنگ ایجنٹ broken ہے" کا سب سے common fix ہے۔ اسے کئی طریقوں سے set کر سکتے ہیں: Ollama ایپ سیٹنگز میں slider, سرور کو OLLAMA_CONTEXT_LENGTH=64000 سے شروع کر کے, custom ماڈل فائل (Modelfile میں PARAMETER num_ctx 64000) یا chat session میں /set parameter num_ctx 64000 سے۔ بڑی کھڑکیاں کو زیادہ memory چاہیے اور ollama ps دکھاتا ہے کہ running ماڈل کو حقیقت میں کون سی کھڑکی ملی۔ Setup chat جواب کرتا لیکن حقیقی کام fail کرتا ہے, تو پہلے سیاق کھڑکی check کریں۔
Quick fix list کھولیں
- اصطلاح Chat جواب کرتا ہے, لیکن حقیقی کام کی instructions ignore کرتا ہے۔ سیاق کھڑکی شاید بہت چھوٹی ہے, اس لیے instructions کٹ گئیں۔ دوسرے causes تلاش کرنے سے پہلے
num_ctxکو 64,000 یا زیادہ کر کے retest کریں۔ - ہر turn منٹ لیتا ہے, پھر timeout ہوتا ہے۔ مشین لمبی instruction وقت پر پڑھنے کے لیے آہستہ ہے۔
export API_TIMEOUT_MS=1200000سے timeout بڑھا سکتے ہیں۔ پھر بھی timeout ہو, تو تھروپٹ رکاوٹ سچ بتا رہی ہے۔ - اصطلاح Missing key یا connectors off ہونے کا message۔ Harmless ہے۔ آپ نے placeholder ٹوکن set کیا ہے اور مقامی ماڈل وہ features use نہیں کرتا, اس لیے دکھتا ہے۔
انہیں یاد کرنے کی ضرورت نہیں۔ Agent کسی بھی fix میں guide کر سکتا ہے۔
تصور 6 تب done ہے جب: آپ نے حقیقی ٹول کال کو structured ڈیٹا کی طرح دیکھا اور سمجھتے ہیں کہ بگڑی call یا بہت چھوٹی سیاق کھڑکی مقامی کوڈنگ ایجنٹ کو توڑتی ہے۔
7. برین own کرنا کب درست ہے
اب اسے run کر سکتے ہیں۔ Honest سوال ہے کہ کب کرنا چاہیے۔
کلاؤڈ میں بڑا ماڈل rent کرنا یا کوڈنگ ایجنٹ کو normal طریقے سے use کرنا عام طور پر آسان اور اکثر smarter ہے۔ اس لیے مقامی کچھ specific cases میں جیتتا ہے, جنہیں واضح سمجھنا درست ہے:
- رازداری۔ کام مشین سے باہر نہیں جاتا۔ Sensitive یا regulated کام میں یہی decision طے کر سکتا ہے۔
- اصطلاح Offline۔ نیٹ ورک, اکاؤنٹ یا outage نہیں۔ Disk والا ماڈل plane یا locked-down firewall کے پیچھے بھی کام کرتا ہے۔
- لاگت, جب کام پورا دن چلے۔ کسی service پر single درخواست سستی ہے۔ لیکن پورے مہینہ ہر few منٹ چلنے والا loop الگ بل ہے۔ کام کبھی نہ رکے, تو برین own کرنا کلاؤڈ سے سستا ہو سکتا ہے۔
آخری بات کتاب میں دو بار important ہے۔ Loop Engineering میں ایسے agents بنائیں گے جو پورا دن خود run اور آپ کے سوتے وقت اپنا کام check کرتے ہیں۔ وہیں کس کا برین loop چلاتا ہے اور ہر run کتنا لاگت کرتا ہے, detail نہیں design بن جاتا ہے۔ آپ نے ابھی وہ برین own کرنا سیکھا۔
ایک اور بات دیکھیں, جو اس پورے حصے کی quiet lesson ہے۔ Companion skill use کی, تو ہاتھ سے setup نہیں کیا۔ آپ نے skill install کی اور agent نے use کیا۔ Skill صرف SKILL.md فائل والی folder ہے, وہی shape جو skills crash کورس میں سیکھی۔ یعنی اپنے knowledge کو ویسے package اور کسی agent کے install کرنے کے لیے share کر سکتے ہیں۔ Publish کرنے کے لیے ready ہوں, تو gh skill publish --dry-run ship کرنے سے پہلے Agent Skills spec کے against check کرتا ہے۔
حصہ 1 پورا ہے۔ آپ برین own کرتے ہیں, دو کوڈنگ ایجنٹس کو اس سے جوڑ چکے ہیں اور usability طے کرنے والی دو رکاوٹیں جانتے ہیں۔ لیکن بنائی چیز پر غور دیں: کچن نے ٹھیک ایک customer کو serve کیا۔ آپ کو۔ ایک ساتھ 10 درخواستیں بھیجیں اور وہ line میں wait کرائے گی۔ وہی line اور اسے ہٹانے والا سافٹ ویئر حصہ 2 ہے۔
حصہ 2: سرور/کلسٹر درجہ۔ ایک مشین، کئی صارفین (vLLM)
اس حصے کی سروس پرت vLLM ہے اور پیمانہ ایک طاقتور مشین پر کئی صارفین ہے۔ ماڈل نہیں بدلتا۔ یہی پورا point ہے۔
سب سے پہلے اس حصہ کا نیا word نام دیں: سروس پرت۔ یہ ماڈل کو memory میں load اور درخواستوں کا جواب دینے والا سافٹ ویئر ہے۔ Ollama سروس پرت ہے۔ vLLM سروس پرت ہے۔ اس حصے میں برین constant, Qwen3 8B, رکھتے ہیں اور نیچے کی صرف سروس پرت بدلتے ہیں۔ Practice جتنا ممکن بنائے, باقی سب fixed رکھیں, ایک چیز بدلیں اور measured difference اہم شکل سے اسی کا ہوگا۔ یہ صرف good science نہیں۔ پورے career میں agent systems ایسے debug کریں گے: variable isolate کریں, پھر measure کریں۔ Honest caveat بھی ساتھ ہے: یہ teaching experiment ہے, laboratory نہیں۔ ماڈل precision, runtime code اور configuration کے چھوٹے differences ساتھ آتے ہیں, اس لیے claim expected pattern ہے, defend کرنے والا decimal نہیں۔
یہاں NVIDIA گرافکس کارڈ والی Linux مشین۔ نیچے کے standard full-precision build کے لیے تقریباً 24 GB GPU memory رکھیں یا compressed FP8 build کے ساتھ 16 GB card use کریں; تصور 9 دونوں paths دکھاتا ہے۔ تقریباً کسی کے پاس ایسی مشین نہیں ہوتی اور ٹھیک ہے: کلاؤڈ GPU provider سے ایک دو گھنٹے rent کرنے میں کچھ ڈالر لگتے ہیں اور ہر کمانڈ کرائے کی مشین پر ایک جیسے ہے۔ ابھی rent نہیں کر سکتے, تو بھی حصہ پڑھیں۔ آخر کی دو curves خود draw کرنے سے پہلے بھی سمجھنے قابل ہیں۔
8. ایک شخص کی کچن: Ollama پر 50 درخواستیں بھیج کر دیکھیں
حصہ 1 ایک claim پر ختم ہوا: Ollama setup ایک customer serve کرتا ہے۔ اسے slogan نہیں, measurement سے prove کریں۔
تجربہ یہ ہے۔ چھوٹی script لکھیں گے جو ماڈل سرور پر کئی درخواستیں ایک وقت پر بھیج کر دو numbers report کرتی ہے: پورا batch کتنا وقت لیتا ہے اور سب درخواستوں کا combined total ٹوکنز per second۔ ایک ساتھ آنے والی درخواستیں کی تعداد concurrency ہے۔ ایک صارف کی concurrency 1 ہے۔ ایک ساتھ Enter دباتے 50 طلبہ کی کلاس concurrency 50 ہے۔
یہاں Ollama اور vLLM ایک standard درخواست format, OpenCode config والا OpenAI-compatible format, جواب کرتے ہیں۔ اس لیے ایک script دونوں test کرتی ہے۔ صرف پتہ اور ماڈل name بدلتے ہیں۔ اسے bench.py کی شکل میں save کریں:
# bench.py: fire N concurrent requests at a model server and measure throughput.
# usage: python bench.py <base_url> <model> <concurrency>
import asyncio, sys, time
import httpx
BASE_URL = sys.argv[1] # http://localhost:11434/v1 (Ollama) or http://localhost:8000/v1 (vLLM)
MODEL = sys.argv[2] # qwen3:8b (Ollama) or Qwen/Qwen3-8B (vLLM)
N = int(sys.argv[3]) # how many requests at once
PROMPT = "Explain in about 200 words how a bank reconciliation works."
async def one_request(client):
r = await client.post("/chat/completions", json={
"model": MODEL,
"messages": [{"role": "user", "content": PROMPT}],
"max_tokens": 300,
"temperature": 0,
})
r.raise_for_status()
return r.json()["usage"]["completion_tokens"]
async def main():
async with httpx.AsyncClient(base_url=BASE_URL, timeout=3600) as client:
await one_request(client) # warm-up: load the model before timing anything
start = time.perf_counter()
results = await asyncio.gather(*[one_request(client) for _ in range(N)],
return_exceptions=True)
wall = time.perf_counter() - start
ok = [r for r in results if isinstance(r, int)]
failed = len(results) - len(ok)
total = sum(ok)
print(f"concurrency={N} ok={len(ok)} failed={failed} tokens={total}"
f" time={wall:.1f}s throughput={total/wall:.1f} tok/s")
asyncio.run(main())
ضروری ایک dependency install کریں (pip install httpx), یقینی بنائیں کہ Ollama qwen3:8b pull کر کے run ہو رہا ہے اور run reproducible بنانے کے لیے ایک سیٹنگ pin کریں۔ Ollama کے parallel slots مشین کے مطابق بدلتے ہیں اور fair experiment اپنی سیٹنگز بتاتا ہے۔ Ollama سرور کو OLLAMA_NUM_PARALLEL=4 ollama serve سے restart کریں (PowerShell: $env:OLLAMA_NUM_PARALLEL=4; ollama serve), تاکہ آپ کی اور classmate کی curve ایک ہی rules سے آئے۔ پھر sweep run کریں۔ اسے کرائے کی GPU مشین پر کریں, تاکہ حصہ 2 comparison fair ہو: دونوں سروس پرتیں کے لیے ایک ہی ہارڈویئر۔
python bench.py http://localhost:11434/v1 qwen3:8b 1
python bench.py http://localhost:11434/v1 qwen3:8b 5
python bench.py http://localhost:11434/v1 qwen3:8b 10
python bench.py http://localhost:11434/v1 qwen3:8b 25
python bench.py http://localhost:11434/v1 qwen3:8b 50
ہر concurrency level تین بار run کر کے تینوں تھروپٹ کی median لکھیں, تاکہ one-off hiccup ڈیٹا point نہ بنے۔ تصور 10 کے plot کے لیے وہ پانچ medians چاہیے۔
اب result پڑھیں۔ Concurrency 1 پر ٹھیک تھا۔ بڑھانے پر total تھروپٹ تقریباً نہیں بدلا, لیکن wall-clock time لمبا ہوتا گیا۔ 50 پر batch نے شاید کئی منٹ لئے۔ اندر simple بات ہوئی: Ollama کچھ درخواستیں parallel run کرتا ہے, یعنی OLLAMA_NUM_PARALLEL slots جنہیں ابھی 4 pin کیا, اور باقی سب کو queue میں رکھتا ہے۔ درخواست number 40 slot کھلنے تک شروع نہیں ہوتی۔ مشین کا سب سے expensive حصہ, گرافکس کارڈ, batch کا زیادہ تر وقت queue کے ساتھ wait کرتا ہے۔
یہ Ollama کی flaw نہیں ہے۔ یہ honest design انتخاب ہے: Ollama ایک شخص کے لیپ ٹاپ کو comfortable بنانے کے لیے بنا ہے۔ ریستوراں بننے کے لیے کبھی نہیں بنا۔
یہ ایک cook اور دو burners والی home کچن ہے۔ ایک dinner guest, بہتر۔ 50 guests ہوں, تو 45 order slip لیکر hallway میں کھڑے ہیں۔ Cook lazy نہیں اور stove broken نہیں۔ Kitchen crowd کے لیے design ہی نہیں ہوئی۔
تصور 8 تب done ہے جب: Ollama پر concurrency 1, 5, 10, 25 اور 50 کے پانچ measured تھروپٹ numbers ہیں اور آپ نے queue کو اپنی آنکھوں سے بنتے دیکھا۔
9. Industrial کچن: اسی برین کو vLLM سے serve کریں
اب دوسری سروس پرت۔ vLLM ایک مفت اوپن سورس پروگرام ہے جس کا ایک کام ہے: گرافکس کارڈ waste کئے بغیر ماڈل کو کئی صارفین کے لیے ایک ساتھ serve کرنا۔ یہ UC Berkeley research سے آیا اور اب کمپنیاں کے اوپن ماڈلز production میں serve کرنے کا standard طریقہ ہے۔ Ollama ایک شخص کی comfort optimize کرتا ہے, vLLM total تھروپٹ۔
وہ تھروپٹ دو ideas سے ملتا ہے, جنہیں simple words میں جاننا useful ہے:
- مسلسل بیچنگ۔ Graphics card کئی کام ایک ساتھ کرنے میں best ہے۔ اس لیے vLLM کئی درخواستیں ساتھ بھیجتا ہے۔ Clever حصہ یہ ہے: ایک درخواست ختم ہوتے ہی waiting درخواست دوسروں کو روکے بغیر درمیان stream میں اس کی slot میں آتی ہے۔ Queue میں کام ہو, تو card idle نہیں رہتا۔ اس کا موازنہ اس queue سے کریں جہاں card کچھ درخواستیں serve کر کے ختم کرتا, پھر اگلی اٹھاتا ہے۔
- اصطلاح Paged memory (PagedAttention)۔ ہر active conversation کو card کی working memory چاہیے۔ پرانے سرورز ہر conversation کے لیے بڑا block reserve کرتے تھے, جو زیادہ تر empty رہتا۔ اس لیے card سچ میں full ہونے سے پہلے "full" دکھتا تھا۔ vLLM memory کو چھوٹی pages میں کاٹ کر صرف ضرورت پر دیتا ہے, جیسے operating system RAM manage کرتا ہے۔ Result: ایک ہی card پر ایک ساتھ بہت زیادہ conversations fit ہوتی ہیں۔

طریقہ کار کے names یاد رکھنے کی ضرورت نہیں۔ Effect یاد رکھیں: card full رہتا ہے, اس لیے زیادہ صارفین آنے پر total تھروپٹ بڑھتا ہے, queue نہیں بنتی۔
ایک اور بات, تاکہ درجہ names mislead نہ کریں۔ یہ حصہ vLLM کو single مشین پر run کرتا ہے, لیکن vLLM وہیں نہیں رکتا: وہ ایک ماڈل کو کئی گرافکس کارڈز اور کلسٹر کی طرح کام کرتی کئی مشینیں میں پھیلا سکتا ہے۔ یہ الگ product نہیں, بڑا پیمانہ والا ایک ہی سافٹ ویئر ہے۔ حصہ 3 میں rent کئے کئی professional hosts اپنے کلسٹرز پر یہی چلاتے ہیں۔ اس لیے درجے کے نام ہارڈویئر کون operate کرتا ہے سے آتے ہیں, سافٹ ویئر کیا کر سکتا ہے اس سے نہیں۔ حصہ 2 میں ایک سرور پر vLLM operator آپ ہیں۔ حصہ 3 میں 64 stoves پر کوئی اور operator ہے اور ان کی کچن کے vLLM چلانے کی اچھا امکان ہے۔
اب run کریں۔ GPU مشین پر vLLM install کر کے ابھی test کئے ماڈل کا counterpart serve کریں۔ Names پر note: Ollama اور vLLM الگ libraries سے ماڈلز download کرتے ہیں, اس لیے ایک ہی برین کے دو names ہیں۔ Ollama library میں qwen3:8b, Hugging Face پر Qwen/Qwen3-8B ہے, جہاں سے vLLM ماڈلز لیتا ہے۔ Variable isolate کرنے کے promise کی وجہ honest note بھی ہے۔ دونوں copies byte-for-byte ایک ہی نہیں: Ollama tag weights کی compressed (quantized) copy دیتا ہے تاکہ لیپ ٹاپس میں fit ہو; vLLM full-precision original download کرتا ہے۔ اس لیے "ایک ہی برین" کو precise پڑھیں: ایک ہی Qwen3 8B ماڈل کے دو serving-specific builds, Ollama والی lighter copy۔ Precision difference numbers کے ساتھ چلنے والا ایک اور variable ہے, لیکن experiment کا تھروپٹ pattern نہیں بدلتا۔ Closest match کے لیے vLLM side پر compressed build بھی serve کریں: ایک ہی flags کے ساتھ vllm serve Qwen/Qwen3-8B-FP8۔
pip install vllm
vllm serve Qwen/Qwen3-8B \
--enable-auto-tool-choice \
--tool-call-parser hermes \
--reasoning-parser qwen3
یہ رن سے پہلے ہارڈویئر note۔ Full-precision 8B build کو صرف weights کے لیے تقریباً 16 GB GPU memory چاہیے, conversation working memory سے پہلے۔ Comfortable run کے لیے تقریباً 24 GB card چاہیے۔ 16 GB card پر compressed build serve کریں: ماڈل name Qwen/Qwen3-8B-FP8 کریں اور ایک ہی flags رکھیں۔ pip install vllm driver اور CUDA versions پر مشین سے لڑتا ہے, تو official vLLM Docker image سب سے reproducible install path ہے; vLLM docs اسے cover کرتے ہیں۔
پہلی run ماڈل download کر کے سرور کو http://localhost:8000 پر start کرتا ہے۔ دو ٹول flags دکھنے سے زیادہ important ہیں: tool-call parser کے ساتھ --enable-auto-tool-choice vLLM کو ماڈل output سے تصور 6 کی clean structured ٹول کالز بنانے دیتا ہے۔ انہیں چھوڑیں اور کوڈنگ ایجنٹس خاموشی سے fail ہوں گے, کیونکہ سرور ہارنس کے execute کرنے قابل ٹول کال نہیں بنائے گا۔ درست parser name ماڈل خاندان کے مطابق بدلتا ہے۔ hermes Qwen3 ماڈلز کا standard ہے۔ دوسرا ماڈل serve کرنے پر vLLM ٹول کالنگ docs check کریں۔
ایک درخواست سے prove کریں کہ یہ up ہے:
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "Qwen/Qwen3-8B", "messages": [{"role": "user", "content": "Say hello in one line."}]}'
ابھی type کئے content کو دیکھیں۔ localhost, port 8000, /v1/chat/completions۔ یہ پورے کورس والا پتہ shape ہے۔ برین نہیں بدلا۔ پتہ کے پیچھے کچن بدلی۔
تصور 9 تب done ہے جب: vLLM مشین پر Qwen3 8B serve کر کے curl درخواست جواب کرتا ہے اور آپ ایک-ایک sentence میں continuous batching و paged memory کا benefit بتا سکتے ہیں۔
10. Reveal: وہی 50 درخواستیں, دو curves
سب تیار ہے۔ ایک ہی مشین۔ ایک ہی برین۔ ایک ہی script۔ ایک ہی 50 درخواستیں۔ صرف سروس پرت الگ ہے۔ vLLM پر وہی sweep run کریں:
python bench.py http://localhost:8000/v1 Qwen/Qwen3-8B 1
python bench.py http://localhost:8000/v1 Qwen/Qwen3-8B 5
python bench.py http://localhost:8000/v1 Qwen/Qwen3-8B 10
python bench.py http://localhost:8000/v1 Qwen/Qwen3-8B 25
python bench.py http://localhost:8000/v1 Qwen/Qwen3-8B 50
خاص تور پر concurrency 50 batch دیکھیں۔ Ollama پر کئی منٹ تک پھیلا wall-clock time collapse ہونا چاہیے: 50-request batch pinned Ollama configuration سے کافی جلدی پورا ہوتا ہے اور جوابات shifts کے بجائے پاس-پاس آتے ہیں۔
اب تصویر draw کریں, کیونکہ حصہ 2 سے یہی ایک چیز ساتھ رکھنی ہے۔ اس script میں اپنے 10 measured numbers ڈالیں (pip install matplotlib اگر needed ہو) اور run کریں:
# plot.py: tokens per second against concurrency, one line per serving layer.
import matplotlib.pyplot as plt
concurrency = [1, 5, 10, 25, 50]
ollama_tps = [0, 0, 0, 0, 0] # your five Ollama numbers from Concept 8
vllm_tps = [0, 0, 0, 0, 0] # your five vLLM numbers from this concept
plt.plot(concurrency, ollama_tps, marker="o", label="Ollama (qwen3:8b)")
plt.plot(concurrency, vllm_tps, marker="o", label="vLLM (Qwen/Qwen3-8B)")
plt.xlabel("Concurrent requests")
plt.ylabel("Total throughput (tokens/sec)")
plt.title("Same model, same machine, two serving layers")
plt.legend()
plt.savefig("two-curves.png", dpi=200)
آپ کو دو curves ملتی ہیں۔ Ollama line تقریباً flat رہنی چاہیے: صارفین جوڑنے سے تھروپٹ نہیں بڑھتا, اہم شکل سے queue لمبی ہوتی ہے, اس لیے ہر صارف کا share گھٹتا ہے۔ vLLM line climb کرنی چاہیے: ہر نیا صارف تھروپٹ جوڑتا ہے, پہلے تیزی سے, پھر گرافکس کارڈ کے سچ میں full ہونے پر مڑتی ہے۔ Exact numbers card, versions اور سیٹنگز پر depend کرتے ہیں اور کسی دوسرے سے match نہیں ہوں گے۔ Shapes اکثر match کریں گی, اور shapes ہی lesson ہیں۔ ایک habit run کو anecdote کے بجائے evidence بناتی ہے: numbers کے پاس card, driver, Ollama اور vLLM versions لکھیں, تاکہ الگ ہارڈویئر کا الگ result mystery نہیں, finding ہو۔

اوپر کی تصویر expected shapes دکھاتی ہے, حقیقی measurements نہیں۔ آپ کے 10 numbers سے بنا آپ کا chart ہی اہم ہے۔
اب curves کے gap کو precisely کہیں۔ ہارڈویئر نہیں: ایک ہی card۔ Script نہیں: ایک ہی درخواستیں۔ Important sense میں برین نہیں: ایک ہی ماڈل خاندان, صرف تصور 9 والا precision difference, جو numbers کے ساتھ چلنے والا ایک اور variable ہے۔ Gap اہم شکل سے سروس پرت کا ہے۔ Practice جتنا allow کرتی ہے, باقی سب fixed رکھا, ایک چیز بدلی اور measured effect بہت بڑا ہے۔ یہی honest claim ہے اور کافی سے زیادہ مضبوط ہے۔
ایک دوست chart دیکھ کر کہتا ہے: "تو vLLM ماڈل کو تیز بناتا ہے۔ لیپ ٹاپ پر بھی use کرنا چاہیے۔" Sentence میں کیا درست اور کیا غلط ہے? دونوں halves غلط ہیں, اور اس سے lesson ملتا ہے۔ ایک صارف کے لیے vLLM ماڈل کو تیز نہیں بناتا: concurrency 1 پر curves اکثر پاس سے شروع ہوتی ہیں, کیونکہ single درخواست card full رکھنے والی techniques use نہیں کر سکتی۔ vLLM load میں مشین کو تیز بناتا ہے, کئی درخواستیں ساتھ serve کر کے۔ وہ عام لیپ ٹاپ کی مدد بھی نہیں کرتا, کیونکہ continuous batching کے لیے گرافکس کارڈ چاہیے۔ vLLM وہیں shine کرتا ہے جہاں Ollama کبھی جانے کے لیے design نہیں ہوا: ایک مضبوط مشین, کئی صارفین۔جواب دیکھیں
تصور 10 تب done ہے جب: chart موجود ہے, ایک curve flat اور ایک climbing ہے, اور ایک sentence میں بتا سکتے ہیں کہ gap اہم شکل سے سروس پرت کا کیوں ہے۔
11. کوڈنگ ایجنٹs کو سرور سے جوڑیں
تیز سرور تبھی interesting ہے جب ٹولز اسے use کر سکیں۔ اس لیے حصہ 1 والا move کورس کے تیسرے پتے پر دہرائیں: Claude Code اور OpenCode کو vLLM پر point کریں۔
اب یہ تقریباً suspicious لگنا چاہیے: wiring وہی ہے۔ vLLM دونوں agents کے درخواست formats بولتا ہے۔ OpenCode والا OpenAI-style پتہ اور Claude Code کا native Anthropic Messages format دونوں implement کرتا ہے, اس لیے درمیان میں translator نہیں ہے۔
- Claude Code
- OpenCode
حصہ 1 والی تین سیٹنگز, نیا port اور ایک addition: Claude Code کو بتائیں کہ ہر ماڈل درجہ served ماڈل پر map ہوتا ہے۔
export ANTHROPIC_BASE_URL=http://localhost:8000 # bare address again, no /v1
export ANTHROPIC_AUTH_TOKEN=dummy
export ANTHROPIC_API_KEY=dummy
export ANTHROPIC_DEFAULT_OPUS_MODEL=Qwen/Qwen3-8B
export ANTHROPIC_DEFAULT_SONNET_MODEL=Qwen/Qwen3-8B
export ANTHROPIC_DEFAULT_HAIKU_MODEL=Qwen/Qwen3-8B
claude
ماڈل درجہ lines اس لیے ہیں کیونکہ Claude Code عام طور پر Anthropic کے بڑے اور چھوٹے ماڈلز میں name سے switch کرتا ہے۔ تینوں درجے کو served ماڈل پر map کرنے کا مطلب ہے کہ وہ جو بھی مانگے, Qwen3 8B پائے۔ یہ variables vLLM کی Claude Code guide سے آتے ہیں; drift ہونے پر وہی live source check کریں۔
حصہ 1 کا opencode.json copy کر کے دو strings بدلیں: port اور ماڈل name۔
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"vllm": {
"npm": "@ai-sdk/openai-compatible",
"name": "vLLM (server)",
"options": { "baseURL": "http://localhost:8000/v1" },
"models": { "Qwen/Qwen3-8B": { "name": "Qwen3 8B (vLLM)" } }
}
},
"model": "vllm/Qwen/Qwen3-8B"
}
غور دیں /v1 رہتا ہے: OpenCode اب بھی OpenAI style بولتا ہے اور vLLM جواب کرتا ہے۔ حصہ 1 کا bare بنام /v1 contrast بغیر change کے آ گیا۔
پھر throwaway folder میں تصور 4 والا exact کام run کریں:
اس folder کو دیکھیں۔ ایک چھوٹا safe improvement تلاش کریں, change کریں اور دکھائیں کہ کیا بدلا۔
حصہ 1 میں لیپ ٹاپ آہستہ یا broken تھا, تو یہ payoff ہے۔ ایک ہی ماڈل, ایک ہی کام, لیکن کام کے لیے بنی سروس پرت کے پیچھے حقیقی گرافکس کارڈ: تصور 5 کی تھروپٹ رکاوٹ چلی گئی اور ٹول کالز flow کرتی ہیں, کیونکہ vLLM کو tool-parser flags سے start کیا۔
شیئرنگ پر honest note۔ vLLM مشین آپ کے علاوہ کسی کو serve کرے, تو localhost مشین کا حقیقی پتہ بنتا ہے اور internet پر open ماڈل سرور کھلا door ہے۔ کم از کم vLLM کو حقیقی secret والی --api-key سے start کریں, صارفین کو key دیں اور مشین کو network کی usual protections کے پیچھے رکھیں۔ vLLM docs safe سروس cover کرتے ہیں۔ کلاس use سے پہلے پڑھیں۔
تصور 11 تب done ہے جب: کم از کم ایک کوڈنگ ایجنٹ نے vLLM سرور سے حقیقی کام پورا کیا اور حصہ 1 سے بدلی ایک چیز, پتہ, تتھا نہ بدلی چیز, باقی سب, بتا سکتے ہیں۔
12. سرور درجہ کب درست ہے
اب دونوں measured curves ہیں, اس لیے decision fashionable کے بجائے honest ہو سکتا ہے۔
سرور درجہ تب جیتتا ہے جب ایک مضبوط مشین کئی mouths serve کر سکے:
- اصطلاح Team یا کلاس۔ 50 لیپ ٹاپس پر 50 طلبہ حصہ 1 کی دونوں رکاوٹیں hit کرتے ہیں۔ ایک vLLM مشین پر point کئے 50 طلبہ ایک cleared رکاوٹ share کرتے ہیں۔ Lab, کمپنی یا PIAIC کلاس ایک GPU کی قیمت پر سب کو capable agent ایسے دیتا ہے۔
- پورا دن چلنے والے loops۔ آگے Loop Engineering میں بنائے agents ہمیشہ ہر few منٹ درخواستیں بھیجیں گے۔ Per-token بل ہمیشہ بڑھتی ہے۔ اپنی GPU پہلے سے busy ہو, تو ایک اور درخواست تقریباً کوئی extra لاگت نہیں جوڑتی۔ Climbing curve وجہ دکھاتی ہے: load کے ساتھ تھروپٹ بڑھتا ہے, اس لیے busy مشین کی per-token لاگت کم ہے۔
- اصطلاح Team پیمانہ پر رازداری۔ حصہ 1 کا رازداری argument پوری organization کے لیے: ڈیٹا آپ کے control کی مشین پر رہتا ہے اور سب کو service ملتی ہے۔
اب honest limit, جو حصہ 3 کا bridge ہے۔ vLLM نے ایک رکاوٹ move کی: تھروپٹ۔ دوسری کو نہیں چھوا۔ vLLM کے پیچھے Qwen3 8B 50 لوگوں کو جلدی جواب کرتا ہے اور لیپ ٹاپ جتنا ہی smart ہے, کیونکہ نیچے ایک ہی برین ہے۔ کام 8B ماڈل کے لیے مشکل ہو, تو کوئی سروس پرت نہیں بچا سکتی۔ صلاحیت رکاوٹ بڑے برین سے clear ہوتی ہے اور دنیا کے سب سے بڑے open برینز کرائے کی مشین یا آپ کی کسی future single مشین میں fit نہیں ہوتے۔ ان کے لئے پتہ ایک بار اور بدلیں۔
پورا دن چلنے والا agent loop مشکل refactoring کام پر wrong جوابات دیتا رہتا ہے۔ Colleague اسے fix کرنے کے لیے Ollama سے vLLM پر جانے کو کہتا ہے۔ کیا وہ کام کرے گا? نہیں۔ مشکل کام پر wrong جوابات صلاحیت رکاوٹ ہیں اور سروس پرت اسے نہیں چھوتی: vLLM ایک ہی برین کو تیز serve کرتا ہے, smarter برین نہیں۔ vLLM پر جانے سے queues اور slowness, یعنی تھروپٹ, fix ہوتے ہیں۔ Wrong جوابات fix کرنے کے لیے مضبوط ماڈل چاہیے, جس کے لئے حصہ 3 کا کلاؤڈ درجہ ہے۔ یہ تصور 5 کی جدول ایک درجہ اوپر ہے۔جواب دیکھیں
تصور 12 تب done ہے جب: ایسی situation بتا سکتے ہیں جہاں سرور درجہ لیپ ٹاپ اور کلاؤڈ دونوں سے بہتر ہے, اور کہ سکتے ہیں vLLM کون سی رکاوٹ move کرتا اور کون سی نہیں۔
حصہ 3: کلاؤڈ درجہ۔ فرنٹیئر اوپن ماڈلز جنہیں تقریباً کوئی خود ہوسٹ نہیں کر سکتا (OpenRouter)
اس حصے کی سروس پرت کسی اور کا کلسٹر ہے, جس تک OpenRouter سے پہنچتے ہیں۔ پیمانہ ایسے بڑے ماڈلز ہیں کہ آپ کے اور دنیا کی تقریباً ہر کمپنی کے لیے "self-host" حقیقی option نہیں رہتا۔
13. ایسے open weights جنہیں اٹھا نہیں سکتے: Kimi K3 اور DeepSeek V4 Pro
حصہ 2 honest limit پر ختم ہوا: صلاحیت رکاوٹ بڑے برین سے clear ہوتی ہے۔ اب موجود سب سے بڑے open برینز دیکھیں اور اس size پر "open" کا مطلب honestly سمجھیں۔
جولائی 2026 میں یہ صفحہ لکھتے وقت کورس دو ماڈلز use کرتا ہے, الگ reasons کے لیے چنے گئے:
- اصطلاح Kimi K3, Moonshot AI کا, کارکردگی کے لیے چنا۔ July 2026 میں release ہوا 2.8 trillion parameter ماڈل, ایک million ٹوکن سیاق کھڑکی کے ساتھ۔ Release پر major صلاحیت indexes میں اب تک کا strongest اوپن ویٹ ماڈل تھا, best closed ماڈلز کے پاس۔ Rankings monthly بدلتی ہیں, اس لیے dated snapshot مانیں اور دوہرانے سے پہلے current leaderboards check کریں۔ Weights سچ میں open ہیں۔ ہر ایک download کر سکتے ہیں۔
- اصطلاح DeepSeek V4 Pro, DeepSeek کا, قیمت کارکردگی کے لیے چنا۔ 1.6 trillion parameter ماڈل, تقریباً 49 billion active per ٹوکن, ایک ہی ایک million ٹوکن سیاق کھڑکی اور MIT license کے ساتھ۔ Raw صلاحیت میں K3 سے ایک مرحلہ نیچے اور use میں بہت cheaper ہے; یہی trade اسے یہاں لاتی ہے۔
ایک detail درجے کو جوڑتی ہے: Moonshot نے K3 release کرتے وقت اس کی نئی attention design کا سروس code براہ راست vLLM میں contribute کیا, تاکہ hosts ہر جگہ چلا سکیں۔ حصہ 2 کی industrial کچن اور اس حصے کی فرنٹیئر کچنز اکثر الگ پیمانے پر ایک ہی سافٹ ویئر ہیں۔
اب honest arithmetic۔ "Open weights" کا مطلب ہے آپ خود run کر سکتے ہیں; یہ نہیں کہ آپ کے پاس صلاحیت ہے۔ Moonshot K3 کو 64 یا زیادہ accelerator chips کی configurations پر ایک مشین کی طرح serve کرنے کی مشورہ دیتا ہے۔ DeepSeek V4 Pro چھوٹا ماڈل ہے, پھر بھی self-host کرنے میں 8 سے 16 datacenter GPUs کا کلسٹر لگتا ہے, ہارڈویئر جس کی لاگت house سے زیادہ ہے۔ حصہ 2 skills Qwen3 32B جیسے ماڈلز یا کرائے کی multi-GPU box پر 100B-class mixture تک پیمانہ ہوتی ہیں۔ یہاں تک نہیں, اور serious infrastructure teams کے باہر تقریباً کسی کی skills نہیں ہوتیں۔ فرنٹیئر اوپن ماڈلز سب rent کرتے ہیں۔
اگر rent ہی کرنا ہے, تو "open" کیا دیتا ہے? تین حقیقی چیزیں۔ No lock-in: ایک کمپنی ماڈل نہیں ہٹا سکتی, اکیلے reprice یا silently change نہیں کر سکتی, کیونکہ کلسٹر والا کوئی بھی ایک ہی weights serve کر سکتا ہے اور competitors کرتے ہیں۔ Landlord انتخاب: کئی کمپنیاں ایک ہی weights host کر کے قیمت اور speed پر compete کرتی ہیں۔ Future floor: سچ میں matter کرے, تو آپ, ملک یا کمپنی ہارڈویئر کھڑا کر سکتے ہیں۔ اس پیمانہ پر open weights کا مطلب "گھر پر run کریں" کم اور "tap پر کسی ایک کا ownership نہیں" زیادہ ہے۔
ہوسٹس کی competition practical problem بناتی ہے: dozens hosting کمپنیاں, سب کے اپنے اکاؤنٹس, keys اور billing۔ OpenRouter اسے کورس کے expected طریقے سے solve کرتا ہے: ایک پتہ۔ Precise رہیں, کیونکہ درجہ جدول simplify کرتی ہے۔ OpenRouter ایک gateway ہے, router جو درخواست receive کر کے اصل ماڈل serve کرنے والے host کو forward کرتا ہے۔ Host سروس پرت operate کرتا ہے, اکثر vLLM۔ OpenRouter front door operate کرتا ہے: سیکڑوں ماڈلز کے لیے ایک اکاؤنٹ, ایک API key, ایک billing صفحہ۔ openrouter.ai پر sign up, کچھ ڈالر credit, key create اور سب سے پہلے monthly spend limit set کریں۔ Key ایک string میں secret اور wallet ہے: commit یا share ہونے والے code میں paste نہ کریں۔
حصہ 1 گھر میں cooking تھا۔ حصہ 2 اپنی industrial کچن چلانا۔ حصہ 3 دنیا کے great restaurants ہیں: 64 stoves اور cooks کی brigade والی کچنز۔ آپ گھر میں نہیں بنائیں گے اور ضرورت بھی نہیں۔ OpenRouter delivery ایپ ہے جس میں سب restaurants ایک menu پر, ایک login اور بل کے ساتھ ہیں۔ فون ایپ پورے وقت وہی ہے۔
تصور 13 تب done ہے جب: OpenRouter اکاؤنٹ, key اور spend limit set ہے, اور ایک sentence میں بتا سکتے ہیں کہ اس پیمانہ پر "open weights" و "آپ self-host کر سکتے ہیں" ایک ہی claim کیوں نہیں رہے۔
14. انہیں دو agents سے فرنٹیئر برینز چلائیں
تیسرا درجہ, وہی move۔ حصے 1 اور 2 کے exact ہارنسز کو زمین کے strongest اوپن ماڈلز پر point کریں گے اور wiring تقریباً شرم ناک شکل سے familiar لگے گی۔
- Claude Code
- OpenCode
یہاں OpenRouter Claude Code کا native format براہ راست بولتا ہے, جسے وہ Anthropic-compatible endpoint کہتا ہے۔ Setup حصہ 1 والی تین variables ہے, درمیان میں حقیقی key:
export ANTHROPIC_BASE_URL=https://openrouter.ai/api # bare, one more time: no /v1
export ANTHROPIC_AUTH_TOKEN=sk-or-... # your OpenRouter key
export ANTHROPIC_API_KEY= # must be empty
claude --model moonshotai/kimi-k3
اسے کہیں persist کرنے سے پہلے hygiene note۔ Key wallet ہے۔ Shell exports ایک session رہتے ہیں, آغاز کی safe جگہ۔ Variables سیٹنگز فائل میں لے جائیں, تو home folder کا ~/.claude/settings.json use کریں, project کی committed سیٹنگز فائل کبھی نہیں, کیونکہ git repository میں pushed key strangers کھرچ کریں گے۔
یہاں OpenRouter ماڈل names maker/model shape follow کرتے ہیں اور exact string matter کرتی ہے: Kimi K3 کے لیے moonshotai/kimi-k3, DeepSeek V4 Pro کے لیے deepseek/deepseek-v4-pro۔ ایک wrong character صرف "ماڈل not found" لوٹاتا ہے, اس لیے slugs type کرنے کے بجائے openrouter.ai ماڈل صفحہ سے copy کریں۔
ہارنس Claude Code کو Anthropic کے ماڈلز کے مقابل بنایا اور جانچا گیا ہے، اور OpenRouter مکمل Claude Code compatibility صرف Anthropic کے first-party provider کے ساتھ یقینی بناتا ہے۔ Kimi K3 اور DeepSeek V4 Pro compatible format بولتے ہیں اور کئی لوگ انہیں کامیابی سے چلاتے ہیں، لیکن setup درست ہونے کے باوجود harness-model fit کے باعث ٹول کال عجیب آ سکتی ہے۔ اس جوڑی کو تجرباتی سمجھیں۔ مکمل طور پر supported راستہ چاہیے تو OpenCode tab استعمال کریں: OpenRouter بغیر compatibility caveat کے OpenCode کا native provider ہے۔ Claude Code رکھ کر خامیاں ہموار کرنی ہوں تو community نے اسی کام کا ٹول بنایا ہے: تصور 16 میں Claude Code Router۔
دو habits ایک evening بچاتی ہیں:
/statusسے verify کریں کہ words کہاں جا رہے ہیں۔Anthropic base URLline پر OpenRouter پتہ اور ٹوکن active credential دکھنا چاہیے۔ Check پر بھروسا کریں, assumption پر نہیں۔- حوالہ: Claude Code current docs کے مطابق
ANTHROPIC_AUTH_TOKENsaved Anthropic login سے پہلے آتا ہے, اس لیے past login درخواستیں hijack نہیں کرنا چاہیے۔ لیکن stale login startup پر auth-conflict warning trigger کر سکتا ہے اور older guides interference report کرتی ہیں۔/statuswrong endpoint دکھائے یا conflict warning دو credential sources بتائے, تو/logoutایک بار run, restart اور پھر check کریں۔
یہاں OpenCode پہلے سے OpenRouter کو جانتا ہے، اس لیے provider block نہیں لکھنا۔ OpenCode کے اندر /connect چلائیں، OpenRouter منتخب کریں اور key paste کریں؛ پرانے versions میں shell سے opencode auth login استعمال ہوتا ہے۔ کئی OpenRouter ماڈلز پہلے سے شامل ہیں، اس لیے /models سے چن سکتے یا opencode.json میں pin کر سکتے ہیں:
{
"$schema": "https://opencode.ai/config.json",
"model": "openrouter/deepseek/deepseek-v4-pro"
}
دوسرے کو چلانے کے لیے openrouter/moonshotai/kimi-k3 لگائیں۔ بس یہی پوری configuration ہے۔
اب ایک ہی throwaway folder میں تصور 4 کام آخری بار, دونوں ماڈلز سے ایک-ایک بار run کریں:
اس folder کو دیکھیں۔ ایک چھوٹا safe improvement تلاش کریں, change کریں اور دکھائیں کہ کیا بدلا۔
پہلے runs سے difference محسوس کریں۔ Queue, crawl یا broken ٹول کالز نہیں ہونے چاہیے: فرنٹیئر ماڈلز صلاحیت رکاوٹ کو بڑے margin سے clear کرتے ہیں اور تھروپٹ رکاوٹ کسی اور کے 64 stoves پر ہے۔ ایک پتہ بدل کر دونوں رکاوٹیں ایک ساتھ clear۔ Run پھر بھی stumble کرے, تو cause بھی move ہوا: مقامی ہارڈویئر نہیں, model-harness fit, provider, routing یا prompt investigate کریں۔
جو چھوڑا اس پر بھی غور دیں, کیونکہ trade lesson ہے۔ تصور 1 کے بعد پہلی بار words مشین سے باہر گئے اور کورس میں پہلی بار ٹوکنز flow کرتے وقت money لاگت کرتے ہیں۔ کام کے بعد OpenRouter activity صفحہ دیکھیں اور قیمت والی درخواست دکھائی دے گی۔ Private اور مفت حصہ 1 تھے۔ یہ powerful اور metered ہے۔
ایجنٹ اب OpenRouter سے کام جلدی complete کرتا ہے۔ تصور 1 کے مقابلے میں چھوڑی دو چیزیں اور words کا destination سچ بتانے والی ایک habit بتائیں۔ آپ نے رازداری چھوڑی, کیونکہ words مشین سے نکل کر provider سے جاتے ہیں, اور مفت چھوڑا, کیونکہ ہر ٹوکن credit سے meter ہوتا ہے۔ Habit check کرنا ہے, assume نہیں: Claude Code میں جواب دیکھیں
/status یا OpenCode ماڈل picker exact پتہ دکھاتا ہے۔ حصہ 1 کا rule ہر درجہ پر ہے: visible سیٹنگ پر بھروسا کریں, یاد والے setup پر نہیں۔
تصور 14 تب done ہے جب: K3 اور V4 Pro دونوں نے agent سے حقیقی coding کام complete کیا, /status یا OpenCode ماڈل picker درخواستوں کا destination confirm کرتا ہے اور activity صفحہ پر حقیقی قیمت والی حقیقی درخواست دیکھی ہے۔
15. کارکردگی یا قیمت: ماڈل اور درجہ چننا
آپ نے دونوں فرنٹیئر ماڈلز چلائے۔ ان کی لاگت ایک ہی نہیں اور انتخاب وہ decision ہے جو اب لگاتار لیں گے۔
یہ صفحہ لکھتے وقت list قیمتیں تقریباً: Kimi K3 کے لیے $3 per million input ٹوکنز اور $15 per million output ٹوکنز, DeepSeek V4 Pro کے لیے تقریباً $0.44 input اور $0.87 output۔ Gap آہستہ پڑھیں: output میں price-performance انتخاب کارکردگی انتخاب سے تقریباً 17 گنا cheaper ہے۔ قیمتیں تیزی سے بدلتی ہیں, اس لیے numbers کو version number کی طرح مانیں: reasoning کا snapshot, اور بجٹ سے پہلے ماڈلز کے OpenRouter pages پر live check۔
تو K3 17 گنا زیادہ کب درست ہے? جب کام اتنی مشکل ہو کہ V4 Pro fail کرے اور failure کی لاگت آپ کا time ہو۔ ایک successful لمبا agentic run ان پانچ سستا runs سے بہتر ہے جنہیں حل کرنا پڑے۔ Teams کا working rule: price-performance ماڈل default رکھیں, سستا ماڈل insufficient prove ہونے پر کارکردگی ماڈل تک escalate کریں, اور vibes نہیں, حقیقی failures escalation trigger کریں۔ Agents کے لیے ایک number پوری calculation بدلتا ہے: cached input۔ Agent ہر turn ایک ہی instructions اور repository سیاق پھر بھیجتا ہے, اور repeated prefix cache hit کرے تو دونوں providers input قیمت کا tiny fraction charge کرتے ہیں۔ Loop-style workloads میں effective بل اکثر list-price math سے بہت کم ہوتی ہے۔ Pricing pages ہر provider کے caching rules سمجھاتی ہیں۔ Agent کام میں وہ section پہلے پڑھیں, آخر میں نہیں۔
اب پورا zoom out کریں, کیونکہ full تصویر earned ہے۔ ایک ہارنس, ایک خیال, تین درجے:
| درجہ | سروس پرت | اس کورس کا برین | پتہ | Compute کون pay کرتا ہے | کس میں جیتتا ہے |
|---|---|---|---|---|---|
| مقامی | Ollama | Qwen3 8B | آپ کا localhost | پہلے pay کر چکے (لیپ ٹاپ) | رازداری, offline, مفت, learning |
| سرور | vLLM | Qwen3 8B, serving-specific build | آپ کے control کی مشین | آپ, GPU گھنٹہ کے حساب سے | کئی صارفین, all-day loops, team ڈیٹا |
| کلاؤڈ | OpenRouter (gateway) | Kimi K3, DeepSeek V4 Pro | openrouter.ai | آپ, per ٹوکن | hardest کام, zero setup, فرنٹیئر |
فیصلے کا طریقہ, سوالات کے order میں۔ پہلا, کیا ڈیٹا باہر جا سکتا ہے? نہیں, تو کلاؤڈ درجہ باہر; کتنے لوگوں کو service چاہیے اس کے مطابق مقامی یا سرور چنیں۔ دوسرا, کیا کام mid-size open ماڈل کی reach میں ہے? ہاں, تو درجہ economics ہے: ایک کے لیے لیپ ٹاپ, کئی یا loops کے لیے vLLM مشین۔ تیسرا, کام کو فرنٹیئر برین چاہیے, تو کلاؤڈ درجہ اور تصور کا rule: سستا ماڈل default, proven failure پر expensive۔ تین سوالات میں open-model deployment کی ہر conversation fit ہوتی ہے۔

ایک کمپنی کو agent چاہیے جو confidential client contracts ہر دن پورا دن review کرے۔ کام moderately مشکل ہیں, لیکن مضبوط mid-size ماڈل کی reach میں ہیں۔ کون سا درجہ اور باقی دونوں غلط کیوں? سرور درجہ۔ سوال ایک کلاؤڈ ہٹاتا ہے: confidential contracts firm کے control والی مشینیں سے باہر نہیں جانے چاہیے۔ لیپ ٹاپ درجہ دو reasons سے fail: کتنے لوگ serve کرنے ہیں اور دن میں کتنی دیر run کرنا ہے۔ Team کے لیے all-day loop فوراً تھروپٹ رکاوٹ hit کرتا ہے۔ Firm network کے اندر vLLM مشین تھروپٹ clear کرتی, ڈیٹا گھر رکھتی اور all-day loop کو per ٹوکن سستا بناتی ہے۔ کام ماڈل کے لیے مشکل prove ہوں, تو حقیقی انتخاب bigger کرائے کی box پر بڑا open ماڈل ہے, public کلاؤڈ نہیں, کیونکہ سوال ایک اب بھی bind کرتا ہے۔جواب دیکھیں
تصور 15 تب done ہے جب: تین سوالات order میں بتا سکتے ہیں اور اس scenario کے درجہ انتخاب کو defend کر سکتے ہیں جس کا جواب کسی نے نہیں دیا۔
16. تینوں درجے کے لیے ایک router: Claude Code Router
اس کورس کی نینو ایک خیال تھی: برین صرف پتہ ہے۔ Natural last مرحلہ ہے اور popular community ٹول اسے کرتا ہے۔ کیا ہوگا اگر پتہ ایک برین نہیں, decision کی طرف point کرے?
Claude Code Router (CCR) musistudio کا اوپن سورس ٹول اور Claude Code ecosystem کے سب سے-starred projects میں ایک ہے۔ وہ مشین پر چھوٹا سرور چلاتا ہے, ایک طرف Claude Code کا native format اور دوسری طرف کئی providers سے بات کر کے درمیان میں translate کرتا ہے۔ Claude Code کو ایک بار point کریں, پھر config فائل ہر درخواست پر طے کرتی ہے کون سا برین جواب دے۔ کورس کے آخر میں اسے جاننے کے تین reasons ہیں:
- کام type سے route کرتا ہے۔
Routerblock Claude Code کے الگ کام کو ماڈلز پر map کرتا ہے: ordinary کام کے لیےdefault, سستا housekeeping کے لیےbackground, مشکل reasoning کے لیےthink, ٹوکن threshold پار درخواستیں کے لیےlongContext۔ List پھر آہستہ پڑھیں۔ یہ تصور 15 کا rule ہے, price-performance default اور مشکل cases میں escalation, discipline کے بجائے config میں۔ - سیکھے ہر درجہ تک جاتا ہے۔ Config میں provider صرف name, پتہ اور ماڈل list ہے۔ اس لیے ایک فائل Ollama لیپ ٹاپ, vLLM سرور اور OpenRouter کو ساتھ رکھ کر route کر سکتی ہے۔
- اصطلاح Rough edges smooth کرتا ہے۔ Transformers (
openrouter,tooluse,enhancetoolاور دوسرے) provider کے مطابق درخواستیں و responses adapt کرتے ہیں, loosely formatted ٹول کالز میں error tolerance بھی جوڑتے ہیں۔ یہ تصور 14 کی compatibility caution کا community working جواب ہے۔
تین مراحل میں setup کریں۔ Claude Code کے پاس install کریں:
npm install -g @musistudio/claude-code-router
پھر ~/.claude-code-router/config.json بنائیں۔ یہ config پورے کورس کے تینوں درجے ایک پتہ کے پیچھے رکھتی ہے:
{
"OPENROUTER_API_KEY": "$OPENROUTER_API_KEY",
"Providers": [
{
"name": "ollama",
"api_base_url": "http://localhost:11434/v1/chat/completions",
"api_key": "ollama",
"models": ["qwen3:8b"]
},
{
"name": "vllm",
"api_base_url": "http://localhost:8000/v1/chat/completions",
"api_key": "dummy",
"models": ["Qwen/Qwen3-8B"]
},
{
"name": "openrouter",
"api_base_url": "https://openrouter.ai/api/v1/chat/completions",
"api_key": "$OPENROUTER_API_KEY",
"models": ["deepseek/deepseek-v4-pro", "moonshotai/kimi-k3"],
"transformer": { "use": ["openrouter"] }
}
],
"Router": {
"default": "openrouter,deepseek/deepseek-v4-pro",
"background": "ollama,qwen3:8b",
"think": "openrouter,moonshotai/kimi-k3",
"longContext": "openrouter,moonshotai/kimi-k3",
"longContextThreshold": 60000
}
}

Router block کو policy کی طرح پڑھیں, کیونکہ وہی ہے۔ Ordinary کام price-performance فرنٹیئر ماڈل پر جاتا ہے۔ سستا background chores لیپ ٹاپ پر مفت رہتے ہیں۔ مشکل reasoning اور huge contexts Kimi K3 پر escalate ہوتے ہیں, جس کی ایک million ٹوکن کھڑکی longContext slot earn کرتی ہے۔ $OPENROUTER_API_KEY syntax environment سے key لیتی ہے, اس لیے secret فائل میں نہیں بیٹھتا۔
پھر router کے ذریعے Claude Code start کریں:
ccr code
کچھ mechanics وقت بچاتے ہیں: config edit کے بعد changes apply کرنے کے لیے ccr restart run کریں۔ Claude Code کے اندر /model provider,model سے session کے درمیان برینز switch کریں, جیسے /model ollama,qwen3:8b۔ JSON کی جگہ web صفحہ میں config edit کرنا پسند ہو, تو ccr ui کھولتا ہے۔
آخر میں دو honest notes۔ پہلا, CCR community project ہے, Anthropic یا provider کا product نہیں۔ تیزی سے بدلتا ہے, transformers guarantees نہیں working fixes ہیں اور ہر درخواست اب ایک اور سافٹ ویئر سے جاتی ہے جسے update اور release notes پڑھنا چاہیے۔ دوسرا, جہاں ضرورت نہیں وہاں نہ جوڑیں۔ حصہ 2 vLLM سرور Claude Code format native بولتا ہے, اس لیے صرف اس کے آگے router کچھ نہیں دیتا۔ CCR تب درست ہے جب ایک Claude Code کو کئی برینز پر ایک ساتھ کام کے مطابق route کرنا ہو۔ کورس کے بعد یہی setup سمجھتے ہیں: تین درجے, ایک پتہ اور ان کے درمیان policy۔
تصور 16 تب done ہے جب: Claude Code router سے run کرتا ہے, ایک session میں کم از کم دو درجے جواب کرتے ہیں (/model provider,model سے switch کر کے source دیکھیں), اور اپنے Router block کو encoded درجہ policy کی طرح پڑھ سکتے ہیں۔
آج اپنے پیمانہ پر try کریں, پھر آگے بڑھیں
آج سب سے چھوٹا حقیقی version کریں۔ Ollama install, ماڈل run اور chat کریں: صرف اتنا دو منٹ میں private on-machine AI دیتا ہے۔ Code لکھتے ہیں, تو کوڈنگ ایجنٹ connect کر کے hit ہونے والی رکاوٹ محسوس کریں۔ Afternoon کے لیے GPU rent کر سکیں, تو 50-request experiment اور اپنی curves بنائیں: کتاب میں کم exercises ایک گھنٹہ میں زیادہ سکھاتی ہیں۔ کام ہر host ہو سکنے والے برین کو ہرا دے, تو آخری بار پتہ بدل کر cents یا ڈالر میں فرنٹیئر برین borrow کریں۔ دوسرے لوگوں کو بنایا کام چاہیے, تو ضمیمہ A سرور کو shared service بناتا ہے۔
ذہنی ماڈل آگے رکھیں, کیونکہ section order میں اسی پر بنتا ہے۔ ٹول ہارنس اور swappable برین ہے, اور برین صرف پتہ۔ پتہ لیپ ٹاپ, سرور یا دنیا کے biggest اوپن ماڈلز پر point کر سکتا ہے, ہارنس difference نہیں جانتا۔ دو رکاوٹیں setup کی حد طے کرتی ہیں: سروس پرت اور ہارڈویئر تھروپٹ move کرتے ہیں, صرف بڑا برین صلاحیت۔ اب Agentic Coding میں agent چلانا, Spec-Driven Development میں written spec سے direct کرنا اور Loop Engineering میں all-day unattended loop دینا سیکھیں گے۔ Last کورس تک جانیں گے کس کا برین کون-سے درجہ پر loop چلائے اور keep-running لاگت کیا ہے۔
ایک سطر میں خلاصہ
اوپن سورس ماڈلز تین پیمانے پر run ہوتے ہیں اور ٹول ایک پتہ کے ذریعے تینوں تک پہنچتا ہے۔ ایک شخص کے لیے Ollama, کئی کے لیے vLLM, تقریباً کسی کے self-host نہ کر سکنے والے فرنٹیئر برینز کے لیے OpenRouter۔ اپنی دو curves سے difference ایک بار measure کریں اور career بھر درست درجہ چنیں گے۔
ضمیمہ A: ایک چھوٹا LLM کلاؤڈ بنائیں
حصہ 2 نے آپ کو industrial کچن دی۔ Kitchen ریستوراں نہیں ہوتی۔ یہ ضمیمہ front door, menu, جدول numbers اور بل جوڑتا ہے, تاکہ ایک شخص کو اچھی طرح serve کرنے والی مشین پوری class کو safely serve کر سکے۔

یہ ضمیمہ جس gap کو close کرتا ہے, وہ یہ ہے۔ حصہ 2 کے آخر میں vLLM Qwen3 8B serve کر رہا تھا اور آپ کی fifty-request curve وہاں چڑھ رہی تھی جہاں Ollama کی flat ہو گئی تھی۔ یہ حقیقی achievement ہے, لیکن ابھی service نہیں ہے۔ اسے class کو دینے کی کوشش کریں تو سوالات فوراً شروع ہوتے ہیں۔ اسے use کرنے کی permission کسے ہے? ایک طالب علم کے runaway loop کو پوری مشین ایک week تک کھا جانے سے کیا روکتا ہے? کس نے کتنا spend کیا? جب Qwen3 8B کافی نہ ہو, تو طالب علم فرنٹیئر برین تک کیسے پہنچے, بغیر آپ کی اپنی OpenRouter key دو سو لوگوں کو دیے?
ان میں سے کوئی سوال ٹوکنز serve کرنے کے بارے میں نہیں ہے, اور ٹھیک اسی وجہ vLLM ان کا جواب نہیں دیتا۔ Inference engine ماڈل load کر کے درخواستوں کا جواب دیتا ہے۔ اسے صارفین کے ہونے کا پتا نہیں۔ اس کے پاس keys, quotas, spending records یا منع کرنے کا طریقہ نہیں۔ اس missing half کا ایک نام ہے, اور اسے بنانا ہی اس ضمیمہ کا موضوع ہے۔
کورس کا ایک خیال یہاں تک چلتا ہے۔ برین صرف پتہ ہے۔ حصہ 1 میں پتہ آپ کا لیپ ٹاپ تھا۔ حصہ 2 میں وہ آپ کی control کی مشین تھی۔ حصہ 3 میں کسی اور کا کلسٹر تھا۔ اس ضمیمہ میں آپ پتہ بنتے ہیں: وہ چیز بناتے ہیں جس کی طرف دوسرے لوگ اپنے agents point کرتے ہیں۔
حصہ 2 کی ہر چیز, ساتھ میں اسی GPU مشین پر Docker اور Docker Compose۔ حصہ 3 کیا ہے, تو تصور A5 کے لیے اپنی OpenRouter key پاس رکھیں۔ بغیر کچھ run کئے پورا ضمیمہ پڑھ سکتے ہیں, اور stack کبھی نہ بنائیں تب بھی تصورات A1, A2 اور A7 پڑھنا مفید ہے۔
ایک نہیں, دو پروگرامز۔ vLLM ٹوکنز serve کرتا ہے۔ اس کے آگے gateway بیٹھتا ہے اور وہ سب handle کرتا ہے جو vLLM نہیں کرتا: صارف keys, spending limits, ماڈل routing اور logs۔ یہاں use کیا gateway LiteLLM ہے۔ Postgres جوڑیں تاکہ restart کے بعد keys اور spending بنی رہیں, اور Open WebUI جوڑیں تاکہ terminal use نہ کرنے والے لوگ بھی آپ کا کلاؤڈ use کر سکیں۔ Four containers, ایک فائل, ایک afternoon۔
اس ضمیمہ کے نئے words
| Term | آسان meaning |
|---|---|
| Inference engine | وہ پروگرام جو ماڈل load کر کے درخواستیں کے جواب دیتا ہے۔ vLLM ایک inference engine ہے۔ یہ ٹوکنز جانتا ہے, لوگوں کو نہیں۔ |
| Gateway / proxy | Engine کے آگے والا پروگرام۔ یہ لوگوں کے بارے میں جانتا ہے: کون call کر رہا ہے, کیا use کر سکتا ہے اور لاگت کیا ہے۔ |
| Virtual key | Per-person API key جو آپ کا gateway issue اور revoke کرتا ہے, اور جس کے اپنے limits ہوتے ہیں۔ |
| بجٹ | Key کی spending cap۔ اس کے ختم ہونے پر gateway بل بڑھانے کی جگہ درخواست refuse کر دیتا ہے۔ |
| Rate limit | درخواستیں per minute کی cap, تاکہ ایک busy صارف باقی سب کو باہر نہ کر دے۔ |
| Multi-tenancy | Shared ہارڈویئر سے کئی الگ صارفین کو serve کرنا, بغیر انہیں ایک-دوسرے کو affect کرنے دیے۔ |
| Fallback | Rule جو کہتا ہے, "اگر یہ ماڈل fail یا full ہو, تو اس کی جگہ وہ والا try کریں۔" |
تصور A1: کچن ریستوراں نہیں ہوتی
تصور 8 سے کورس جس metaphor کو use کرتا آیا ہے, اسے ایک مرحلہ آگے لے جائیں۔ Ollama دو burners والی home کچن تھی۔ vLLM industrial کچن تھی جو ہر burner کو جلتا رکھتی ہے۔ یہ دونوں گھر کا back ہیں۔
ریستوراں کو front of house بھی چاہیے۔ Door پر کوئی جو جانے کہ reservation ہے یا نہیں۔ Menu جو بتائے کہ آج کیا available ہے۔ جدول number, تاکہ کچن کو پتا ہو ہر dish کہاں جاتی ہے۔ آخر میں بل۔ ان میں سے کچھ بھی cooking نہیں ہے, اور بغیر front of house کی شاندار کچن ریستوراں نہیں ہوتی۔ وہ کچن ہے جس میں strangers بھٹک کر اندر آ جاتے ہیں۔
سادہ vLLM سرور کی حالت ٹھیک یہی ہے۔ Port تک پہنچنے والا کوئی بھی شخص اسے مفت میں ہمیشہ use کر سکتا ہے۔ یہ کیا نہیں کرتا, اسے آہستہ پڑھنا مفید ہے, کیونکہ ہر item وہ چیز ہے جو ورنہ آپ کو خود بنانی پڑے گی:
| آپ کو کیا چاہیے | کیا vLLM یہ کرتا ہے? |
|---|---|
| ایک ساتھ کئی صارفین کو تیزی سے ٹوکنز serve کرنا | ہاں۔ یہی اس کا پورا کام ہے اور یہ اس میں excellent ہے۔ |
| یہ جاننا کہ کون call کر رہا ہے | نہیں۔ |
| Spending limit پر کسی کو روک دینا | نہیں۔ |
| ایک صارف کو باقی سب کو باہر کرنے سے روکنا | کچھ ہد تک queueing سے, لیکن per صارف نہیں۔ |
| ایک پتے پر ایک سے زیادہ ماڈل offer کرنا | نہیں۔ ایک سرور, ایک ماڈل۔ |
| اس کے fail ہونے پر دوسرے ماڈل پر fallback کرنا | نہیں۔ |
| کس نے کتنا spend کیا, record کرنا | نہیں۔ |
| مقامی ماڈل fail ہونے پر کلاؤڈ ماڈل تک پہنچنا | نہیں۔ |
اس جدول کا ہر "نہیں" gateway کا کام ہے۔
کچن کھانا بناتی ہے۔ Front of house طے کرتا ہے کون کھائے, menu میں کیا ہے اور pay کون کرے۔ آپ نے بہت اچھی کچن بنائی ہے۔ اب آپ کو door چاہیے۔
اس point پر fair سوال ہے: کیا کوئی ایک پروگرام دونوں کرتا ہے? تقریباً, اور honest جواب ماینے رکھتا ہے۔ سروس infrastructure problem ہے, اور اوپن سورس world نے اسے بہت اچھی طرح solve کیا ہے۔ Metering, quotas اور billing product problem ہے, اور inference کمپنیاں اصل میں یہی بیچتی ہیں۔ اس لیے open ٹولز engine اور meter الگ pieces میں دیتے ہیں, اور آپ انہیں assemble کرتے ہیں۔ اچھی بات یہ ہے کہ یہاں ہر پرت وہی OpenAI-compatible درخواست shape بولتی ہے جسے حصہ 1 سے use کر رہے ہیں, اس لیے assembly کا مطلب configuration ہے, translation کام نہیں۔
تصور A1 تب done ہے جب: bare vLLM سرور کی تین ایسی چیزیں بتا سکیں جنکی پچاس طلبہ کی class کو دن ایک پر ضرورت ہوگی۔
تصور A2: گیٹ وے۔ ایک پتہ، کئی برین، حقیقی صارفین
Gateway ایک چھوٹا پروگرام ہے جو ایک یا زیادہ ماڈل سرورز کے آگے بیٹھتا ہے۔ درخواستیں gateway پر آتی ہیں, gateway طے کرتا ہے ان کے ساتھ کیا کرنا ہے اور پھر انہیں آگے بھیجتا ہے۔ یہ front door ہے۔
آپ ایک پہلے ہی use کر چکے ہیں۔ حصہ 3 کا OpenRouter gateway ہے: ایک پتہ, ایک key, ایک بل, اس کے پیچھے سیکڑوں of ماڈلز اور actual سروس ایسے hosts کرتے ہیں جنہیں آپ direct contact نہیں کرتے۔ یہ ضمیمہ وہی shape اپنے پیمانہ پر, اپنی مشین پر بناتا ہے, جہاں کمپنی کی جگہ operator آپ ہیں۔
اس کام کے لیے یہاں LiteLLM ہے, ایک اوپن سورس proxy جو صارفین سے OpenAI-compatible shape میں بات کرتا ہے اور باہر providers کی لمبی list کے لیے translate کرتا ہے, جس میں آپ کا اپنا vLLM سرور بھی ہے۔ چار چیزیں اسے درست piece بناتی ہیں:
- اصطلاح Virtual keys۔ ہر طالب علم کو اپنی key issue کرتے ہیں۔ اس پر limits لگا سکتے ہیں, اس کا spend دیکھ سکتے ہیں اور semester ختم ہونے یا لیپ ٹاپ کھونے پر فوراً revoke کر سکتے ہیں۔
- بجٹس اور rate limits۔ Key میں spending cap اور per-minute limit ہو سکتی ہے۔ Runaway loop cap hit کرے, تو gateway اگلی درخواست refuse کر دیتا ہے۔ آپ کا بل اس number پر بڑھنا روک دیتا ہے جسے پہلے چنا تھا۔
- ایک پتے پر ماڈلز کا menu۔ آپ کا مقامی Qwen3 8B اور فرنٹیئر کلاؤڈ ماڈل دونوں ایک ہی gateway پر دکھ سکتے ہیں, اور وہی طلبہ اسی key سے دونوں تک پہنچ سکتے ہیں۔
- اصطلاح Records۔ ہر درخواست صارف کے against log ہوتی ہے, اس لیے "کس نے کتنا spend کیا" investigation نہیں, query ہے۔
اس کا shape notice کریں۔ Gateway کسی چیز کو faster نہیں بناتا۔ یہ ٹوکنز per second کے بارے میں کچھ نہیں بدلتا اور اپنے کچھ milliseconds جوڑتا ہے۔ یہ کارکردگی ٹول بالکل نہیں۔ یہ control ٹول ہے, اور control ہی سرور کو service میں بدلتا ہے۔
طالب علم کہتا ہے gateway بیکار ہے کیونکہ "vLLM مجھے پہلے ہی OpenAI-compatible پتہ دیتا ہے, اس لیے میں وہی use کر سکتا ہوں۔" سب سے مضبوط reply کیا ہے? پتہ کے بارے میں وہ درست اور service کے بارے میں غلط ہیں۔ vLLM پتہ ایک trusted شخص کے لیے ٹھیک کام کرتا ہے, اور اسی وجہ تصور 11 وہاں رک سکتا تھا۔ Gateway اس ہر چیز کے لیے ہے جو کئی لوگوں کے آتے ہی سامنے آتی ہے: separate keys, spending caps, rate limits, ایک سے زیادہ ماڈلز کا menu, fallbacks اور کس نے کیا use کیا اس کا record۔ ان میں سے کوئی speed feature نہیں ہے, اس لیے comparison اس دن تک خالی لگتا ہے جب runaway loop پورے weekend چلتا رہے اور کوئی نہ بتا سکے کہ وہ کس کا تھا۔جواب دیکھیں
تصور A2 تب done ہے جب: ایک sentence میں بتا سکیں کہ gateway کیا جوڑتا ہے جو inference engine کبھی نہیں دے گا, اور یہ speed feature کیوں نہیں ہے۔
تصور A3: اسے کھڑا کریں۔ پورا اسٹیک ایک فائل میں
چار کنٹینرز۔ ایک مشین۔ ایک فائل۔
| Container | کام |
|---|---|
| vllm | آپ کے GPU پر Qwen3 8B serve کرتا ہے۔ تصور 9 والا ہی سرور, اب اس کے آگے door ہے۔ |
| litellm | Gateway۔ یہی ایک چیز ہے جسے آپ کے صارفین کبھی touch کرتے ہیں۔ |
| postgres | Keys, صارفین, بجٹس اور spending store کرتا ہے, تاکہ restart آپ کی class کو wipe نہ کرے۔ |
| open-webui | آپ کی class میں terminal use نہ کرنے والے لوگوں کے لیے chat صفحہ۔ |
گیٹ وے کی اپنی config سے شروع کریں۔ اسے litellm-config.yaml کی شکل میں save کریں:
model_list:
# Your own GPU, from Part 2. Students see the name on the left.
- model_name: qwen3-8b
litellm_params:
model: hosted_vllm/Qwen/Qwen3-8B
api_base: http://vllm:8000/v1
api_key: "not-needed"
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
database_url: os.environ/DATABASE_URL
litellm_settings:
drop_params: true
وہاں دو details کے نام جاننا مفید ہے۔ model_name وہ نام ہے جو آپ کے صارفین type کرتے ہیں, اور اس کا نیچے والے حقیقی ماڈل name سے match کرنا ضروری نہیں: یہی indirection آپ کو بعد میں بغیر کسی کو بتائے برین swap کرنے دیتا ہے۔ اور master_key پورے کلاؤڈ کا آپ کا admin password ہے۔ یہ طالب علم key نہیں۔ یہ آپ کی مشین سے کبھی باہر نہیں جاتا۔
اب stack۔ اسے docker-compose.yml کی شکل میں save کریں:
services:
vllm:
image: vllm/vllm-openai:latest
command: >
--model Qwen/Qwen3-8B
--enable-auto-tool-choice
--tool-call-parser hermes
--reasoning-parser qwen3
volumes:
- ./hf-cache:/root/.cache/huggingface
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
postgres:
image: postgres:16
environment:
POSTGRES_DB: litellm
POSTGRES_USER: litellm
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- ./pgdata:/var/lib/postgresql/data
litellm:
# Pin the version. Read the security note below before you change this.
image: ghcr.io/berriai/litellm:main-v1.80.5
depends_on: [vllm, postgres]
ports:
- "4000:4000"
environment:
LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}
DATABASE_URL: postgresql://litellm:${POSTGRES_PASSWORD}@postgres:5432/litellm
volumes:
- ./litellm-config.yaml:/app/config.yaml
command: ["--config", "/app/config.yaml", "--port", "4000"]
open-webui:
image: ghcr.io/open-webui/open-webui:main
depends_on: [litellm]
ports:
- "3000:8080"
environment:
OPENAI_API_BASE_URL: http://litellm:4000/v1
OPENAI_API_KEY: ${LITELLM_MASTER_KEY}
volumes:
- ./webui-data:/app/backend/data
اپنی دو secrets اس کے پاس .env فائل میں رکھیں, compose فائل میں کبھی نہیں:
LITELLM_MASTER_KEY=sk-choose-a-long-random-string
POSTGRES_PASSWORD=choose-another-long-random-string
پھر اسے up کر کے ثابت کریں کہ یہ کام کرتا ہے:
docker compose up -d
curl http://localhost:4000/v1/chat/completions \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "qwen3-8b", "messages": [{"role": "user", "content": "Say hello in one line."}]}'
اس درخواست کو تصور 9 والی درخواست کے پاس دیکھیں۔ ایک ہی shape, ایک ہی /v1/chat/completions, ایک نئی line: Authorization header۔ یہی single header سرور اور service کے درمیان پورا difference ہے۔ اب کسی کو بتانا پڑتا ہے کہ وہ کون ہے۔
مارچ 2026 میں LiteLLM package supply chain attack کا target بنا اور malicious releases ہٹائے جانے سے پہلے باہر چلی گئیں۔ آپ کا gateway کلاؤڈ کی ہر key اور ہر spending record رکھتا ہے, اس لیے یہ stack کا highest-value target ہے۔ اس لیے exact version tag pin کریں, latest کبھی track نہ کریں, move کرنے سے پہلے release notes پڑھیں اور دونوں کام کرنے تک gateway کو public internet سے دور رکھیں۔ یہ LiteLLM-specific warning نہیں ہے۔ Credentials رکھنے والی کوئی بھی service run کرنے کا یہی مطلب ہے۔
ڈرائیور اور CUDA mismatches عام وجہ ہیں, اور اسی وجہ compose فائل pip install کی جگہ official image use کرتی ہے۔ Host پر NVIDIA Container Toolkit بھی installed چاہیے, ورنہ Docker کے اندر GPU دکھائی نہیں دے گا۔ 16 GB card ہے, تو تصور 9 کی طرح ماڈل line کو Qwen/Qwen3-8B-FP8 سے swap کریں۔
تصور A3 تب done ہے جب: docker compose up -d four containers کو up کرے, port 4000 سے curl جواب لوٹائے اور Authorization header کے بغیر وہی درخواست refuse ہو۔
تصور A4: کیز بانٹیں۔ بجٹ، حدود اور خرچ کا ریکارڈ
یہی تصور اسے کلاؤڈ بناتا ہے۔ اس سے پہلے کی ہر چیز plumbing تھی۔
ایک طالب علم کے لیے key generate کریں:
curl -X POST http://localhost:4000/key/generate \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{
"user_id": "student-0417",
"models": ["qwen3-8b"],
"max_budget": 2.00,
"budget_duration": "30d",
"rpm_limit": 20
}'
چاروں سیٹنگز پڑھیں, کیونکہ ہر ایک decision ہے جو آپ جان بوجھ کر لے رہے ہیں:
user_idہر future درخواست اور ہر logged dollar کو ایک شخص سے جوڑتا ہے۔ اس کے بغیر usage report ایک بڑا anonymous number ہے۔modelsوہ menu ہے جس سے یہ key order کر سکتی ہے۔ صرفqwen3-8blist کرنے والی key کسی اور چیز تک نہیں پہنچ سکتی, چاہے طالب علم کچھ بھی type کرے۔max_budgetکے ساتھbudget_durationcap ہے۔ دو ڈالر a مہینہ, پھر gateway refuse کرنا شروع کرتا ہے۔ Runaway loop رات میں, آپ کو جگائے بغیر, اپنے آپ رک جاتا ہے۔rpm_limitایک enthusiastic طالب علم کو باقی سب کے لیے queue بھرنے سے روکتا ہے۔
جواب ایسی key کے ساتھ لوٹتا ہے جو sk- سے شروع ہوتی ہے۔ طالب علم کو صرف وہی string ملتی ہے۔ اور کچھ نہیں۔
اب وہ moment جس کے لئے یہ پورا ضمیمہ ہے۔ طالب علم آپ کا کلاؤڈ ٹھیک اسی طرح use کرتا ہے جیسے حصہ 3 نے OpenRouter use کیا تھا۔ وہی دو سیٹنگز, نیا پتہ:
# OpenCode, or anything speaking the OpenAI shape
export OPENAI_BASE_URL="http://your-server:4000/v1"
export OPENAI_API_KEY="sk-the-students-key"
ہارنس کو کبھی پتا نہیں چلتا کہ کچھ بدلا ہے۔ یہ اب بھی ہارنس plus برین plus پتہ ہے, اور اب پتہ آپ کی اپنی building کی ایک مشین ہے۔
خاص تور پر Claude Code کے لیے LiteLLM Anthropic-format endpoint بھی expose کرتا ہے, جس سے ANTHROPIC_BASE_URL کو direct اپنے gateway پر point کر سکتے ہیں, وہی bare-address move جو تین بار پہلے کر چکے ہیں۔ وہ surface اس صفحہ کے track کر سکنے سے faster move کرتا ہے, اس لیے اس پر منحصر ہونے سے پہلے live LiteLLM docs check کریں۔ Pinned version پر یہ کام نہ کرے, تو تصور 16 کا Claude Code Router ایک extra hop سے وہاں پہنچا دیتا ہے اور gateway اس کی config میں صرف ایک اور provider بن جاتا ہے۔
کلاس live ہونے کے بعد یہ دو کمانڈز لگاتار use کریں گے:
# What has this key spent?
curl -X GET "http://localhost:4000/key/info?key=sk-the-students-key" \
-H "Authorization: Bearer $LITELLM_MASTER_KEY"
# Semester over, or laptop lost.
curl -X POST http://localhost:4000/key/delete \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{"keys": ["sk-the-students-key"]}'
ہر diner کو spending limit کے ساتھ اپنا جدول number ملتا ہے۔ Kitchen بالکل نہیں بدلی۔ لیکن اب جانتے ہیں کون کھا رہا ہے, ایک جدول کو پورا menu order کرنے سے روک سکتے ہیں اور کسی کے جانے پر اس کی جدول واپس لے سکتے ہیں۔
آپ دو hundred طالب علم keys issue کرتے ہیں, ہر ایک پر دو ڈالر a مہینہ کی cap ہے اور سب آپ کے اپنے GPU کی طرف point کرتی ہیں۔ Colleague پوچھتا ہے مقامی ماڈل کی per ٹوکن کوئی لاگت نہیں, تو بجٹس کی پریشانی کیوں لی۔ حقیقی جواب کیا ہے? دو جوابات ہیں اور دوسرا important ہے۔ پہلا, مقامی میں بھی "مفت" غلط ہے: آپ کے GPU کی fixed تھروپٹ ہے, ٹھیک جیسا حصہ 2 کی curve نے card بھرنے پر دکھایا تھا, اس لیے money move نہ ہونے پر بھی ایک طالب علم کا endless loop باقی سب کی capacity spend کر رہا ہے۔ بجٹ shared resource کو ration کرتا ہے۔ دوسرا, اور تصور A5 یہیں جاتا ہے, menu میں کلاؤڈ ماڈل جوڑتے ہی انہیں keys سے حقیقی money flow ہوتا ہے۔ مفت رہتے ہوئے بجٹ habit set کرنے کا مطلب ہے کہ مفت ہونا بند ہونے والے دن panic میں اسے نہیں بنا رہے۔جواب دیکھیں
تصور A4 تب done ہے جب: الگ مشین پر دوسرے شخص نے اپنی key سے آپ کے gateway کے through حقیقی کام run کیا, آپ نے دیکھا کہ اس نے کتنا spend کیا اور بعد میں key revoke کر دی۔
تصور A5: تینوں درجے ایک دروازے کے پیچھے رکھیں
آپ کا کلاؤڈ ابھی ایک برین offer کرتا ہے۔ اب کورس کے دوسرے دو درجے کو اسی menu میں جوڑیں, تاکہ طالب علم ماڈل name بدل کر درجہ چنے اور کچھ نہیں۔
litellm-config.yaml extend کریں:
model_list:
# Tier 2: your own GPU. Free at the margin, capped by your hardware.
- model_name: qwen3-8b
litellm_params:
model: hosted_vllm/Qwen/Qwen3-8B
api_base: http://vllm:8000/v1
api_key: "not-needed"
# Tier 3: a frontier brain, rented. Your key, never theirs.
- model_name: frontier
litellm_params:
model: openrouter/moonshotai/kimi-k3
api_key: os.environ/OPENROUTER_API_KEY
# Tier 3, the cheap end. The right default for high-volume work.
- model_name: frontier-cheap
litellm_params:
model: openrouter/deepseek/deepseek-v4-pro
api_key: os.environ/OPENROUTER_API_KEY
router_settings:
fallbacks:
- qwen3-8b: ["frontier-cheap"]
ابھی تین things ہوئیں اور ہر ایک اپنا sentence deserve کرتی ہے۔
آپ کی OpenRouter key مشین سے کبھی باہر نہیں جاتی۔ دو hundred طلبہ اب Kimi K3 تک پہنچ سکتے ہیں اور ان میں سے کسی کے پاس ایسا credential نہیں جو public repository میں paste ہو سکے۔ ان کے پاس آپ کی gateway key ہے, جسے ایک کمانڈ میں revoke کر سکتے ہیں اور جو اپنی cap سے آگے spend نہیں کر سکتی۔ تصور 14 نے warn کیا تھا کہ OpenRouter key ایک string میں secret اور wallet دونوں ہے۔ String دیے بغیر wallet share کرنے کا یہی طریقہ ہے۔
درجہ انتخاب ماڈل name بن گئی۔ مشکل refactor کے لیے فرنٹیئر برین چاہنے والا طالب علم frontier type کرتا ہے, qwen3-8b کی جگہ۔ یہ تصور 15 کی three-question procedure کو ایسی چیز میں بدلتا ہے جسے شخص کام کے درمیان سچ میں کر سکتا ہے۔
Fallback line policy ہے۔ آپ کا GPU down یا full ہو, تو qwen3-8b کی درخواستیں fail ہونے کی جگہ خاموشی سے frontier-cheap پر جاتی ہیں۔ یہ حقیقی trade ہے جسے آپ جان بوجھ کر چن رہے ہیں: money سے خریدی availability۔ اسے ایسی جگہ لکھیں جہاں future self پائے, کیونکہ بھولا ہوا fallback ایسا بل ہے جسے سمجھ نہیں پائیں گے۔
اب فرنٹیئر menu کو الگ limits دیں, کیونکہ اس کی لاگت حقیقی money ہے:
curl -X POST http://localhost:4000/key/generate \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{
"user_id": "student-0417-frontier",
"models": ["qwen3-8b", "frontier-cheap", "frontier"],
"max_budget": 5.00,
"budget_duration": "30d"
}'
پیچھے ہٹ کر دیکھیں کہ کیا بنایا۔ ایک پتہ۔ اس کے پیچھے آپ کے اپنے ہارڈویئر پر ماڈل اور ایسے کلسٹرز کے ماڈلز جنہیں room میں کوئی کبھی own نہیں کر سکتا, ایک ہی menu پر offer ہوتے ہیں, ایک ہی caps کے against billed ہوتے ہیں اور ایک ہی دو سیٹنگز سے پہنچتے ہیں۔ تصور 2 نے سکھایا تھا کہ برین صرف پتہ ہے۔ یہ اسی sentence کو الٹا پڑھنا ہے: ایک پتہ کتنے بھی برینز چھپا سکتا ہے, اور ان کے درمیان انتخاب اب کسی کی config فائل ہے۔ آپ کی۔
آپ کا fallback failed تقریباً sixty گھنٹے تک ہر وہ درخواست جو مفت ہوتی, paid کلاؤڈ ماڈل پر run ہوئی اور service perfectly کام کرتی رہی, اور ٹھیک اسی وجہ کسی کو پتا نہیں چلا۔ Fallbacks silently money کو availability سے trade کرتے ہیں, اور silence ہی danger ہے۔ دو things add کریں: vLLM container unhealthy ہونے پر alert اور gateway پر spending alert۔ Fix fallback ہٹانا نہیں ہے۔ یہ یقینی کرنا ہے کہ کچھ منٹ سے longer fallback کسی کو بتائے۔qwen3-8b درخواستوں کو frontier-cheap پر بھیجتا ہے۔ Friday evening کو driver update کے لیے GPU مشین reboot ہوتی ہے اور Monday تک کسی کو پتا نہیں چلتا۔ Weekend میں کیا ہوا اور کیا add کرنا چاہیے?جواب دیکھیں
تصور A5 تب done ہے جب: ایک key مقامی ماڈل اور فرنٹیئر ماڈل دونوں تک name سے پہنچے اور سمجھا سکیں کہ fallback rule کیا خریدتا ہے اور اس کی لاگت کیا ہے۔
تصور A6: نگرانی کریں۔ صحت بتانے والے تین اعداد
جس service کو کوئی watch نہیں کر رہا, وہ quietly fail ہوتی ہے۔ vLLM اپنے numbers http://localhost:8000/metrics پر اس format میں publish کرتا ہے جسے Prometheus پڑھتا ہے, اور standard تصویر Prometheus کا انہیں collect کرنا تتھا Grafana کا انہیں draw کرنا ہے۔
دن ایک پر اس کی ضرورت نہیں۔ یہ جاننا ضروری ہے کہ کون-سے تین numbers matter کرتے ہیں, کیونکہ طالب علم سے پہلے وہ بتاتے ہیں کہ غلط کیا ہے:
- اصطلاح Queue depth: کتنی درخواستیں wait کر رہی ہیں۔ یہ آپ کا single most useful number ہے, اور حصہ 2 experiment live gauge بن گیا ہے۔ Near zero کا مطلب مشین آسانی سے چل رہی ہے۔ چڑھ کر اوپر رہنے کا مطلب GPU ختم ہو گیا, اور second card, smaller ماڈل یا class پر honest limit کا وقت ہے۔
- اصطلاح Time to first ٹوکن: کچھ دکھائی دینے سے پہلے صارف کتنی دیر wait کرتا ہے۔ ہر individual شخص کا experience خراب ہونے پر بھی تھروپٹ wonderful دکھ سکتا ہے۔ طلبہ اصل میں یہی number feel کرتے ہیں اور total tokens-per-second figure ٹھیک اسی کو چھپاتا ہے۔
- اصطلاح Use میں GPU memory۔ Compute سے پہلے memory بھرتی ہے اور بھرنے پر, کچھ broken دکھنے سے پہلے کارکردگی گرتی ہے۔ Node کی ساری memory quietly use کرتا ماڈل سب کا experience degrade کرتا ہے, جبکہ ہر container اب بھی healthy report کرتا ہے۔
ان کے ساتھ دو things اور بیٹھتی ہیں۔ Gateway کا اپنا spending dashboard, جہاں unexpected بل کو مہینہ end کی جگہ جلدی پکڑتے ہیں۔ اور دونوں containers پر plain health check, کیونکہ "کیا یہ up ہے" ایسا سوال ہے جس کا جواب مشین سے تین in the morning چاہیے, طالب علم کے message سے نہیں۔
قطار depth door کی line ہے۔ Time to first ٹوکن وہ time ہے جتنا ہر diner food کے لیے wait کرتا ہے۔ GPU memory بتاتی ہے کچن کتنی full ہے۔ صرف total meals served دیکھتا ریستوراں owner سب سے آخر میں جانتا ہے کہ جگہ بکھر رہی ہے۔
تصور A6 تب done ہے جب: اپنی آنکھوں سے vLLM container پر /metrics load کیا ہو اور بتا سکیں کہ طالب علم کے "آج آہستہ feel ہو رہا ہے" کہنے پر تین numbers میں پہلے کون سا check کریں گے۔
تصور A7: یہ کب مفید ہے اور کب آگے بڑھنا ہے
تصورات 7, 12 اور 15 کی spirit میں honest accounting۔
Mini کلاؤڈ تب بنائیں جب:
- آپ کے پاس کئی صارفین اور ایک بجٹ ہے۔ کلاس, bootcamp, department, چھوٹا کمپنی۔ پچاس لوگ کو serve کرتا ایک GPU ان میں سے کسی کو ملنے والا cheapest capable setup ہے, اور gateway "پچاس لوگ" کو chaotic کی جگہ safe بناتا ہے۔
- ڈیٹا باہر نہیں جا سکتا۔ تصور 15 کا first سوال organizational پیمانہ پر answered, ساتھ میں institution کے لیے matter کرنے والا extra piece: کس نے کیا access کیا دکھانے والی audit trail۔
- اصطلاح Moving world کے آگے ایک stable پتہ چاہیے۔ ماڈلز, قیمتیں اور providers ہر few weeks بدلتے ہیں۔ طلبہ gateway پر point کریں, تو دو hundred لوگوں سے سیٹنگز بدلوانے کی جگہ config فائل میں وہ churn absorb کرتے ہیں۔
- اصطلاح Loops پورے دن run کرتے ہیں۔ بعد میں ملنے والے Loop Engineering agents ہمیشہ درخواستیں fire کرتے ہیں۔ Per-token بل پر وہ addition کبھی نہیں رکتا۔ پہلے سے owned اور saturated GPU پر ایک اور درخواست کی extra لاگت تقریباً کچھ نہیں ہے۔
اسے تب نہ بنائیں جب:
- آپ ایک شخص ہیں۔ پورا front of house آپ ہیں۔ تصور 11 کی طرح direct vLLM use کریں اور یہ ضمیمہ skip کریں۔
- اصطلاح Traffic چھوٹا اور occasional ہے۔ Idle GPUs کی لاگت busy ones جتنی ہی ہے۔ حقیقی daily traffic volume سے نیچے حصہ 3 کے through rent کرنا money اور weekends دونوں پر جیتتا ہے, اور بہت بڑے margin سے جیتتا ہے۔
- کوئی اسے own نہیں کرتا۔ یہ وہ failure ہے جسے کوئی plan نہیں کرتا۔ Mini کلاؤڈ service ہے اور ٹوٹنے پر services کو responsible شخص چاہیے۔ وہ شخص موجود نہ ہو, تو holiday پر پہلی بار down ہوتے ہی چیز مرتی ہے اور سب کا trust ختم ہوتا ہے۔
Docker Compose سے آگے کب graduate کریں۔ اوپر کا compose stack حقیقی service ہے اور surprising number of طلبہ کو carry کرے گا, لیکن یہ ہر چیز کی ایک copy والی ایک مشین ہے۔ اس میں autoscaling اور کسی چیز کی second copy نہیں۔ اسے outgrow کرنے پر rewrite نہیں کرتے: ایک ہی pieces کو Kubernetes پر move کرتے ہیں۔ دو paths کے names جاننا مفید ہے۔ vLLM production stack metrics, dashboards اور cache reuse پہلے سے wired Helm chart دیتا ہے۔ KubeAI آگے جاکر ماڈلز کو Kubernetes resources کی طرح manage کرتا ہے, نیچے vLLM اور Ollama run کرتا ہے اور chat UI bundle کرتا ہے, اس لیے اس ضمیمہ کا بڑا حصہ دو Helm installs میں collapse ہو جاتا ہے۔ ان میں سے کوئی gateway replace نہیں کرتا, کیونکہ کوئی per-user keys اور بجٹس نہیں کرتا۔ وہ پرت ٹھیک وہیں رہتی ہے جہاں رکھی تھی۔
واضح limit, اور وہی جس پر حصہ 2 ختم ہوا۔ Gateway کسی رکاوٹ کو move نہیں کرتا۔ یہ تھروپٹ improve نہیں کرتا اور برین کو smarter نہیں بناتا۔ یہ تیز برین کو shareable بناتا ہے, جو الگ طرح کی win ہے اور اکثر وہی طے کرتی ہے کہ room بھر لوگ AI use کر پائیں گے یا نہیں۔
ایک شعبہ forty staff کے لیے private AI service چاہتا ہے۔ کوئی direct autoscaling اور multi-node سروس والے Kubernetes پر جانے کا proposal دیتا ہے, "تاکہ بعد میں دوبارہ نہ کرنا پڑے۔" اس کے against argument کیا ہے? چالیس صارفین اسے comfortably fit ہوتے ہیں جسے Docker Compose کے پیچھے ایک GPU serve کر سکتا ہے, اس لیے Kubernetes آج setup کے weeks اور permanent operational burden کی لاگت پر کچھ نہیں خریدتا۔ Upgrade path rewrite بھی نہیں: load justify کرے تو وہی containers, وہی gateway config اور وہی ماڈل Helm charts پر move ہوتے ہیں۔ اس مہینہ کام کرنے والی چیز بنائیں, حقیقی traffic measure کریں اور measurement کو decide کرنے دیں کہ graduate کب کرنا ہے۔ درست سوال "کیا اسے outgrow کریں گے" نہیں بلکہ "اس کے ٹوٹنے پر on call کون ہے" ہے۔جواب دیکھیں
تصور A7 تب done ہے جب: اپنی situation کے لیے دونوں sides argue کر سکیں اور gateway کی improve نہ کی جانے والی ایک thing بتا سکیں۔
ضمیمہ A ایک سطر میں
استنتاجی engine ٹوکنز serve کرتا ہے اور gateway لوگوں کو serve کرتا ہے, اور mini LLM کلاؤڈ صرف وہ دو پروگرامز اور keys رکھنے کی جگہ ہے۔ اسے تب بنائیں جب کئی mouths ایک بجٹ share کریں۔ اور notice کریں کہ اصل میں کیا کیا ہے: آپ کے پتے پر point کرنے والے ہر شخص کے لیے اب آپ کلاؤڈ ہیں۔
حوالہ جات
اس صفحہ کے کمانڈز کے primary sources یہ ہیں۔ وہ تیزی سے move کرتے ہیں, اس لیے کسی specific flag, قیمت یا version پر depend ہونے سے پہلے live docs check کریں۔
حصہ 1: مقامی (Ollama)
- حوالہ: Ollama, desktop ایپ (ماڈل download اور chat کریں, terminal کے بغیر)۔ https://ollama.com/blog/new-app اور https://ollama.com/download
- حوالہ: Ollama,
ollama launch(مقامی ماڈل پر کوڈنگ ایجنٹ wire اور launch کرنے کے لیے ایک کمانڈ)۔ https://ollama.com/blog/launch اور https://docs.ollama.com/integrations/claude-code - حوالہ: Ollama, Anthropic API compatibility (native endpoint جو no-proxy setup possible بناتا ہے)۔ https://ollama.com/blog/claude
- حوالہ: Ollama, context length اور
num_ctx، VRAM-based defaults اور کوڈنگ ایجنٹس کے لیے 64K guidance۔ https://docs.ollama.com/context-length - حوالہ: Claude Code, Environment variables,
ANTHROPIC_BASE_URL,ANTHROPIC_AUTH_TOKENاورAPI_TIMEOUT_MSکے لیے۔ https://code.claude.com/docs/en/env-vars - حوالہ: OpenCode, Providers,
opencode.jsonprovider block اور OpenAI-compatible endpoint کے لیے۔ https://opencode.ai/docs/providers/ - حوالہ: Skills installer اور GitHub CLI
gh skillکمانڈز, skills install اور publish کرنے کے لیے۔ https://skills.sh/docs
حصہ 2: سرور (vLLM)
- حوالہ: vLLM, documentation home (installing,
vllm serveاور OpenAI-compatible سرور)۔ https://docs.vllm.ai - حوالہ: vLLM, ٹول کالنگ,
--enable-auto-tool-choiceاور per ماڈل خاندان tool-call parser کے لیے۔ https://docs.vllm.ai/en/latest/features/tool_calling/ - حوالہ: vLLM, Claude Code integration, Anthropic Messages support اور
ANTHROPIC_DEFAULT_*_MODELvariables کے لیے۔ https://docs.vllm.ai/en/latest/serving/integrations/claude_code/ - حوالہ: Qwen, vLLM deployment guide, Qwen3 ماڈلز serve کرنے اور recommended parsers کے لیے۔ https://qwen.readthedocs.io/en/latest/deployment/vllm.html
حصہ 3: کلاؤڈ (OpenRouter)
- حوالہ: OpenRouter, Claude Code integration, environment variables اور Anthropic-compatible endpoint کے لیے۔ https://openrouter.ai/docs/cookbook/coding-agents/claude-code-integration
- حوالہ: OpenRouter, Kimi K3 ماڈل صفحہ, live slug, قیمت اور providers کے لیے۔ https://openrouter.ai/moonshotai/kimi-k3
- حوالہ: OpenRouter, DeepSeek V4 Pro ماڈل صفحہ, live slug, قیمت اور providers کے لیے۔ https://openrouter.ai/deepseek/deepseek-v4-pro
- حوالہ: Moonshot AI, Kimi K3 technical blog, architecture, سیاق کھڑکی اور سروس recommendations کے لیے۔ https://www.kimi.com/blog/kimi-k3
- حوالہ: DeepSeek, API pricing, current V4 Pro rates اور cache-hit pricing کے لیے۔ https://api-docs.deepseek.com
تصور 16: Claude Code Router
- حوالہ: Claude Code Router, router install کرنے,
ProvidersاورRouterconfig, transformers اورccrکمانڈز کے لیے۔ https://github.com/musistudio/claude-code-router
ضمیمہ A: Mini LLM کلاؤڈ
- حوالہ: LiteLLM, proxy سرور documentation, config فائل, virtual keys, بجٹس اور rate limits کے لیے۔ https://docs.litellm.ai/docs/simple_proxy
- حوالہ: LiteLLM, virtual keys,
/key/generate,/key/info,/key/deleteاور per-key ماڈل access کے لیے۔ https://docs.litellm.ai/docs/proxy/virtual_keys - حوالہ: LiteLLM, بجٹس اور rate limits,
max_budget,budget_durationاورrpm_limitکے لیے۔ https://docs.litellm.ai/docs/proxy/users - حوالہ: LiteLLM, reliability اور fallbacks,
router_settingsfallback rules کے لیے۔ https://docs.litellm.ai/docs/proxy/reliability - حوالہ: vLLM, Docker deployment, official
vllm/vllm-openaiimage اور GPU runtime flags کے لیے۔ https://docs.vllm.ai/en/latest/deployment/docker.html - حوالہ: vLLM, production metrics, Prometheus endpoint, queue depth اور time to first ٹوکن کے لیے۔ https://docs.vllm.ai/en/latest/serving/metrics.html
- حوالہ: vLLM, production stack, Kubernetes upgrade path کے routing, metrics اور dashboards والا Helm chart۔ https://github.com/vllm-project/production-stack
- حوالہ: KubeAI, Kubernetes کے لیے AI inference operator, vLLM اور Ollama پر ماڈلز کو Kubernetes resources کی طرح manage کرنے کے لیے۔ https://www.kubeai.org
- حوالہ: Open WebUI, documentation, chat interface اور OpenAI-compatible endpoint سے connect کرنے کے لیے۔ https://docs.openwebui.com
- حوالہ: NVIDIA, Container Toolkit installation guide, Docker کے اندر GPU access کے لیے required۔ https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html