اگر یک سرور اشتراکی برای چندین کاربر مدیریت می‌کنید، یک به‌روزرسانی ساده می‌تواند کل جریان کاری تیم شما را متوقف کند. در محیط‌های عملیاتی، پیش‌بینی‌پذیریِ یک فرآیند بسیار ارزشمندتر از جذابیت یک قابلیت جدید است.
یک سرور عملیاتی که اولاما (Ollama) را روی سخت‌افزار M1 Max با ۶۴ گیگابایت رم اجرا می‌کرد، به‌رغم وسوسه‌برانگیز بودن قابلیت‌های عامل (Agent) — که شبیه دستیاری است که فقط دستور نمی‌گیرد، بلکه می‌تواند برای رسیدن به هدف، مراحل مختلف را برنامه‌ریزی و اجرا کند — پیشنهاد به‌روزرسانی به نسخه v0.32.0 را رد کرد. طبق گزارش‌های فنی، در سخت‌افزارهای اشتراکی، تضادی بنیادین بین خودمختاری مدل و پایداری سیستم وجود دارد. برای تیم‌هایی که منابع واحد پردازش گرافیکی (GPU) را به صورت مشترک مدیریت می‌کنند، مواجه شدن با خطای «دستور ناشناخته» بسیار بهتر از کراش کردن کل سیستم در محیط عملیاتی است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مدیریت منابع در مدل‌های محلی اشاره کردیم، انتقال از محیط‌های آزمایشگاهی به سرویس‌های داخلی اشتراکی، حساسیت‌ها را تغییر می‌دهد. در این محیط‌ها، یک دستگاه مک اغلب به عنوان مرکزی برای کاربران متعدد عمل می‌کند که وظایفی متنوع نظیر تولید تصویر یا استنتاج (Inference) — یعنی لحظه‌ای که مدل واقعاً جواب تولید می‌کند؛ مثل خودِ آشپزی، نه دوره‌ی آموزش آشپز — را اجرا می‌کنند. وقتی سخت‌افزار به صورت اشتراکی استفاده می‌شود، قابلیت پیش‌بینی یک فرآیند بسیار باارزش‌تر از نوآوری‌های یک قابلیت جدید است.
واقعیت «دستور ناشناخته»
طبق بررسی‌های عملی، کسانی که سعی کردند از قابلیت‌های جدید استفاده کنند با شکست مواجه شدند. اجرای دستور ollama agent منجر به خطای Error: unknown command "agent" for "ollama" می‌شود.
بررسی دستورات موجود از طریق --help نشان می‌دهد که فایل باینری تنها از دستوراتی نظیر serve ،create ،show ،run ،stop ،pull ،push ،list ،ps ،cp ،rm و launch پشتیبانی می‌کند. زیردستور agent به طور فیزیکی در باینری غایب است. این موضوع تایید می‌کند که نسخه‌ی نصب شده، آن نسخه‌ای نیست که در آخرین یادداشت‌های انتشار (Release Notes) توصیف شده است.
تله‌ی انحراف نسخه
به نقل از گزارش فنی وب‌سایت dev.to که در ۳۰ ژوئیه ۲۰۲۶ منتشر شد، بررسی‌های ساده‌ی نسخه اغلب مدیران سیستم را گمراه می‌کند. بررسی از طریق Homebrew ممکن است نسخه v0.32.1 را به صورت پایدار (bottled) نشان دهد، در حالی که باینری در حال اجرا که به صورت اپلیکیشن Electron نصب شده، همچنان روی نسخه v0.30.8 مانده است.
این اختلاف به این دلیل رخ می‌دهد که مسیرهای سیستم (System Path) اغلب به باینریِ اپلیکیشن لینک می‌شوند که چرخه به‌روزرسانی Homebrew را دنبال نمی‌کند. در این مورد خاص، دستور brew info ollama وضعیت را «نصب نشده» (Not installed) گزارش می‌کرد، چون نصب واقعی در مسیر /Applications/Ollama.app قرار داشت. باینری موجود در /usr/local/bin/ollama صرفاً یک لینک نمادین (Symbolic Link) به باینری داخلی اپلیکیشن است.
برای یافتن نسخه واقعی باید متادیتای اپلیکیشن بررسی شود:$ defaults read /Applications/Ollama.app/Contents/Info.plist CFBundleShortVersionString
این بررسی تایید کرد که نسخه واقعی ۰.۳۰.۸ است. همچنین بررسی برچسب‌های زمانی (Timestamps) پوشه‌ها نشان داد که اپلیکیشن از تاریخ ۱۲ ژوئن ۲۰۲۶ جایگزین یا به‌روزرسانی نشده است. این موضوع یک «انحراف» (Drift) میان آنچه مستندات ادعا می‌کنند و آنچه سخت‌افزار در عمل اجرا می‌کند ایجاد می‌کند.
تحول ساختاری در نسخه v0.32.0
بر اساس خلاصه‌های داخلی از انتشار این نسخه در ۱۱ ژوئیه ۲۰۲۶، ماهیت ابزار به‌طور بنیادین تغییر کرده است:
- نسخه‌های پیشین (v0.30.x): ابزارهایی طراحی شده بودند تا مدل را یک بار فراخوانی کنند و یک پاسخ واحد دریافت نمایند.
- نسخه v0.32.0 و پس از آن: ابزارهایی که اجرای آن‌ها یک عامل را فعال می‌کند که قادر است کارهای واقعی را تفویض کند؛ مانند کدنویسی یا انجام جست‌وجوی وب.
این یک گذار از ابزاری «واکنشی» (Reactive) به یک عامل «خودمختار» (Autonomous) است که می‌تواند وظایف چندمرحله‌ای را به طور مستقل پیش ببرد.
ترومای تخریب پایگاه داده
تصمیم برای اجتناب از به‌روزرسانی، ریشه در شکست شدیدی دارد که در ۱۴ ژوئیه ۲۰۲۶ رخ داد. در یکی از تلاش‌ها برای آپدیت، پایگاه داده تنظیمات Ollama.app در مسیر ~/Library/Application Support/Ollama/db.sqlite دچار فساد (Corruption) شد و سلسله‌مراتب مدل‌ها را تخریب کرد.
- علائم: دستور
ollama listناگهان تنها یک مدل را نشان می‌داد، در حالی که مدل‌های دیگر هنوز روی دیسک حضور داشتند. - علت ریشه‌ای: ستون
settings.modelsدر دیتابیس SQLite به‌اشتباه به‌روزرسانی شده بود تا به جای ریشه (Root)، به یک زیرپوشه در سلسله‌مراتب مدل‌ها اشاره کند. - تضاد: این تنظیم داخلی اپلیکیشن بر متغیرهای محیطی
OLLAMA_MODELSو پیکربندی‌هایlaunchctl setenvاولویت داشت.
بازیابی این وضعیت نیازمند اجرای مستقیم دستورات UPDATE در SQL برای بازنویسی دستی فایل db.sqlite بود. این تجربه ثابت می‌کند که پرش‌های نسخه‌ای در این ابزار می‌تواند نحوه مدیریت حالت‌های داخلی را به‌طور بنیادین تغییر دهد و ریسک از دست رفتن پیکربندی مدل‌های متعدد را به همراه داشته باشد.
تداخل منابع در GPUهای اشتراکی
در یک دستگاه M1 Max اشتراکی، حافظه ویدیویی (VRAM) یک بازی با مجموع صفر است. این ماشین یک محیط ایزوله نیست، بلکه واحدی عملیاتی برای اجرای مدل‌های محلی Qwen است. در حال حاضر، یک اسکریپت هماهنگ‌ساز، صف وظایف خطی را مدیریت می‌کند تا از کراش سیستم هنگام تولید سنگین ویدیو یا موسیقی جلوگیری شود.
مانیتورینگ سیستم با دستور ps aux | grep ollama بار فعلی را نشان می‌دهد:
llama-serverدر حال اجرایqwen3-coder-nextروی پورت ۵۵۴۳۳ با فعال بودن--flash-attn onو پارامتر-np 1.- فرآیندهای هم‌زمان برای
ollama serveو اپلیکیشن Electron مخفی (Ollama hidden).
معرفی عامل‌های خودمختار، این مدل خطی را می‌شکند:
- وضعیت فعلی: هر دستور برابر با یک فرآیند واحد با چرخه حیات و زمان اجرای پیش‌بینی‌پذیر است.
- وضعیت عامل‌محور: یک دستور، یک حلقه چندمرحله‌ای از جست‌وجوهای وب و اجرای کدها را فعال می‌کند.
از آن‌جا که زمان‌بند (Scheduler) خارجی نمی‌داند چرا یک عامل چندین گام داخلی برمی‌دارد، این عامل می‌تواند GPU را به‌طور نامحدود اشغال کند، سایر فرآیندهای حیاتی شرکت را منجمد سازد و این فرض را که «هر دستور برابر با یک فرآیند است» از بین ببرد.
چک‌لیست به‌روزرسانی در محیط عملیاتی
برای جلوگیری از این شکست‌ها، گزارش مذکور یک فرآیند تأیید چهار مرحله‌ای را پیش از به‌روزرسانی ابزارهای GPU اشتراکی پیشنهاد می‌کند:
۱. تأیید فیزیکی: به مدیریت بسته (Package Manager) اعتماد نکنید. دستور --version و --help را روی خودِ باینری اجرا کنید تا وضعیت فعلی را بررسی کنید. به خاطر داشته باشید که مسیرهای مختلف نصب (Homebrew در مقابل اپلیکیشن رسمی یا بیلد دستی) چرخه‌های به‌روزرسانی متفاوتی ایجاد می‌کنند.
۲. حسابرسی تاریخی: به دنبال کراش‌های گذشته مربوط به فایل‌های پیکربندی، شمای دیتابیس‌های داخلی یا اولویت‌های متغیرهای محیطی در آن ابزار خاص بگردید. اگر یک به‌روزرسانی قبلی دیتابیس را خراب کرده است، به‌روزرسانی جدید ممکن است همان شکست را تکرار کند.
۳. تحلیل وضعیت: از ps aux استفاده کنید تا دقیقاً ببینید چه چیزی در حال اجراست و چه کسی از GPU استفاده می‌کند. تعیین کنید که آیا ماشین یک ایستگاه آزمایشگاهی اختصاصی است یا یک ستون عملیاتی اشتراکی.
۴. همسویی با سیاست‌ها: بررسی کنید آیا یک قابلیت خودمختار (مانند مرور وب یا اجرای خودکار کد) با سیاست‌های امنیتی، جریان‌های تأییدیه یا پروتکل‌های زمان‌بندی منابع موجود تداخل دارد یا خیر. اگر ابزاری اکنون بتواند «تصمیم بگیرد» چند مرحله طی کند، ممکن است اسکریپت‌های هماهنگ‌سازی فعلی را دور بزند.
این رویکرد، به‌روزرسانی را از یک واکنش غریزی به یک تمرین مدیریت ریسک تبدیل می‌کند. در بستر زیرساخت‌های اشتراکی هوش مصنوعی، گران‌ترین به‌روزرسانی آن است که منجر به بازسازی دستی دیتابیس شود، در حالی که بقیه تیم از دسترسی به GPU محروم شده‌اند.
اینکه آیا به‌روزرسانی کنیم یا خیر، به این بستگی دارد که ماشین شما یک محیط آزمایشگاهی برای کنجکاوی است یا ستونی برای تولید. برای مورد دوم، «توقف در نسخه فعلی» یک قابلیت است، نه یک باگ.
گفتگو