اگر GPU شما در حالی که CPU در حال تلاش برای اجرای کرنل‌هاست بیکار می‌ماند، احتمالاً با یک گلوگاهِ «محدود به سربار» (Overhead-bound) دست‌وپنجه نرم می‌کنید. این تله‌ای رایج برای توسعه‌دهندگانی است که می‌خواهند تعداد توکن‌های تولیدشده در هر ثانیه را در مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — افزایش دهند.
تنها راه بهینه‌سازی چیزهایی که نمی‌بینید، تحلیل دقیق یا پروفایلینگ است. اکثر توسعه‌دهندگان از این کار می‌گریزند چون خروجی‌های پروفایلر شبیه دیواره‌ای از مستطیل‌های رنگی است. اما تسلط بر ماژول torch.profiler به شما کمک می‌کند تفاوت بین یک «کرنل کند» و یک «زنجیره توزیع کند» را بفهمید. به نقل از راهنمایی که در ۲۹ می ۲۰۲۶ توسط Hugging Face منتشر شد، مسیر بهینه‌سازی نیازمند درک دو ابزار است: جدول پروفایلر برای نقاط داغ آماری و ردپای (Trace) پروفایلر برای تحلیل زمانی اجرا.
همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی حافظه در مدل‌های بازمتن اشاره کردیم، ابعاد داده‌ها تعیین‌کننده رفتار سخت‌افزار هستند. در عملیات کوچک، مثل ضرب ماتریس‌های ۶۴ در ۶۴، GPU اغلب کمتر از ۱٪ زمان را صرف محاسبات می‌کند. در این حالت، CPU بیشتر وقت خود را صرف آماده‌سازی و ارسال دستورات می‌کند. اما با افزایش اندازه ماتریس‌ها به ۴۰۹۶ در ۴۰۹۶، بار کاری به «محدود به محاسبات» (Compute-bound) تغییر می‌کند و در نهایت خودِ کرنل GPU به گلوگاه اصلی تبدیل می‌شود.
بررسی عمیق زنجیره توزیع نشان می‌دهد PyTorch چگونه سخت‌افزار را مدیریت می‌کند. کرنل‌های سنگین مثل GEMM، ابتدا یک فراخوانی برای بررسی ظرفیت بلوک‌ها در پردازنده دارند. این یک مرحله برنامه‌ریزی است تا مشخص شود چه تعداد بلوک در یک پردازنده جریان (SM) جای می‌گیرند. عملیات‌های ساده‌تر این مرحله را رد می‌کنند چون نیاز به منابع آن‌ها ثابت و کم است.
استفاده از torch.compile بازی را با معرفی ادغام عملگرها (Operator Fusion) — مثل ترکیب چند مرحله‌ی خرد کردن و پخت سبزیجات در یک قابلمه برای صرفه‌جویی در زمان — تغییر می‌دهد. این ابزار، ضرب ماتریس و جمع را در یک فراخوانی واحد (aten::addmm) بازنویسی می‌کند. اما این ادغام اغلب در سطح توزیع‌کننده رخ می‌دهد، نه در سطح کرنل.
در عمل، نسخه کامپایل‌شده هنوز برای مقداردهی اولیه بافر، یک کپی دستگاه-به-دستگاه (Memcpy DtoD) اجرا می‌کند. علاوه بر این، برای عملیات‌های تک‌گانه، torch.compile یک «مالیات CPU» اضافه می‌کند. سربار پشته‌ی Dynamo و Inductor می‌تواند هزینه اجرای یک عملیات را در CPU تا دو برابر حالت عادی (Eager mode) افزایش دهد. بنابراین نباید تنها به میانگین زمان اجرا اعتماد کنید؛ یک ردپای دقیق ممکن است نشان دهد کرنلی که معمولاً ۵۸۰ میکروثانیه زمان می‌برد، گاهی به دلیل مدیریت توان یا کاهش فرکانس GPU، دچار جهش زمانی می‌شود.
گام بعدی شما
- برای کاهش سربار، عملیات‌ها را دسته‌بندی (Batching) کنید.
- حالت‌های مختلف
torch.compileرا برای کاهش مالیات توزیع‌کننده آزمایش کنید. - به جای تکیه بر میانگین زمان، از Trace برای شناسایی جهش‌های زمانی (Spikes) استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو