آموزش ثابت نگه داشتن مدل در حافظه Ollama

چرا Ollama مدل را پس از چند دقیقه از حافظه خارج می‌کند؟

Ollama مدل را تا پنج دقیقه پس از آخرین درخواست در حافظه نگه می‌دارد و پس از آن، حافظه را آزاد می‌کند. در درخواست بعدی، سیستم مجبور است وزن‌های مدل را دوباره از دیسک بخواند و در RAM یا VRAM بارگذاری کند؛ به همین دلیل، پیش از تولید اولین توکن، تأخیری ایجاد می‌شود. به همین علت است که رابط کاربری چت یا یک دستیار برنامه‌نویسی در ابتدا سریع عمل می‌کند، مدتی ساکت می‌ماند و در پیام بعدی دوباره کند می‌شود. هیچ خرابی‌ای وجود ندارد؛ صرفاً تایمر بیکاری (idle timer) به پایان رسیده است.

این تایمر keep_alive نام دارد. این تایمر برای هر مدل به‌صورت جداگانه محاسبه می‌شود و با پایان هر درخواست، دوباره از نو شروع می‌شود. مدلی که در حال پاسخ‌دهی به یک درخواست است، هرگز از حافظه خارج نمی‌شود، زیرا سرور فقط مدل‌هایی را که هیچ درخواست فعالی ندارند، غیرفعال می‌کند. تا اوت 2026، مقدار پیش‌فرض پنج دقیقه است و برای تمام مدل‌هایی که این سرور بارگذاری می‌کند، اعمال می‌شود.

دو روش برای تنظیم keep_alive وجود دارد: در سطح درخواستِ تکی، یا به‌عنوان تنظیمات پیش‌فرض سرور. استفاده از یک فایل drop-in در systemd باعث می‌شود تنظیمات پیش‌فرض سرور پس از راه‌اندازی مجدد (reboot) باقی بمانند. این راهنما فرض می‌کند که Ollama هم‌اکنون به‌عنوان یک سرویس در حال اجراست. اگر چنین نیست، با نصب Ollama روی VPS شروع کنید و سپس به اینجا بازگردید.

کدام مدل‌ها در حال حاضر در حافظه مستقر هستند و چه زمانی منقضی می‌شوند؟

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

خروجی خالی به این معناست که هیچ مدلی بارگذاری نشده است، بنابراین درخواست بعدی هزینه کامل بارگذاری را متحمل خواهد شد. PROCESSOR به شما نشان می‌دهد که وزن‌ها در کجا قرار گرفته‌اند. 100% GPU و 100% CPU موارد واضح هستند. تقسیم‌بندی به صورت 25%/75% CPU/GPU به این معناست که مدل در VRAM جا نشده است، بنابراین بخشی از آن روی پردازنده اجرا می‌شود و سرعت تولید کندتر خواهد بود.

UNTIL شمارش معکوس است و زمان نسبی مانند 4 minutes from now را نمایش می‌دهد. اگر مدل با keep_alive منفی بارگذاری شده باشد، مقدار Forever چاپ می‌شود. در بازه زمانی کوتاه تخلیه مدل از حافظه توسط سرور، مقدار Stopping... نمایش داده می‌شود.

مجموعه ستون‌ها بین نسخه‌ها تغییر کرده است، بنابراین به جای شمارش فیلدها در اسکریپت، هدر را بخوانید. برای هرگونه عملیات خودکار، از API پرس‌وجو کنید:

curl -s http://localhost:11434/api/ps

هر ورودی شامل expires_at، یک برچسب زمانی مطلق مانند 2026-08-09T14:38:31.83753Z، و size_vram است که بخشی از آن مدل مستقر در حافظه GPU را نشان می‌دهد. مقدار size_vram برابر با 0 به این معناست که مدل روی CPU در حال اجرا است.

هزینه واقعی بارگذاری مجدد

در این مورد حدس نزنید. Ollama زمان بارگذاری را در هر پاسخ با عنوان load_duration و بر حسب نانوثانیه گزارش می‌کند.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

اولین فراخوانی، مدل را بارگذاری می‌کند، بنابراین مقدار load_duration آن بزرگ است. برای خواندن آن به ثانیه، عدد را بر 1000000000 تقسیم کنید. فراخوانی دوم در حالی اجرا می‌شود که مدل در حافظه مستقر است و عدد بسیار کوچک‌تری را گزارش می‌کند. اختلاف بین این دو عدد، هزینه‌ای است که هر کاربر پس از اتمام زمان تایمر می‌پردازد و همین موضوع دلیل اصلی تغییر keep_alive است. برای مشاهده سرعت تولید در هر دو طرف این وقفه، به نحوه اندازه‌گیری توکن بر ثانیه روی سیستم خود مراجعه کنید.

نگه داشتن مدل Ollama در حافظه پس از یک درخواست

پارامتر keep_alive را همراه با درخواست ارسال کنید. این پارامتر از لحظه پایان درخواست، برای آن مدل اعمال می‌شود.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

چهار نوع مقدار برای این پارامتر پذیرفته می‌شود:

• یک رشته زمانی: "30m"، "24h"، "90s"
• یک عدد ساده که به عنوان ثانیه خوانده می‌شود: 3600
• یک مقدار منفی، -1 یا "-1m"، به این معنی که هیچ محدودیت زمانی برای بیکاری (idle timeout) وجود نداشته باشد
• 0، به این معنی که بلافاصله پس از پایان این درخواست، مدل از حافظه خارج شود

مقدار ارسالی در درخواست، جایگزین پیش‌فرض سرور می‌شود (در هر دو جهت). این موضوع اهمیت بیشتری از آنچه به نظر می‌رسد دارد: کلاینتی که مقدار keep_alive خود را ارسال می‌کند، بر هر تنظیماتی که روی سرور اعمال کرده‌اید، اولویت دارد.

شما همچنین می‌توانید یک مدل را بدون تولید هیچ خروجی، بارگذاری کنید. فقط نام مدل را ارسال کنید. سرور آن را بارگذاری کرده و یک پاسخ خالی با کد "done": true برمی‌گرداند.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

این دستوری است که باید پس از راه‌اندازی مجدد (reboot) یا پس از دریافت (pull) یک مدل جدید اجرا کنید تا اولین درخواست واقعی کاربر، منتظر بارگذاری مدل نماند. رابط خط فرمان (CLI) نیز همین کار را با یک فلگ انجام می‌دهد:

ollama run --keepalive 30m qwen3:8b "hello"

نگه داشتن مدل در حافظه به صورت پیش‌فرض با OLLAMA_KEEP_ALIVE

سرور در زمان راه‌اندازی، مقدار OLLAMA_KEEP_ALIVE را می‌خواند و برای هر مدلی که مقدار اختصاصی خود را نداشته باشد، از آن استفاده می‌کند. این متغیر همان فرمت‌های فیلد درخواست را می‌پذیرد، بنابراین مقادیر 30m، 3600 و -1 همگی معتبر هستند.

نکته مهم این است که این متغیر باید در محیط (environment) مناسب تنظیم شود. اجرای دستور export OLLAMA_KEEP_ALIVE=30m در نشست SSH شما هیچ اثری ندارد، زیرا نصب بسته‌بندی‌شده، سرور را به عنوان یک سرویس systemd تحت کاربر مخصوص خود و با محیط (environment) مجزا اجرا می‌کند. نشست ورود (login shell) شما و آن سرویس هیچ ارتباطی با هم ندارند. این رایج‌ترین دلیلی است که باعث می‌شود تنظیمات اعمال‌شده نادیده گرفته شوند.

پایداری پس از راه‌اندازی مجدد با استفاده از drop-in در systemd

sudo systemctl edit ollama.service

ویرایشگر با دو علامت کامنت باز می‌شود. تنظیمات خود را بین این دو علامت وارد کنید: systemd هر چیزی را که زیر علامت دوم بنویسید، نادیده می‌گیرد.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

ذخیره‌سازی، فایل /etc/systemd/system/ollama.service.d/override.conf را ایجاد می‌کند. این یک فایل drop-in است و نه ویرایش مستقیم unit اصلی؛ بنابراین ارتقای بسته Ollama که فایل ollama.service را جایگزین می‌کند، تنظیمات شما را دست‌نخورده باقی می‌گذارد. اگر با فایل‌های unit و drop-in آشنا نیستید، راهنمای سرویس‌ها و تایمرهای systemd جزئیات فنی آن را توضیح داده است.

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

دستور آخر، محیطی را که سرویس واقعاً در آن اجرا خواهد شد، نمایش می‌دهد. اگر OLLAMA_KEEP_ALIVE=30m در آن خروجی وجود ندارد، یعنی drop-in اعمال نشده است. علت این موضوع تقریباً همیشه نبود هدر [Service] یا نوشتن دستورات در زیر علامت دوم است. فرآیند راه‌اندازی مجدد باعث تخلیه تمامی مدل‌های بارگذاری‌شده از حافظه می‌شود، بنابراین درخواست بعدی یک cold load خواهد بود. با استفاده از دستور preload که در بالا ذکر شد، مدل را دوباره گرم (warm) کنید.

هزینه‌های نگهداشت مدل در حافظه

ستون SIZE در ollama ps نشان‌دهنده حافظه‌ای است که در تمام طول پنجره idle اشغال شده است، نه فقط در زمان پردازش یک درخواست. یک مدل 8B با کوانتایزیشن 4-bit حدود 5 تا 6 گیگابایت فضا اشغال می‌کند. مدل 27B بحث متفاوتی دارد و محاسبات حافظه برای اجرای آن روی یک VPS فقط با CPU موضوعی است که پیش از تصمیم‌گیری برای نگهداشت دائمی مدل در حافظه، باید بررسی شود. با تنظیم keep_alive روی -1، شما عملاً تصمیم گرفته‌اید که مدل نسبت به هر چیز دیگری در سرور اولویت داشته باشد. در یک VPS کوچک، این به معنای رقابت مستقیم با دیتابیس، وب‌اپلیکیشن و کارهای build شماست.

به جای اعتماد به تخمین‌ها، اعداد واقعی را مانیتور کنید. این دستور را در حالی که مدل بارگذاری شده اجرا کنید، و سپس دوباره پس از ollama stop:

free -h

ستون available نشان‌دهنده حافظه‌ای است که کرنل هنوز می‌تواند به یک پروسه جدید اختصاص دهد. در سرورهای دارای GPU انویدیا، nvidia-smi همین وضعیت را در VRAM نشان می‌دهد. اگر حافظه سرور تمام شود، کرنل برای بازیابی منابع، یک پروسه را می‌کشد (kill):

sudo dmesg -T | grep -i "out of memory"

خطی که نام ollama را ذکر می‌کند به این معناست که سرور مدل قربانی شده است. خطی که نام دیتابیس شما را ذکر می‌کند به این معناست که مدل برنده شده و سرویس مهم شما از دست رفته است. هر دو نتیجه از یک تصمیم واحد ناشی می‌شوند: یک پنجره keep-alive طولانی روی سروری که فضای خالی کافی ندارد.

دو هزینه در اینجا وجود دارد که نادیده گرفتن آن‌ها آسان است. طول context بیشتر، KV cache (کش کلید-مقدار، یعنی وضعیت attention به ازای هر توکن که مدل هنگام تولید حفظ می‌کند) بزرگ‌تری را رزرو می‌کند و این کش بخشی از حجم حافظه resident است. مقدار OLLAMA_NUM_PARALLEL بزرگ‌تر از 1، این کش را به ازای هر اسلات موازی یک‌بار رزرو می‌کند. اگر قصد دارید به چندین نفر از طریق یک مدل سرویس دهید، حافظه را بر اساس اسلات‌ها محاسبه کنید، نه فقط بر اساس وزن‌های مدل.

