گیت‌هاب: هزینه‌های برخی توسعه‌دهندگان به دلیل مدل مصرفی به ۷۵۰ دلار رسید

۷۵۰ دلار در ماه؛ این واقعیت جدیدی است که برخی کاربران حرفه‌ای پس از تغییر سیاست‌های مالی گیت‌هاب با آن رو‌به‌رو شده‌اند. در ۱ ژوئن ۲۰۲۶، این شرکت مدل پرداخت ثابت برای درخواست‌های ویژه در GitHub Copilot را به‌طور کامل حذف و آن را با اعتبارهای مصرفی جایگزین کرد. وقتی اولین صورت‌حساب‌های مدل جدید یک ماه بعد رسید، شوک مالی برای بسیاری از توسعه‌دهندگان آغاز شد. کسانی که از گردش‌کارهای عامل‌محور (Agentic) سنگین استفاده می‌کردند، دیدند هزینه ماهانه‌شان تقریباً یک‌شبه از ۲۹ دلار به ارقامی نجومی جهش کرده است.

این گذار، یک مشکل سیستمی در نحوه محاسبه بازگشت سرمایه (ROI) در سازمان‌ها را آشکار می‌کند. اکثر شرکت‌ها فقط ساعت‌های ذخیره‌شده را می‌شمارند، اما هزینه‌های نامرئی مصرف پنجرهٔ زمینه (Context Window) و تلاش‌های مجدد برای رفع خطا را نادیده می‌گیرند. هزینه‌های دیگری نیز وجود دارند که هرگز در فاکتور فروشنده ظاهر نمی‌شوند؛ از جمله زمانی که صرف بازبینی خروجی‌ها و نگهداری پرامپت‌ها می‌شود. همان‌طور که بازار به سمت مدل‌های مبتنی بر مصرف حرکت می‌کند، فقدان انضباط در مدیریت هزینه‌ها برای سازمان‌هایی که امروز هنوز از نرخ‌های ثابت پرداخت می‌کنند، به یک نقطه ضعف تبدیل خواهد شد.

مالیات زمینه

عامل‌ها (Agents) برای عملکرد درست به زمینه نیاز دارند، اما روش ارسال این داده‌ها اغلب ناکارآمد است. ارسال یک سند کامل سریع‌ترین راه برای ارائه اطلاعات است، اما به‌ندرت ارزان‌ترین یا بهترین روش است. مسئله اصلی این است که آیا زمینه‌ای که ارسال می‌شود واقعاً مرتبط است یا صرفاً چون به‌راحتی در دسترس بوده، ارسال شده است؟

به نقل از آزمایشگاه اقتصاد دیجیتال استنفورد (Stanford’s Digital Economy Lab)، تحلیلی در مه ۲۰۲۶ روی هشت مدل پیشرو نشان داد که وظایف کدنویسی عامل‌محور تا ۱۰۰۰ برابر بیشتر از یک چت ساده، توکن (Token) مصرف می‌کنند. دلیل اصلی این موضوع خروجی مدل نیست، بلکه زمینه ورودی است که عامل در هر مرحله از فرآیند، دوباره ارسال می‌کند. در واقع، عامل هر بار که یک قدم به جلو می‌رود، تمام تاریخچه را از اول می‌خواند.

این «کوری توکنی» به این معناست که دقت مدل با افزایش حجم داده‌ها به‌صورت خطی رشد نمی‌کند. عملکرد مدل‌ها معمولاً در حجم متوسطی از داده به اوج می‌رسد و هر داده اضافی، بدون افزودن ارزش، فقط هزینه را بالا می‌برد. همچنین تحلیل استنفورد نشان داد که یک وظیفه مشابه، در اجراهای مختلف، تا ۳۰ برابر تفاوت در مصرف توکن دارد.

هزینه شکست

گردش‌کارهای عامل‌محور هزینه‌ای تصاعدی برای عدم اطمینان دارند. در یک زنجیره ساده ۱۰ مرحله‌ای که هر مرحله ۹۵٪ احتمال موفقیت دارد، احتمال موفقیت کل فرآیند تنها حدود ۶۰٪ است.

