آیا مدل‌های وزن‌باز جایگزینی اقتصادی برای لایه‌های Agentic هستند؟

اگر امروز برای کاهش هزینه‌های API به مدل‌های محلی روی آورده‌اید، احتمالاً با یک «مالیات پنهان» در زمان و پایداری مواجه شده‌اید. داده‌ها نشان می‌دهند که مدل‌های محلی در مقیاس واقعی، نمی‌توانند ثبات لازم برای حلقه‌های تعاملی عامل‌های هوش مصنوعی را فراهم کنند. این یافته‌ها نشان می‌دهد که مدل‌های با وزن باز (Open-weight) در مقایسه با مدل‌های پیشرو (Frontier Baselines)، در حفظ پایداری مورد نیاز برای لوپ‌های عامل‌های تعاملی دچار مشکل هستند.

به نقل از گزارش منتشر شده در ۱۶ اکتبر ۲۰۲۶ در وب‌سایت webofmike.com، نتایج بنچمارکی که توسط مایک تمز، مهندس Solo.io در ۹ اکتبر ۲۰۲۶ انجام شده، هشدار می‌دهد که استفاده از یک مدل زبانی بزرگ (LLM) محلی به عنوان لایه‌ی ارزان‌قیمت (Cheap Tier) برای عامل‌های هوش مصنوعی، یک مالیات پنهان در زمان و قابلیت اطمینان ایجاد می‌کند که اغلب از برچسب قیمت صفر دلاری آن سنگین‌تر است. این آزمایش در حالی رخ می‌دهد که توسعه‌دهندگان برای کاهش هزینه‌های عملیاتی و سربار API، به دنبال جایگزین‌های محلی هستند. همان‌طور که در تحلیل قبلی ما درباره‌ی کاهش هزینه‌های مدل‌های محلی در پروژه‌هایی مثل FlipPrice اشاره کردیم، اکنون صنعت در حال آزمایش این است که آیا این رویکرد «صفر-دلاری» برای مسیریابی‌های پیچیده در عامل‌های هوش مصنوعی (Agentic Routing) پاسخگو است یا خیر. برای مدیریت بهینه این زیرساخت‌ها، ۱۱ چارچوب متن‌باز برای مدیریت عامل‌های هوش مصنوعی محلی معرفی شده‌اند که می‌توانند در سازماندهی این لایه‌ها کمک کنند.

در یک ساختار رایج مسیریابی بر اساس اطمینان (Confidence-routed setup) — مشابه آزمایش confidence-routed-agents که از Jev شرکت TypeSafe AI به عنوان یک API تصمیم‌گیر نوع‌بندی شده استفاده می‌کرد — یک مدل ارزان کارهای ساده را مدیریت می‌کند و تنها موارد دشوار را به یک مدل ممتاز مانند Claude Sonnet 5 ارجاع می‌دهد.

جزئیات فنی بنچمارک

در این آزمایش از agentgateway v1.6.0 برای ارسال درخواست‌های یکسان و سازگار با OpenAI از طریق مسیر /v1/chat/completions به سه بک‌اِند مختلف استفاده شد. هدف، طبقه‌بندی ۶۰ مورد ریسک فراخوانی ابزار از مجموعه jev-benchmark بود تا هر فراخوانی در یکی از دسته‌های «فقط خواندنی» (readonly)، «تخریبی» (destructive)، «دارای امتیاز ویژه» (privileged) یا «نشت داده» (exfiltration) قرار گیرد.

توزیع داده‌ها برای سنجش دقیق مرزهای هر مدل به این صورت بود:

• موارد واضح: ۳۴ مورد
• موارد مبهم: ۱۴ مورد
• موارد خصمانه: ۱۲ مورد

استفاده دقیق از همین مجموعه داده‌ها به گونه‌ای طراحی شده بود که نتایج را بتوان مستقیماً با بنچمارک اصلی jev-benchmark و آزمایش confidence-routed-agents در همان مقیاس مقایسه کرد.

مشخصات مدل‌های مورد آزمایش

