مدل‌های زبانی بزرگ می‌توانند متن‌هایی باکیفیت تولید کنند، اما فرایند تولید پاسخ در آن‌ها ذاتاً ترتیبی است. مدل ابتدا Token بعدی را تولید می‌کند، سپس همان Token را برای پیش‌بینی Token بعدی به کار می‌گیرد.

این وابستگی مرحله‌به‌مرحله باعث می‌شود تولید یک پاسخ طولانی به صدها یا هزاران اجرای متوالی مدل نیاز داشته باشد.

Speculative Decoding یکی از روش‌های مهم برای کاهش این محدودیت است. در این روش، یک مدل کوچک و سریع چند Token آینده را حدس می‌زند و مدل اصلی تمام آن‌ها را در یک مرحله بررسی می‌کند.

اگر حدس‌ها درست باشند، چند Token با یک اجرای مدل اصلی پذیرفته می‌شوند. در نتیجه، تعداد مرحله‌های متوالی کاهش پیدا می‌کند و پاسخ سریع‌تر تولید می‌شود.

پاسخ کوتاه: Speculative Decoding چیست؟

Speculative Decoding یا رمزگشایی گمانه‌زنانه روشی برای افزایش سرعت Inference مدل‌های زبانی است که در آن:

1. یک مدل کوچک به نام Draft Model چند Token آینده را پیشنهاد می‌دهد.
2. مدل اصلی یا Target Model همه Tokenهای پیشنهادی را به‌صورت موازی بررسی می‌کند.
3. Tokenهای قابل‌قبول وارد پاسخ نهایی می‌شوند.
4. از اولین Token ردشده به بعد، فرایند اصلاح یا تولید مجدد انجام می‌شود.
5. این چرخه تا پایان پاسخ تکرار می‌شود.

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

پژوهش اولیه Speculative Decoding نشان داد می‌توان بدون تغییر خروجی مورد انتظار مدل، چند Token را به‌صورت موازی بررسی و فرایند تولید را سریع‌تر کرد. منبع: Fast Inference from Transformers via Speculative Decoding

چرا تولید Token در LLM کند است؟

مدل‌های زبانی Autoregressive پاسخ را به شکل ترتیبی تولید می‌کنند:

[
P(x_1,x_2,\dots,x_n)

\prod_{t=1}^{n}
P(x_t \mid x_1,\dots,x_{t-1})
]

یعنی احتمال هر Token به تمام Tokenهای قبلی وابسته است.

اگر مدل بخواهد ۱۰۰ Token تولید کند، معمولاً باید ۱۰۰ مرحله Decoding متوالی انجام شود. هر مرحله نیز نیازمند اجرای Forward Pass و دسترسی به وزن‌های بزرگ مدل است.

فرایند عادی:

Prompt
  ↓
Token 1
  ↓
Token 2
  ↓
Token 3
  ↓
Token 4
  ↓
...

GPUها در محاسبات موازی بسیار قدرتمند هستند، اما تولید Autoregressive مدل را مجبور می‌کند Tokenها را یکی‌یکی بسازد. Speculative Decoding تلاش می‌کند بخشی از این محدودیت ترتیبی را به پردازش موازی تبدیل کند.

ایده اصلی Speculative Decoding

فرض کنید مدل اصلی بسیار قدرتمند اما کند است. در کنار آن یک مدل کوچک‌تر داریم که سرعت بیشتری دارد، اما کیفیت آن پایین‌تر است.

مدل کوچک می‌تواند چند Token احتمالی را سریع پیشنهاد دهد:

مدل کوچک:
«هوش مصنوعی می‌تواند در پردازش زبان»

مدل بزرگ به‌جای آنکه هر Token را جداگانه تولید کند، کل ادامه پیشنهادی را در یک Forward Pass بررسی می‌کند:

هوش → پذیرفته
مصنوعی → پذیرفته
می‌تواند → پذیرفته
در → پذیرفته
پردازش → رد

در این مثال، چهار Token اول هم‌زمان پذیرفته می‌شوند. مدل اصلی از نقطه ردشدن به بعد مسیر را اصلاح می‌کند.

اگر Draft Model شباهت مناسبی به Target Model داشته باشد، نرخ پذیرش بالا می‌رود و تعداد فراخوانی‌های سنگین مدل اصلی کاهش پیدا می‌کند.

اجزای اصلی Speculative Decoding

Target Model

Target Model همان مدل اصلی است که می‌خواهیم خروجی آن را تولید کنیم.

این مدل:

• کیفیت نهایی را تعیین می‌کند.
• Tokenهای پیشنهادی را بررسی می‌کند.
• درباره پذیرش یا رد Candidateها تصمیم می‌گیرد.
• در صورت ردشدن، توزیع صحیح را برای ادامه تولید فراهم می‌کند.

Target Model معمولاً بخش پرهزینه و کند سیستم است.

Draft Model

Draft Model یک مدل کوچک‌تر و سریع‌تر است که چند Token آینده را پیشنهاد می‌دهد.

یک Draft Model مناسب باید:

• از Target Model سریع‌تر باشد.
• رفتار نسبتاً مشابهی داشته باشد.
• Tokenizer سازگار داشته باشد یا امکان تطبیق Token وجود داشته باشد.
• حافظه زیادی مصرف نکند.
• نرخ پذیرش مناسبی ایجاد کند.

کوچک‌ترین مدل همیشه بهترین Draft Model نیست. اگر مدل بیش از حد ضعیف باشد، Candidateهای زیادی رد می‌شوند و هزینه اجرای آن عملاً هدر می‌رود.

Candidate Tokens

Candidateها همان Tokenهایی هستند که Draft Model برای آینده پیشنهاد می‌کند.

تعداد این Tokenها را می‌توان Draft Length یا Speculation Length نامید.

اگر این مقدار پنج باشد، Draft Model در هر مرحله پنج Token پیشنهاد می‌دهد.

Draft Length بزرگ‌تر می‌تواند تعداد بیشتری Token را در یک مرحله جلو ببرد؛ اما اگر نرخ پذیرش پایین باشد، بخش زیادی از آن‌ها دور ریخته می‌شوند.

Verification

Target Model تمام Candidateها را به‌صورت موازی امتیازدهی می‌کند. سپس الگوریتم مشخص می‌کند کدام Tokenها قابل‌پذیرش هستند.

در تولید Greedy، بررسی می‌تواند ساده‌تر باشد: Candidate با انتخاب Target Model مقایسه می‌شود.

در Sampling، برای حفظ توزیع مدل اصلی به روش پذیرش و بازنمونه‌گیری دقیق‌تری نیاز است.

Speculative Decoding مرحله‌به‌مرحله

فرض کنید Draft Model چهار Token را پیشنهاد می‌دهد:

[
\tilde{x}_1,\tilde{x}_2,\tilde{x}_3,\tilde{x}_4
]

مراحل اجرا به این شکل هستند:

مرحله اول: تولید Candidate

Draft Model Tokenها را به‌صورت Autoregressive اما سریع تولید می‌کند.

Token پیشنهادی ۱
Token پیشنهادی ۲
Token پیشنهادی ۳
Token پیشنهادی ۴

مرحله دوم: بررسی موازی

Target Model احتمال تمام Tokenهای پیشنهادی را در یک Forward Pass محاسبه می‌کند.

مرحله سوم: پذیرش Tokenها

Tokenها از ابتدا بررسی می‌شوند. تا زمانی که Candidateها معتبر باشند، در خروجی پذیرفته می‌شوند.

مرحله چهارم: رسیدگی به اولین رد

وقتی Candidate نامعتبر باشد:

• آن Token و Candidateهای بعدی کنار گذاشته می‌شوند.
• Token جایگزین براساس توزیع Target Model انتخاب می‌شود.
• فرایند Speculation از Context جدید ادامه پیدا می‌کند.

مرحله پنجم: تکرار

Draft Model دوباره چند Token بعدی را پیشنهاد می‌دهد و Target Model آن‌ها را بررسی می‌کند.

چرا Target Model می‌تواند چند Token را هم‌زمان بررسی کند؟

تولید Tokenها به‌صورت Autoregressive ترتیبی است؛ اما اگر Candidateها از قبل مشخص باشند، Target Model می‌تواند احتمال آن‌ها را در موقعیت‌های مختلف به‌صورت موازی محاسبه کند.

این تفاوت مهم است:

• Generation: مدل هنوز نمی‌داند Token بعدی چیست و باید مرحله‌به‌مرحله آن را تولید کند.
• Verification: Candidateها از قبل موجودند و می‌توان چند موقعیت را هم‌زمان ارزیابی کرد.

Speculative Decoding هزینه تولید اولیه Candidateها را به مدل کوچک واگذار و از توان موازی GPU برای Verification استفاده می‌کند.

آیا Speculative Decoding کیفیت پاسخ را کاهش می‌دهد؟

در پیاده‌سازی Lossless و صحیح، پاسخ باید از همان توزیع Target Model نمونه‌برداری شود. بنابراین Speculative Decoding قرار نیست کیفیت مدل اصلی را کاهش دهد یا خروجی Draft Model را مستقیماً جایگزین آن کند.

