Speculative Decoding تاخیر استنتاج LLM را تا ۳ برابر کاهش میدهد بدون افت دقت

مدلهای زبانی بزرگ (LLM) هر بار یک Token تولید میکنند و هر Token نیازمند یک forward pass کامل روی میلیاردها پارامتر است. همین وابستگی ترتیبی دلیل اصلی هزینه بالای inference است. Speculative decoding این گلوگاه را میشکند؛ نه با تغییر مدل، بلکه با تغییر استراتژی تولید. این تکنیک میتواند latency واقعی را در کارهایی مثل تکمیل کد و چت ۲ تا ۳ برابر کاهش دهد، بدون اینکه کیفیت خروجی افت کند.

مکانیسم اصلی

Speculative decoding از دو مدل استفاده میکند: یک "draft model" کوچک و یک "target model" بزرگ. draft model سریعاً چند Token کاندید تولید میکند. سپس target model همه این کاندیدها را در یک forward pass موازی ارزیابی میکند — Tokenهایی را که خودش هم پیشبینی میکرده میپذیرد و بقیه را رد میکند. وقتی یک Token رد میشود، تولید به توزیع target model برای آن موقعیت برمیگردد و فرآیند از نو شروع میشود.

از آنجایی که forward pass target model روی یک batch از Tokenهای کاندید فقط کمی گرانتر از forward pass تکتراست (به لطف parallelism در GPU)، نتیجه نهایی این است که Token بیشتری به ازای واحد محاسبه تولید میشود. ریاضیات وقتی کار میکند که draft model توافق منطقی با target داشته باشد — معمولاً ۷۰ تا ۸۵ درصد نرخ پذیرش Token در کارهای واقعی و ساختاری مثل تولید کد.

چرا نرخ پذیرش همه چیز است

افزایش سرعت از speculative decoding به طور مستقیم با میانگین تعداد Tokenهای draft که قبل از رد شدن پذیرفته میشوند، مقیاس میشود. روی Benchmarkهای رایج کدنویسی مثل HumanEval، نرخ پذیرش با یک draft model مناسب حدود ۷۵ تا ۸۰ درصد است که منجر به کاهش latency ۲.۵ تا ۳ برابری میشود. در کارهای خلاقانه و باز، نرخ پذیرش به ۵۵ تا ۶۵ درصد میرسد و افزایش سرعت به ۱.۵ تا ۲ برابر کاهش مییابد.

این یعنی انتخاب draft model بسیار مهم است. تحقیقات DeepMind در سال ۲۰۲۳ (مقاله اصلی speculative decoding از Leviathan و همکاران) نشان داد که حتی یک تفاوت اندازه ۳ مرتبه بزرگی — draft با ۷ میلیارد پارامتر در مقابل target با ۷۰ میلیارد — همچنان افزایش سرعت معناداری به همراه دارد زیرا پیشبینیهای مدل کوچکتر به طرز شگفتآوری با مدل بزرگتر در کارهای ساختاری همسو است.

Self-Speculative Decoding: بدون نیاز به Draft Model

یکی از موانع عملی استفاده از speculative decoding در تولید، سربار اجرا و نگهداری یک draft model جداگانه است. Self-speculative decoding که در سال ۲۰۲۴ توسط محققان CMU و مایکروسافت معرفی شد، این نیاز را حذف میکند. این رویکرد از خروج زودهنگام از لایههای میانی خود target model به عنوان مکانیزم draft استفاده میکند. به طور خاص، Tokenها را از زیرمجموعهای از لایههای مدل عبور میدهد تا یک draft سریع تولید کند، سپس با کل مدل اعتبارسنجی میکند.

روش EAGLE-2 (از محققان دانشگاه پکن، همچنین ۲۰۲۴) رویکرد متفاوتی دارد: یک "draft head" سبک و تک لایه آموزش میدهد که به target model متصل میشود و Tokenهای آینده را بر اساس hidden states داخلی پیشبینی میکند. EAGLE-2 در MT-Bench به نرخ پذیرش بالای ۸۰ درصد رسید و throughput را نسبت به روشهای قبلی speculative روی A100 GPUها ۲۰ تا ۴۰ درصد افزایش داد. draft head کمتر از ۱٪ به تعداد پارامترهای مدل اضافه میکند.

استقرار در تولید

Speculative decoding دیگر فقط یک کنجکاوی تحقیقاتی نیست. زیرساخت سرویسدهی تولید گوگل برای Gemini از آن استفاده میکند. Anthropic نیز استفاده از روشهای speculative را در سرویسدهی Claude شرح داده است. Framework vLLM (محبوبترین کتابخانه Open Source برای سرویسدهی LLM، با بیش از ۳۰٬۰۰۰ ستاره در GitHub) پشتیبانی از speculative decoding را در نسخه ۰.۳ در اوایل ۲۰۲۴ ارائه داد.

برای سازمانهایی که stack inference خود را اجرا میکنند، پیامدهای عملی مستقیم است: همان سختافزاری که یک مدل ۷۰ میلیاردی را با سرعت ۲۰ Token بر ثانیه سرویس میدهد، میتواند با speculative decoding تنظیمشده به ۵۰ تا ۶۰ Token بر ثانیه برسد. این یعنی کاهش ۲.۵ تا ۳ برابری هزینه به ازای هر Token بدون هیچ تغییری در مدل، quantization، یا معاوضه دقت.

محدودیتها و زمانهایی که کمک نمیکند

Speculative decoding به latency کمک میکند — زمان تولید پاسخ — اما کل محاسبات را کاهش نمیدهد. در واقع، به دلیل Tokenهای draft رد شده، FLOPs کل را کمی افزایش میدهد. این به این معنی است که هزینه انرژی هر درخواست را کاهش نمیدهد؛ بلکه زمان تا تکمیل را کاهش میدهد که برای latency کاربر اهمیت دارد اما برای throughput پردازش دستهای (batch processing) نه.

همچنین در کارهای با entropy بالا بدترین عملکرد را دارد: نوشتن خلاقانه، طوفان فکری، یا هر خروجی که مدل در هر گام عدم قطعیت بالایی دارد. در این موارد، نرخ پذیرش draft به زیر ۶۰٪ میرسد و سربار اجرای draft model شروع به خوردن gains میکند.

نکات عملی

• اگر از Llama 3.1 70B یا مدلهای مشابه با vLLM استفاده میکنید: speculative decoding را با یک مدل کوچک متناسب (مثلاً Llama 3.2 3B به عنوان draft) فعال کنید. انتظار بهبود latency ۲ تا ۲.۵ برابری در کارهای چت/کد با حداقل تنظیمات داشته باشید.
• اگر روی APIهای میزبانشده (hosted APIs) کار میکنید: speculative decoding احتمالاً از قبل در backend در حال اجراست. تلاش بهینهسازی خود را روی ساختار Prompt و بهرهوری Token متمرکز کنید.
• اگر latency گلوگاه شماست اما هزینه نه: speculative decoding بهترین اهرم شماست — برای کارهای حساس به کیفیت از quantization بهتر است و نیازی به retraining مدل ندارد.
• اگر batch inference (خلاصهسازی، طبقهبندی در مقیاس) دارید: speculative decoding کمکی نمیکند. به جای آن به دنبال continuous batching و quantization باشید.