مقامی لارج لینگویج ماڈلز (LLMs) شروع میں بجلی کی طرح تیز محسوس ہوتے ہیں۔ آپ ایک 7B یا 13B پیرامیٹر والا ماڈل لوڈ کرتے ہیں، ایک مختصر پرامپٹ (prompt) بھیجتے ہیں، اور ٹوکنز (tokens) آرام دہ رفتار سے اسکرین پر نظر آنے لگتے ہیں۔ پھر آپ کوڈ کا ایک لمبا بلاک پیسٹ کرتے ہیں، یا آپ کی چیٹ ہسٹری کئی دور (turns) تک بڑھ جاتی ہے، اور ماڈل کی رفتار رینگنے لگتی ہے۔ یہ رفتار میں کمی شاذ و نادر ہی آہستہ ہوتی ہے۔ یہ ایک اچانک گراوٹ (cliff) کی طرح ہوتی ہے۔ ایک لمحہ پہلے GPU ٹوکنز تیار کر رہا ہوتا ہے؛ اگلے ہی لمحے، آپ کا سسٹم مانیٹر میموری کے دباؤ (memory pressure) میں اضافہ دکھاتا ہے اور ٹوکن کی تخلیق لڑکھڑانے لگتی ہے۔ آپ کسی سادہ فارمولے سے بالکل درست اندازہ نہیں لگا سکتے کہ یہ کب ہوگا۔ آپ کا واحد قابلِ اعتماد رہنما خود ہارڈ ویئر ہے۔

کانٹیکسٹ (Context) کی پوشیدہ قیمت

آپ جو بھی ٹوکن جنریٹ کرتے ہیں وہ KV cache میں اسٹیٹ (state) کا اضافہ کرتا ہے۔ یہ کیش (cache) prefill اور generation کے مراحل کے دوران حساب کیے گئے keys اور values کو محفوظ کرتا ہے، اور یہ آپ کے ماڈل ویٹس (model weights)، attention buffers، اور runtime overhead کے ساتھ میموری میں رہتا ہے۔ 12 GB یا 16 GB VRAM والے عام کنزیومر GPU پر، KV cache آخر کار باقی تمام چیزوں کے ساتھ جگہ کے لیے مقابلہ کرنے لگتا ہے۔ جب مخصوص ویڈیو میموری (dedicated video memory) بھر جاتی ہے، تو آپریٹنگ سسٹم کوئی ایرر (error) دے کر رک نہیں جاتا۔ یہ خاموشی سے اضافی ڈیٹا کو shared memory میں منتقل کر دیتا ہے، اور PCIe bus کے ذریعے GPU اور سسٹم RAM کے درمیان ڈیٹا کا تبادلہ کرتا ہے۔ وہ بس فائل ٹرانسفر کے لیے تو تیز ہے، لیکن گرافکس کارڈ کے اندر موجود میموری بینڈوتھ (memory bandwidth) کے مقابلے میں انتہائی سست ہے۔ اس کا نتیجہ کارکردگی میں معمولی کمی نہیں، بلکہ مکمل تباہی (collapse) ہے۔

تین اشارے کہ رفتار کی گراوٹ (Cliff) آ چکی ہے

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

  • Shared VRAM میں اضافہ۔ یہ وہ میموری ہے جسے GPU ڈرائیور نے مخصوص ویڈیو RAM سے نکال کر ہوسٹ آپریٹنگ سسٹم کے زیرِ انتظام پول (pool) میں منتقل کر دیا ہے۔ جس لمحہ یہ میٹرک زیرو سے اوپر جاتا ہے، سمجھ لیں کہ آپ حد عبور کر چکے ہیں۔
  • System RAM کا استعمال بڑھنا۔ اضافی ڈیٹا کو کہیں نہ کہیں تو جانا ہی ہے، اور وہ جگہ آپ کی مین میموری ہے۔ اگر ماڈل کے ٹوکنز جنریٹ کرنے کے دوران آپ کی RAM کا استعمال بڑھ رہا ہے، تو اس کا مطلب ہے کہ ڈیٹا GPU سے ہٹایا جا رہا ہے۔
  • Eval speed میں آدھی یا اس سے زیادہ کمی۔ 10% کی سست رفتاری کا مطلب تھرمل تھروٹلنگ (thermal throttling) یا بیک گراؤنڈ پروسیسز ہو سکتے ہیں۔ لیکن 50% یا اس سے زیادہ کی کمی کا مطلب ہے کہ رکاوٹ (bottleneck) اب tensor cores سے ہٹ کر میموری بینڈوتھ اور PCIe latency پر منتقل ہو گئی ہے۔ جب آپ دیکھیں کہ جنریشن کی رفتار دو ہندسوں سے گر کر ایک ہندسے پر آ گئی ہے، تو سمجھ لیں کہ آپ پہلے ہی گراوٹ کا شکار ہو چکے ہیں۔

آپ کا فوری بینچ مارک (Benchmark) غالباً جھوٹ بول رہا ہے

ایک مختصر 'سموک ٹیسٹ' آپ کو غلط اعتماد دے سکتا ہے۔ اگر آپ سو ٹوکنز والے پرامپٹ کے ساتھ ماڈل کا بینچ مارک کرتے ہیں، اچھی تھرو پٹ (throughput) دیکھتے ہیں، اور سمجھتے ہیں کہ کام ہو گیا، تو آپ نے صرف 'ہنی مون فیز' کی پیمائش کی ہے۔ اس وقت KV cache تقریباً خالی ہوتا ہے۔ تہوں (layers) پر طویل prefill کا دباؤ نہیں پڑا ہوتا ہے۔ اصل اثر (footprint) تب ہی ظاہر ہوتا ہے جب ماڈل ایک بڑا پرامپٹ پروسیس کر چکا ہو اور کیش اپنے اصل ورکنگ سائز تک بھر چکا ہو۔ آپ کو گہرے prefill اور طویل جنریشن رنز کے ساتھ ٹیسٹ کرنا چاہیے۔ کانٹیکسٹ کو حقیقت میں جمع ہونے دیں۔ صرف تب ہی میموری کا دباؤ مستحکم ہوگا اور آپ کو اصل حد کا پتہ چلے گا۔

llama.cpp کے ساتھ اپنی حد کا تعین کرنا

اگر آپ llama.cpp کے ذریعے ماڈلز چلا رہے ہیں، تو آپ سادہ ریاضی اور ایک صبر آزما ٹیسٹ کے ذریعے اپنی حد کا تعین کر سکتے ہیں۔

1. Shared memory کے استعمال کی پیمائش کریں۔
ایک مختصر ترین پرامپٹ کے ساتھ اپنی بنیادی (baseline) مخصوص VRAM ریکارڈ کریں، پھر ایک طویل کانٹیکسٹ والا ٹاسک چلائیں اور اس کی انتہا (peak) نوٹ کریں۔ انتہا میں سے بنیادی مقدار کو تفریق کریں۔ یہ فرق وہ مقدار ہے جو آپ کے GPU سے نکل کر shared system memory میں منتقل ہو گئی ہے۔

2. اپنے RAM delta کا حساب لگائیں۔
سسٹم RAM کے لیے بھی یہی تفریق کریں۔ طویل رن کے دوران اپنی بنیادی RAM کو انتہا والی RAM سے تفریق کریں۔ یہ نمبر آپ کو بالکل درست بتاتا ہے کہ کتنا ڈیٹا ویڈیو کارڈ سے آپ کی مین میموری میں منتقل کیا گیا ہے۔ یہ بس (bus) کے ذریعے ہونے والے ڈیٹا کے اخراج (leak) کی مقدار بتاتا ہے۔

3. Eval speed کی گراوٹ کے وقت کا تعین کریں۔
اپنے بنیادی tokens-per-second ریٹ کا موازنہ اس ریٹ سے کریں جو ماڈل کے ایک طویل دستاویز کو پروسیس کرنے کے بعد حاصل ہو۔ ہو سکتا ہے کہ آپ دیکھیں کہ جب کانٹیکسٹ نیا ہو تو ماڈل 17 ٹوکنز فی سیکنڈ کی رفتار سے چل رہا ہو، لیکن کیش بھر جانے کے بعد وہ صرف 2 ٹوکنز فی سیکنڈ فراہم کر رہا ہو۔ یہ 15 ٹوکنز کی کمی آپ کے لیے ایک انتباہی علامت (canary in the coal mine) ہے۔

بریکنگ پوائنٹ (Breaking Point) کا تعین کرنا

کرو (curve) کو درست طریقے سے نقش کرنے کے لیے، صرف ایک اکیلے ڈیٹا پوائنٹ پر اکتفا نہ کریں۔ 16,000 tokens، 32,000 tokens، اور 65,000 tokens پر تین الگ الگ آزمائشیں (trials) کریں۔ دو پوائنٹس ایک لائن کا اشارہ دے سکتے ہیں، لیکن دو نقطے محض ایک اندازہ ہیں۔ تیسرا پوائنٹ یہ ثابت کرتا ہے کہ آیا آپ پیمائش کے شور (measurement noise) کو دیکھ رہے ہیں یا ایک حقیقی میموری وال (memory wall) کو۔ مختلف رنز (runs) کے نتائج کے درمیان فرق نکالیں تاکہ یہ حساب لگایا جا سکے کہ آپ کے ماڈل، quantization layer، اور GPU کے مخصوص مجموعے پر ہر اضافی ایک ہزار ٹوکنز کتنی اضافی میموری استعمال کرتے ہیں۔

جب آپ کو وہ ڈھلوان (slope) مل جائے، تو آپ مستقبل کا تخمینہ لگا سکتے ہیں۔ اپنی فی ٹوکن لاگت (per-token cost) لیں، اسے ہدف شدہ context length سے ضرب دیں، یونٹس کے درمیان تبدیلی کے لیے 1024 سے تقسیم کریں، اور نتیجے کو اپنے بیس ماڈل کے VRAM load میں جمع کر دیں۔ مساوات کچھ اس طرح ہے:

Model VRAM load + (tokens × memory per token ÷ 1024) = Theoretical VRAM usage

یہ تخمینہ کوئی پیش گوئی نہیں ہے۔ یہ اصل طرزِ عمل سے اخذ کردہ ایک رہنما اصول ہے۔ مکمل پروڈکشن رن (production run) شروع کرنے سے پہلے اپنی حد (ceiling) کا اندازہ لگانے کے لیے اسے استعمال کریں۔

کاغذ پر مبنی فارمولے کیوں ناکام ہو جاتے ہیں، اور Quantization کس طرح اصلاح کر سکتا ہے

درسی کتابوں کے فارمولے لوکل انفرنس (local inference) کی پیچیدہ حقیقت کو نظر انداز کر دیتے ہیں۔ مختلف آرکیٹیکچرز (architectures) attention buffers کو مختلف طریقے سے مختص کرتے ہیں۔ آپ کا آپریٹنگ سسٹم ڈسپلے ڈرائیور، کمپوزٹر (compositor)، اور CUDA context کے لیے VRAM محفوظ رکھتا ہے۔ ڈرائیور کے ورژن اس بات کو تبدیل کر دیتے ہیں کہ وہ شیئرڈ میموری (shared memory) کا کتنا جارحانہ استعمال کرتے ہیں۔ ایک نظریاتی مساوات یہ نہیں جان سکتی کہ دوپہر 2:00 بجے، براؤزر میں بہت سے ٹیبز کھلے ہونے کی صورت میں آپ کی مشین پر اصل میں کتنی VRAM خالی ہے۔ آپ کو اپنے مخصوص ہارڈ ویئر پر ماڈل چلانا ہوگا اور میٹرز (meters) پر نظر رکھنی ہوگی۔

Quantization جزوی ریلیف فراہم کرتی ہے۔ KV cache کو f16 سے q8_0 پر منتقل کرنے سے اس کا میموری فٹ پرنٹ (memory footprint) آدھا ہو جاتا ہے، جبکہ درستگی (precision) تقریباً تمام عملی کاموں کے لیے کافی بلند رہتی ہے۔ یہ تبدیلی آپ کو کچھ اضافی جگہ (headroom) فراہم کرتی ہے۔ یہ مکمل تحفظ (immunity) کی ضمانت نہیں دیتی۔ کیش (cache) اب بھی ہر اس ٹوکن کے ساتھ خطی طور پر (linearly) بڑھتا ہے جو آپ اس میں ڈالتے ہیں۔ آخر کار، کم شدہ سائز بھی آپ کی دستیاب مخصوص میموری (dedicated memory) پر حاوی ہو جاتا ہے اور سسٹم RAM میں ڈیٹا کا بہاؤ (spillover) شروع ہو جاتا ہے۔ دباؤ صرف اس وقت ختم ہوتا ہے جب context window کی حد مقرر کر دی جائے یا ڈیٹا کا بہاؤ رک جائے۔

اصل حاصلِ کلام

مارکیٹنگ سلائیڈز، پیرامیٹر کی تعداد، یا سرسری حساب کتاب پر بھروسہ نہ کریں۔ ماڈل لوڈ کریں۔ اپنا سسٹم مانیٹر کھولیں۔ 65,000 ٹوکنز والا تھریڈ (thread) چلائیں، RAM کے بڑھنے کا مشاہدہ کریں، اور فی سیکنڈ ٹوکنز کی تعداد گنیں۔ وہ نمبر جو آپ کی مخصوص اسکرین اور آپ کے مخصوص GPU پر ظاہر ہوتے ہیں، وہی واحد نمبر ہیں جو اہمیت رکھتے ہیں۔ Context ہمیشہ جیتتا ہے۔ آپ کا کام یہ جاننا ہے کہ آپ کی مشین پر یہ بالکل کب جیتتا ہے۔