پژوهش DeepMind درباره Speculative Sampling از یک روش اصلاح‌شده Rejection Sampling استفاده کرد که توزیع Target Model را حفظ می‌کند. در آزمایش ارائه‌شده روی مدل Chinchilla با ۷۰ میلیارد پارامتر، سرعت Decoding در محیط توزیع‌شده حدود ۲ تا ۲٫۵ برابر افزایش یافت، بدون آنکه کیفیت نمونه‌برداری هدف تغییر کند. منبع: Accelerating Large Language Model Decoding with Speculative Sampling

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

• Lossless Speculative Decoding: حفظ توزیع Target Model
• Approximate Speculative Decoding: پذیرش تقریبی با احتمال تغییر محدود خروجی

Acceptance Rate چیست؟

Acceptance Rate نشان می‌دهد چه درصدی از Tokenهای پیشنهادی Draft Model توسط Target Model پذیرفته می‌شوند.

[
\text{Acceptance Rate}

\frac{\text{Accepted Draft Tokens}}
{\text{Total Draft Tokens}}
]

برای مثال، اگر Draft Model هزار Token پیشنهاد دهد و ۷۵۰ Token پذیرفته شوند:

[
\text{Acceptance Rate}=0.75
]

نرخ پذیرش بالاتر معمولاً به معنی عملکرد بهتر Speculative Decoding است؛ زیرا Target Model با هر مرحله Verification می‌تواند Tokenهای بیشتری را جلو ببرد.

اما Acceptance Rate تنها معیار نیست. Draft Model ممکن است نرخ پذیرش بالایی داشته باشد، ولی آن‌قدر کند باشد که Speedup کلی کاهش پیدا کند.

Expected Accepted Length

معیار مهم دیگر، میانگین تعداد Tokenهای پذیرفته‌شده در هر چرخه است:

[
E[L_{\text{accepted}}]

\frac{\text{Total Accepted Tokens}}
{\text{Verification Steps}}
]

اگر Target Model در هر Forward Pass به‌طور متوسط فقط ۱٫۱ Token را بپذیرد، بهبود زیادی نسبت به Decoding عادی ایجاد نمی‌شود.

اگر این مقدار به چهار یا پنج Token برسد، تعداد مراحل Target Model به میزان قابل‌توجهی کاهش پیدا می‌کند.

چه عواملی بر نرخ پذیرش اثر می‌گذارند؟

شباهت Draft و Target Model

هرچه توزیع احتمال دو مدل مشابه‌تر باشد، Candidateهای بیشتری پذیرفته می‌شوند.

نوع محتوا

متن‌های قابل‌پیش‌بینی معمولاً Acceptance Rate بیشتری دارند:

• عبارت‌های رایج
• کدهای الگوپذیر
• متن‌های تکراری
• ساختارهای استاندارد
• خروجی‌های Formatشده

وظایف خلاقانه یا بسیار نامطمئن ممکن است نرخ پذیرش پایین‌تری داشته باشند.

Temperature

Temperature بالا تنوع Sampling را افزایش می‌دهد و می‌تواند توافق Draft و Target را کمتر کند.

طول Speculation

با افزایش تعداد Candidateها، احتمال اینکه یکی از Tokenهای ابتدایی رد شود نیز افزایش پیدا می‌کند.

زبان

اگر Draft Model در زبان خاصی مانند فارسی ضعیف‌تر از Target Model باشد، نرخ پذیرش در آن زبان ممکن است پایین‌تر باشد.

Domain

یک Draft Model عمومی ممکن است در کد، متن حقوقی یا محتوای تخصصی توافق کمتری با مدل اصلی داشته باشد.

رابطه Draft Length و Speedup

انتخاب تعداد Tokenهای پیشنهادی یک Trade-off است.

Draft Length کوتاه

مزایا:

• Candidateهای کمتری هدر می‌روند.
• Verification ساده‌تر است.
• مصرف حافظه کمتر است.

معایب:

• فرصت موازی‌سازی محدود می‌شود.
• تعداد اجرای Target Model بیشتر باقی می‌ماند.

Draft Length بلند

مزایا:

• در صورت نرخ پذیرش بالا، Tokenهای بیشتری در هر مرحله تولید می‌شوند.
• تعداد مراحل Target Model کاهش می‌یابد.

معایب:

• پس از اولین رد، Candidateهای بعدی قابل استفاده نیستند.
• Draft Model زمان بیشتری صرف تولید می‌کند.
• هزینه Verification افزایش پیدا می‌کند.

راهکار بهتر، تنظیم تطبیقی Draft Length براساس Acceptance Rate اخیر است.

Dynamic Speculation

در Dynamic Speculation تعداد Candidateهای تولیدشده ثابت نیست.

برای مثال:

• اگر چند چرخه متوالی نرخ پذیرش بالا باشد، Draft Length افزایش می‌یابد.
• اگر Candidateها زود رد شوند، Draft Length کاهش پیدا می‌کند.
• اگر Confidence مدل Draft پایین باشد، Speculation زودتر متوقف می‌شود.

این رویکرد می‌تواند برای Promptها و بخش‌های مختلف پاسخ، Budget مناسب‌تری انتخاب کند.

مقایسه Decoding عادی و Speculative Decoding

تفاوت Throughput و Latency

Speculative Decoding معمولاً برای کاهش Inter-Token Latency و زمان تولید یک درخواست مفید است؛ اما لزوماً Throughput کل سیستم را در تمام شرایط افزایش نمی‌دهد.

Latency

زمانی است که یک کاربر برای دریافت پاسخ منتظر می‌ماند.

معیارهای مرتبط:

• Time to First Token
• Time per Output Token
• End-to-End Latency

Throughput

مقدار کاری است که سیستم در واحد زمان انجام می‌دهد.

معیارهای مرتبط:

• Tokens per Second
• Requests per Second
• Concurrent Users

ممکن است Speculative Decoding پاسخ یک کاربر را سریع‌تر کند، اما به دلیل اجرای Draft Model و مصرف حافظه بیشتر، ظرفیت Batch سیستم را کاهش دهد.

بنابراین باید در شرایط واقعی Serving ارزیابی شود.

آیا Speculative Decoding زمان تولید اولین Token را کاهش می‌دهد؟

معمولاً مهم‌ترین مزیت این روش پس از آغاز Decoding و در فاصله میان Tokenها دیده می‌شود. Time to First Token بیشتر تحت تأثیر Prefill، طول Prompt، Queue و Load مدل قرار دارد.

Speculative Decoding مستقیماً مشکل Prefill بسیار طولانی را حل نمی‌کند. اگر بیشتر زمان درخواست صرف پردازش Context شود، افزایش سرعت Decoding اثر محدودی بر Latency نهایی خواهد داشت.

می‌توان زمان کلی را به شکل ساده زیر در نظر گرفت:

[
T_{\text{total}}

T_{\text{queue}}
+
T_{\text{prefill}}
+
T_{\text{decode}}
]

Speculative Decoding عمدتاً بخش (T_{\text{decode}}) را هدف قرار می‌دهد.

Speculative Decoding چه زمانی بیشترین اثر را دارد؟

این روش معمولاً در شرایط زیر مفیدتر است:

• Target Model بزرگ و کند باشد.
• پاسخ‌های نسبتاً طولانی تولید شوند.
• Batch Size کوچک یا متوسط باشد.
• Draft Model بسیار سریع باشد.
• توافق Draft و Target بالا باشد.
• Decoding بخش اصلی Latency باشد.
• منابع GPU برای اجرای هر دو مدل وجود داشته باشد.

چه زمانی اثر کمتری دارد؟

• خروجی بسیار کوتاه باشد.
• Prompt بسیار طولانی و Prefill غالب باشد.
• Acceptance Rate پایین باشد.
• Draft Model به‌اندازه کافی سریع نباشد.
• Batch Size بسیار بزرگ باشد.
• سیستم از قبل GPU را کاملاً اشباع کرده باشد.
• حافظه اضافه Draft Model ظرفیت Serving را کاهش دهد.
• Target و Draft از Tokenizerهای ناسازگار استفاده کنند.

انتخاب Draft Model مناسب

یک Draft Model مناسب فقط «مدل کوچک‌تر» نیست. انتخاب آن باید براساس Benchmark واقعی انجام شود.

معیارهای مهم عبارت‌اند از:

• Latency مدل Draft
• Acceptance Rate
• اندازه مدل
• مصرف VRAM
• سازگاری Tokenizer
• کیفیت در زبان هدف
• کیفیت در Domain هدف
• هزینه انتقال میان Deviceها
• پشتیبانی موتور Inference
• Draft Length بهینه

مدل هم‌خانواده

مدل کوچک‌تر از همان خانواده معمولاً Tokenizer و رفتار مشابه‌تری دارد.

مزیت:

• نرخ پذیرش بهتر
• پیاده‌سازی ساده‌تر
• سازگاری Tokenizer

مدل Distilled

یک مدل کوچک می‌تواند برای تقلید از Target Model آموزش داده شود. این کار ممکن است Acceptance Rate را افزایش دهد، اما Training و نگهداری مدل Draft را پیچیده‌تر می‌کند.

مدل عمومی کوچک

راه‌اندازی آن ساده است، اما باید میزان توافق واقعی آن با Target Model سنجیده شود.

Tokenizer Compatibility

در بسیاری از پیاده‌سازی‌های اولیه، Draft و Target باید Tokenizer یکسانی داشته باشند؛ زیرا Candidateها در سطح Token بررسی می‌شوند.

اگر یک متن در دو Tokenizer متفاوت به شکل‌های متفاوت تقسیم شود، تطبیق Positionها پیچیده‌تر خواهد شد.

برای مثال، عبارت واحد ممکن است در یک Tokenizer دو Token و در Tokenizer دیگر چهار Token باشد.

برخی پیاده‌سازی‌های جدیدتر از هم‌ترازی مجدد متن و Lookbehind برای پشتیبانی از Tokenizerهای متفاوت استفاده می‌کنند، اما این قابلیت به موتور و کتابخانه مورد استفاده وابسته است.

پیاده‌سازی با Hugging Face Transformers

کتابخانه Transformers از Assisted Generation پشتیبانی می‌کند. در یک نمونه ساده می‌توان Target Model و Assistant Model را به متد generate داد.

ابتدا کتابخانه‌ها را نصب کنید:

pip install torch transformers accelerate

نمونه کد:

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer


target_model_id = "TARGET_MODEL_ID"
draft_model_id = "DRAFT_MODEL_ID"

tokenizer = AutoTokenizer.from_pretrained(
    target_model_id
)

target_model = AutoModelForCausalLM.from_pretrained(
    target_model_id,
    torch_dtype=torch.float16,
    device_map="auto",
)

draft_model = AutoModelForCausalLM.from_pretrained(
    draft_model_id,
    torch_dtype=torch.float16,
    device_map="auto",
)

prompt = "Speculative Decoding در مدل‌های زبانی چیست؟"

inputs = tokenizer(
    prompt,
    return_tensors="pt",
).to(target_model.device)

outputs = target_model.generate(
    **inputs,
    assistant_model=draft_model,
    max_new_tokens=200,
    do_sample=False,
)

generated_text = tokenizer.decode(
    outputs[0],
    skip_special_tokens=True,
)

print(generated_text)

در این مثال:

• target_model خروجی نهایی را تعیین می‌کند.
• draft_model Candidateها را تولید می‌کند.
• کتابخانه فرایند Verification را مدیریت می‌کند.

پشتیبانی دقیق از Device Map، Tokenizer متفاوت و تنظیمات Dynamic Speculation به نسخه کتابخانه و معماری مدل بستگی دارد. مستندات رسمی Assisted Decoding در Transformers

Benchmark صحیح Speculative Decoding

برای اندازه‌گیری واقعی باید Decoding عادی و Speculative Decoding در شرایط یکسان مقایسه شوند.

متغیرهای ثابت

• Target Model
• Promptها
• طول خروجی
• Precision
• سخت‌افزار
• Sampling Parameters
• Batch Size
• تعداد درخواست
• شرایط Warm-up

معیارهای مهم

• Time to First Token
• Inter-Token Latency
• Tokens per Second
• End-to-End Latency
• P50، P95 و P99
• Acceptance Rate
• Accepted Tokens per Step
• Peak VRAM
• GPU Utilization
• Throughput
• هزینه هر میلیون Token

Warm-up

اجرای اول ممکن است شامل موارد زیر باشد:

• بارگذاری Kernel
• Compile
• تخصیص حافظه
• ایجاد Cache
• انتقال داده

بنابراین چند اجرای Warm-up را از نتیجه نهایی حذف کنید.

نمونه Benchmark ساده

import time
import torch


def benchmark_generation(
    model,
    tokenizer,
    prompt: str,
    assistant_model=None,
    runs: int = 10,
):
    inputs = tokenizer(
        prompt,
        return_tensors="pt",
    ).to(model.device)

    latencies = []
    generated_counts = []

    for _ in range(runs):
        torch.cuda.synchronize()
        start = time.perf_counter()

        output = model.generate(
            **inputs,
            assistant_model=assistant_model,
            max_new_tokens=200,
            do_sample=False,
        )

        torch.cuda.synchronize()
        elapsed = time.perf_counter() - start

        generated_tokens = (
            output.shape[1] - inputs["input_ids"].shape[1]
        )

        latencies.append(elapsed)
        generated_counts.append(generated_tokens)

    total_tokens = sum(generated_counts)
    total_time = sum(latencies)

    return {
        "average_latency": total_time / runs,
        "tokens_per_second": total_tokens / total_time,
    }

این Benchmark برای بررسی اولیه مناسب است، اما شرایط Production مانند Queue، Batch و هم‌زمانی کاربران را پوشش نمی‌دهد.

