মাল্টি-নোট DeepSeek ডিপ্লয়মেন্ট সহ কম লেটেন্সি এবং উচ্চ থ্রুপুট

অধিকাংশ সিস্টেমে, লেটেন্সি এবং থ্রুপুট প্রায়শই পরস্পরবিরোধী লক্ষ্য যা ডিজাইন এবং ডিপ্লয়মেন্টের সময় ট্রেড-অফ দাবি করে। উদাহরণস্বরূপ, ঘন লার্জ ল্যাঙ্গুয়েজ মডেলে, ব্যাচের আকার বৃদ্ধি করলে থ্রুপুট উন্নত হতে পারে তবে লেটেন্সিও বৃদ্ধি পায়; একটি একক মেশিনের মধ্যে টেন্সর প্যারালালিজম বৃদ্ধি করলে লেটেন্সি হ্রাস পেতে পারে কিন্তু রেপ্লিকার সংখ্যা হ্রাস পায়, যা কম থ্রুপুটের দিকে পরিচালিত করে।

DeepSeek-V3/R1-এর মতো মিক্সচার অফ এক্সপার্টস (MoE) মডেলগুলি সম্প্রতি চমৎকার মডেল ক্ষমতা এবং অপারেশনাল দক্ষতা প্রদর্শন করেছে। উদাহরণস্বরূপ, DeepSeek-V3/R1 মডেলে মোট 671B প্যারামিটার রয়েছে, কিন্তু ইনফারেন্সের সময় প্রতিটি টোকেন শুধুমাত্র 37B প্যারামিটার ব্যবহার করে। এই মডেল আর্কিটেকচারটি ইনফারেন্স সিস্টেমের জন্য উভয় চ্যালেঞ্জ এবং সুযোগ উপস্থাপন করে।

এই নিবন্ধটি প্রদর্শন করে যে, প্রচলিত সিস্টেমের বিপরীতে, DeepSeek-V3/R1-এর মতো MoE মডেলগুলি বেশিরভাগ পরিস্থিতিতে মাল্টি-নোট ডিপ্লয়মেন্টে আরও বেশি জিপিইউ ব্যবহার করার সময় একযোগে উচ্চ থ্রুপুট এবং কম লেটেন্সি অর্জন করতে পারে।

ডিপ্লয়মেন্ট আর্কিটেকচার

বড় করুন

বড় করুন

মডেলটিতে প্রচুর সংখ্যক ছোট এক্সপার্ট থাকার কারণে, ডিপ্লয়মেন্টগুলি অবশ্যই একাধিক ডিভাইসে ছড়িয়ে দিতে হবে। আমরা 8xH200 জিপিইউ সহ একটি একক নোডে একক-নোট ডিপ্লয়মেন্ট এবং 8xH100 জিপিইউতে মাল্টি-নোট ডিপ্লয়মেন্ট উভয়ের কথাই বিবেচনা করেছি।

উভয় ডিপ্লয়মেন্ট আর্কিটেকচারই আমাদের ইন-হাউস রিকোয়েস্ট শিডিউলারের মাধ্যমে অর্কেস্ট্রেট করা ডেটা প্যারালালিজমের সদ্ব্যবহার করে। ডেটা প্যারালালিজম বাস্তবায়নে একাধিক ইনফারেন্স ইঞ্জিন ইন্সট্যান্স লঞ্চ করা জড়িত, যার প্রতিটি অনুরোধ পরিবেশন এবং রক্ষণাবেক্ষণ করতে স্বাধীনভাবে কাজ করে। GRPC-এর মাধ্যমে ইঞ্জিনের সাথে ইন্টারঅ্যাক্ট করে এমন রিকোয়েস্ট শিডিউলারটি অনুরোধগুলিকে যতটা সম্ভব সমানভাবে ছড়িয়ে দেওয়ার জন্য দায়ী, পাশাপাশি KV রি-ইউজ সহজতর করে, ক্যাশে ধারণকারী সার্ভারগুলিতে আংশিক মেলে যাওয়া প্রিফিক্স সহ অনুরোধ পাঠায়। ইঞ্জিন ইন্সট্যান্সগুলি একাধিক নোড জুড়ে বিস্তৃত হয় না। তারা ঐচ্ছিকভাবে একাধিক ডিভাইসে অ্যাটেনশন শার্ড করতে টেন্সর প্যারালালিজম ব্যবহার করতে পারে। একক-নোটের ক্ষেত্রে NVLink বা মাল্টি-নোটের ক্ষেত্রে InfiniBand-এর মাধ্যমে ইন্সট্যান্সগুলি আন্তঃসংযুক্ত থাকে, যা এক্সপার্টদের ডিসপাচ এবং সংগ্রহ করে।

একক-নোট ডিপ্লয়মেন্ট কনফিগারেশন ছোট ব্যাচ সাইজের সাথে চমৎকার লেটেন্সি প্রদান করে; তবে, বর্ধিত লোড অবস্থার অধীনে কার্যক্ষমতা দ্রুত হ্রাস পায়।

সার্ভিং ইঞ্জিন ডিপ্লয় করতে, আমরা একাধিক ইঞ্জিন ইন্সট্যান্স হোস্ট করে এমন প্রতি নোডে একটি পড লঞ্চ করি। বিতরণ করা যোগাযোগ সেট আপ করা এবং NVSHMEM প্রারম্ভিকতা আলোচনা করার জন্য PyTorch দায়ী। যোগাযোগের জন্য, আমরা পূর্ববর্তী একটি ব্লগ পোস্টে বর্ণিত কাস্টম CUDA কার্নেলের উপর নির্ভর করি। দুটি ডিপ্লয়মেন্টের বাস্তবায়ন কার্যত অভিন্ন, যেখানে এক্সপার্ট প্যারালালিজম বাস্তবায়নকারী ফ্যাব্রিকের উপর ভিত্তি করে মডেলটি ব্যবহারের জন্য সঠিক কার্নেলগুলি বেছে নেয়।

প্যারালালিজেশন কৌশল

আমাদের কার্যক্ষমতা তুলনা করার আগে, মূল প্যারালালিজম কৌশলগুলি বোঝা অপরিহার্য যা DeepSeek-V3/R1-এর মতো বিশাল MoE মডেলগুলি ডিপ্লয় করা সম্ভব করে তোলে।

টেন্সর প্যারালালিজম

LLM ইনফারেন্সে, প্রতি জিপিইউতে মেমরি ব্যবহার এবং গণনা কমাতে সাধারণত টেন্সর প্যারালালিজম (TP) ব্যবহার করা হয়, যার ফলে লেটেন্সি হ্রাস পায়। সাধারণত, আমরা রো বা কলাম ডাইমেনশন বরাবর অ্যাটেনশন এবং MLP লেয়ারে Linear প্রজেকশন শার্ড করতে পারি, এবং অ্যাটেনশন হেড ডাইমেনশন বরাবর অ্যাটেনশন অপারেশন শার্ড করতে পারি।

TP-এর সাহায্যে, Llama-3 আর্কিটেকচারে জিপিইউ জুড়ে Linear প্রজেকশন এবং অ্যাটেনশন অপারেশনের জন্য কোনো ডুপ্লিকেটেড গণনা থাকে না, যা একটি আদর্শ শার্ডিং পদ্ধতি। তবে, DeepSeek-V3/R1 মডেলে, TP এটি অর্জন করতে পারে না।

