۵,۰۰۰ توکن در ثانیه؛ این عددی است که هنگام سرویسدهی به مدل Llama 3.1 8B روی یک GPU مدل A100 با استفاده از vLLM به دست میآید، در حالی که این رقم در کتابخانه استاندارد HuggingFace Transformers تنها حدود ۵۰۰ توکن در ثانیه است. طبق یک تحلیل فنی عمیق که در ۷ اوت ۲۰۲۶ منتشر شد، این جهش عظیم به این دلیل رخ داده که این موتور گلوگاه اصلی هوش مصنوعی مدرن، یعنی پهنایباند حافظه را هدف قرار داده است، نه قدرت خام محاسباتی.
گلوگاه حافظه
بسیاری از بارهای کاری مدلهای زبانی بزرگ (LLM) در محیطهای عملیاتی، محدود به حافظه (Memory-bound) هستند، نه محدود به محاسبات (Compute-bound). این بدان معناست که GPU بیشتر زمان خود را منتظر رسیدن وزنهای مدل از حافظه میماند تا اینکه واقعاً مشغول انجام محاسبات باشد. به همین دلیل است که صرفاً اضافه کردن GPUهای بیشتر، لزوماً توان عملیاتی را به صورت خطی افزایش نمیدهد؛ زیرا مشکل اصلی پهنایباند حافظه است، نه تعداد عملیات ممیز شناور در ثانیه (FLOPs).
همانطور که در تحلیل قبلی ما دربارهی آستانه ۳۲ گیگابایت رم برای مدلهای محلی اشاره کردیم، تمرکز صنعت اکنون از «چگونه مدل را در حافظه جای دهیم» به «چگونه حافظه را هنگام تولید فعال مدیریت کنیم» تغییر کرده است. در همین راستا، تکنیکهایی مانند TriAttention توانستهاند مصرف حافظه مدلهای زبانی را تا ۱۰ برابر کاهش دهند تا بهرهوری در لایههای عمیقتر مدل افزایش یابد. vLLM برای حل این مشکل از سه محور عمل میکند: PagedAttention برای بهرهوری، دستهبندی پیوسته برای توان عملیاتی و هستههای بهینهشده CUDA برای سرعت.
مکانیزم PagedAttention
vLLM مکانیزمی به نام PagedAttention را معرفی میکند که KV Cache (حافظهای که حالتهای میانی را ذخیره میکند) را شبیه به نحوه مدیریت حافظه مجازی در یک سیستمعامل مدیریت میکند. در موتورهای استنتاج سنتی، بلوکهای متوالی و پیوسته از حافظه برای هر درخواست رزرو میشد. این رویکرد توسعهدهندگان را مجبور میکرد تا بلوکهای بزرگی از حافظه را پیشتخصیص دهند؛ امری که اگر درخواست کوتاه بود باعث اتلاف شدید حافظه میشد و در نهایت تعداد درخواستهایی که میتوانستند به طور همزمان سرویس داده شوند را محدود میکرد.
PagedAttention این روند را تغییر میدهد و KV Cache را به صفحاتی با اندازه ثابت (Blocks) تقسیم میکند. در این حالت، حافظه هر درخواست به جای یک بلوک پیوسته، به مجموعهای از صفحات تبدیل میشود. این تغییر امکانات زیر را فراهم میکند:
- تخصیص حافظه بر اساس نیاز (On-demand) برای حذف کامل اتلاف.
- به حداقل رساندن تکهتکه شدن (Fragmentation) منابع GPU.
- افزایش ۲ تا ۴ برابری ظرفیت درخواستهای همزمان در مقایسه با موتورهای پیشفرض HuggingFace.
دستهبندی پیوسته و عملکرد
علاوه بر مدیریت حافظه، vLLM از دستهبندی پیوسته (Continuous Batching) استفاده میکند. در استنتاج سنتی از «دستهبندی استاتیک» استفاده میشد؛ جایی که سیستم منتظر میماند تا تعداد N درخواست جمع شود، برای همه آنها یک توکن تولید کند و این چرخه را تکرار نماید. در این مدل، اگر یک درخواست زودتر تمام شود، باید منتظر بماند تا بقیه درخواستهای دسته کامل شوند. همچنین اگر درخواست جدیدی در میانه یک دسته برسد، باید منتظر شروع دسته بعدی بماند.
اما دستهبندی پیوسته به صورت پویا عمل میکند: درخواستها در هر مرز توکنی میتوانند وارد یا خارج از دسته شوند. وقتی یک درخواست به پایان میرسد، بلافاصله دسته را ترک میکند و وقتی درخواست جدیدی میرسد، بدون معطلی به دسته جاری میپیوندد. این قابلیت برای بارهای کاری ترکیبی — جایی که یک کاربر تنها یک جمله میخواهد و کاربر دیگر یک مقاله ۲۰۰۰ کلمهای درخواست میکند — حیاتی است و توان عملیاتی کلی را از ۱۰ توکن در ثانیه به بیش از ۱۰۰ توکن در ثانیه میرساند. این بهینهسازیهای نرمافزاری در کنار سختافزارهای پیشرفته، نتایج خیرهکنندهای ایجاد کردهاند؛ برای مثال در سیستمهای DGX Spark، سرعت استنتاج مدل Qwen3.5 به ۷۸ توکن در ثانیه رسیده است.
در یک مقایسه مستقیم روی یک کارت A100 (۸۰ گیگابایت) برای سرویسدهی به مدل Llama 3.1 8B با پنجره بافت (Context) ۱ هزار توکنی، نتایج تکاندهنده است:
- HuggingFace Transformers: حدود ۵۰۰ توکن در ثانیه (۸ درخواست همزمان، ۴۰٪ بهرهوری حافظه).
- TGI (HuggingFace): حدود ۲,۰۰۰ توکن در ثانیه (۳۲ درخواست همزمان، ۶۰٪ بهرهوری حافظه).
- vLLM: بیش از ۵,۰۰۰ توکن در ثانیه (۶۴+ درخواست همزمان، بیش از ۹۰٪ بهرهوری حافظه).
این نتایج ثابت میکند که لایه نرمافزاری اکنون به اندازه سختافزار تعیینکننده است. شرکتی که ۳۰ هزار دلار برای یک H100 هزینه میکند اما از موتوری استفاده میکند که ۶۰٪ حافظه را هدر میدهد، در واقع هزینه یک تراشه تراز اول را پرداخت میکند اما عملکردی در سطح یک GPU ۱۲ هزار دلاری دریافت میکند.
استقرار و جایگزینها
برای کسانی که مدلهای بین ۷ تا ۷۰ میلیارد پارامتر را مستقر میکنند، vLLM یک API سازگار با OpenAI ارائه میدهد. نصب آن از طریق دستور pip install vllm بسیار ساده است. یک مدل را میتوان با یک دستور واحد با استفاده از python -m vllm.entrypoints.openai.api_server فعال کرد، به شرطی که مدل (مثلاً meta-llama/Llama-3.1-8B-Instruct)، اندازه موازیسازی تنسور (tensor-parallel-size) و حداکثر طول مدل (مثلاً ۸۱۹۲) مشخص شده باشد. این دستور یک API روی پورت ۸۰۰۰ باز میکند.
در انتخاب موتور استنتاج، این توازنها را در نظر بگیرید:
- vLLM: بهترین گزینه برای محیطهای عملیاتی (Production)، مدلهای ۷ تا ۷۰ میلیارد پارامتری و دستیابی به حداکثر توان عملیاتی. برای مدیریت مقیاسپذیر این موتورها در محیطهای ابری، ترکیب KServe و KEDA میتواند گلوگاههای مقیاسدهی GPU در کوبرنتیز را به طور کامل رفع کند.
- Ollama: بهترین برای توسعه محلی روی مکبوکها یا رزبریپایها با استفاده از مدلهای کوچک (۱ تا ۳ میلیارد پارامتر).
- TGI: بهترین برای کسانی که در اکوسیستم HuggingFace هستند یا زمانی که به کنترل بسیار دقیق روی پارامترهای رمزگشایی (Decoding) نیاز دارند.
- APIهای تجاری: بهترین برای دسترسی به کیفیت مدلهای پیشرو (Frontier) یا حجم استفاده پایین که در آن مدیریت زیرساخت مطلوب نیست.
توسعهدهندگان اکنون باید هزینههای استنتاج فعلی خود را با این بنچمارکها ارزیابی کنند تا ببینند آیا یک مهاجرت نرمافزاری میتواند نیاز به ارتقای سختافزاری گرانقیمت را به تأخیر بیندازد. مرز بعدی احتمالاً این خواهد بود که چگونه این تکنیکهای مدیریت حافظه با پنجرههای بافت بسیار بزرگتر در مدلهای پیشرو سازگار میشوند.
گام بعدی شما
- اگر از مدلهای متنباز در محیط تولید استفاده میکنید، هزینه استنتاج فعلی خود را با بنچمارکهای vLLM مقایسه کنید تا ببینید آیا مهاجرت نرمافزاری میتواند نیاز به ارتقای سختافزاری گرانقیمت را به تأخیر بیندازد.
- برای مدلهای زیر ۷ میلیارد پارامتر، ابتدا Ollama را برای تست سریع امتحان کنید و سپس برای مقیاسدهی به vLLM کوچ کنید.
- مستندات PagedAttention را مطالعه کنید تا متوجه شوید چگونه مدیریت حافظه میتواند تأخیر (Latency) را در درخواستهای طولانی کاهش دهد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو