vLLM یا TGI؛ بار هم‌زمان و پرامپت بلند برنده را عوض می‌کند

برای سرو درخواست‌های هم‌زمانِ پرتعداد، vLLM نقطهٔ شروع قوی‌تری است؛ در گفت‌وگوی کم‌بار، سرعت رسیدن نخستین توکن می‌تواند انتخاب را به سود TGI تغییر دهد. پیش‌چاپ مقایسهٔ تجربی با مدل‌های LLaMA-2، شتاب‌دهنده‌های A100، نسخهٔ 0.6.1 از vLLM و نسخهٔ 2.3.0 از TGI، در بار هم‌زمانِ بالا تا ۲۴ برابر توان عملیاتی بیشتر برای vLLM گزارش می‌کند؛ در همان مطالعه، TGI برای رسیدن به نخستین توکن سریع‌تر بود. این نتایج به مدل‌ها، نسخه‌ها و بار همان آزمایش تعلق دارند.

برای درخواست‌هایی که زمینهٔ بلندشان تکرار می‌شود، وضعیت cache می‌تواند نتیجه را برگرداند. در آزمون منتشرشدهٔ TGI v3، اجرای دوم با cache گرم، مدل Llama 3.1 70B و هشت H100، تکمیل ۲۰ درخواست را برای TGI در ۲ ثانیه و برای vLLM در ۲۷٫۵ ثانیه ثبت کرد؛ مجموع ورودی آن درخواست‌ها حدود ۲۰۰ هزار توکن بود. این عدد، زمان پایان یک مجموعهٔ ثابت است، نه تأخیر هر پاسخ یا توان عملیاتی پایدار یک سرویس.

چرا نتایج دو آزمایش قابل جابه‌جایی نیستند؟

آزمایش LLaMA-2 می‌پرسد با زیاد شدن درخواست‌های هم‌زمان، هر موتور چه مقدار خروجی تولید می‌کند. آزمایش متن بلند می‌پرسد یک مجموعهٔ مشخص از درخواست‌ها در اجرای دوباره چه زمانی تمام می‌شود. مدل، نسل شتاب‌دهنده، نسخهٔ موتور، شکل درخواست و وضعیت cache میان آن‌ها فرق دارد؛ بنابراین نمی‌توان نسبت برتری یکی را به سناریوی دیگری منتقل کرد. حتی اگر هر دو گزارش از «سرعت» حرف بزنند، مخرج کسرشان ممکن است توکن خروجی، درخواست تکمیل‌شده یا زمان پایان کل مجموعه باشد.

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

تأخیر چت را با کدام سنجه بخوانیم؟

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

میانگین تأخیر نیز برای تصمیم کافی نیست. وقتی طول پرامپت‌ها و پاسخ‌ها متفاوت است، درخواست‌های کند در انتهای توزیع پنهان می‌شوند؛ صدک‌های بالای زمان نخستین توکن و تکمیل پاسخ نشان می‌دهند کاربرانی که بیشتر منتظر می‌مانند چه تجربه‌ای دارند. نام سنجه را کنار هر صدک بنویسید: «صدک بالای زمان نخستین توکن» را نباید با «صدک بالای زمان تکمیل» یکسان خواند. نرخ خطا و تعداد درخواست‌های موفق هم باید کنار این اعداد باشند تا حذف شدن درخواست‌های دشوار، موتور را ظاهراً سریع‌تر نشان ندهد.

پرامپت بلند چه زمانی به سود TGI است؟

مزیت اجرای گرم به وجود پیشوند مشترک وابسته است. در درخواست تازه، موتور باید متن ورودی را پردازش کند؛ در درخواست بعدی با همان آغاز، می‌تواند بخشی از محاسبهٔ قبلی را بازاستفاده کند. اگر هر کاربر سندی متفاوت بفرستد، یا پرسش بعدی به نمونه‌ای برسد که cache پیشین را در اختیار ندارد، انتظار همان جهش سرعت منطقی نیست. طول کل پرامپت به‌تنهایی کافی نیست؛ طول بخش مشترک و احتمال رسیدن دوباره به آن بخش تعیین‌کننده‌اند.

