جیپییوی بیکار، هواپیمای زمینگیر
هوش مصنوعیخلاصهٔ کاملتر
نویسندههای این مقاله از تیم Dharma AI با یه قیاس شروع میکنن: تو صنعت هوانوردی، عددی که بهتر از هر چیزی بقای یه ایرلاین رو پیشبینی میکرد این بود که هر هواپیما چقدر از روز رو روی زمین میمونه. هزینهٔ هواپیما ساعتبهساعتِ تقویم بالا میره — تأمین مالی، استهلاک، بیمه، تعمیرات، قرارداد خدمه — ولی درآمدش فقط با ساعت پرواز میاد. به گفتهٔ نویسندهها، جیپییو دقیقاً همین ساختار رو داره: هزینهش با تقویم میره بالا، خروجیش فقط با ساعت پردازش.
تو مقاله اومده که کمیابی با بزرگتر شدن هوش مصنوعی از بین نرفته، فقط جاش عوض شده و از مدل رفته روی محاسبات. سال ۲۰۲۰ مایکروسافت برای OpenAI یه ابرکامپیوتر با بیش از ۱۰ هزار جیپییو و ۲۸۵ هزار هستهٔ CPU ساخت که اون موقع جزو پنج سیستم بزرگ دنیا بود؛ شش سال بعد همون عدد بیشتر شبیه نقطهٔ شروعه تا سقف. تا ۲۰۲۶ حتی آزمایشگاههای پرسرمایه هم دسترسی به توان پردازش رو یه محدودیت زندهٔ استراتژیک میدونن — نویسنده مثال میزنه که Anthropic همزمان روی چهار پلتفرم سختافزاری تعهد چندگیگاواتی گرفته.
پاییندستِ آزمایشگاهها، شرکتها با شکل دیگهای از همین مسئله روبهرو میشن: هزینهٔ API خطی با مصرف توکن بالا میره، برای همین چیزی که تو نمونهٔ اولیه ارزون به نظر میرسه، تو حجم واقعیِ تولید میتونه هیچوقت بهصرفه نشه. جایگزینی که داره جا باز میکنه اینه که سازمانها خودشون جیپییو بخرن و مدل رو محلی اجرا کنن، یعنی هزینهٔ متغیر رو با هزینهٔ سرمایهایِ ثابت عوض کنن. اما همونجا مسئلهٔ تازهای باز میشه: سؤال دیگه این نیست که «شتابدهنده گیرمون میاد؟»، اینه که «میتونیم مشغول نگهش داریم؟»
نویسندهها میگن یه کلاستر پرمشغله هم میتونه بیشتر ظرفیتشو هدر بده. زیرساخت باید به اندازهٔ اوج مصرف چیده بشه، پس بیرون از اوج بخشی از ظرفیت بیکار میمونه. مهمتر از اون، امروز همون سختافزار باید آموزش، فاینتیونینگ، کوانتیزیشن، استنتاج بلادرنگ، استنتاج دستهای، تولید embedding و ارزیابی مدل رو ببره جلو و هر کدوم چیز متفاوتی از سختافزار میخوان. زمانبندی که برای یکی تنظیم شده، سهتای دیگه رو بد تخصیص میده — و داشبورد ممکنه همچنان اشغال بالا نشون بده در حالی که کارها تو صف منتظرن.
اینجا قیاس هواپیما به مرزش میرسه و همین نکتهش آموزندهست: یه هواپیمای بیکار رو میشه تقریباً به هر مسیری فرستاد، ولی یه جیپییوی بیکار فقط باری رو قبول میکنه که با حافظه، تأخیر و مدتزمانش جور دربیاد. برای همین به گفتهٔ نویسندهها یه رشتهٔ جدید داره شکل میگیره به اسم GPU Management: یه لایهٔ ارکستراسیون بین بار کاری، مدل و سختافزار که مدام تصمیم میگیره چه کاری، کِی، چطور و روی کدوم جیپییو اجرا بشه. تصمیم تأمین یه بار گرفته میشه، تصمیم تخصیص هر لحظه.
بخش آخر مقاله دو اهرم رو کنار هم میذاره. مدلهای تخصصیِ کوچیکتر میتونن یه کار مشخص رو با کسری از منابع مدل عمومی انجام بدن و ظرفیت آزاد کنن؛ ولی به گفتهٔ نویسندهها اون ظرفیت آزادشده اگه چیزی فعالانه بازتخصیصش نکنه، فقط یه جور بیکاریِ نامرئیتره. تخصصیسازی بدون ارکستراسیون ظرفیتی آزاد میکنه که کسی برنمیداره، و ارکستراسیون بدون تخصصیسازی ظرفیت کمتری برای برداشتن داره. نتیجهگیری مقاله اینه که شرکتهایی که هر دو رو با هم داشته باشن، سرعت رقابت دههٔ بعد رو تعیین میکنن.
نکات کلیدی:
- هزینهٔ جیپییو با ساعت تقویم بالا میره، درآمدش فقط با ساعت پردازش — درست مثل هواپیما
- گلوگاه از کیفیت مدل رفته روی دسترسی و بهرهوری توان پردازش
- هزینهٔ API خطی با توکن بالا میره؛ بعد از نقطهٔ سربهسر، سختافزار خودی بهصرفهتر میشه
- اشغال بالا لزوماً یعنی بهرهوری بالا نیست؛ ناهمگونی بارهای کاری ظرفیت رو هدر میده
- GPU Management یه لایهٔ ارکستراسیون همیشهفعاله، نه یه تصمیم یکبارهٔ خرید
- تخصصیسازی ظرفیت آزاد میکنه، ارکستراسیون خرجش میکنه؛ هیچکدوم بهتنهایی کافی نیست