وقتی در چنین گردش‌کاری که تمام زمینه‌های انباشته را در هر فراخوانی ارسال می‌کند خطایی رخ می‌دهد، تلاش مجدد رایگان نیست. کاربر باید هزینه تمام توکن‌های ارسال شده در تمام مراحل موفق قبلی را دوباره پرداخت کند. این یک نقطه درد رایج هنگام ساخت اولین خط لوله عامل‌محور است؛ هرچه خط لوله رشد می‌کند، هر اجرای شکست‌خورده به‌طور نمایی گران‌تر می‌شود.

طبق گزارش استنفورد، یک عامل ۱۰ مرحله‌ای با قابلیت اطمینان ۹۵٪ در هر مرحله، حدود ۴۰٪ توکن بیشتر نسبت به یک سیستم کاملاً بی‌نقص مصرف می‌کند. این «مالیات شکست» به‌ندرت در جداول ROI ثبت می‌شود اما در فاکتور نهایی حاکم است.

شکاف نگهداری

فراتر از هزینه توکن‌ها، هزینه انسانی قابل‌توجهی برای نظارت بر هوش مصنوعی وجود دارد. بازبینی خروجی‌های هوش مصنوعی یک نقص سیستمی نیست؛ بلکه بخشی مشروع و مورد انتظار از کار با AI است، درست همان‌طور که بازبینی کد (Code Review) بخشی مشروع از کار با توسعه‌دهندگان است. مشکل اینجاست که این کار تقریباً هرگز در محاسبات مربوط به میزان صرفه‌جویی واقعی هوش مصنوعی لحاظ نمی‌شود.

مؤسسه Work AI متعلق به Glean با بررسی ۶۰۰۰ کارکن، دریافت که اگرچه اتوماسیون حدود ۱۱ ساعت در هفته صرفه‌جویی می‌کند، اما ۶.۵ ساعت از آن زمان صرف نگهداری می‌شود. این موارد شامل موارد زیر است:

• ارائه زمینه‌های لازم به سیستم‌های هوش مصنوعی
• بررسی صحت و دقت کار
• پاک‌سازی و اصلاح اشتباهات

در نتیجه، صرفه‌جویی خالص تنها ۴.۵ ساعت است؛ یعنی کمتر از نصف عددی که در گزارش‌های تبلیغاتی دیده می‌شود. هوش مصنوعی همچنان زمان می‌بخشد، اما نه به اندازه آنچه اعداد اولیه نشان می‌دهند.

مهندسی پرامپت به مثابه بدهی فنی

امروزه مهندسی پرامپت (Prompt Engineering) مانند کدهای عملیاتی در محیط تولید رفتار می‌کند. یک به‌روزرسانی مدل، تغییری در زمینه یا حتی یک ویرایش به‌ظاهر جزئی در یک جمله می‌تواند به‌طور خاموش نحوه عملکرد پرامپت را تغییر داده و دقت را کاهش دهد، بدون اینکه کسی متوجه شود تا زمانی که مشکل انباشته شود.

با این حال، بسیاری از سازمان‌ها تست‌های رگرسیون (Regression Tests) را که در توسعه نرم‌افزار استاندارد است، نادیده می‌گیرند. ایجاد یک چارچوب ارزیابی مناسب — شامل یک مجموعه داده آزمونی و تست‌های رگرسیون خودکار برای هر تغییر — ضروری است، اما این تلاش مهندسی به‌ندرت در معادله «زمان ذخیره‌شده» گنجانده می‌شود.

پارادوکس توکن

مورد GitHub Copilot یک اتفاق تک‌گیر نیست. گزارشی که CFO Dive به آن استناد کرده، نشان می‌دهد نزدیک به ۷۰٪ شرکت‌های آمریکایی در سال گذشته با افزایش پیش‌بینی‌نشده بودجه هوش مصنوعی مواجه شده‌اند که بیشتر آن‌ها پیش از انتقال کامل به سیستم پرداخت مبتنی بر مصرف رخ داده است. این روند با تحلیل‌های پیشین ما درباره ناپایداری مدل‌های رایگان API همسو است که نشان می‌داد مدل‌های رایگان تنها پلی برای انتقال کاربران به سیستم‌های پرداخت مصرفی هستند.

