vLLM در برابر پیاده‌سازی‌های بومی؛ برابری سرعت در محیط تولید

تصور کنید مدل جدیدی ساخته‌اید و حالا باید هفته‌ها وقت صرف کنید تا آن را برای اجرا در محیط واقعی بهینه کنید؛ این دقیقاً همان گلوگاهی است که امروز شکسته شد. چرا باید بین انعطاف‌پذیری یک بک‌اِند مدل‌سازی کلی و سرعت خام یک نسخه پورت‌شده سفارشی یکی را انتخاب کنیم؟ طبق اعلام Hugging Face در ۸ ژوئیه ۲۰۲۶، بک‌اِند ترنسفورمر در vLLM اکنون در معماری‌های مختلف Qwen3، توان عملیاتی (Throughput) کاملاً مشابه با پیاده‌سازی‌های بومی و دست‌نویس دارد و به‌طور مؤثر جریمه‌های عملکردی سنتی را حذف نموده است.

زمینه (Context)

به‌طور تاریخی، صنعت هوش مصنوعی کتابخانه ترنسفورمر (Transformers) را صرفاً به عنوان یک مرجع برای بررسی معماری می‌شناخت و آن را برای محیط‌های عملیاتی و تولید (Production) بسیار کند می‌دانست. این کتابخانه با پشتیبانی از بیش از ۴۵۰ معماری از طریق APIهای سازگار، به‌گونه‌ای طراحی شده است که جامع و برای درک آسان باشد. همین ویژگی، آن را به نقطه شروع ایده‌آلی برای مشارکت‌کنندگانی تبدیل کرده است تا پیش از پورت کردن یک معماری به چارچوب‌هایی مثل vLLM، SGLang، MLX یا llama.cpp، ابتدا آن را یاد بگیرند.

برای رسیدن به حداکثر سرعت، توسعه‌دهندگان پیش از این مجبور بودند مدل‌ها را به‌صورت دستی به vLLM منتقل کنند؛ فرآیند خسته‌کننده‌ای که منجر به ایجاد یک گلوگاه برای انتشار مدل‌های جدید می‌شد. ادغام ترنسفورمر به‌عنوان یک بک‌اِند مدل‌سازی از سال گذشته آغاز شد تا کاربران بتوانند مدل‌های زبانی بزرگ (LLM) و مدل‌های بینایی-زبانی (VLM) را بدون نیاز به پورت کردن، درون vLLM اجرا کنند. اگرچه vLLM قابلیت‌هایی نظیر دسته‌بندی پیوسته (Continuous Batching) و کرنل‌های توجه سفارشی را ارائه می‌داد، اما بسیاری از ابعاد استقرار مدل برای رسیدن به بالاترین بازدهی، همچنان به پورت‌های سفارشی نیاز داشتند. همان‌طور که در تحلیل قبلی ما درباره‌ی برتری رقابتی vLLM در برابر ابزارهایی مثل لاماسیسی‌پلاس‌پلاس (llama.cpp) اشاره کردیم، این به‌روزرسانی اکنون شکاف میان انعطاف‌پذیری و عملکرد خام را می‌بندد. این رویکرد برای تسهیل استقرار مدل‌های باز در مقیاس بالا است، مشابه آنچه توسعه‌دهندگان در NovaStack برای تلفیق انعطاف‌پذیری و مقیاس‌پذیری به کار می‌گیرند.

جزئیات عملکرد (Performance Details)

بر اساس گزارش Hugging Face، این بک‌اِند جدید در یک تقابل مستقیم با پیاده‌سازی‌های بومی vLLM روی یک گره ۸×H100 در سه مدل متمایز آزمایش شد:

• Qwen3-4B: یک مدل متراکم (Dense) که روی یک تک GPU اجرا می‌شود.
• Qwen3-32B: مدل متراکم که از موازی‌سازی تانسور (Tensor Parallelism) بهره می‌برد.
• Qwen3-235B-A22B-FP8: یک مدل ترکیب خبره‌ها (Mixture-of-Experts یا MoE) — شبیه به تیمی از متخصصان که هر سوال را به فرد خبره می‌سپارند — که از هر دو نوع موازی‌سازی داده (Data Parallelism) و موازی‌سازی خبره (Expert Parallelism) استفاده می‌کند.

در تمامی این موارد آزمایشی، بک‌اِند مدل‌سازی ترنسفورمر توانست با توان عملیاتی بومی برابری کند یا حتی از آن پیشی بگیرد. هر مدل تحت سه شرایط یکسان اندازه‌گیری شد: حالت «بومی» (با پرچم --model-impl vllm)، حالت «بعد از» (با PR جدید) و حالت «قبل» (بدون اعمال تغییرات جدید). کاربران برای فعال‌سازی این قابلیت، تنها باید پرچم --model-impl transformers را به دستور اجرای سرویس خود اضافه کنند.