DeepSeek-V3/R1 মডেলগুলি মাল্টি-ল্যাটেন্ট অ্যাটেনশন (MLA) ব্যবহার করে। একটি MLA লেয়ার প্রথমে ল্যাটেন্ট ভেক্টর গণনা করতে একটি Linear প্রজেকশন kv_a_proj ব্যবহার করে, তারপর এটিকে প্রতিটি অ্যাটেনশন হেডের স্পেস-এ রূপান্তর করতে আরেকটি Linear প্রজেকশন kv_b_proj ব্যবহার করে। যেহেতু সমস্ত অ্যাটেনশন হেড একই ল্যাটেন্ট ভেক্টর শেয়ার করে, তাই TP ল্যাটেন্ট ভেক্টর শার্ড করতে পারে না, তাই সমস্ত TP র‍্যাঙ্কের kv_a_proj এবং kv_b_proj-এর প্যারামিটার এবং গণনা প্রতিলিপি করতে হয়। একইভাবে, যেহেতু MLA KV ক্যাশে ল্যাটেন্ট ভেক্টর সংরক্ষণ করে, তাই প্রতিটি TP র‍্যাংক KV ক্যাশের একটি অভিন্ন কপি সংরক্ষণ করে।

MLA-তে কিছু ডুপ্লিকেশন থাকা সত্ত্বেও, টেন্সর প্যারালালিজম এখনও গণনার চাহিদার আংশিক হ্রাস প্রদান করে, যা উচ্চ আউটপুট গতির প্রয়োজন এমন পরিস্থিতিতে এটিকে মূল্যবান করে তোলে।

এক্সপার্ট প্যারালালিজম

DeepSeek-V3/R1 মডেলগুলি MLP লেয়ারকে MoE লেয়ার দিয়ে প্রতিস্থাপন করে। একটি MoE লেয়ারে 256টি রাউটেড এক্সপার্ট এবং একটি শেয়ার্ড এক্সপার্ট থাকে। প্রতিটি টোকেন গণনার জন্য 8টি বিভিন্ন রাউটেড এক্সপার্টে ডিসপাচ করা হয়, এবং ফলাফলগুলিকে ওয়েটেড সাম করা হয়। প্রতিটি টোকেন শেয়ার্ড এক্সপার্টেও গণনা করে, এবং ফলাফলটি রাউটেড এক্সপার্টের ফলাফলের সাথে যোগ করা হয়।

এক্সপার্ট প্যারালালিজম (EP) MoE লেয়ারের জন্য সাধারণ শার্ডিং পদ্ধতি হিসেবে কাজ করে, যেখানে প্রতিটি জিপিইউ শেয়ার্ড এক্সপার্টের একটি কপি বজায় রেখে 256 / EP রাউটেড এক্সপার্ট পরিচালনা করে। TP-এর তুলনায়, EP-এর সুবিধা হলো এটি আরও বেশি জিপিইউ জুড়ে গণনা বিতরণ করতে পারে, প্রতি জিপিইউতে গণনা এবং মেমরি ব্যবহার হ্রাস করতে পারে।

এক্সপার্ট গণনা করার আগে, সংশ্লিষ্ট এক্সপার্টরা অবস্থিত সেই জিপিইউগুলিতে টোকেন ডিসপাচ করার জন্য সমস্ত জিপিইউকে একটি AllToAll যোগাযোগ করতে হবে; এক্সপার্ট গণনার পরে, বিভিন্ন জিপিইউ থেকে গণনার ফলাফল সংগ্রহ করতে এবং ওয়েটেড সামেশন সম্পাদন করতে আরেকটি AllToAll যোগাযোগ প্রয়োজন। আমরা NVSHMEM ব্যবহার করে এই দুটি AllToAll যোগাযোগ কার্নেল, Dispatch এবং Combine-এর একটি অপ্টিমাইজ করা সংস্করণ বাস্তবায়ন করেছি। আমাদের পূর্ববর্তী ব্লগ পোস্টে, আমরা বাস্তবায়নটি বিস্তারিতভাবে বর্ণনা করেছি, এবং আমাদের কার্নেলগুলি GitHub-এ ওপেন-সোর্স করা হয়েছে।

ডেটা প্যারালালিজম

EP-এর সাহায্যে, আমরা 128 বা আরও বেশি জিপিইউ জুড়ে MoE গণনা বিতরণ করতে পারি। তবে, EP দিয়ে MLA গণনা বিভাজ্য করা যায় না। এই বিন্দুতে, আমরা ডেটা প্যারালালিজম (DP) প্রবর্তন করতে পারি। প্রতিটি DP গ্রুপের MLA লেয়ারের একটি সম্পূর্ণ কপি থাকে। প্রতিটি DP গ্রুপ বিভিন্ন ইনপুট গ্রহণ করে এবং স্বাধীনভাবে MLA লেয়ার গণনা সম্পাদন করে।

MLA লেয়ারের DP এবং TP একত্রিত করা যেতে পারে, যেখানে একটি DP গ্রুপ একাধিক TP র‍্যাঙ্কে বিভক্ত হয়। MoE লেয়ারের EP-কে MLA লেয়ারের DP/TP-এর সাথে একত্রিত করা যেতে পারে। EP = DP * TP। উদাহরণস্বরূপ, 16টি মেশিনে, EP128 DP32 TP4 মানে 128টি জিপিইউ জুড়ে রাউটেড এক্সপার্ট বিতরণ করা, প্রতিটি 4টি জিপিইউ একটি DP গ্রুপ গঠন করে, মোট 32টি স্বাধীন DP গ্রুপ।

একক-নোট বনাম মাল্টি-নোট

DeepSeek-এর 671B প্যারামিটার একটি একক 8-GPU H100 মেশিনের মেমরি ক্ষমতা (80 GB * 8) অতিক্রম করে, কিন্তু একটি একক 8-GPU H200 মেশিন সম্পূর্ণ মডেলটিকে পুরোপুরি ধারণ করতে পারে (141 GB * 8)। EP8 DP8 TP1 কনফিগারেশন ব্যবহার করে, মডেলটি প্রতি জিপিইউতে প্রায় 100 GB মেমরি ব্যবহার করে, যা KV ক্যাশে এবং অন্যান্য মধ্যবর্তী ফলাফলের জন্য প্রায় 40 GB খালি রাখে। একটি টোকেন KV ক্যাশের 70,272 বাইট দখল করে। ধরে নেওয়া যাক প্রতিটি অনুরোধে 5,000 টোকেন রয়েছে, প্রতিটি জিপিইউ মোটামুটি 100টি অনুরোধ ধারণ করতে পারে।

আমরা বিভিন্ন কনফিগারেশনের অধীনে একক-নোট এবং মাল্টি-নোট ডিপ্লয়মেন্টের মধ্যে কার্যক্ষমতার পার্থক্য বুঝতে চেয়েছিলাম। আমরা একক-নোট ডিপ্লয়মেন্টের জন্য একটি H200 মেশিন এবং মাল্টি-নোট ডিপ্লয়মেন্টের জন্য 16টি H100 মেশিন পর্যন্ত ব্যবহার করেছি। প্রতিটি ডিপ্লয়মেন্ট পরিবেশের জন্য, আমরা TP 1, 2, 4, 8 এবং প্রতি জিপিইউতে ব্যাচ সাইজ 1, 2, 4, 8, 16, 32, 64, 128-এর সংমিশ্রণ ব্যবহার করেছি। আমরা ধরে নিয়েছি প্রতিটি অনুরোধে 5,000 টোকেনের KV ক্যাশে দৈর্ঘ্য রয়েছে। আমরা আরও ধরে নিয়েছি মাল্টি-টোকেন প্রেডিকশন (MTP) অতিরিক্ত 1টি টোকেন ভবিষ্যদ্বাণী করে (অর্থাৎ, প্রতিটি অনুরোধের কোয়েরি দৈর্ঘ্য 2), এবং রক্ষণশীলভাবে 60% গ্রহণযোগ্যতার হার ধরে নিয়েছি। নীচের চিত্রটি বিভিন্ন কনফিগারেশনের জন্য থ্রুপুট এবং আউটপুট গতি দেখায়।

বড় করুন

অনুভূমিক অক্ষ টোকেন/সেকেন্ডে প্রতি অনুরোধ আউটপুট গতি প্রতিনিধিত্ব করে। লম্বালম্বি অক্ষ টোকেন/সেকেন্ডে প্রতি মেশিন থ্রুপুট দেখাতে একটি লগারিদম স্কেল ব্যবহার করে। আমরা বিভিন্ন রঙের লাইন দিয়ে প্রতিটি EP কনফিগারেশনের জন্য প্যারেটো ফ্রন্টিয়ার চিহ্নিত করেছি।

অত্যন্ত উচ্চ আউটপুট গতির প্রয়োজনীয়তা সহ পরিস্থিতিতে, ব্যাচ সাইজ 1 সহ একক-নোট EP8 DP1 TP8 ব্যবহার করে 100 টোকেন/সেকেন্ড অতিক্রমকারী আউটপুট গতি অর্জন করা যেতে পারে, তবে থ্রুপুট অত্যন্ত কম, যা আউটপুট গতির সমান। এই পরিস্থিতিতে, পুরো ব্যাচে কেবল 2টি টোকেন রয়েছে, যা সর্বাধিক 2*8=16 এক্সপার্টে ডিসপাচ করা যেতে পারে, যা সর্বাধিক মোট 57B প্যারামিটার সক্রিয় করে।

80-40 টোকেন/সেকেন্ড আউটপুট গতির সীমার মধ্যে, থ্রুপুট বৃদ্ধির সাথে সাথে, আউটপুট গতি উল্লেখযোগ্যভাবে হ্রাস পায়। বিপরীতে, একই আউটপুট গতিতে একক-নোট ডিপ্লয়মেন্টের তুলনায় EP128-এর প্রায় 5 গুণ বেশি থ্রুপুট রয়েছে।

একক-নোট ডিপ্লয়মেন্টগুলি কীভাবে আচরণ করে তা পরীক্ষা করে এই ঘটনাটি ব্যাখ্যা করা যেতে পারে: ব্যাচ সাইজ বৃদ্ধি করা সরাসরি সক্রিয় এক্সপার্টদের বৃদ্ধির সাথে সম্পর্কিত। যখন ব্যাচ সাইজ 1 হয়, প্রতি জিপিইউতে সক্রিয় এক্সপার্টদের গড় সংখ্যা হলো 2 * 8 / 8 = 2। যখন ব্যাচ যথেষ্ট বড় হয়, সমস্ত এক্সপার্ট সক্রিয় হয়, যার অর্থ প্রতিটি জিপিইউ 256 / 8 = 32 এক্সপার্ট সক্রিয় করে। আরও বেশি এক্সপার্ট সক্রিয় করার অর্থ হলো জিপিইউকে মেমরি থেকে আরও বেশি প্যারামিটার পড়তে হবে, যা মেমরি ব্যান্ডউইথ চাপ উল্লেখযোগ্যভাবে বৃদ্ধি করে। যেহেতু লার্জ ল্যাঙ্গুয়েজ মডেলের ডিকোড পর্যায়টি গণনার কার্যক্ষমতার পরিবর্তে ইতিমধ্যেই মেমরি ব্যান্ডউইথ দ্বারা বোতলনেক হয়ে থাকে, তাই একক-নোট ডিপ্লয়মেন্টে ব্যাচ সাইজ বৃদ্ধি করা আউটপুট গতি উল্লেখযোগ্যভাবে হ্রাস করে।

চারটি মাল্টি-নোট ডিপ্লয়মেন্ট কনফিগারেশনের (EP16, EP32, EP64 এবং EP128) তুলনা প্রকাশ করে যে উচ্চ EP মানগুলি প্যারেটো ফ্রন্টিয়ারকে থ্রুপুট এবং আউটপুট গতির একযোগে উন্নতির দিকে স্থানান্তরিত করে।

একটি উচ্চ EP নম্বর ব্যবহার করার অর্থ হলো প্রতিটি জিপিইউতে কম এক্সপার্ট বরাদ্দ করা হয়। উদাহরণস্বরূপ, EP128-এর অর্থ হলো প্রতিটি জিপিইউ 256 / 128 = 2 এক্সপার্টের জন্য দায়ী, তাই মেমরি ব্যান্ডউইথ চাপ উল্লেখযোগ্যভাবে হ্রাস পায়। অন্য কথায়, একটি বড় EP নম্বর ব্যবহার করে, আমরা কার্যকরভাবে আরও মেমরি ব্যান্ডউইথ অর্জন করি। যখন প্রতি-GPU ব্যাচ সাইজ 64-এর কম হয়, তখন ব্যাচ সাইজ বৃদ্ধি করা এক্সপার্ট গণনার গতিকে উল্লেখযোগ্যভাবে প্রভাবিত করে না কারণ ইনপুট সংখ্যা বৃদ্ধি করা মেমরি ব্যান্ডউইথ চাপ উল্লেখযোগ্যভাবে বৃদ্ধি করে না। অতএব, আমরা লক্ষ্য করি যে যখন EP128 ব্যবহার করা হয়, তখন ব্যাচ সাইজ বৃদ্ধি করা আউটপুট গতিকে ততটা উল্লেখযোগ্যভাবে প্রভাবিত করে না।

মজার বিষয় হলো, বড় ব্যাচ সাইজে (প্রতি জিপিইউতে 64টি অনুরোধ), আমরা একটি নতুন ঘটনা লক্ষ্য করেছি: একক-নোট ডিপ্লয়মেন্ট থ্রুপুট মাল্টি-নোট ডিপ্লয়মেন্টের চেয়ে কিছুটা বেশি। এর আংশিক কারণ হলো নোডের অভ্যন্তরীণ NVLink-এর নোডগুলির মধ্যে থাকা InfiniBand-এর চেয়ে উচ্চ ব্যান্ডউইথ রয়েছে। আরেকটি অংশ আমাদের বাস্তবায়নের সীমাবদ্ধতার কারণে। আমরা পরবর্তীতে আরও বিশদে এই ঘটনাটি বিশ্লেষণ করব।

মেমরি ক্ষমতার সীমাবদ্ধতার কারণে, EP8 DP8 TP1 কনফিগারেশন প্রতি জিপিইউতে 128 ব্যাচ সাইজে পৌঁছাতে পারে না, তাই উচ্চ থ্রুপুট অনুসরণকারী পরিস্থিতিতে মাল্টি-নোট ডিপ্লয়মেন্ট এখনও একটি ভালো পছন্দ।