Prompt Lookup Decoding

در برخی وظایف، Candidateها را می‌توان بدون Draft Model جداگانه از خود Prompt استخراج کرد. این روش با نام Prompt Lookup Decoding شناخته می‌شود.

این روش زمانی مفید است که خروجی احتمالاً شامل عبارت‌هایی از ورودی باشد:

• خلاصه‌سازی
• بازنویسی
• استخراج اطلاعات
• پاسخ‌گویی براساس سند
• ویرایش متن
• تولید کد مبتنی بر Context موجود

برای مثال، هنگام خلاصه‌سازی یک سند، بسیاری از عبارت‌های احتمالی پاسخ در همان سند وجود دارند. سیستم می‌تواند دنباله‌های مشابه را به‌عنوان Candidate پیشنهاد دهد و Target Model آن‌ها را بررسی کند.

مزیت اصلی این روش، حذف نیاز به بارگذاری Draft Model است.

Self-Speculative Decoding

در Self-Speculative Decoding از خود Target Model یا بخشی از آن برای تولید سریع Candidate استفاده می‌شود.

یک روش ممکن است از خروجی لایه‌های میانی مدل استفاده کند. لایه‌های ابتدایی سریع‌تر Candidate می‌سازند و تمام لایه‌ها آن‌ها را تأیید می‌کنند.

مزایا:

• نیاز نداشتن به مدل جداگانه
• اشتراک وزن‌ها
• کاهش مصرف حافظه اضافه
• سازگاری طبیعی Tokenizer

محدودیت:

• هر معماری برای خروجی‌گیری از لایه میانی مناسب نیست.
• ممکن است به Training یا تنظیمات خاص نیاز باشد.
• پشتیبانی موتورهای Inference متفاوت است.

Multi-Token Prediction

در Multi-Token Prediction مدل به‌جای پیش‌بینی فقط Token بعدی، برای چند موقعیت آینده نیز خروجی تولید می‌کند.

برای مثال:

Head 1 → Token بعدی
Head 2 → دو Token بعد
Head 3 → سه Token بعد
Head 4 → چهار Token بعد

این Headها Candidateهای آینده را پیشنهاد می‌دهند و مدل اصلی می‌تواند آن‌ها را بررسی کند.

Multi-Token Prediction می‌تواند نیاز به Draft Model مستقل را کاهش دهد.

Medusa چیست؟

Medusa روشی برای افزایش سرعت Inference است که چند Decoding Head به مدل اضافه می‌کند. این Headها به‌صورت هم‌زمان Tokenهای آینده را پیش‌بینی می‌کنند.

Medusa با استفاده از Tree-Based Attention چند ادامه احتمالی را می‌سازد و آن‌ها را به‌صورت موازی بررسی می‌کند.

مزایای اصلی:

• نیاز نداشتن به Draft Model جداگانه
• امکان اتصال Headها به مدل موجود
• کاهش مرحله‌های Decoding
• استفاده از چند Candidate در قالب درخت

در مقاله Medusa، نسخه Medusa-1 با Backbone ثابت و Headهای آموزش‌دیده، بیش از ۲٫۲ برابر Speedup گزارش کرده است. نسخه Medusa-2 نیز در آزمایش‌های مقاله به بازه ۲٫۳ تا ۳٫۶ برابر رسیده، هرچند به Training خاص‌تری نیاز دارد. منبع: مقاله Medusa

مقایسه روش‌های Speculative Generation

ارتباط Speculative Decoding با KV Cache

KV Cache از محاسبه دوباره Key و Value مربوط به Tokenهای قبلی جلوگیری می‌کند. Speculative Decoding نیز باید Cache مربوط به Tokenهای Candidate را مدیریت کند.

اگر Candidate پذیرفته شود، بخش مرتبط Cache حفظ می‌شود. اگر Token رد شود، Cache مربوط به ادامه نامعتبر باید کنار گذاشته یا اصلاح شود.

مدیریت ناکارآمد Cache می‌تواند بخشی از Speedup را از بین ببرد.

به همین دلیل، عملکرد واقعی فقط به الگوریتم وابسته نیست؛ کیفیت پیاده‌سازی موتور Inference نیز اهمیت زیادی دارد.

ارتباط با Continuous Batching

Continuous Batching درخواست‌های مختلف را به‌صورت پویا در یک Batch ترکیب می‌کند. Speculative Decoding طول متفاوتی از Tokenهای پذیرفته‌شده برای هر درخواست ایجاد می‌کند.

برای مثال:

• درخواست اول چهار Token می‌پذیرد.
• درخواست دوم فقط یک Token می‌پذیرد.
• درخواست سوم تمام Candidateها را رد می‌کند.

