تنظیم OLLAMA_NUM_PARALLEL و OLLAMA_MAX_QUEUE در Ollama

هنگام تولید پاسخ توسط اولین درخواست Ollama، چه اتفاقی برای درخواست دوم می‌افتد

همزمانی (concurrency) در Ollama توسط سه متغیر محیطی تعیین می‌شود و به‌صورت پیش‌فرض، هر مدل بارگذاری‌شده در لحظه فقط به یک درخواست پاسخ می‌دهد. درخواست دوم رد نمی‌شود و پاسخ ناقص نیز دریافت نمی‌کند؛ بلکه در یک صف منتظر می‌ماند تا یک جایگاه (slot) آزاد شود و سپس با سرعت عادی اجرا می‌گردد.

یک درخواست ورودی سه سرنوشت احتمالی دارد: یا بلافاصله در یک جایگاه آزاد شروع می‌شود، یا در صف منتظر می‌ماند، و یا اگر صف پر باشد، سرور با خطای HTTP 503 آن را رد می‌کند. اینکه کدام حالت رخ دهد، توسط OLLAMA_NUM_PARALLEL، OLLAMA_MAX_QUEUE و OLLAMA_MAX_LOADED_MODELS تعیین می‌شود.

تنظیمات پیش‌فرض امن هستند و همین موضوع دلیل آن است که کاربران دوم گزارش می‌دهند سرور "هنگ" کرده است، در حالی که هیچ خرابی‌ای وجود ندارد. افزودن جایگاه‌ها تنها با تغییر دو خط انجام می‌شود. بخش چالش‌برانگیز، حافظه است. هر جایگاه موازی به کش کلید/مقدار (KV cache) اختصاصی خود نیاز دارد؛ یعنی همان بلوک حافظه‌ای که مدل برای توکن‌هایی که قبلاً پردازش کرده است، نگه می‌دارد. اگر بدون افزایش VRAM (حافظه ویدیویی روی GPU) جایگاه‌ها را اضافه کنید، پاسخ‌های کند به خطای عدم بارگذاری مدل تبدیل می‌شوند.

پارامترهای OLLAMA_NUM_PARALLEL، OLLAMA_MAX_QUEUE و OLLAMA_MAX_LOADED_MODELS چه چیزی را کنترل می‌کنند

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

• OLLAMA_NUM_PARALLEL مشخص می‌کند که یک مدل بارگذاری‌شده، چند درخواست را به‌طور همزمان پردازش می‌کند. مقدار پیش‌فرض 1 است، بنابراین درخواست‌ها یکی پس از دیگری پاسخ داده می‌شوند.
• OLLAMA_MAX_LOADED_MODELS مشخص می‌کند که چند مدل مختلف به‌طور همزمان در حافظه باقی می‌مانند. مقدار پیش‌فرض 0 است که به این معنی است که Ollama خود تصمیم می‌گیرد: سه مدل برای هر GPU، و سه مدل برای سیستمی که GPU ندارد.
• OLLAMA_MAX_QUEUE مشخص می‌کند که چند درخواست می‌توانند در صف انتظار بمانند. مقدار پیش‌فرض 512 است. درخواستی که هنگام پر بودن صف برسد، بلافاصله رد می‌شود.

بدترین حالت مصرف حافظه، حاصل‌ضرب دو مورد اول است. دو مدل بارگذاری‌شده با چهار اسلات برای هر کدام، به معنای هشت تخصیص اسلات برای KV cache است که همگی همزمان در حافظه فعال هستند و Ollama تلاش می‌کند این مقدار را تأمین کند. در سیستمی با یک GPU، معمولاً بهتر است یک مدل را نگه دارید و به آن اسلات اختصاص دهید، زیرا محاسبات آن به‌سادگی در ذهن قابل انجام است.

چرا هر اسلات موازی هزینه VRAM دارد

هنگامی که Ollama یک مدل را بارگذاری می‌کند، یک پردازش runner مجزا را اجرا می‌نماید. دو آرگومانی که به آن ارسال می‌کند در اینجا اهمیت دارند: -c که کل کانتکستی است که runner برای آن کش KV تخصیص می‌دهد، و -np که تعداد توالی‌های موازی است. Ollama مقدار -c را برابر با طول کانتکست هر درخواست ضرب‌در تعداد اسلات‌ها قرار می‌دهد. سپس runner این مقدار کل را به‌طور مساوی بین اسلات‌ها تقسیم می‌کند تا هر درخواست همچنان همان طول کانتکستی را که درخواست کرده‌اید، دریافت کند.

