در ادامه بحث درباره کاهش وابستگی زیرساخت هوش مصنوعی به انویدیا، یک پرسش مهم مطرح شد: وقتی مزیت اصلی انویدیا فقط در تراشه نیست و به یک زیست‌بوم بزرگ نرم‌افزاری و عملیاتی تکیه دارد، آیا مجموعه‌هایی با منابع محدود اصلاً می‌توانند مسیر دیگری را دنبال کنند؟ آیا چنین تلاشی به پراکندگی منابع و آزمون‌وخطایی پرهزینه منتهی نمی‌شود؟
این پرسش را باید جدی گرفت. داشتن یک شتاب‌دهنده با مشخصات مناسب، به معنی داشتن زیرساخت آماده بهره‌برداری نیست. اما در پاسخ، باید میان هزینه ساختن یک زیست‌بوم و هزینه استفاده از اجزای موجود آن تفاوت گذاشت. قرار نیست هر بهره‌بردار، همه ابزارهای موردنیاز مسیر دوم را خودش از ابتدا بسازد.
انتشار DeepInfer، چارچوب استنتاج دیپ‌سیک، فرصت مناسبی برای بررسی همین تفاوت است. در مستندات رسمی منتشرشده از این چارچوب، انویدیا و Ascend هر دو در فهرست سخت‌افزارهای پشتیبانی‌شده قرار دارند. این یادداشت را باید در امتداد پرسش یادداشت «اگر فردا NVIDIA را برداریم، چه چیزهایی می‌شکند؟» خواند: کدام قطعات مسیر جایگزین در حال ساخته‌شدن هستند، کدام‌ها در اختیار دیگران قرار گرفته‌اند و چه مسئولیت‌هایی همچنان بر عهده بهره‌بردار باقی مانده است؟
DeepInfer چه چیزی را در اختیار می‌گذارد؟
طبق توضیحات در مخزن رسمی، DeepInfer چارچوب استنتاجی است که خدمات بزرگ‌مقیاس دیپ‌سیک بر آن تکیه دارند. نسخه عمومی با مجوز Apache 2.0 منتشر شده و فعلاً از DeepSeek-V4.1-Flash روی شتاب‌دهنده‌های NVIDIA SM100 و Huawei Ascend 950 پشتیبانی می‌کند. بنابراین با یک موتور عمومی برای همه مدل‌ها و همه کارت‌های موجود روبه‌رو نیستیم.
نکته مهم‌تر در سند فنی استقرار آمده است: پشتیبانی از شتاب‌دهنده‌های چند سازنده، یکی از اهداف اولیه طراحی سامانه معرفی شده؛ با تأکید بر استفاده از توان هر پلتفرم. برداشت راهبردی از این انتخاب روشن است: یک بهره‌بردار می‌تواند بهینه‌سازی عملکرد را دنبال کند و هم‌زمان، امکان اجرا روی بیش از یک خانواده سخت‌افزاری را در طراحی خود بگنجاند.
این سند، اثبات برابری دو پلتفرم نیست. همچنین نشان نمی‌دهد جابه‌جایی میان آن‌ها بدون هزینه انجام می‌شود. اما نمونه‌ای مشخص از تبدیل «حفظ امکان انتخاب» به یک هدف مهندسی ارائه می‌کند؛ هدفی که باید برای تحقق آن نرم‌افزار نوشته شود و محدودیت‌های هر سخت‌افزار شناخته شود.
رابط مشترک، مهندسی متفاوت
برای فهم اهمیت این تحول، کتابخانه DeepEP-Ascend نیز قابل‌توجه است. این کتابخانه برای ارتباطات موردنیاز آموزش و استنتاج روی Ascend توسعه یافته و رابط عمومی buffer آن با نسخه انویدیایی DeepEP هم‌راستا شده است. در لایه زیرین، از ابزارها و سازوکارهای ارتباطی اختصاصی Ascend استفاده می‌کند.
چنین رویکردی می‌تواند بخشی از تفاوت سخت‌افزار را پشت یک رابط مشابه مدیریت کند. اما مشابه‌بودن رابط به معنی یکسان‌بودن رفتار، کارایی یا هزینه نگهداری نیست. پیاده‌سازی و بهینه‌سازی زیرین همچنان به تخصص نیاز دارد.
اهمیت انتشار این اجزا برای بهره‌برداران بعدی در همین‌جاست: می‌توانند به‌جای بازسازی تمام لایه‌ها، از یک پیاده‌سازی موجود شروع کنند و توان خود را صرف ارزیابی و تکمیل نیاز مشخصشان کنند. موفقیت این مسیر را باید در عمل سنجید، اما نمی‌توان هزینه آن را از پیش معادل هزینه خلق کل زیست‌بوم دانست.
پشتیبانی از Ascend، بنچمارک Ascend نیست
در بازتاب خبری انتشار DeepInfer، عددهای بزرگی نیز دیده می‌شود. برای استفاده تحلیلی، باید سه موضوع را جدا نگه داشت: سخت‌افزار پشتیبانی‌شده، سخت‌افزار آزموده‌شده و سامانه‌ای که آمار بهره‌برداری به آن مربوط است.
README رسمی DeepInfer تصریح می‌کند بنچمارک‌های منتشرشده روی SM100 انویدیا انجام شده‌اند؛ چهار GPU برای پیش‌پردازش و ۶۴ GPU برای تولید خروجی. بنابراین عدد عملکرد این آزمون‌ها را نمی‌توان به Ascend نسبت داد.
دیپ‌سیک همچنین در سند پرسش‌وپاسخ استقرار از پردازش روزانه ۱۵۵ تریلیون توکن در یک خوشه خبر می‌دهد. این ادعای توسعه‌دهنده، به‌خودی‌خود ترکیب سخت‌افزار خوشه یا سهم ورودی، خروجی و استفاده مجدد از کش را روشن نمی‌کند. پس آن را نباید معادل ظرفیت اثبات‌شده یک خوشه Ascend یا مبنای مقایسه مستقیم با یک استقرار دیگر گرفت.
در این مرحله، شاهد روشن ما انتشار نرم‌افزار با پشتیبانی اعلام‌شده از دو پلتفرم است؛ برای داوری درباره برابری عملکرد و هزینه، به آزمون مقایسه‌ای نیاز داریم.
میان اجرای مدل و ارائه خدمت، فاصله باقی است
نسخه عمومی DeepInfer فعلاً استنتاج آفلاین را ارائه می‌کند. مستندات انتشار، سامانه KV cache، اجزای لازم برای استقرار تفکیک‌شده مراحل پردازش و توازن بار میان نمونه‌ها را از نیازهای یک خدمت کامل می‌شمارند که در این انتشار ارائه نشده‌اند.
این تفاوت برای تصمیم زیرساختی تعیین‌کننده است. اجرای موفق یک مدل، هنوز پاسخ پرسش‌هایی مانند کنترل صف، حفظ کیفیت خدمت زیر بار، بازیابی پس از خرابی و توسعه ظرفیت نیست. برای تبدیل کد منتشرشده به خدمت قابل اتکا، باید این فاصله‌ها در برنامه و هزینه پروژه دیده شوند.
از سوی دیگر، «آفلاین» در اینجا اشاره به شیوه اجرای استنتاج دارد؛ نباید از آن نتیجه گرفت که یک محصول آماده برای نصب در هر شبکه بسته سازمانی تحویل شده است.
در مقیاس استقرار هم احتیاط لازم است. سند استقرار دیپ‌سیک برای معماری توصیه‌شده، کوچک‌ترین واحد کارا را ۶۴ GPU برای پیش‌پردازش و ۶۴ GPU برای تولید خروجی معرفی می‌کند. این توصیه درباره همان مدل و معماری است؛ نه حداقل اندازه همه کاربردهای هوش مصنوعی. بااین‌حال، نشان می‌دهد انتشار حاضر را نباید نسخه آماده و اقتصادی برای هر مجموعه کوچک معرفی کرد.
منابع محدود، مسئولیت انتخاب را بیشتر می‌کند
برای یک تیم کوچک ممکن است اجرای مستقیم این معماری توجیه نداشته باشد. ارزش چنین انتشاری لزوماً در نصب کامل آن نیست؛ شناخت روش‌ها، بررسی کد و ارزیابی امکان استفاده از بعضی اجزا نیز می‌تواند موضوع کار باشد. انتقال تجربه باید با سنجش سازگاری و هزینه انجام شود؛ هیچ تضمینی وجود ندارد که یک بهینه‌سازی در مقیاسی دیگر همان منفعت را ایجاد کند.
برای مجموعه‌ای که نیاز و مقیاس مناسب دارد، پرسش دقیق‌تر این است: با استفاده از اجزای منتشرشده، چه مقدار از هزینه مهندسی مسیر دوم کاهش می‌یابد و چه مقدار باقی می‌ماند؟ پاسخ باید تأمین سخت‌افزار، نیروی متخصص، نرم‌افزارهای وابسته، نگهداری و تعهد خدمت را پوشش دهد.
داشتن بودجه محدود، دلیل پراکنده‌کردن منابع میان چند پلتفرم نیست. اما دلیل حذف ارزیابی وابستگی هم نیست. هر دو تصمیم هزینه دارند و هر دو باید توجیه شوند.
از پیشنهاد تنوع‌بخشی به آزمونی مشخص
نتیجه عملی این تحول برای ما، خرید فوری Ascend یا تعویض موتورهای موجود نیست. می‌توان یک مدل و بار کاری مشخص انتخاب کرد، پیش‌نیازهای دو مسیر را سنجید و مقایسه‌ای با سقف هزینه، زمان و معیار توقف روشن تعریف کرد.
در چنین آزمونی، صرف اجرای مدل یا رسیدن به بیشترین تعداد توکن کافی نیست. کیفیت خروجی، زمان انتظار، سرعت پاسخ زیر بار، پایداری و ساعات مهندسی مصرف‌شده باید کنار هم ثبت شوند. عملکرد بهتر بدون امکان نگهداری، یا قیمت خرید کمتر همراه با هزینه نرم‌افزاری بالاتر، ممکن است مزیت مورد انتظار را از بین ببرد.
اگر نتیجه نامناسب بود، گسترش آن مسیر متوقف می‌شود؛ اگر مناسب بود، می‌توان بخشی مشخص از نیاز را به آن سپرد. این همان تفاوت ارزیابی مهندسی با آزمون‌وخطای بی‌پایان است: پیش از شروع معلوم است چه می‌خواهیم بدانیم و با چه نتیجه‌ای ادامه می‌دهیم.
توان انتخاب، به‌تدریج ساخته می‌شود
در یادداشت «کاهش وابستگی به انویدیا؛ پاسخ به چند پرسش راهبردی» تأکید کردم که تأمین تجهیزات ضروری امروز و ساختن توان انتخاب فردا می‌توانند هم‌زمان پیش بروند. انتشار DeepInfer نمونه‌ای برای دقیق‌ترکردن همین پیشنهاد است: بخشی از ابزارهای مسیر دوم ممکن است بیرون از مجموعه ما ساخته و عمومی شوند؛ مسئولیت ما شناخت، ارزیابی و تشخیص حدود استفاده از آن‌هاست.
این انتشار به معنی پایان وابستگی نرم‌افزاری نیست. کد در دسترس، هنوز باید به نرم‌افزار قابل اجرا، سپس به خدمت پایدار و در نهایت به گزینه‌ای اقتصادی و قابل نگهداری تبدیل شود. اما فاصله‌ای که باید طی کنیم نیز ثابت نمی‌ماند؛ با انتشار ابزار و تجربه، ممکن است بخشی از آن کوتاه‌تر شود.
برای حفظ امکان انتخاب، لازم نیست سازنده تمام اجزای مسیر دوم باشیم؛ باید توان تشخیص، آزمودن و بهره‌برداری از آن را بسازیم.