پرامپٹ کیشنگ (prompt caching) آن کرنے سے مجھے کوئی فائدہ نہیں ہوا—بلکہ، میرا OpenAI-API کا بل تقریباً ایک چوتھائی بڑھ گیا۔ اس کی وجہ ایک ایسی لائن تھی جو ہر درخواست کے ساتھ بدل جاتی تھی: سسٹم پرامپٹ میں شامل ایک ٹائم اسٹیمپ (timestamp)۔
LLM فراہم کنندگان ٹوکن پروسیسنگ کے اخراجات کم کرنے کے لیے ڈویلپرز کو پرامپٹ کے ٹکڑوں (fragments) کو کیش (cache) کرنے کی اجازت دیتے ہیں۔ کیش ریڈ (ایک "hit") کی قیمت عام ریٹ کے دسویں حصے کے برابر ہوتی ہے، جبکہ کیش رائٹ (ایک "miss") کی قیمت تقریباً عام قیمت کا 1.25 گنا ہوتی ہے۔ اگر رائٹ (write) ہو جائے لیکن کیش شدہ ٹکڑا کبھی پڑھا نہ جائے، تو اضافی 25% چارج ضائع ہو جاتا ہے۔ میرے ساتھ بالکل یہی ہوا جب ٹائم اسٹیمپ کی وجہ سے پرامپٹ کسی بھی موجودہ کیش انٹری سے میچ نہیں کر پا رہا تھا۔
کیشنگ کیوں الٹی پڑ سکتی ہے
پرامپٹ کیشنگ کیش شدہ حصے کے بالکل درست بائٹ سیکوئنس (byte sequence) کو میچ کرنے کے ذریعے کام کرتی ہے۔ فراہم کنندہ ان پٹ کو ہیش (hash) کرتا ہے؛ اگر ہیش کسی محفوظ شدہ انٹری سے میچ کر جائے، تو سسٹم پچھلی کمپیوٹیشن کو دوبارہ استعمال کرتا ہے اور سستا ریڈ ریٹ لاگو کرتا ہے۔ کوئی بھی تبدیلی—یہاں تک کہ ایک حرف بھی—میچ کو توڑ دیتی ہے اور ایک نئی کمپیوٹیشن پر مجبور کرتی ہے، جس کا بل زیادہ ریٹ (write rate) پر وصول کیا جاتا ہے۔
میرے کیس میں سسٹم پرامپٹ یہاں سے شروع ہوا تھا:
Current session started: 2026-07-14T09:41:07Z
چونکہ ہر API کال کے لیے ٹائم اسٹیمپ اپ ڈیٹ ہو رہا تھا، اس لیے درخواست کے پہلے چند بائٹس کبھی بھی ایک جیسے نہیں تھے۔ فراہم کنندہ نے ہر کال کو ایک نئی کیش انٹری کے طور پر لیا، رائٹ پریمیم وصول کیا، اور کبھی بھی ریڈ (read) ریکارڈ نہیں کیا۔ اس کا نتیجہ یہ نکلا کہ cache_creation_input_tokens میں مسلسل اضافہ ہوا جبکہ cache_read_input_tokens صفر پر رہا، جو اس بات کی واضح علامت تھی کہ کیش کبھی استعمال (hit) نہیں ہو رہا تھا۔
خراب کیش کی نشاندہی کیسے کریں
API کے ذریعے فراہم کردہ یوزج لاگز (usage logs) دو اہم کاؤنٹرز دیتے ہیں:
- cache_creation_input_tokens – وہ ٹوکنز جنہوں نے رائٹ (write) کو ٹرگر کیا۔
- cache_read_input_tokens – وہ ٹوکنز جنہوں نے ریڈ (read) سے فائدہ اٹھایا۔
جب پہلا بڑھ رہا ہو اور دوسرا ساکن رہے، تو اس کا مطلب ہے کہ کیش کو دوبارہ استعمال نہیں کیا جا رہا۔ ایک فوری چیک کرنے کا طریقہ یہ ہے کہ بالکل وہی درخواست دو بار دہرائی جائے؛ اگر کیش کام کر رہا ہے تو دوسری کال میں ریڈ ٹوکنز میں اضافہ نظر آنا چاہیے۔
مسئلے کا حل
حل سادہ ہے: اس بات کو یقینی بنائیں کہ کیش شدہ حصہ تمام کالز کے دوران سٹیٹک (static) رہے۔ ان دو اصولوں پر عمل کریں:
- غیر متبدل (immutable) مواد کو پہلے رکھیں۔ سسٹم پرامپٹس، ٹول ڈیفینیشنز، یا کوئی بھی ایسی ہدایت جو کبھی نہیں بدلتی، درخواست کے ابتدائی بائٹس پر ہونی چاہیے۔
- متبدل (mutable) مواد کو آخر میں شامل کریں۔ ٹائم اسٹیمپ، صارف کا تیار کردہ متن، ریکوسٹ آئی ڈیز، یا کوئی بھی ڈیٹا جو ہر کال کے ساتھ بدلتا ہے، کیش شدہ حصے کے بعد آنا چاہیے۔
اگر ایک حرف بھی بدل جائے تو ہیش تبدیل ہو جاتا ہے اور کیش مس (cache miss) برقرار رہتا ہے۔ پرامپٹ کو اس طرح ترتیب دینا کہ ٹائم اسٹیمپ آخر میں ہو، کیش ہٹ ریٹ کو بحال کر دیتا ہے اور بل کو دوبارہ متوقع کم لاگت کی سطح پر لے آتا ہے۔
کیشنگ کب واقعی مددگار ہوتی ہے
پرامپٹ کیشنگ ان حالات میں بہترین کام کرتی ہے جہاں ہدایات کا ایک ہی سیٹ کئی بار استعمال کیا جاتا ہے:
- ایجنٹ لوپس (Agent loops) جہاں ایک AI بار بار ٹولز کے ایک مقررہ سیٹ کو کال کرتا ہے۔
- چیٹ سیشنز (Chat sessions) جو ایک طویل، سٹیٹک دستاویز کا حوالہ دیتے ہیں جبکہ صرف صارف کا تازہ ترین سوال بدلتا ہے۔
- بلک ڈیٹا ایکسٹریکشن (Bulk data extraction) جہاں بہت سے ریکارڈز پر ایک ہی پارسنگ پرامپٹ لاگو کیا جاتا ہے۔
ایسی سنگل شاٹ کالز کے لیے جن میں ہر بار نیا سیاق و سباق (context) شامل ہوتا ہے—جیسے ایک منفرد تمہید کے ساتھ پوچھا گیا ایک سوال—کیشنگ سے کوئی فائدہ نہیں ہوتا اور اگر درخواست غیر ارادی طور پر رائٹ (write) کو ٹرگر کر دے تو یہ لاگت میں اضافہ بھی کر سکتی ہے۔
پوشیدہ خطرات
اگرچہ پرامپٹ خود سٹیٹک ہو، لیکن درخواست کو بعد میں تبدیل کیا جا سکتا ہے:
- پروکسیز یا ایگریگیٹرز (Proxies or aggregators) جو ترتیب بدل دیتے ہیں یا وائٹ سپیس (whitespace) شامل کر دیتے ہیں، وہ بائٹ ٹو بائٹ میچ کو توڑ سکتے ہیں۔
- گیٹ وے سروسز (Gateway services) جو آتھنٹیکیشن ہیڈرز شامل کرتی ہیں یا JSON فارمیٹنگ کو تبدیل کرتی ہیں، وہ غیر ارادی طور پر کیش شدہ ٹکڑے کو بدل سکتی ہیں۔
گیٹ وے کے ذریعے ایک جیسی درخواست دو بار بھیج کر اور ریڈ کاؤنٹرز چیک کر کے یہ تصدیق کرنے میں مدد ملتی ہے کہ کیشنگ کا راستہ برقرار ہے۔
لاگت کی وسیع تر تصویر
رائٹس (writes) پر 25% کا اضافی چارج کیشنگ استعمال کرنے کی سزا نہیں ہے؛ یہ مستقبل میں دوبارہ استعمال کے لیے ٹکڑے کو اسٹور کرنے کے لیے درکار اضافی کمپیوٹیشن کی عکاسی کرتا ہے۔ جب کیش ہٹ (cache hit) ہوتا ہے، تو لاگت ڈرامائی طور پر کم ہو جاتی ہے—اکثر عام ریٹ کے ایک چھوٹے سے حصے تک۔ اصل بات یہ ہے کہ سسٹم کو حقیقت میں کیش تک پہنچنے دیا جائے۔ ورنہ، آپ بغیر کسی بچت کے پریمیم ادا کرتے ہیں۔
جوابی دلیل: کیشنگ ختم نہیں ہوئی
کچھ ڈویلپرز کا یہ استدلال ہے کہ سٹیٹک بمقابلہ ڈائنامک پرامپٹ حصوں کے انتظام کی پیچیدگی بچت سے زیادہ ہے۔ یہ نظریہ اس حقیقت کو نظر انداز کرتا ہے کہ بہت سی پروڈکشن پائپ لائنز پہلے سے ہی کنفیگریشن (سٹیٹک) کو صارف کے ڈیٹا (ڈائنامک) سے الگ رکھتی ہیں۔ پرامپٹس کو اس کے مطابق ترتیب دے کر، وہی کیشنگ میکانزم جس نے API کے اصل ڈویلپرز کی بچت کی تھی، اسے بغیر کسی اضافی محنت کے استعمال کیا جا سکتا ہے۔ اس کا تبادلہ پرامپٹ ڈیزائن میں ایک معمولی نظم و ضبط ہے، نہ کہ ٹیکنالوجی میں کوئی بنیادی نقص۔
آگے کیا دیکھنا ہے
- اپنے یوزج ڈیش بورڈ میں دو کیش کاؤنٹرز کی ہفتہ وار نگرانی کریں۔
- پرامپٹ کی ساخت کا آڈٹ کریں تاکہ اس بات کی تصدیق ہو سکے کہ کوئی بھی متغیر عنصر (variable element) کیش شدہ بلاک کے بعد واقع ہو۔
- اصل بچت کا تعین کرنے کے لیے ایک نمائندہ ورک لوڈ پر کیشنگ کے ساتھ اور اس کے بغیر A/B ٹیسٹ چلائیں۔
- کسی بھی پراکسی سے پہلے اور بعد میں را (raw) ریکویسٹ پے لوڈز کا موازنہ کر کے گیٹ وے کی تصدیق کریں۔
خلاصہ
پرامپٹ کیشنگ LLM API کے اخراجات کو تیزی سے کم کر سکتی ہے، لیکن صرف اس صورت میں جب کیش شدہ حصہ تمام کالز میں بالکل یکساں ہو۔ پرامپٹ کے آغاز میں کوئی بھی غیر متعلقہ ٹائم اسٹیمپ یا کوئی دوسرا ڈائنامک ٹوکن ہر بار ایک مہنگا 'رائٹ' (write) کرنے پر مجبور کرتا ہے، جس سے بل بڑھ جاتا ہے۔ سٹیٹک ہدایات کو شروع میں رکھ کر اور بدلتے ہوئے ڈیٹا کو آخر میں منتقل کر کے، آپ کیش کو اپنا کام کرنے دیتے ہیں اور اپنے اخراجات کو قابو میں رکھتے ہیں۔