تصور کنید ماهانه ۲۷۶,۸۱۴ درخواست از مدل‌های پیشرفته هوش مصنوعی ارسال کنید، اما به‌جای یک صورت‌حساب نجومی و متغیر، مبلغی ثابت و پیش‌بینی‌پذیر بپردازید. تیم LeanStack دقیقاً همین کار را کرد و هزینه پردازش این حجم عظیم از داده را به ۴۳۰ دلار در ماه رساند.
این دستاورد از طریق ایجاد یک درگاه محلی (Local Gateway) و ترکیبی از اشتراک‌های ماهانه با نرخ ثابت (Flat-rate) به‌دست آمده است. این رویکرد ثابت می‌کند که جریان‌های کاری عامل‌محور (Agentic) — شبیه به داشتن تیمی از کارمندان مجازی که هر کدام وظیفه خاصی دارند — لزوماً نباید با افزایش حجم توکن‌ها، هزینه‌های خطی و سرسام‌آوری داشته باشند و می‌توان آن‌ها را از مقیاس‌بندی هزینه‌های خطی جدا کرد. این چالش مدیریت هزینه‌ها در سیستم‌های عامل‌محور، مشابه همان دغدغه‌ای است که در بررسی سازوکار Claude Code برای مهار هزینه‌های تصادفی API به آن پرداختیم.
بسیاری از توسعه‌دهندگان امروز بین دو راه سخت گیر کرده‌اند: یا نرخ‌های گرانِ توکنی (Per-token) را برای پایداری بپذیرند یا از نسخه‌های رایگان استفاده کنند که زیر فشار حجم زیاد فرو می‌پاشند. راهکار LeanStack مسیر سومی را باز می‌کند؛ آن‌ها با تبدیل حساب‌های اشتراکی (Subscription Logins) به API، ریسک مالی را از «صورت‌حساب‌های غافلگیرکننده» به «محدودیت سهمیه» (Quota Limit) تغییر دادند که مدیریت آن در محیط توسعه بسیار ساده‌تر است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم، مدیریت لایه دسترسی به مدل‌ها کلید کاهش هزینه‌هاست.
معماری درگاه محلی
به نقل از گزارشی که در ۱۵ اکتبر ۲۰۲۶ منتشر شد، هسته این سیستم یک درگاه محلی است که بین هر عامل (Agent) و هر ارائه‌دهنده مدل قرار می‌گیرد. تمام اسکریپت‌ها، ابزارهای کدنویسی و هر عاملی که روی ماشین در حال اجراست، ابتدا با این نقطه اتصال محلی واحد صحبت می‌کنند و درگاه تصمیم می‌گیرد هر درخواست در واقع به کجا ارسال شود. این درگاه به عنوان مغز مرکزی تمام ترافیک عمل کرده و چهار قابلیت حیاتی را فراهم می‌کند:
- ثبت یکپارچه (Unified Logging): هر درخواست در یک فایل واحد ثبت می‌شود که شامل ارائه‌دهنده، مدل، وضعیت (Status)، مدت‌زمان پاسخ‌دهی و میزان توکن‌های مصرفی (شامل توکن‌های حافظه پنهان) است. تمام اعداد ذکر شده در این گزارش از این فایل استخراج شده‌اند؛ بدون آن، تیم تنها در حال حدس زدن بود.
- مسیریابی متمرکز (Centralized Routing): عامل‌ها یک مدل یا نام مسیر (Route Name) را درخواست می‌کنند و درگاه آن را به یک ارائه‌دهنده متصل می‌کند. انتقال یک حجم کاری از یک مسیر پولی به یک مسیر رایگان، تنها با یک تغییر در فایل تنظیمات (Config) انجام می‌شود، نه با ویرایش بیست عامل مختلف.
- جایگزینی خودکار (Automatic Fallbacks): اگر یک مسیر خاص با محدودیت نرخ (Rate Limit) مواجه شود یا با خطا متوقف شود، درگاه به‌طور خودکار تلاش می‌کند درخواست را به یک گزینه جایگزین (Secondary Candidate) ارسال کند. این قابلیت برای حفظ پایداری سیستم هنگام استفاده از لایه‌های رایگان ناپایدار، ضروری است.
- یکپارچگی با اشتراک‌ها (Subscription Integration): این درگاه اجازه می‌دهد تیم به‌جای استفاده از کلیدهای API متری (که بر اساس توکن هزینه دارند)، از لاگین‌های طرح‌های ماهانه با نرخ ثابت استفاده کند. این مکانیسم اصلی است که هزینه هر توکن را به صفر می‌رساند.
مسیریابی بر اساس پیچیدگی وظیفه
تیم LeanStack برای هر کاری از یک مدل واحد استفاده نمی‌کند. آن‌ها وظایف را بر اساس عمق استدلال مورد نیاز دسته‌بندی می‌کنند تا هزینه‌ها بهینه شوند. قانون کلی آن‌ها این است که استدلال‌های سنگین و کدنویسی به قوی‌ترین مدل‌ها در طرح‌های ثابت ارجاع داده شوند. در ماه ثبت شده، بزرگ‌ترین مسیر از نظر حجم ورودی، یک مدل برتر Claude بود که از طریق لاگین اشتراکی دسترسی داشت.
- استدلال سنگین (Heavy Reasoning): کدنویسی پیچیده و منطق‌های عمیق به قوی‌ترین مدل‌ها در طرح‌های ماهانه ارجاع داده می‌شوند.
- کارهای پس‌زمینه (Background Work): خلاصه‌سازی، طبقه‌بندی، تریاژ و حجم زیادی از کارهای زمان‌بندی شده (Cron-style jobs) روی لایه‌های رایگان مدل‌ها اجرا می‌شوند، به شرطی که کیفیت خروجی قابل قبول باشد.
- کارهای آزمایشی (Experimental Work): تست‌های جدید از SKUهای پیش‌نمایش (Preview) و رایگان استفاده می‌کنند، با این پیش‌فرض صریح که این مسیرها ممکن است ناپایدار (Flaky) باشند.
از نظر حجم، اشتراک‌های ثابت و لاگین‌ها (شامل Claude، xAI، Cursor، ChatGPT و Google Antigravity) تقریباً ۷۸٪ از توکن‌های ورودی را مدیریت کرده‌اند. یک طرح کدنویسی ۱۰ دلاری ۱۱٪ و لایه‌های رایگان مدل‌ها (شامل SKUهای رایگان/پیش‌نمایش OpenRouter، لایه رایگان NVIDIA و مسیرهای رایگان محلی) ۱۰٪ سهم داشتند. تنها ۲٪ از ترافیک از طریق یک کلید API پولی گوگل عبور کرده است که صورت‌حساب آن هنوز تأیید نشده بود.
توزیع درخواست‌ها و مدل‌ها
تفاوت عجیبی بین تعداد درخواست‌ها و حجم توکن‌ها وجود دارد. مسیرهای رایگان تعداد درخواست‌های بسیار زیادی را جابه‌جا می‌کنند اما سهم کمی از کل توکن‌ها را دارند. برای مثال، تنها دو مسیر OpenRouter به تنهایی بیش از ۱۱۵,۰۰۰ درخواست داشتند. در مقابل، کارهای سنگین و غنی از کانتکست (Context-rich) در اشتراک‌های ماهانه متمرکز بودند.
تفکیک دقیق درخواست‌ها و توکن‌ها:
- OpenRouter (رایگان اختصاصی): ۶۱,۷۰۵ درخواست / ۴۸۸ میلیون توکن ورودی
- OpenRouter (رایگان/پیش‌نمایش): ۵۳,۲۹۱ درخواست / ۱۹۱ میلیون توکن ورودی
- Google: ۴۲,۰۳۷ درخواست / ۱۶۳ میلیون توکن ورودی
- طرح کدنویسی (۱۰ دلار): ۲۹,۹۴۷ درخواست / ۱.۰۶ میلیارد توکن ورودی
- Anthropic: ۲۹,۴۶۶ درخواست / ۳.۱۴ میلیارد توکن ورودی
- xAI: ۲۴,۱۶۴ درخواست / ۳.۰۶ میلیارد توکن ورودی
- Cursor: ۱۱,۶۸۴ درخواست / ۱.۲۵ میلیارد توکن ورودی
- مسیرهای رایگان محلی: ۱۰,۱۳۲ درخواست / ۱۸۲ میلیون توکن ورودی
- OpenAI (طرح ChatGPT): ۴,۰۲۸ درخواست / ۲۳۲ میلیون توکن ورودی
قدرت حافظه پنهان پرامپت
استفاده از حافظه پنهان پرامپت (Prompt Caching) موتور اصلی این بهره‌وری بود. از مجموع ۹.۹ میلیارد توکن ورودی، ۷.۲ میلیارد توکن (حدود ۷۳٪) از حافظه پنهان سرو شده‌اند. از آنجا که عامل‌ها به‌طور مکرر پرامپت‌های سیستمی، تعاریف ابزارها (Tool Definitions) و تاریخچه گفتگو را در تقریباً هر فراخوانی ارسال می‌کنند، ثابت نگه داشتن پیشوند پرامپت (Prompt Prefix) ارزان‌ترین بهینه‌سازی موجود است.
برای به حداکثر رساندن این قابلیت، LeanStack مکانیسم‌های خاصی را دنبال کرد:
- ثبات پیشوند (Prefix Stability): آن‌ها پرامپت سیستمی و طرح‌های ابزار (Tool Schemas) را در ابتدا قرار دادند و هرگز ترتیب آن‌ها را تغییر ندادند.
- جای‌گذاری داده‌های پویا (Dynamic Data Placement): هر چیزی که تغییر می‌کند، مانند برچسب‌های زمانی (Timestamps) یا شناسه‌های اجرا (Run IDs)، در انتهای پرامپت قرار گرفت.
- بازاستفاده از گفتگو (Conversation Reuse): برای عامل‌هایی که مدت زمان اجرای طولانی دارند، به‌جای شروع مجدد، از گفتگوهای موجود استفاده کردند (در مواردی که کلاینت پشتیبانی می‌کرد).
- مانیتورینگ مسیرها (Route Monitoring): آن‌ها از لاگ‌های درگاه استفاده کردند تا مسیرهایی که توکن‌های حافظه پنهان صفر گزارش می‌کردند را شناسایی کنند؛ این موضوع نشان‌دهنده یا عدم گزارش‌دهی ارائه‌دهنده یا شکست در فرآیند کشینگ بود.
کالبدشکافی هزینه‌ها و بهای «رایگان»
مجموع هزینه ۴۳۰ دلاری ماهانه شامل چهار اشتراک ثابت است. تیم همچنین از یک لایه میزبانی رایگان به همراه یک Redis رایگان برای ثبت‌نام‌ها استفاده کرد، به این معنی که هزینه میزبانی صفر دلار به مجموع اضافه شد:
- طرح Claude: ۲۰۰ دلار
- طرح Cursor: ۲۰۰ دلار
- طرح ChatGPT: ۲۰ دلار
- طرح کدنویسی: ۱۰ دلار
- هزینه API توکنی (Metered): ۰ دلار
اما این بهره‌وری با یک جریمه جدی در زمینه پایداری همراه است. LeanStack گزارش داد که ۲۵٪ از ۲۷۶,۸۱۴ درخواست آن‌ها با شکست مواجه شدند. به‌طور دقیق‌تر، ۷۱,۹۵۳ درخواست پاسخ موفق نداشتند که ۲۲,۱۱۱ مورد آن مربوط به محدودیت نرخ (HTTP 429) بود. باقی شکست‌ها ترکیبی از خطاهای ۵xx در سمت سرور، درخواست‌های نادرست (Bad Requests)، قطع اتصال کلاینت و خطاهای ۴۰۴ (یافت نشد) بودند.
مسیرهای رایگان و پیش‌نمایش بدترین عملکرد را داشتند و برخی از آن‌ها کمتر از ۵۰٪ مواقع موفق بودند. تیم همچنین با خطاهای ۴۰۴ مکرری مواجه شد زیرا ارائه‌دهندگان مدل‌های پیش‌نمایش یا مخفی (Stealth) خود را تغییر نام داده یا بازنشسته می‌کردند. این موضوع سه درس کلیدی را برجسته کرد: لایه‌های رایگان ذاتاً ناپایدارند، نام مدل‌ها به‌سرعت تغییر می‌کنند و محدودیت‌های نرخ (Rate Limits) کل معماری را شکل می‌دهند. یک مسیر رایگان نمی‌تواند بار ۶۶ شغل زمان‌بندی‌شده را که به‌صورت شبانه‌روزی اجرا می‌شوند، تحمل کند.
حفاظ‌ها و مدیریت ریسک
برای جلوگیری از حلقه‌های تکراری (Runaway Loops) که سهمیه‌ها را تخلیه کنند یا منجر به شکست‌های خاموش شوند، تیم سه حفاظ (Guardrails) سخت‌گیرانه را پیاده کرد. در طرح‌های ثابت، ریسک دیگر صورت‌حساب غافلگیرکننده نیست، بلکه سوختن سهمیه یا محدود شدن (Throttling) در میانه یک وظیفه است. برای هر کلید متری که در سیستم باشد، ریسک یک حلقه تکراری در طول شب وجود دارد.
- بودجه روزانه هر عامل (Per-Agent Daily Budgets): توقف‌های سخت بر اساس تعداد درخواست یا توکن که به‌جای هشدار دادن، عامل را به‌طور کامل متوقف (Kill) می‌کند.
- مسیرهای مجاز (Allow-listed Routes): محدودیت‌های خاص برای اطمینان از اینکه یک شغل پس‌زمینه نتواند به‌طور خودکار سطح دسترسی خود را به گران‌ترین مدل ارتقا دهد.
- عدم جایگزینی خاموش (No Silent Fallbacks): اگر یک مسیر رایگان شکست بخورد، سیستم باید به یک مسیر رایگان/ثابت دیگر برود یا به‌طور واضح خطا دهد. انتقال مخفیانه به یک API پولی (Pay-per-token) اکیداً ممنوع است.
این معماری برای چه کسانی مناسب نیست؟
این معماری یک راهکار جهانی نیست و برای چندین گروه نامناسب است:
- کاربران کم‌حجم: اگر در ماه تنها چند صد فراخوانی انجام می‌دهید، مدل پرداخت به‌ازای مصرف (Pay-as-you-go) قطعاً ارزان‌تر از ۴۳۰ دلار هزینه اشتراک است.
- محصولات تجاری و مشتری‌محور: لاگین‌های اشتراکی و لایه‌های رایگان فاقد قراردادهای سطح خدمات (SLA) هستند و شرایط استفاده (ToS) سخت‌گیرانه‌ای دارند. استقرار حرفه‌ای نیازمند قراردادهای API رسمی است. در واقع، برای تبدیل این ابزارها به یک محصول تجاری موفق، باید بر موانعی نظیر وابستگی به توزیع انسانی در جذب مخاطب غلبه کرد.
- تیم‌های دارای نیازهای انطباقی (Compliance): طرح‌های شخصی، شخصی هستند. این ساختار توافق‌نامه‌های پردازش داده (DPA)، مسیرهای حسابرسی (Audit Trails) یا صورت‌حساب‌های مشترک سازمانی را فراهم نمی‌کند.
- جویندگان سیستم‌های بدون نیاز به نگهداری: مدیریت جداول مسیریابی، جابه‌جایی بین سهمیه‌ها و مدیریت مدل‌های بازنشسته نیاز به توجه و نظارت مداوم دارد.
توسعه‌دهندگانی که می‌خواهند این مسیر را پیاده کنند، باید با ساخت یک درگاه ثبت وقایع (Logging Gateway) شروع کنند. شما نمی‌توانید هزینه‌ای را بهینه کنید که نمی‌بینید، و لاگ‌ها تنها راه شناسایی مسیرهای شکست‌خورده یا پرامپت‌هایی هستند که از حافظه پنهان استفاده نمی‌کنند.
گام بعدی شما
- پیاده‌سازی یک درگاه محلی ساده برای ثبت تمام توکن‌های ورودی و خروجی مدل‌هایتان.
- شناسایی پرامپت‌های تکراری و سازماندهی آن‌ها برای فعال‌سازی حافظه پنهان (Prompt Caching).
- دسته‌بندی وظایف عامل‌هایتان به سه سطح «سنگین»، «معمولی» و «آزمایشی» برای توزیع بین مدل‌های پولی و رایگان.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو