Amazon Bedrock এখন Claude 4.6-এর জন্য প্রম্পট-ক্যাশিং (prompt-caching) অফার করছে, যা জেনারেটিভ-AI অ্যাপ্লিকেশনগুলোর রেসপন্স ল্যাটেন্সি কমাতে এবং ইনফারেন্স খরচ হ্রাস করতে পারে। এই সক্ষমতাটি একটি প্রম্পটের একটি স্থির অংশ পাঁচ মিনিট পর্যন্ত মনে রাখতে পারে, ফলে পরবর্তী কলগুলোতে সেই টেক্সটটি পুনরায় প্রসেস করার ব্যয়বহুল ধাপটি এড়িয়ে যাওয়া যায়।
রিকোয়েস্ট চেইনে ক্যাশ কীভাবে কাজ করে
যখন একটি Claude 4.6 রিকোয়েস্ট আসে, তখন দুটি স্তর একত্রে কাজ করে।
মডেল লেভেল – Claude 4.6 GPU মেমরিতে একটি কি-ভ্যালু (KV) ক্যাশ বজায় রাখে। মডেলটি যখন প্রথমবার নির্দেশনার একটি ব্লক পার্স করে, তখন এটি এর অভ্যন্তরীণ রিপ্রেজেন্টেশনটি সংরক্ষণ করে। পরবর্তীতে যখন একই ব্লক পুনরায় ব্যবহার করা হয়, তখন মডেলটি সেটি পুনরায় গণনা করার পরিবর্তে সেই রিপ্রেজেন্টেশনটি পুনরুদ্ধার করতে পারে।
Bedrock লেভেল – Bedrock স্থির প্রম্পট সেগমেন্টটির একটি ফিঙ্গারপ্রিন্ট তৈরি করে। যদি নতুন কোনো রিকোয়েস্টে একই রকম ফিঙ্গারপ্রিন্ট থাকে, তবে Bedrock এটিকে সরাসরি সেই GPU-তে পাঠিয়ে দেয় যেখানে ক্যাশ করা স্টেটটি আগে থেকেই রয়েছে, ফলে "ওয়ার্ম-আপ" (warm-up) পর্যায়টি এড়িয়ে যাওয়া সম্ভব হয়।
এটিকে প্রতিবার নতুন গেম শুরু করার পরিবর্তে একটি সেভ করা গেম লোড করার মতো ভাবুন।
ক্যাশ সচল রাখার নিয়মাবলী
সর্বনিম্ন টোকেন সংখ্যা – Claude Sonnet 4.6-এর ক্ষেত্রে ক্যাশ করা সেগমেন্টে অন্তত ১,০২৪টি টোকেন প্রয়োজন; Claude Opus 4.6-এর জন্য প্রয়োজন ৪,০৯৬টি টোকেন। এর চেয়ে কম টোকেন থাকলে তা উপেক্ষা করা হবে।
পাঁচ মিনিটের লাইফটাইম – নিষ্ক্রিয় থাকার পাঁচ মিনিট পর ক্যাশটির মেয়াদ শেষ হয়ে যায়। প্রতিটি হিট টাইমারটিকে রিসেট করে, তাই কলগুলোর একটি অবিচ্ছিন্ন প্রবাহ ক্যাশটিকে অনির্দিষ্টকাল সচল রাখতে পারে।
প্রম্পট অর্ডারিং – Bedrock প্রম্পটটি ক্রমানুসারে পড়ে। স্থির নির্দেশাবলী অবশ্যই প্রথমে থাকতে হবে, তারপরে একটি
cachePointমার্কার থাকবে, এবং সেই মার্কারের পরে সমস্ত ইউজার-জেনারেটেড মেসেজ থাকতে হবে। মার্কারের আগে একটি অক্ষর পরিবর্তন করলেও ফিঙ্গারপ্রিন্ট ভেঙে যায় এবং এটি পুনরায় 'কোল্ড রিড' (cold read) করতে বাধ্য করে।
ফিচারটি বাস্তবে প্রয়োগ করা
Bedrock Converse API হলো এর প্রবেশদ্বার। নিচে একটি সংক্ষিপ্ত পাইথন স্নিপেট দেওয়া হলো যা প্রয়োজনীয় কাঠামোটি প্রদর্শন করে।
import boto3
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = "anthropic.claude-sonnet-4-6"
# Must be >1,024 tokens for Sonnet
BASE_SYSTEM_PROMPT = "Your long instructions here..."
system_configuration = [
{"text": BASE_SYSTEM_PROMPT},
{"cachePoint": {"type": "default"}}
]
conversation_history = []
def run_chat_turn(user_input):
global conversation_history
conversation_history.append(
{"role": "user", "content": [{"text": user_input}]}
)
response = bedrock.converse(
modelId=MODEL_ID,
system=system_configuration,
messages=conversation_history,
inferenceConfig={"maxTokens": 500, "temperature": 0.4}
)
assistant_message = response["output"]["message"]
conversation_history.append(assistant_message)
metrics = response["usage"]
print(f"Read from cache: {metrics.get('cacheReadInputTokens', 0)}")
cachePoint Bedrock-কে জানায় যে অপরিবর্তনীয় অংশটি কোথায় শেষ হয়েছে। প্রথম কলের পরে, cacheReadInputTokens মেট্রিকটি একটি নন-জিরো (non-zero) মান দেখাবে, যা নিশ্চিত করে যে ক্যাশটি সফলভাবে ব্যবহৃত হয়েছে।
ডেভেলপারদের কেন এটি নিয়ে ভাবা উচিত
স্থির নির্দেশাবলীকে ডাইনামিক ইউজার ইনপুট থেকে আলাদা করার মাধ্যমে কাজটিকে ব্যয়বহুল GPU সাইকেল থেকে একটি হালকা রাউটিং ধাপে নিয়ে আসা হয়। চ্যাটবট, রিট্রিভাল-অগমেন্টেড জেনারেশন (RAG) পাইপলাইন, বা যে কোনো সার্ভিস যা একই সিস্টেম প্রম্পট বারবার ব্যবহার করে, তাদের জন্য এর ফলাফল হলো দ্রুততর রেসপন্স এবং কম বিলযোগ্য টোকেন সংখ্যা। উচ্চ-থ্রুপুট (high-throughput) পরিস্থিতিতে, কম্পিউট টাইম বা গণনার সময়ের সামান্য হ্রাসও উল্লেখযোগ্য খরচ সাশ্রয় করতে পারে।
সীমাবদ্ধতা এবং ট্রেড-অফ
এই ফিচারটি তখনই কার্যকর হয় যখন প্রম্পট সেগমেন্টটি নির্ধারিত সর্বনিম্ন টোকেন সংখ্যা পূরণ করে এবং অপরিবর্তিত থাকে। যেসব অ্যাপ্লিকেশন ঘন ঘন সিস্টেম নির্দেশাবলী পরিবর্তন করে বা ছোট প্রম্পটের ওপর নির্ভর করে, তারা খুব সামান্যই সুবিধা পাবে। পাঁচ মিনিটের উইন্ডো থাকার অর্থ হলো, দীর্ঘ বিরতিযুক্ত বা হঠাৎ আসা ট্রাফিক (bursty traffic) বারবার 'কোল্ড রিড' ঘটাতে পারে, যা ল্যাটেন্সির সুবিধা কমিয়ে দেয়। পরিশেষে, ক্যাশটি GPU মেমরিতে থাকে; যদি একাধিক মডেল একই হার্ডওয়্যার শেয়ার করে, তবে কনটেনশন (contention) পারফরম্যান্সে প্রভাব ফেলতে পারে, যদিও Bedrock সেই বিস্তারিত তথ্য প্রকাশ করে না।
পরবর্তীতে যা খেয়াল রাখতে হবে
- মেট্রিক ড্যাশবোর্ড – ক্যাশটি সঠিকভাবে ব্যবহৃত হচ্ছে কিনা তা যাচাই করতে
cacheReadInputTokensএবং সামগ্রিক ল্যাটেন্সির ওপর নজর রাখুন। - প্রম্পট ইঞ্জিনিয়ারিং – রিকোয়েস্টকে অতিরিক্ত বড় না করে টোকেন থ্রেশহোল্ড পূরণ করে এমন প্রম্পট ডিজাইন করা ডেভেলপারদের জন্য একটি নতুন দক্ষতা।
- ভবিষ্যৎ সম্প্রসারণ – যদি Bedrock ক্যাশ করার সময়সীমা বাড়ায় বা টোকেন লিমিট শিথিল করে, তবে দীর্ঘস্থায়ী কথোপকথনের খরচ আরও কমে আসতে পারে।
সারকথা: প্রম্পট ক্যাশিং Claude 4.6 ব্যবহারকারীদের রেসপন্স টাইম এবং খরচ উভয়ই কমানোর একটি কার্যকর উপায় প্রদান করে, যদি তারা একটি যথেষ্ট বড় এবং অপরিবর্তনীয় প্রম্পট নিশ্চিত করতে পারে এবং স্বল্প সময়ের ব্যবধানে কলগুলো বজায় রাখতে পারে। যে কোনো GenAI সার্ভিসের জন্য যা একই সিস্টেম নির্দেশাবলী বারবার ব্যবহার করে, এই ফিচারটি দ্রুত পরীক্ষা করে দেখা উচিত।