কার্সর ওপেন সোর্স MoK প্রয়োগ করে টোকেন স্কিডিউলিং, ক্রস-জিপিইউ যোগাযোগ এবং এক্সপার্ট কম্পিউটিংকে একই জিপিইউ কার্নেলে একীভূত করেছে। এই সমাধানটি GB300 NVL72-এ MXFP8 ফরওয়ার্ডের জন্য সর্বোচ্চ 2.37x এবং ব্যাকওয়ার্ডের জন্য 1.78x পারফরম্যান্স বৃদ্ধি অর্জন করেছে, 512টি GB300 GPU-এর মাধ্যমে ট্রেনিং থ্রুপুট 41% বৃদ্ধি পেয়ে 1070.2 টোকেন/সেকেন্ডে পৌঁছেছে। সিগনালিং ল্যাটেন্সি 103μs-এর থেকে কমে 18μs-এ নেমেছে। বিশ্লেষণগুলি নির্দেশ করছে যে, আজকাল NVLink ব্যান্ডউইথ 130 TB/s-এ পৌঁছেছে, GPU-তে ডেটার সময়ই নতুন পারফরম্যান্স বাধা হয়ে দাঁড়িয়েছে—এই বিপ্লবটি AI-এর প্রতিযোগিতাকে “সম্পূর্ণ-স্ট্যাক সুযোগ” পর্যায়ে নিয়েছে, যারা GPU-এর ডেটা মেমরি এবং রেজিস্টারের কাছাকাছি কোড লিখবে, তাদেরই বড় মূল্যনির্ধারণ ক্ষমতা থাকবে।লেখক এবং উৎস: লেইফেঙ্গওয়েন
জুলাই ২১, এনভিডিয়া ঘোষণা করেছে যে GB300 NVL72 ব্যবহার করে DeepSeek-V3 প্রশিক্ষণের সর্বশেষ ফলাফল: ২৫৬টি GPU-এ, প্রতিটি GPU-এর পারফরম্যান্স ১,৬৪৮ TFLOPS পৌঁছেছে।
দুই সপ্তাহের কম সময়ের মধ্যে, Cursor মিক্সচার-অফ-কিটেন্স, বা MoK ওপেন সোর্স করেছে। এটি আরও দ্রুত ম্যাট্রিক্স গুণনের জন্য আরও চেষ্টা করেনি, বরং একটি MoE একecিউশন লেয়ারকে পুনর্লিখন করেছে, যেখানে token স্কিডিউলিং, গুগল মধ্যে যোগাযোগ এবং এক্সপার্ট ক্যালকুলেশন একই GPU কার্নেলের মধ্যে ঢুকিয়ে দেওয়া হয়েছে।
এটি কিছুটা বিপরীতমুখী। কারণ GB300 NVL72 একই NVLink ডোমেইনে 72টি GPU রাখেছে, যার ফলে পুরো র্যাকের NVLink মোট ব্যান্ডউইথ 130 TB/s পৌঁছেছে। এই স্পেসিফিকেশন অনুযায়ী, GPU গুলির মধ্যে ডেটা ট্রান্সফার ইতিমধ্যেই যথেষ্ট দ্রুত হওয়া উচিত।
বড় পরিসরের MoE প্রশিক্ষণে, যোগাযোগ এখনও বিশেষজ্ঞ গণনাকে ধীর করে দেয়।
সমস্যাটি MoE ডেটা ফ্লোতে। রাউটার প্রতিটি পদক্ষেপে টোকেনকে কোন এক্সপার্টে পাঠাবে তা পুনরায় নির্ধারণ করে, এবং এক্সপার্টগুলি বিভিন্ন GPU-এ বিক্ষিপ্ত। টোকেনগুলিকে প্রথমে কার্ডের মধ্যে পাঠাতে হয়, গণনা শেষ হওয়ার পর আবার ফিরিয়ে আনতে হয়; পাঠানোর আগে অবস্থানগুলি সাজাতে হয়, এবং পৌঁছানোর পর ডেটা সম্পূর্ণ হওয়ার জন্য অপেক্ষা করতে হয়। MXFP8 এবং Blackwell Tensor Core-এর কারণে এক্সপার্ট গণনা যতটা সংক্ষিপ্ত হচ্ছে, সেইসব আগে গণনার পিছনে লুকিয়ে থাকা অপেক্ষা সময়গুলি এখন আরও স্পষ্টভাবে দৃশ্যমান হচ্ছে।
কার্সর MoK করে, এটি এখান থেকে শুরু করে। এটি শুধুমাত্র একবারে ডিস্প্যাচ কত দ্রুত পাঠানো যায় তা নয়, বরং টোকেনগুলি কীভাবে বিশেষজ্ঞদের কাছে পৌঁছাবে, কখন গণনা শুরু হবে, এবং যোগাযোগ ও গণনা কীভাবে GPU-এর সাথে একসাথে ব্যবহার করা যায় তা পুনর্বিন্যস্ত করে।
আজকের দিনে, যখন ক্যালকুলেশন রিসোর্সগুলি ব্ল্যাকওয়েল এবং এনভিলিঙ্ক দ্বারা সর্বোচ্চ পর্যায়ে পৌঁছেছে, ডেভেলপাররা আবিষ্কার করেছেন: হার্ডওয়্যার যতই দ্রুত চলুক না কেন, অকার্যকর সফটওয়্যার অর্ডারিংকে উদ্ধার করতে পারে না।
MoK-এর ওপেন সোর্স শুধু একটি কোরের বিজয় নয়, এটি "অ্যাপ্লিকেশন লেয়ার ডিফাইনস অপারেটর" যুগের শুরু চিহ্নিত করে: শেষ 30% ক্যালকুলেশন ক্ষমতা চরমভাবে উত্তোলনের জন্য, AI স্টার্টআপগুলি একটি বেসমেন্ট সার্বভৌমত্বের জন্য সংগ্রাম শুরু করেছে।
কিন্তু কার্সরের এই ডিজাইন কেন কার্যকর তা বুঝতে হলে প্রথমে দেখতে হবে যে MoE কোথায় “যোগাযোগ কর” পরিশোধ করছে।
01
MoE-এর "যোগাযোগ কর"
শুধু টোকেন পাঠানোর চেয়ে অনেক বেশি
সাধারণ ঘন FFN-এ, টোকেনগুলি যে ওজনগুলি অতিক্রম করে তা প্রায় স্থির থাকে। MoE-এ রাউটার যোগ করার পর, প্রতিটি টোকেন সময়ের সাথে কয়েকজন বিশেষজ্ঞকে বাছাই করে। Expert Parallel ব্যবহার করলে, বিশেষজ্ঞদের অনেক GPU-এ বিভক্ত করা হয়, ফলে একবার ফরওয়ার্ড প্রোপাগেশনে কমপক্ষে দুটি প্রসেসিং কার্ডের মধ্যে যোগাযোগ ঘটতে হয়।
প্রথম রাউন্ডটি ডিসপ্যাচ নামে পরিচিত, যেখানে টোকেনটিকে বিশেষজ্ঞের গিপিইউতে পাঠানো হয়; বিশেষজ্ঞ গণনা সম্পন্ন করার পর, ফলাফলটি কম্বাইনের মাধ্যমে টোকেনের মূল অবস্থানে ফিরিয়ে আনা হয়। ট্রেনিংয়ের জন্য ব্যাকওয়ার্ড প্রোপাগেশনও প্রয়োজন, যার জন্য দুটি বিপরীত দিকের যোগাযোগ পুনরায় সম্পাদন করা হয়।
যদি শুধু একটি বড় অবিচ্ছিন্ন ডেটা ব্লককে A থেকে B-এ স্থানান্তর করা হয়, তাহলে NVLink যথেষ্ট দ্রুত। MoE-এর সমস্যা হলো, প্রতিটি ধাপে Router দ্বারা প্রদানকৃত ডেটা বণ্টন ভিন্ন হয়।
একজন বিশেষজ্ঞের এই ধাপে অনেক টোকেন পাওয়া যেতে পারে, আর পরবর্তী ধাপে খুব কম। সিস্টেমটিকে প্রথমে প্রতিটি বিশেষজ্ঞের কাছে কতগুলি টোকেন আছে তা গণনা করতে হবে, তারপর এই টোকেনগুলিকে লক্ষ্য GPU-এর কোথায় রাখতে হবে তা নির্ধারণ করতে হবে, এবং একই বিশেষজ্ঞের ডেটা যতটা সম্ভব একসাথে সাজাতে হবে। Grouped GEMM-এর জন্য সুসংগঠিত ইনপুট প্রয়োজন, যাতে Tensor Core-এর কাছে দক্ষতার সাথে প্রদান করা যায়।
যোগাযোগ শেষ হওয়ার পরেও তাত্ক্ষণিকভাবে গণনা শুরু করা যাবে না। লক্ষ্য GPU-কে নিশ্চিত করতে হবে যে দূরবর্তী লেখা সম্পূর্ণরূপে সম্পন্ন হয়েছে এবং ডেটা প্রকৃতপক্ষে দৃশ্যমান। বিশেষজ্ঞ লোডও সম্পূর্ণরূপে সমান নয়, কিছু GPU সম্ভবত খুব তাড়াতাড়ি শেষ করে ফেলবে, তবুও সবচেয়ে বেশি ব্যস্ত বিশেষজ্ঞের শেষ পর্যন্ত অপেক্ষা করতে হবে।
তাই একটি “যোগাযোগ” পর্যায়ে আসলে ডেটা স্থানান্তর, লেআউট জেনারেশন, সিঙ্ক্রোনাইজেশন এবং লোড অসামঞ্জস্যতা—এই কয়েকটি কাজ মিশে আছে। 130 TB/s হল পুরো র্যাক দ্বারা প্রদানকৃত শীর্ষ ব্যান্ডউইথ, যা প্রতিবার ডাইনামিক এবং ছোটখাটো MoE যোগাযোগের জন্য এই লিঙ্কগুলি একসাথে পূর্ণভাবে ব্যবহার করা হচ্ছে তা বোঝায় না।
DeepEP ইতিমধ্যেই তার ডেটা মাইগ্রেশনকে খুব দ্রুত করেছে। এটি নিজেই Expert Parallel-এর জন্য উচ্চ পারফরম্যান্স কমিউনিকেশন লাইব্রেরি, যা বিশেষায়িত Dispatch এবং Combine কোর প্রদান করে, FP8 সমর্থন করে এবং কমিউনিকেশনের জন্য ব্যবহৃত SM-এর সংখ্যা নিয়ন্ত্রণ করতে দেয়। সর্বশেষ সংস্করণটি অনেক কম SM ব্যবহার করেও উচ্চ কমিউনিকেশন থ্রুপুট বজায় রাখতে পারে।
একটি স্তর MoE এখনও ডিস্প্যাচ, গ্রুপড জেমএম এবং কম্বাইনের মধ্যে নিয়মিত হস্তান্তর করে।
একটি বাস্তবিক বিরোধ দেখা দেয়: যদি যথেষ্ট সংখ্যক টোকেন জমা হওয়ার অপেক্ষায় থাকেন, তাহলে ম্যাট্রিক্সটি বড় হয়, যাতে টেনসর কোর সহজে কাজ করে, কিন্তু গণনা দেরিতে শুরু হয়; যদি কিছুটা টোকেন আসামাত্রই গণনা শুরু করা হয়, তাহলে যোগাযোগ এবং গণনা আগে থেকেই ওভারল্যাপ হয়, কিন্তু ম্যাট্রিক্সটি খুব ছোট হয়, ফলে GPU-এর অনেক SM-এর জন্য যথেষ্ট কাজ থাকে না।
একাধিক CUDA স্ট্রিম কমিউনিকেশন এবং কম্পিউটেশনকে সমান্তরালে চালাতে পারে, তবে সবসময় দুই পক্ষকেই ঠিক পরিমাণ GPU সংস্থান প্রদান করা কঠিন।
MoK-এর পরের ডিজাইনগুলি মূলত এই "রিদম" সমস্যার সমাধানে কাজ করে।
02
টোকেন পাঠানোর সময় কিভাবে গণনা করবেন
MoK-এর সবচেয়ে আকর্ষণীয় পরিবর্তনগুলির একটি হল ফরওয়ার্ড ডিস্প্যাচকে Push থেকে Pull-এ পরিবর্তন করা।
প্রাচীন Push খুব সহজ: সোর GPU-এর কাছে যদি token থাকে, তাহলে সে সক্রিয়ভাবে এটিকে টার্গেট GPU-এ লিখে দেয়। সমস্যাটি টার্গেট ঠিকানায় দেখা দেয়। একটি GPU একসাথে অন্যান্য অনেক GPU থেকে আসা token পায়।
প্রতিটি প্রেরককে আগে থেকে জানতে হবে যে সে কোন সেকশনে লিখবে, যাতে তারা পরস্পরকে ওভাররাইট না করে; একই বিশেষজ্ঞের টোকেনগুলি ক্রমানুসারে সাজানো ভালো, অন্যথায় পরবর্তী GEMM-এর জন্য আবার পুনর্বিন্যাস করতে হবে।
যত বেশি GPU অংশগ্রহণ করবে, এই স্কিডিউলিং প্রক্রিয়াটি তত বেশি ভারী হয়ে উঠবে। পুল একটি ভিন্ন পদ্ধতি ব্যবহার করে: এক্সপার্টের লক্ষ্য GPU নিজেই প্রয়োজনীয় টোকেনগুলি পড়ে। এটি শুধুমাত্র জানে যে টোকেনটি কোন সোর GPU-এ এবং সোর ডেটার কোন অবস্থানে আছে; স্থানীয়ভাবে কোথায় সংরক্ষণ করতে হবে, তা নিজেই নির্ধারণ করে।
এটি লক্ষ্য ঠিকানার জন্য বিভিন্ন প্রেরকের মধ্যে সমন্বয়ের প্রয়োজনীয়তা কমিয়ে দেয়। প্রাপ্ত ডেটা স্থানীয় বিশেষজ্ঞদের দ্বারা সরাসরি সাজানো যেতে পারে।
আকর্ষণীয় বিষয় হলো, Pull কম ডেটা পাঠায়নি। Cursor-এর মাইক্রো-বেঞ্চমার্কে, একই 256×256 BF16 ডেটা ব্লকের জন্য, Push NVLink-এ প্রায় 159.6 KB স্থানান্তর করে, কিন্তু Pull পৌঁছায় 172.0 KB, কারণ পড়ার জন্য অতিরিক্ত অনুরোধ পাঠাতে হয়।
পুলের সুবিধা হল অন্য একটি বিষয়: MoE-এর যোগাযোগ খণ্ডিত এবং লোড অসমভাবে বণ্টিত। NVLink-এর দুটি দিকের জন্য পৃথক চ্যানেল রয়েছে, যার ফলে পুল একইসাথে অনুরোধ এবং ডেটা ফিরতি দুটি দিককেই ব্যবহার করতে পারে। এক্সপার্ট লোড অসমতা পরীক্ষায়, Cursor-এ 29% পর্যন্ত NVLink ব্যবহারের উন্নতি দেখা গেছে।
সিঙ্ক্রোনাইজেশনের ব্যবধানটি আরও স্পষ্ট। পুশ শেষ হওয়ার পর, লক্ষ্য GPU-কে অন্যান্য GPU-এর সম্পূর্ণ হওয়ার সংকেত অপেক্ষা করতে হয়, এক্সপার্ট প্যারালালের আকার বড় হলে, একটি র্যাঙ্ক সর্বোচ্চ 71টি পিয়ারের সাথে জড়িয়ে পড়তে পারে। পুল হল স্থানীয় GPU-এর নিজস্ব পড়ার শুরু, ডেটা ফিরে আসার পর সরাসরি ব্যবহার করা যায়।
কার্সরের মাল্টি-নোড মাইক্রোবেঞ্চমার্কে, এই সিগনালিং ল্যাটেন্সি পুশের প্রায় 103 মাইক্রোসেকেন্ড থেকে পুলের 18 মাইক্রোসেকেন্ডে কমেছে।
MoK সব জায়গায় Pull ব্যবহার করে না। ফরওয়ার্ড পথে Pull Dispatch এবং Push Combine ব্যবহার করা হয়; রিভার্স পথে Pull Reverse-Combine এবং Push Reverse-Dispatch ব্যবহার করা হয়। Dispatch পর্যায়ে অনেকগুলি সোর্সের token-কে একত্রিত করে এক্সপার্ট ইনপুটে পুনর্গঠন করতে হয়, যেখানে Pull সমন্বয়ের জন্য কম সম্পদ নেয়; Combine পর্যায়ে প্রতিটি ফলাফল কোন token-এর দিকে ফিরে যাবে তা পরিষ্কারভাবে জানা যায়, তাই সরাসরি Push করা সহজ।
যোগাযোগের দিক পরিবর্তনের পরেও, MoK যোগাযোগ এবং বিশেষজ্ঞ গণনাকে একই Megakernel-এ রাখে।
এটি GPU-এর SM-কে দুটি অংশে বিভক্ত করে। একটি অংশ ডিসপ্যাচ, কম্বাইন এবং স্টেট ম্যানেজমেন্টের জন্য দায়ী, অন্যটি শুধুমাত্র Expert FFN বাস্তবায়নের জন্য। কমিউনিকেশন সাইড একটি পূর্ণাঙ্গ টোকেন ব্যাচ পেলে, GPU-এর লোকাল কাউন্টারের মাধ্যমে কম্পিউটেশন সাইডকে জানায়; কম্পিউটেশন শেষ হলে, ফলাফলটি ফিরিয়ে দেওয়ার জন্য কমিউনিকেশন সাইডকে আবার জানায়।
এটি সরাসরি কমিউনিকেশনের জন্য কতগুলি SM এবং ক্যালকুলেশনের জন্য কতগুলি SM বরাদ্দ করতে দেয়, যাতে এটি একাধিক CUDA Stream-এর মধ্যে প্রতিযোগিতার উপর সম্পূর্ণভাবে ছেড়ে না দেওয়া হয়। এখানে সবচেয়ে গুরুত্বপূর্ণ প্যারামিটারটি হল minbatch, যা একবারে একজন এক্সপার্টকে কতগুলি token দেওয়া হয়।
এটি খুব বড় হতে পারে না। খুব বড় হলে প্রথম গণনাগুলির জন্য দীর্ঘ সময় অপেক্ষা করতে হবে। এটি খুব ছোটও হতে পারে না। বিশেষজ্ঞ GEMM শেষ পর্যন্ত অসংখ্য গণনা কাজে বিভক্ত হয়ে SM-এর মধ্যে বিতরণ করা হয়, যদি token-এর সংখ্যা খুব কম হয়, তাহলে কাজের সংখ্যা অপর্যাপ্ত হবে এবং অনেক SM অকর্মণ্য থাকবে।
কার্সর এই সীমানা নির্ধারণের জন্য ওয়েভ ব্যবহার করে। একটি পূর্ণাঙ্গ ওয়েভ হল যেখানে সমস্ত SM-এর জন্য কাজ বণ্টন করা হয়। MoK চায় যে একটি মিনিব্যাচে কমপক্ষে দুটি পূর্ণাঙ্গ ওয়েভ গঠিত হোক, যাতে Tensor Core-এর জন্য পর্যাপ্ত কাজ স্থায়ীভাবে উপলব্ধ থাকে।
বাস্তব ফলাফলটি খুব স্পষ্ট। Kimi 2.5 আকৃতির হিডেন সাইজ 7168 এবং এক্সপার্ট মিডিয়াম ডাইমেনশন 2048 এর জন্য, Cursor অনুমান করে যে minbatch-এর জন্য কমপক্ষে প্রায় 2368টি টোকেন প্রয়োজন। 512 টোকেনের জন্য MoK ফরওয়ার্ড সময় 5.981 মিলিসেকেন্ড; 2560 টোকেনে বাড়ানোর পরে, এটি 3.425 মিলিসেকেন্ডে কমে যায়। আরও বাড়ালে, গতির কোনও উল্লেখযোগ্য উন্নতি হয়নি।
অর্থাৎ, যোগাযোগকে আরও ছোট ছোট টুকরোতে ভাগ করলে সবসময় দ্রুত হয় না। প্রকৃতপক্ষে কার্যকরী ওভারল্যাপিং-এর জন্য যোগাযোগকে শীঘ্রই ডেটা দিতে হবে, কিন্তু GEMM-কে খুব ছোট করে ভাগ করা উচিত নয়।
কিন্তু MoE-এর আরেকটি সমস্যা হল: রাউটার শেষ হওয়ার আগে, প্রতিটি GPU-এ চূড়ান্তভাবে কতগুলি টোকেন পৌঁছাবে তা কোনোভাবেই জানা যায় না।
সর্বাধিক খারাপ পরিস্থিতির জন্য বাফার প্রস্তুত করলে অনেক জিপিইউ মেমোরি বর্জ্য হবে। যদি প্রথমে জিপিইউ টোকেন গণনা করে তারপর সিপিইউকে সংশ্লিষ্ট স্থান আবদ্ধ করার জন্য জানায়, তাহলে জিপিইউকে সিপিইউর জন্য অপেক্ষা করতে হবে।
MoK একটি স্থির আকারের Ring Token Buffer ব্যবহার করে। একটি স্পেস প্রথমে Dispatch দ্বারা আসা token গুলির জন্য ব্যবহার করা হয়, এবং এক্সপার্ট গণনা শেষ করে Combine ফলাফলটি পাঠানোর পর, সেই স্পেসটি তৎক্ষণাৎ পরবর্তী token ব্যাচের জন্য পুনরায় ব্যবহার করা হয়। একটি macrobatch-এর Combine প্রক্রিয়াটি পরবর্তী macrobatch-এর Dispatch-এর সাথে একসাথে চলতে পারে।
এখানে রিং বাফার একটি বাফার স্তরের মতো: যখন যোগাযোগ দ্রুততর হয়, তখন ডেটা এর মধ্যে জমা হয়; যখন গণনা দ্রুততরভাবে সম্পন্ন হয়, তখন পরবর্তী ব্যাচের token-এর জন্য অপেক্ষা করা হয়। সমগ্র প্রক্রিয়াটি GPU-এর উপর অবস্থার প্রগতির মাধ্যমে পরিচালিত হয়, যার ফলে CPU-কে প্রতিটি চক্রে পরবর্তী পদক্ষেপ নির্ধারণের জন্য আসতে হয় না।
কার্সর এখন MXFP8 এক্টিভেশনের কোয়ান্টাইজেশনকে ডিস্প্যাচ, গ্রুপড জেমএম এবং সুইজিএলইউ-এর ডেটা পাথে একীভূত করেছে, যার ফলে স্বতন্ত্র কোয়ান্টাইজ কার্নেল এবং HBM-এর মধ্যে মধ্যবর্তী ফলাফলের একবারের বেশি পড়া-লেখা এড়ানো হয়েছে।
পুল, মিনিব্যাচ, এসএম পার্টিশন এবং রিং বাফারকে একত্রিত করার পরে, মোক প্রকৃতপক্ষে একটি নিরবচ্ছিন্ন মোই পাইপলাইনে পরিণত হয়।
03
একটি অত্যন্ত বিশেষায়িত বাস্তবায়ন প্যাকেজ
কার্সরের বেঞ্চমার্কটি সম্পূর্ণ MoE স্তরকে পরীক্ষা করে, যার মধ্যে রয়েছে স্কিডিউল, ডিসপ্যাচ, এক্সপার্ট FFN, কম্বাইন এবং শেষের ওজনযুক্ত একীভূতকরণ, যার তুলনা করা হয়েছে NCCL + PyTorch, DeepEP, TransformerEngine এবং HybridEP + Megatron-এর সাথে।
GB300 NVL72-এ, MoK-এর MXFP8 ফরওয়ার্ডে সর্বোচ্চ 2.37 গুণ এবং ব্যাকওয়ার্ডে সর্বোচ্চ 1.78 গুণ উন্নতি পাওয়া যায়, যখন প্রতিটি সিনেরিওর দ্রুততম পাবলিক বেসলাইনের সাথে তুলনা করা হয়; BF16 ফরওয়ার্ড এবং ব্যাকওয়ার্ডে সর্বোচ্চ যথাক্রমে 1.92 গুণ এবং 1.58 গুণ উন্নতি পাওয়া যায়।
আরও গুরুত্বপূর্ণ হল এন্ড-টু-এন্ড ট্রেনিং। কার্সরের মূল উৎপাদন সমাধানে ইতিমধ্যেই DeepEP ব্যবহার করা হচ্ছে। 512টি GB300 GPU-এ, MoK-এ স্যুইচ করার পর, প্রতি কার্ডের থ্রুপুট 760.9টি টোকেন/সেকেন্ড থেকে বেড়ে 1070.2টি টোকেন/সেকেন্ড হয়েছে, যা প্রায় 41% বৃদ্ধি।
এই ফলাফলগুলির সীমানা স্পষ্টভাবে বুঝতে হবে। কারণ কার্সর পূর্ণাঙ্গ পদক্ষেপভিত্তিক অপসারণ প্রকাশ করেনি, তাই 2.37 গুণের মধ্যে কতটা পুল, কতটা মেগাকার্নেল এবং কতটা রিং বাফার থেকে এসেছে, তা সঠিকভাবে বলা সম্ভব নয়।
পুল দ্বারা NVLink ব্যবহার এবং সিগন্যালিং ল্যাটেন্সির উন্নতি একা প্রমাণিত হয়েছে, বাকি সুবিধাগুলি বেশিরভাগই সম্পূর্ণ বাস্তবায়ন পদ্ধতির সমন্বয়ের ফলে পাওয়া যায়।
MoK-এর হার্ডওয়্যারের উপর প্রচুর নির্ভরশীলতা রয়েছে। এটি Blackwell এবং NVL72-এর মতো হাই-স্পিড NVLink ডোমেইনের জন্য ডিজাইন করা হয়েছে। রিমোট রিড, কমিউনিকেশন এবং কম্পিউটেশনের সূক্ষ্ম গ্রেনুলারিটির ইন্টারলিভিং সমস্তই GPU-গুলির মধ্যে পরস্পরের VRAM-এ লো-ল্যাটেন্সি অ্যাক্সেসের উপর নির্ভর করে। মডেলের Hidden Size, Top-k, এবং এক্সপার্ট সাইজ পরিবর্তন হলে, উপযুক্ত minibatch এবং কমিউনিকেশন SM-এর সংখ্যা ও পরিবর্তিত হয়।
এটিই MoK-এর সবচেয়ে গুরুত্বপূর্ণ দিক। অতীতে MoE অপ্টিমাইজেশন নিয়ে আলোচনা করার সময়, আমরা সহজেই দুটি সংখ্যার দিকে মনোযোগ দিতাম: GEMM-এর কত TFLOPS, All-to-All-এর কত GB/s। GB300-এর এই প্রজন্মে, শুধু এই দুটি সংখ্যা আরও বাড়ানো দিয়ে সম্পূর্ণ পারফরম্যান্সকে ব্যাখ্যা করা যায় না।
টোকেন কখন আসবে, এক্সপার্টদের প্রয়োজনীয় বিন্যাসে কিভাবে সাজানো হবে, কতটা জমা করলে গণনা শুরু হবে, যোগাযোগে কতটা SM নেওয়া হবে, buffer কখন মুক্ত হবে—এই সমস্ত বাস্তবায়ন বিস্তারিতগুলি প্রশিক্ষণের গতি সরাসরি নির্ধারণ করে।
130 TB/s NVLink ব্যান্ডউইথ সহ একটি র্যাক, শেষ পর্যন্ত GPU কার্নেলগুলি পুনর্লিখনের প্রয়োজন হয় কারণ লিঙ্কগুলি ইতিমধ্যেই খুব দ্রুত—এখন যা বাঁচানোর প্রয়োজন, তা হল GPU-এর মতো ডেটা প্রক্রিয়াকরণের সময়।
কার্সর জিপিইউ কোর পুনর্লিখনের আচরণ, যা এআই 2.0 যুগের প্রতিযোগিতাকে "স্ট্যাক-সম্পূর্ণ সার্বভৌমত্ব" এর নতুন পর্যায়ে নিয়ে আসে।
আগে, আমরা বিশ্বাস করতাম যে “প্রতিটি কাজের জন্য বিশেষজ্ঞ থাকা উচিত”, অ্যাপ্লিকেশন তৈরি করতে হলে অ্যাপ্লিকেশনই তৈরি করতে হবে (Cursor), লোয়ার-লেভেল তৈরি করতে হলে লোয়ার-লেভেলই তৈরি করতে হবে (NVIDIA)। কিন্তু আজকের AI প্রতিযোগিতা “মধ্যস্বত্বহীনকরণ”-এর নতুন পর্যায়ে পৌঁছেছে, Cursor কেবল “করতে চাই”-এর কারণেই কোর তৈরি করছে না, বরং “করতে হচ্ছে”-এর কারণে।
ডিপসিক ইঞ্জিনিয়ারিং এক্সট্রাকশনের একটি নতুন যুগ শুরু করেছে, আর কার্সর এই আগুনকে অ্যাপ্লিকেশন লেয়ারে নিয়ে এসেছে। এই “মধ্যস্বত্বহীনকরণ” প্রবণতা AI-এর মূল্যনির্ধারণ ক্ষমতাকে পুনরায় গঠন করছে: ভবিষ্যতে, AI কোম্পানির মূল্যায়ন নির্ধারণ করবে না যে এটি কতগুলি টোকেন দখল করেছে, বরং এটির কোডটি ভিডিও মেমোরি এবং রেজিস্টারের কতটা কাছাকাছি।
যারা নিজেদের অধীনস্থ ব্ল্যাক বক্সকে ভেদ করতে পারবে না, তারা চূড়ান্তভাবে "মধ্যম কর" এর কাদায় আটকে যাবে।