گزارشی در MIT Technology Review استدلال می‌کند که معیارهای رایج هزینه‌ی کدنویسی هوش مصنوعی — شمارش توکن و سقف مصرف — نشانه‌ی درستی از ارزش تولیدشده نیستند و شرکت‌ها باید به «هزینه به‌ازای هر پراگم ادغام‌شده» (cost per merged pull request) روی بیاورند.
مقاله با این واقعیت شروع می‌کند که یک تسک کدنویسی ایجنتی می‌تواند ۱۰ تا ۵۰ برابر بیشتر از یک پرامپت چت ساده توکن مصرف کند؛ چون ایجنت برنامه‌ریزی می‌کند، کد تولید می‌کند، تست اجرا می‌کند و برای رفع خطا تکرار می‌کند. هرچه ایجنت مفیدتر باشد، فراخوانی‌های بیشتری انجام می‌دهد و با مدل قیمت‌گذاری به‌ازای توکن، پرهزینه‌ترین کارها همان‌هایی هستند که بیشترین ارزش را می‌سازند.
فشار مالی این مسئله از قبل قابل مشاهده است. طبق گزارش، Uber پس از گسترش استفاده از Claude Code تا ماه آوریل کل بودجه‌ی هوش مصنوعی ۲۰۲۶ خود را مصرف کرده بود. GitHub Copilot نیز از قیمت‌گذاری ثابت به اعتبارهای مصرفی (metered credits) تغییر کرده است. Gartner پیش‌بینی می‌کند هزینه‌ی توکن‌های کدنویسی هوش مصنوعی تا ۲۰۲۸ از میانگین حقوق توسعه‌دهندگان فراتر خواهد رفت.
دو تغییر ساختاری: تقسیم کار بین مدل‌ها و مالکیت زیرساخت#
مقاله دو راهکار اصلی پیشنهاد می‌کند:
- تطبیق مدل با تسک: از مدل frontier فقط برای برنامه‌ریزی دشوار و استدلال نوآورانه استفاده شود و کارهای تکراری مثل تولید کد، نوشتن تست و ریفکتورینگ به مدل‌های open-weight منتقل شوند. یک gateway بر اساس پیچیدگی، حساسیت داده، هزینه و تأخیر مسیر را تعیین می‌کند.
- مالکیت ظرفیت: با استنتاج اجاره‌ای، هر فراخوانی به فاکتور اضافه می‌کند؛ با ظرفیت مالکیتی، بیشتر هزینه از پیش پرداخت‌شده است و هر فراخوانی اضافی ارزان‌تر می‌شود.
داده‌های HPE#
در HPE یک پلتفرم هیبریدی، بارهای کاری روتین از بیش از ۱۵۰ اپلیکیشن داخلی را به مدل‌های open-weight روی زیرساخت داخلی هدایت می‌کند. نتیجه: کاهش ۳۰ تا ۵۰ درصدی هزینه‌ی توکن.
داده‌های مصرفی HPE نشان می‌دهد ۵ درصد برتر کاربران بیشترین مصرف را تولید کرده‌اند و سنگین‌ترین‌ها حدود ۴۵۰ برابر بیشتر از سبک‌ترین‌ها روی همان لایسنس استفاده کرده‌اند. اگر کاربران پرمصرف از اقلیت کوچک به نیمی از نیروی کار تبدیل شوند، هزینه‌ی ماهانه با تعداد ثابت لایسنس حدود ۴.۴ برابر افزایش می‌یابد.
HPE دو شاخص را ردیابی می‌کند: هزینه به‌ازای هر توسعه‌دهنده‌ی فعال (چون میانگین‌گیری روی همه‌ی لایسنس‌ها کاربران پرمصرف را پنهان می‌کند) و هزینه به‌ازای هر پراگم ادغام‌شده. توصیه‌ی مقاله این است که قبل از تغییر زیرساخت، هر دو شاخص را baseline کنید و یک چرخه‌ی کامل توسعه را روی ظرفیت مالکیتی اجرا کنید؛ اگر هر دو شاخص بهبود نیافتند، مدل فعلی همچنان بهینه‌تر است.
این خبر برای کسی که همین حالا ایجنت می‌سازد یعنی چه#
نکته‌ی محوری این گزارش، تغییر واحد اندازه‌گیری است. اگر امروز روی pricing به‌ازای توکن یا سقف مصرف کار می‌کنید، این گزارش می‌گوید آن عدد نشانه‌ی درست نیست — چون مصرف و زباله را از هم تشخیص نمی‌دهد. اما معیار پیشنهادی (هزینه به‌ازای پراگم ادغام‌شده) هم بی‌نقص نیست: مستلزم این است که کیفیت و باگ را هم‌زمان ردیابی کنید، وگرنه تغییرات ارزان‌تر ممکن است فقط تغییرات بی‌کیفیت‌تر باشند.
برای اکثر تیم‌های کوچک و متوسط، بخش «مالکیت ظرفیت» عملاً قابل‌اجرا نیست. توصیه‌ی عملی‌ترِ مقاله برای این تیم‌ها همان gateway و تقسیم کار بین مدل‌هاست: frontier را فقط برای جاهایی که واقعاً لازم است نگه دارید. عدد ۳۰ تا ۵۰ درصد کاهش هزینه‌ی HPE مشروط به حجم بالای مصرف داخلی است؛ اگر مصرف‌تان پایین یا غیرقابل‌پیش‌بینی است، همان API اجاره‌ای منطقی‌تر است.
آنچه این خبر تغییر نمی‌دهد: هیچ‌کدام از این اعداد (۴۵۰ برابر، ۴.۴ برابر، ۳۰ تا ۵۰ درصد) تعمیم‌پذیر نیستند. مقاله‌ی خود HPE را می‌گوید «mix شما متفاوت خواهد بود». قبل از هر تصمیمی، داده‌ی خودتان را اندازه بگیرید.
منبع: MIT Technology Review
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته میشوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.