গণনা এবং যোগাযোগ ওভারল্যাপিং

এক্সপার্ট প্যারালালিজম সম্পর্কে উপরে সংক্ষিপ্তভাবে পরিচিতি দেওয়া হয়েছে, MoE লেয়ার যোগাযোগের সময় জিপিইউগুলি অলস থাকে। অপচয় কমাতে এবং লেটেন্সি কমাতে, আমাদের এই অলস সময় পূরণ করার জন্য ডেটা-স্বাধীন গণনার কাজ খুঁজে বের করতে হবে।

বড় করুন

উপরের চিত্রের উপরের অংশটি একটি স্তরের গণনা প্রবাহ দেখায়। MoE গণনা Dispatch-এর উপর নির্ভর করে এবং পরবর্তী স্তরের গণনা Combine-এর ফলাফলের উপর নির্ভর করে।

আমরা প্রতিটি জিপিইউতে শেয়ার্ড এক্সপার্ট রাখি। এই ভাবে, শেয়ার্ড এক্সপার্ট গণনার জন্য AllToAll যোগাযোগের প্রয়োজন হয় না। অতএব, আমরা ডিসপাচ সেন্ড সম্পন্ন হওয়ার সাথে সাথেই শেয়ার্ড এক্সপার্ট গণনা করতে পারি, তারপরে ডিসপাচ রিসিভ সম্পন্ন হওয়ার জন্য অপেক্ষা করতে পারি। আমরা এই ওভারল্যাপ স্কিমটিকে "Dispatch Overlap" বলি।

Dispatch Overlap সহজ বাস্তবায়ন এবং ব্যাপক প্রযোজ্যতা প্রদান করে। এই কৌশলটি সমস্ত EP আকার এবং ব্যাচ আকারে শেয়ার করা এক্সপার্ট গণনার সময় লুকিয়ে রাখে।

গণনা এবং যোগাযোগের ওভারল্যাপ আরও বাড়াতে, ডেটা নির্ভরতা ভাঙতে আমরা DeepSeek প্রযুক্তিগত প্রতিবেদনে উল্লিখিত মাইক্রো ব্যাচিং ব্যবহার করেছি। চিত্রের নীচের অংশে দেখানো হয়েছে, আমরা একটি ট্রান্সফর্মার লেয়ারের গণনাকে 5টি পর্যায়ে ভাগ করেছি:

পর্যায় 1: InputNorm, QKVProj, AppendKV, BMM

পর্যায় 2: BMM, Attn, OProj, PostNorm, Gate

পর্যায় 3: Dispatch Send, Shared Expert

পর্যায় 4: Dispatch Recv, MoE, Combine Send

পর্যায় 5: Combine Recv

প্রথম 3টি ডেন্স ট্রান্সফর্মার লেয়ারে, আমরা পুরো ব্যাচটি ব্যবহার করি। নিম্নলিখিত 58টি MoE ট্রান্সফর্মার লেয়ারে, আমরা ব্যাচটিকে সমানভাবে দুটি মাইক্রো ব্যাচে বিভক্ত করি। দুটি মাইক্রো ব্যাচ বিকল্পভাবে সম্পাদিত হয়, 3টি পর্যায় দ্বারা অফসেট করা হয়। যেহেতু এই দুটি মাইক্রো ব্যাচের মধ্যে কোনো ডেটা নির্ভরতা নেই, তাই আমরা ডিসপাচ সেন্ডের পরে এবং কম্বাইন সেন্ডের পরে অন্য মাইক্রো ব্যাচের গণনায় স্যুইচ করতে পারি।

লেটেন্সি ব্রেকডাউন

এর পরে, আমরা একটি পরীক্ষার মাধ্যমে ওভারল্যাপিংয়ের প্রভাবগুলির তুলনা করি, পাশাপাশি একক-নোট ডিপ্লয়মেন্ট EP8 এবং মাল্টি-নোট ডিপ্লয়মেন্ট EP128-এর মধ্যে কার্যক্ষমতার পার্থক্যের তুলনা করি। তুলনার সুবিধার জন্য, আমরা নিম্নলিখিত পরীক্ষার জন্য H100 জিপিইউ ব্যবহার করেছি। আমরা TP1, প্রতি জিপিইউতে 128 ব্যাচ সাইজ, প্রতি অনুরোধে 2 কোয়েরি দৈর্ঘ্য এবং 5000 KV ক্যাশে দৈর্ঘ্য ব্যবহার করেছি।

বড় করুন

উপরের চিত্রটি একটি MoE ট্রান্সফর্মার লেয়ারে ব্যয় করা মোট সময় এবং বিভিন্ন ধরণের কার্নেলের লেটেন্সি অনুপাত দেখায়। Dispatch, Combine এবং GroupGEMM ছাড়া, EP8, EP128 NoOverlap এবং EP128 DispatchOverlap সিরিজে অন্যান্য কার্নেলের কার্যনির্বাহী সময় সমান হওয়া উচিত কারণ ব্যাচ সাইজ একই।

ওভারল্যাপিং

প্রথমে তিনটি ওভারল্যাপিং পদ্ধতির প্রভাব তুলনা করা যাক। NoOverlap মোট ২৬৬৭µs সময় নিয়েছে, DispatchOverlap নিয়েছে ২৬৫১µs, যার ফলে ১৬µs বা মাত্র ০.৬% সাশ্রয় হয়েছে। MicroBatch অত্যন্ত উল্লেখযোগ্য উন্নতি দেখিয়েছে, যা ১৮৯৬µs সময় নিয়েছে এবং ২৯% গতি বাড়িয়েছে। Dispatch এবং Combine উভয় সময় উল্লেখযোগ্যভাবে হ্রাস পেয়েছে। Dispatch ৫৯৩µs থেকে কমে ৩৬৭µs হয়েছে এবং Combine ১০১২µs থেকে কমে ২৩৭µs হয়েছে।

মনে রাখবেন যে গণনা কার্নেলগুলির জন্য, 128 সাইজের একটি ব্যাচকে 64 সাইজের দুটি ব্যাচে বিভক্ত করা মোট কার্যনির্বাহী সময় বৃদ্ধি করে। অতএব, যোগাযোগের জন্য ব্যয় করা সময় 1001µs হ্রাস পেলেও, মোট সময় কেবল 771µs হ্রাস পেয়েছে। আমরা নিম্নলিখিত বিভাগে রুফলাইন মডেল ব্যবহার করে কারণটি ব্যাখ্যা করব।

এই কারণে, মাইক্রোব্যাচিং সবসময় কার্যক্ষমতা উন্নত করে না।

বড় করুন

উপরের চিত্রটি ব্যাচ সাইজ 4-128-এর জন্য DispatchOverlap-এর তুলনায় Microbatch-এর কার্যক্ষমতার উন্নতি দেখায়। যখন ব্যাচ সাইজ 32-এর কম হয়, তখন Microbatch কার্যক্ষমতা 5%-40% হ্রাস করে। যখন ব্যাচ সাইজ 32-এর বেশি বা সমান হয়, তখন Microbatch কার্যক্ষমতা 10%-35% উন্নত করতে পারে।

EP8 বনাম EP128

