۶ راهکار کاهش هزینه‌های عملیاتی LLM از طریق کشینگ و مدل‌های آبشاری

اگر امروز برای استفاده از مدل‌های پیشرو هزینه می‌پردازید، احتمالاً بخش بزرگی از بودجه شما صرف پردازش داده‌های تکراری می‌شود. بسیاری از استقرارات هوش مصنوعی از هزینه‌های سرباری بیش از حد رنج می‌برند، اما یک معماری استراتژیک و آگاه به هزینه می‌تواند هزینه عملیاتی یک دستیار پشتیبانی را بدون هیچ‌گونه افت در کیفیت، از ۱۰۰٪ به ۱۰٪ کاهش دهد.

این کارایی و بهره‌وری محوریت یک راهنمای فنی بود که توسط وب‌سایت dev.to در تاریخ ۲۳ ژوئیه ۲۰۲۶ منتشر شد. این گزارش با جزئیات کامل، شش اهرم خاص را برای حذف اتلاف‌های اجتناب‌پذیر در هزینه‌های مدل‌های زبانی بزرگ (LLM) شرح می‌دهد. اکثر صورت‌حساب‌های هوش مصنوعی به دلیل «اتلاف تکراری» متورم می‌شوند؛ یعنی پرداخت هزینه برای یک پرامپت سیستمی (System Prompt) — که مثل دستورالعمل ثابت یک آشپزخانه است و باید هر بار بازخوانی شود — به هزار مرتبه، یا استفاده از یک مدل پیشرو و گران‌قیمت برای یک وظیفه ساده‌ی طبقه‌بندی، یا تولید توکن‌هایی که هیچ‌کس هرگز آن‌ها را نمی‌خواند.

این شکاف کارایی دقیقاً زمانی ظاهر می‌شود که توسعه‌دهندگان از مرحله نمونه‌سازی (Prototyping) به مرحله مقیاس‌پذیری (Scaling) حرکت می‌کنند؛ جایی که هزینه‌های توکن به یک گلوگاه عملیاتی اصلی تبدیل می‌شود. همان‌طور که در تحلیل قبلی ما درباره‌ی Vibe Coding و خطرات آن برای اکوسیستم‌های نرم‌افزاری اشاره کردیم، این بهینه‌سازی‌های عملی، توسعه AI را از حدس‌های شهودی و تجربی به سمت یک مهندسی منظم و منضبط می‌برد.

غول‌های بهینه‌سازی: کشینگ و ابعاد

کشینگ پرامپت (Prompt Caching) بزرگ‌ترین پیروزی تک‌مرحله‌ای در کاهش هزینه‌ها است، زیرا با تخفیف دادن به پیشوندهای مشترک عمل می‌کند. بسیاری از برنامه‌ها در هر درخواست، پیشوندهای بزرگی را مجدداً ارسال می‌کنند؛ این پیشوندها شامل پرامپت‌های سیستمی، تعاریف ابزارها، پایگاه‌های دانش و مثال‌های چند-نمونه‌ای (few-shot examples) هستند. این بخش از متن اغلب ۸۰٪ از توکن‌های ورودی شما را تشکیل می‌دهد و بدون کشینگ، شما در هر بار درخواست، قیمت کامل آن را می‌پردازید.

به نقل از گزارش dev.to، اگر یک درخواست با کش مطابقت داشته باشد (Hit)، هزینه پیشوند کش‌شده تقریباً یک‌دهم قیمت عادی ورودی است. از آنجا که هزینه نوشتن اولیه در کش حدود ۱.۲۵ برابر است، نقطه سر‌به‌سر (break-even point) تنها ۲ درخواست است؛ پس از آن، بخش کش‌شده تقریباً ۹۰٪ تخفیف می‌گیرد.

برای کشینگ مؤثر، تطابق دقیق بایتی (Byte-identical) ضروری است. هر چیزی که قبل از نقطه شکستِ کش شما قرار دارد، باید در تمامی درخواست‌ها دقیقاً یکسان باشد. برای بهینه‌سازی این فرآیند، توسعه‌دهندگان باید استراتژی ترتیب‌بندی خاصی را دنبال کنند:

• محتوای ایستا در ابتدا: پرامپت‌های سیستمی منجمد (Frozen) و لیست‌های ابزارهای قطعی (Deterministic) را در ابتدای متن قرار دهید.
• محتوای متغیر در انتها: سؤال واقعی کاربر، برچسب‌های زمانی (timestamps) و شناسه‌های مربوط به هر درخواست (per-request IDs) را در پایان بیاورید.

حضور یک تابع ساده مثل datetime.now() که در پرامپت سیستمی تزریق شده باشد، می‌تواند کل کش را در هر درخواست باطل کند؛ این رایج‌ترین دلیل تبدیل نرخ Hit کش به صفر است. برای رفع این مشکل، توسعه‌دهندگان باید لاگ‌های cache_read_input_tokens خود را بررسی کنند. اگر مقدار این توکن‌ها در درخواست‌های مکرر با پرامپت سیستمی یکسان، صفر باشد، احتمالاً یک «باطل‌کننده خاموش» مانند برچسب زمانی، شناسه تصادفی یا یک JSON نامرتب در پیشوند حضور دارد.

انتخاب ابعاد مناسب مدل (Right-sizing)، دومین منبع بزرگ کاهش هزینه است. این واکنش غریزی که همه چیز به سمت هوشمندترین و گران‌ترین مدل هدایت شود، سربار عظیمی ایجاد می‌کند. راهنما یک رویکرد سه‌لایه پیشنهاد می‌دهد تا مدل را بر اساس «نوع شغل» انتخاب کنید، نه بر اساس «جاه‌طلبی توسعه‌دهنده»:

• کوچک (کلاس Haiku): حدود ۱ دلار برای ورودی و ۵ دلار برای خروجی به ازای هر میلیون توکن. این لایه برای طبقه‌بندی، استخراج داده، مسیریابی و پاسخ‌های کوتاه استفاده شود.
• متوسط (کلاس Sonnet): حدود ۳ دلار برای ورودی و ۱۵ دلار برای خروجی به ازای هر میلیون توکن. این لایه برای اکثر قابلیت‌های محصول، عامل‌های فراخوانی ابزار (tool-calling agents) و کمک‌های برنامه‌نویسی مناسب است.
• پیشرو (کلاس Opus): حدود ۵ دلار برای ورودی و ۲۵ دلار برای خروجی به ازای هر میلیون توکن. این لایه را فقط برای استدلال‌های سخت، عامل‌های با افق بلندمدت (long-horizon agents) و درخواست‌های حیاتی و پیچیده رزرو کنید.

در حالی که قیمت‌ها نوسان می‌کنند، اما نسبت‌ها ثابت می‌مانند: لایه کوچک برای ورودی و خروجی تقریباً ۵ برابر ارزان‌تر از لایه پیشرو است. همچنین توسعه‌دهندگان تشویق شده‌اند که برای کارهای حجیم با محدوده مشخص (مانند خلاصه‌سازی و ابزارهای داخلی)، از مدل‌های وزن‌های باز (Open-source) مانند Llama، Mistral، DeepSeek و Qwen استفاده کنند تا هزینه‌های مدل‌های میزبان (Hosted) را به شدت کاهش دهند.

کارایی معماری: مدل‌های آبشاری

مسیریابی چندعاملی یا «الگوی آبشاری» (Cascade Pattern)، ابعاد و کشینگ را در یک معماری با اهرم بالا ترکیب می‌کند. در این الگو، یک مدل ارزان به عنوان مرحله سریع غربال‌گری (Triage) عمل می‌کند و هر درخواست ورودی را پیش از آنکه به مدل گران برسد، طبقه‌بندی می‌کند.

در یک پیاده‌سازی رایج، مدلی ارزان (مانند Claude Haiku) با یک پرامپت هدایت می‌شود تا درخواست را تنها با یک کلمه به دو دسته «ساده» (SIMPLE) یا «سخت» (HARD) تقسیم کند. تنها درخواست‌هایی که واقعاً سخت هستند به لایه پیشرو (مانند Claude Sonnet یا Opus) ارتقا می‌یابند، در حالی که ۸۰٪ ترافیک خسته‌کننده به مدل ارزان یا مدل باز هدایت می‌شود. این کار تضمین می‌کند که شما قیمت‌های سطح بالا را فقط برای گام‌هایی می‌پردازید که واقعاً نیازمند کار سطح بالا هستند.

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

فراتر از مسیریابی API، برخی توسعه‌دهندگان کاملاً از ارائه‌دهندگان خدمات فاصله گرفته‌اند. یک پیاده‌سازی نمایش داده شد که در آن مدل Llama 3.3 70B از طریق vLLM و آداپتورهای LoRA روی یک دراپلت GPU در DigitalOcean با هزینه ۱۱ دلار در ماه مستقر شده است. این رویکرد، استدلال تنظیم‌شده (Fine-tuned reasoning) را با تقریباً ۱/۱۴۰ هزینه مدل Claude Opus فراهم می‌کند؛ جزئیات فنی این استقرار بهینه را می‌توانید در بررسی جامع نحوه استقرار Llama 3.3 70B با هزینه ماهانه ۱۱ دلار دنبال کنید.

مدیریت پاسخ‌ها و درگاه‌ها

کشینگ پاسخ (Response Caching) هدفش پرس‌وجوهای با دانش ایستا مانند FAQها، جستجوی سیاست‌ها، ترجمه‌ها یا استخراج داده از اسناد یکسان است. در حالی که کشینگ پرامپت فقط پیشوند را تخفیف می‌دهد، کشینگ پاسخ کل فراخوانی مدل را حذف می‌کند. با کش کردن پاسخ در درگاه (Gateway) — برای مثال با استفاده از کنترل max-age=3600 — درخواست‌های یکسان در بازه زمانی کش، به‌صورت رایگان سرو می‌شوند.

نکته حیاتی این است که «کلید کش» (Cache Key) شامل مدل، پرامپت و پارامترهای تولید (Generation Parameters) است. این یعنی درخواست‌های کاملاً یکسان به کش برخورد می‌کنند، در حالی که گفتگوهای متغیر از کش عبور کرده و طبق روال عادی صورت‌حساب می‌شوند. به توسعه‌دهندگان توصیه شده است که گفتگوهای خاصِ کاربر (User-specific) را کش نکنند، بلکه بر روی جستجوهای تکراری و قطعی تمرکز کنند.

پیاده‌سازی یک «درگاه» (Gateway) واحد باعث می‌شود این کنترل‌ها به جای تئوری، قابل مدیریت باشند. یک درگاه امکانات زیر را فراهم می‌کند:

• تخصیص هزینه (Spend Attribution): استفاده از تگ‌هایی مانند feature:support یا env:prod برای تبدیل صورت‌حساب‌های مبهم به تجزیه و تحلیل هزینه به ازای هر قابلیت.
• جابه‌جایی خودکار (Automatic Failover): تنظیم ترتیب ارائه‌دهندگان (مثلاً ابتدا Anthropic و سپس Bedrock) برای تغییر مدل در صورتی که ارائه‌دهنده اصلی پایین باشد یا محدودیت نرخ (Rate-limit) اعمال کند.
• محدودیت‌های کاربر: ردیابی userId برای اطمینان از اینکه یک کاربر سوءاستفاده‌گر نتواند صورت‌حساب ماهانه را به شدت افزایش دهد.
• هشدار بودجه: تنظیم تریگرها (Triggers) پیش از آنکه بودجه ماهانه تمام شود.

