اجرای مدل‌های زبانی بزرگ محلی (LLMs) به یک رویه استاندارد برای توسعه‌دهندگانی تبدیل شده است که به دنبال حریم خصوصی، تأخیر کم و کارایی هزینه هستند. در حالی که Ollama اجرای این مدل‌ها را ساده می‌کند، مقیاس‌بندی از یک محیط توسعه تک‌کاربره به یک محیط تولید چندکاربره، چالش‌های پیچیده‌ای در مدیریت منابع را ایجاد می‌کند. گلوگاه‌های اصلی، تکه‌تکه شدن حافظه ویدیویی (VRAM) و فرسایش پنجره زمینه هستند. این راهنما استراتژی‌هایی را برای حداکثرسازی همزمانی بدون قربانی کردن کیفیت استنتاج یا پایداری بررسی می‌کند.
مسئله رقابت بر سر VRAM
برخلاف APIهای ابری که در آن‌ها استنتاج در سراسر خوشه‌های عظیم توزیع می‌شود، استنتاج محلی به حافظه گرافیکی مجزا (GPU) سخت‌افزار شما متکی است. به طور پیش‌فرض، Ollama وزن‌های مدل را در VRAM بارگذاری می‌کند. وقتی چندین کاربر به طور همزمان درخواست استنتاج می‌دهند، سیستم باید تصمیم بگیرد که آیا مدل‌های موجود را در حافظه نگه دارد یا آن‌ها را برای بارگذاری مدل‌های جدید حذف کند. این «thrashing» (جابه‌جایی مکرر داده) منجر به جهش‌های قابل توجه در تأخیر می‌شود، زیرا وزن‌ها به طور مداوم بین RAM پردازنده مرکزی و VRAM کارت گرافیک جابه‌جا می‌شوند.
مدیریت مؤثر VRAM نیاز به درک از ردپای حافظه یک مدل دارد. فرمول تقریبی برای مصرف VRAM به شرح زیر است:
مصرف VRAM ≈ (تعداد پارامترهای مدل × بایت به ازای هر وزن) + (طول زمینه × تعداد سرهای توجه × اندازه نوع داده)برای یک مدل با 7 میلیارد پارامتر که به 4 بیت (Q4_K_M) کم‌فشرده شده است، اندازه پایه وزن‌ها تقریباً 4 گیگابایت است. با این حال، پنجره زمینه بار پویا اضافه می‌کند. یک پنجره زمینه با 4,096 توکن روی یک لایه توجه FP16 می‌تواند چند صد مگابایت اضافه کند. برای کاهش این مشکل، باید اندازه‌های زمینه را در سراسر استقرار خود استاندارد کنید تا از جهش‌های غیرقابل پیش‌بینی حافظه جلوگیری شود.
استراتژی‌ها برای استنتاج همزمان
سه رویکرد اصلی برای مدیریت بار چندکاربره در Ollama وجود دارد:
- سنجاق کردن مدل (Model Pinning): نگه داشتن مدل‌های پرکاربرد در حافظه. این روش برای سناریوهای با پهنای باند بالا و مجموعه‌ای ثابت از مدل‌ها ایده‌آل است.
- خارج کردن تهاجمی (Aggressive Offloading): استفاده از پرچم `num_gpu` در Ollama برای کنترل تعداد لایه‌هایی که روی GPU باقی می‌مانند. این امکان می‌دهد مدل‌های کوچک‌تر همزمان وجود داشته باشند، اما زمان استنتاج روی CPU را افزایش می‌دهد.
- صف‌بندی درخواست‌ها (Request Queueing): پیاده‌سازی یک صف در سطح برنامه برای سریال کردن درخواست‌ها در صورتی که سخت‌افزار شما قادر به مدیریت موازی‌سازی واقعی نیست.
پیکربندی Ollama برای پایداری
در حالی که Ollama زمان‌بندی را به طور داخلی مدیریت می‌کند، می‌توانید از طریق متغیرهای محیطی و پارامترهای API بر رفتار آن تأثیر بگذارید. ابتدا، محدودیت‌های VRAM خود را به طور صریح تعریف کنید. اگر از GPU انویدیا استفاده می‌کنید، اطمینان حاصل کنید که از آخرین درایورها برای پشتیبانی از CUDA 12.0+ برای مدیریت بهتر حافظه استفاده می‌کنید.
هنگام راه‌اندازی نمونه Ollama خود، در نظر بگیرید که متغیر محیطی `OLLAMA_MAX_LOADED_MODELS` را تنظیم کنید. این کار تعداد مدل‌هایی که می‌توانند به طور همزمان بارگذاری شوند را محدود می‌کند و از خطاهای OOM (خارج شدن از حافظه) تحت بار سنگین جلوگیری می‌کند.
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_GPU_OVERHEAD=1024 # MB
docker run -d \
-e OLLAMA_MAX_LOADED_MODELS=$OLLAMA_MAX_LOADED_MODELS \
-e OLLAMA_GPU_OVERHEAD=$OLLAMA_GPU_OVERHEAD \
-p 11434:11434 \
ollama/ollama:latestمدیریت پویا پنجره‌های زمینه
همه درخواست‌ها به طول زمینه یکسانی نیاز ندارند. کمک به کدنویسی اغلب از زمینه‌های طولانی بهره می‌برد، در حالی که وظایف خلاصه‌سازی ساده این نیاز را ندارند. برای بهینه‌سازی VRAM، باید محدودیت‌های پویای زمینه را در سطح API اعمال کنید.
در اینجا یک مثال پایتون با استفاده از `requests` آورده شده است که نشان می‌دهد چگونه می‌توان یک پنجره زمینه تنگ‌تر (`num_ctx`) را برای یک وظیفه خاص مشخص کرد تا اطمینان حاصل شود که مدل VRAM اضافی برای بافرهای توجه تخصیص نمی‌دهد:
import requests
def generate_response(prompt, num_ctx=2048):
response = requests.post(
"http://localhost:11434/api/generate",
json={
"model": "llama3:8b",
"prompt": prompt,
"stream": False,
"options": {
"num_ctx": num_ctx,
"temperature": 0.7
}
}
)
return response.json().get("response")
# مثال: زمینه کوتاه برای پرسش و پاسخ سریع
quick_answer = generate_response("What is Python?", num_ctx=512)
print(quick_answer)پایش و هشداردهی
بهینه‌سازی یک فرآیند تکراری است. باید از مصرف GPU خود را به صورت بلادرنگ پایش کنید. ابزارهایی مانند `nvidia-smi` یا `nvtop` ضروری هستند. به معیارهای زیر توجه کنید:
- مصرف حافظه GPU: باید زیر 90٪ از کل VRAM باقی بماند تا برای بار سیستم‌عامل فضا بماند.
- استفاده از GPU: استفاده بالا با تأخیر کم نشان‌دهنده دسته‌بندی (batching) خوب است. استفاده بالا با تأخیر بالا ممکن است نشان‌دهنده thrashing حافظه باشد.
این معیارها را در استک پایش خود (مثلاً Prometheus با `node_exporter`) یکپارچه کنید تا زمانی که مصرف VRAM از آستانه‌های ایمن فراتر رفت، هشدارها را فعال کنید.
نتیجه‌گیری
بهینه‌سازی Ollama برای استنتاج همزمان چندکاربره درباره زورآزمایی سخت‌افزار نیست، بلکه درباره تخصیص هوشمند منابع است. با محدود کردن تعداد مدل‌های بارگذاری شده، استاندارد کردن پنجره‌های زمینه و پایش مصرف VRAM، می‌توانید خدمات هوش مصنوعی محلی پایدار و کم‌تأخیر را دستیابی کنید. با تنظیمات محافظه‌کارانه شروع کنید، بار کاری خود را پروفایل کنید و پارامترها را بر اساس داده‌های تجربی تنظیم کنید. با ادامه کوچک شدن و کارآمدتر شدن مدل‌های هوش مصنوعی محلی، این استراتژی‌ها برای ساخت برنامه‌های مقیاس‌پذیر و اولویت‌دار حریم خصوصی همچنان حیاتی خواهند ماند.