প্রম্পট ক্যাশিং — ৯০% পর্যন্ত সাশ্রয়

১ · কেন একই কনটেন্ট বারবার বিল হয়

পাঠ ০১-এ আমরা দেখেছি — API কল করার সময় সম্পূর্ণ প্রম্পট (system prompt, tool definition, কথোপকথনের ইতিহাস, ডকুমেন্ট, প্রশ্ন — সবকিছু) প্রতিবার নতুন করে মডেলে পাঠানো হয়। কিন্তু বাস্তব প্রোডাকশন সিস্টেমে এই প্রম্পটের একটা বড় অংশ প্রতিটি কলে হুবহু একই থাকে — যেমন একই system prompt, একই tool definitions, একই রেফারেন্স ডকুমেন্ট। শুধু ব্যবহারকারীর সাম্প্রতিক প্রশ্নটাই বদলায়।

ডিফল্ট আচরণে মডেল এই অপরিবর্তিত অংশটুকুও প্রতিবার শূন্য থেকে প্রসেস করে এবং প্রতিবারই তার জন্য পুরো দাম নেয় — এমনকি যদি সেই একই ৮,০০০ টোকেন গত এক মিনিট আগেও পাঠানো হয়ে থাকে। উচ্চ-ভলিউম অ্যাপ্লিকেশনে (যেমন একটি চ্যাটবট যেখানে হাজার হাজার ব্যবহারকারী একই system prompt ও ডকুমেন্ট সেট শেয়ার করে) এটি বিপুল অপচয়।

২ · প্রম্পট ক্যাশিং কী এবং কীভাবে কাজ করে

প্রম্পট ক্যাশিং (Prompt Caching)Prompt Cachingপ্রম্পটের অপরিবর্তিত prefix (শুরুর অংশ) মনে রাখার একটি প্রক্রিয়া, যাতে পরবর্তী কলে সেই অংশ পুনরায় গণনা না করে সরাসরি ব্যবহার করা যায় — ফলে সেই অংশের ইনপুট খরচ ও লেটেন্সি অনেক কমে যায়। হলো একটি প্রক্রিয়া যেখানে প্রোভাইডার প্রম্পটের অপরিবর্তিত অংশ (prefix) মনে রাখে, এবং পরের কলে সেই একই prefix দেখলে সেটি আবার প্রসেস না করে সরাসরি cached ফলাফল ব্যবহার করে। শুধু নতুন/ভিন্ন অংশটুকু (সাধারণত শেষের প্রশ্নটি) নতুন করে প্রসেস হয়।

৩ · আসল সংখ্যায় সাশ্রয় — একটি বাস্তব উদাহরণ

সংখ্যাটা বিমূর্ত মনে হলে একটি বাস্তব উদাহরণ দেখা যাক। ধরুন একটি RAG চ্যাটবট প্রতিটি বার্তার সাথে ৮,০০০ টোকেনের system prompt এবং ডকুমেন্ট সেট পাঠায়। ক্যাশিং ছাড়া, স্ট্যান্ডার্ড রেটে এই পুনরাবৃত্ত কনটেক্সট চালাতে প্রতি মিলিয়ন বার্তায় আনুমানিক $24 খরচ হতে পারে। ক্যাশিং চালু থাকলে সেই একই পুনরাবৃত্ত টোকেনগুলোর খরচ নেমে আসতে পারে প্রতি মিলিয়নে আনুমানিক $0.30-এ — অর্থাৎ পুনরাবৃত্ত অংশে প্রায় ৯৮% হ্রাস।

সাধারণভাবে প্রোভাইডারদের দাবি হলো cached অংশে ইনপুট খরচ ৯০% পর্যন্ত কমানো সম্ভব — উপরের উদাহরণটি দেখায় যে বাস্তব প্রোডাকশন পরিস্থিতিতে (যেখানে prefix প্রায় সম্পূর্ণ পুনরাবৃত্ত হয়) এই সাশ্রয় আরও বেশি হতে পারে।

৪ · প্রতিটি প্রোভাইডারে ক্যাশিং কীভাবে কাজ করে

তিনটি প্রধান প্রোভাইডারই ২০২৬ সালে ক্যাশিং সাপোর্ট করে, কিন্তু ডেভেলপারের জন্য বাস্তবায়নের অভিজ্ঞতা বেশ ভিন্ন —

• Anthropic (Claude): এখানে ক্যাশিং explicit opt-incache_controlমেসেজ কনটেন্টের একটি নির্দিষ্ট ব্লকে সেট করা একটি ফিল্ড, যা ডেভেলপারকে বলে দিতে হয় ঠিক কোন অংশটুকু ক্যাশ করতে হবে। — ডেভেলপারকে মেসেজ কনটেন্টের নির্দিষ্ট ব্লকে cache_control ফিল্ড সেট করে বলে দিতে হয় ঠিক কোথায় ক্যাশ পয়েন্ট বসবে। এতে নিয়ন্ত্রণ বেশি, কিন্তু ডেভেলপারকেই সচেতনভাবে এটি চালু করতে হয়।
• OpenAI (GPT): ক্যাশিং স্বয়ংক্রিয় এবং কোনো কোড পরিবর্তন ছাড়াই কাজ করে — শুধু শর্ত একটাই, পুনরাবৃত্ত/স্ট্যাটিক কনটেন্ট প্রম্পটের শুরুতে রাখতে হবে। প্রোভাইডার নিজে থেকেই পুনরাবৃত্ত prefix শনাক্ত করে ক্যাশ প্রয়োগ করে।
• Google (Gemini): এখানে একে বলা হয় Context Caching — এটিও একটি সামঞ্জস্যপূর্ণ prefix অর্ডারিং থেকে উপকৃত হয়, অর্থাৎ একই universal নিয়মই এখানেও কাজ করে।

৫ · সোনালী নিয়ম — Static আগে, Variable পরে

সব প্রোভাইডার জুড়ে একটিই ইউনিভার্সাল বাস্তবায়ন-নিয়ম প্রযোজ্য — স্ট্যাটিক ও পুনর্ব্যবহৃত কনটেন্ট (system prompt, tool definitions, রেফারেন্স ডকুমেন্ট) প্রম্পটের শুরুতে রাখুন, আর ভ্যারিয়েবল/প্রশ্ন-নির্দিষ্ট কনটেন্ট একদম শেষে রাখুন। এটাই একটি cacheable prefix তৈরি করার একমাত্র উপায় — কারণ ক্যাশিং কেবল তখনই কাজ করে যখন প্রম্পটের শুরুর অংশ প্রতিটি কলে অভিন্ন থাকে। প্রশ্ন বা ভ্যারিয়েবল ডেটা মাঝখানে বসিয়ে দিলে সেই পয়েন্ট থেকে prefix আর মেলে না, এবং ক্যাশ ভেঙে যায়।

সুখবর হলো — এই একই অর্ডারিং নিয়ম Anthropic-এর long-context গবেষণা অনুযায়ী শুধু ক্যাশের জন্যই ভালো নয়, বরং উত্তরের মানও বাড়ায়। দীর্ঘ ডকুমেন্ট/ডেটা উপরে এবং প্রশ্নটি একদম শেষে রাখলে মডেলের উত্তরের গুণমান উন্নত হতে পারে, কারণ প্রশ্নটি মডেলের "চোখের সামনে" সবচেয়ে সাম্প্রতিক অবস্থানে থাকে ঠিক উত্তর দেওয়ার আগ মুহূর্তে। অর্থাৎ এখানে খরচ ও মান — দুটোই একই দিকে টানে।

৬ · ভালো বনাম খারাপ প্রম্পট অর্ডার

নিচের দুটি উদাহরণ একই তথ্য বহন করে, কিন্তু একটি ক্যাশযোগ্য (cacheable) এবং অন্যটি নয় —

❌ কম কার্যকর (ক্যাশ ভেঙে যায় — প্রশ্ন মাঝখানে বসানো):

[System prompt — ২০০ টোকেন]

ব্যবহারকারীর প্রশ্ন: "রিফান্ড পলিসি কী বলে যদি প্রোডাক্ট
৩০ দিনের বেশি ব্যবহার করা হয়ে থাকে?"

[রেফারেন্স ডকুমেন্ট — কোম্পানি পলিসি, ৭,৮০০ টোকেন]

উপরের ডকুমেন্ট অনুযায়ী উত্তর দাও।

এখানে প্রশ্নটি ডকুমেন্টের আগে বসানো হয়েছে — প্রতিটি নতুন প্রশ্নে prefix ভিন্ন হয়ে যাবে (কারণ প্রশ্ন সবার আগে), তাই ৭,৮০০-টোকেন ডকুমেন্টের জন্যও কোনো ক্যাশ হিট হবে না, যদিও ডকুমেন্টটা প্রতিবার একই।

✅ বেশি কার্যকর (স্ট্যাটিক অংশ শুরুতে — cacheable prefix):

[System prompt — ২০০ টোকেন]

[রেফারেন্স ডকুমেন্ট — কোম্পানি পলিসি, ৭,৮০০ টোকেন]

উপরের ডকুমেন্ট অনুযায়ী নিচের প্রশ্নের উত্তর দাও।

ব্যবহারকারীর প্রশ্ন: "রিফান্ড পলিসি কী বলে যদি প্রোডাক্ট
৩০ দিনের বেশি ব্যবহার করা হয়ে থাকে?"

এখানে system prompt এবং ডকুমেন্ট — দুটোই প্রম্পটের শুরুতে, এবং প্রতিটি কলে হুবহু একই থাকে। শুধু একদম শেষের প্রশ্নটি বদলায়। ফলে প্রথম ৮,০০০ টোকেন প্রতিবার cache থেকে আসে, আর নতুন করে বিল হয় শুধু প্রশ্ন ও উত্তরের টোকেন।