আসুন পূর্ববর্তী চিত্রে ফিরে যাই এবং EP8 এবং EP128 Microbatch-এর তুলনা করি। EP8 মোট 1802µs সময় নিয়েছে, যা EP128-এর 1896µs-এর চেয়ে কিছুটা কম। উপরে উল্লিখিত Microbatch দ্বারা আনা বর্ধিত কার্নেল কার্যনির্বাহী সময় ছাড়াও, প্রধান পার্থক্যগুলি হলো MoE গণনার জন্য ব্যবহৃত GroupGEMM, এবং দুটি যোগাযোগ কার্নেল, Dispatch এবং Combine-এ।

EP8-এর GroupGEMM 555µs সময় নিয়েছে, যেখানে EP128-এর GroupGEMM 270µs সময় নিয়েছে, যা অর্ধেক হ্রাস পেয়েছে। এটি মাল্টি-নোট ডিপ্লয়মেন্টের মূল সুবিধা।

দুর্ভাগ্যবশত, যোগাযোগের জন্য ব্যয় করা সময় 213µs বৃদ্ধি পেয়েছে, যা GroupGEMM-এর সুবিধাকে অনেকাংশে অফসেট করেছে। আমাদের যোগাযোগ কার্নেলগুলির পৃথক কার্যক্ষমতা পরীক্ষায়, আমরা দেখেছি যে তারা ইনফিনিব্যান্ড ব্যান্ডউইথের মাত্র অর্ধেক অর্জন করতে পারে। আমরা আমাদের যোগাযোগ কার্নেলগুলি অপ্টিমাইজ করা চালিয়ে যাব।

আরেকটি কার্নেল যা উল্লেখযোগ্যভাবে পিছিয়ে আছে তা হলো GEMM। Microbatch GEMM-কে 95µs বৃদ্ধি করেছে। আমরা নীচের রুফলাইন বিভাগে আরও গভীরভাবে GEMM বিশ্লেষণ করব। আমরা বিশ্বাস করি যে বর্তমান GEMM বাস্তবায়ন এখনও অনুকূল কার্যক্ষমতা অর্জন করতে পারেনি।

রুফলাইন

কার্নেল কার্যক্ষমতা বিশ্লেষণের জন্য রুফলাইন মডেল একটি ভালো হাতিয়ার। এর অনুভূমিক অক্ষ হলো অ্যারিথমেটিক ইন্টেনসিটি, FLOP এবং মেমরি I/O বাইটের অনুপাত। কার্নেলের সেমান্টিকস থেকে অনুভূমিক অক্ষের মান সরাসরি গণনা করা যেতে পারে। লম্বালম্বি অক্ষ অর্জিত কার্যক্ষমতা প্রতিনিধিত্ব করে, যা বেঞ্চমার্ক লেটেন্সি দ্বারা FLOP ভাগ করে গণনা করা হয়।

কার্নেল কার্যক্ষমতার তাত্ত্বিক উচ্চ সীমা সরাসরি জিপিইউ-এর স্পেসিফিকেশন দ্বারা নির্ধারিত হয়। H100-এর FP8 পিক কার্যক্ষমতা হলো 1979 TFLOP/s, যা রুফলাইন মডেলে একটি অনুভূমিক রেখা হিসেবে প্রতিনিধিত্ব করা হয়। H100-এর মেমরি ব্যান্ডউইথ হলো 3.35 TB/s, যা উৎপত্তি বিন্দুর মধ্য দিয়ে অতিক্রমকারী একটি রেখার ঢাল হিসেবে প্রতিনিধিত্ব করা হয়। দুটি রেখা যথাক্রমে কম্পিউট-বাউন্ড এবং মেমরি-বাউন্ড কার্নেলগুলির জন্য কার্যক্ষমতার সীমা প্রদান করে।

নীচে, আমরা GroupGEMM এবং GEMM কার্নেলগুলির কার্যক্ষমতা আলোচনা করি।

GroupGEMM

MoE-তে GroupGEMM কার্নেল নিম্নলিখিত গণনা সম্পাদন করে: মোট g টি গ্রুপ রয়েছে, i-তম গ্রুপে m_i টি টোকেন রয়েছে, যা [m_i, k] x [k, n] -> [m_i, n] এর একটি ম্যাট্রিক্স গুণন সম্পাদন করে। কার্যক্ষমতা পরীক্ষায়, আমরা ধরে নিই যে প্রতিটি গ্রুপের টোকেনের সংখ্যা একই, যাকে m_i = m হিসেবে চিহ্নিত করা হয়। তাহলে GroupGEMM-এর জন্য FLOP গণনা হলো 2 * g * m * k * n, এবং মেমরি I/O বাইট হলো g * (m * k + n * k + m * n)।

DeepSeek-V3/R1 মডেলে, 256টি এক্সপার্ট রয়েছে, এবং প্রতিটি টোকেন গণনার জন্য 8টি এক্সপার্টে ডিসপাচ করা হয়। 128 ব্যাচ সাইজ, 2 কোয়েরি দৈর্ঘ্য, EP128 DP128 কনফিগারেশন ব্যবহার করে ধরে নিলে, প্রতিটি এক্সপার্ট দ্বারা প্রাপ্ত টোকেনের গড় সংখ্যা (অর্থাৎ, m) হলো 128 * 2 * 8 * 128 / 256 = 1024। একইভাবে, আমরা অন্যান্য কনফিগারেশন এবং ব্যাচ সাইজের জন্য m গণনা করতে পারি।

আমরা কার্যক্ষমতা পরীক্ষার জন্য DeepGEMM-এর GroupGEMM বাস্তবায়ন ব্যবহার করেছি। পরীক্ষার পয়েন্টগুলি TP1 এবং ব্যাচ সাইজ 1-128 সহ EP8, EP16, EP32, EP64, EP128 কনফিগারেশনের সংমিশ্রণ কভার করেছে।

বড় করুন

উপরের চিত্রটি বিভিন্ন EP কনফিগারেশনের অধীনে GroupGEMM-এর জন্য রুফলাইন মডেল দেখায়। বিভিন্ন EP বিভিন্ন সংখ্যক গ্রুপের সাথে মিলে যায়। চিত্রটি প্রায় ওভারল্যাপিং কার্যক্ষমতা রেখাগুলি চিত্রিত করে, যা নির্দেশ করে যে GroupGEMM কার্যক্ষমতা মূলত মোট টোকেন গণনা (g * m হিসেবে প্রতিনিধিত্ব করা হয়) দ্বারা নির্ধারিত হয়।

তারকাগুলি প্রতিটি EP কনফিগারেশনের জন্য প্রতি জিপিইউতে 128 ব্যাচ সাইজের সাথে সংশ্লিষ্ট ডেটা পয়েন্টগুলিকে চিহ্নিত করে। এই তারকা চিহ্নিত ডেটা পয়েন্টগুলির তুলনা করে, আমরা দেখতে পারি যে EP বৃদ্ধি পাওয়ার সাথে সাথে (এবং DP সিঙ্ক্রোনাসভাবে বৃদ্ধি পায়), প্রতি এক্সপার্ট টোকেনের সংখ্যা m ও বৃদ্ধি পায়। EP8-এ, m=128, যেখানে EP128-এ, m=2048।

