تصور کنید داشبورد نظارتی شما عدد ۱۰۰٪ را برای استفاده از GPU نشان می‌دهد، اما در واقعیت، سخت‌افزار شما تقریباً بیکار است. طبق تحلیل فنی منتشر شده در وب‌سایت dev.to در ۸ اوت ۲۰۲۶، این تضاد یک باگ نیست، بلکه نتیجه‌ی تفاوت بنیادین در نحوه اندازه‌گیری «اشغال سخت‌افزاری» و «کارایی واقعی محاسبات» است.
برای مهندسانی که مدل‌های زبانی بزرگ (LLM) — شبیه کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — را مستقر می‌کنند، اشتباه گرفتن این دو معیار، رایج‌ترین خطای تشخیص در زیرساخت‌های سرویس‌دهی است. این اشتباه باعث می‌شود تیم‌ها هفته‌ها وقت خود را صرف بهینه‌سازی هسته‌ها (Kernels) کنند، در حالی که مشکل اصلی صرفاً یک «دسته» (Batch) خالی است. برای درک این موضوع، باید سه عدد متمایز را از هم تفکیک کنیم: اشغال دستگاه (Device Occupancy)، پهنای‌باند حافظه و بهره‌وری عملیات اعشاری مدل یا MFU (Model FLOPs Utilisation).
سه معیار کلیدی عملکرد GPU
اشغال دستگاه همان چیزی است که اکثر ابزارهای مانیتورینگ گزارش می‌دهند. این معیار صرفاً بررسی می‌کند که در چه درصدی از بازه‌های زمانی، حداقل یک هسته در حال اجرا بوده است. در واقع درایور به‌طور دوره‌ای می‌پرسد «آیا چیزی در حال اجراست؟» و پاسخ مثبت را ثبت می‌کند. این عدد نمی‌گوید که آن هسته چه مقدار از مسیرهای پردازشی یا پهنای‌باند را اشغال کرده است، یا اصلاً آیا کار مفیدی انجام می‌دهد یا خیر. به نقل از مستندات فنی، حتی یک هسته بسیار کوچک که در یک حلقه بی‌نهایت گیر کرده باشد، می‌تواند اشغال ۱۰۰٪ را گزارش کند، در حالی که ۹۹٪ توان GPU بلااستفاده مانده است. از نظر این شمارنده، هسته‌ای که روی یک مسیر پردازشی می‌چرخد، هیچ تفاوتی با هسته‌ای ندارد که حافظه را با حداکثر سرعت ممکن می‌خواند.
بهره‌وری پهنای‌باند حافظه، مقدار بایت‌های منتقل شده در ثانیه را در برابر حداکثر توان بایت بر ثانیه سخت‌افزار می‌سنجد. در مرحله رمزگشایی (Decoding) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، مثل خودِ آشپزی و نه دوره‌ی آموزش آشپز — این عدد حیاتی‌ترین معیار است؛ زیرا در این مرحله، گلوگاه اصلی پهنای‌باند است، نه قدرت محاسباتی. بنابراین، این همان عددی است که باید بالا باشد و همان معیاری است که باید روی داشبورد شما قرار بگیرد.
در نهایت، MFU همان عددی است که اکثر افراد تصور می‌کنند در حال مشاهده آن هستند. MFU عملیات اعشاری (FLOPs) مورد نیاز واقعی مدل را بر حاصل‌ضرب حداکثر توان FLOPs ممکن در زمان سپری شده تقسیم می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی استنتاج اشاره کردیم، در مرحله رمزگشایی، MFU به‌طور طبیعی پایین است و هیچ بازنویسیِ کد در سطح هسته نمی‌تواند آن را تغییر دهد، مگر اینکه وزن‌ها همچنان نیاز به خواندن از حافظه داشته باشند. این بهینه‌سازی‌های نرم‌افزاری در کنار سخت‌افزارهای قدرتمند، نتایج چشمگیری دارد؛ برای مثال در مدل Qwen3.5 با استفاده از تکنیک‌های مشابه توانستیم به سرعت استنتاج ۷۸ توکن در ثانیه دست یابیم.
ریاضیات «سقف» عملکرد
پایین بودن MFU در مرحله رمزگشایی نتیجه‌ی «شدت محاسباتی» (Arithmetic Intensity) است. در اندازه دسته B و با b بایت برای هر پارامتر، رمزگشایی حدود 2B/b عملیات اعشاری به ازای هر بایت خوانده شده انجام می‌دهد. نقطه ریزج (Ridge Point) سخت‌افزار به عنوان حاصل تقسیم حداکثر FLOP/s بر حداکثر پهنای‌باند تعریف می‌شود.
این موضوع یک سقف تئوریک ایجاد می‌کند: MFU_ceiling ≈ intensity / ridge_point.
به عنوان مثال، در اندازه دسته ۱ و با دقت bf16، شدت محاسباتی تقریباً ۱ عملیات اعشاری به ازای هر بایت است. با توجه به نقطه ریزج سخت‌افزاری (مثلاً 1e15 تقسیم بر 3e12 که برابر با ۳۳۳ عملیات اعشاری بر بایت است)، سقف MFU تنها ۱ تقسیم بر ۳۳۳، یا حدود ۰.۳٪ است.
این یعنی اگر یک جریان رمزگشایی تک‌کاناله به ۰.۳٪ از توان پیک برسد، در واقع در حداکثر توان تئوریک خود در حال اجراست. تنها راه افزایش این سقف، افزایش شدت محاسبات است که منحصراً از طریق دسته‌بندی (Batching) — شبیه به این است که به‌جای پختن یک تکه نان، هم‌زمان یک سینی کامل را در فر بگذاریم — به دست می‌آید.
شناسایی گلوگاه‌های واقعی
در حالی که MFU پایین در رمزگشایی طبیعی است، اما در مرحله پیش‌پُرکردن (Prefill) یک مشکل جدی را نشان می‌دهد. چون در پیش‌پُرکردن، صدها یا هزاران توکن از هر وزن خوانده شده به طور مشترک استفاده می‌کنند، این مرحله بسیار بالاتر از نقطه ریزج قرار می‌گیرد. بنابراین، MFU پایین در اینجا نشان‌دهنده انتخاب نادرست هسته، طول توالی نامناسب یا Padding بیش از حد است.
علاوه بر محدودیت‌های ریاضی، «حباب‌هایی» وجود دارند که توان عملیاتی را نابود می‌کنند:
- دسته‌های خالی یا نامنظم: در دسته‌بندی استاتیک، یک دسته تا زمان تکمیل کامل اجرا می‌شود و سپس جایگزین می‌گردد. از آنجایی که توالی‌ها با طول‌های متفاوتی به پایان می‌رسند، جایگاه‌های توالی‌های تمام شده تا زمان تکمیل طولانی‌ترین توالی، بیکار می‌مانند. راهکار این مشکل، دسته‌بندی پیوسته (Continuous Batching) است که اجازه می‌دهد یک توالی جدید در اولین گام بعدی وارد جایگاه آزاد شده شود. این قابلیت، بزرگ‌ترین ویژگی افزایش توان عملیاتی در موتورهای مدرن است.
- مسدود شدن رمزگشایی توسط پیش‌پُرکردن: ورود یک پرامپت طولانی در میانه مسیر، دستگاه را برای یک پیش‌پُرکردن سنگین از نظر محاسباتی اشغال می‌کند، در حالی که تمام توالی‌های در حال رمزگشایی منتظر می‌مانند. این اتفاق باعث جهش شدید تأخیر بین-توکنی برای کاربران غیرمرتبط می‌شود. پیش‌پُرکردن تکه‌ای (Chunked Prefill) با تقسیم پرامپت به قطعات کوچک و تداخل آن‌ها با گام‌های رمزگشایی، این مشکل را حل می‌کند؛ در واقع کمی سرعت پیش‌پُرکردن را فدای رمزگشایی پایدارتر می‌کند.
- سریال‌سازی در سمت میزبان: سربار پایتون، توکن‌سازی، منطق نمونه‌گیری، بررسی محدودیت‌های JSON schema و ثبت لاگ‌ها، همگی بین اجرای هسته‌ها در GPU رخ می‌دهند. در دسته‌های کوچک، زمان کار دستگاه ممکن است تنها یک یا دو میلی‌ثانیه باشد که با مرتبه زمانی کارهای میزبان برابر است. به همین دلیل است که از Graph Capture و نمونه‌گیری دسته‌ای استفاده می‌شود.
- انتظارهای جمعی: در موازی‌سازی تانسوری، هر لایه با یک عملیات جمعی (Collective) به پایان می‌رسد. اگر دستگاه‌ها به‌دلیل فشار نابرابر حافظه یا کاهش فرکانس ساعت (Clock Throttling) کاملاً متوازن نباشند، سریع‌ترین دستگاه در هر مانع (Barrier) بیکار می‌ماند. این زمان بیکاری به‌صورت اشغال بالا اما توان عملیاتی پایین ظاهر می‌شود.
نظم جدید در عیب‌یابی
برای دیباگ درست یک استک، مهندسان باید این ترتیب عملیاتی را دنبال کنند: ابتدا رژیم کاری را مشخص کنید. اگر خروجی در حال تولید است، رمزگشایی غالب است و MFU پایین طبیعی است. موفقیت را باید با پهنای‌باند و تعداد توکن در ثانیه (Tokens per second) در کل دسته سنجید.
سپس، اندازه دسته واقعی به دست آمده در هر گام را در طول زمان تحلیل کنید. اگر یک موتور گزارش می‌دهد که توالی‌های «در حال اجرا» در مقابل «در انتظار» قرار دارند، وجود یک صف انتظار بزرگ در کنار یک دسته در حال اجرای کوچک نشان می‌دهد که حافظه محدودکننده است و باید KV Cache — شبیه به یادداشت‌های سریع مدل برای به خاطر سپردن کلمات قبلی — کوچک‌تر شود.
مهندسان همچنین باید به‌جای میانگین، توزیع تأخیر بین-توکنی (Inter-token latency) را مقایسه کنند. رمزگشایی پایدار با جهش‌های دوره‌ای نشان‌دهنده تداخل Prefill است، در حالی که رمزگشایی به‌طور یکنواخت کند، نشان‌دهنده محدودیت پهنای‌باند است که یک باگ محسوب نمی‌شود.
در نهایت، سربار میزبان را بررسی کنید. اگر زمان صرف شده در دستگاه در هر گام با فاصله بین گام‌ها قابل مقایسه است، گلوگاه CPU یا سربار نرم‌افزاری است. بررسی هسته‌ها باید آخرین مرحله باشد، هرچند اکثر مهندسان از همین‌جا شروع می‌کنند.
بازتعریف اهداف و ظرفیت
استفاده (Utilisation) یک هدف نیست، بلکه یک متغیر میانی است. اهداف واقعی، توان عملیاتی در تأخیر قابل قبول و هزینه به ازای هر توکن هستند. استکی که با اشغال ۶۰٪ کار می‌کند اما هدف تأخیر را در اندازه دسته‌ای که توسط بودجه حافظه تعیین شده برآورده می‌کند، سالم‌تر از استکی است که به‌دلیل پر بودن دائمی صف، روی ۱۰۰٪ قفل شده است.
مفیدترین نمودار، تعداد توکن در ثانیه در کل دسته را در مقابل تأخیر p95 بین-توکنی، هم‌زمان با افزایش اندازه دسته، نمایش می‌دهد. این نمودار ناحیه آزاد زیر نقطه ریزج، «زانو» (Knee) که در آن تأخیر هر کاربر افت می‌کند و نقطه‌ای که حافظه تمام می‌شود را آشکار می‌کند.
این موضوع برنامه‌ریزی ظرفیت را تغییر می‌دهد. چون ناحیه آزاد وجود دارد، یک نقطه پایانی (Endpoint) که به تعداد کمی کاربر سرویس می‌دهد، تنها از بخش کوچکی از سخت‌افزار خود استفاده می‌کند. افزودن کاربران تقریباً هیچ هزینه‌ای ندارد تا زمانی که به نقطه «زانو» برسیم. بنابراین، وقتی استفاده پایین است، حرکت بهینه به‌ندرت خرید دستگاه کوچک‌تر است، بلکه تجمیع ترافیک بیشتر روی سخت‌افزار موجود است. این رویکرد به ما کمک می‌کند تا به‌جای هزینه‌های گزاف سخت‌افزاری، بر مدیریت لایه‌های نرم‌افزاری برای رشد هوش مصنوعی تمرکز کنیم. این توضیح می‌دهد که چرا نقاط پایانی مشترک بین مستاجران زیاد، از نظر ساختاری ارزان‌تر از نقاط اختصاصی با حجم کم هستند، تا زمانی که دسته کاملاً پر شود.
گام بعدی شما
- ابزارهای مانیتورینگ خود را از Device Occupancy به پهنای‌باند حافظه و MFU تغییر دهید.
- توزیع تأخیر بین-توکنی (Inter-token latency) را به‌جای میانگین بررسی کنید تا تداخل‌های Prefill را شناسایی کنید.
- اگر اشغال GPU بالاست اما توان عملیاتی پایین است، ابتدا توازن بین گره‌ها در موازی‌سازی تانسوری را چک کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو