مدل‌های ابری در برابر مدل‌های محلی؛ نبرد پایداری در نظارت زیرساختی

تصور کنید سیستمی را طراحی کرده‌اید که قرار است نگهبان سرورهای شما باشد، اما این نگهبان با اطمینان کامل، وجود خطاهایی را تأیید می‌کند که اصلاً رخ نداده‌اند. انتخاب مدل اشتباه برای نظارت بر زیرساخت، خطرناک‌تر از نبودِ کاملِ اتوماسیون است. این خطر، محوریت گزارش منتشر شده در ۲۱ ژوئیه ۲۰۲۶ توسط یک توسعه‌دهنده بود که در آن، تلاشی سخت‌گیرانه برای جایگزینی چارچوب‌های گسترده و حجیم عامل‌ها با یک پشته «حداقلی» (Bare-minimum) را مستند کرده است؛ سیستمی که هدفش دستیابی به پایداری در محیط‌های با ریسک بالا است.

زمینه: گسترش بی‌رویه عامل‌ها (Agent Sprawl)

اکثر عامل‌های هوش مصنوعی مدرن به عنوان دستیارهای دیجیتالی طراحی شده‌اند که کارهایی مانند مدیریت تقویم‌ها و ایمیل‌ها را از طریق ادغام‌های پیچیده OAuth انجام می‌دهند. پروژه OpenClaw نمونه بارز این روند است؛ این پروژه در کمتر از پنج ماه، از یک فعالیت ساده آخر هفته به یکی از مخازن ستاره‌دار (Most-starred) گیت‌هاب تبدیل شد. OpenClaw تعریف «عامل هوش مصنوعی» را از یک چت‌بات ساده به سیستمی تغییر داد که ایمیل‌ها را می‌خواند، ایشوهای گیت‌هاب را ثبت می‌کند و از طریق رابط‌های دیسکورد یا تلگرام به‌صورت نیمه‌خودکار اجرا می‌شود. این تحول در مدیریت عامل‌ها، مسیر جایگزینی کنترل‌های محلی با رابط‌های ابری در OpenClaw را هموار کرد تا دسترسی‌پذیری این ابزارها افزایش یابد.

برای کسانی که سرورهای عملیاتی (Production) را مدیریت می‌کنند، این سطح از گسترش و پیچیدگی، یک نقطه ضعف و ریسک محسوب می‌شود. ناوگان‌های کامل از عامل‌ها با ده‌ها سطح دسترسی OAuth, ساختار مناسبی برای کارهای زیرساختی ندارند. هدف این توسعه‌دهنده در مقابل، خلق یک محیط اجرای متمرکز بر خط فرمان (CLI-first) و نابود بود که بتواند یک کار خسته‌کننده اما حیاتی را به‌درستی انجام دهد: حسابرسی وضعیت زیرساخت. او به سیستمی نیاز داشت که آن‌قدر کوچک و ساده باشد که بتوان با اطمینان، آن را به‌صورت بدون نظارت در کنار زیرساخت‌های حساس رها کرد.

برای دستیابی به این هدف، توسعه‌دهنده از PicoClaw استفاده کرد؛ یک محیط اجرای سبک برای عامل‌ها. PicoClaw مفاهیم اصلی یک عامل — یعنی یک مدل، مجموعه‌ای از ابزارها، یک فضای کاری ایزوله (Sandboxed workspace) و یک کانال ارتباطی — را حفظ می‌کند اما تمام اضافات و زواید را حذف می‌کند. در این سیستم خبری از رابط کاربری وب (Web UI)، سربارهای داکر (Docker overhead) و ادغام با اینباکس یا تقویم نیست. در واقع، این ابزار تنها یک حلقه اجرایی (Agent loop) است که به یک پوشه کاری و مجموعه‌ای از ابزارهای صراحتاً مجاز اشاره می‌کند. این رویکرد مینیمالیستی در واقع پاسخی به تلاش‌های پیشین برای به دست آوردن دقت بالا در تحلیل مخازن گیت‌هاب بدون وابستگی به ابر است.

لایه‌بندی مدل‌ها

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

• سطح ۱ (ریسک پایین): PicoLM. یک مدل محلی بسیار کوچک با پاسخ‌های آنی که برای پاسخ‌های بدیهی و تک‌کلمه‌ای در نظر گرفته شده است. هرچند این مدل نصب شده است، اما فعلاً بدون تغییر مانده است، زیرا پرسش‌هایی مانند «ساعت چند است» در نظارت بر زیرساخت کاربردی ندارند. این لایه برای وظایف آینده با ریسک پایین و تکرار زیاد رزرو شده است.
• سطح ۲ (تحلیل محلی): Qwen3 (8B). این مدل برای اجرا روی دستگاه (On-device) پیکربندی شده و از یک تنظیمات خاص «بدون تفکر» (No-think) بهره می‌برد تا قابلیت اطمینان در فراخوانی ابزارها تضمین شود.
• سطح ۳ (پایداری بالا): DeepSeek V4 Flash. این مدل از طریق یک پروکسی LiteLLM که به‌صورت خودمیزبان (Self-hosted) است، دسترسی پیدا می‌کند تا یک «مغز» ابری برای تحلیل‌های پیچیده فراهم کند.

