৬৪K-টোকেন প্রম্পটের ক্ষেত্রে vLLM, SGLang-কে ছাড়িয়ে গেছে, কিন্তু ৮-GPU B300 সার্ভারে কনটেক্সট ২০০K স্পর্শ করার সাথে সাথে SGLang এগিয়ে যায়। এই পরিবর্তনটি দেখায় যে টোকেন উইন্ডো বৃদ্ধির সাথে সাথে প্রিল (prefill) কাজের পরিবর্তে ডিকোড-স্টেজ (decode-stage) এর বাধাগুলো পারফরম্যান্স নির্ধারণ করে।

কেন এই বেঞ্চমার্কটি গুরুত্বপূর্ণ

চ্যাট অ্যাসিস্ট্যান্ট, কোড অ্যাসিস্ট্যান্ট এবং যে কোনো অ্যাপের জন্য লং-কনটেক্সট ইনফারেন্স (long-context inference) খরচ বাড়িয়ে দেয়, যাদের মেমরিতে লক্ষ লক্ষ টোকেন রাখতে হয়। Kimi-K3 একটি লার্জ-প্যারামিটার মডেল এবং এটি প্রথম ওপেন-ওয়েট LLMগুলোর মধ্যে একটি যা স্বাচ্ছন্দ্যে এই ধরনের উইন্ডো হ্যান্ডেল করতে পারে, তবে এটি কোন ইঞ্জিন দিয়ে চালানো হচ্ছে তার ওপর নির্ভর করে একটি রিকোয়েস্ট কয়েক সেকেন্ড নাকি কয়েক মিনিটে শেষ হবে।

vLLM এবং SGLang উভয়ই উচ্চ-থ্রুপুট (high-throughput) ইনফারেন্সের প্রতিশ্রুতি দেয়, তবে ডিকোড স্টেজে তারা বিপরীত পদ্ধতি অবলম্বন করে। vLLM ডিকোড পাথকে সহজ রাখে এবং Decode Context Parallelism (DCP) এর মাধ্যমে আসা অতিরিক্ত সিনক্রোনাইজেশন এড়িয়ে চলে। SGLang, DCP ব্যবহার করে একাধিক GPU-তে key-value (KV) ক্যাশ রিড (read) ছড়িয়ে দেয়, যা অতিরিক্ত কমিউনিকেশনের বিনিময়ে মেমরি ব্যান্ডউইথকে কাজে লাগাতে পারে।

টেস্টবেড (The testbed)

  • হার্ডওয়্যার: একটি সিঙ্গেল সার্ভার যাতে আটটি NVIDIA B300 GPU রয়েছে, যার প্রতিটির মেমরি সমান।
  • ওয়ার্কলোড: দুটি কনটেক্সট-লেংথ সেটিং – ৬৪K টোকেন ("লং কনটেক্সট"-এর নিম্ন সীমা) এবং ২০০K টোকেন (অনেক রিসার্চ ডেমোর লক্ষ্যমাত্রা বা উচ্চ সীমা)।
  • মেট্রিক্স: একটি নির্দিষ্ট ব্যাচ প্রম্পট প্রসেস করতে মোট সময়; থ্রুপুট সময়ের পার্থক্য থেকে নির্ণয় করা হয়।

আমরা ব্যাচ সাইজ, মডেল ওয়েট এবং মেমরি-ইউটিলাইজেশন টার্গেট স্থির রেখেছিলাম। প্রতিটি রানের মধ্যে আমরা কেবল ইনফারেন্স ইঞ্জিনটি পরিবর্তন করেছি।

পরিসংখ্যানের ফলাফল

কনটেক্সট ইঞ্জিন সময় (সেকেন্ড) আপেক্ষিক গতি
64 K vLLM 100.5 –
SGLang 150.8 vLLM ≈ 1.5× দ্রুততর
200 K vLLM 295.2 –
SGLang 225.3 SGLang ≈ 1.31× দ্রুততর

কনটেক্সট বৃদ্ধির সাথে সাথে vLLM-এর থ্রুপুট (প্রতি সেকেন্ডে টোকেন) নাটকীয়ভাবে কমে গেছে: ৬৪K থেকে ২০০K-এ এটি ৩.২৯× কমেছে। SGLang-এর থ্রুপুট একই পরিসরে মাত্র ১.২৫× কমেছে।

পার্থক্যের কারণ

