مدیریت همزمانی در Ollama با OLLAMA_NUM_PARALLEL

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

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

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

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

پارامترهای 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 cache تخصیص می‌دهد و -np تعداد دنباله‌های موازی است. Ollama مقدار -c را برابر با طول متن هر درخواست ضرب‌در تعداد اسلات‌ها قرار می‌دهد. سپس runner این مقدار کل را به‌طور مساوی بین اسلات‌ها تقسیم می‌کند تا هر درخواست همچنان به همان طول متنی که درخواست کرده‌اید، دسترسی داشته باشد.

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

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

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

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

اگر وزن‌های مدل به اضافه آن KV cache در VRAM جا نشوند، Ollama برخی از لایه‌ها را به RAM سیستم منتقل می‌کند و آن لایه‌ها روی CPU اجرا می‌شوند. لایه‌های CPU بسیار کندتر از لایه‌های GPU هستند، بنابراین این کار هر درخواستی را کندتر می‌کند، از جمله همان تک درخواستی که با آن شروع کرده‌اید. بنابراین افزایش موازی‌سازی می‌تواند به‌جای افزایش throughput، آن را کاهش دهد. با یک مدل به اندازه کافی بزرگ، وزن‌ها به‌تنهایی پیش از شروع هرگونه محاسبات اسلات، تکلیف را مشخص می‌کنند؛ به همین دلیل است که میزبانی شخصی چیزی به اندازه Kimi K3 بحثی درباره تعداد کارت‌هایی است که دارید، نه تعداد اسلات‌هایی که تنظیم کرده‌اید.

ollama ps

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

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

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

در لینوکس، Ollama به عنوان یک سرویس systemd اجرا می‌شود. اجرای export OLLAMA_NUM_PARALLEL=4 در shell شما هیچ تغییری ایجاد نمی‌کند، زیرا systemd سرویس را با محیط اختصاصی خود اجرا می‌کند و 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 درخواست در هر اسلات می‌تواند در آن بازه زمانی پردازش شود و صفی عمیق‌تر از این مقدار، تنها منجر به ایجاد timeout می‌شود.

چه زمانی باید یک صف در مقابل 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 cache را به اسلات‌های ثابت و مساوی تقسیم می‌کند. حافظه یک اسلات بیکار نمی‌تواند توسط اسلات مشغول استفاده شود و تعداد اسلات‌ها نیز بدون بارگذاری مجدد مدل قابل تغییر نیست. این طراحی برای یک نفر، یک تیم کوچک یا یک عامل کدنویسی (coding agent) مناسب است.

سرورهایی که برای تعداد زیادی کاربر همزمان ساخته شده‌اند، متفاوت عمل می‌کنند. آن‌ها حافظه KV cache را در صفحات کوچک و بر اساس تقاضا تخصیص می‌دهند و درخواست‌های جدید را به دسته‌ای که در حال اجراست اضافه می‌کنند؛ بنابراین حافظه به جای تقسیم‌بندی ثابت، از تقاضای واقعی پیروی می‌کند. اگر هدف شما پشتیبانی از تعداد زیادی کاربر همزمان روی یک 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))}'

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

یک endpoint عمومی با صف بزرگ، هدفی برای حملات Denial of Service است

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

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

FAQ

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

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

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

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

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

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

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

بله. سرور این متغیرها را هنگام راه‌اندازی می‌خواند و مدلی که در حال اجراست، تعداد جایگاه‌هایی را که در لحظه شروع پردازشگر تعیین شده بود، حفظ می‌کند. فایل 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 بررسی کنید که محیطی را که سرور واقعاً بارگذاری کرده است، فهرست می‌کند.

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

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