این تمام محدودیت موجود است و به همین دلیل است که موازی‌سازی رایگان نیست. تغییر از یک اسلات به چهار اسلات، چهار برابر کش KV بیشتری در همان طول کانتکستِ هر درخواست طلب می‌کند. هیچ چیزی بین اسلات‌ها به اشتراک گذاشته نمی‌شود و سهم یک اسلات بیکار به اسلات مشغول قرض داده نمی‌شود، زیرا این تقسیم‌بندی هنگام شروع runner ثابت می‌شود.

شما می‌توانید اعداد واقعی را به‌جای اعدادی که قصد تنظیم آن‌ها را داشتید، بخوانید:

journalctl -u ollama --no-pager -n 500 | grep "starting llama-server"

آن خط شامل خط فرمان کامل runner، از جمله -c و -np است. اگر پس از تنظیم متغیر، مقدار -np برابر با 1 باشد، تنظیمات به سرور نمی‌رسد و بخش بعدی دلیل آن را توضیح می‌دهد.

اگر وزن‌های مدل به همراه آن کش KV در VRAM جا نشوند، Ollama برخی لایه‌ها را به RAM سیستم منتقل می‌کند و آن لایه‌ها روی CPU اجرا می‌شوند. لایه‌های CPU بسیار کندتر از لایه‌های GPU هستند، بنابراین این کار باعث کندتر شدن هر درخواست می‌شود، از جمله همان تک درخواستی که با آن شروع کرده بودید. بنابراین، افزایش موازی‌سازی می‌تواند به‌جای افزایش throughput، آن را کاهش دهد.

ollama ps

ستون PROCESSOR زمانی که کل مدل در حافظه جا می‌شود، مقدار 100% GPU را نشان می‌دهد. تقسیمی مانند 35%/65% CPU/GPU به این معنی است که بخشی از مدل روی CPU در حال اجراست. ستون SIZE شامل کش KV است، بنابراین با افزایش تعداد اسلات و بارگذاری مجدد مدل، این مقدار رشد می‌کند. مقدار OLLAMA_NUM_PARALLEL را افزایش دهید، سرویس را restart کنید، یک درخواست بفرستید و دوباره ollama ps را اجرا کنید: این هزینه حافظه تغییر شماست که به‌جای حدس زدن، اندازه‌گیری شده است.

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

نحوه تنظیم این متغیرها به‌گونه‌ای که پس از reboot باقی بمانند

در لینوکس، Ollama به‌عنوان یک سرویس systemd اجرا می‌شود. اجرای export OLLAMA_NUM_PARALLEL=4 در shell شما هیچ تغییری ایجاد نمی‌کند، زیرا systemd سرویس را با محیط (environment) اختصاصی خود شروع می‌کند و shell شما را نمی‌بیند. از یک فایل drop-in استفاده کنید.

sudo systemctl edit ollama.service

محتوای زیر را در ویرایشگری که باز می‌شود اضافه کنید:

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_MAX_QUEUE=32"

سپس تنظیمات را reload و سرویس را restart کنید:

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

دستور systemctl show آنچه را که systemd به پردازش تحویل می‌دهد، چاپ می‌کند. اگر متغیر شما در آنجا وجود ندارد، فایل drop-in ذخیره نشده یا مرحله daemon-reload انجام نشده است. این موضوع را از سمت خودِ سرور نیز تأیید کنید:

journalctl -u ollama --no-pager | grep "server config" | tail -1

Ollama کل محیط خود را در زمان شروع به کار در خطی که پیام آن server config است، لاگ می‌کند. آن نقشه (map) حقیقت محض است. این سریع‌ترین راه برای پایان دادن به بحث درباره اعمال شدن یا نشدن یک متغیر است.

مدلی که از قبل بارگذاری شده است، تعداد slotهایی را که با آن شروع شده حفظ می‌کند، زیرا این مقدار در زمان راه‌اندازی در پردازش runner ثابت می‌شود. restart بالا همه چیز را unload می‌کند، بنابراین درخواست بعدی، مدل را با تنظیمات جدید بارگذاری کرده و یک بار هزینه زمان بارگذاری را پرداخت می‌کند. اینکه یک مدل پس از آن چه مدت در حافظه باقی می‌ماند، یک کنترل جداگانه است که در نگه داشتن مدل Ollama در حافظه بین درخواست‌ها به آن پرداخته شده است.

وضعیت‌های served، queued و refused از دیدگاه کلاینت

چندین درخواست را به‌طور هم‌زمان ارسال کرده و زمان‌بندی آن‌ها را اندازه‌گیری کنید. دستور زیر هشت درخواست استریم را به‌صورت موازی اجرا کرده و وضعیت و زمان‌بندی هر کدام را چاپ می‌کند:

for i in $(seq 1 8); do
  curl -s -o /dev/null \
    -w "req$i http=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
    http://127.0.0.1:11434/api/generate \
    -d '{"model":"llama3.2:3b","prompt":"Explain what a KV cache is.","stream":true}' &
done
wait

ttfb زمان رسیدن اولین بایت از استریم است که به زمان رسیدن اولین توکن (TTFT) بسیار نزدیک است، زیرا اولین بخش استریم‌شده حاوی اولین توکن است.

Served (سرویس‌شده) به‌صورت موازی. هر درخواست، ttfb مشابهی را گزارش می‌دهد و total برای همه آن‌ها به‌طور هم‌زمان افزایش می‌یابد. GPU بین اسلات‌های در حال اجرا به اشتراک گذاشته می‌شود، بنابراین هر پاسخ نسبت به زمانی که به‌تنهایی اجرا می‌شد کندتر است، اما تعداد بیشتری از آن‌ها در هر دقیقه تکمیل می‌شوند. این همان وضعیتی است که با افزایش OLLAMA_NUM_PARALLEL برای آن هزینه می‌کنید.

Queued (در صف انتظار). درخواست‌های اول به‌سرعت پاسخ داده می‌شوند و درخواست‌های بعدی، ttfb بزرگی را نشان می‌دهند که پس از آن تولید متن به‌صورت عادی انجام می‌شود. این تأخیر مربوط به صف است، نه مدل. کاربری که پنجره چت را مشاهده می‌کند، یک وقفه طولانی و خالی را می‌بیند و سپس متن با سرعت کامل ظاهر می‌شود. این الگو—شروع کند و سپس سرعت بالا—نشانه وجود صف است، نه بارگذاری بیش از حد GPU.

Refused (ردشده). کلاینت تقریباً بلافاصله http=503 را دریافت می‌کند و بدنه پاسخ به این صورت است:

{"error":"server busy, please try again.  maximum pending requests exceeded"}

این پیام به این معناست که در لحظه رسیدن درخواست، صف پر بوده است. این پیام هیچ ارتباطی به VRAM یا خودِ مدل ندارد.

یک محدودیت صادقانه: Ollama عمق صف را منتشر نمی‌کند. ollama ps و اندپوینت /api/ps مدل‌های بارگذاری‌شده را گزارش می‌دهند، نه درخواست‌هایی که در انتظار هستند. بنابراین شما باید صف را از سمت کلاینت و با مشاهده زمان رسیدن اولین بایت اندازه‌گیری کنید، یا پاسخ‌های 503 را در هر ابزاری که جلوی سرویس قرار دارد، شمارش کنید.

چرا تنظیم MAX_QUEUE روی مقادیر کمتر اغلب انتخاب بهتری است

یک صف با اندازه 512 بزرگ به نظر می‌رسد، اما در یک slot واحد تقریباً بی‌فایده است. درخواست 300 باید پشت 299 نسل (generation) کامل منتظر بماند. این زمان در بهترین حالت چند دقیقه است. هر کلاینت HTTP خیلی زودتر از آن زمان منصرف می‌شود، بنابراین کلاینت با خطای timeout مواجه می‌شود که هیچ اطلاعاتی درباره علت مشکل نمی‌دهد و سیستم مانیتورینگ شما نیز هشداری دریافت نمی‌کند.

صف را تقریباً روی مقداری تنظیم کنید که سرور شما بتواند در بازه زمانی timeout کلاینت پردازش کند؛ در این صورت، سرریز صف بلافاصله به خطای 503 تبدیل می‌شود. خطای 503 مفید است: یک reverse proxy می‌تواند آن را دوباره تلاش (retry) کند، کلاینت می‌تواند عقب‌نشینی (back off) کند، داشبورد می‌تواند آن را شمارش کند و یک انسان می‌تواند آن را بخواند. این عدد را بر اساس اندازه‌گیری‌های خود محاسبه کنید. اگر یک نسل حدود 10 ثانیه طول می‌کشد و کلاینت شما 60 ثانیه منتظر می‌ماند، در این بازه حدود 6 درخواست در هر slot قابل پردازش است و صفی عمیق‌تر از این مقدار، تنها منجر به ایجاد timeout می‌شود.

