اگر امروز برای اجرای عاملهای هوش مصنوعی هزینه میپردازید، احتمالاً بخش بزرگی از بودجهی شما صرف پردازش دادههایی میشود که مدل پیشتر خوانده است. این یک نشت مالی خاموش است که هیچ هشدار یا خطایی صادر نمیکند و تنها با یک حسابرسی دستی آشکار میشود.
به نقل از گزارشی که در ۴ سپتامبر ۲۰۲۶ در dev.to منتشر شد، عادت باز گذاشتن نامحدود جلسات باعث میشود با هر پاسخ ساده، مدل مجبور شود مگابایتها متن قدیمی را دوباره پردازش کند. این پدیده به عنوان «مالیات بازخوانی» شناخته میشود؛ جایی که هر پاسخ جدید، هزینهی پردازش کل تاریخچه را به همراه دارد.
مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — در اینجا شبیه کارمندی است که پیش از پاسخ به هر سؤال ساده، باید تمام صفحات یک پوشهی در حال رشد را از ابتدا بخواند. تصور کنید هر بار که یک سؤال روتین میپرسید، این کارمند مجبور است تمام سوابق قبلی را مرور کند. هرچه پوشه حجیمتر شود، هزینه پاسخ حتی برای کارهای ساده هم سرسامآور میشود. این حالت شکست، یک نشت مالی ایجاد میکند که چون باعث توقف سیستم یا ایجاد خطا نمیشود، تا زمانی که یک حسابرسی دقیق انجام نشود، نامرئی باقی میماند.
زمینه و جزئیات حسابرسی
همانطور که در تحلیلهای قبلی ما دربارهی بهینهسازی هزینههای استنتاج اشاره کردیم، مدیریت حافظه کلید سودآوری در مقیاس است. برای یافتن این نشت، نویسنده ۴۵ روز از تاریخچههای محلی (که تقریباً بازه زمانی ژوئن تا اوایل اوت را پوشش میداد) را از طریق یک اسکریپت سفارشی PowerShell تحلیل کرد. هدف این بود که اندازهگیری شود آیا عامل هوش مصنوعی به دلیل «ناکارآمدی» — یعنی شکست در فراخوانی ابزارها و صرف زمان زیاد برای بازیابی از خطاها — در حال سوزاندن بودجه است یا خیر.
یک نکته حیاتی در این متدولوژی این بود که کل فرآیند تجزیه و تحلیل (Parse) روی ماشین محلی اجرا شد و هیچ توکنی مصرف نکرد. نویسنده اشاره میکند که وقتی اندازهگیری رایگان باشد، تبدیل به یک عادت هفتگی میشود، نه یک پروژه یکباره که فقط یک بار انجام شود.
هزینه ناکارآمدی
طبق دادههای این حسابرسی، ۷۲۹ مورد شکست در استفاده از ابزار (Tool Use) در این بازه ۴۵ روزه شناسایی شد که بهطور متوسط روزانه ۱۶ مورد است. این خطاها منجر به ۷۱۸ دور «بازیابی» (Recovery Turns) شد؛ یعنی لحظاتی که مدل متوقف شد تا پس از یک شکست، محیط را پاکسازی و اصلاح کند. هزینه این پاکسازیها حدود ۱۵.۸۵ میلیون «واحد مؤثر» محلی بود. وقتی این رقم با کل هزینه ۱.۰۵ میلیارد واحدی مقایسه شود، میبینیم که صورتحساب پاکسازی خطاها تنها ۱.۵٪ از کل هزینهها را تشکیل میداد.
مقصر اصلی، پنجرهٔ زمینه (Context Window) — میزان متنی که مدل همزمان در ذهن نگه میدارد، شبیه میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — بود. «مالیات بازخوانی» حدود ۸۰٪ از کل هزینهها را به خود اختصاص داده بود.
جزئیات تکاندهنده این اتلاف منابع عبارت است از:
- سنگینترین جلسات: تنها سه جلسه حجیم در یک هفته ۴۹۳ میلیون توکن مصرف کردند که معادل ۲۰٪ کل هزینه هفتگی بود. این تبها صرفاً به این دلیل باز مانده بودند که کاربر احساس میکرد با بستن آنها، چیزی را از دست میدهد.
- رکورد تکجلسه: بدترین جلسه با ۶۶۵ پیام و تاریخچهای به حجم ۷.۲ مگابایت، ۲۴۰ میلیون توکن از حافظه پنهان (Cache) خواند.
- تحلیل شکستها: ۴۰٪ شکستها اشتباهات واقعی عامل بود. این موارد شامل ویرایش فایلهایی بود که قدیمی شده بودند، مسیرهایی که از دو جلسه قبل دیگر وجود نداشتند، ساختارهای JSON فراخوانی ابزار که توسط Schema رد شده بودند، یا اسکریپتهای PowerShell که از عملگرهایی استفاده میکردند که در نسخه نصبشده روی سیستم موجود نبود. این نوع خطاها یادآور تلههای دقت ساختگی در عاملهای هوش مصنوعی است که در آن مدلها نتایجی متقاعدکننده اما غلط تولید میکنند.
- اصطکاک محیطی: ۶۰٪ خطاها ناشی از محیط بود. برای مثال، زمانبر شدن تزریق اسکرینشات در صفحات شلوغ، قفل شدن فایلها توسط ویندوز در هنگام ویرایش، و یک سایت شبکه اجتماعی حرفهای که هرگز به حالت DOM-idle نمیرسید و باعث میشد ابزار مرورگر ۴۵ ثانیه منتظر بماند و سپس تسلیم شود.
راهکار سه مرحلهای برای توقف نشت
برای متوقف کردن این نشت، نویسنده سه تغییر عملیاتی خاص را اعمال کرد. اول، اجرای یک قانون بهداشت سختگیرانه: جلساتی که طبق حسابرسی مصرف بالایی دارند، فوراً آرشیو میشوند. سپس یک جلسه جدید باز شده و تنها با یک خط «تحویل» (Handoff) اطلاعات ضروری منتقل میشود تا هیچ ارزشی به بقای زمینه قدیمی وابسته نباشد.
دوم، تغییر رویکرد در مورد کارایی مدل؛ نویسنده دیگر فرض نکرد که مدلها بهطور خودکار بهینه عمل میکنند. هر روتین برنامهریزیشده در سیستم به ارزانترین مدلی که توانایی انجام آن کار را داشت، «پین» (Pin) شد. این بررسی باعث شناسایی «فراخوانیهای پخش جریان کاری» (Workflow fan-out calls) شد که به دلیل نبود تنظیمات صریح، از مدلهای پرمیوم و گرانقیمت استفاده میکردند. انتقال اینها به لایههای ارزانتر تنها با یک تغییر کوچک در پیکربندی انجام شد. این بهینهسازی هزینهای در مقیاس وسیع، مشابه تجربیات اتوماسیون در برزیل است که تضاد میان قیمتهای نمایشی و هزینههای واقعی عملیاتی را برجسته میکند.
سوم، اتوماسیون فرآیند اندازهگیری؛ یک اسکریپت ۲۰۰ خطی PowerShell اکنون هر یکشنبه اجرا میشود تا تاریخچههای هفته را بهصورت محلی تجزیه کرده و یک فایل Snapshot بنویسد. چون این ابزار از API استفاده نمیکند، ابزار اندازهگیری «صادق» باقی میماند و هزینه توکن آن صفر است.
نتایج و دستاوردها
تأثیر این تغییرات فوری و قابل اندازهگیری بود. حجم توکنهای خواندهشده از حافظه پنهان (Cache-read) در بازه هفتروزه برای تمام مدلها، از ۲.۴۵ میلیارد توکن در ۹ اوت، به ۴۴۷ میلیون در ۲۷ اوت و در نهایت به ۱۵۱ میلیون توکن در ۳۰ اوت رسید.
تعداد پیامهای هفتگی نیز در همین بازه بهشدت کاهش یافت و از ۱۷,۳۸۵ پیام به ۲,۸۹۹ و در نهایت به ۱,۰۱۴ پیام رسید. اگرچه در این بازه زمانی یک مهاجرت سیستمی (Estate Migration) رخ داد، اما نویسنده اشاره میکند که تعداد پیامها «سیگنال صادقانه» است، زیرا بستن جلسات یک تغییر رفتاری است، نه صرفاً یک تغییر فنی.
یک نکته مهم: «واحدهای مؤثر» استفاده شده در این گزارش، وزندهیهای محلی برای مقایسه هزینهها بین انواع مختلف توکنها هستند و با صورتحساب نهایی فروشنده تفاوت دارند. با این حال، نسبتها (Ratios) یافتههای کلیدی هستند. این تغییر ثابت میکند که عامل هوش مصنوعی بهندرت بخش گرانِ معادله است؛ بلکه رفتار کاربر — بهویژه تمایل به باز گذاشتن تبها — اصلیترین ردیف هزینه در صورتحساب است.
برای هر کسی که در حال مقیاسدهی عاملهای هوش مصنوعی است، این یعنی مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — اهمیت کمتری نسبت به مدیریت جلسات دارد. مؤثرترین راه کاهش هزینه، باهوشتر کردن مدل نیست، بلکه کوتاهتر کردن زمینه است.
گام بعدی شما
- تاریخچه جلسات فعال خود را بررسی کنید و هر جلسهای که بیش از ۵۰ پیام دارد را آرشیو کرده و در جلسه جدید باز کنید.
- برای کارهای تکراری و ساده، مدلهای ارزانتر (مانند GPT-4o-mini یا Claude Haiku) بهصورت صریح جایگزین مدلهای پرچمدار کنید.
- یک اسکریپت ساده برای تحلیل حجم توکنهای مصرفی در هر جلسه بنویسید تا نقاط نشت بودجه را شناسایی کنید.
اما داستان سختافزاری این تحول و نحوه مدیریت حافظه در لایههای پایینتر حتی شگفتانگیزتر است — به تحلیل ما دربارهی KV Cache مراجعه کنید.
گفتگو