توکن‌মিনینگ: استراتژی کاهش ۹۵ درصدی هزینه‌های استنتاج در مدل‌های زبانی

اگر در حال حاضر از تابع openai.chat.completions.create در یک عامل عملیاتی (Production Agent) استفاده می‌کنید، احتمالاً هزاران دلار از بودجه شما به‌دلیل پدیده‌ای به نام «بیش‌مصرفی توکن» یا Tokenmaxxing در حال نشت است. این اتفاق زمانی رخ می‌دهد که تیم‌های فنی، مصرف خام مدل‌های زبانی بزرگ (LLM) را — که اغلب در تابلوهای امتیازات داخلی شرکت‌ها به عنوان یک دستاورد جشن گرفته می‌شود — بدون پیوند دادن آن به خروجی‌های واقعی و نتایج عملیاتی ارسالی برای مشتری، به حداکثر می‌رسانند.

یک توکن (Token) — که می‌توان آن را به عنوان واحد قابل پرداخت یا قطعات کوچکی از کلمات در نظر گرفت — سازنده‌ای است که ارائه‌دهندگان بر اساس آن هزینه ورودی (Input) و خروجی (Output) را به‌طور جداگانه محاسبه می‌کنند. در حلقه‌های عامل‌محور (Agent Loops)، هزینه‌های ورودی معمولاً غالب هستند؛ زیرا تاریخچه کامل گفتگوها و تخلیه‌های داده‌ای ابزارها (Tool Dumps) در هر نوبت و هر چرخه از حلقه، دوباره و به‌طور کامل ارسال می‌شوند.

تا ۱۹ ژوئن ۲۰۲۶، سازمان‌های بزرگ و پیشروی دنیا مانند اوبر (Uber)، متا (Meta)، وال‌مارت (Walmart) و آمازون (Amazon) مسیر خود را در استفاده نامحدود از هوش مصنوعی تغییر دادند. این شرکت‌ها سقف‌های سخت مصرفی را پیاده کرده و تابلوهای امتیازات داخلی مربوط به میزان استفاده از مدل‌ها را حذف کردند. طبق گزارشی که نیویورک تایمز منتشر کرد، شرکت اوبر به‌دلیل نبود این لایه‌های نظارتی و محدودکننده، کل بودجه سالانه پیش‌بینی‌شده خود برای هوش مصنوعی را تنها در چهار ماه سوزاند. این نشان می‌دهد که صورت‌حساب‌های نجومی شما یک شکست شخصی یا خطای انسانی نیست، بلکه نتیجه نبود یک لایه‌ی محدودکننده در معماری سیستم است.

برای مقابله با این بحران، تیم‌های مهندسی در حال گذار به رویکرد «توکن‌مینینگ» (Tokenminning) یا کمینه‌سازی توکن هستند. برخلاف توصیه‌های کلی و منعطف مانند «سعی کنید پرامپت‌های کوتاه‌تری بنویسید»، توکن‌مینینگ یک سیستم رسمی و مهندسی‌شده برای اندازه‌گیری (Metering)، مسیریابی (Routing) و بهداشت بستر متن (Context Hygiene) است. هدف در این رویکرد، تغییر تمرکز از «بیشینه کردن حجم» به «بیشینه کردن ارزش به ازای هر توکن» است.

محرک‌های اصلی هزینه

سه «باگ» رایج در محیط‌های عملیاتی به‌طور معمول باعث انفجار بودجه‌های مالی می‌شوند:

• استفاده سخت‌افزاری از مدل‌های پیشرو (Hardcoded Frontier Models): استفاده از GPT-4 یا مدل‌های معادل آن برای تک‌تک درخواست‌ها، فارغ از اینکه ماهیت تکلیف چیست. کارهایی نظیر طبقه‌بندی (Classification)، استخراج داده (Extraction) و تبدیل فرمت‌ها به JSON به‌ندرت به توانمندی‌های مدل‌های لبه (Frontier Tiers) نیاز دارند. جایگزینی این روش با یک مسیریاب که ارزان‌ترین مدلی را که استانداردهای کیفیت (SLA) را پاس می‌کند انتخاب کند، می‌تواند پس از بنچ‌مارک روی ترافیک واقعی، ۶۰ تا ۹۰ درصد در هزینه‌ها صرفه‌جویی کند. در همین راستا، مقایسه‌های عملیاتی نشان می‌دهد که جایگزینی مدل‌های گران‌قیمت با گزینه‌های بهینه‌تر مانند DeepSeek می‌تواند هزینه‌های API را تا ۸۹ درصد کاهش دهد.
• حلقه‌های باز عامل‌ها (Unbounded Agent Loops): عامل‌هایی که تمام داده‌های خروجی ابزارها را حفظ می‌کنند، هرگز وضعیت (State) را خلاصه نمی‌کنند و در هر گام، همه چیز را دوباره ارسال می‌کنند. این وضعیت منجر به «تورم زمینه» یا Context Inflation می‌شود؛ جایی که تعداد کل توکن‌های هر درخواست ۱۰ برابر رشد می‌کند، حتی در حالی که قیمت هر توکن ثابت به نظر می‌رسد.
• اتلاف در ساختار پرامپت (Prompt Scaffolding Waste): گنجاندن جملات بدون سیگنال و پرورده شده مانند «تو یک دستیار مفید هستی» یا «یک نفس عمیق بکش و مرحله به مرحله فکر کن» در هر درخواست. در مقیاس ۱۰ میلیون درخواست در ماه، پرامپتی که ۲۰۰ توکن رشد کند، دیگر رایگان نیست، بلکه به یک ردیف هزینه‌ای چشمگیر در صورت‌حساب تبدیل می‌شود.

جزئیات فنی و منطق اجرا

تیم‌های مهندسی برای جایگزینی «حدس و گمان» با مهندسی دقیق، به سمت اجرای اجباری طرح‌واره (Schema Enforcement) حرکت کرده‌اند. به‌جای استفاده از قواعد توصیفی و متنی برای فرمت‌بندی، آن‌ها از json_schema برای تعریف دقیق خروجی‌ها استفاده می‌کنند. برای مثال، یک طرح‌واره برای summary_response می‌تواند به‌طور سخت‌گیرانه یک maxLength یا حداکثر طول ۵۰۰ کاراکتر را برای رشته مربوط به خلاصه را اجرا کند. خروجی‌های مبتنی بر طرح‌واره در محیط CI (یکپارچه‌سازی مداوم) اعتبارسنجی می‌شوند، در حالی که «حدس و گمان» قابل تست نیست.

منطق مسیریابی مدل باید به‌صورت یک «آبشار» (Cascade) باشد، نه اینکه به‌طور پیش‌فرض به سراغ مدل‌های گران‌قیمت برود. جریان منطقی به‌این صورت است:
درخواست $\rightarrow$ مدل کوچک $\rightarrow$ اگر بررسی کیفیت تایید شد $\rightarrow$ بازگشت پاسخ $\rightarrow$ اگر شکست خورد $\rightarrow$ تلاش با مدل میان‌رده $\rightarrow$ اگر تایید شد $\rightarrow$ بازگشت پاسخ (و ثبت گزارش ارتقاء) $\rightarrow$ اگر باز هم شکست خورد $\rightarrow$ استفاده از مدل پیشرو (و ثبت دلیل توجیهی).

این مدل تفکیکی از نقش‌ها، مشابه آنچه در معماری هیبریدی gas-fakes برای کاهش هزینه‌های Gemini مشاهده شد، اجازه می‌دهد تا پردازش‌های ساده‌تر به مدل‌های محلی یا ارزان‌تر سپرده شوند.

هر فراخوانی از مدل‌های پیشرو (Frontier) باید دلیل قابل حسابرسی (Auditable) داشته باشد؛ مواردی نظیر نمره یک طبقه‌بندی‌کننده پیچیدگی که از آستانه خاصی بالاتر رفته است، ثبت شکست یک مدل ارزان‌تر در مستندات، یا کاربری که صراحتاً سطح «کیفیت بالا» را انتخاب کرده و هزینه آن را می‌پذیرد. «ترجیح شخصی توسعه‌دهنده» هرگز توجیه پذیرفتنی برای استفاده از مدل‌های گران‌قیمت نیست.

توالی بهینه‌سازی

پیاده‌سازی موثر توکن‌مینینگ نیازمند رعایت یک ترتیب عملیاتی خاص است. بهینه‌سازی پرامپت‌ها پیش از اندازه‌گیری، یک الگوی غلط (Anti-pattern) است، زیرا در این صورت نمی‌توانید میزان صرفه‌جویی را اثبات کنید یا گلوگاه واقعی را مکان‌یابی نمایید. به همین ترتیب، محدود کردن max_tokens در خروجی بی‌فایده است اگر ورودی‌ها ۸۰ درصد از کل هزینه را تشکیل دهند.