উভয় ইঞ্জিনই প্রিল (prefill) স্টেজে—অর্থাৎ KV ক্যাশে প্রম্পট লোড করতে—একই পরিমাণ সময় ব্যয় করে। পার্থক্যটি দেখা দেয় ডিকোড স্টেজে, যেখানে মডেলটি একটির পর একটি টোকেন জেনারেট করে।

  • ৬৪K টোকেন: এখানে ইন্টার-GPU কমিউনিকেশন প্রধান ভূমিকা পালন করে। vLLM-এর সিঙ্গেল-GPU ডিকোড পাথ DCP-এর জন্য প্রয়োজনীয় অতিরিক্ত সিনক্রোনাইজেশন এড়িয়ে যায়, ফলে এটি প্রায় ১.৫× দ্রুত কাজ শেষ করতে পারে।
  • ২০০K টোকেন: KV ক্যাশ এত বড় হয়ে যায় যে এটি পড়া (reading) একটি বাধা বা বটleneck হয়ে দাঁড়ায়। SGLang-এর DCP (সাইজ ৮ সেট করা) সেই রিডগুলোকে আটটি GPU-তে ছড়িয়ে দেয়। ব্যান্ডউইথের এই লাভ কমিউনিকেশনের ঘাটতিকে ছাপিয়ে যায়, যা SGLang-কে স্পষ্ট এগিয়ে দেয়।

একটি গৌণ এবং ব্যবহারিক পর্যবেক্ষণ হলো মেমরি প্রেশার। ০.৯৫ মেমরি-ইউটিলাইজেশন টার্গেটে যেকোনো ইঞ্জিন চালালে B300-এ আউট-অফ-মেমরি (OOM) রিট্রাই (retry) শুরু হয়। টার্গেট ০.৯২-এ নামিয়ে আনলে রিট্রাই বন্ধ হয় এবং রানটাইম স্থিতিশীল হয়, যদিও এতে ল্যাটেন্সি (latency) সামান্য বৃদ্ধি পায়।

কে জিতল, কে হারল

  • স্বল্প থেকে মাঝারি কনটেক্সট (≤ ৬৪K টোকেন) ব্যবহারকারী ডেভেলপাররা vLLM-এর স্লিম ডিকোড পাথ থেকে বেশি সুবিধা পান। দ্রুত কাজ সম্পন্ন হওয়া মানে কম ক্লাউড-কম্পিউট বিল এবং উন্নত ইউজার-এক্সপেরিয়েন্স।
  • গভীর বিশ্লেষণ বা রিসার্চ টুল তৈরি করা টিমগুলো, যাদের কনটেক্সটে লক্ষ লক্ষ টোকেন রাখা প্রয়োজন, তাদের DCP এনাবল করা SGLang ব্যবহার করা উচিত। এর স্থিতিশীল থ্রুপুট টাইম-আউট হওয়ার ঝুঁকি কমায় এবং মেমরির চাহিদা বাড়ার সাথে সাথে GPU ইউটিলাইজেশন উচ্চ রাখে।
  • হার্ডওয়্যার প্ল্যানাররা দেখতে পাচ্ছেন যে কেবল GPU-এর সংখ্যা থাকলেই লিনিয়ার স্কেলিং (linear scaling) নিশ্চিত হয় না। যখন KV ব্যান্ডউইথ একটি বাধা হয়ে দাঁড়ায়, তখন যে আর্কিটেকচারগুলো ক্যাশ রিড প্যারালাল করতে পারে—তা DCP-এর মাধ্যমে হোক বা ভবিষ্যতে মেমরি-সাবসিস্টেম আপগ্রেডের মাধ্যমে—তারা একই সিলিকন থেকে বেশি ভ্যালু বের করে আনতে পারবে।

পাল্টা যুক্তি: vLLM কি এই ব্যবধান কমাতে পারে?

নতুন ডেটা না আসা পর্যন্ত বর্তমান সংখ্যাগুলোই সেরা পাবলিক তুলনা হিসেবে গণ্য।

পরবর্তীতে যা লক্ষ্য রাখতে হবে

  • আরও বড় কনটেক্সট উইন্ডো KV ব্যান্ডউইথের ওপর আরও বেশি চাপ সৃষ্টি করবে, যা সম্ভবত SGLang-এর ব্যবধান আরও বাড়িয়ে দেবে।

মূল কথা (Bottom line)

যখন আপনার একটি B300-ভিত্তিক ক্লাস্টারে লং-কনটেক্সট রিকোয়েস্ট সার্ভ করার প্রয়োজন হবে, তখন আপনার টোকেন উইন্ডোর সাথে সামঞ্জস্যপূর্ণ ইঞ্জিনটি বেছে নিন। ৬৪K-টোকেন ওয়ার্কলোডের জন্য vLLM প্রায় ১.৫× দ্রুত ইনফারেন্স প্রদান করে। ২০০K টোকেনের বেশি হলে, SGLang-এর DCP-চালিত ডিকোড আরও দক্ষ বিকল্প হয়ে ওঠে, কারণ এর থ্রুপুট মাত্র ১.২৫× কমে, যেখানে vLLM-এর ক্ষেত্রে তা ৩.২৯× কমে। OOM রিট্রাই এড়াতে মেমরি ইউটিলাইজেশন ০.৯২-এ সেট করুন, এবং মনে রাখবেন যে "সেরা" ইঞ্জিনটি কনটেক্সটের ওপর নির্ভর করে, এটি সবার জন্য এক সমাধান নয়।