به‌عنوان مثال، کاربران می‌توانند مدل متراکم Qwen3-32B را روی ۲ پردازنده گرافیکی با دستور vllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2 اجرا کنند، یا مدل MoE ۲۳۵ میلیاردی را روی ۸ پردازنده گرافیکی با دستور vllm serve Qwen/Qwen3-235B-A22B-FP8 --model-impl transformers --data-parallel-size 8 --enable-expert-parallel مستقر نمایند.

مکانیزم فنی (Technical Mechanism)

این جهش سرعت مدیون مکانیزم جدیدی است که از torch.fx برای تحلیل استاتیک گراف مدل استفاده می‌کند. این ابزار به vLLM اجازه می‌دهد الگوهای شناخته‌‌شده را شناسایی کرده و سپس با استفاده از یک درخت نحو انتزاعی (AST)، کد منبع را در زمان اجرا (Runtime) به‌صورت درجا بازنویسی کند.

به‌طور مشخص، سیستم اکنون ادغام لایه‌ها (Layer Fusions) را به‌صورت خودکار انجام می‌دهد:

• نگاشت چند-به-یک (Many-to-one mapping): عملیات‌ها به کرنل‌های فوق‌بهینه‌ vLLM متصل می‌شوند؛ مانند کرنل‌های مورد استفاده برای موازی‌سازی خبره (EP) در مدل‌های MoE.
• برنامه‌ریزی موازی (Parallel Planning): سیستم از بلوک‌های MergedColumnParallelLinear و QKVParallelLinear برای استخراج طرح‌های موازی‌سازی تانسور (TP) استفاده می‌کند. همچنین اگر لیست بلوک‌های دکودر قابل شناسایی باشد، طرح‌های موازی‌سازی خط لوله (PP) نیز استخراج می‌شوند.

از آنجا که این مدل‌های تغییریافته همچنان از طریق torch.compile و گراف‌های CUDA کاملاً قابل کامپایل هستند، بازدهی یک پیاده‌سازی اختصاصی و متمرکز را حفظ می‌کنند. تفاوت حیاتی در این است که اکنون می‌توان از یک کد واحد برای آموزش، ارزیابی و رول‌اوت‌های RL (یادگیری تقویت شده) استفاده کرد، به جای اینکه دو کدبیس مجزا برای تحقیق و تولید نگهداری شود.

این تغییر، انگیزه‌ی نویسندگان مدل را به‌طور بنیادی دگرگون می‌کند. دیگر نیاز به انتخاب سخت بین اکوسیستم راحتِ ترنسفورمر و سرعتِ vLLM نیست؛ در واقع مرحله‌ی «پورت کردن» در چرخه حیات یک مدل، عملاً در حال خودکار شدن است. برای توسعه‌دهندگان، این به معنای کاهش زمان رسیدن به بازار (Time-to-Market) برای معماری‌های جدید است. سد ورود برای سرویس‌دهی با کارایی بالا، از نیاز به داشتن یک مهندس متخصص کرنل، به رعایت ساده‌ی استانداردهای کدنویسی کتابخانه ترنسفورمر کاهش یافته است.

کاربران می‌توانند با دستور uv pip install --upgrade vllm --torch-backend auto این به‌روزرسانی را دریافت کرده و فوراً از این بهبودها بهره‌مند شوند.

در حالی که اکثر مدل‌ها اکنون پشتیبانی می‌شوند، مدل‌های دارای توجه خطی (Linear Attention) فعلاً خارج از این scope هستند. علاوه بر این، مدل‌های سفارشی که در مخازن Hub میزبانی شده‌اند اما استانداردهای کدنویسی سازگار را رعایت نکرده‌اند، ممکن است همچنان به پورت‌های بومی نیاز داشته باشند.

گام بعدی شما

• اگر مدل‌های اختصاصی روی Hugging Face دارید، آن‌ها را با پرچم جدید در vLLM تست کنید تا تفاوت سرعت را بسنجید.
• بررسی کنید آیا کدهای مدل شما با استانداردهای کتابخانه Transformers سازگار است تا از مزایای خودکار-بهینه‌سازی بهره ببرید.
• برای کاهش هزینه‌های استنتاج در مقیاس بالا، ترکیب این بک‌اِند با کوانتش وزن‌ها را امتحان کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.