این ناهمگونی، زمان‌بندی Batch را پیچیده می‌کند. موتور Inference باید بتواند مرحله‌های Draft و Verification را بدون کاهش شدید GPU Utilization مدیریت کند.

آیا Speculative Decoding هزینه API را کاهش می‌دهد؟

اگر از یک API عمومی استفاده می‌کنید، معمولاً کنترل مستقیمی روی الگوریتم Decoding داخلی Provider ندارید. Provider ممکن است از Speculative Decoding استفاده کند، اما قیمت‌گذاری همچنان براساس Token یا مدل انجام شود.

اگر مدل را خودتان میزبانی کنید، Speculative Decoding می‌تواند:

• زمان اشغال GPU را کاهش دهد.
• تعداد درخواست پردازش‌شده در واحد زمان را افزایش دهد.
• هزینه زیرساخت برای هر پاسخ را کاهش دهد.

اما این نتیجه تضمینی نیست. مصرف VRAM مدل Draft و کاهش ظرفیت Batch نیز باید محاسبه شوند.

تفاوت Speculative Decoding با Test-Time Scaling

هر دو روش از Compute بیشتر یا ساختار متفاوت Inference استفاده می‌کنند، اما هدف آن‌ها متفاوت است.

مقاله Test-Time Scaling چیست؟ این رویکرد را به‌صورت کامل توضیح می‌دهد.

اشتباهات رایج در پیاده‌سازی

انتخاب Draft Model صرفاً براساس اندازه

یک مدل بسیار کوچک ممکن است سریع باشد، اما Candidateهای ضعیفی تولید کند و Acceptance Rate را کاهش دهد.

بررسی فقط میانگین Latency

میانگین نمی‌تواند رفتار کاربران کندتر را نشان دهد. P95 و P99 نیز باید اندازه‌گیری شوند.

نادیده‌گرفتن Prefill

اگر Prompt بسیار طولانی باشد، کاهش زمان Decode ممکن است تأثیر کمی بر Latency کلی داشته باشد.

استفاده از Benchmark غیرواقعی

Promptهای کوتاه انگلیسی ممکن است نتیجه‌ای متفاوت از درخواست‌های فارسی، کد یا Contextهای طولانی داشته باشند.

مقایسه با Sampling متفاوت

Temperature، Top-p و Seed باید در آزمایش‌ها کنترل شوند.

نادیده‌گرفتن مصرف VRAM

Draft Model ممکن است ظرفیت Batch یا تعداد کاربران هم‌زمان را کاهش دهد.

فرض Speedup ثابت

میزان افزایش سرعت به Prompt، Domain، زبان، طول خروجی، Batch Size و سخت‌افزار بستگی دارد.

معماری پیشنهادی برای Production

یک سرویس Production می‌تواند اجزای زیر را داشته باشد:

1. Request Router: انتخاب مسیر عادی یا Speculative
2. Target Model: مدل اصلی
3. Draft Model: مدل سریع پیشنهادی
4. Candidate Generator: تولید Tokenهای احتمالی
5. Verification Engine: بررسی موازی Candidateها
6. Adaptive Controller: تنظیم Draft Length
7. KV Cache Manager: مدیریت Cache پذیرفته و ردشده
8. Batch Scheduler: هماهنگی درخواست‌های هم‌زمان
9. Metrics Collector: ثبت Latency و Acceptance Rate
10. Fallback: بازگشت به Decoding عادی

سیستم باید بتواند در صورت پایین‌بودن نرخ پذیرش، Speculation را موقتاً غیرفعال کند.

معیارهای پایش در Production

• Acceptance Rate
• Accepted Tokens per Verification
• Draft Latency
• Verification Latency
• End-to-End Latency
• Time to First Token
• Inter-Token Latency
• Tokens per Second
• Requests per Second
• P50، P95 و P99
• Peak VRAM
• Batch Utilization
• Fallback Rate
• Cost per Million Tokens

برای طراحی لایه پایش می‌توانید مقاله AI Observability چیست؟ را مطالعه کنید.

چک‌لیست انتخاب Speculative Decoding

• Decoding سهم مهمی از Latency کل دارد.
• پاسخ‌ها به‌اندازه کافی طولانی هستند.
• Draft Model سریع‌تر از Target Model است.
• Acceptance Rate روی داده واقعی اندازه‌گیری شده است.
• زبان فارسی در Benchmark وجود دارد.
• VRAM مدل Draft محاسبه شده است.
• Batch Size واقعی آزمایش شده است.
• Sampling Parameters یکسان هستند.
• خروجی Lossless بررسی شده است.
• P95 و P99 اندازه‌گیری شده‌اند.
• KV Cache به‌درستی مدیریت می‌شود.
• مسیر Fallback به Decoding معمولی وجود دارد.
• Speedup روی سخت‌افزار Production تأیید شده است.

