‏vLLM در دنیای واقعی: یه پول مشترک کافی نیست

یه آزمایشگاه تخصصی با شبیه‌سازی ترافیک واقعی مختلط، عملکرد چند فریم‌ورک سرویس‌دهی مدل‌های زبانی رو با هم مقایسه کرده. برخلاف بنچمارک‌های معمول که فقط یه عدد throughput می‌دن، این آزمایش شش کلاس درخواست واقعی رو شامل می‌شه: چت تعاملی، RAG با پیشوندهای تکراری، درخواست‌های long-prefill، حلقه‌های ابزار agent، خلاصه‌سازی دسته‌ای، و کلاینت‌های با استریم کند.

در این آزمایش چهار فریم‌ورک مقایسه شدن: vLLM V1، SGLang، llama.cpp و TGI، و همه از یه رابط OpenAI-compatible استفاده می‌کردن تا مقایسه منصفانه باشه. پروفایل‌های مختلفی هم بررسی شد: یه پول متعادل، یه پول برای توکن‌های بزرگ، یه پول تعاملی کوچیک، مسیریابی prefix-cache، ایزولاسیون کلاینت کند، و مسیریابی آگاه از کلاس درخواست.

نتیجه اصلی اینه که یه پول مشترک vLLM برای ترافیک مختلط، پیش‌فرض بدیه. بهترین پروفایل، vllm-v1/class-aware-router بود که بهترین ترکیب از نظر تأخیر اولین توکن (TTFT)، ریتم توکن (ITL)، ایزولاسیون کلاینت‌های کند، و throughput مفید رو داشت.

توصیه عملی اینه که قبل از هر تغییری در کرنل‌ها، لاین‌های ترافیکی رو جدا کنی. ترافیک تعاملی باید روی یه پول کوچیک‌تر با max_num_batched_tokens محدودتر و max_num_seqs متوسط بمونه. کارهای long-context و batch هم باید به یه پول جداگانه با بودجه توکن بزرگ‌تر منتقل بشن.

برای chunked prefill هم باید همین رویکرد رو داشت. مقدار max_long_partial_prefills باید زیر max_num_partial_prefills نگه داشته بشه تا پرامپت‌های کوتاه بتونن همزمان با پردازش پرامپت‌های بلند وارد اسکجولر بشن. بودجه توکن، تعداد سکوئنس، محدودیت‌های partial-prefill و فاصله استریم باید به عنوان کنترل‌های بار کاری در نظر گرفته بشن، نه تنظیمات ثابت.

آزمایش مقیاس بزرگ‌تر این نتیجه رو تأیید کرد. پول مشترک واحد نتونست gate مربوط به TTFT/ITL رو پاس بده، در حالی که پروفایل class-aware routing تقریباً همه درخواست‌ها رو قبول کرد. پروفایل‌های prefix-cache-only و slow-client-only برای لاین خودشون خوب بودن، ولی به عنوان استراتژی کل سیستم جواب نمی‌دن.

در بخش build، نسخه Debian نیاز به rootfs بزرگ‌تر داشت و به مشکل نسخه GCC خورد. Fedora 44 با GCC 16، Python 3.14 و تنظیمات VLLM_TARGET_DEVICE=cpu، MAX_JOBS=4 و numactl-devel موفق به build شد. یه نکته مهم deployment هم اینه که برای عملکرد بهتر runtime، نصب tcmalloc توصیه می‌شه.

در آزمایشگاه hybrid KV، مسیر بازنویسی PagedAttention بررسی شد. این رویکرد مالکیت بلوک، اشتراک پیشوند، refcount، بلوک‌های جزئی، eviction و copy-on-write رو حفظ می‌کنه، ولی به جای یه block table طولانی به ازای هر توکن، span‌های منطقی فشرده رو در اختیار کرنل‌های آینده می‌ذاره. در اولین اجرا، ۳۰ تا از ۳۰ تست کرکتنس پاس شد و دو layout به عنوان اولویت پروفایل روی سخت‌افزار معرفی شدن: virtual-contiguous و hybrid-prefix-shared.

نکات کلیدی:

• یه پول مشترک vLLM برای ترافیک مختلط کافی نیست و عملکرد ضعیفی داره
• بهترین پروفایل، class-aware-router بود که همه جنبه‌های لیتنسی و throughput رو با هم بهینه می‌کنه
• لاین‌های ترافیکی رو جدا کن: ترافیک تعاملی و ترافیک سنگین هر کدوم باید پول جداگانه داشته باشن
• max_long_partial_prefills رو زیر max_num_partial_prefills نگه دار تا اسکجولر گیر نکنه
• برای build روی CPU، Fedora 44 با GCC 16 موفق بود و نصب tcmalloc توصیه می‌شه
• بازنویسی PagedAttention با رویکرد hybrid KV همه تست‌های کرکتنس رو پاس کرد