چه زمانی باید یک صف (Queue) پیش از Ollama قرار داد

صف داخلی Ollama از نوع FIFO (اولین ورودی، اولین خروجی) است و هیچ شناختی از هویت فراخواننده ندارد. برای حالتی که یک برنامه با یک سرور در ارتباط است، این کافی است و افزودن زیرساخت اضافی تنها باعث ایجاد نقاط شکست جدید می‌شود. زمانی که یکی از موارد زیر صادق باشد، باید از یک لایه واسط استفاده کنید:

• نیاز به اولویت‌بندی دارید. یک چت تعاملی نباید پشت یک عملیات پردازش دسته‌ای (Batch) منتظر بماند. صف Ollama اولویتی ندارد، بنابراین کارهای دسته‌ای باید خارج از آن نگهداری شده و به‌آرامی به سیستم تزریق شوند.
• نیاز به برقراری عدالت (Fairness) دارید. یک کلاینت می‌تواند به‌تنهایی صف را پر کند و باعث شود سایرین با خطای 503 مواجه شوند.
• نیاز دارید که درخواست‌ها پس از راه‌اندازی مجدد (Restart) باقی بمانند. صف در حافظه سرور قرار دارد. با ری‌استارت کردن Ollama، تمام درخواست‌های در انتظار از بین می‌روند.
• نیاز به مکانیزم واقعی تلاش مجدد (Retry) با قابلیت Backoff دارید که در جایی ثبت شده باشد تا بتوانید بعداً آن را بررسی کنید.

نسخه سبک، استفاده از یک reverse proxy است. در nginx، پارامتر limit_conn تعداد اتصالات همزمان را محدود می‌کند و limit_req نرخ ورود درخواست‌ها به ازای هر کلاینت را کنترل می‌کند؛ بنابراین درخواست‌های مازاد در سطح پروکسی رد می‌شوند و هرگز به صف Ollama نمی‌رسند. نسخه سنگین، استفاده از یک صفِ کار (Job Queue) به همراه یک دیتابیس در مقابل یک Worker است که Ollama را فراخوانی می‌کند؛ این همان چیزی است که وقتی درخواست‌ها باید پس از ری‌استارت شدن فرآیند باقی بمانند، به آن نیاز دارید. تعیین ابعاد این سیستم برای ترافیک واقعی، خود یک چالش است: برنامه‌ریزی برای یک LLM خودمیزبان جهت کاربران همزمان محاسبات مربوط به آن را بررسی می‌کند و اجرای Ollama روی یک VPS نصب پایه که این متغیرها بر اساس آن فرض شده‌اند را پوشش می‌دهد.

زمانی که پاسخ صادقانه، استفاده از یک سرور متفاوت است

محدودیتی وجود دارد که نمی‌توانید با تغییر تنظیمات از آن عبور کنید. Ollama هنگام بارگذاری مدل، حافظه نهان KV را به اسلات‌های ثابت و برابر تقسیم می‌کند. حافظه یک اسلات بیکار نمی‌تواند توسط اسلات دیگری که در حال پردازش است استفاده شود و تعداد اسلات‌ها نیز بدون بارگذاری مجدد مدل قابل تغییر نیست. این طراحی برای یک نفر، یک تیم کوچک یا یک عامل برنامه‌نویسی (coding agent) مناسب است.

سرورهایی که برای تعداد زیادی کاربر همزمان ساخته شده‌اند، متفاوت عمل می‌کنند. آن‌ها حافظه نهان KV را در صفحات کوچک و بر اساس تقاضا تخصیص می‌دهند و درخواست‌های جدید را به دسته‌ای که در حال اجراست اضافه می‌کنند؛ بنابراین حافظه به جای تقسیم‌بندی ثابت، از تقاضای واقعی پیروی می‌کند. اگر هدف شما پشتیبانی از تعداد زیادی کاربر همزمان روی یک GPU است، این تفاوت معماری از هر مقداری برای OLLAMA_NUM_PARALLEL اهمیت بیشتری دارد. مقایسه بین Ollama و vLLM مکانی است که باید در آن تصمیم‌گیری کنید. با این حال، صرفاً بر اساس اصول تغییر ایجاد نکنید: مدیریت یک سرور متفاوت دشوارتر است و اگر ترافیک شما محدود به چند نفر است، رفتار پیش‌فرض برنامه پاسخ صحیح است.

