‏قبل از خرید مک جدید برای AI agentها، مک فعلی رو بررسی کن

حرف اصلی مقاله اینه که هیچ مکی یه workload بی‌نظم agentها رو درست نمی‌کنه. مشکل معمولاً قدرت خام نیست، اینه که agentهای کدنویسی، مدل‌های محلی، مرورگرها و dev serverها همه هم‌زمان سر RAM و فضای ذخیره‌سازی رقابت می‌کنن. نویسنده می‌گه قبل از خرید Mac mini یا Mac Studio یا یه MacBook بزرگ‌تر، اول ببین مک فعلیت زیر بار واقعی چه وضعی داره.

اولین قدم Activity Monitor و تب Memory هست. نمودار memory pressure (یعنی میزان فشاری که سیستم برای جواب دادن به نیاز حافظه تحمل می‌کنه) سبز یعنی اوضاع خوبه، زرد و قرمز یعنی سیستم داره کم میاره. قدم دوم بخش Storage تو System Settings هست. RAM فضای کاریه و دیسک هم فایل‌ها و swap (جایی که macOS وقتی RAM پر می‌شه داده رو موقتاً روی دیسک می‌ذاره) رو نگه می‌داره. پیشنهاد مقاله اینه که یه agent یه بررسی فقط-خواندنی انجام بده و بدون تغییر چیزی، بزرگ‌ترین مصرف‌کننده‌ها رو پیدا کنه.

چرا agentها این‌قدر حافظه می‌خورن؟ حتی وقتی مدلی مثل Claude یا Codex از دیتاسنتر جواب می‌ده، dev server، مرورگر پیش‌نمایش و ابزارهای build روی خود مک اجرا می‌شن. هر harness حافظهٔ خودش رو داره و با بقیه هماهنگ نیست. نویسنده می‌گه agentهایی که با reinforcement learning آموزش دیدن معمولاً تا کسی متوقفشون نکنه ادامه می‌دن، پس یه کار تموم‌شده ممکنه dev server و تب مرورگرش رو روشن بذاره. راه‌حل ارزونش اینه که برای هر کار یه شرط توقف و یه جای مشخص برای خروجی تعریف کنی.

مشکلات دیسک هم عجیب‌تر از انتظاره. تو کامیونیتی Codex مواردی گزارش شده: یه پوشهٔ crash report که از ۵۰ گیگ رد شد، بیشتر از ۱۰۰ گیگ Git object مربوط به checkpointهای هر turn، و یه باگ لاگ‌نویسی که تو ۲۱ روز حدود ۳۷ ترابایت روی SSD نوشت، تا اینکه OpenAI تو ژوئن اصلاحش کرد و بعداً هم یه نسخه فضای بلااستفادهٔ دیتابیس لاگ رو آزاد کرد. این عددها مال تنظیمات خاصن، ولی نشون می‌دن باگ‌ها بی‌صدا دیسک رو پر می‌کنن و SSD رو هم فرسوده می‌کنن.

تعداد هستهٔ CPU هم مستقیم به تعداد agent قابل اجرا تبدیل نمی‌شه. دوتا agent که منتظر جواب API ابری‌ان تقریباً هیچ منبعی مصرف نمی‌کنن، ولی دوتا agent که build بزرگ محلی یا رندر ویدیو انجام می‌دن همهٔ هسته‌ها رو پر می‌کنن. پس هسته‌های بیشتر Mac Studio فقط وقتی کمک می‌کنن که کارت واقعاً موازی و محلی باشه. برای مدل‌های محلی هم context بزرگ‌تر حافظهٔ بیشتر می‌خواد و لود نگه داشتن مدل حافظه رو اشغال می‌کنه، و تنظیمات Ollama، LM Studio و Docker Desktop (مثل resource saver و محدودیت VM) از خود مک مهم‌ترن.

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

نکات کلیدی:

• گلوگاه معمولاً memory pressure و فضای دیسکه، نه سرعت چیپ.
• دو بررسی اول: نمودار حافظه تو Activity Monitor و بخش Storage تو System Settings.
• موارد گزارش‌شده از Codex: پوشهٔ crash بالای ۵۰ گیگ، بیشتر از ۱۰۰ گیگ Git checkpoint، و ۳۷ ترابایت نوشتن روی SSD تو ۲۱ روز.
• تعداد هسته فقط برای کارهای محلی موازی مثل build، inference یا رندر کمک می‌کنه.
• تنظیمات Ollama، LM Studio و Docker Desktop روی مصرف حافظه اثر زیادی دارن.
• مک قدیمی رو بعد از ارتقا به‌عنوان worker دوم نگه دار.