ডেস্কটপে ১২৮k কনটেক্সট মিথ্যা। KV ক্যাশ তা খেয়ে ফেলেছে।

প্রতিটি লোকাল মডেল কার্ড এখন 128k কনটেক্সট নিয়ে ফুরফুরে ওঠে। ডেস্কটপে সেই সংখ্যাটা এমন এক লিজ, যার শর্ত না পড়েই আপনার RAM সই কেটে দিয়েছে। লম্বা ডকুমেন্ট কতদূর ঠেলে নেবেন তা ঠিক করে ওয়েট নয় — KV ক্যাশ, আর সে কনটেক্সটের সঙ্গে এমনভাবে বাড়ে যেন অন্যের মুদ্রায় সাজানো কোনো কর।

কনটেক্সট উইন্ডো এমন কোনো ফিচার নয় যা চালু-বন্ধ করেন। এ মেমরির লিজ — সার্ভার চলার প্রতিটি সেকেন্ডে কিস্তি যায়।

128k কনটেক্সট আসলে কত RAM খায়?

গণিতটা প্রকাশ্য এবং ছোট। Transformer Inference Arithmetic যেমন বোঝায়, KV ক্যাশ প্রতি লেয়ারে, প্রতি KV হেডে, প্রতি টোকেনে দুটি টেনসর রাখে — key ও value:

cache_bytes = 2 × লেয়ার × কনটেক্সট × kv_হেড × head_dim × প্রতি_উপাদানে_বাইট

Llama 3.1 8B নিন: 32 লেয়ার, 8 KV হেড, head_dim 128 — সরাসরি Hugging Face-এর config.json থেকে। fp16 (2 বাইট)-এ 131,072 টোকেনে:

2 × 32 × 131072 × 8 × 128 × 2 = 17,179,869,184 বাইট ≈ 16 GiB

একই মডেলের fp16 ওয়েট প্রায় 16 GiB। সর্বোচ্চ কনটেক্সটে ক্যাশ ঠিক তার মতোই বড়, যার সে অংশ। “16 GiB-এ ঢোকে এমন 8B মডেল” num_ctx 128k-এ তোলার মুহূর্তে নিঃশব্দে 32 GiB-এর সমস্যা হয়ে দাঁড়ায়।

ক্যাশ উইন্ডোর সঙ্গে বাড়ে কেন?

কারণ অ্যাটেনশনকে প্রতিটি টোকেনকে তার আগের সব টোকেনের সঙ্গে মেলাতে হয়, আর ইনফারেন্স অটোরিগ্রেসিভ — কিছুই নতুন করে গোনা হয় না, সব মনে রাখা হয়। জেনারেশন দ্রুত করার পুরো কৌশলই এটুকু: প্রতিটি টোকেনের key ও value একবার গোনা হয়, জমা থাকে। প্রতি টোকেনে স্টোরেজ ধ্রুবক, তাই মোট জায়গা কনটেক্সটের সঙ্গে রৈখিক বাড়ে। 128k মানে “সংখ্যাটা বড়” নয় — 1k উইন্ডোর ক্যাশের ১২৮ গুণ, পুরো সেশন জুড়ে জিম্মায় রাখা।

Grouped-query attention (GQA) মডেল-পাশের ছাড়: কম KV হেড, রোগা ক্যাশ। Qwen2.5 7B-এ ২৮ লেয়ারে মাত্র ৪টি KV হেড (config এখানে), তাই একই 128k উইন্ডো fp16-তে প্রায় 7 GiB — সত্যিকারের স্বস্তি, আর এসব মডেল সাধারণ মেশিনে বন্ধুসুলভ লাগার একটা কারণ।

মডেল (fp16)	লেয়ার × KV হেড	KV ক্যাশ @ 128k	ওয়েট	ক্যাশ বনাম ওয়েট
Llama 3.1 8B	32 × 8	~16 GiB	~16 GiB	~100%
Qwen2.5 7B	28 × 4	~7 GiB	~15 GiB	~47%