۱. اندازه‌گیری و انتساب (Metering + Attribution): پیش‌نیاز اصلی. شما باید بتوانید به این سوال پاسخ دهید: «این اقدام کاربر، در لحظه تکمیل، دقیقاً چند دلار هزینه داشت؟»
۲. بهداشت پرامپت: حذف توکن‌های بدون سیگنال معمولاً در قالب‌های پرکاربرد، ۲۰ تا ۲۵ درصد صرفه‌جویی ایجاد می‌کند.
۳. مسیریابی مدل: پیاده‌سازی ساختار آبشاری بسته به ترکیب تسک‌ها، می‌تواند هزینه‌ها را ۶۰ تا ۹۵ درصد کاهش دهد.
۴. حافظه پنهان پرامپت (Prompt Caching): استفاده از پیشوندهای ثابت (مانند پرامپت‌های سیستمی ایستا و تعاریف ابزارها) قبل از محتوای پویا کاربر، می‌تواند ۴۱ تا ۸۰ درصد هزینه را کاهش دهد.
۵. بهداشت زمینه: مدیریت وضعیت (State) و خلاصه‌سازی در گردش‌کارهای عامل‌محور معمولاً ۴۰ تا ۶۰ درصد صرفه‌جویی می‌کند.
۶. کنترل خروجی و انضباط RAG: محدود کردن max_tokens برای تسک‌های بسته (مانند طبقه‌بندی بوليانی) از پاسخ‌های مقاله‌ای غیرضروری جلوگیری کرده و ۱۵ تا ۴۰ درصد صرفه‌جویی می‌کند.
۷. حافظه پنهان معنایی (Semantic Caching): در صورت برخورد با درخواست‌های مشابه در حافظه (Cache Hit)، استنتاج را به‌طور کامل حذف می‌کند.

اعمال محدودیت‌های سخت

در فلسفه توکن‌مینینگ، بودجه‌ها به عنوان بخشی از «معماری» در نظر گرفته می‌شوند، نه صرفاً توصیه‌هایی برای رعایت. این رویکرد شامل پیاده‌سازی بودجه‌های نشست (Session Budgets) با قابلیت «تخریب تدریجی و محترمانه» (Graceful Degradation) است. این بدان معناست که برای هر جلسه، یک tokenBudget مشخص (مثلاً ۵۰,۰۰۰ توکن) و یک usdCeiling یا سقف دلاری (مثلاً ۰.۵۰ دلار) تعریف شود.

هنگامی که یک جلسه به حد نصاب بودجه خود می‌رسد، سیستم باید به‌صورت برنامه‌ریزی شده واکنش نشان دهد:

• در ۹۰٪ بودجه: یک دستور «جمع‌بندی و نهایی‌سازی» به عامل تزریق شود.
• در ۱۰۰٪ بودجه: بهترین نتیجه ناقص ممکن با وضعیت completed_degraded بازگردانده شود.
• هرگز: نباید گفتگو را در وسط یک جمله با یک خطای خام ۴۲۹ (Too Many Requests) قطع کرد.

این رویکرد تضمین می‌کند که هیچ استثنایی تحت عنوان «تست داخلی» در محیط عملیاتی وجود نداشته باشد. سقف‌های سخت باید در کد جای بگیرند و تورم توکنی باید به‌گونه‌ای باشد که از نظر فیزیکی امکان استقرار (Deploy) در محیط تولید را نداشته باشد.

برای توسعه‌دهندگان، این بدان معناست که تمرکز از «مهندسی پرامپت» به «مهندسی زیرساخت» منتقل می‌شود. هدف، ساخت یک دفتر کل تغییرناپذیر است که در آن هر فراخوانی استنتاج به یک ویژگی خاص و هزینه جلسه متصل شود. اکنون که عصر دموهای رایگان و بی‌باک هوش مصنوعی به پایان رسیده، چالش بعدی این است که تعیین کنیم کدام «سطح کیفیت» واقعاً ارزش پرداخت مبلغ بالای مدل‌های پیشرو را دارد.

گام بعدی شما

• تحلیل صورت‌حساب‌های ماه گذشته را با تفکیک «بر اساس هر ویژگی» (Feature-based cost) انجام دهید تا نقاط نشت بودجه شناسایی شوند.
• یک لایه مسیریاب (Router) ساده برای تفکیک کارهای ساده (مثل استخراج داده) از کارهای پیچیده (مثل استدلال) پیاده‌سازی کنید.
• برای هر جلسه کاربر، سقف دلاری سخت در کد تعریف کنید تا از انفجار هزینه‌ها در حلقه‌های بی‌نهایت عامل‌ها جلوگیری کنید.

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