شرکت بین (Bain & Company) در تحلیل ژوئن ۲۰۲۶ خود پارادوکسی را در اقتصاد توکن‌ها شناسایی کرد: در حالی که قیمت هر توکن در طول سال نصف شد، مصرف کل ۴.۵ برابر رشد کرد. توکن‌های ارزان‌تر منجر به فاکتورهای کمتر نشدند؛ بلکه شرکت‌ها را تشویق کردند تا از مدل‌های جدیدتر استفاده کنند، وظایف پیچیده‌تری به عامل‌ها بسپارند و گردش‌کارهای بیشتری برای آن‌ها پیدا کنند. مدل ارزان شد، اما فاکتورها به‌طور سرسختانه‌ای بالا ماندند.

استراتژی‌های انضباط هزینه

برای جلوگیری از شوک‌های مالی، سازمان‌ها باید دیداری دقیق و سخت‌گیری مهندسی را اجرا کنند. هدف، استفاده کمتر از هوش مصنوعی نیست، بلکه دانستن هزینه پیش از مقیاس‌پذیری است.

• ردیابی جزئی: تفکیک مصرف بر اساس تیم، گردش‌کار، اپلیکیشن و وظیفه تکمیل‌شده. ردیابی مراحل عامل‌محور، ثبت نتایج و نظارت بر حلقه‌های تکراری (Runaway Loops) نیازمند ابزار و زمان مهندسی اختصاصی است. این مورد باید به عنوان یک هزینه اصلی در بودجه اجرای هوش مصنوعی لحاظ شود.
• محاسبه ROI خالص: کسر زمان صرف‌شده برای بازبینی، اصلاحات و نگهداری پرامپت از ساعت‌های ذخیره‌شده گزارش‌شده. اگر نتیجه خالص منفی یا غیرقابل تایید باشد، آن مورد استفاده (Use Case) آماده مقیاس‌پذیری نیست. برای اهدافی مانند کیفیت یا کاهش ریسک، نتایج را به‌طور مستقیم اندازه‌گیری کنید.
• حفاظ‌های لایه‌ای: اعمال انضباط هزینه به‌صورت غیریکسان. از سقف‌های هزینه سخت (Hard Caps) برای ابزارهای داخلی، عامل‌های آزمایشی و محیط‌های توسعه استفاده کنید، جایی که هزینه شکست پایین است. برای قابلیت‌های حساس مشتری‌محور (مانند دستیار خدمات مشتری)، از جایگزین‌های لایه‌ای (Tiered Fallbacks) به مدل‌های ارزان‌تر و هشدارهای زودهنگام برای جلوگیری از ریسک قطع سرویس استفاده کنید.
• نسخه‌بندی پرامپت: برخورد با پرامپت‌ها و ارزیابی‌ها به عنوان دارایی‌های مهندسی؛ نسخه‌بندی، تست و بازبینی تغییرات پیش از استقرار، دقیقاً همان‌طور که کدهای عملیاتی را مدیریت می‌کنید.

شرکت‌ها باید پیش از تمدید قراردادها با فروشندگان یا تغییر مدل‌ها، هزینه گردش‌کارهای فعلی را تحت شرایط پیشنهادی و با استفاده از داده‌های مصرف واقعی خود محاسبه کنند. هدف این است که بفهمند قیمت در سطح مصرف واقعی چگونه رفتار می‌کند، نه اینکه این موضوع را از روی فاکتور کشف کنند.

گام بعدی شما

سه اقدام فوری برای این هفته:

• بررسی کنید آیا امکان تفکیک مصرف هوش مصنوعی بر اساس تیم و گردش‌کار در سازمانتان وجود دارد یا خیر.
• یک مورد استفاده (Use Case) را انتخاب کنید و زمان واقعی بازبینی خروجی را با صرفه‌جویی گزارش‌شده مقایسه کنید.
• نقاطی را شناسایی کنید که اعمال سقف هزینه سخت، به‌جای کنترل هزینه، منجر به قطع سرویس (Outage) شود.

اما داستان سخت‌افزاری این تحول و فشار بر مراکز داده حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.