হিসেবটা নিজে চালান — যাচাইয়ের পুরোটাই এই:

def kv_cache_gib(layers, kv_heads, head_dim, ctx, bytes_per=2):
    return 2 * layers * ctx * kv_heads * head_dim * bytes_per / 2**30

print(kv_cache_gib(32, 8, 128, 131_072))  # Llama 3.1 8B  -> 16.0
print(kv_cache_gib(28, 4, 128, 131_072))  # Qwen2.5 7B    -> 7.0

মার্কেটিংয়ের সংখ্যাটা কী বলে না

এই যুক্তির সৎ হিসাবখাতা এই — যেখানে সে বেঁকে যায়, সেসবসহ:

• prefill দ্বিতীয় বিল। প্রথম উত্তর-টোকেনের আগে পুরো প্রম্পট এক নিঃশ্বাসে প্রসেস হয়। 100k টোকেনের প্রম্পট মানে প্রথম অক্ষর দেখার আগে 100k টোকেন চিবানো। 3060-এ সেটা মিলিসেকেন্ড নয়, মিনিট।
• sliding-window মডেল হিসেবটা ভাঙে — আপনার পক্ষে। Mistral-ঘরানার আর্কিটেকচার প্রতি লেয়ারে অ্যাটেনশনকে স্থির উইন্ডোতে আটকে রাখে, ক্যাশ অন্ত্যন্ত বাড়ে না। সরল সূত্র তাদের বাড়াবাড়ি করে দেখায়। এই লেখা ফুল-অ্যাটেনশন ট্রান্সফরমার নিয়ে — মানুষ যা চালায়, তার বেশিরভাগই তাই।
• KV কোয়ান্টাইজেশন সত্যি, কিন্তু আংশিক। llama.cpp KV কে q8_0-এ রাখতে পারে — ক্যাশ প্রায় অর্ধেক, কিছু মানের ঝুঁকিতে। 16 GiB-এর অর্ধেকও 8 GiB।
• স্পেকশিটে KV হেড লেখাই হয় না। config.json খুঁড়তে হয় — নিজেই বলে দেয় সংখ্যাটা কীভাবে পড়া চাওয়া হয়।

এর কোনোটাই লম্বা কনটেক্সটকে অপ্রয়োজনীয় করে না। RAG এজন্যই যে উইন্ডো ভরে “সেকশন ৪ পড়ো” বলা দামি রাস্তা। কিন্তু যে কার্ড “128k” ছাপে আর মেমরির বিল ছাপে না, সে গাড়ি বেচে সর্বোচ্চ গতি দেখিয়ে, ট্যাংকির প্রসঙ্গ একবারও তোলে না।

কেউ 128,000 টোকেন পড়ে না। তবুও আপনার RAM সবগুলোর বিল দেয়।

প্রতিকার একঘেয়ে: কনটেক্সট রাখুন আপনার কাজ যতটুকু সত্যিই ব্যবহার করে। 32k উইন্ডোর খরচ 128k ক্যাশের এক-চতুর্থাংশ, আর একা এক ডেভেলপারের পাঠানো প্রায় সব প্রম্পটই ঢেকে যায়। এটা লোকাল LLM-এর RAM গণিত-এরই হিসাব-শৃঙ্খলা — মডেলের সাইজ বাজেটের অর্ধেক, আর কোয়ান্টাইজেশন লেভেল ওয়েট ছোট করে, ক্যাশের হিসেব ছোঁয় না।

ক্যাশই যদি কনটেক্সটের আসল দাম হয়, কার্ডগুলো উইন্ডো বেচে কেন, বিল বেচে না কেন? আর স্বীকারোক্তির পালা: শেষ টোকেন পর্যন্ত সত্যিই ভরাট করা সবচেয়ে বড় কনটেক্সট কোনটা — আউটপুট কি গিগাবাইটের মূল্য ফিরিয়েছে? কমেন্ট খোলা; সিরিজের পরের লেখা হারা পক্ষের পাশে দাঁড়াবে।