سنجش توان عملیاتی و زمان رسیدن به اولین توکن

ارقام مربوط به تعداد توکن‌های تولیدشده در ثانیه که منتشر می‌شوند، از GPU، مدل، کوانتایزیشن، طول کانتکست و پرامپتِ شخص دیگری به دست آمده‌اند. هیچ‌کدام از این موارد با شرایط شما مطابقت ندارند؛ بنابراین هر عددی که می‌خوانید را صرفاً به عنوان یک راهنمای کلی در نظر بگیرید و عملکرد دستگاهی که در اختیار دارید را خودتان بسنجید.

Ollama در شیء JSON نهایی هر پاسخ، زمان‌بندی‌ها را برمی‌گرداند. eval_count تعداد توکن‌های تولیدشده و eval_duration زمان صرف‌شده برای تولید آن‌ها به نانوثانیه است.

sudo apt install -y jq
curl -s http://127.0.0.1:11434/api/generate \
  -d '{"model":"llama3.2:3b","prompt":"Explain what a KV cache is.","stream":false}' \
  | jq '{prompt_eval_count, eval_count, eval_duration, tokens_per_second: (.eval_count / (.eval_duration / 1000000000))}'

این کار را یک‌بار با یک اسلات (slot) و سپس با همان میزان هم‌زمانی (concurrency) که انتظار دارید اجرا کنید. سپس دو عددی که تعیین‌کننده رضایت کاربران هستند را مقایسه کنید: زمان رسیدن به اولین توکن و تعداد توکن در ثانیه برای هر درخواست. توان عملیاتی به ازای هر درخواست، با افزایش تعداد اسلات‌ها همیشه کاهش می‌یابد. پرسش اصلی این است که آیا این کاهش بیش از حدِ تحمل کاربران شماست یا خیر. سنجش توکن در ثانیه در یک LLM محلی این روش را با جزئیات بیشتری پوشش می‌دهد، از جمله اینکه چگونه پرامپت را در طول اجراهای مختلف ثابت نگه دارید.

یک endpoint عمومی با صف بزرگ، هدفی برای حملات محروم‌سازی از سرویس (DoS) است

تنظیم OLLAMA_HOST=0.0.0.0:11434 باعث می‌شود API روی تمام رابط‌های شبکه در دسترس قرار گیرد و Ollama هیچ سیستم احراز هویت داخلی ندارد. یک endpoint باز با صف پیش‌فرض، 512 درخواست در انتظار را از هر کسی که آن را پیدا کند می‌پذیرد. پر کردن این صف برای مهاجم تقریباً هیچ هزینه‌ای ندارد: پرامپت‌های طولانی، بدون نیاز به ورود، بدون محدودیت نرخ (rate limit) و بدون هزینه. در نتیجه، کاربران واقعی شما با پاسخ‌های 503 یا زمان‌های انتظار طولانی مواجه می‌شوند و سرور تمام مدت درگیر پردازش‌های کاذب خواهد بود.

شنونده (listener) را روی loopback نگه دارید و از طریق SSH tunnel یا یک شبکه خصوصی به آن دسترسی پیدا کنید، یا یک لایه احراز هویت و محدودیت نرخ در مقابل آن قرار دهید. ایمن‌سازی یک endpoint برای Ollama API هر دو روش را پوشش می‌دهد. پس از انجام این کار، صف را تنظیم کنید؛ زیرا طول صف صرفاً یک تنظیم ظرفیت است و هیچ‌گونه حفاظتی ایجاد نمی‌کند.

FAQ

چرا دومین درخواست Ollama منتظر می‌ماند تا اولی تمام شود؟

