اگر امروز از سختافزارهای Ascend برای استقرار مدلهای زبانی بزرگ استفاده میکنید، احتمالاً ۸۰٪ از توان سختافزاری خود را روی میز جا گذاشتهاید. زمان بارگذاری مدل DeepSeek-70B روی پلتفرم Huawei Atlas 910B از ۱,۳۹۹ ثانیه به ۱۵۰ ثانیه کاهش یافت؛ جهشی ۹.۳ برابری که تنها با همگامسازی سه لایه مجزای نرمافزاری ممکن شد. این نتیجه که در ۱۱ اوت ۲۰۲۶ منتشر شد، ثابت میکند که استنتاج با کارایی بالا روی سختافزار Ascend را نمیتوان از طریق وصلههای ساده در فریمورک به دست آورد. این دستاورد در واقع تکمیلی بر بهینهسازیهای زیرساختی Mingxin FX100 است که پیشتر کاهش چشمگیر زمان بارگذاری مدل DeepSeek-70B را به نمایش گذاشته بود.
استنتاج (Inference) — لحظهای که مدل واقعاً جواب تولید میکند، شبیه به خودِ آشپزی و نه دورهی آموزش آشپز — در سختافزار Ascend 910B یک تلاش مهندسی جامع در لایههای درایور، اپراتور و فریمورک است. انطباق پشتهٔ استنتاج در این پلتفرم، موضوع وصله زدن به یک جزء واحد نیست، بلکه یک رویکرد سیستماتیک است. اگر هر یک از این لایهها نادیده گرفته شوند، بهینهسازیهای لایههای بالاتر اساس خود را از دست میدهند و عملاً بیاثر میشوند.
بسیاری از توسعهدهندگان با سختافزار هوش مصنوعی مانند یک جعبه سیاه یا یک انتزاع شفاف برخورد میکنند و تصور میکنند نوشتن یک اپراتور سطح بالا کافی است. این «تجربهٔ CUDA» در پلتفرم Ascend شکست میخورد؛ زیرا معماری محاسباتی ناهمگن آن، یعنی CANN، بهجای انتزاعهای کلی، بر نمایش عمیق توپولوژی سختافزار تأکید دارد. بر اساس مستندات رسمی «CANN - Ascend Heterogeneous Computing Architecture - Ascend Community»، این معماری نقشی مشابه CUDA در پلتفرمهای انویدیا دارد اما مسیر پیادهسازی متفاوتی را دنبال میکند. CANN از انتزاعهای شفاف و عمومی برای لایههای بالایی اجتناب میکند تا در عوض، توپولوژی واقعی سختافزار را در اختیار توسعهدهنده قرار دهد.
برای دستیابی به کارایی واقعی، باید درایور، اپراتور و فریمورک را به عنوان یک سیستم واحد و وابسته به هم ببینید. پشتهٔ هوش مصنوعی شما را میتوان به یک خط آهن سریعالسیر تشبیه کرد: درایور همان ریل است، اپراتور موتور قطار و فریمورک سیستم زمانبندی است. اگر ریلها تراز نباشند، سریعترین موتور جهان هم از مسیر خارج میشود یا به شدت کند میشود. لایه درایور تعیین میکند منابع سختافزاری چگونه توسط سیستمعامل دیده شوند، لایه اپراتور نحوه نگاشت محاسبات به واحدهای NPU (واحد پردازش عصبی) را مشخص میکند و لایه فریمورک استراتژیهای بهینهسازی گراف و مدیریت حافظه را مدیریت میکند.
لایه درایور: زیربنای دیدهشدن
لایه درایور پایه و اساس پشتهٔ استنتاج Ascend است و سه وظیفه اصلی دارد: شناسایی دستگاه (Device Enumeration)، نگاشت حافظه و مدیریت مسیرهای وقفه/DMA. در مدل 910B، اولین مانع بحرانی، ترتیب شناسایی دستگاه است. موقعیت NPU، HBM (حافظه پهنایباند بالا) و کنترلکننده ذخیرهسازی در توپولوژی PCIe، نزدیکی به گرههای NUMA را تعیین میکند. اگر درایور این توپولوژی را اشتباه گزارش کند، فریمورکهای لایه بالاتر ممکن است دادهها را روی گره NUMA اشتباه قرار دهند. این اتفاق باعث افزایش شدید تأخیر دسترسی بینگرهای میشود؛ مشکلی در سطح سختافزار که اپراتورها هرگز قادر به حل آن نیستند.
دومین میدان نبرد، دانهبندی نگاشت حافظه است. اینکه HBM و حافظه سیستم در Ascend از آدرسدهی یکپارچه (Unified Addressing) استفاده کنند یا آدرسدهی قطعهقطعه (Segmented Addressing)، مستقیماً بر نحوه پر شدن KV Cache توسط ذخیرهسازهای خارجی اثر میگذارد. طبق مستندات PyTorch، تخصیصکننده حافظه (Caching Allocator) فرض میکند مرز مشخصی بین حافظه دستگاه و حافظه میزبان وجود دارد. اگر درایور مسیری برای کپی صفر (Zero-copy) فراهم نکند، فریمورک مجبور به استفاده از کپیهای صریح میشود که تمام دستاوردهای شتابدهی ذخیرهسازی را از بین میبرد.
در نهایت، درایور باید تعادلی بین وقفهها (Interrupts) و نظارت (Polling) ایجاد کند. عملیات IOPS بالا از دستگاههای NVMe-oF به پردازش کارآمد صفهای تکمیل (Completion Queue) وابسته است. اگر درایور صرفاً بر پردازشهای مبتنی بر وقفه تکیه کند، سناریوهای با توان عملیاتی بالا باعث ایجاد تعویضهای متوالی زمینه (Context Switches) میشوند. طبق تستهای بارگذاری Mingxin روی پلتفرم 910B، تنظیم پارامترهای تجمیع وقفه (Interrupt Coalescing) در درایور تأثیر قابلاندازهگیری بر زمان بارگذاری داشت و به عنوان یک جهتگیری حیاتی برای تنظیم پشته شناسایی شد.
لایه اپراتور: نگاشت محاسبات به NPU
انطباق اپراتورها اغلب دستکم گرفته میشود زیرا NPUهای Ascend شفاف نیستند. یک ضرب ماتریسی که در CUDA بهطور یکنواخت توسط cuBLAS توزیع میشود، در Ascend نیازمند انتخاب صریح نسخههای اپراتور است؛ زیرا سلسلهمراتب HBM در Ascend با انویدیا متفاوت است و سیاستهای حافظه کش L2 و ویژگیهای تخصیص پهنایباند خاص خود را دارد.
بر اساس منطق مقاله FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness، گلوگاه اصلی در محاسبات توجه (Attention)، پهنایباند HBM است و نه قدرت محاسباتی خام. این موضوع در Ascend نیز صادق است. در نتیجه، اپراتورهایی که برای CUDA بهینه شدهاند، هنگام انتقال به 910B باید استراتژیهای بلوکبندی (Blocking Strategies) خود را بازتنظیم کنند. تجربه Mingxin نشان میدهد تمرکز باید از اپراتورهای سنگین محاسباتی مانند GEMM به اپراتورهای متمرکز بر دسترسی حافظه، مانند بازیابی KV در Attention و کاهش در RMSNorm تغییر کند.
- الگوی ناکارآمد: «ابتدا همه چیز را بارگذاری کن، سپس محاسبه کن»؛ این روش تأخیر ذخیرهسازی را مستقیماً در مسیر بحرانی قرار میدهد.
- الگوی کارآمد: «بارگذاری بلوکبهبلوک با محاسبات خطلولهای»؛ این روش تأخیر ذخیرهسازی را پنهان میکند.
- تلفیق سفارشی (Custom Fusion): توسعهدهندگان میتوانند با استفاده از فریمورک توسعه اپراتور CANN، اپراتورهای تلفیقی تعریف کنند. طبق مستندات «CANN - Ascend Heterogeneous Computing Architecture»، این قابلیت اجازه میدهد چندین اپراتور در یک کرنل ادغام شوند تا جابهجایی دادههای میانی کاهش یابد.
در سناریوی KV Cache، تلفیق «خواندن بلوک KV + محاسبه Attention» در یک اپراتور میتواند رفتوبرگشتهای بین NPU و ذخیرهساز را بهشدت کاهش دهد. با این حال، سود حاصل از این بهینهسازی به دانهبندی تلفیق و عمق خطلوله سختافزاری بستگی دارد و باید مورد به مورد تأیید شود.
لایه فریمورک: استراتژی گراف و حافظه
لایه فریمورک جایی است که اکثر انطباقهای «صوری» رخ میدهند؛ کدهایی که اجرا میشوند اما بهینه نیستند. چالش اصلی، کامپایلر ACL Graph است که کل گراف محاسباتی را پیش از اجرا بازنویسی میکند. اگر کامپایلر نتواند «خواندن KV Cache» را به عنوان یک وابستگی خارجی شناسایی کند، ممکن است عملیات خواندن از ذخیرهساز را به اشتباه پس از محاسبات زمانبندی کند و باعث توقف خطلوله (Pipeline Stall) شود. در تستهای Mingxin روی 910B، تغییر سطح بهینهسازی گراف برای جلوگیری از این خطاهای زمانبندی ضروری بود.
مدیریت حافظه نیز به همان اندازه حیاتی است. بر اساس اصول Efficient Memory Management for Large Language Model Serving with PagedAttention، مدیریت صفحهبندیشدهٔ KV Cache باعث کاهش تکهتکه شدن حافظه میشود. در Ascend این مکانیسم قابل اجراست، اما موفقیت آن به این بستگی دارد که فریمورک رابطهای صفحهبندی را ارائه دهد. اگر لایه فریمورک از نگاشت مستقیم ذخیرهساز خارجی به استخر صفحهبندی پشتیبانی نکند، شتابدهی لایهای KV Cache محقق نخواهد شد.
در تستهای FX100 روی 910B، شتاب ۹.۳ برابری برای DeepSeek-70B تنها به این دلیل رخ داد که فریمورک اجازه داد دستگاههای ذخیرهسازی، بافرهای وزن مدل را مستقیماً پر کنند. اگر فریمورک مسیر «رله میزبان» (Host Relay) — یعنی کپی به حافظه میزبان پیش از انتقال به دستگاه — را تحمیل کند، این شتاب ناپدید میشود. این پر کردن مستقیم، کلید کاهش زمان از ۱,۳۹۹ ثانیه به ۱۵۰ ثانیه است.
توالی اجرا و اعتبارسنجی
انطباق باید از یک ترتیب خطی سختگیرانه پیروی کند: درایور $ \rightarrow $ اپراتور $ \rightarrow $ فریمورک. این توالی اجباری است زیرا اگر لایه درایور دستگاه یا توپولوژی آن را نشناسد، بهینهسازیهای لایههای اپراتور و فریمورک بیمعنی خواهند بود.
اعتبارسنجی در هر مرحله نیازمند معیارهای متفاوتی است:
- درایور: بررسی شناسایی دستگاه، توپولوژی NUMA و در دسترس بودن مسیرهای کپی صفر.
- اپراتور: اولویتدهی به اپراتورهای متمرکز بر دسترسی حافظه و استفاده از ابزارهای پروفایلینگ برای مشاهده الگوهای دسترسی حافظه در اپراتورهای Attention و تأیید نبود کپیهای میانی غیرضروری.
- فریمورک: استفاده از معیارهای سرتاسری (End-to-End) به عنوان استاندارد نهایی. اندازهگیری زمان بارگذاری مدل، زمان تا نخستین توکن (TTFT) و توان عملیاتی کل، بهجای تکیه بر دادههای پروفایلینگ یک لایه واحد.
برای مدل DeepSeek-32B، این رویکرد سهلایه زمان بارگذاری را از ۶۹۱ ثانیه به ۱۱۲ ثانیه (شتاب ۶.۲ برابری) کاهش داد [اندازهگیری شده، گزارش R2]. این اعداد تنها زمانی تکرارپذیر هستند که هر سه لایه همراستا باشند. اگر تنها بهینهسازی لایه ذخیرهسازی انجام شود و انطباق سهلایه نادیده گرفته شود، این نتایج حاصل نخواهند شد.
این تغییر رویکرد، معیار استقرار در Ascend را جابهجا میکند و هدف را از «اجرا شدن» به «کارآمد شدن» تغییر میدهد و مهندسان را مجبور میکند به سطوحی پایینتر از فریمورک نگاه کنند. برای کسانی که خوشههای استنتاج در مقیاس بزرگ میسازند، پیام روشن است: نادیده گرفتن لایههای درایور و اپراتور یعنی رها کردن ۸۰٪ از عملکرد سختافزار.
گام بعدی شما
برای مشاهده این دستاوردها در محیط خود، با این موارد شروع کنید:
- پروفایلینگ نزدیکی (Affinity) گرههای NUMA در محیط استقرار خود را بررسی کنید.
- در تنظیمات درایور فعلی، وجود مسیرهای کپی صفر (Zero-copy) را برای انتقال دادهها اعتبارسنجی کنید.
- اپراتورهای متمرکز بر دسترسی حافظه را در مدلهای خود شناسایی و استراتژی بلوکبندی آنها را بازنگری کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو