جداسازی عامل از مدل هزینهٔ اتوماسیون خانگی را به ۲ دلار در ماه رساند

اگر امروز برای اشتراک‌های ماهانه مدل‌های هوش مصنوعی هزینه می‌دهید، احتمالاً بخش زیادی از بودجه خود را بابت «سکوت» مدل پرداخت می‌کنید. یک توسعه‌دهنده در ۱۰ سپتامبر ۲۰۲۶ با جزئیات شرح داد که چگونه با تغییر معماری و جداسازی عامل از مدل، صورت‌حساب ماهانه خود را به حدود ۲ دلار کاهش داده است.

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

انگیزه‌های تغییر ساختار

به نقل از مستندات این پروژه، سه هدف اصلی باعث شد توسعه‌دهنده از اشتراک‌های تک‌فروشنده فاصله بگیرد. نخست، حذف وابستگی به فروشنده (Vendor Coupling) بود. وقتی یک عامل، یک مدل و یک حساب کاربری به هم گره می‌خورند، کاربر در برابر محدودیت‌های نرخ درخواست (Rate Limit) و تغییرات ناگهانی سیاست‌ها آسیب‌پذیر است. اگر هر یک از این اجزا روز بدی داشته باشند، کل وضعیت اتوماسیون کاربر دچار اختلال می‌شود.

دوم، نیاز به هزینه‌ای بود که با میزان مصرف واقعی رشد کند. استفاده از عامل (Agent) — شبیه به یک دستیار اداری که می‌تواند ابزارها را مدیریت کند و تصمیم بگیرد — در محیط‌های خانگی (Homelab) به‌طور ذاتی نوسانی است؛ یعنی برخی روزها به‌شدت شلوغ و برخی هفته‌ها کاملاً ساکت است. اشتراک‌های ماهانه بر اساس تعداد کاربر (Per-seat) مبلغ ثابتی می‌گیرند، فارغ از اینکه فعالیتی صورت گرفته باشد یا خیر. هدف این بود که فقط هزینه توکن‌هایی که واقعاً «سوزانده» شده‌اند پرداخت شود.

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

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

معماری جداساز: تفکیک دست از مغز

در این ساختار جدید، «دست‌ها» از «مغز» جدا شده‌اند. توسعه‌دهنده از OpenCode به‌عنوان لایه عامل استفاده کرد. چون OpenCode متن‌باز و مستقل از مدل (Model-agnostic) است، می‌تواند مخازن کد را بخواند، ابزارها را اجرا کند و فایل‌ها را ویرایش نماید، فارغ از اینکه کدام مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — در حال استدلال است. این کار باعث شکستن وابستگی می‌شود، زیرا ابزاری که با کد در تماس است، دیگر به ارائه‌دهنده هوش متصل نیست.

برای مدیریت لایه هوش، او OpenRouter را یکپارچه کرد. این سرویس مانند یک نقطه اتصال واحد (API Endpoint) عمل می‌کند که دسترسی به ده‌ها مدل از ارائه‌دهندگان مختلف را فراهم می‌سازد. با تغییر یک مقدار ساده در تنظیمات (Configuration value)، کاربر می‌تواند بین یک مدل پیشرو، یک مدل ارزان و سریع، یا حتی یک مدل رایگان جابه‌جا شود.

این ترکیب، یک تابلوی توزیع واقعی می‌سازد. عامل ثابت می‌ماند و مغز تنها یک مقدار در فایل تنظیمات است. وقتی مدلی جدید معرفی می‌شود که بازدهی بهتری نسبت به قیمت (Performance-per-pound) ارائه می‌دهد، می‌توان آن را تنها با ویرایش یک خط کد آزمایش کرد. در این حالت، هیچ بخشی از اتوماسیون به یک شرکت خاص جوش داده نشده است.

استراتژی‌های بهینه‌سازی هزینه

کاهش هزینه به قیمت یک فنجان قهوه در ماه، از طریق مسیریابی استراتژیک حاصل شده است:

