আমি মাত্র 3.2 GB RAM সম্পন্ন একটি ল্যাপটপে শুধুমাত্র plain C99 এবং একটি NVMe ড্রাইভ ব্যবহার করে একটি 284-billion-parameter ল্যাঙ্গুয়েজ মডেল চালাতে সক্ষম হয়েছি। কৌশলটি ছিল পুরো 160 GB চেকপয়েন্টটি মেমরিতে লোড করার পরিবর্তে মডেলের expert weights গুলোকে stream করা, যা প্রমাণ করে যে এমনকি সবচেয়ে বড় mixture-of-experts (MoE) মডেলগুলোকেও সাধারণ কনজিউমার হার্ডওয়্যারে ব্যবহার করা সম্ভব।

কেন এটি গুরুত্বপূর্ণ

Large language models (LLMs) কোড জেনারেশন, রিসার্চ অ্যাসিস্ট্যান্স এবং আরও অনেক কিছু করতে সাহায্য করে, কিন্তু তাদের বিশাল আকার সাধারণত ব্যবহারকারীদের ব্যয়বহুল multi-GPU সার্ভার অথবা ভারী quantisation ব্যবহার করতে বাধ্য করে, যা মডেলের গুণমান কমিয়ে দেয়। একটি 284 B-প্যারামিটার MoE মডেল মাত্র কয়েক গিগাবাইট RAM-এ চলতে পারে তা দেখানো শখের ব্যবহারকারী (hobbyists), ছোট স্টার্টআপ এবং সীমিত বাজেটের গবেষকদের জন্য গুণমান বজায় রেখে state-of-the-art মডেল নিয়ে পরীক্ষা-নিরীক্ষা করার পথ খুলে দেয়।

মডেল এবং হার্ডওয়্যার বাধা (bottleneck)

DeepSeek-V4-Flash প্রতিটি transformer layer-এ 256 জন expert-এর মাধ্যমে 284 B প্যারামিটার সংরক্ষণ করে। এর raw checkpoint ডিস্কে প্রায় 160 GB জায়গা দখল করে—যা একটি সাধারণ ল্যাপটপের 3.2 GB RAM-এর তুলনায় বিশাল। প্রথাগত inference pipeline পুরো চেকপয়েন্টটিকে মেমরিতে ম্যাপ করার চেষ্টা করে, যা দ্রুত RAM শেষ করে ফেলে এবং সিস্টেম ক্র্যাশ ঘটায়।

Streaming expert weights: মূল ধারণা

MoE আর্কিটেকচার প্রতিটি token-এর জন্য শুধুমাত্র একদল ছোট subset expert-কে সক্রিয় করে। DeepSeek-V4-Flash-এ, router প্রতি layer-এ 256 জন expert-এর মধ্যে ছয়জনকে নির্বাচন করে। যেহেতু গণনা (computation) কখনোই নিষ্ক্রিয় (dormant) expert-দের স্পর্শ করে না, তাই inference engine তাদের লোড করা বাদ দিতে পারে।

এই ইমপ্লিমেন্টেশনে checkpoint-টিকে একটি streaming source হিসেবে বিবেচনা করা হয়েছে। যখন router সিদ্ধান্ত নেয় যে বর্তমান token-এর জন্য কোন expert-দের প্রয়োজন, তখন engine সেই weight block-গুলোকে NVMe ড্রাইভ থেকে RAM-এ থাকা একটি LRU (least-recently-used) cache-এ নিয়ে আসে। যদি cache যথেষ্ট বড় হয়, তবে পরপর token-গুলোর জন্য একই expert-দের পুনরায় ব্যবহার করা হয়, যা cache hits তৈরি করে; আর যদি cache খুব ছোট হয়, তবে engine-টিকে বারবার disk থেকে পড়তে হয়। এর ফলে peak memory footprint দাঁড়ায় মাত্র 3.23 GB, যা ল্যাপটপের সীমার মধ্যেই থাকে, এবং এটি full-precision weights সংরক্ষণ করে কোনো GPU acceleration ছাড়াই কাজ করে।

ইমপ্লিমেন্টেশন থেকে অর্জিত কঠিন শিক্ষাগুলো

1. সাবলীল আউটপুট মানেই সঠিকতা নয় একটি buggy kernel তবুও বিশ্বাসযোগ্য মনে হতে পারে এমন বাক্য তৈরি করতে পারে, বিশেষ করে যখন মডেলের ল্যাঙ্গুয়েজ প্যাটার্নগুলো গাণিতিক ত্রুটিগুলোকে ঢেকে দেয়। আমি 14টি গুরুত্বপূর্ণ অপারেশনকে একটি নতুন PyTorch reference-এর সাথে যাচাই করেছি এবং নিশ্চিত করেছি যে গাণিতিক পার্থক্য একটি অত্যন্ত ক্ষুদ্র সীমার (tolerance) মধ্যে আছে। এই ধাপটি বাদ দিলে সূক্ষ্ম বিচ্যুতিগুলো (subtle drift) ধরা পড়ত না।