یک مقدار پیش‌فرض معقول: یک مدل روی سروری که فضای کافی دارد می‌تواند از -1 استفاده کند. در یک سرور اشتراکی، باید از پنجره‌ای استفاده کنید که فواصل بین درخواست‌های شما را پوشش دهد، مانند 30m، تا وقتی کارتان تمام شد، حافظه آزاد شود.

تخلیه فوری مدل

ollama stop qwen3:8b

این دستور بدون خروجی بازمی‌گردد و مدل از ollama ps حذف می‌شود. اگر نامی را وارد کنید که بارگذاری نشده باشد، با couldn't find model "qwen3:8b" to stop مواجه خواهید شد. فرمت API یک درخواست بدون prompt است که در آن keep_alive روی 0 تنظیم شده است:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

پاسخ شامل "done_reason": "unload" است. از این روش به‌جای راه‌اندازی مجدد سرویس استفاده کنید. دستور systemctl restart ollama نیز حافظه را آزاد می‌کند، اما تمام مدل‌های دیگر بارگذاری‌شده را حذف کرده و هر درخواستی که در حال اجرا باشد را متوقف می‌کند.

اجرای بیش از یک مدل روی یک سرور

OLLAMA_MAX_LOADED_MODELS تعداد مدل‌هایی که همزمان در حافظه بارگذاری می‌شوند را محدود می‌کند و از اوت 2026، مقدار پیش‌فرض آن سه مدل به ازای هر GPU یا سه مدل برای سیستم‌های فاقد GPU است. این محدودیت بر اساس تعداد مدل‌ها اعمال می‌شود، اما محدودیت اصلی در واقع حافظه است؛ بنابراین ممکن است پیش از رسیدن به عدد سه، فضای کافی برای یک مدل بزرگ دوم وجود نداشته باشد.

هنگامی که درخواستی برای یک مدل جدید ارسال می‌شود و حافظه کافی برای آن وجود ندارد، زمان‌بند (scheduler) یکی از مدل‌های موجود در حافظه را تخلیه می‌کند تا فضا باز شود. اولویت با مدلی است که درخواست فعالی ندارد؛ همچنین مدل‌هایی که تایمر آن‌ها منقضی نشده است، از جمله مدل‌هایی که با -1 بارگذاری شده‌اند، ممکن است تخلیه شوند. بنابراین مقدار منفی برای keep_alive به معنای عدم وجود زمان انتظار (timeout) برای مدل‌های بیکار است. این تنظیم، وزن‌های مدل را در برابر درخواست مدل دیگر ثابت (pin) نمی‌کند.

این تصمیم در سطح debug ثبت می‌شود. یک خط Environment="OLLAMA_DEBUG=1" دوم به همان فایل drop-in اضافه کنید، سرویس را restart کنید و لاگ‌ها را بررسی کنید:

sudo journalctl -u ollama -f

مشاهده خطی درباره تخلیه یک runner برای ایجاد فضا، در کنار درخواستی که باعث آن شده است، نشان می‌دهد که این دو مدل در کنار هم روی این دستگاه جا نمی‌شوند. راه حل این است که تعداد مدل‌های روی این دستگاه را کاهش دهید، یا برای مدلی که باید سریع پاسخ دهد یک بازه زمانی طولانی در نظر بگیرید و برای مدلی که به ندرت فراخوانی می‌کنید از 0 استفاده کنید.

راهنمایی‌هایی که فراتر از نسخه بعدی معتبر می‌مانند