جمع‌بندی

Speculative Decoding یکی از مهم‌ترین روش‌های کاهش Latency در مدل‌های زبانی Autoregressive است. این روش با کمک یک Draft Model سریع، چند Token آینده را پیشنهاد می‌دهد و Target Model آن‌ها را به‌صورت موازی بررسی می‌کند.

اگر Candidateها با رفتار مدل اصلی هماهنگ باشند، چند Token در هر Forward Pass پذیرفته می‌شوند و تعداد مرحله‌های متوالی Decoding کاهش پیدا می‌کند.

موفقیت این روش به عوامل زیر وابسته است:

• سرعت Draft Model
• نرخ پذیرش Candidateها
• طول Speculation
• سازگاری Tokenizer
• نوع محتوا و زبان
• Batch Size
• مدیریت KV Cache
• سخت‌افزار
• موتور Inference

Speculative Decoding بیشتر برای افزایش سرعت طراحی شده است، نه افزایش هوشمندی مدل. در پیاده‌سازی Lossless، خروجی همچنان توسط Target Model تعیین می‌شود.

برای توسعه اپلیکیشن‌های چندمدلی، می‌توانید از API درواره برای دسترسی به مدل‌های مختلف از طریق یک API سازگار استفاده کنید. اگر مدل‌ها را روی زیرساخت اختصاصی میزبانی می‌کنید، Speculative Decoding می‌تواند یکی از گزینه‌های مهم برای بهینه‌سازی لایه Inference باشد.

سؤالات متداول

Speculative Decoding چیست؟

روشی برای افزایش سرعت تولید متن است که در آن یک مدل کوچک Tokenهای آینده را پیشنهاد می‌دهد و مدل اصلی آن‌ها را به‌صورت موازی تأیید می‌کند.

Draft Model چیست؟

Draft Model یک مدل سبک و سریع است که Candidate Tokenها را پیش از اجرای Target Model تولید می‌کند.

Target Model چیست؟

Target Model مدل اصلی و دقیق‌تری است که Tokenهای پیشنهادی را بررسی و خروجی نهایی را تعیین می‌کند.

آیا Speculative Decoding کیفیت پاسخ را کاهش می‌دهد؟

در نسخه Lossless و پیاده‌سازی صحیح، توزیع خروجی Target Model حفظ می‌شود. روش‌های تقریبی ممکن است این توزیع را کمی تغییر دهند.

Acceptance Rate چیست؟

درصد Tokenهای پیشنهادی Draft Model است که توسط Target Model پذیرفته می‌شوند.

آیا Draft Model باید از همان خانواده Target Model باشد؟

اجباری نیست، اما مدل‌های هم‌خانواده معمولاً Tokenizer و رفتار مشابه‌تری دارند و می‌توانند نرخ پذیرش بیشتری ایجاد کنند.

آیا می‌توان از Tokenizer متفاوت استفاده کرد؟

برخی پیاده‌سازی‌های جدید از Tokenizerهای متفاوت پشتیبانی می‌کنند، اما هم‌ترازی Tokenها پیچیده‌تر است و به موتور مورد استفاده بستگی دارد.

تفاوت Speculative Decoding و Medusa چیست؟

Speculative Decoding کلاسیک معمولاً از یک Draft Model جداگانه استفاده می‌کند. Medusa چند Decoding Head به همان مدل اضافه می‌کند تا Tokenهای آینده را پیشنهاد دهد.

آیا این روش Time to First Token را کاهش می‌دهد؟

مزیت اصلی آن معمولاً کاهش زمان میان Tokenها و Decode Latency است. Prefill و Time to First Token ممکن است بهبود کمتری داشته باشند.

آیا Speculative Decoding همیشه سرعت را افزایش می‌دهد؟

خیر. اگر Draft Model کند یا Acceptance Rate پایین باشد، سربار Speculation می‌تواند مزیت آن را کاهش دهد.

مقالات مرتبط

• Test-Time Scaling چیست؟ افزایش قدرت استدلال مدل‌های زبانی هنگام اجرا
• Inference چیست؟ راهنمای اجرای مدل‌های هوش مصنوعی
• Token در هوش مصنوعی چیست؟
• Temperature در هوش مصنوعی چیست؟
• Top-p در مدل‌های هوش مصنوعی چیست؟
• Prompt Caching چیست؟
• Context Window چیست؟
• AI Observability چیست؟
• راهنمای کاهش هزینه API هوش مصنوعی