2. সাধারণ ব্যর্থতার ধরন আপনার টেস্টকে বিভ্রান্ত করতে পারে একটি memory-corruption bug রাউটিং পছন্দগুলোকে মাত্র কয়েকজন expert-এর মধ্যে সীমাবদ্ধ করে ফেলেছিল, যা cache-hit rate 52% থেকে বাড়িয়ে 95% করে দিয়েছিল এবং একটি বিশাল গতি বৃদ্ধির বিভ্রম তৈরি করেছিল। যেহেতু test suite একই ত্রুটিপূর্ণ কোডের দুটি ভার্সন তুলনা করছিল, তাই এটি সমস্যাটি ধরতে পারেনি। এর সমাধান হলো একটি স্বাধীন reference path যোগ করা—এমন কোড যা মূল ইমপ্লিমেন্টেশনের সাথে কোনো লজিক শেয়ার করে না—যাতে কোনো সাধারণ ত্রুটি নজর এড়িয়ে না যায়।

3. অপ্টিমাইজ করার আগে পরিমাপ করুন আমি ধরে নিয়েছিলাম একটি memory copy করতে 1 ms সময় লাগে এবং সেটি অপ্টিমাইজ করতে সময় ব্যয় করেছিলাম। Profiling থেকে দেখা গেছে যে অপারেশনটি আসলে 3.6 ms সময় নেয়, যা মোট inference সময়ের 22%। শিক্ষাটি হলো: পারফরম্যান্স-ক্রিটিক্যাল সেকশনগুলোর জন্য কখনোই অনুমানের ওপর নির্ভর করবেন না; সঠিক পরিমাপই একমাত্র নির্ভরযোগ্য নির্দেশিকা।

4. তাপমাত্রার অবস্থা থ্রুপুটকে নাটকীয়ভাবে প্রভাবিত করে একটি "heat-soaked" ল্যাপটপে benchmark চালানোর ফলে রানটাইম একটি ঠান্ডা মেশিনের তুলনায় তিনগুণ পর্যন্ত ধীর হয়ে গিয়েছিল। উচ্চ তাপমাত্রা NVMe ড্রাইভের থ্রুপুট কমিয়ে দেয় এবং CPU-কে ধীর করে দেয়, যা ফলাফলকে প্রভাবিত করে। আপনি যখনই পারফরম্যান্সের সংখ্যা প্রকাশ করবেন, তখনই সিস্টেমের তাপমাত্রার অবস্থা (thermal state) রেকর্ড করে রাখুন।

পরিসংখ্যানগুলো কেমন

  • ডিস্কে মডেলের আকার: ~160 GB
  • সর্বোচ্চ RAM ব্যবহার: 3.23 GB
  • প্রতি token-এ expert: 6 (256 জনের মধ্যে)
  • Cache-hit rate: RAM-এর সাথে পরিবর্তিত হয়; 3.2 GB-তে এটি ওঠানামা করে।
  • কোনো quantisation নেই: full-precision weights stream করা হয়, যা মডেলের গুণমান বজায় রাখে।

যদি RAM বাজেট প্রায় 3.21 GB-এর নিচে নেমে যায়, তবে cache কখনোই পূর্ণ হয় না এবং engine প্রতিটি token-এর জন্য stream করতে থাকে, যার ফলে পারফরম্যান্স মারাত্মকভাবে কমে যায়।

সোর্স কোডটি github.com/ronak-create/deepseek-v4-in-c-এ জনসমক্ষে উপলব্ধ। যারা এই পরীক্ষাটি পুনরায় করতে বা আরও সম্প্রসারিত করতে চান, তাদের জন্য t.me/GyaanSetuAi-তে একটি কমিউনিটি ডিসকাশন চ্যানেল রয়েছে।

সারসংক্ষেপ

একটি MoE মডেল প্রকৃতপক্ষে যে এক্সপার্টদের ব্যবহার করে শুধুমাত্র তাদেরই স্ট্রিম করার মাধ্যমে একটি 284 B-প্যারামিটারের LLM কোনো কোয়ান্টাইজেশন বা GPU অ্যাক্সিলারেশন ছাড়াই একটি সাধারণ ল্যাপটপে চালানো সম্ভব হচ্ছে। এই পরীক্ষাটি দেখায় যে, চতুর ডেটা মুভমেন্ট, কঠোর যাচাইকরণ এবং সুশৃঙ্খল পরিমাপের মাধ্যমে সেই হার্ডওয়্যার সীমাবদ্ধতাগুলোকে এড়িয়ে যাওয়া সম্ভব যেগুলোকে অনেকে অপরিবর্তনীয় বলে মনে করেন।