Ollama برای طول زمینه (Context Length) بسیار بیشتری از آنچه واقعاً استفاده می‌کنید، حافظه رم (RAM) رزرو می‌کند. اگر مدلی با پنجره زمینه ۳۲ هزار توکن بارگذاری شود در حالی که پرسش‌ها و پاسخ‌های شما به‌ندرت از چند هزار توکن فراتر می‌روند، بیشتر آن ظرفیت بی‌استفاده می‌ماند. اما همین ظرفیت بی‌استفاده هم هزینه حافظه دارد.
Ollama باید برای طول زمینه پیکربندی‌شده یک کش کلید-مقدار (KV Cache) تخصیص دهد و این کش می‌تواند چند گیگابایت روی مدل دانلودشده اضافه کند. این مشکل فقط به Ollama محدود نیست؛ همان مسئله بنیادی برای llama.cpp و مدل‌های GGUF که از طریق موتور llama.cpp در LM Studio اجرا می‌شوند نیز صدق می‌کند. روی ماشینی با رم کمتر، می‌توانید پنجره زمینه را به مقداری نزدیک به مصرف واقعی کاهش دهید و حافظه بسیار بیشتری برای سایر کارها آزاد کنید.
Ollama برای زمینه‌ای که ممکن است هرگز استفاده نکنید، حافظه رزرو می‌کند
طول زمینه یک ظرفیت حداکثری است، نه اندازه‌گیری آنچه پرسش فعلی شما مصرف می‌کند. این مقدار شامل اعلان سیستمی (System Prompt)، تاریخچه گفتگو، ورودی فعلی و پاسخ تولیدشده می‌شود. برای مثال، ممکن است مدلی را برای ۳۲ هزار توکن پیکربندی کنید و در یک گفتگوی عادی فقط ۳ هزار توکن استفاده کنید، اما Ollama هنگام بارگذاری همچنان مدل را برای حد بزرگ‌تر آماده می‌کند.
بیشتر این حافظه اضافی به KV Cache می‌رود. این کش محاسبات مربوط به توکن‌هایی را که مدل قبلاً پردازش کرده ذخیره می‌کند تا مجبور نباشد کل گفتگو را دوباره پردازش کند. پنجره زمینه بزرگ‌تر به فضای بیشتری برای این محاسبات نیاز دارد. در Ollama و سایر رانتایم‌های مبتنی بر llama.cpp، اندازه این تخصیص به ظرفیت پیکربندی‌شده گره خورده است، نه به طول پرسش کوتاهی که بعداً می‌فرستید.
اندازه مدل دانلودشده این موضوع را به‌روشنی نشان نمی‌دهد. برای مثال، یک مدل Q4 پنج گیگابایتی می‌گوید وزن‌های کوانتیزه‌شده چقدر فضا اشغال می‌کنند، اما Ollama همچنان به بافرهای محاسباتی (Compute Buffers) و KV Cache نیاز دارد. بنابراین می‌توانید اندازه وزن‌های مدل را کاهش دهید و همچنان چند گیگابایت را به خاطر یک تنظیم زمینه بیش‌ازحد بزرگ از دست بدهید.
روی Apple Silicon، این تخصیص از همان استخر حافظه یکپارچه (Unified Memory) انجام می‌شود که macOS و هر برنامه دیگری از آن استفاده می‌کنند. روی سیستمی با پردازنده گرافیکی اختصاصی، معمولاً حافظه گرافیکی (VRAM) را اشغال می‌کند و وقتی VRAM تمام شود می‌تواند به حافظه سیستم یا حافظه اشتراکی سرریز کند. زمینه بی‌استفاده در این حالت حافظه را از سایر برنامه‌ها می‌گیرد یا بخشی از مدل را به حافظه کندتر می‌راند، بدون آنکه کمکی به درخواست‌های معمول شما کند. پیش‌فرض‌های Ollama روی سیستم‌هایی با VRAM بیشتر این وضعیت را بدتر می‌کنند. این برنامه در حال حاضر برای کمتر از ۲۴ گیبی‌بایت زمینه ۴K، بین ۲۴ تا ۴۸ گیبی‌بایت زمینه ۳۲K و برای ۴۸ گیبی‌بایت یا بیشتر زمینه ۲۵۶K اختصاص می‌دهد.
محدودیت زمینه را بر اساس درخواست‌های واقعی انتخاب کنید
به آن اندازه که فکر می‌کنید به زمینه بزرگ نیاز ندارید. API Ollama اعداد مفیدی برای انتخاب پنجره زمینه ارائه می‌دهد. پاسخ‌های آن شامل prompt_eval_count است که توکن‌های ورودی را گزارش می‌کند و eval_count که توکن‌های تولیدشده را گزارش می‌دهد. می‌توانید این اعداد را در چند گفتگو بررسی کنید تا نقطه شروع بهتری از حداکثر تبلیغ‌شده مدل به دست آورید. تبادل‌های طولانی‌تر خود را هم در این مقایسه بگنجانید تا همه‌چیز را حول یک پرسش کوتاه تنظیم نکنید.
برای گفتگوهای چند هزار توکنی که در اینجا توصیف شد، پیشنهاد می‌شود ابتدا یک پنجره ۸K را آزمایش کنید. این مقدار برای پرسش‌های پیگیری و یک پاسخ غیرعادی طولانی جا می‌گذارد، بدون آنکه فوراً به ۳۲K بپرید. باید مدل‌های استدلالی (Reasoning Models) را متفاوت در نظر بگیرید، چون آن‌ها پیش از پاسخ نهایی توکن‌های تفکر تولید می‌کنند. Ollama این تفکر را جداگانه نمایش می‌دهد، بنابراین پاسخی که در رابط چت می‌بینید لزوماً همه چیزهایی نیست که مدل تولید می‌کند. باید برای آن خروجی هم بودجه حافظه در نظر بگیرید.
می‌توانید لغزنده زمینه را در اپلیکیشن Ollama تغییر دهید یا در یک نشست ترمینال دستور /set parameter num_ctx 8192 را وارد کنید. برای یک تنظیم پایدار مخصوص مدل، می‌توانید از Modelfile استفاده کنید که از PARAMETER num_ctx 8192 پشتیبانی می‌کند. پنجره کوچک‌تر را با گفتگویی آزمایش کنید که به اطلاعات پیام‌های قبلی نیاز دارد. وقتی برش (Truncation) فعال باشد، Ollama پیام‌های قدیمی‌تر را برای رسیدن به محدودیت حذف می‌کند و پیام‌های سیستمی و آخرین پیام را حفظ می‌کند.
دقت کش و درخواست‌های موازی هم نیاز به توجه دارند
Ollama راه دیگری هم برای کاهش مصرف حافظه دارد: ذخیره کش گفتگو با دقت عددی کمی کمتر. به این کار کوانتیزه‌سازی کش (Cache Quantization) می‌گویند. گزینه ۸ بیتی که معمولاً Q8 نامیده می‌شود، تقریباً نصف حافظه کش پیش‌فرض را استفاده می‌کند. محدودیت گفتگوی شما ثابت می‌ماند، هرچند اعداد ذخیره‌شده در کش کمی کم‌دقت‌تر هستند. این صرفه‌جویی فقط به کش اعمال می‌شود، بنابراین نیاز حافظه کل مدل را نصف نمی‌کند.
Q8 گزینه‌ای است که ابتدا باید امتحان کرد، چون اثر آن بر کیفیت پاسخ معمولاً ناچیز است. گزینه ۴ بیتی با نام Q4 حافظه بیشتری ذخیره می‌کند و کش را به حدود یک‌چهارم اندازه اصلی می‌رساند. اما همان‌طور که انتظار دارید، دقت بیشتری از دست می‌رود که می‌تواند بر پاسخ‌ها به‌ویژه در گفتگوهای طولانی‌تر اثر بگذارد. پیش از فعال نگه‌داشتن هر یک از این تنظیمات، پاسخ‌ها را با چند پرسش آشنا مقایسه کنید.
همچنین باید بررسی کنید Ollama برای پردازش هم‌زمان چند درخواست پیکربندی شده است. اگر اجازه می‌دهید چهار گفتگو هم‌زمان پاسخ تولید کنند، فضای کش خود را هدر می‌دهید. اگر چند نفر یا چند برنامه از سرور محلی شما استفاده می‌کنند، می‌توانید این قابلیت را فعال نگه دارید. برای استفاده‌ای مثل فرستادن یک پرسش و انتظار برای پاسخ، دلیل کمی برای رزرو آن ظرفیت اضافی وجود دارد. Ollama در حال حاضر به‌صورت پیش‌فرض یک درخواست هم‌زمان را پردازش می‌کند، بنابراین فقط در صورت افزایش آن باید این تنظیم را دوباره بررسی کنید.
استنتاج‌های دیگر را هم امتحان کنید
Ollama در اجرای مدل‌ها کار بسیار خوبی انجام می‌دهد، اما ممکن است بخواهید گزینه‌های دیگر را هم بررسی کنید. به‌گفته نویسنده، LM Studio برای او بسیار بهتر از Ollama بوده است. همچنین تجربه‌های خوبی با Docker Model Runner و BaseRT داشته است.