چیت‌شیت
مقایسه‌ی موتورهای سروینگ
Serving Engines Compared
مقایسه‌ی رو در روی vLLM، SGLang، TRT-LLM و llama.cpp؛ زمان‌بندها، استفاده مجدد از KV، دقت، تخلیه و انتخاب بهینه.
فهرست مطالب
موتورها در یک نگاه
مقایسه| فاکتور | vLLM | SGLang | TRT-LLM | llama.cpp |
|---|---|---|---|---|
| ایده‌ی اصلی | PagedAttention، دسته‌بندی پیوسته، پیش‌پرکنی تکه‌ای | توجه رادیکس، زمان‌بند آگاه از کش | وزن‌های NVFP4، کش FP8 KV، و MTP | سریع‌ترین روی پردازنده‌ی اصلی، بیشترین پشتیبانی از مدل‌ها |
| اسکژولینگ | زمان‌بند V1، الگوریتم FCFS | اعزام اول-عمق، LRU در سطح branch | پیش‌پرکنی/رمزگشایی تفکیک‌شده | کنترل کامل روی ریسه‌بندی (threading) |
| سخت‌افزار | NVIDIA و AMD ROCm | NVIDIA و AMD | فقط NVIDIA، پردازنده‌های Blackwell | پردازنده‌ی اصلی، Apple Silicon Metal |
| شاخص‌ترین رقم | 2,200 تا 2,400 توکن بر ثانیه، 70B FP8 روی H100 | حدود 16,200 در برابر 12,500 توکن بر ثانیه روی مدل 8B | 0.012 دلار به ازای هر 1 میلیون توکن روی GB200 NVL72 | نرم‌افزار Ollama بین 15 تا 30 درصد کندتر است |
| فرمت وزن‌ها | HF safetensors | HF safetensors | کامپایل‌شده اختصاصی برای هر مدل GPU | GGUF |
| نقطه‌ضعف | ترافیک سنگین مبتنی بر پیشوند | پرامپت‌های غیرتکراری، افت کارایی تا سطح vLLM | عدم پشتیبانی از AMD، Intel و ARM | نامناسب برای مراحل عملیاتیِ پایپ‌لاین |
چه زمانی از کدام موتور استفاده کنیم؟
مفهوم‌ها- vLLM
- گفت‌وگوهای عمومی، بیش از 100 کاربر، پردازنده‌های گرافیکی AMD یا سخت‌افزار ترکیبی.
- SGLang
- ایجنت‌ها، سیستم‌های RAG و گفت‌وگوهایی با پیشوندهای مشترک طولانی.
- TRT-LLM
- زیرساخت‌های صرفاً NVIDIA و کارهای با اولویت هزینه روی Blackwell.
- llama.cpp
- پردازنده‌ی اصلی، سیستم‌های لبه (edge) یا Apple Silicon.
- Ollama
- کار تک‌کاربره روی لپ‌تاپ توسعه؛ نه برای محیط اشتراکی عملیاتی.
- TGI
- فقط استقرارهای پیشین؛ در وضعیت نگهداری از 11 دسامبر 2025.
- Native CPU offload
- زمانی که یک موتور دچار کمبود حافظه‌ی HBM باشد.
- LMCache
- پیشوندهای مشترک بین چند موتور، یا پیش‌دستی‌های پرتکرار.
حلقه‌ی زمان‌بند vLLM
کدpython
while True:
finished = [s for s in RUNNING if s.is_done()]
for s in finished: release_blocks(s); RUNNING.remove(s) # بلوک‌های آزاد
while WAITING and have_free_blocks_for(WAITING[0]): # پذیرش در صورت وجود KV آزاد
s = WAITING.pop(0)
allocate_initial_blocks(s)
RUNNING.append(s)
batch = []
for s in RUNNING:
if s.in_prefill:
batch.append(next_prefill_chunk(s)) # مثلاً 512 توکن
else:
batch.append(decode_one_token(s)) # 1 توکن
run_forward(batch) # یک فراخوانی ادغام‌شده‌ی GPU
یک درخواست در درخت مبنا (Radix Tree)
گام‌به‌گام- درخواستپرامپت سیستم به همراه "Context: <doc A>" و "Question: Carol".
- زمان‌بندپیمایش درخت؛ تطابق پیشوند سیستم، 124 بلوک مجدداً استفاده شد.
- زمان‌بندتطابق شاخه‌ی doc A، استفاده‌ی مجدد از 31 بلوک.
- تخصیص‌دهندهتخصیص بلوک‌های جدید تنها به "Question: Carol"، معادل 4 بلوک.
- نتیجهپیش‌پرکنی 4 بلوک به‌جای 160 بلوک؛ حدود 40 برابر پیش‌پرکنی کمتر.
- تخلیه (Eviction)حذف کامل شاخه‌ها از برگ‌هایی با کمترین میزان استفاده.
استک عملیاتی
معماریدقت و اقتصاد استک در main.py
مقایسه| فاکتور | H100 + BF16 + vLLM | H100 + FP8 + vLLM | B200 + NVFP4 + FP8 + TRT-LLM | GB200 NVL72 + TRT-LLM + Dyn |
|---|---|---|---|---|
| حافظه HBM به ازای GPU برحسب گیگابایت | 80 | 80 | 192 | 192 |
| پهنای باند HBM برحسب ترابایت بر ثانیه | 3.35 | 3.35 | 8.00 | 8.00 |
| بیت‌های وزن | 16 | 8 | 4 | 4 |
| بیت‌های کش کلید-مقدار | 16 | 8 | 8 | 8 |
| ضریب MTP | 1.0 | 1.0 | 1.8 | 1.8 |
| ضریب تفکیک (Disaggregation) | 1.0 | 1.0 | 1.6 | 2.5 |
| هزینه به ازای هر ساعت کار GPU | 2.50 | 2.50 | 4.80 | 6.20 |
اجرای شبیه‌سازها
کار و کد| وظیفه | کد |
|---|---|
| بچینگ ایستا | simulate_static(reqs, batch=16) |
| پیوسته به‌همراه تکه‌ای | simulate_continuous(reqs, chunked=True) |
| ترتیب رادیکس آگاه از کش | simulate(requests, "CACHE_AWARE") |
| ترتیب پیشوند درهم‌ریخته | workload_scrambled(n=80, docs=4) |
| ردپای HBM به ازای هر استک | hbm_footprint_gb(params_b, active_b, seq_len, stack) |
| هزینه به ازای یک میلیون توکن | cost_per_million_tokens(active_b, stack) |
| LMCache تحت فشار حافظه‌ی HBM | simulate("LMCACHE", reqs) |
| موتور مناسب محدودیت‌های شما | pick_engine(hardware, scale, workload) |
عیب‌یابی
عیبیابیتوقف رمزگشایی در پرامپت‌های طولانی
- علت
- فریز شدن رمزگشایی ناشی از پیش‌پرکنی
- راه‌حل
- پیش‌پرکنی تکه‌ای؛ کاهش P99 ITL از حدود 50 میلی‌ثانیه به 15 میلی‌ثانیه
نرخ اصابت 7٪ در پرامپت‌های مشترک
- علت
- محتوای پویا در بخش پیشوند
- راه‌حل
- قرار دادن بخش‌های ثابت در ابتدا؛ ارتقای نرخ از 7٪ به 74٪
از دست رفتن جهش کارایی 6.4 برابری
- علت
- تغییر ترتیب قالب به ازای هر درخواست
- راه‌حل
- ثابت کردن ترتیب اجزا
تکمیل ظرفیت 100٪ حافظه‌ی HBM و پیش‌پرکنی مجدد پرامپت‌های یکسان
- علت
- حذف KV بر اثر پیش‌دستی
- راه‌حل
- تخلیه روی پردازنده‌ی اصلی به‌صورت محلی یا استفاده از LMCache
3 تا 5 درصد کندتر با LMCache
- علت
- فشار ناچیز روی HBM
- راه‌حل
- خاموش کردن LMCache
افت دقت پس از اعمال NVFP4
- علت
- وزن‌های FP4 در وظایف استدلالی
- راه‌حل
- وزن‌های FP8 به همراه فعال‌سازهای FP4
فروپاشی اتنشن در FP4 KV
- علت
- نیاز KV به دامنه‌ی پویای بیشتر
- راه‌حل
- نگه‌داشتن کش کلید-مقدار در فرمت FP8
خرابی هم‌زمان قابلیت‌ها
- علت
- ترکیب تعریف‌نشده در ماتریس سازگاری
- راه‌حل
- بررسی ماتریس سازگاری نسخه‌ی فعلی
پرسش و پاسخ
پرسش و پاسخ- چرا FCFS برای ترافیک پیشوندی نامناسب است؟
- شاخه‌ی داغ را برای پذیرش درخواست‌هایی با پیشوند کوتاه حذف می‌کند.
- پیش‌پرکنی تکه‌ای چه چیزی را بهبود می‌دهد؟
- تاخیرهای صدک بالای TTFT و ITL؛ نه میانگین نرخ پردازش را.
- شکاف کارایی 7 برابری TRT-LLM ناشی از چیست؟
- پهنای باند HBM، وزن‌های NVFP4، قابلیت MTP و تفکیک وظایف.
- آیا LMCache برای پرامپت‌های زیر 1,000 توکن مناسب است؟
- خیر؛ زمان انتقال بیش از پیش‌پرکنی مجدد طول می‌کشد.
- آیا PagedAttention باید فعال شود؟
- فلگی ندارد؛ تنها تخصیص‌دهنده‌ی داخلی vLLM است.
- آیا vLLM پیشوندها را مجدداً استفاده می‌کند؟
- بله، با فلگ
--enable-prefix-caching؛ درحالی‌که SGLang ذاتا مبتنی بر رادیکس است.
واژه‌نامه
اصطلاح‌ها- ITL
- تاخیر بین‌توکنی؛ زمان سپری‌شده میان دو توکن رمزگشایی.
- TTFT
- زمان تا اولین توکن؛ مجموع پیش‌پرکنی، صف و شبکه.
- FCFS
- سیستم نوبت‌دهی اولویت با ورود؛ باعث تضعیف محلی‌سازی پیشوند می‌شود.
- NVFP4
- فرمت میکرومقیاس‌بندی 4 بیتی انویدیا برای وزن‌ها و فعال‌سازها.
- MTP
- پیش‌بینی چندتوکنی؛ پیش‌نویس ادغام‌شده در TRT-LLM.
- MXFP8
- نسخه‌ی میکرومقیاس‌بندی FP8 روی هسته‌های تنسور Blackwell.
- Connector API
- رابط حافظه‌ی ماژولار KV از نسخه‌ی 0.9.0 vLLM به بعد.
- Preemption
- بازآرایی و جابه‌جایی کش کلید-مقدار در زمان پر شدن HBM.