যেহেতু m বৃদ্ধি পায়, অ্যারিথমেটিক ইন্টেনসিটি ও বৃদ্ধি পায়। বেশিরভাগ কনফিগারেশনে, GroupGEMM মেমরি ব্যান্ডউইথ দ্বারা সীমাবদ্ধ, তাই m বৃদ্ধি করা কার্যক্ষমতা উন্নত করে।

GEMM

GEMM কার্নেল মডেলের Linear প্রজেকশনগুলির সাথে মিলে যায়, যেমন Q/K/V/O প্রজেকশন। [m, k] x [k, n] -> [m, n] এর একটি ম্যাট্রিক্স গুণনের জন্য, FLOP গণনা হলো 2 * m * k * n, এবং মেমরি I/O বাইট হলো m * k + n * k + m * n। আমরা ব্যাচ সাইজ 1-128-এর জন্যও লেটেন্সি পরীক্ষা করতে পারি।

বড় করুন

উপরের চিত্রটি বিভিন্ন EP কনফিগারেশনের অধীনে GEMM-এর জন্য রুফলাইন মডেল দেখায়। আমরা দেখতে পারি যে GEMM কার্যক্ষমতা মেমরি ব্যান্ডউইথ দ্বারা সীমাবদ্ধ। ব্যাচ সাইজ বৃদ্ধির সাথে সাথে, অ্যারিথমেটিক ইন্টেনসিটি ও বৃদ্ধি পায়, এইভাবে কার্যক্ষমতা উন্নত হয়।

মাইক্রোব্যাচ

মাইক্রোব্যাচিং ব্যবহার করার সময়, আমরা ব্যাচটিকে সমানভাবে দুটি ভাগে বিভক্ত করি। উপরের দুটি চিত্র থেকে, আমরা দেখতে পারি যে যখন m, m/2 হয়ে যায়, তখন ম্যাট্রিক্স গুণনের দক্ষতা হ্রাস পায়। অতএব, m/2 সাইজের দুটি ম্যাট্রিক্স গুণন সম্পাদন করা m সাইজের একটি ম্যাট্রিক্স গুণন সম্পাদনের চেয়ে বেশি সময় নেয়।

মাল্টি-টোকেন প্রেডিকশন

এই নিবন্ধ জুড়ে, আমরা স্পেকুলেটিভ ডিকোডিংয়ের জন্য মাল্টি-টোকেন প্রেডিকশন (MTP) ব্যবহারের কথা ধরে নিয়েছি। MTP প্রতি অনুরোধে কোয়েরি দৈর্ঘ্য 1 থেকে 2 তে পরিবর্তন করে। ম্যাট্রিক্স গুণনের জন্য, এটি m-কে m * 2-এ পরিবর্তনের সমতুল্য, যার ফলে ম্যাট্রিক্স গুণন দক্ষতা বৃদ্ধি পায়। অন্যদিকে, আমরা যদি MLA-এর জন্য রুফলাইন মডেল আঁকি, তবে আমরা দেখতে পাব যে কোয়েরি দৈর্ঘ্য বৃদ্ধি করা MLA কার্নেল দক্ষতাকে উল্লেখযোগ্যভাবে বৃদ্ধি করে।

অতএব, MTP-এর ব্যবহার মডেল দক্ষতায় একটি গুরুত্বপূর্ণ ভূমিকা পালন করে।

বাস্তবায়ন ও অপ্টিমাইজেশন

এই বিভাগে, আমরা আমাদের DeepSeek-V3/R1 মডেলের জন্য কিছু বাস্তবায়ন এবং অপ্টিমাইজেশন বিবরণ পরিচয় করিয়ে দেব।

কোয়ান্টাইজেশন

DeepSeek-V3/R1 প্রাকৃতিকভাবে প্রতি-ব্লক কোয়ান্টাইজেশন স্কিম ব্যবহার করে FP8-এ প্রশিক্ষিত হয়েছিল, যেখানে ওজনগুলি স্থিরভাবে কোয়ান্টাইজ করা হয়েছিল এবং অ্যাক্টিভেশনগুলি অন-দ্য-ফ্লাই কোয়ান্টাইজ করা হয়েছিল। চ্যানেল প্রতি বা ম্যাট্রিক্স প্রতি একটি স্কেলিং ফ্যাক্টর স্থিরভাবে গণনার পরিবর্তে, অ্যাক্টিভেশনের জন্য 128-এলিমেন্ট ভেক্টর জুড়ে এবং ম্যাট্রিক্সের জন্য 128x128 এলিমেন্ট টাইল জুড়ে স্কেলিং ফ্যাক্টর গণনা করা হয়, যা কোয়ান্টাইজেশনের কারণে নির্ভুলতা হ্রাস সীমিত করে।

Perplexity-তে, আমরা ইনফারেন্স সমর্থন করতে CUDA এবং Triton কার্নেলের মিশ্রণের উপর নির্ভর করি, যেখানে CUDA সর্বাধিক কার্যক্ষমতা-সংবেদনশীল এবং কদাচিৎ পরিবর্তিত কার্নেলগুলির জন্য (যেমন অ্যাটেনশন এবং GEMM) ব্যবহৃত হয়, যেখানে Triton বিস্তৃত পরিসরের অ্যাক্টিভেশন, নরমালাইজেশন এবং ইউটিলিটি কার্নেল বাস্তবায়ন করে। Triton আমাদের ব্লক কোয়ান্টাইজেশন স্কিমের সাথে কার্নেলগুলিকে দ্রুত মানিয়ে নিতে সাহায্য করেছে।

লিনিয়ার এবং MoE লেয়ারগুলির জন্য, আমরা Deep GEMM কার্নেলগুলিকে আমাদের নিজস্ব Triton GEMM কার্নেলগুলির সাথে মিশ্রিত করি, কারণ আমরা লক্ষ্য করেছি যে নির্দিষ্ট ম্যাট্রিক্স ডাইমেনশন এবং কম ব্যাচ সাইজের জন্য Split-K কম লেটেন্সি প্রদান করে। যদি অনকোয়ান্টাইজড লেয়ারটি একটি (M, K) x (K, N) গুণন সম্পাদন করে, তবে ব্লক কোয়ান্টাইজেশনের জন্য এটির (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) স্কেলিং ফ্যাক্টর প্রয়োজন। ব্লক কোয়ান্টাইজেশনের জন্য, প্রি-ক্যালিব্রেট করার পরিবর্তে অ্যাক্টিভেশনের স্কেলিং ফ্যাক্টরগুলি অন-দ্য-ফ্লাই গণনা করা হয়। যেহেতু অ্যাক্টিভেশন স্কেলিং ফ্যাক্টরগুলি শুধুমাত্র K ডাইমেনশন বরাবর একত্রিত করা হয় এবং M ডাইমেনশন বরাবর নয়, তাই স্কিম সমর্থন করার জন্য কার্নেলগুলির কেবল সামান্য পরিবর্তনের প্রয়োজন হয়।

বড় করুন

