Ollama یا vLLM؟ ایک صارف میں سہولت، بوجھ پر رفتار فیصلہ بدلتی ہے

ایک صارف کے مقامی تجربے یا مختصر API نمونے کے لیے Ollama کی سادہ ترتیب عموماً بہتر انتخاب ہے؛ متعدد بیک وقت درخواستوں کی خدمت میں vLLM کی رفتار زیادہ اہم ہو جاتی ہے۔ Red Hat کی تقابلی آزمائش بھی مقامی نمونہ سازی کے لیے Ollama کی سہولت اور زیادہ بوجھ پر vLLM کی بہتر کارکردگی دکھاتی ہے۔ اس کا مطلب یہ نہیں کہ ہر کمپیوٹر پر ایک ہی نظام تیز ترین جواب دے گا۔

فیصلہ اس بات سے شروع ہوتا ہے کہ درخواستیں کیسے آتی ہیں۔ اکیلے ڈویلپر کو ماڈل چلانے اور جواب شروع ہونے کا انتظار محسوس ہوتا ہے؛ مشترکہ API پر انہی درخواستوں کے ساتھ قطار، تاخیر اور فی سیکنڈ مکمل ہونے والے کام کا حساب بھی جڑ جاتا ہے۔ اسی لیے واحد صارف کی رفتار کو سرور کی گنجائش، یا زیادہ بوجھ کی مجموعی رفتار کو مقامی استعمال کی سہولت کا بدل نہیں سمجھنا چاہیے۔

شائع شدہ بوجھ کی آزمائش سے کیا معلوم ہوتا ہے؟

شائع شدہ تقابلی تحقیق میں ایک NVIDIA H100 پر Qwen3-4B کے سوال و جواب کا بوجھ چلایا گیا: ۱۰۰ بیک وقت درخواستوں کی سطح پر vLLM نے ۱۵٫۲۰ اور Ollama نے ۰٫۴۵ کامیاب درخواستیں فی سیکنڈ مکمل کیں، جبکہ Ollama کی ۳۹٫۲۹ فیصد درخواستیں مقررہ وقت میں مکمل نہ ہوئیں؛ اس ترتیب میں Ollama کے Q8_0 وزن اور FP16 کیش کے مقابلے میں vLLM کے FP8 وزن اور کیش تھے، اور دونوں کی فعال درخواستوں کی حد بھی الگ تھی۔ یہ اعداد اسی ہارڈویئر اور پوری خدمت کی ترتیب کا نتیجہ ہیں۔

ماڈل کا نام اور سوالات ملتے ہوں تب بھی وزن محفوظ کرنے کا طریقہ، کیش کی درستگی اور بیک وقت فعال درخواستوں کی حد نتیجہ بدل سکتے ہیں۔ تحقیق اس بات کا مضبوط اشارہ دیتی ہے کہ بھاری سرور بوجھ کے لیے vLLM کو سنجیدگی سے جانچنا چاہیے؛ اسے دونوں پروگراموں کی خالص رفتار کا ایسا مستقل تناسب نہیں بنایا جا سکتا جو دوسرے GPU یا دوسری ترتیب پر بھی برقرار رہے۔ خاص طور پر قطار میں رکی درخواست کا طویل انتظار، متن بننا شروع ہونے کے بعد کی رفتار سے الگ مسئلہ ہے۔

مقامی تجربے میں سہولت کا فائدہ کہاں ہے؟

اگر مقصد اپنے کمپیوٹر پر ماڈل آزمانا، سوالات بدلنا یا ایک چھوٹا API نمونہ تیار کرنا ہے تو مختصر ترتیب خود ایک عملی فائدہ ہے۔ اس استعمال میں زیادہ صارفین کو اکٹھا جواب دینے کی گنجائش تب تک فائدہ نہیں دیتی جب تک واقعی بیک وقت ٹریفک نہ ہو۔ Ollama کی طرف جھکاؤ اسی محدود کام کے لیے ہے؛ اسے کم ترین تاخیر کی ضمانت سمجھ کر منتخب کرنا درست نہیں ہوگا۔

مقامی پیمائش میں پہلی درخواست اور پہلے سے چلتے ماڈل کی درخواست الگ رکھنی چاہیے۔ پہلی بار وزن میموری میں آنے کا وقت جواب کے انتظار میں شامل ہو سکتا ہے، جبکہ گرم ماڈل کے ساتھ وہ مرحلہ گزر چکا ہوتا ہے۔ اگر نمونے میں ماڈل بار بار بدلا جاتا ہے تو لوڈ ہونے کا وقت اہم ہے؛ مستقل API خدمت میں منتخب ماڈل کے گرم رہنے کے بعد کی تاخیر زیادہ متعلق ہوگی۔ دونوں حالتوں کا اوسط ملا دینے سے اصل استعمال کا تجربہ دھندلا جاتا ہے۔

بیک وقت درخواستوں میں میموری اور قطار کا کردار

Ollama کی سرکاری رہنمائی کے مطابق کافی میموری ہو تو ایک ماڈل متوازی درخواستیں چلا سکتا ہے؛ اضافی متوازی کام کانٹیکسٹ کے لیے درکار میموری بڑھاتا ہے، نئی ماڈل درخواست میموری نہ ملنے پر قطار میں جاتی ہے، اور بھری ہوئی قطار کے بعد درخواست مسترد بھی ہو سکتی ہے۔ یوں Ollama کو صرف ایک صارف تک محدود کہنا غلط ہے، لیکن متوازی درخواستوں کی تعداد بڑھانا میموری اور انتظار کی قیمت کے بغیر ممکن نہیں۔

قطار کا اثر پہلے ٹوکن تک وقت میں نمایاں ہوتا ہے۔ ایک فعال درخواست کے لیے متن مناسب رفتار سے نکل سکتا ہے جبکہ دوسری درخواستیں اپنی باری کی منتظر ہوں۔ اس لیے متن شروع ہونے کے بعد ٹوکن نکلنے کی رفتار، پہلے ٹوکن کا انتظار اور کامیابی سے مکمل ہونے والی درخواستوں کی تعداد الگ پیمانے ہیں۔ اگر مشترکہ خدمت میں پہلے ٹوکن کا انتظار مسلسل بڑھتا ہے تو اچھی مجموعی ٹوکن رفتار بھی صارف کے خراب تجربے کو چھپا سکتی ہے۔

ویڈیو میموری کو بھی صرف ماڈل کے وزن تک محدود نہ سمجھیں۔ طویل سوال، بڑا کانٹیکسٹ اور زیادہ فعال درخواستیں چلتے وقت اضافی جگہ مانگتی ہیں۔ ایک ترتیب میں ماڈل آرام سے لوڈ ہو جانا اس بات کا ثبوت نہیں کہ وہ متوقع بیک وقت بوجھ بھی اسی میموری میں سنبھال لے گا۔ جو نظام حد تک پہنچنے پر کام کو قطار میں روکتا ہے، اس کی ناکامی محض سست جواب نہیں بلکہ بعد میں آنے والی درخواستوں کے انتظار یا انکار کی صورت میں بھی ظاہر ہو سکتی ہے۔

یکساں بوجھ کا قابلِ تکرار خاکہ

اپنے ہارڈویئر پر موازنہ کرتے وقت دونوں نظام باری باری ایک ہی مشین پر چلائیں اور ہر دور کے لیے ایک ہی ماڈل کا نسخہ، سوالات، ان پٹ ٹوکن، جواب کی حد، کانٹیکسٹ اور نمونہ سازی کی ترتیبات درج کریں۔ وزن اور کیش کی کوانٹائزیشن حقیقتاً یکساں رکھ سکیں تو بہتر ہے؛ اگر دونوں نظام ایک ہی شکل قبول نہ کریں تو فرق صاف لکھیں۔ صرف ماڈل کے نام یا بٹوں کی ملتی ہوئی گنتی سے مساوی آزمائش قائم نہیں ہوتی۔