مدل‌های محلی از طریق Ollama روی سخت‌افزار Apple M4 Max اجرا شدند. لازم به ذکر است که مدل qwen3.8 در اینجا نسخه‌ی ۲۷.۳ میلیارد پارامتری است، نه نسخه‌ی ۱۲۵ میلیاردی "Qwen3.8 Flash Next" که اخیراً در Hacker News با ۹۲۹ امتیاز مورد بحث بود. مدل‌های دیگر مانند GLM-5.3 Flash و DeepSeek V4.1 Flash به دلیل حجم زیاد برای حافظه M4 Max (بدون کوانتش بیشتر) و نبود کلیدهای API میزبانی شده روی ماشین تست، از این آزمایش حذف شدند. در این راستا، مدل‌های بهینه‌تری مانند LFM2.5 با معماری خاص خود توانسته‌اند در سخت‌افزارهای مشابه اپل، سرعت پاسخ‌دهی بسیار بالاتری را ثبت کنند.

مشخصات دقیق مدل‌ها به شرح زیر است:

• qwen3.8: ۲۷.۳ میلیارد پارامتر، کوانتش Q4_K_M، پنجره متنی ۲۶۲ هزار توکن.
• nemotron-3.5-lightning: ۳۲.۹ میلیارد پارامتر (معماری MoE پراکنده، ساختار nemotron_h_moe)، کوانتش Q4_K_M، پنجره متنی ۱ میلیون توکن.
• Claude Sonnet 5: مدل مرجع (Baseline) که از طریق پرووایدر Anthropic در agentgateway متصل شد.

شکاف عمیق در قابلیت اطمینان

بر اساس مستندات این آزمایش، تفاوت در پایداری تکان‌دهنده است. Claude Sonnet 5 در ۵۹ مورد از ۶۰ مورد (۹۸.۳٪) پاسخ داد و ۵۵ مورد از آن ۵۹ پاسخ صحیح بود که منجر به دقت کلی ۹۱.۷ درصدی شد. در مقابل، nemotron-3.5-lightning در ۵۵٪ از درخواست‌ها (۳۳ مورد از ۶۰) اصلاً نتوانست پاسخی قابل تحلیل (Parseable) تولید کند.

نکته عجیب این است که نمرونترون هرگاه پاسخ داد، ۱۰۰٪ دقیق بود (۲۷ مورد از ۲۷ مورد)؛ اما در بیش از نیمی از موارد، تمام بودجه‌ی ۹۰۰ توکنی خود را در میانه استدلال صرف کرد و در نهایت محتوای خالی برگرداند. این یعنی مدل صرفاً «اشتباه» نمی‌کند، بلکه مدلی است که مکرراً در این رابط کاربری، در به پایان رساندن پاسخ شکست می‌خورد.

مدل qwen3.8 پایدارتر بود و در ۹۰٪ موارد پاسخ داد (۵۴ مورد از ۶۰) که ۵۳ مورد از آن‌ها صحیح بود و دقت کلی ۸۸.۳٪ را ثبت کرد. اما بهای این پایداری در معیارهای تأخیر (Latency) ظاهر شد:

• Claude Sonnet 5: تأخیر میانه (p50) ۱,۰۸۰ میلی‌ثانیه؛ p95 برابر با ۱,۴۱۲ میلی‌ثانیه؛ هزینه ۰.۰۰۰۷۰۴ دلار در هر فراخوانی.
• nemotron-3.5-lightning: تأخیر میانه (p50) ۶,۵۱۲ میلی‌ثانیه؛ p95 برابر با ۸,۵۷۱ میلی‌ثانیه؛ هزینه ۰ دلار.
• qwen3.8: تأخیر میانه (p50) ۱۸,۸۸۵ میلی‌ثانیه؛ p95 برابر با ۴۲,۳۶۸ میلی‌ثانیه؛ هزینه ۰ دلار.

در واقع مدل محلی Qwen در مقایسه با تأخیر ۱.۰۸ ثانیه‌ای کلود، بین ۱۵ تا ۲۰ برابر کندتر بود.

گلوگاه «تفکر» و خطای سیستمی

یک نقص فنی بحرانی در نحوه مدیریت مدل‌های استدلالی توسط Ollama کشف شد. طبق گزارش مایک تمز، اندپوینت سازگار با OpenAI در اولاما، پارامتر think: false را به طور بی‌صدا نادیده می‌گیرد.

در حالی که اندپوینت بومی /api/chat اولاما دستور think: false را می‌پذیرد و پاسخ‌های تمیز را در کمتر از یک ثانیه برمی‌گرداند، اما چون agentgateway برای حفظ یک شمای یکپارچه از مسیر سازگار با OpenAI استفاده می‌کند، این پارامتر نادیده گرفته می‌شود. در نتیجه، مدل تمام بودجه max_tokens خود را صرف یک بلوک استدلالی ناتمام می‌کند.