DeepSeek-V3/R1 দ্বারা ব্যবহৃত SiLU অ্যাক্টিভেশন ফাংশনটির CUDA গ্রাফ, ব্লক কোয়ান্টাইজেশন এবং গতিশীলভাবে রাউটেড টোকেন গণনা সমর্থন করার জন্য যথেষ্ট পরিবর্তনের প্রয়োজন হয়েছিল। ব্লক কোয়ান্টাইজেশন সমস্যামূলক হতে পারে কারণ এটি অনুভূমিক রিডাকশন প্রবর্তন করে, তবে কার্নেল ইতিমধ্যে এর লুকানো ডাইমেনশন বরাবর অ্যাক্টিভেশনগুলিকে 1024 এলিমেন্টের ব্লকে খণ্ড খণ্ড করেছিল। একটি ব্লকের মধ্যে, কোয়ান্টাইজ করার জন্য টেনসরটি বৃহত্তম পরম মান গণনা করতে 128 এর ব্লকে আরও খণ্ড খণ্ড করা হয়েছিল, যেখানে Triton দক্ষ ক্রস-ওয়ার্প ম্যাক্স রিডাকশন তৈরি করে, যা ন্যূনতম ওভারহেড যোগ করে।

CUDA গ্রাফের অধীনে MoE রাউটিং সমর্থন করার জন্য, কার্নেলগুলিকে প্রতি এক্সপার্টে টোকেনের সংখ্যা নির্দেশকারী রাউটিং তথ্য সম্পর্কে সচেতন হতে হবে, টোকেন গণনার উচ্চ সীমা ধরে রাখতে বরাদ্দ করা বাফারগুলির সাইজের উপর ভিত্তি করে কাজ সময় নির্ধারণ করার পরিবর্তে। আমরা ইনপুট টেনসর ডাইমেনশনের উপর ভিত্তি করে সমস্যাটি বিভক্ত করতে পারি না, তাই আমরা একটি নির্দিষ্ট সংখ্যক পার্সিস্টেন্ট কার্নেল লঞ্চ করি যা কতগুলি টোকেন জনবহুল তা নির্ধারণ করতে রাউটিং তথ্য পড়ে এবং তাদের মধ্যে অ্যাক্টিভেশন প্রক্রিয়াকরণের কাজ গতিশীলভাবে বিভক্ত করে।

আমরা ইতিমধ্যে FlashInfer প্রজেক্টে আমাদের কিছু কার্নেল আপস্ট্রিম করেছি এবং ভবিষ্যতে আমরা আমাদের আরও কোড ওপেন-সোর্স করব।

MLA লেয়ার

আমরা MLA গণনার জন্য FlashInfer ব্যবহার করি। FlashInfer নমনীয় পেজ টেবিল সেটিংস এবং অত্যন্ত উচ্চ কার্যক্ষমতা সমর্থন করে।

আমরা q_a_proj এবং kv_a_proj-কে একটি একক qkv_a_proj-এ ফিউজ করেছি। লেটেন্সি 15.4 µs + 14.8 µs = 30.2 µs থেকে কমে 16.7 µs হয়েছে।

আমরা kv_b_proj-কে দুটি ম্যাট্রিক্সে, k_b_proj এবং v_b_proj-এ পচিয়েছি। আমরা এই দুটি ম্যাট্রিক্স সম্পর্কিত গণনার জন্য একটি FP8 ব্লক কোয়ান্টাইজড BMM কার্নেল লিখেছেন।

Cuda গ্রাফ

Cuda গ্রাফ কার্নেল লঞ্চিং ওভারহেড উল্লেখযোগ্যভাবে হ্রাস করতে পারে, যা কার্যক্ষমতার জন্য অত্যন্ত গুরুত্বপূর্ণ। আমরা প্রতিটি ব্যাচ সাইজের জন্য একটি Cuda গ্রাফ তৈরি করি।

আমাদের AllToAll কার্নেল বিকাশের আগে, আমরা AllToAll যোগাযোগের জন্য torch.all_to_all_single() ব্যবহার করেছি। এই অপারেশনের জন্য সমস্ত জিপিইউকে একই ব্যাচ সাইজ ব্যবহার করার প্রয়োজন হয়। তবে, বিভিন্ন DP গ্রুপ বিভিন্ন ব্যাচ সাইজ চালাতে পারে।

all_to_all_single() বিভিন্ন ব্যাচ সাইজ ব্যবহার করে বিভিন্ন DP গ্রুপের সাথে সামঞ্জস্যপূর্ণ তা নিশ্চিত করতে, সমস্ত DP গ্রুপের মধ্যে সর্বাধিক ব্যাচ সাইজ পেতে আমরা প্রতিটি মডেল চালানোর আগে প্রথমে একটি allreduce() অপারেশন ব্যবহার করেছি। তারপরে আমরা সমস্ত DP গ্রুপকে চালানোর জন্য এই ব্যাচ সাইজ ব্যবহার করেছি।

যদিও এই পদ্ধতিটি নিশ্চিত করে যে আমরা Cuda গ্রাফ ব্যবহার করতে পারি, এর তিনটি অসুবিধা রয়েছে। প্রথমত, এটির একটি অতিরিক্ত allreduce() অপারেশন প্রয়োজন। দ্বিতীয়ত, ছোট ব্যাচ সাইজ সহ DP গ্রুপগুলিকে প্যাড করতে বাধ্য করা হয়। তৃতীয়ত, এটি আমাদের বাস্তবায়ন কোড জটিল করে তোলে।

আমাদের নিজস্ব AllToAll কার্নেল বাস্তবায়নের পরে, আমাদের আর সমস্ত জিপিইউকে একই ব্যাচ সাইজ ব্যবহার করার প্রয়োজন হয় না। অতএব, আমাদের আর অতিরিক্ত allreduce() অপারেশন সম্পাদন করার বা ব্যাচ সাইজ প্যাড করার প্রয়োজন নেই।

MoE রাউটার

MoE রাউটারটি Triton-এ বাস্তবায়িত হয়েছে, যা স্ট্যান্ডার্ড লাইব্রেরি থেকে প্রাপ্ত একটি পরিবর্তিত সাজানোর উপর নির্ভর করে যা সাজানো এলিমেন্টগুলির সূচকগুলির ট্র্যাকও রাখে। বাস্তবায়নটি সমস্ত MoE মডেল জুড়ে শেয়ার করা হয়, কারণ Mixtral রাউটিং হলো DeepSeek রাউটের একটি বিশেষ ক্ষেত্র যেখানে Top-K গ্রুপ সমস্ত এক্সপার্টের গ্রুপের মতোই। স্পার্স কার্নেলগুলি সরাসরি Top-K সূচক এবং স্কোরগুলি ব্যবহার করে, যেখানে অল-টু-অল-এর উপর নির্ভর করে ডেন্স ডিসপাচ/কম্বাইন স্কিমগুলির জন্য প্রতি-টোকেনের পরিবর্তে প্রতি-এক্সপার্ট ভিত্তিতে রাউটিং তথ্য একত্রিত করা প্রয়োজন।

ভবিষ্যতের কাজ

ভবিষ্যতের কাজের ক্ষেত্রে, আমরা DeepSeek মডেলের কার্যক্ষমতা আরও অপ্টিমাইজ করার পরিকল্পনা করছি।

সবচেয়ে গুরুত্বপূর্ণ পরবর্তী অপ্টিমাইজেশন হলো প্রিফিল ডিসএগ্রিগেশন। DeepSeek-V3/R1 মডেলের প্রিফিল পর্যায় এবং ডিকোড পর্যায়ে অত্যন্ত ভিন্ন গণনামূলক বৈশিষ্ট্য রয়েছে। উভয়ই বিভিন্ন অপ্টিমাইজেশন কৌশল এবং ডিপ্লয়মেন্ট স্কিম ব্যবহার করতে পারে।