vLLM هم cache پیشوندی خودکار دارد و بلوک‌های پردازش‌شدهٔ ورودی مشترک را برای درخواست بعدی نگه می‌دارد. پس مقایسهٔ متن بلند باید فرصت بازاستفاده را برای هر دو موتور روشن کند، نه اینکه اجرای گرم یکی را کنار اجرای سرد دیگری بگذارد. در سرو چندنمونه‌ای، مسیردهی درخواست‌های یک کاربر نیز اثر دارد: اگر پاسخ بعدی به نمونه‌ای دیگر برود، cache نمونهٔ قبلی به آن کمک نمی‌کند.

حافظه و بار را چگونه هم‌شرط بسنجیم؟

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

برای بازتولید، یک مدل و tokenizer، قالب پیام، دقت عددی و سخت‌افزار برابر انتخاب کنید. توزیع طول درخواست‌ها و فاصلهٔ ورود آن‌ها را از بار موردنظر نگه دارید؛ ورودی‌های ساختگیِ هم‌طول، تغییرات صف و فشار حافظه را کم‌نمایی می‌کنند. اجرای سرد را از اجرای دارای پیشوند تکراری جدا کنید و در گزارش هر دو، پیک حافظه، درخواست‌های موفق، توان عملیاتی، زمان نخستین توکن و تأخیر کل را بیاورید. با این کار تفاوت موتور از تفاوت داده یا نحوهٔ گرم شدن cache جدا می‌شود.

راهنمای رسمی vllm bench serve گزینه‌های --request-rate، --max-concurrency، --input-len، --output-len و --num-prompts را برای ساخت بار سرو آنلاین توضیح می‌دهد. یک قالب دستور برای نقطهٔ پایانی سازگار چنین است: vllm bench serve --backend openai-chat --base-url BASE_URL --endpoint /v1/chat/completions --model MODEL_ID --dataset-name random --input-len INPUT_LEN --output-len OUTPUT_LEN --num-prompts COUNT --request-rate RATE --max-concurrency LIMIT. مقدارهای جایگزین را برای هر دو سرویس یکسان بگذارید و سپس در هر نوبت فقط نرخ ورود، طول ورودی یا سهم پیشوندهای تکراری را تغییر دهید. دادهٔ تصادفی برای سنجش اثر cache واقعی کافی نیست؛ آن بخش به مجموعه‌ای با پیشوندهای مشترکِ مشخص نیاز دارد.

ماتریس انتخاب برای سه الگوی سرو

• چت تعاملی کم‌بار: TGI نامزد جدی است اگر شروع سریع پاسخ اولویت دارد. زمان نخستین توکن را همراه با تأخیر کل و فاصلهٔ میان توکن‌ها بسنجید؛ برتری در شروع پاسخ ممکن است تا پایان پاسخ حفظ نشود.
• پردازش دسته‌ای پرتراکم: vLLM نقطهٔ شروع مناسب‌تری است. معیار انتخاب، توان عملیاتیِ پایدار در نرخی است که صف و خطا هنوز با نیاز سرویس سازگارند، نه بیشینهٔ لحظه‌ای توکن بر ثانیه.
• متن بسیار بلند با زمینهٔ تکراری: TGI در آزمون اجرای گرم نتیجهٔ چشمگیری دارد. سهم درخواست‌هایی که واقعاً به همان پیشوند و همان cache می‌رسند، مشخص می‌کند آن مزیت تا چه حد به بار شما منتقل می‌شود.

افق نگهداری نیز بخشی از انتخاب زیرساخت است. مستندات اصلی TGI وضعیت پروژه را «حالت نگهداری» اعلام می‌کند و مشارکت‌های آینده را عمدتاً به اصلاح‌های کوچک، مستندات و کارهای سبک محدود می‌داند. این وضعیت نتیجهٔ آزمون‌های عملکرد را تغییر نمی‌دهد، اما برای تیمی که به توسعهٔ پیوستهٔ موتور و پشتیبانی از نیازهای تازه وابسته است، در کنار نتیجهٔ بار واقعی اهمیت دارد.

بیشتر بخوانید:

• رزومهٔ زمانی یا مهارت‌محور؛ سابقهٔ پیوسته انتخاب را عوض می‌کند
• Wise Business یا Revolut Business؛ آخر هفته می‌تواند برنده را عوض کند
• Zapier یا Make؛ گردش‌کار هشت‌مرحله‌ای می‌تواند برنده را عوض کند