سه بنچمارک مستقل نشان دادند همان مدل پایه وقتی تحت هارنسهای مختلف اجرا شود، مصرف توکن برای حل یک وظیفه میتواند از حدود 3,500 تا 292,000 توکن نوسان کند — معادل افزایش حدود 70 تا 80 برابر در عمل. این تفاوت عمدتاً به رفتار لایهٔ هارنس برمیگردد، نه تغییر در خودِ مدل.
نتایج بنچمارکها دربارهٔ مصرف توکن هارنس
سه مجموعهسنجی مستقل به یک سؤال مشابه پرداختند: آیا تفاوت در نرمافزار هارنس — لایهای که مدل را به ابزارها و گردش کار متصل میکند — میتواند مصرف توکن و هزینهٔ عاملها را تغییر دهد؟ خلاصهٔ نتایج:
- یک بنچمارک مستقل در ژوئن، 12 پیکربندی مختلف را روی همان 12 وظیفهٔ پایتون اجرا و مصرف توکن را ثبت کرد.
- Composio در اوت، هشت هارنس را با استفاده از DeepSeek V4 Flash روی 30 جریان کاری سازمانی شامل ابزارهایی مثل Airtable، Gmail، Google Calendar، Google Sheets، GitHub و Slack اجرا کرد و نتایج را با یک ارزیاب برنامهای سنجید.
- Artificial Analysis مجموعهٔ بزرگتری از صدها وظیفه منتشر کرد و جفتهای هارنس-مدل را پیوسته رصد میکند.
چرا هارنس مصرف توکن را تغییر میدهد؟
عامل اصلی اختلاف را میتوان در «مالیات استارتاپی» هارنس خلاصه کرد: هارنس پیش از هر نوبتِ کار واقعی، یک بارِ ثابت از دادهها را ارسال میکند — شامل پرومپت سیستمی، شرح ابزارها و پیکربندی محیط. بنچمارک ژوئن نشان داد کفِ پرومپت بین ~700 توکن (برای حالت architect در Aider) تا ~26,000 توکن (برای OpenClaw) تفاوت دارد.
وقتی آن کفِ ثابت در هر نوبت تکرار شود، هزینهٔ تجمعی سریع بالا میرود. مثلاً هارنس با کف 26,000 توکنی در 15 نوبت حدود 390,000 توکن صرف ارسال داربست زمینه میکند — بدون احتساب محتوای جدید هر نوبت. نویسندهٔ بنچمارک ژوئن گزارش کرد که حاصلضربِ کف پرومپت در تعداد نوبتها تقریباً مصرف توکن به ازای هر وظیفه را با R² = 0.99 پیشبینی میکند؛ یعنی هارنس، نه مدل، عامل اصلی اختلاف است.
ابعاد عددی و هزینهها
Composio گزارش کرد از 240 اجرا، 129 اجرا موفق بودند و هزینهٔ هر وظیفهٔ موفق بین $0.028 برای Pi Agent تا $0.195 برای Claude Code متغیر بود؛ در یک مورد DeepAgents همان نرخ موفقیت Claude Code را با حدود یکچهارم هزینه ارائه کرد. بنچمارک توکنی ژوئن دامنهٔ وسیعتری نشان داد: حدود 3,500 توکن برای Aider (architect) تا 292,000 توکن برای OpenClaw.
چه چیزی تفاوت را توجیه نمیکند
تحلیلها نشان میدهد رشد زمینه (افزودن متن در هر نوبت) بین هارنسها مشابه است؛ بنابراین رشد زمینه عامل اصلی نیست. هارنسهای پرهزینه نه تنها متن بیشتری در هر نوبت ارسال نمیکنند، بلکه تفاوت عمده در وجود یک کف ثابت بزرگ و تکرارشونده است.
نقش کش و توکنهای کششده در مصرف توکن هارنس
دو آزمایش به اثر کش اشاره کردند: هارنسهایی که محتوای ثابت را محلی یا در سطح سرویس کش میکنند یا آن را خلاصه میسازند، مصرف ورودی را کاهش میدهند. این مکانیسم میتواند رتبهبندی هارنسها را تغییر دهد و مقایسهٔ مستقیم را دچار اعوجاج کند. Artificial Analysis با مجموعهٔ بزرگ دادهها این اثر را نیز ثبت کرده است.
راهکارهای عملی برای کاهش مصرف توکن هارنس
- کاهش کف پرومپت: شرح ابزارها و تنظیمات سیستمی را فشرده و فقط بخشهای ضروری را نگه دارید.
- کاهش تعداد نوبتها: گفتگوها و تعاملها را هدفمند و مختصر طراحی کنید تا بار تکراری زمینه کمتر شود.
- خلاصهسازی و کش محتوای ثابت: توصیف ابزارها یا اطلاعات ثابت را محلی کش یا خلاصه کنید تا ارسالِ کاملِ آنها در هر نوبت لازم نباشد.
- ارسال تفکیکی مستندات: مستندات و دادههای حجیم را تنها در صورت نیاز و بهصورت انتخابی به مدل بفرستید.
- اندازهگیری و رصد مصرف: مصرف توکن را بر حسب وظیفه پایش کنید تا منابع و نقاط بهینهسازی مشخص شوند.
پیامدها برای تیمها و فروشندگان
وقتی تیمها هزینهٔ یک عامل مبتنی بر مدلهای زبانی بزرگ را برآورد میکنند، نباید تنها به نرخ مدل نگاه کنند؛ رفتار هارنس میتواند بخش بزرگی از هزینهٔ نهایی را شکل دهد. برای سازندگان عامل، بهینهسازی کف پرومپت، سیاستهای ارسال زمینه و راهکارهای کش میتواند کاهش هزینهٔ محسوس برای کاربران نهایی فراهم کند.
منابع برای مطالعهٔ بیشتر
- پرومپتسازی — مفاهیم پایهای مرتبط با کف پرومپت.
- NVIDIA — یکی از سختافزارهایی که در برخی بنچمارکها استفاده شد.
یافتهها نشان میدهد بهبود در لایهٔ هارنس اغلب بازدهی بیشتری نسبت به تغییر مدل خام دارد؛ بنابراین تیمهایی که دنبال کاهش هزینهاند ابتدا باید طراحی هارنس و مدیریت زمینه را بازبینی کنند. انتظار میرود در آیندهٔ نزدیک نوآوریهایی در کش و خلاصهسازی زمینه عرضه شود که مصرف توکن هارنس و هزینهها را بهطرز چشمگیری کاهش دهد.