MLA লেয়ারের জন্য, ডিকোড পর্যায়ে, আমরা MLA গণনার FLOP গণনা কমাতে ম্যাট্রিক্স অ্যাবজরপশন ব্যবহার করি। প্রিফিল পর্যায়ে, প্রথমে ল্যাটেন্ট ভেক্টরকে K/V স্পেস-এ প্রজেক্ট করা এবং তারপরে মাল্টি-হেড অ্যাটেনশন (MHA) ফর্মে গণনা করা আরও ভালো পারফর্ম করবে।

যদি প্রিফিল এবং ডিকোড একই জিপিইউতে চলে, ডিকোড আউটপুট গতির উপর প্রিফিলের প্রভাব কমাতে, প্রিফিলের জন্য কোয়েরিকে একাধিক খণ্ডে বিভক্ত করতে আমরা সাধারণত চাংকড প্রিফিল ব্যবহার করি। যেহেতু KV ক্যাশে ল্যাটেন্ট ভেক্টর সংরক্ষণ করে, তাই MLA-কে MHA ফর্মে রূপান্তর করা কঠিন হয়ে পড়ে।

MoE লেয়ারের জন্য, ডিকোড পর্যায়ে, প্রতি এক্সপার্টে ইনপুট টোকেনের সংখ্যা বাড়াতে আমরা যথাসম্ভব বড় EP এবং DP ব্যবহার করি, যার ফলে GroupGEMM কার্যক্ষমতা উন্নত হয়। প্রিফিল পর্যায়ে, টোকেনের সংখ্যা ইতিমধ্যে যথেষ্ট বড় হওয়ায়, GroupGEMM ইতিমধ্যেই কম্পিউট-বাউন্ড। অতএব, প্রিফিলের জন্য, আমরা ছোট EP এবং DP ব্যবহার করতে পারি।

যদি প্রিফিল এবং ডিকোড একই জিপিইউতে চলে, যতক্ষণ পর্যন্ত কোনো DP গ্রুপ প্রিফিল সম্পাদন করছে, সমস্ত জিপিইউতে MoE লেয়ারের লেটেন্সি বৃদ্ধি পাবে, যা ডিকোড আউটপুট গতিকে উল্লেখযোগ্যভাবে প্রভাবিত করবে।

প্রিফিল ডিসএগ্রিগেশন ছাড়াও, আমরা নিম্নলিখিত দিকগুলি অপ্টিমাইজ করার পরিকল্পনা করছি:

AllToAll কার্যক্ষমতা: আমাদের AllToAll কার্নেল বর্তমানে ইনফিনিব্যান্ড ব্যান্ডউইথের মাত্র 1/3 অর্জন করতে পারে। আমরা এই কার্নেলটি অপ্টিমাইজ করা চালিয়ে যাব।

EAGLE-শৈলী স্পেকুলেটিভ ডিকোডিং: উপরের ডেটাতে, আমরা 1টি টোকেনের ভবিষ্যদ্বাণী করতে স্পেকুলেটিভ ডিকোডিং ব্যবহারের কথা ধরে নিয়েছি। EAGLE একাধিক টোকেনের ভবিষ্যদ্বাণী করতে একটি ট্রি আর্কিটেকচার ব্যবহার করতে পারে, গ্রহণযোগ্যতার দৈর্ঘ্য উন্নত করে, যা আউটপুট গতি উল্লেখযোগ্যভাবে বৃদ্ধি করতে পারে।

GEMM কার্নেল: পূর্বে দেখানো রুফলাইন মডেলে, আমরা দেখতে পাচ্ছি যে GEMM কার্নেলের দক্ষতা তাত্ত্বিক সীমা থেকে এখনও অনেক দূরে। আমরা এই কার্নেলটি অপ্টিমাইজ করা চালিয়ে যাব।

GB200 NVL72: NVIDIA-এর সর্বশেষ GB200 NVL72 সলিউশনে, 72টি ব্ল্যাকওয়েল জিপিইউ উচ্চ-গতির NVLink-এর মাধ্যমে আন্তঃসংযুক্ত। MoE আর্কিটেকচার মডেলের জন্য, এটি একটি অত্যন্ত বড় সুযোগ এবং চ্যালেঞ্জ।

উপসংহার

DeepSeek MoE মডেলের মাল্টি-নোট ডিপ্লয়মেন্ট এমন কিছু অর্জন করে যা ঘন LLM-এর সাথে সাধারণত অসম্ভব: একযোগে থ্রুপুট এবং লেটেন্সি উভয়ই উন্নত করা. আরও বেশি জিপিইউ জুড়ে এক্সপার্ট বিতরণ করে, আমরা প্রতি ডিভাইসে মেমরি ব্যান্ডউইথ চাপ হ্রাস করি, দ্রুত প্রক্রিয়াকরণ এবং উচ্চ সিস্টেম থ্রুপুট সক্ষম করি। আমাদের পরীক্ষাগুলি দেখায় যে একক-নোট ডিপ্লয়মেন্টের তুলনায় সমতুল্য আউটপুট গতিতে EP128 কনফিগারেশনগুলি 5 গুণ পর্যন্ত উচ্চ থ্রুপুট অর্জন করে।

মাইক্রো-ব্যাচিংয়ের মতো গণনা-যোগাযোগ ওভারল্যাপিং কৌশলগুলি মাল্টি-নোট যোগাযোগের ওভারহেড উল্লেখযোগ্যভাবে হ্রাস করে, আমাদের বাস্তবায়ন 40% পর্যন্ত গতি বৃদ্ধি দেখায়। আমাদের কাস্টম AllToAll যোগাযোগ কার্নেল এবং অপ্টিমাইজ করা কার্নেল বাস্তবায়ন 671B প্যারামিটার মডেলের দক্ষ ডিপ্লয়মেন্ট সক্ষম করেছে।

MoE আর্কিটেকচারগুলি তাদের ক্ষমতার জন্য জনপ্রিয়তা অর্জন করার সাথে সাথে, এই ডিপ্লয়মেন্ট কৌশলগুলি এই ধরনের মডেলগুলিকে দক্ষতার সাথে স্কেল করার জন্য মূল্যবান অন্তর্দৃষ্টি প্রদান করে।

তথ্যসূত্র

DeepSeek-V3 প্রযুক্তিগত প্রতিবেদন

DeepSeek-V3/R1 ইনফারেন্স সিস্টেম ওভারভিউ

Megatron-LM: মডেল প্যারালালিজম ব্যবহার করে মাল্টি-বিলিয়ন প্যারামিটার ল্যাঙ্গুয়েজ মডেল প্রশিক্ষণ

EAGLE: স্পেকুলেটিভ স্যাম্পলিংয়ের জন্য ফিচার অনিশ্চয়তা পুনর্বিবেচনা করা প্রয়োজন

উদ্ধৃতি

@online{perplexity2025LowerLatencyAndHigherThroughputWithMultiNodeDeepseekDeployment,
  author = {{Perplexity} and Lequn Chen and Nandor Licker and Erin McKnight},
  title = {{Lower latency and higher throughput with multi-node DeepSeek deployment}},
  date = {2025-04-18},
  url = {https://perplexity.coolkeypoint.com/hub/blog/lower-latency-and-higher-throughput-with-multi-node-deepseek-deployment}
}