از آنجا که درگاه‌ها قیمت لیست ارائه‌دهنده را بدون هیچ حاشیه سودی شارژ می‌کنند، این ویژگی‌ها بدون پرداخت هزینه اضافی برای هر توکن (نسبت به فراخوانی مستقیم ارائه‌دهنده) در دسترس هستند.

بهداشت توکن و دسته‌بندی

در نهایت، «بهداشت توکن» (Token Hygiene) باقی‌مانده اتلافات را حذف می‌کند. از آنجا که صورت‌حساب بر اساس توکن‌های ورودی و خروجی است، تراشیدن هر دو ضروری است.

جزئیات پیاده‌سازی:

• خروجی ساخت‌یافته: به جای درخواست JSON در قالب نثر (Prose)، از یک Schema استفاده کنید. این روش کوتاه‌تر است، تجزیه (Parse) آن راحت‌تر است و توکن‌های تلف شده برای توضیح فرمت را حذف می‌کند.
• سقف خروجی: از maxOutputTokens استفاده کنید تا مانع از این شوید که مدل برای پاسخی که در یک جمله می‌گنجد، سه پاراگراف بنویسد.
• هرس کردن زمینه (Context Trimming): تاریخچه‌های قدیمی و نتایج ابزارهایی که دیگر با نوبت فعلی گفتگو مرتبط نیستند را خلاصه‌سازی یا حذف کنید.
• پردازش دسته‌ای (Batch Processing): برای هر وظیفه‌ای که آنی (Real-time) نیست — مانند گزارش‌های شبانه، طبقه‌بندی‌های انبوه یا بازسازی امبدینگ‌ها (Embeddings backfills) — از Batch API استفاده کنید. این پردازش نامتقارن معمولاً با تقریباً نصف قیمت استنتاج (Inference) آنی اجرا می‌شود.

این تغییر در رویکرد، این فرض را که «کیفیت بالاتر همیشه نیازمند گران‌ترین مدل است» تغییر می‌دهد. اگر این اهرم‌ها روی هم قرار گیرند، می‌توانند پروفایل هزینه یک دستیار پشتیبانی را به این شکل متحول کنند:

۱. پایه: ارسال همه چیز به مدل پیشرو + ارسال کامل پیشوند در هر درخواست = ۱۰۰٪ هزینه.
۲. با کشینگ پرامپت: کش کردن پرامپت سیستمی و ابزارها = حدود ۴۰٪ هزینه.
۳. با مسیریابی آبشاری: غربال‌گری با مدل ارزان و ارتقای تنها موارد سخت = حدود ۱۵٪ هزینه.
۴. با کشینگ پاسخ: کش کردن جستجوهای تکراری + سقف خروجی = حدود ۱۰٪ هزینه.

شرکت‌ها باید با مدل‌های پیشرو به عنوان یک منبع تخصصی برخورد کنند، نه به عنوان موتور پیش‌فرض. اتلافی که کاهش یافت، هرگز در حال انجام کار مفیدی نبود. برای کسانی که پروژه‌های جدید را شروع می‌کنند، ابزارهایی مانند Keel یک کیت شروع آگاه به هزینه، همراه با مسیریابی درگاه و قابلیت‌های جایگزینی مدل (Fallbacks) را از همان ابتدا فراهم می‌کنند.

گام بعدی شما

• لاگ‌های cache_read_input_tokens خود را بررسی کنید تا متغیرهای مخرب کش (مانند Timestampها) را بیابید.
• مدل‌های Haiku یا Llama-3-8B را برای پیاده‌سازی مرحله غربال‌گری (Triage) درخواست‌ها به کار بگیرید.
• برای کارهای غیر-آنی، فوراً به Batch API مهاجرت کنید تا ۵۰٪ هزینه استنتاج ذخیره شود.

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