اگر امروز تنها به درصد بهره‌وری GPU برای سنجش سلامت سرویس خود تکیه می‌کنید، احتمالاً توسط داده‌های خودتان فریب خورده‌اید. یک دستگاه که ۱۰۰٪ درگیر است، لزوماً در حال انجام محاسبات مفید نیست و ممکن است تنها در یک حلقهٔ بی‌پایان گیر کرده باشد. در واقع، متریک بهره‌وری شما احتمالاً درباره سلامت سرویس استنتاج (Inference) دروغ می‌گوید.
بسیاری از مهندسان تصور می‌کنند وقتی داشبوردها دمای مناسب، مصرف حافظه و بهره‌وری را برجسته می‌کنند، همه چیز مرتب است. اما این شاخص‌های «سطحی» (Level Metrics) نمی‌توانند تفاوت بین یک پردازندهٔ کاملاً اشباع‌شده و کرنلی را تشخیص دهند که تنها از ۲٪ پردازنده‌های جریان-چندگانه (Streaming Multiprocessors) استفاده می‌کند اما به‌طور مداوم در حال تکرار است؛ در هر دو حالت، گزارش بهره‌وری ۱۰۰٪ است. این موضوع دقیقاً همان چالش فریب شاخص Occupancy است که پیش‌تر بررسی کردیم و نشان می‌دهد چرا ابزارهای نظارتی رایج در تشخیص کارایی واقعی دچار خطا می‌شوند. از آن‌جا که یک سیگنال اشباع‌شده نمی‌تواند کنترل‌کننده را هدایت کند، هرگز به شما نمی‌گوید که آیا فضای رشد (Headroom) دارید یا در آستانهٔ یک فاجعه هستید.
در ۸ اوت ۲۰۲۶، راهنمای فنی منتشرشده در dev.to با جزئیات توضیح داد که چرا تکیه بر این سیگنال‌های رایج، منجر به ایجاد نقاط کوری در محیط‌های عملیاتی هوش مصنوعی می‌شود. در یک محیط حساس و با ریسک بالا، اگر یک پاد (Pod) سرویس‌دهنده بهره‌وری نزدیک به صفر نشان دهد در حالی که درخواست‌ها در صف منتظرند، این یک هشدار بحرانی است؛ این یعنی کار در توکن‌سازی (Tokenization) — شبیه به خرد کردن جملات به تکه‌های کوچک برای فهم مدل — یا در یک قفل نرم‌افزاری (Lock)، یک بارگذار داده (Data Loader) یا یک فراخوان شبکه گیر کرده است، نه در خودِ GPU.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی زیرساخت‌های مدل‌های زبانی اشاره کردیم، تفاوت بین «پایش سطح» و «پایش وضعیت» تعیین‌کننده است. برای عبور از این توهمات، مهندسان باید از نظارت بر «سطوح» به سمت پایش «وضعیت‌ها» حرکت کنند. طبق گزارش dev.to، آموزنده‌ترین شمارنده‌ها آن‌هایی هستند که یک وضعیت فیزیکی را نام‌گذاری می‌کنند که پیش از وقوع یک شکست قابل مشاهده برای کاربر رخ می‌دهد.
لایه وضعیت سخت‌افزار
پایش مؤثر با کتابخانه مدیریت NVIDIA آغاز می‌شود. در واقع یک منبع زیربنایی برای تله‌متری وجود دارد و چندین راه برای خواندن آن هست. در حالی که nvidia-smi یک رابط کاربری انسان‌خوان برای بازرسی‌های تک‌مرحله‌ای و موردی فراهم می‌کند، مدیریت GPU مرکز داده (DCGM) استاندارد صنعتی برای یک دیمون (Daemon) است که برای استخراج داده (Scraping) طراحی شده است. برای خوشه‌های کوبرنتیز، اجرای DCGM exporter به عنوان یک DaemonSet روی گره‌های GPU اجازه می‌دهد تا متریک‌ها با برچسب پاد و کانتینر خاصی که از دستگاه استفاده می‌کند، علامت‌گذاری شوند و این امر تخصیص متریک‌ها به هر حجم کاری (Per-workload attribution) را ممکن می‌سازد.
مهندسان می‌توانند از nvidia-smi برای نیازهای مختلف استفاده کنند: یک پرس‌وجوی خاص برای استخراج CSVهای ماشین‌خوان (با استفاده از --query-gpu برای فیلدهایی مثل clocks_throttle_reasons.active و ecc.errors.uncorrected.volatile.total)، یا استفاده از دستور nvidia-smi dmon -s pucvmet -d 1 برای نمونه‌برداری مداوم در حین یک حادثه، به صورت یک خط در هر ثانیه. در Prometheus، این فیلدها از الگوی DCGM_FI_DEV_* پیروی می‌کنند، مانند DCGM_FI_DEV_GPU_UTIL و DCGM_FI_DEV_FB_USED.
- دلایل Throttle (کاهش سرعت): این حیاتی‌ترین شمارنده است. این ابزار با استفاده از یک بیت‌ماسک (Bitmask) مشخص می‌کند که آیا فرکانس ساعت به‌دلیل مسائل حرارتی، محدودیت‌های توان، کند شدن سخت‌افزاری یا یک تنظیم ساعت اعمال‌شده، پایین‌تر از حداکثر است یا خیر. این ابزار معمای مبهم «کند شدن استنتاج» را به یک علت فیزیکی نام‌دار تبدیل می‌کند. Throttle مداوم به این معناست که دستگاه محاسبات کمتری نسبت به آنچه هزینه پرداخت کرده‌اید، ارائه می‌دهد.
- خطاهای XID: این رویدادهای سطح درایور، نزدیک‌ترین چیز به یک بیانیه قطعی درباره شکست هستند. هر XID شماره‌ای دارد که کلاسی از خطاها را شناسایی می‌کند؛ مثلاً خطاهای حافظه، آدرس‌های غیرمجاز یا حالتی که دستگاه «از باس جدا شده است» (Fallen off the bus). خطاهای XID در لاگ کرنل اغلب توضیح می‌دهند چرا یک پاد بدون هیچ خطای در سطح اپلیکیشن، ناگهان می‌میرد.
- خطاهای ECC: خطاهای حافظه به دو دسته قابل اصلاح (Correctable) و غیرقابل اصلاح (Uncorrectable) تقسیم می‌شوند. افزایش خطاهای قابل اصلاح، سیگنالی از تخریب سخت‌افزاری است که ارزش اقدام دارد. خطاهای غیرقابل اصلاح می‌توانند به‌طور خاموش محاسبات را فاسد کنند یا پردازش‌ها را متوقف کنند؛ در قطعات مرکز داده، این معمولاً به این معناست که کارت باید تخلیه (Drain) و جایگزین شود.
- توان مصرفی در برابر حد مجاز: نسبت این دو مهم‌تر از مقدار مطلق است. قرار داشتن در سقف توان (Power Cap) به این معناست که حجم کاری محدود به توان است و فرکانس ساعت افت خواهد کرد. برعکس، افت ناگهانی توان مصرفی در حالی که درخواست‌ها همچنان ادامه دارند، به این معناست که داده‌ها دیگر به دستگاه نمی‌رسند.
- دما: این شاخص بیشتر برای توضیح علت یک Throttle حرارتی مفید است تا به عنوان یک هشدار مستقل. کارتی که داغ است اما سرعتش کم نشده، صرفاً دارد وظیفه‌اش را انجام می‌دهد.
ظرافت‌های حافظه و توان عملیاتی
پایش حافظه فریم‌بافر نیازمند رویکرد روند-محور است تا رویکرد ساده‌ی آستانه‌ای (Threshold). عدد کلیدی که باید رصد شود، حافظه آزاد در وضعیت پایدار (Steady State) است. چون KV Cache — شبیه به تخته‌سیاهی که مدل برای یادآوری بخش‌های قبلی متن از آن استفاده می‌کند — با افزایش هم‌زمانی و طول متن رشد می‌کند، خطاهای کمبود حافظه (OOM) به‌طور ناگهانی رخ می‌دهند؛ به‌ویژه زمانی که یک درخواست طولانی با یک دسته (Batch) پر هم‌زمان شود.
توان عملیاتی PCIe یا interconnect زمانی به داستان اصلی تبدیل می‌شود که وزن‌ها در حال بارگذاری باشند، تنسورها در هر گام جابجا شوند یا یک مدل بین چندین دستگاه تقسیم (Shard) شده باشد. اشباع در این لایه منجر به دستگاهی می‌شود که در انتظار داده‌ها بیکار مانده است؛ این دقیقاً همان مورد خاصی است که در آن بهره‌وری پایین، واقعاً خبر از یک مشکل می‌دهد. در محیط‌های محلی، این نوع اختلالات می‌تواند با ابزارهایی مانند Picchio شناسایی شود که تخصصش در تشخیص «پس‌نشینی خاموش» مدل‌ها به CPU و خطاهای کوانتش است.
متریک‌های سطح سرویس در برابر سطح دستگاه
شمارنده‌های دستگاه مشکل را «توضیح» می‌دهند، اما متریک‌های سرویس آن را «تشخیص» می‌دهند. اگر توجه سیستم هشدار محدود است، این راهنما استدلال می‌کند که ابتدا باید روی لایه اپلیکیشن متمرکز شد:
۱. عمق صف و انتظار: اندازه‌گیری شده به عنوان انتظار صف به ازای هر رپلیکا. این اولین نشانگر مشکل ظرفیت و محرک اصلی برای مقیاس‌دهی خودکار (Autoscaling) است.
۲. توکن در ثانیه: عدد بهره‌وری به ازای هر رپلیکا. کاهش تدریجی این عدد در بار ثابت، امضای Throttle حرارتی، یک کارت تخریب‌شده یا تغییر در توزیع ورودی‌ها به سمت پرامپت‌های طولانی‌تر است.
۳. زمان تا نخستین توکن (TTFT): مقدار p95 از TTFT چیزی است که کاربران واقعاً حس می‌کنند و معمولاً پیش از افزایش تأخیر کلی (End-to-End)، بالا می‌رود.
۴. اندازه دسته (Batch Size) محقق‌شده: اگر سرور دسته‌بندی می‌کند، این متریک نشان می‌دهد آیا مکانیزم درست کار می‌کند یا خیر. سقوط اندازه دسته در نرخ درخواست ثابت به این معناست که درخواست‌ها آن‌طور که در محاسبات توان عملیاتی فرض شده بود، هم‌پوشانی ندارند.
۵. تولیدات شکست‌خورده بر اساس علت: ردیابی شکست‌ها بر اساس OOM، Timeout، خطای دستگاه یا قطع شدن (Truncation)، مستقیماً به ریشه‌های مختلف مشکل اشاره می‌کند.
برای به حداکثر رساندن ارزش، تمام متریک‌های سرویس را با یک شناسه دستگاه (Device ID) و برچسب گره (Node Label) منتشر کنید. این کار اجازه می‌دهد یک ناهنجاری در سطح سرویس در یک پرس‌وجوی واحد به یک علت در سطح دستگاه متصل شود.
پیاده‌سازی هشدارهای با سیگنال بالا
برای جلوگیری از خستگی هشدار (Alert Fatigue)، این راهنما سه هشدار خاص را پیشنهاد می‌کند. اول، یک هشدار علامت‌محور برای کاربران: InferenceQueueWaitHigh زمانی فعال می‌شود که p95 انتظار صف برای ۱۰ دقیقه بالای ۱۰ ثانیه باشد. دوم، هشدار نقص سخت‌افزاری: GPUDeviceFault فوراً فعال می‌شود اگر افزایشی در DCGM_FI_DEV_XID_ERRORS یا DCGM_FI_DEV_ECC_UNCORRECTABLE_TOTAL رخ دهد. سوم، هشدار ظرفیت: GPUThrottledSustained یک تیکت ایجاد می‌کند اگر DCGM_FI_DEV_CLOCK_THROTTLE_REASONS برای ۳۰ دقیقه بیشتر از ۰ باشد.
طراحی داشبورد عملیاتی
یک داشبورد مؤثر باید از بالا به پایین و از «علامت» به «علت» خوانده شود:
- ردیف اول (سرویس): نرخ درخواست، TTFT p50 و p95، انتظار صف p95 و نرخ خطا بر اساس کلاس. پاسخ به: «آیا مشکلی هست؟»
- ردیف دوم (توان عملیاتی): توکن در ثانیه به ازای هر رپلیکا، اندازه دسته محقق‌شده و تولیدات هم‌زمان در برابر حداکثر مقدار پیکربندی شده. پاسخ به: «آیا کار پیش می‌رود؟»
- ردیف سوم (دستگاه‌ها): حافظه آزاد فریم‌بافر هر GPU، دلیل Throttle (که به جای نمودار خطی، به صورت یک Timeline از وضعیت‌ها نمایش داده شود) و توان مصرفی در برابر حد مجاز. پاسخ به: «چرا پیش نمی‌رود؟»
- ردیف چهارم (رویدادها): تعداد XID و ECC، ری‌استارت‌های پاد و نشانگرهای استقرار (Deploy markers). پاسخ به: «چه چیزی تغییر کرد؟» وجود یک نشانگر استقرار روی همان محور زمانی اغلب حوادث را فوراً حل می‌کند.
یک متریک غیرفنی برای بخش تجاری ضروری است: هزینه هر هزار درخواست موفق در طول زمان. این تنها خطی است که پس‌رفت‌های هزینه‌ای را شکار می‌کند؛ جایی که تأخیر با افزودن رپلیکاها کم شده اما هزینه بدون بهبود عملکرد واقعی، افزایش یافته است.
این تغییر در رویکرد پایش، فرض بنیادی عملیات هوش مصنوعی را عوض می‌کند. مهندس از واکنش به «بهره‌وری بالا» — که اغلب نشانه یک سیستم سالم و شلوغ است — به واکنش به «وضعیت‌های Throttle» حرکت می‌کند که نشانه‌های سرمایه تلف‌شده و عملکرد تخریب‌شده هستند.
گام بعدی شما
- داشبورد خود را بازبینی کنید و متوجه شوید آیا در حال پایش «سطح» (Level) هستید یا «وضعیت» (Condition).
- شمارنده‌های XID و ECC را به سیستم هشدار لحظه‌ای خود اضافه کنید تا پیش از سقوط سرویس، از تخریب سخت‌افزار مطلع شوید.
- متریک «هزینه هر هزار درخواست موفق» را برای نظارت بر بازدهی اقتصادی زیرساخت تعریف کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو