লাভ:
- প্রম্পট ক্যাশিং এর উপসর্গ মেলা যুক্তি ব্যাখ্যা করুন
- স্থির প্রসঙ্গ প্রথমে এবং পরিবর্তনশীল প্রসঙ্গ পরে রেখে ক্যাশে হিট বাড়ায়
- ক্যাশে লেখা/পড়া অর্থনীতি এবং ব্রেক-ইভেন পয়েন্ট গণনা করতে পারে
একটি LLM পণ্য প্রোটোটাইপে সস্তা দেখায়; আপনি যখন স্কেলে উঠে যান, বিলটি অবাক করে দেয়। বেশিরভাগ কাজের চাপে, বেশিরভাগ বিল একই নির্দিষ্ট প্রসঙ্গ থেকে আসে যা প্রতিটি অনুরোধের সাথে বারবার পাঠানো হয়: একটি দীর্ঘ সিস্টেম প্রম্পট, একটি নিয়ম বই, রেফারেন্স ডকুমেন্টেশন। প্রম্পট ক্যাশিং ঠিক এই বর্জ্য নির্মূল করে। এই ইউনিটে, আপনি শিখবেন কীভাবে ক্যাশে কাজ করে, কীভাবে প্রম্পটকে আঘাত করার ব্যবস্থা করতে হয় এবং ক্যাশে অর্থনীতির ব্রেক-ইভেন পয়েন্ট কীভাবে গণনা করতে হয়। সঠিকভাবে ইনস্টল করা হলে, এটি একাই আপনার বিলকে অর্ধেক বা তারও কম করতে পারে।
ক্যাশে কিভাবে কাজ করে? এক অপরিবর্তনীয় নিয়ম
প্রম্পট ক্যাশিং একটি প্রিফিক্স ম্যাচ। প্রদানকারী আপনার প্রম্পটের শুরু থেকে প্রক্রিয়াকৃত টোকেনগুলি অস্থায়ীভাবে সংরক্ষণ করে। যদি পরবর্তী অনুরোধে প্রম্পট একই উপসর্গ দিয়ে শুরু হয়, এই সাধারণ অংশটি পুনরায় গণনা করা হয় না; এটি ক্যাশের চেয়ে পড়তে অনেক সস্তা।
এটি থেকে একটি অপরিবর্তনীয় নিয়ম অনুসরণ করা হয়: যদি একটি একক বাইট উপসর্গের কোথাও পরিবর্তিত হয়, তাহলে সেই বিন্দু থেকে সম্পূর্ণ ক্যাশে অবৈধ হয়ে যাবে। অর্থাৎ, নির্দিষ্ট বিষয়বস্তু শুরুতে এবং পরিবর্তনশীল বিষয়বস্তু শেষে থাকা উচিত। আপনি যদি সিস্টেম প্রম্পটের শুরুতে একটি লাইন রাখেন যা প্রতিটি অনুরোধের সাথে পরিবর্তিত হয়, যেমন "আজকের তারিখ: 18.07.2026", এর পিছনে থাকা সবকিছু ক্যাশে প্রবেশ করতে সক্ষম হবে না।
প্রক্রিয়াকরণের ক্রম সাধারণত: টুলস → সিস্টেম প্রম্পট → বার্তা। আপনি নির্দিষ্ট বিভাগের শেষে ক্যাশে পয়েন্ট (ব্রেকপয়েন্ট) রাখুন।
ক্যাশে ইকোনমি
ক্যাশে তিনটি মূল্য স্তর আছে:
- ক্যাশে লিখুন: প্রথমবারের জন্য সংরক্ষণ করা হচ্ছে। ~1.25x সাধারণ ইনপুট মূল্য (5 মিনিট স্টোরেজের জন্য)।
- ক্যাশে রিড: পরবর্তী অনুরোধে পড়া। সাধারণ ইনপুট মূল্যের ~0.1 গুণ — অর্থাৎ এক দশমাংশ।
- সাধারণ ইনপুট: যে অংশটি ক্যাশে প্রবেশ করে না এবং প্রতিবার সম্পূর্ণ খরচে প্রক্রিয়া করা হয়।
ব্রেক-ইভেন পয়েন্ট: প্রথম অনুরোধ রাইট প্রিমিয়াম (1.25×) প্রদান করে। দ্বিতীয় অনুরোধ থেকে, পড়া (0.1×) খেলায় আসে। মোটামুটিভাবে, আপনি দুটি অনুরোধে ঘাড় এবং ঘাড় হবেন; এর পরে, এটি নেট সেভিংস। স্থির প্রসঙ্গ যত বড় হবে এবং যত বেশি অনুরোধ এটি পুনঃব্যবহার করা হবে, লাভ তত বেশি হবে।
দৃশ্যকল্প
ক্যাশে কাজ করে?
বড় ফিক্সড সিস্টেম প্রম্পট, হাজার হাজার অনুরোধ
হ্যাঁ — সর্বোচ্চ আয়
একই রেফারেন্স ডক্সে অনেক প্রশ্ন
হ্যাঁ
প্রতিটি অনুরোধের জন্য সম্পূর্ণ ভিন্ন সংক্ষিপ্ত পাঠ্য
না—লিখে বোনাস নষ্ট হয়
একবার অনুরোধ
না - মোটেও পড়া নেই
সিস্টেম প্রম্পটে প্রতিটি অনুরোধের সাথে তারিখ/আইডি পরিবর্তন করা হচ্ছে
না — উপসর্গ ভাঙা, আঘাত শূন্য
ধাপে ধাপে: কিভাবে একটি হিট প্রম্পট সেট আপ করবেন?
- ধ্রুবক এবং পরিবর্তনশীল পৃথক করুন। কোন বিষয়বস্তু কখনই পরিবর্তন হয় না (সিস্টেম প্রম্পট, রুলবুক, ডকুমেন্টেশন)? প্রতিটি অনুরোধের সাথে কোনটি পরিবর্তন হয় (ব্যবহারকারীর প্রশ্ন, তারিখ, আইডি)?
- শুরুতে ধ্রুবক রাখুন। প্রক্রিয়াকরণের সময়, যে অংশটি প্রথমে আসে (সরঞ্জাম, সিস্টেম) অবশ্যই স্থিতিশীল হতে হবে।
- শেষে ভেরিয়েবল রাখুন। ব্যবহারকারীর বর্তমান প্রশ্ন, শেষ.
- সীমানার শেষে চিহ্নটি রাখুন। স্থির অংশের শেষ ব্লকে ক্যাশে পয়েন্ট রাখুন।
- হিট যাচাই করুন. প্রতিক্রিয়াতে ব্যবহারের ক্ষেত্রে ক্যাশে_রিড_ইনপুট_টোকেন শূন্যের চেয়ে বেশি কিনা তা পরীক্ষা করুন। শূন্য হলে, উপসর্গে একটি লুকানো বিঘ্নকারী থাকে।
{ "সিস্টেম": [ { "টাইপ": "টেক্সট", "টেক্সট": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content"{current]}}"
টিপ: ক্যাশে হিট অনুমান করবেন না, তাদের পরিমাপ করুন। যদি পরপর অনুরোধে usage.cache_read_input_tokens এখনও শূন্য থাকে, একটি নীরব ব্রেকার (datetime.now() সিস্টেম প্রম্পটে, unordered JSON, প্রতিটি অনুরোধের সাথে পরিবর্তিত সরঞ্জামগুলির তালিকা) চলছে। বাইট দ্বারা বাইট দুটি অনুরোধের কাঁচা প্রম্পট তুলনা করুন এবং পার্থক্য খুঁজুন।
নীরব বিঘ্নকারী
সাধারণ নিদর্শন যা অজান্তে ক্যাশে দূষিত করে:
# BREAKER: সিস্টেম প্রম্পটে এম্বেড করা তথ্য যা প্রতিটি অনুরোধের সাথে পরিবর্তিত হয় "আজকের তারিখ: {{এখন}}। আপনি একজন সহকারী..." ← প্রতিটি অনুরোধের সাথে উপসর্গ পরিবর্তন হয়, হিট শূন্য# সত্য: ভেরিয়েবলটিকে বার্তা সিস্টেমে সরান: "আপনি একজন সহকারী..." ← ধ্রুবক ক্যাচেমেসেজে প্রবেশ করে: [{roday}} প্রশ্ন: [{roday}} প্রশ্ন:} ..."}] ← শেষে পরিবর্তনশীল
অন্যান্য ব্রেকার: JSON প্রতিটি অনুরোধে আলাদাভাবে সাজানো হয়েছে (কীগুলিকে নির্দিষ্ট ক্রমে রাখুন), ব্যবহারকারীর দ্বারা পরিবর্তিত টুলগুলির তালিকা (সরঞ্জামগুলি প্রথমে প্রক্রিয়া করা হয়; পরিবর্তন হলে কিছুই ক্যাশে যায় না), মডেলের মধ্য-কথোপকথনের পরিবর্তন (ক্যাশে মডেল নির্দিষ্ট)।
দুর্বল প্রম্পট / শক্তিশালী প্রম্পট (ক্যাশে বন্ধুত্বপূর্ণ কাঠামো)
# দুর্বল (ক্যাশে বাস্টিং বিল্ড) সিস্টেম: "তারিখ: 18.07.2026 14:32। ব্যবহারকারী: আহমেট (আইডি 8842)। আপনি একটি সমর্থন বট। নিয়ম: ...(2000 টোকেন)..."
# স্ট্রং (ক্যাশে-ফ্রেন্ডলি স্ট্রাকচার) সিস্টেম: "আপনি একটি সাপোর্ট বট। নিয়ম: ...(2000 টোকেন, কখনই পরিবর্তন হয় না)..." [ক্যাশে সাইন] বার্তা: [ { ভূমিকা: ব্যবহারকারী, বিষয়বস্তু: "তারিখ: 18.07.2026 14:32। ব্যবহারকারীর আইডি: 8842। প্রশ্ন: আমি কীভাবে আমার রিফান্ড করতে পারি?" }]
দুর্বল সংস্করণে, 2000 টোকেনের নিয়ম ব্লক প্রতিটি অনুরোধে সম্পূর্ণ খরচে প্রক্রিয়া করা হয়। শক্তিশালী সংস্করণে, একই ব্লক একবার লেখা হয় এবং মূল্যের দশমাংশের জন্য পরবর্তী সমস্ত অনুরোধগুলিতে পড়া হয়।
তিনটি মিনি কেস
কেস 1 - রুলবুক ক্যাশ করা। একটি অ্যাকাউন্টিং অটোমেশন প্রতিটি চালানে 12,000 টোকেন রুলবুক যোগ করছিল; প্রতিদিন 5,000 অনুরোধ। ক্যাশেলেস ইনপুট খরচ প্রতিদিন ~$180। তারা রুলবুকটি ধ্রুবক রাখে এবং এটি ক্যাশ করে: প্রথম অনুরোধগুলি একটি লেখার প্রিমিয়াম প্রদান করে, পরবর্তীতে 0.1× পড়ে৷ ইনপুট খরচ প্রতিদিন ~90% থেকে ~$18 কমেছে।
কেস 2 - লুকানো তারিখ লাইনের খরচ। একটি দল একটি ক্যাশে সেট আপ কিন্তু কোন হিট পাচ্ছিল না; cache_read_input_tokens সবসময় শূন্য ছিল। কারণ: সিস্টেম প্রম্পটের প্রথম লাইনে datetime.now() ছিল, প্রতিটি অনুরোধের সাথে উপসর্গটি পরিবর্তিত হচ্ছে। যখন আমরা তারিখটিকে ব্যবহারকারীর বার্তায় স্থানান্তরিত করি, তখন আঘাতের হার হঠাৎ করে 0% থেকে 94% বেড়ে যায়।
কেস 3 - ভুল ক্যাশে। একটি অনুসন্ধান অ্যাপ্লিকেশন প্রতিটি অনুরোধের সাথে সম্পূর্ণ ভিন্ন ছোট প্রশ্ন পাঠাচ্ছিল; তারা সাগ্রহে একটি ক্যাশে চিহ্ন যোগ করেছে। কোন সাধারণ উপসর্গ ছাড়াই, প্রতিটি অনুরোধ শুধুমাত্র একটি লেখার প্রিমিয়াম প্রদান করে, কোন পঠিত হয় না — খরচ বৃদ্ধি করে। তারা চিহ্নটি সরিয়ে দিয়েছে। পাঠ: পুনঃব্যবহৃত একটি বড় এবং ধ্রুবক উপসর্গ থাকলেই ক্যাশে অর্থ প্রদান করে।
সাধারণ ভুল
- ধ্রুবক এবং পরিবর্তনশীল মিশ্রণ: যখন পরিবর্তনশীল বিষয়বস্তু উপসর্গে থাকে, তখন হিট পুনরায় সেট করা হয়।
- সিস্টেম প্রম্পটে তারিখ/আইডি এমবেডিং: সবচেয়ে সাধারণ নীরব বিঘ্নকারী।
- হিট পরিমাপ না করা: ক্যাশে_রিড_ইনপুট_টোকেন চেক করা না থাকলে, অপচয় লক্ষ্য করা যাবে না।
- কোনো পাবলিক উপসর্গ না থাকলে ক্যাশে যোগ করা: আপনি শুধুমাত্র লেখার প্রিমিয়াম প্রদান করেন, খরচ বেড়ে যায়।
- গাড়ির তালিকা বা মডেল পরিবর্তন করা: উপসর্গটি শুরু থেকে ভেঙে গেছে; সবকিছু আবার লেখা হয়।
- ন্যূনতম ক্যাশে আকার ভুলে যাওয়া: খুব ছোট ক্যাশে (মডেলের উপর নির্ভর করে ~1–4k টোকেনের অধীনে) নীরবে ক্যাশে প্রবেশ করবে না।
আরও গভীর: কাজের চাপের ধরন অনুসারে ক্যাশে ডিজাইন করা
আপনার কাজের চাপের প্রকৃতির উপর নির্ভর করে ক্যাশিংয়ের প্রকৃত অর্থ পরিবর্তিত হয়; তাই আগে আপনার ট্রাফিক জানুন. তিনটি সাধারণ নিদর্শন এবং সঠিক ইনস্টলেশন:
কমন সিস্টেম প্রম্পট, বিভিন্ন প্রশ্ন। সর্বাধিক সাধারণ এন্টারপ্রাইজ প্যাটার্ন: একটি বৃহৎ সিস্টেম প্রম্পট (ভূমিকা, নিয়ম, হতে পারে রেফারেন্স নথি) শত শত বিভিন্ন ব্যবহারকারীর প্রশ্ন সহ। এখানে নির্দিষ্ট অংশ (সিস্টেম) প্রাথমিকভাবে ক্যাশে করা হয়; প্রতিটি নতুন প্রশ্ন শুধুমাত্র তার নিজের ছোট অংশের জন্য সম্পূর্ণ মূল্য প্রদান করে। লাভ খুব বেশি কারণ বড় অংশ দামের দশমাংশে বারবার পাঠ করা হয়।
বহু-বৃত্তাকার একক শব্দ। একটি কথোপকথন যখন টেনে আনে, প্রতিটি নতুন রাউন্ড আগের সমস্ত ইতিহাসের উপরে তৈরি হয়। আপনি যদি শেষ রাউন্ডের শেষে ক্যাশে পতাকা রাখেন, প্রতিটি অনুরোধ পূর্ববর্তী কথোপকথনের উপসর্গটি পুনরায় ব্যবহার করে; কথোপকথন বাড়ার সাথে সাথে হিট জমা হয়। এটি নাটকীয়ভাবে দীর্ঘ সহকারী সেশনের খরচে লাগাম দেয়।
ভাগ করা উপসর্গটি পরিবর্তন করার শেষ বিট। একাধিক অনুরোধ নির্দিষ্ট পূর্বের একটি বড় সেট ভাগ করে (নমুনা সেট, নির্দেশাবলী) কিন্তু শেষে একটি একক প্রশ্ন দ্বারা পৃথক করা হয়। আপনি ভাগ করা অংশের শেষে ক্যাশে পয়েন্টার রাখুন; অন্যথায়, প্রতিটি অনুরোধ তার নিজস্ব আলাদা ক্যাশে লিখবে এবং এর কোনটিই পড়া হবে না।
একটি সতর্কতা: ক্যাশে মডেল এবং একটি নির্দিষ্ট সর্বনিম্ন আকারের উপর নির্ভর করে। খুব ছোট উপসর্গ (কয়েক হাজার টোকেনের অধীনে, মডেলের উপর নির্ভর করে) নীরবে ক্যাশে প্রবেশ করবে না এমনকি যদি আপনি তাদের পতাকাঙ্কিত করেন — cache_creation_input_tokens শূন্য থাকে। এছাড়াও, মডেল-কথোপকথনের মধ্যবর্তী পরিবর্তন সম্পূর্ণ ক্যাশে অবৈধ করে; যদি একটি ভিন্ন কাজের জন্য একটি সস্তা মডেলের প্রয়োজন হয়, একটি মডেলের মধ্যে মূল প্রবাহ রাখুন এবং একটি পৃথক কলে পাশের কাজটি রাখুন।
সংক্ষেপে
প্রম্পট ক্যাশিং হল একটি প্রিফিক্স ম্যাচ: নির্দিষ্ট বিষয়বস্তু শুরুতে হওয়া উচিত, পরিবর্তনশীল বিষয়বস্তু শেষে হওয়া উচিত। একটি বৃহৎ, পুনঃব্যবহৃত প্রেক্ষাপটের জন্য, পঠিত খরচ সম্পূর্ণ মূল্যের দশমাংশ, মোটামুটিভাবে এমনকি দুটি অনুরোধের মধ্যেও ভেঙে যায়। সবচেয়ে সাধারণ ভুল হল সিস্টেম প্রম্পটে পরিবর্তনশীল ডেটা এমবেড করে উপসর্গটিকে দূষিত করা; আপনি ব্যবহারের ক্ষেত্রে এটি পরিমাপ করে হিট যাচাই করুন।
আবেদন টাস্ক
একটি কাজের চাপ চয়ন করুন। (1) বিষয়বস্তুটিকে দুটি কলামে ভাগ করুন: "কখনও পরিবর্তন হয় না" এবং "প্রতিটি অনুরোধের সাথে পরিবর্তন হয়"। (2) প্রম্পট কাঠামোটি পুনরায় আঁকুন, শুরুতে ধ্রুবক অংশ এবং শেষে পরিবর্তনশীল অংশটি রাখুন। (3) নির্দিষ্ট অংশের টোকেন আকার অনুমান করুন এবং ক্যাশ ছাড়া/ছাড়া মাসিক খরচ তুলনা করুন। (4) লক্ষ্য করুন কোন ক্ষেত্র (cache_read_input_tokens) থেকে আপনি হিটটি যাচাই করবেন।
চেকলিস্ট
- [ ] আমি ব্যাখ্যা করতে পারি যে ক্যাশে হল প্রিফিক্স ম্যাচিং এবং একমাত্র অপরিবর্তনীয় নিয়ম।
- [ ] আমি শুরুতে স্থির বিষয়বস্তু এবং শেষে পরিবর্তনশীল রেখে যথার্থতা বাড়াতে পারি।
- [ ] আমি অর্থনীতি লিখতে/পড়তে জানি এবং দুই-অনুরোধ ব্রেক-ইভেন পয়েন্ট।
- [ ] আমি নীরব বিঘ্নকারীকে চিনতে পারি (তারিখ, অবিন্যস্ত JSON, গাড়ির তালিকা পরিবর্তন করা)।
- [ ] আমি usage.cache_read_input_tokens দিয়ে হিট যাচাই করতে পারি।