• ایک صارف کا دور، متوقع بیک وقت ٹریفک کا دور اور اچانک اضافے کا دور الگ چلائیں۔ ہر دور میں درخواستوں کی آمد کی رفتار اور آزمائش کا دورانیہ ایک جیسا رکھیں۔
• ہر سوال کے ان پٹ ٹوکن اور جواب کی زیادہ سے زیادہ حد یکساں مقرر کریں۔ اصل پیدا ہونے والے ٹوکن بھی محفوظ کریں، کیونکہ مختصر جواب بظاہر تیزی پیدا کر سکتا ہے۔
• پہلے ٹوکن تک درمیانی اور زیادہ تاخیر، پورا جواب آنے کا وقت، کامیاب درخواستیں فی سیکنڈ، مجموعی پیدا شدہ ٹوکن، ناکامیاں اور استعمال شدہ ویڈیو میموری الگ دکھائیں۔
• ماڈل لوڈ ہونے والی پہلی درخواست کو گرم حالت کی درخواستوں سے الگ ناپیں۔ اگر جانچ کا کلائنٹ خود درخواستیں روکتا ہے تو اس کا انتظار بھی سرور کی قطار سے الگ درج کریں۔

vLLM کی بنچ مارک رہنمائی درخواستوں کی آمد کی رفتار، آمد میں اچانک اضافے اور زیادہ سے زیادہ بیک وقت درخواستوں کو الگ قابو کرنے کے اختیارات دیتی ہے؛ کلائنٹ کی اپنی حد سے پیدا ہونے والا قطار کا وقت بھی رپورٹ کیا جا سکتا ہے۔ یہی بیرونی بوجھ دونوں سروروں کو بھیجنے سے معلوم ہوتا ہے کہ فرق سرور کے رویے میں ہے یا آزمائش بھیجنے والے کلائنٹ میں۔ یکساں اوسط آمد کے باوجود اچانک آنے والی درخواستیں زیادہ قطار بنا سکتی ہیں، اس لیے دونوں صورتوں کے نتائج الگ رکھیں۔

انتخاب کس نتیجے پر کریں؟

واحد صارف کے لیے پہلے یہ دیکھیں کہ مطلوبہ ماڈل دستیاب میموری میں چلتا ہے، جواب کا انتظار قابلِ قبول ہے اور ترتیب روزمرہ تجربے میں آسان رہتی ہے۔ مختصر API نمونے میں ان شرائط کے ساتھ Ollama کا سہولت والا فائدہ فیصلہ کن ہو سکتا ہے۔ اگر اسی مشین اور اسی کام پر vLLM بہتر عملی نتیجہ دے تو انتخاب بدل سکتا ہے؛ شائع شدہ سرور آزمائش اکیلے مقامی فاتح طے نہیں کرتی۔

متعدد صارفین کے لیے وہ ترتیب موزوں ہے جو متوقع آمد پر درخواستیں مکمل کرے، پہلے ٹوکن کا انتظار قابو میں رکھے اور میموری کی حد سے نہ ٹکرائے۔ دستیاب بوجھ کی آزمائش vLLM کے حق میں جاتی ہے، مگر اپنے منتخب ماڈل، GPU اور ٹریفک پر قطار اور تاخیر الگ ناپنا ضروری ہے۔ اگر بیک وقت درخواستیں کم ہیں تو سادہ انتظام کی قدر برقرار رہتی ہے؛ جب قطار صارف کے انتظار کو بڑھانے لگے تو سرور کی مجموعی گنجائش فیصلہ بدل دیتی ہے۔

یہ بھی پڑھیں:

• QuickBooks یا Xero؟ پاکستان میں امریکی ٹیکس سہولت قیمت کا فائدہ مٹا سکتی ہے
• امریکی سرکاری بھرتیوں میں AI داخل: آخری فیصلہ پھر بھی انسان کا ہوگا
• TikTok comments میں poll اور آواز آگئی—moderation کا بوجھ بھی بڑھے گا