اگر امروز برای اجرای عاملهای هوش مصنوعی هزینه میپردازید، احتمالاً بخش بزرگی از صورتحساب شما صرف دادههایی میشود که مدل هرگز از آنها استفاده نمیکند. یک باگ ساده در یک مخزن کوچک npm، وقتی با عامل Locally Uncensored نسخه ۲.۶.۶ اجرا میشود، ۴۰٪ ارزانتر از opencode تمام میشود. یک بنچمارک با استفاده از مدل deepseek-ai/DeepSeek-V3.2 نشان داد که اگرچه هر دو عامل با موفقیت تسک را حل کردند، اما هزینه مالی آنها بر اساس نحوه مدیریت حلقههای داخلیشان، تفاوت فاحشی داشت.
بسیاری از توسعهدهندگان به اشتباه تصور میکنند عامل «باهوشتر» ارزانتر است چون گامهای کمتری برای حل یک مسئله برمیدارد. اما این آزمایش ثابت میکند که حجم توکنها — و نه تعداد گامها — محرک اصلی صورتحساب API است. در دنیای واقعی، شما برای هر بایتی که به مدل ارسال میشود پول میپردازید، از جمله دستورالعملهای پنهانی که مدل در عمل هرگز از آنها استفاده نمیکند. این بهینهسازی در سطح توکن، در راستای روند کلی کاهش شدید هزینههای توسعه از طریق مدلهای وزنباز است که دسترسی به مدلهای قدرتمند را ارزانتر کرده است.
جزئیات آزمایش
برای اینکه مقایسه هزینه معتبر باشد، پژوهشگران تمام متغیرهایی که باعث تغییر قیمت میشوند را تثبیت کردند. تسک مورد نظر، رفع یک تست شکستخورده در یک مخزن کوچک npm بود که از سه فایل تشکیل شده بود. هدف دقیقاً یک باگ تکخطی در فایل add.js بود که در ابتدای کار باعث قرمز شدن تستها میشد. موفقیت در این آزمایش به طور سختگیرانه تعریف شده بود: تست npm test باید پاس میشد، دقیقاً یک کامیت با پیام مورد نیاز ثبت میشد، تنها فایل add.js تغییر میکرد و در نهایت درخت کاری (working tree) باید کاملاً پاک و بدون تغییرات اضافی میبود.
تنظیمات فنی به شرح زیر بود:
- پرامپت: در تمام اجراها از نظر بایتی کاملاً یکسان بود (sha256 29cec6c3...cf62687).
- مدل و نقطه اتصال: هر دو عامل از یک API سازگار با OpenAI برای مدل deepseek-ai/DeepSeek-V3.2 استفاده کردند.
- قیمتگذاری: از یک حساب کاربری واحد، یک سطح دسترسی (tier) یکسان و نرخ توکن برابر استفاده شد.
- روش شمارش: یک پروکسی شبکه (wire proxy) در مقابل API قرار داده شد تا اعتبارها را دقیقاً قبل و بعد از هر اجرا بخواند.
- نسخههای نرمافزاری: opencode نسخه ۱.۱۸.۲۱ (که از طریق دستور
opencode run --autoاجرا شد) و Locally Uncensored نسخههای ۲.۶.۵ و ۲.۶.۶.
کالبدشکافی هزینهها
بر اساس مستندات این گزارش، نتایج بسیار صریح بود. هر چهار اجرای آزمایشی از سد موفقیت عبور کردند، به این معنی که هزینه تنها متغیری بود که تغییر میکرد:
- opencode بهطور میانگین ۲,۱۵۷ اعتبار در سه اجرای موفق مصرف کرد. در اجرای اول ۱,۶۷۹ اعتبار (۸ درخواست و ۹۸,۷۸۹ توکن ورودی)، در اجرای دوم ۲,۴۳۳ اعتبار (۱۱ درخواست و ۱۴۶,۰۵۸ توکن ورودی) و در اجرای سوم ۲,۳۵۸ اعتبار (۱۱ درخواست و ۱۴۶,۳۸۷ توکن ورودی) هزینه شد.
- Locally Uncensored 2.6.6 همان تسک مشابه را با ۱,۲۹۸ اعتبار، با استفاده از ۱۶ درخواست و ۷۴,۶۲۹ توکن ورودی به پایان رساند.
- حتی بهینهترین اجرای opencode (با ۱,۶۷۹ اعتبار) همچنان ۲۹٪ گرانتر از عامل LU 2.6.6 بود.
پارادوکس کارایی
نکته عجیب اینجاست که opencode از نظر منطقی «کارآمدتر» بود. این عامل تنها به ۸ تا ۱۱ درخواست برای اتمام کار نیاز داشت، در حالی که عامل Locally Uncensored به ۱۶ درخواست نیاز داشت. اگر بنچمارک بر اساس تعداد گامها امتیازدهی میشد، opencode برنده میشد. اما با وجود تعداد نوبتهای بیشتر، عامل LU در هر نوبت توکنهای بسیار کمتری مصرف کرد.
چرا صورتحسابها متفاوت است؟
دو مکانیزم فنی خاص این شکاف قیمتی را ایجاد کرده است. نرخ پرداخت یکسان بود — نرخ اعتبار به ازای هر توکن ورودی در تمام اجراها در محدوده چند درصد تفاوت بود (۰.۰۱۷۳۹ برای LU در مقابل ۰.۰۱۶۱۱ تا ۰.۰۱۷۰۰ برای opencode). بنابراین تفاوت کاملاً مربوط به حجم توکنهاست.
اولین مورد، «بلاک ثابت» (Fixed Block) است. هر درخواست شامل یک کاتالوگ از ابزارهاست. opencode کاتالوگی با حجم ۲۱,۱۸۸ بایت ارسال میکند، در حالی که Locally Uncensored از یک نسخه سبکتر با حجم ۷,۷۰۳ بایت استفاده میکند. این یعنی تقریباً سه برابر سربار ثابت. شما برای این بلاک در هر بار فراخوانی در حلقه پرداخت میکنید، چه مدل واقعاً از آن ابزارها استفاده کند و چه نکند.
دومین مورد، «زوال زمینه» (Context Decay) است. هرچه یک عامل بیشتر کار میکند، متن تاریخچه گفتگو رشد میکند. خروجیهای قدیمی ابزارها که ۱۰ گام پیش دیگر اهمیتی نداشتند، همچنان با طول کامل ارسال میشوند مگر اینکه سیستمی برای هرس کردن (trimming) فعال باشد. این تورم، در ترکیب با بلاک ثابت، باعث شد هر درخواست opencode از ۱۲,۰۰۰ توکن ورودی عبور کند (میانگین ۱۲,۳۴۹ تا ۱۳,۳۰۸)، در حالی که عامل LU درخواستهای خود را در محدوده ۴,۶۶۴ توکن نگه داشت.
جهش در بهینهسازی داخلی
این محک همچنین پیشرفت خیرهکننده در بهینهسازیهای داخلی را نشان میدهد. نسخه قبلی یعنی Locally Uncensored 2.6.5، گرانترین عامل در کل تست بود و برای همان تسک ۴,۳۹۵ اعتبار (۳۰ درخواست و ۲۵۷,۲۷۰ توکن ورودی) مصرف کرد.
بین نسخههای ۲.۶.۵ و ۲.۶.۶، توسعهدهندگان روی اندازه بلاک ثابت و هرس کردن تاریخچه تمرکز کردند. در مجموعهای از اجراهای ابزار-محور، این تغییرات مصرف اعتبار را ۷۸.۶٪ کاهش داد و در طولانیترین اجرای این مجموعه، میزان کاهش به ۸۰.۴٪ رسید.
محدودیتهای بنچمارک
نویسندگان پذیرفتهاند که این یک تست محدود است. این آزمایش روی یک مخزن بسیار کوچک با یک باگ تکخطی تمرکز داشت و تغییرات در مقیاس بزرگ (Refactor)، تغییرات در چندین فایل یا جلسات طولانیمدت که ممکن است رتبهبندی را تغییر دهد، را در نظر نمیگیرد.
سایر محدودیتها عبارتند از:
- نمونهبرداری نامتوازن: opencode سه بار اجرا شد اما LU 2.6.6 تنها یک بار. پراکندگی هزینه در خودِ opencode حدود ۴۵٪ بود (۱,۶۷۹ تا ۲,۴۳۳)، به این معنی که یک اجرا تنها یک نقطه داده است، نه یک توزیع آماری.
- تنظیمات پیشفرض: opencode با همان حالتی که عرضه شده اجرا شد. این ابزار قابل پیکربندی است و یک تنظیم بهینه با مجموعه ابزارهای هرس شده احتمالاً نتایج متفاوتی میداد.
- هزینه در برابر کیفیت: هر اجرا خروجی صحیحی تولید کرد. در مسائل سختتر، ارزانترین عامل لزوماً بهترین نیست.
جمعبندی نهایی
برای توسعهدهندگانی که حلقههای عامل (Agent Loops) خود را میسازند، درس این آزمایش روشن است: وسواس روی تعداد گامها را کنار بگذارید. دو معیاری که واقعاً صورتحساب شما را پیشبینی میکنند، اندازه بایتی کاتالوگ ابزارها و میانگین توکنهای ورودی در هر درخواست است.
این تغییر در تمرکز نشان میدهد که مرز بعدی توسعه عاملها، تنها استدلال بهتر نیست، بلکه «بهداشت توکنی» (Token Hygiene) بهتر است. کاهش سربار ثابت یک درخواست، کف هزینهها را پایین میآورد. حتی بهترین اجرای opencode با تنها ۸ درخواست، به دلیل همین کف هزینه، به ۹۸,۷۸۹ توکن نیاز داشت.
در نهایت، opencode همچنان یک عامل متنباز واقعاً خوب است که هر بار یک diff تمیز و پیام کامیت صحیح تولید کرد. هدف از این اندازهگیری، دلسرد کردن از استفاده از آن نیست، بلکه تشویق توسعهدهندگان به اندازهگیری حلقههای خود است. صورتحسابهای عاملها از توکنهایی ساخته شدهاند که شما هرگز نمیبینید، و دو ابزاری که هر دو سریع به نظر میرسند، میتوانند در فاکتور نهایی ۱.۶۶ برابر با هم تفاوت داشته باشند.
گام بعدی شما
- اگر عاملهای شخصی میسازید، به جای تمرکز بر کاهش تعداد گامها، حجم کاتالوگ ابزارهای ارسالی را کاهش دهید.
- سیستمی برای «هرس کردن» تاریخچه گفتگو (Transcript Trimming) پیادهسازی کنید تا توکنهای تکراری در هر درخواست ارسال نشوند.
- هزینههای استنتاج خود را بر اساس حجم توکنهای ورودی در هر درخواست اندازه بگیرید، نه فقط تعداد فراخوانی API.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو