Markdown সংস্করণ

AI-translated from English; not yet reviewed by a fluent editor.

# নির্দিষ্ট GB300 পরীক্ষায় সেকেন্ডে 842 টোকেনে পৌঁছেছে vLLM-এর Kimi K3 ডিকোড পথ

> নির্দিষ্ট DSpark বিন্যাসে 16টি GB300 GPU-তে Kimi K3-এর সম্মিলিত ডিকোড গতি সেকেন্ডে 842 বনাম 488 টোকেন বলে জানিয়েছে vLLM। প্রিফিল এতে অন্তর্ভুক্ত নয়।

By BIG CHANGE Editorial

Published: 2026-10-18T20:03:34.885Z
Updated: 2026-10-18T20:03:34.885Z
Canonical: https://bigchange.ai/blog/kimi-k3-vllm-gpu-inference-benchmark

![Conceptual charcoal illustration of the rear of a generic compute cabinet with rack units and secured cables in a data-center aisle.](https://bigchange.ai/api/media/file/kimi-k3-decode-cabinet-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual GB300 chassis, vLLM installation or measured result is depicted.

NVIDIA Blackwell GPU-তে Kimi K3-এর জন্য ঐচ্ছিক, মডেল-নির্দিষ্ট ডিকোড পথ যুক্ত করেছে vLLM। তাদের [16 অক্টোবরের বিবরণে](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) প্রকল্পটি সাধারণ vLLM-এর সেকেন্ডে 488 টোকেনের বিপরীতে 842 টোকেন তৈরির কথা জানিয়েছে, অর্থাৎ 1.73× উন্নতি। তুলনাটির পরিসর সীমিত: একবারে একটি অনুরোধ, 16টি GB300 GPU জুড়ে টেনসর প্যারালেলিজম, সাতটি খসড়া টোকেনসহ DSpark স্পেকুলেটিভ ডিকোডিং, ছয় টোকেনের কৃত্রিম গ্রহণ-দৈর্ঘ্য, এক টোকেন ইনপুট এবং 1000 টোকেন আউটপুট। সংখ্যাটি প্রিফিলের পরের সম্মিলিত ডিকোডিং থ্রুপুট মাপে। ব্যবহারকারীর সম্পূর্ণ অনুরোধ কত দ্রুত শেষ হয়, তা মাপে না।

এই পথ মূল্যায়ন করবেন কি না, সে সিদ্ধান্ত নেওয়া প্রকৌশলীদের জন্য কার্যকর অগ্রগতি হলো উল্লেখযোগ্য ডিকোড ফলের সঙ্গে কোথায় তা প্রযোজ্য, তার মোটামুটি স্পষ্ট বিবরণ পাওয়া। [যুক্ত করা বাস্তবায়ন](https://github.com/vllm-project/vllm/pull/61867) চালু করতে `decode_backend: latency_specialized` ব্যবহার করে স্পষ্টভাবে বেছে নিতে হয়; ডিফল্ট `auto` সেটিং আগের সাধারণ ডিকোডিংই ব্যবহার করে। vLLM জানায়, বিশেষায়িত পথটি একই NVLink ডোমেইনে আটটি বা 16টি GPU থাকা GB300 স্থাপনার জন্য; প্রিফিল, মিশ্র ব্যাচ ও অসমর্থিত ধাপগুলো স্বাভাবিক মডেল ফরোয়ার্ড পথে ফিরে যায়।

## সময় কোথায় খরচ হচ্ছিল

Kimi K3 একটি বড় মিক্সচার-অব-এক্সপার্টস মডেল, তার [মডেল কার্ড](https://huggingface.co/moonshotai/Kimi-K3) অনুযায়ী। ডিকোডিংয়ের সময় পরবর্তী টোকেন তৈরি করতে সার্ভিং ব্যবস্থা বারবার অ্যাটেনশন চালায়, এক্সপার্ট বেছে নেয় এবং GPU-গুলোর মধ্যে ডেটা বিনিময় করে। vLLM দল প্রত্যাশিত টেনসর আকৃতির জন্য কাজগুলো বিশেষায়িত করতে CuTe DSL পথ তৈরি করেছে। বিবরণে ছোট ও বড় ব্যাচের জন্য আলাদা অ্যাটেনশন প্রজেকশন কার্নেল; অ্যাটেনশন আউটপুট প্রজেকশন, GPU-গুলোর মধ্যে রিডাকশন ও পরের রেসিডুয়াল কাজ একত্র করা; ভাগ করা রাউটার গণনা; শেয়ার্ড ও রাউটেড এক্সপার্টের কাজের ওভারল্যাপ; এবং যোগাযোগের সময় আগাম ওয়েট এনে রাখার কথা আছে। পোস্টে দেখানো স্তরভিত্তিক ট্রেসে বিশেষায়িত পথ 13টি কার্নেল ও 69 মাইক্রোসেকেন্ড ব্যবহার করে, যেখানে সাধারণ vLLM ব্যবহার করে 23টি কার্নেল ও 130 মাইক্রোসেকেন্ড। এটি দেখানো বিন্যাসের রিপোর্ট করা ট্রেস, অ্যাপ্লিকেশনের ল্যাটেন্সির পরিমাপ নয়।

কার্নেলের নকশার মতোই গুরুত্বপূর্ণ প্রযোজ্যতার পরিসর। [পুল রিকোয়েস্ট](https://github.com/vllm-project/vllm/pull/61867) TP8 ও TP16-তে GB300 যাচাই, ব্যাচ 64 পর্যন্ত নন-স্পেকুলেটিভ ডিকোড, তিন থেকে সাতটি খসড়া টোকেন দিয়ে DSpark যাচাই এবং ঐচ্ছিক ডিকোড কনটেক্সট প্যারালেলিজম বর্ণনা করেছে। এতে বলা হয়েছে, পারফরম্যান্সের কাজে FP8 KV ক্যাশ, FP32 SSM ক্যাশ ও মডেল প্রদানকারীর ওয়েট ব্যবহৃত হয়েছে। পথটি মডেলের ওয়েট, শিডিউলিং, স্যাম্পলিং বা DSpark খসড়া-জেনারেটর বদলায় না। ফলে পরিচিত বাকি স্ট্যাক রেখেই সার্ভিং দল বদলে দেওয়া ডিকোড বাস্তবায়ন তুলনা করতে পারে; তবে এর অর্থ, অপ্টিমাইজেশন সার্ভিংয়ের প্রতিটি অংশ দ্রুত করে না।

## দুটি বেঞ্চমার্ক সারণি আলাদা করে পড়ুন

842 বনাম 488 ফলটি ব্যবহার করে **16টি GB300 GPU-তে TP16, ব্যাচ 1, সাতটি খসড়া টোকেনসহ DSpark, ছয় টোকেনের কৃত্রিম গ্রহণ-দৈর্ঘ্য, DL=7, ISL=1 ও OSL=1k**। vLLM এই মেট্রিককে সেকেন্ডে সম্মিলিত ডিকোড টোকেন বলে এবং প্রিফিল বাদ দেয়। প্রস্তাবিত টোকেনের কতটি বেঞ্চমার্ক গ্রহণ করবে, কৃত্রিম গ্রহণ তা স্থির করে; এটি ব্যবহারকারীর প্রম্পট থেকে মাপা গ্রহণের হার নয়। ভিন্ন প্রম্পট, গ্রহণের আচরণ, ব্যাচের আকার বা ইনপুটের দৈর্ঘ্যের স্থাপনার নিজস্ব পরিমাপ প্রয়োজন।

পোস্টে একটি [নন-স্পেকুলেটিভ সারণিও](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation) আছে। যেমন, TP16-তে ব্যাচ 1-এ সেকেন্ডে 256.4 টোকেন এবং ব্যাচ 64-তে 3606.1 টোকেন জানানো হয়েছে; সংশ্লিষ্ট সাধারণ বিন্যাসের তুলনায় উন্নতি যথাক্রমে 1.88× ও 1.62×। এগুলো স্পেকুলেটিভ ডিকোডিং ছাড়া পুরো TP গ্রুপের সম্মিলিত ফল। ব্যাচ 64-তে ব্যবহারকারীপ্রতি আরও দ্রুত অভিজ্ঞতা দাবি করতে এগুলোকে DSpark সংখ্যার সঙ্গে মেলানো যায় না।

পোস্টের আরেকটি সংখ্যা [AgentX](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#improvement-on-agentx) নিয়ে। এটি কৃত্রিম কনটেন্ট দিয়ে কোডিং এজেন্টের ট্র্যাফিকের ধরন পুনরায় চালানো একটি ওয়ার্কলোড। একসঙ্গে একটি অনুরোধে ব্যবহারকারীপ্রতি সেকেন্ডে টোকেন হিসেবে P90 ইন্টারঅ্যাক্টিভিটি 403.2 বনাম 223.7 বলে জানিয়েছে vLLM। অপ্টিমাইজ করা ফল চলেছে **16টি GB300 GPU-তে**, আর আগের তুলনাটি চলেছিল **আটটিতে**। বাস্তবায়নের সঙ্গে GPU-র সংখ্যাও বদলেছে বলে 1.8× তুলনাটি শুধু ডিকোড পথের উন্নতি আলাদা করে দেখায় না। AgentX-এ দীর্ঘতর কনটেক্সট, কথোপকথনের পালা, বিরতি ও ক্যাশ পুনর্ব্যবহারও রয়েছে। তাই এর মেট্রিক নিখাদ ডিকোড বেঞ্চমার্কের চেয়ে ভিন্ন প্রশ্নের উত্তর দেয়।

সর্বসাধারণের জন্য প্রকাশিত পোস্ট এবং আগের [পুল-রিকোয়েস্ট পারফরম্যান্স সারণিতে](https://github.com/vllm-project/vllm/pull/61867) সামান্য অমিল আছে: দ্বিতীয়টি TP16, ব্যাচ 1, DSpark DL7 ও কৃত্রিম গ্রহণ ছয়ের জন্য সেকেন্ডে 838 বনাম 489 টোকেন দেখায়। এখানে 1.73× সংখ্যাটির উৎস পোস্টের 842 বনাম 488 তুলনা। আগের সারণি অনুরূপ একটি রান সম্পর্কে উপযোগী প্রমাণ, তবে দুই জোড়া সংখ্যাকে মিলিয়ে দেওয়া উচিত নয়। vLLM কোড ও নিজেদের যাচাই প্রকাশ করেছে; BIG CHANGE দুটি রানের কোনোটিই পুনরুৎপাদন করেনি।

## মূল্যায়নে কী লাগবে

অর্থবহ স্থানীয় তুলনা শুরু হবে [যুক্ত করা PR ও তাতে বলা বিন্যাস](https://github.com/vllm-project/vllm/pull/61867) দিয়ে: Kimi K3 মডেল প্রদানকারীর একই ওয়েট, একই NVLink ডোমেইনে 16টি GPU-সহ GB300 ব্যবস্থা, TP16, ক্যাশের ফরম্যাট এবং প্রধান পরীক্ষার হুবহু DSpark বিন্যাস। সাধারণ `auto` ও ঐচ্ছিক `latency_specialized` একই ওয়ার্কলোডে চালান। এরপর ডিকোড থ্রুপুটকে প্রিফিল, প্রথম টোকেন পেতে সময়, আউটপুট থ্রুপুট ও অনুরোধভিত্তিক ল্যাটেন্সি থেকে আলাদাভাবে লিখে রাখুন। একটি ওয়ার্কস্টেশন বা ছোট GPU পুল সরাসরি 16-GB300 প্রধান ফল পুনরুৎপাদন করতে পারে না। পোস্টটি ওই ব্যবস্থার ভাড়ার খরচ প্রতিষ্ঠা করে না।

ওই [PR-এর যাচাই বিবরণ](https://github.com/vllm-project/vllm/pull/61867) সংখ্যাগত পরীক্ষা ও মডেল মূল্যায়ন জানায়, যার মধ্যে AIME25, GPQA-Diamond ও দীর্ঘ কনটেক্সটের MRCR পরীক্ষা রয়েছে। উন্নয়নের সময় পাওয়া একটি সিঙ্ক্রোনাইজেশন ত্রুটি এবং দীর্ঘ আউটপুটের পরীক্ষায় তারতম্যও বর্ণিত হয়েছে। এই পরীক্ষাগুলো পাঠককে গতির চার্টের চেয়ে বেশি যাচাইয়ের উপাদান দেয়, যদিও সেগুলো বাস্তবায়নকারীদেরই প্রমাণ। সার্ভিং দলকে ঠিক করতে হবে, তাদের প্রকৃত হার্ডওয়্যার, ব্যাচিং, কনটেক্সটের দৈর্ঘ্য ও স্পেকুলেটিভ গ্রহণ সমর্থিত বিন্যাসের এতটা কাছাকাছি কি না যে নিজেদের ট্র্যাফিকে ঐচ্ছিক পথটি মাপা যুক্তিযুক্ত।

## বড় পরিবর্তন

vLLM-এ যুক্ত Kimi K3 পথ নথিবদ্ধ বেঞ্চমার্ক ও যাচাইয়ের রেকর্ডসহ একটি বিশেষায়িত, ঐচ্ছিক GPU ডিকোড বাস্তবায়ন সরবরাহ করে। সর্বজনীন প্রধান ফলগুলোর মধ্যে সবচেয়ে জোরালোটি হলো **16টি GB300 GPU-তে TP16, ব্যাচ 1, DSpark-এর সাতটি খসড়া টোকেন ও ছয় টোকেনের কৃত্রিম গ্রহণ-দৈর্ঘ্যে সেকেন্ডে 842 বনাম 488 সম্মিলিত ডিকোড টোকেন, অর্থাৎ 1.73×**। প্রিফিল বাদ দেওয়া হয়েছে। কোনো নির্দিষ্ট সেবা উন্নত হবে কি না, তা সেই সেবার হার্ডওয়্যার ও সম্পূর্ণ অনুরোধের ওয়ার্কলোডের ওপর নির্ভর করে।

## সূত্র ও আরও পড়ুন

- [vLLM-এর 16 অক্টোবরের প্রযুক্তিগত পোস্ট](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) ডিকোড পরিবর্তন ব্যাখ্যা করে এবং 842/488 বিন্যাস, নন-স্পেকুলেটিভ সারণি ও AgentX তুলনা দেয়। ফল জানিয়েছে প্রকল্প ও NVIDIA অবদানকারী Benjamin Chislett।
- [যুক্ত করা vLLM পুল রিকোয়েস্ট #61867](https://github.com/vllm-project/vllm/pull/61867) ঐচ্ছিক সেটিং, সমর্থিত বিন্যাস, বাস্তবায়নের সীমা, যাচাই ও আগের 838/489 DSpark সারণি নথিবদ্ধ করে। এটি কোড ও ফলের রেকর্ড, স্বতন্ত্র পুনরুৎপাদন নয়।
- [Moonshot AI-এর Kimi K3 মডেল কার্ড](https://huggingface.co/moonshotai/Kimi-K3) বাস্তবায়নে উল্লেখ করা মডেল ও ওয়েট শনাক্ত করে।
- [AgentX পদ্ধতি](https://inferencex.semianalysis.com/agentx) আলাদা ইন্টারঅ্যাক্টিভিটি তুলনার পেছনের ট্র্যাফিক পুনরায় চালানোর ওয়ার্কলোড বর্ণনা করে।

## Sources

- [vLLM, vLLM-এ Kimi K3-এর গভীর অপ্টিমাইজেশন: দ্রুত ও দায়িত্বশীল অগ্রগতি (2026-10-16)](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — প্রথম-পক্ষীয় প্রযুক্তিগত বিবরণ এবং 842/488, 1.73× ফলের উৎস। এতে 16টি GB300 GPU-তে TP16, ব্যাচ 1, DSpark DL7, কৃত্রিম AL6, ISL1, OSL1k ও প্রিফিল বাদ দিয়ে সম্মিলিত ডিকোড TPS নির্দিষ্ট করা হয়েছে। আলাদা নন-স্পেকুলেটিভ ও AgentX ফলও দেয়।
- [vLLM পুল রিকোয়েস্ট #61867, Kimi K3 বিশেষায়িত ডিকোড](https://github.com/vllm-project/vllm/pull/61867) — যুক্ত করা বাস্তবায়ন ও লেখকদের চালানো যাচাইয়ের রেকর্ড। চূড়ান্ত ঐচ্ছিক সেটিং, সমর্থিত বিন্যাস ও স্বাভাবিক পথে ফিরে যাওয়া নথিবদ্ধ করে। আগের DSpark সারণিতে TP16 B1 কৃত্রিম AL6-এ 838/489 বলা হয়েছে, তাই সেই সংখ্যা ব্লগের জোড়ার সঙ্গে মেলানো হয়নি।
- [Moonshot AI, Kimi K3 মডেল কার্ড](https://huggingface.co/moonshotai/Kimi-K3) — মডেল ও মডেল প্রদানকারীর ওয়েট শনাক্ত করে; স্বতন্ত্রভাবে vLLM-এর পারফরম্যান্স প্রতিষ্ঠা করে না।
- [InferenceX, AgentX পদ্ধতি ও ডেটাসেট](https://inferencex.semianalysis.com/agentx) — আলাদাভাবে জানানো ইন্টারঅ্যাক্টিভিটি তুলনায় ব্যবহৃত ট্র্যাফিক পুনরায় চালানোর ওয়ার্কলোড বর্ণনা করে। vLLM-এর তুলনায় GPU-র সংখ্যাও বদলেছে।