چگونه یک LLM را برای چند کاربر همزمان روی GPU Server اجرا کنیم؟

اجرای یک مدل زبانی برای خودتان ساده است؛ اما وقتی ده‌ها کارمند یا صدها کاربر همزمان از آن استفاده می‌کنند، مسئله کاملاً تغییر می‌کند. زمان انتظار بالا می‌رود، حافظه GPU پر می‌شود و سرور زیر بار کند می‌شود. در این راهنما توضیح می‌دهیم چطور یک LLM را برای چند کاربر همزمان روی GPU Server اجرا کنیم: کدام موتور را انتخاب کنیم، ظرفیت را چطور تخمین بزنیم و چه معماری‌ای برای رشد مناسب است.

چرا همزمانی در LLM دشوار است؟

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

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

معیارهای سنجش: TTFT، سرعت توکن و Throughput

• TTFT (زمان تا اولین توکن): مدت انتظار کاربر تا شروع پاسخ. برای چت، زیر یک تا دو ثانیه مطلوب است.
• سرعت تولید برای هر کاربر: تعداد توکن در ثانیه‌ای که هر کاربر می‌بیند. بیش از حدود ۱۰ تا ۱۵ توکن در ثانیه از سرعت خواندن انسان بیشتر است.
• Throughput کل: مجموع توکن‌هایی که سرور در هر ثانیه برای همه کاربران تولید می‌کند؛ معیار اصلی هزینه.

این معیارها با هم معامله دارند: با افزایش کاربران همزمان، Throughput کل بالا می‌رود، اما سرعت هر کاربر کمی کاهش می‌یابد. هدف، پیدا کردن نقطه‌ای است که هر دو در محدوده قابل قبول باشند.

Continuous Batching

روش قدیمی Batching، چند درخواست را جمع می‌کرد و با هم پردازش می‌کرد، اما همه باید منتظر می‌ماندند تا طولانی‌ترین پاسخ تمام شود. در Continuous Batching، در هر مرحله تولید توکن، درخواست‌های تمام‌شده از دسته خارج و درخواست‌های جدید وارد می‌شوند. GPU همیشه پر است و هیچ درخواستی منتظر بقیه نمی‌ماند. این تکنیک در vLLM، SGLang و TensorRT-LLM پیاده شده و در عمل Throughput را چند برابر روش ساده می‌کند.

حافظه: محدودیت اصلی همزمانی

هر درخواست فعال، KV Cache مخصوص خود را دارد که با طول متن بزرگ می‌شود. پس تعداد کاربران همزمان به این بستگی دارد که بعد از بارگذاری مدل، چقدر VRAM باقی می‌ماند:

ظرفیت همزمانی ≈ (VRAM کل − حجم مدل − سربار) ÷ (KV Cache هر توکن × طول متن متوسط)

راه‌های افزایش ظرفیت:

• کوانتایز مدل: مدل کوچک‌تر، فضای بیشتر برای کش.
• کوانتایز KV Cache به FP8: تقریباً دو برابر ظرفیت کش.
• محدود کردن طول متن به نیاز واقعی کاربرد.
• PagedAttention: تخصیص حافظه کش به اندازه نیاز واقعی، نه حداکثر طول متن.
• Prefix Caching: اشتراک کش پیام سیستمی مشترک بین همه درخواست‌ها.

انتخاب موتور سرویس‌دهی

برای بیشتر سازمان‌ها، vLLM بهترین تعادل بین کارایی و سادگی را دارد. مقایسه دقیق با Ollama را در Ollama یا vLLM و معرفی کامل آن را در vLLM چیست بخوانید.

نمونه پیکربندی vLLM

vllm serve Qwen/Qwen2.5-14B-Instruct \
  --host 127.0.0.1 --port 8000 \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 64 \
  --kv-cache-dtype fp8 \
  --enable-prefix-caching

• --max-model-len: حداکثر طول متن هر درخواست؛ عدد کمتر یعنی کاربران همزمان بیشتر.
• --gpu-memory-utilization: سهم VRAM قابل استفاده؛ باقی‌مانده بعد از مدل، به کش می‌رسد.
• --max-num-seqs: سقف درخواست‌های همزمان در هر دسته.
• --enable-prefix-caching: استفاده مجدد از کش پیام سیستمی مشترک.

در لاگ شروع، vLLM ظرفیت KV Cache را به توکن اعلام می‌کند؛ این عدد را بر طول متن متوسط تقسیم کنید تا حداکثر همزمانی واقعی را تخمین بزنید. برای دسترسی امن کاربران، این سرویس را پشت Nginx با کلید API قرار دهید؛ روش آن در ساخت OpenAI-Compatible API آمده است.

تخمین ظرفیت و تست بار

ظرفیت واقعی را فقط با تست بار می‌توان فهمید، چون به اندازه مدل، طول ورودی و خروجی و الگوی استفاده بستگی دارد. روش پیشنهادی:

1. طول متوسط ورودی و خروجی را از کاربرد واقعی (یا تخمین منطقی) مشخص کنید.
2. با ابزار بنچمارک vLLM یا ابزارهایی مثل Locust، تعداد کاربران همزمان را به‌تدریج افزایش دهید.
3. TTFT و سرعت هر کاربر را ثبت کنید.
4. نقطه‌ای را که TTFT از حد قابل قبول بیشتر می‌شود، به‌عنوان ظرفیت در نظر بگیرید و برای اوج مصرف حاشیه بگذارید.

توجه کنید که «کاربر همزمان» با «کاربر فعال» فرق دارد: در یک سازمان ۲۰۰ نفره، معمولاً فقط بخش کوچکی از کاربران در یک لحظه منتظر پاسخ هستند.

معماری برای رشد

• مقیاس عمودی: GPU با حافظه و پهنای باند بیشتر. انتقال از L40S به H100 علاوه بر ظرفیت، سرعت هر کاربر را هم افزایش می‌دهد. مقایسه را در L40S یا H100 ببینید.
• مقیاس افقی: چند نسخه مستقل از مدل روی چند GPU یا سرور و یک Load Balancer در جلو. ساده‌ترین روش افزایش ظرفیت است و تحمل خطا هم ایجاد می‌کند.
• مسیریابی بر اساس مدل: درخواست‌های ساده به مدل کوچک و سریع، درخواست‌های پیچیده به مدل بزرگ. یک Gateway مثل LiteLLM این کار را انجام می‌دهد.
• صف و محدودیت نرخ: در اوج مصرف، درخواست‌ها به‌جای خطا در صف بمانند و هیچ کاربری کل ظرفیت را اشغال نکند.

سوالات متداول