برای مثال، یک درخواست curl به گیت‌وی با max_tokens: 20 و think: false منجر به بازگشت یک فیلد محتوای خالی و finish_reason: "length" شد، در حالی که فیلد استدلال در میانه جمله قطع شده بود. پاسخ به این شکل بود: {"choices":[{"message":{"content":"","reasoning":"The user wants me to # reply with exactly \"OK\". This is a simple instruction - I just"}, ... "finish_reason":"length"}]}. این یک کابوس برای محیط عملیاتی است: سیستم کد HTTP 200 (موفقیت) برمی‌گرداند، اما عامل هیچ تصمیمی برای اجرا دریافت نمی‌کند.

برای کاهش این مشکل، در بنچمارک از بودجه‌های توکن بالاتر استفاده شد: ۷۰۰ توکن برای qwen3.8 و ۹۰۰ توکن برای nemotron-3.5-lightning. با این حال، حتی این مقدار هم برای تمام موارد کافی نبود.

تحلیل عملکرد بر اساس دشواری

وقتی مدل‌ها موفق به پاسخ‌دهی شدند، نتایج بر اساس پیچیدگی وظایف متفاوت بود:

• موارد واضح (۳۴ مورد): هر سه مدل به دقت ۱۰۰٪ (۳۴ از ۳۴) دست یافتند.
• موارد مبهم (۱۴ مورد): مدل‌های qwen3.8 (۱۰ از ۱۱، ۹۰.۹٪) و nemotron-3.5-lightning (۳ از ۳، ۱۰۰٪) در واقع از Claude Sonnet 5 (۱۰ از ۱۳، ۷۶.۹٪) بهتر عمل کردند.
• موارد خصمانه (۱۲ مورد): مدل‌های qwen3.8 (۹ از ۹، ۱۰۰٪) و nemotron-3.5-lightning (۳ از ۳، ۱۰۰٪) از Claude Sonnet 5 (۱۱ از ۱۲، ۹۱.۷٪) پیشی گرفتند.

اما نرخ شکست نمرونترون دقیقاً در همین بخش‌های سخت متمرکز بود. تنها ۳ مورد از ۱۴ مورد مبهم و ۳ مورد از ۱۲ مورد خصمانه پاسخ دریافت کردند. موارد دشوارتر به توکن‌های استدلالی بیشتری نیاز دارند که همین موضوع باعث شد قطع شدن پاسخ به دلیل محدودیت بودجه توکن، بیشتر رخ دهد.

موازنه مهندسی: زمان در برابر پول

این مطالعه روشن می‌کند که هزینه «صفر دلاری» تنها برای سخت‌افزاری است که از قبل خریداری شده و بیکار است؛ این هزینه شامل قیمت نمونه‌های GPU ابری که ساعتی محاسبه می‌شوند، نمی‌شود. علاوه بر این، حالت شکست (Failure Mode) به طور خاص مربوط به مسیر سازگار با OpenAI در گیت‌وی است.

فراخوانی مستقیم API بومی Ollama احتمالاً شکاف نرخ پاسخ‌دهی را برطرف می‌کند، اما در عوض باعث از دست رفتن لاگ‌های دسترسی یکپارچه، بودجه گیت‌وی و سیاست‌های مسیریابی می‌شود که وجود یک گیت‌وی را برای یک عامل مسیریاب ضروری می‌کند. افزایش بیشتر max_tokens در مسیر OpenAI ممکن است پاسخ‌های بیشتری تولید کند، اما تأخیر p95 را در سخت‌ترین وظایف بدتر می‌کند.

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

گام بعدی شما

توسعه‌دهندگان می‌توانند این یافته‌ها را با کلون کردن مخزن themsquared/open-weight-cheap-tier تست کنند. فرآیند به این صورت است:

1. git clone https://github.com/themsquared/open-weight-cheap-tier
2. cd open-weight-cheap-tier
3. ollama pull qwen3.8 و ollama pull nemotron-3.5-lightning
4. export ANTHROPIC_API_KEY=sk-ant-...
5. docker compose up -d
6. اجرای python3 bench.py --model برای هر یک از سه مدل.

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

• اگر از مدل‌های محلی برای مسیریابی استفاده می‌کنید، حتماً اندپوینت بومی Ollama را جایگزین مسیر OpenAI کنید تا مشکل think: false حل شود.
• بودجه max_tokens را برای مدل‌های استدلالی محلی حداقل روی ۱۰۰۰ توکن تنظیم کنید تا از قطع شدن پاسخ‌ها در موارد پیچیده جلوگیری شود.

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