نرم‌افزار Ollama به‌طور مرتب منتشر می‌شود و مقادیر پیش‌فرض آن تغییر می‌کنند؛ بنابراین به‌جای حفظ کردن اعداد، همیشه نسخه‌ای که در اختیار دارید را بررسی کنید:

ollama --version
ollama serve --help

ollama serve --help متغیرهای محیطی که آن نسخه خاص می‌خواند را فهرست می‌کند، که OLLAMA_KEEP_ALIVE نیز در میان آن‌هاست. دو قانون در تمامی نسخه‌ها ثابت مانده‌اند و می‌توانید با اطمینان بر آن‌ها تکیه کنید. مقداری که در درخواست (request) ارسال می‌شود، بر مقدار پیش‌فرض سرور اولویت دارد. همچنین ollama ps منبع نهایی حقیقت درباره آنچه بارگذاری شده است محسوب می‌شود، فارغ از اینکه فایل پیکربندی چه چیزی را نشان می‌دهد.

اگر یک ویرایشگر یا عامل (agent) سرور شما را مدیریت می‌کند، پیش از مقصر دانستن سرور، بررسی کنید که آن کلاینت چه چیزی ارسال می‌کند. هدایت یک عامل کدنویسی به سمت سرور Ollama شخصی توضیح می‌دهد که تنظیمات آن درخواست‌ها در کجا قرار دارند.

FAQ

چرا Ollama مدل من را پس از 5 دقیقه از حافظه خارج می‌کند؟

5 دقیقه مقدار پیش‌فرض keep_alive است؛ تایمر بیکاری که Ollama پس از پایان هر درخواست شروع می‌کند. با اتمام این زمان، سرور وزن‌های مدل را از حافظه آزاد می‌کند، بنابراین درخواست بعدی باعث بارگذاری مجدد آن‌ها از دیسک می‌شود و آن وقفه، همان زمانی است که شما احساس می‌کنید. برای افزایش این زمان در یک درخواست خاص، "keep_alive": "30m" را در بدنه JSON ارسال کنید، یا برای کل سرور از متغیر محیطی OLLAMA_KEEP_ALIVE استفاده کنید.

چگونه یک مدل Ollama را به‌طور دائم در حافظه نگه دارم؟

از یک مقدار منفی استفاده کنید: "keep_alive": -1 در درخواست، یا OLLAMA_KEEP_ALIVE=-1 برای سرور. در این حالت ollama ps مقدار Forever را در ستون UNTIL نشان می‌دهد. این کار فقط تایمر بیکاری را حذف می‌کند. اگر مدل دیگری درخواست شود و حافظه کم باشد، زمان‌بند (scheduler) همچنان این مدل را برای ایجاد فضای خالی از حافظه خارج می‌کند.

چرا متغیر OLLAMA_KEEP_ALIVE نادیده گرفته می‌شود؟

محل تنظیم آن را بررسی کنید. دستور systemctl show ollama --property=Environment را اجرا کنید؛ اگر متغیر در خروجی نباشد، سرور هرگز آن را دریافت نکرده است، زیرا متغیری که در shell شما export شده به سرویس systemd نمی‌رسد. آن را با sudo systemctl edit ollama.service تنظیم کنید، سپس sudo systemctl daemon-reload و sudo systemctl restart ollama را اجرا کنید. دلیل دیگر، کلاینتی است که keep_alive اختصاصی خود را در درخواست ارسال می‌کند که جایگزین مقدار پیش‌فرض سرور می‌شود.

چگونه بدون ری‌استارت کردن Ollama حافظه را آزاد کنم؟

ollama stop qwen3:8b آن مدل خاص را بلافاصله از حافظه خارج می‌کند و سرور و سایر مدل‌های بارگذاری‌شده را فعال نگه می‌دارد. از طریق API، درخواستی بدون prompt و با "keep_alive": 0 ارسال کنید؛ پاسخ با "done_reason": "unload" بازمی‌گردد. با دستور ollama ps تأیید کنید که مدل دیگر نباید در لیست باشد.