توسط Matt Connor 2026-08-09 · به‌روزرسانی شده 2026-08-27

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

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

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

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

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

Q: چرا متغیر 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 اختصاصی خود را در درخواست ارسال میکند که جایگزین پیشفرض سرور میشود.

Q: چگونه بدون restart کردن Ollama حافظه را آزاد کنم؟

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

Ollama مدل‌ها را پس از 5 دقیقه غیرفعال می‌کند که باعث تأخیر در درخواست بعدی می‌شود. با تنظیم پارامتر keep_alive در فایل systemd، مدل را برای همیشه در RAM نگه دارید.

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

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

این تایمر 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 است. بخش عمده این اختلاف مربوط به خواندن از دیسک است؛ بنابراین اگر دایرکتوری مدل را به یک volume دوم منتقل کرده‌اید، سرعت آن volume تعیین‌کننده حداقل زمان برای هر بارگذاری سرد (cold load) است. برای اطلاع از سرعت تولید متن در هر دو طرف این وقفه، به نحوه اندازه‌گیری توکن بر ثانیه روی سیستم خود مراجعه کنید.

نگه داشتن مدل 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 اختصاصی خود را ارسال می‌کند، بر هر تنظیماتی که در سرور اعمال کرده‌اید اولویت دارد.

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

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

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

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

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

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

نکته مهم این است که این متغیر باید در محیط (environment) مناسب تنظیم شود. اجرای export OLLAMA_KEEP_ALIVE=30m در نشست SSH شما هیچ تأثیری ندارد، زیرا نصب بسته‌بندی‌شده، سرور را به‌عنوان یک سرویس systemd تحت کاربر مخصوص خود و با محیط اختصاصی آن اجرا می‌کند. 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 را جایگزین می‌کند، تنظیمات شما را دست‌نخورده باقی می‌گذارد. اگر با drop-inها و فایل‌های unit آشنا نیستید، راهنمای سرویس‌ها و تایمرهای 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 بدون GPU پیش از آنکه تصمیم بگیرید آن را به‌صورت مقیم (resident) نگه دارید، ارزش بررسی دقیق دارد. با تنظیم keep_alive روی -1، شما عملاً تصمیم گرفته‌اید که مدل، اولویت بالاتری نسبت به هر چیز دیگری در سرور داشته باشد. در یک VPS کوچک، این به معنای رقابت مستقیم حافظه با دیتابیس، اپلیکیشن وب و فرآیندهای build شماست.

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

free -h

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

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

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

دو هزینه در اینجا وجود دارد که به‌راحتی نادیده گرفته می‌شوند. طول context بیشتر، یک KV cache (حافظه کش کلید-مقدار؛ وضعیت توجه به ازای هر توکن که مدل هنگام تولید متن نگه می‌دارد) بزرگ‌تر رزرو می‌کند و این کش بخشی از حجم حافظه مقیم است. میزان بزرگی آن از num_ctx تبعیت می‌کند، بنابراین افزایش پنجره context باعث می‌شود مدل مقیم، حافظه بیشتری را در تمام طول دوره idle اشغال کند، نه فقط زمانی که در حال پاسخ‌دهی است. مقدار 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) یکی از مدل‌های موجود را برای ایجاد فضا تخلیه (unload) می‌کند. اولویت با مدلی است که درخواست فعالی ندارد؛ همچنین سیستم می‌تواند مدلی را که تایمر آن منقضی نشده است (از جمله مدلی که با -1 بارگذاری شده) حذف کند. بنابراین، مقدار منفی برای keep_alive به معنای عدم وجود زمان انتظار برای حالت بیکاری (idle 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 متغیرهای محیطی (environment variables) که نسخهٔ فعلی واقعاً می‌خواند را فهرست می‌کند که 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 اختصاصی خود را در درخواست ارسال می‌کند که جایگزین پیش‌فرض سرور می‌شود.

چگونه بدون restart کردن Ollama حافظه را آزاد کنم؟

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

#ollama #llm #self-hosted-ai #systemd #performance