درون فایل‌های لاگ Jan.ai؛ ریشه‌ی توقف مدل‌ها در کمبود حافظه

تصور کنید ساعتی را صرف دانلود یک مدل زبانی بزرگ کرده‌اید، اما حالا با یک نوار بارگذاری چرخان روبرو هستید که هرگز تمام نمی‌شود. در Jan.ai، این وضعیت معمولاً به معنای کندی مدل نیست، بلکه نشانه‌ای از فروپاشی کامل سیستم در پس‌زمینه است. رابط کاربری Jan دستور شروع مدل را به موتور استنتاج می‌فرستد و منتظر می‌ماند تا پیام «آماده‌باش» دریافت کند؛ تمام آنچه شما می‌بینید، همین انتظار است. چون رابط کاربری به‌طور نامحدود منتظر می‌ماند تا یک پردازش مجزا (موتور استنتاج) گزارش آمادگی دهد، هرگونه کرش منجر به یک توقف خاموش بدون هیچ رشته متنی از خطا می‌شود. چه پردازش موتور توسط سیستم‌عامل کشته شده باشد، چه به دلیل یک فایل بدشکل (Malformed) کرش کرده باشد و چه اصلاً هرگز استارت نخورده باشد، در هر صورت چیزی وجود ندارد که آمادگی را گزارش کند و همچنین چیزی نیست که شکست را گزارش دهد.

میزبانی شخصی (Self-hosting) مدل‌های محلی به‌دلیل پل زدن میان یک رابط گرافیکی سطح بالا و منابع سخت‌افزاری سطح پایین، به‌شدت شکننده است. این پیچیدگی‌های زیرساختی در بررسی معماری Jan و نحوه ادغام llama.cpp برای تسهیل دسترسی به APIهای محلی به تفصیل شرح داده شده است. وقتی موتور زیرین می‌میرد، رابط کاربری هیچ مکانیزمی برای گزارش این شکست ندارد و کاربر را در وضعیت انتظاری ابدی رها می‌کند. این شکاف تشخیصی، یک مانع رایج برای کسانی است که از هوش مصنوعی ابری به سمت میزبانی محلی حرکت می‌کنند. در این مورد خاص، نبودِ پیام خطا، خود یک نشانه تشخیصی است. مدلی که صرفاً در بارگذاری کند است، فعالیت دیسک را نشان می‌دهد و در نهایت اجرا می‌شود؛ اما مدلی که موتور آن از کار افتاده، نه فعالیتی دارد و نه پایانی.

برای حل این مشکل باید رابط کاربری را دور بزنید و به سراغ لاگ‌ها بروید. از آنجا که رابط کاربری Jan، موتور آن و مکان‌های ذخیره‌سازی لاگ‌ها در نسخه‌های مختلف تغییر شکل داده‌اند و موتور زیرین در طول عمر پروژه تغییر نام داده و جایگزین شده است، توصیه می‌شود به جای تایپ دستی مسیرها، از گزینه منوی تنظیمات داخل برنامه که دایرکتوری لاگ‌ها را نمایش می‌دهد، استفاده کنید.

دسترسی به فایل‌های لاگ

برنامه Jan دو نوع لاگ متمایز ثبت می‌کند: یک لاگ اپلیکیشن و یک لاگ موتور استنتاج. برای دسترسی سریع به این فایل‌ها می‌توانید از دستورات زیر در ترمینال استفاده کنید:

• macOS / Linux:
  tail -n 200 ~/jan/logs/app.log
tail -n 200 ~/jan/logs/cortex.log
• Windows PowerShell:
  Get-Content "$env:USERPROFILE\jan\logs\app.log" -Tail 200

رمزگشایی از لاگ موتور

لاگ موتور استنتاج (Inference Engine) منبع اصلی حقیقت است. همیشه ابتدا لاگ موتور را بخوانید. اگر لاگ در میانه بارگذاری بدون هیچ خطایی متوقف شد، یعنی پردازش از بیرون کشته شده و شما با مورد «کمبود حافظه» روبرو هستید. اگر لاگ گزارش‌هایی مانند 'parse failure' (شکست در تجزیه)، 'bad magic value' (مقدار جادویی نامعتبر) یا 'truncated read' (خوانش ناقص) را ثبت کرده است، شما در مورد «دانلود ناقص» هستید. اما اگر لاگ اصلاً ظاهر نشد، یعنی موتور هرگز استارت نخورده است؛ این بدان معناست که مشکل از انتخاب Backend (پشتوانه) است و نه خودِ مدل. این رویکرد تحلیل لاگ‌ها برای یافتن ریشه مشکل، مشابه متدولوژی چهارمرحله‌ای برای شناسایی نقاط شکست در عامل‌های هوش مصنوعی است که بر اساس تحلیل نقاط انحراف عمل می‌کند.

علت اول: کمبود حافظه (OOM)

مدل‌های محلی نیاز دارند تمام فایل وزن‌ها (Weights) به‌طور کامل در حافظه مقیم شوند. فایل وزن‌ها به عنوان کف یا پایه عمل می‌کند و حافظه KV Cache برای طول زمینه (Context Length) پیکربندی شده، روی آن قرار می‌گیرد. وقتی مجموع این دو از آنچه ماشین می‌تواند فراهم کند بیشتر شود، سیستم‌عامل پردازش را خاتمه می‌دهد. این اتفاق به صورت Linux OOM killer، یا macOS jetsam و یا یک شکست در تخصیص حافظه در ویندوز ظاهر می‌شود که پردازش را به‌طور ناگهانی می‌بندد.

• محاسبات ریاضی: یک مدل ۱۳ میلیارد پارامتری با کوانتش Q4 تقریباً یک فایل ۷ تا ۸ گیگابایتی است. اجرای این مدل در کنار یک سیستم‌عامل دسکتاپ و یک مرورگر روی ماشینی با ۱۶ گیگابایت رم، فضای بسیار محدودی باقی می‌گذارد. اگر ماشین مجبور باشد تخصیص حافظه GPU را نیز حفظ کند، ممکن است مدل اصلاً جا نشود.
• نشانه: لاگ نشان می‌دهد که بارگذاری پیش می‌رود و سپس به سادگی به پایان می‌رسد. در macOS، می‌توانید این موضوع را از طریق یک گزارش تشخیصی در دایرکتوری لاگ کاربر که یک پایان jetsam را ثبت کرده است، تایید کنید. در لینوکس، دستور dmesg صراحتاً نام پردازش کشته شده را ذکر می‌کند.
• تله: گزارش‌های موجود در Tracker پروژه Jan توصیف می‌کنند که مدل‌ها حتی پس از یک بارگذاری شکست‌خورده، ممکن است همچنان در حافظه مقیم بمانند. هر تلاش مجدد با حافظه کمتری نسبت به تلاش قبلی شروع می‌شود و سریع‌تر شکست می‌خورد، که باعث می‌شود اپلیکیشن به‌طور پیشرونده بدتر به نظر برسد. اگر تلاش دوم سریع‌تر از اول شکست خورد، برنامه را کاملاً ببندید و بررسی کنید که آیا پردازش موتور باقی‌مانده‌ای در پس‌زمینه وجود دارد یا خیر.

علت دوم: دانلودهای ناقص

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

• راه حل: حجم فایل روی دیسک را با حجم اعلام شده در صفحه ناشر مدل مقایسه کنید. هیچ دلیل منطقی وجود ندارد که یک فایل GGUF کوچک‌تر از مقدار منتشر شده باشد. شما می‌توانید لیست فایل‌ها را با دستور ls -lh ~/jan/models/**/*.gguf مشاهده کنید.
• تایید فنی: از ترمینال برای بررسی چهار بایت اول فایل استفاده کنید: head -c 4 model.gguf | xxd. شما باید عبارت GGUF را ببینید. اگر چهار بایت اول GGUF نباشند، یعنی دانلود شما چیزی را آورده است که اصلاً مدل نیست.
• بازیابی: فایل را از داخل خودِ اپلیکیشن حذف کنید (نه از طریق سیستم فایل) تا ورودی آن نیز پاک شود، و سپس دوباره دانلود کنید.

سایر نقاط شکست

فراتر از حافظه و خرابی فایل، دو عامل دیگر نیز اغلب شبیه به توقف در بارگذاری عمل می‌کنند:

• انتخاب Backend: برنامه Jan بین Backendهای CPU و GPU انتخاب می‌کند. مستندات اشاره می‌کنند که GPU تنها زمانی ترجیح داده می‌شود که حداقل ۶ گیگابایت VRAM گزارش کند. در ماشین‌هایی با GPUهای کوچک یا شناسایی‌نشده، موتور ممکن است تلاشی برای مقداردهی اولیه کند که به‌طور خاموش شکست می‌خورد. اجبار به استفاده از CPU یک راه سریع برای تست این موضوع است؛ اگر مدل روی CPU لود شد، مدل سالم است و مشکل از Backend بوده است.
• طول پنجره زمینه (Context Length): حافظه برای زمینه پیکربندی شده در لحظه بارگذاری تخصیص می‌یابد. مدلی که در ۴,۰۹۶ توکن لود می‌شود اما در ۳۲,۷۶۸ توکن متوقف می‌شود، در واقع همان مورد کمبود حافظه است که تغییر شکل داده است. قبل از اینکه نتیجه بگیرید مدل خراب است، طول زمینه را نصف کنید و دوباره امتحان کنید.

ترتیب عملیات برای بازیابی

برای حل سیستماتیک یک توقف (Hang)، این مراحل را دنبال کنید:

۱. برنامه را کاملاً ببندید و تایید کنید که هیچ پردازش موتوری باقی نمانده است. اگر تلاش قبلی هنوز حافظه را اشغال کرده باشد، هر چیز دیگری غیرقابل اعتماد است.
۲. لاگ موتور را باز کنید و بیست خط آخر را بخوانید تا تصمیم بگیرید با کدام علت روبرو هستید.
۳. فایل را بررسی کنید: حجم را با رقم ناشر مقایسه کنید و چهار بایت اول را با GGUF چک کنید. اگر هر یک اشتباه بود، دوباره دانلود کنید.
۴. تنظیمات را تغییر دهید: طول زمینه را کاهش دهید، سپس یک کوانتش کوچک‌تر از همان مدل را امتحان کنید. یک فایل Q4 تقریباً نصف حجم یک فایل Q8 است، که اغلب تفاوت بین «جا شدن در حافظه» و «نشدن» است.
۵. Backend را روی CPU اجبار کنید به عنوان تست نهایی. اگر کار کرد، مدل سالم است و کارهای باقی‌مانده مربوط به پیکربندی GPU است.

این انتقال به سمت استنتاج محلی، بار مدیریت سیستم را بر دوش کاربر می‌اندازد. در حالی که هوش مصنوعی ابری سخت‌افزار را انتزاع (Abstract) می‌کند، AI محلی نیازمند درک دقیق از تخصیص VRAM و مدیریت پردازش‌هاست تا پایداری حفظ شود. برای جلوگیری از افت عملکرد نامحسوس در این زیرساخت‌ها، استفاده از داشبوردهای نظارتی به جای حدس و خطا توصیه می‌شود. اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.