• وظایف پیش‌پاافتاده: کارهایی مانند خلاصه‌سازی لاگ‌ها، پیش‌نویس متون و دسته‌بندی لیست‌ها به مدل‌های محلی روی سخت‌افزار کاربر سپرده شده است. هزینه این بخش تنها برق مصرفی است و این مدل‌ها اغلب برای کارهای ابتدایی دسته‌بندی، توانمندتر از حد انتظار هستند.
• کارهای حجیم: وظایف خسته‌کننده، تکراری و با حجم بالا از طریق OpenRouter به مدل‌های ارزان یا رایگان ارسال می‌شوند تا هرگز به مدل‌های گران‌قیمت نرسند.
• استدلال‌های پیچیده: مدل‌های پیشرو منحصراً برای بخش کوچکی از کارهای واقعاً دشوار و استدلال‌های عمیق رزرو شده‌اند.

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

مالیات یکپارچه‌سازی

این انعطاف‌پذیری رایگان نیست. توسعه‌دهنده هشدار می‌دهد که جداسازی، یک «وظیفه نگهداری» ایجاد می‌کند و کاربر باید خودش نقش یکپارچه‌ساز (Integrator) را ایفا کند. این «مالیات یکپارچه‌سازی» لبه‌های تیزی دارد:

• پایداری فراخوانی ابزار: کارهای عامل‌محور به فراخوانی تابع (Function Calling) ساختاریافته و قابل اعتماد نیاز دارند. بسیاری از مدل‌های ارزان یا محلی در این زمینه ضعیف‌اند؛ برخی اصلاً نمی‌توانند ابزار را فراخوانی کنند و برخی دیگر فراخوانی را صادر می‌کنند اما نتایج را نادیده می‌گیرند. این یک حالت شکست فریبنده ایجاد می‌کند که در آن سیستم به‌نظر می‌رسد در حال کار است، اما در واقع نیست.
• ریسک پنجره زمینه: محدودیت‌های پنهان در پنجره زمینه (Context Window) — میزان متنی که مدل هم‌زمان در ذهن نگه می‌دارد، شبیه میز کاری که جای چند ورق دارد — خطرناک است. یک تنظیم محلی به‌طور پیش‌فرض پنجره زمینه کوچکی داشت و به‌سادگی انتهای پرامپت‌های طولانی را بدون دادن هیچ خطایی حذف می‌کرد. این منجر به خروجی‌هایی می‌شد که با اعتمادبه‌نفس کامل اما بر اساس نیمی از ورودی، غلط بودند.
• ویژگی‌های خاص بک‌اِند: مسیریابی بین چندین بک‌اِند به این معناست که کاربر باید پیش‌فرض‌های منحصربه‌فرد و رفتارهای عجیب هر ارائه‌دهنده را مدیریت کند.

به همین دلیل، توسعه‌دهنده فهرستی از مدل‌هایی که به‌طور خاموش شکست می‌خورند (Blocklist) را تهیه کرده است. او تأکید می‌کند که کاربران باید هر مدل را روی کارهای واقعی عامل‌ها آزمایش کنند، نه اینکه صرفاً به جدول‌های رتبه‌بندی (Leaderboards) عمومی اعتماد کنند.

اولویت تاب‌آوری بر راحتی

استفاده از لایه‌های رایگان نیز ریسک‌های خاص خود را دارد. مدل‌های رایگان اغلب محدودیت نرخ درخواست دارند یا ممکن است به‌طور کلی ناپدید شوند. توسعه‌دهنده پیشنهاد می‌کند لایه‌های رایگان به‌عنوان یک امتیاز (Bonus) دیده شوند و همیشه یک جایگزین پولی (Paid fallback) برای جلوگیری از شکست زنجیره اتوماسیون فعال باشد.

در حالی که اشتراک تک‌فروشنده برای کسانی که می‌خواهند یک جفت ابزار تست‌شده داشته باشند که «فقط کار کند» منطقی است، اما یک وابستگی بحرانی در مسیر اجرای سیستم ایجاد می‌کند. با مالکیت عامل و مسیریابی، توسعه‌دهنده یک قطعی احتمالی را به یک تغییر ساده در تنظیمات تبدیل کرد.

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

گام بعدی شما

• بررسی OpenRouter برای جایگزینی APIهای تک‌فروشنده با یک نقطه اتصال واحد.
• تست مدل‌های محلی (از طریق Ollama) برای وظایف ساده جهت کاهش هزینه استنتاج.
• پیاده‌سازی لایه مسیریابی برای تفکیک کارهای ساده از استدلال‌های پیچیده.

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