حل مشکل «تفکر»

هنگام آزمایش مدل Qwen3، یک مانع بزرگ ظاهر شد. حالت پیش‌فرض «استدلال» یا «تفکر» (Reasoning/Thinking) این مدل — که برای چت‌های باز و گسسته عالی است — برای یک حلقه اجرایی عامل (Agent loop) مضر بود. مدل اغلب در تحلیل‌های داخلی خود می‌چرخید و باعث تأخیر در فراخوانی ابزار مورد نیاز می‌شد. برای یک عامل، عدم توانایی در فراخوانی مطمئن دستوراتی مانند read_file یا run_command باعث می‌شود سیستم فارغ از اینکه چقدر متون آن شیوا باشد، عملاً بی‌فایده شود. این چالش در مدیریت منطق استدلالی، مشابه پیچیدگی‌هایی است که در سازوکار GnLOLot برای استخراج منطق استدلالی از داده‌های متنی بررسی شده است.

استفاده از پرچم‌های استاندارد زمان اجرا مانند PARAMETER think false در Ollama با شکست مواجه شد و خطای «پارامتر ناشناخته» (Unknown parameter) را برگرداند. دلیل این اتفاق این بود که سینتکس Modelfile در اولاما، علیرغم شباهت ظاهری به سایر پارامترهای فعال، از این پارامتر خاص پشتیبانی نمی‌کرد.

برای رفع این مشکل، نیاز بود یک Modelfile سفارشی با یک قالب (TEMPLATE) ویژه ساخته شود که سه اقدام مشخص را انجام دهد:
۱. افزودن عبارت /no_think به هر پیام کاربر، پیش از آنکه به مدل برسد.
۲. حذف هرگونه بلوک <think>...</think> از نحوه رندر شدن پاسخ‌های دستیار.
۳. اجبار به قرار دادن یک جفت بلوک خالی `

` در ابتدای هر نوبت پاسخ دستیار، تا به Qwen3 سیگنال داده شود که مرحله تفکر به پایان رسیده و باید بلافاصله به سراغ محتوا یا فراخوانی ابزار برود.

این ساخت سفارشی به عنوان یک مدل مجزا با نام qwen3-local در اولاما تعریف شد، به جای اینکه از تگ استاندارد qwen3:8b استفاده شود. یک اجرای آزمایشی با دستور ollama run qwen3-local "hello" تأیید کرد که هیچ بلوک تفکر سرگردانی در پاسخ‌ها نشت نمی‌کند.

دیوار توهمات

حتی پس از تثبیت فراخوانی ابزارها، مدل‌های محلی مانند Gemma4 و Qwen3 با یک شکست بحرانی مواجه شدند: توهم (Hallucination) در تحلیل‌های چندمرحله‌ای. در طول حسابرسی‌های زیرساختی که شامل چندین فایل می‌شد، مدل‌های محلی با اطمینان کامل چیزهایی را گزارش می‌دادند که وجود نداشتند: فایل‌هایی که هرگز ایجاد نشده بودند و خطوطی از لاگ که با داده‌های واقعی مطابقت نداشتند.

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

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

درس‌هایی برای مهندسی عامل‌ها

این تغییر رویکرد، نشان‌دهنده یک روند رو به رشد در توسعه عامل‌ها است. دیگر چارچوب — یعنی CLI، محیط ایزوله و سیم‌کشی API — بخش سخت ساخت نیست. چالش واقعی مهندسی اکنون در «لایه میانی خسته‌کننده» نهفته است: تصمیم‌گیری درباره اینکه کدام مدل آن‌قدر قابل اعتماد هست که وظایفی به او سپرده شود (لایه به لایه) و صداقت در پذیرفتن اینکه یک ساختار محلیِ جذاب‌تر، لزوماً قابل اطمینان‌تر نیست.

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

فاز بعدی این آزمایش، انتقال از شرایط تست پاکیزه به حسابرسی‌های زنده زیرساختی است. این مرحله تعیین خواهد کرد که آیا شرط‌بندی روی DeepSeek برای پایداری، در برابر هرج‌ومرج داده‌های واقعی محیط تولید (Production) دوام می‌آورد یا خیر، و آیا مدل می‌تواند بدون شکست در حین تحلیل، مشکلات را به‌طور دقیق شناسایی کند یا نه.

گام بعدی شما

• اگر عامل محلی می‌سازید، نرخ توهم مدل را در سناریوهای «منفی» (تلاش برای یافتن چیزی که وجود ندارد) بسنجید.
• برای حذف حلقه‌های تفکر در مدل‌های استدلالی، از قالب‌های سفارشی (Custom Templates) در اولاما استفاده کنید.
• هزینه‌ی یک پاسخ اشتباه را محاسبه کنید؛ اگر قیمت آن بالا است، از مدل‌های ابری با قابلیت اطمینان بیشتر استفاده کنید.

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