زیرا مقدار پیش‌فرض OLLAMA_NUM_PARALLEL برابر با 1 است، بنابراین مدل بارگذاری‌شده در هر لحظه فقط یک درخواست را پردازش می‌کند و سایر درخواست‌ها به ترتیب در صف می‌مانند. درخواستِ در انتظار، اتصال HTTP خود را باز نگه می‌دارد و تا زمانی که یک جایگاه (slot) خالی نشود، هیچ داده‌ای ارسال نمی‌کند؛ این وضعیت از دید کلاینت دقیقاً مشابه کند بودن مدل به نظر می‌رسد. تفاوت در الگوی زمانی است: وقفه طولانی و سپس دریافت متن با سرعت کامل، نشانه وجود صف است، در حالی که دریافت قطره‌چکانی متن از همان توکن اول، نشانه کند بودن مدل است. برای افزایش تعداد جایگاه‌ها، از یک فایل drop-in در systemd استفاده کرده و سرویس را مجدداً راه‌اندازی کنید.

خطای "server busy, please try again. maximum pending requests exceeded" به چه معناست؟

این خطای سرریز صف در Ollama است که با کد وضعیت HTTP 503 بازگردانده می‌شود. تعداد درخواست‌های در انتظار به حد نصاب OLLAMA_MAX_QUEUE رسیده است (که به‌طور پیش‌فرض 512 است)، بنابراین درخواست جدید به‌جای اضافه شدن به صف، رد شده است. این خطا مربوط به حافظه یا مدل نیست. افزایش ظرفیت صف فقط باعث می‌شود کلاینت‌ها قبل از دریافت همان خطای رد درخواست، مدت بیشتری منتظر بمانند؛ بنابراین راهکارهای واقعی عبارتند از: افزایش تعداد جایگاه‌ها (اگر VRAM کافی دارید)، کاهش بار ورودی، یا استفاده از یک صف در لایه جلویی (front-end) که بتواند درخواست‌ها را مجدداً ارسال و اولویت‌بندی کند.

آیا افزایش OLLAMA_NUM_PARALLEL باعث سریع‌تر شدن Ollama می‌شود؟

خیر. این کار اجازه می‌دهد درخواست‌های بیشتری به‌طور هم‌زمان اجرا شوند، اما سرعت هر یک از این درخواست‌ها نسبت به زمانی که به‌تنهایی اجرا می‌شدند کمتر است، زیرا همگی از یک GPU مشترک استفاده می‌کنند. این کار همچنین حافظه KV cache را چندبرابر می‌کند، زیرا Ollama پردازشگر (runner) را با مجموع طول کانتکست (context length) ضرب‌در تعداد جایگاه‌ها راه‌اندازی می‌کند. اگر نتیجه دیگر در VRAM جا نشود، Ollama لایه‌ها را به CPU منتقل می‌کند و سرعت تمام درخواست‌ها، حتی زمانی که فقط یک درخواست در حال اجراست، کاهش می‌یابد. پس از تغییر، ollama ps را بررسی کنید و مطمئن شوید که ستون PROCESSOR همچنان مقدار 100% GPU را نشان می‌دهد.

آیا پس از تغییر این متغیرها باید Ollama را مجدداً راه‌اندازی کنم؟

بله. سرور این متغیرها را هنگام شروع می‌خواند و مدل در حال اجرا، تعداد جایگاه‌هایی را که در لحظه راه‌اندازی در پردازشگر آن ثابت شده است، حفظ می‌کند. فایل drop-in را با sudo systemctl edit ollama.service ویرایش کنید، سپس sudo systemctl daemon-reload و sudo systemctl restart ollama را اجرا نمایید. با systemctl show ollama --property=Environment تغییرات را تأیید کنید و سپس خط server config را در journalctl -u ollama بررسی کنید که محیطی را که سرور واقعاً بارگذاری کرده است، فهرست می‌کند.

چند جایگاه موازی باید تنظیم کنم؟

از 1 شروع کنید و هر بار یک واحد افزایش دهید. پس از هر مرحله، Ollama را مجدداً راه‌اندازی کنید، یک درخواست برای بارگذاری مدل بفرستید و ollama ps را اجرا کنید. در آخرین مقداری که PROCESSOR همچنان 100% GPU را نشان می‌دهد و ستون SIZE فضای کافی برای طولانی‌ترین کانتکستی که ارائه می‌دهید باقی می‌گذارد، متوقف شوید. سپس زمان رسیدن به اولین توکن و تعداد توکن در ثانیه را در آن تنظیمات تحت بار کاری واقعی خود اندازه‌گیری کنید و اگر سرعت هر درخواست به کمتر از حد تحمل کاربران شما رسید، یک گام به عقب برگردید.