Speculative decoding به این خاطر ship شد که output رو عوض نمی‌کنه.

Liquid AI بیستم آگست ۲۰۲۶ LFM2.5-DSpark رو ship کرد: سه draft model که target شون LFM2.5 1.2B-Instruct، LFM2.5 2.6B، و LFM2.5 8B-A1B (یه MoE) ـه، تحت لایسنس lfm1.0. عددهای headline، mean ی 2.67× روی H100 و 2.27× روی M4 Max، روی target ی 2.6B، با peak ی 3.06× روی MATH500. headline کم‌جالب‌ترین چیز release ـه. چیز جالب اینه که چرا این جور release اصلاً می‌تونه day one، تو production، بدون eval-suite expansion و بدون rollback story، ship بشه.

Speculative decoding چیه

الگو ساده‌ست. یه draft model ی کوچیک یه sequence ی کوتاه از token ها رو پیشنهاد می‌ده؛ target model parallel verify شون می‌کنه، هرکدوم که match داره رو accept می‌کنه، بقیه رو رد می‌کنه، و از اولین position ی رد شده ادامه می‌ده. سه عدد یه cycle رو characterize می‌کنن: draft length (چند token رو drafter per step پیشنهاد می‌ده)، acceptance rate (verifier چندتاش رو accept می‌کنه)، و effective tokens-per-step (بهره‌ی throughput ی realized).

property ی حیاتی exactness under greedy decoding ـه. وقتی verifier از argmax استفاده می‌کنه و یه draft token رو accept می‌کنه، اون token byte-identical ـه به چیزی که target model تنها تولید می‌کرد. stream ی output byte-identical ـه به greedy decoding ی non-speculative. کل family ی EAGLE، Medusa، DFlash، DSpark روی این property معامله می‌کنه. بدونش، speculative decoding یه quantization problem ی با tooling ی بدتر می‌شد، نه یه free lunch.

DSpark واقعاً چی‌کار می‌کنه

design choice ی جالب اینه که چی نیست. paper (arXiv:2607.05147، Cheng et al.، DeepSeek-AI + PKU) یه confidence-scheduled Markov-head draft رو describe می‌کنه، لایه‌شده روی lineage ی DFlash / EAGLE-3. یه confidence scheduler ساخته شد که draft های low-confidence رو at inference time dynamically trim کنه. dormant موند. dynamic trimming بیشتر آسیب زد تا کمک. DSpark نسخه‌ی ساده‌تر و static رو ship می‌کنه چون نسخه‌ی ساده‌تر رو benchmark های واقعی می‌بره.

این یه posture statement ـه. family ی speculative decoding سه نسل دنبال dynamic adaptation بوده. EAGLE-2 ایده‌ی tree-of-tokens رو معرفی کرد، که drafter چند candidate رو at branching position ها پیشنهاد می‌ده و verifier طولانی‌ترین prefix ی accept شده رو انتخاب می‌کنه. EAGLE-3 head رو refine کرد؛ DFlash (arXiv:2602.06036) Markov head رو به یه confidence-scheduled mechanism generalize کرد. DSpark static ship می‌کنه. machinery ی dynamic ساخته شده و dormant ـه. نسخه‌ی static برد. posture وقتی مهمه که family سه نسل داشته بالا می‌رفته و release کف رو ship می‌کنه.

عددها

جدول spine ـه.

Draft target	Acceptance length	H100 mean	M4 Max mean	MATH500 peak
LFM2.5-1.2B-Instruct	—	—	—	—
LFM2.5-2.6B	4.81	2.67×	2.27×	3.06×
LFM2.5-8B-A1B (MoE)	—	—	1.18×	—

دو تا extra که اسم بردن می‌ارزن. latency ی BFCL function-calling: ۵۷٪ کاهش روی M4 Max روی target ی 2.6B (BFCL تو PMLR v267 ـه). Confidence-scheduled verification: ساخته شده ولی استفاده نشده؛ checkpoint ی release شده از static drafting استفاده می‌کنه.

ضعف صادقانه row ی 8B-A1B روی M4 Max ـه: 1.18×. routing ی MoE به‌علاوه‌ی memory bandwidth ی draft model، bus ی unified-memory رو قبل از این‌که draft path کمک کنه saturate می‌کنه. release draft ی 8B-A1B رو با‌هم ship کرد، و این call ی درستیه: یه عدد صادقانه روی یه workload ی واقعی از یه عدد cherry-picked شده مفیدتره. draft ی 8B-A1B unusable نیست؛ فقط headline نیست.

چرا exactness under greedy کل بازیه

قانون قابل انتقال. هر optimization ی inference که output ها رو عوض نمی‌کنه free lunch ـه: A/B parity، بدون re-run ی eval-suite، بدون golden regression trace، بدون rollback plan. optimization هایی که output رو عوض می‌کنن (post-training quantization، distillation، pruning، kernel fusion با numerical drift) به eval suite، golden trace، و rollback plan نیاز دارن. speculative decoding under greedy به هیچ‌کدوم نیاز نداره.

حساب‌وکتاب cost نامتقارنه. exactness ship می‌شه. non-exactness budget می‌خواد. به‌خاطر همینه که هر production serving stack ی که من ship یا audit کردم، speculative decoding رو روی hot path داره، و تقریباً هیچ‌کدوم post-training quantization رو روی hot path بدون eval gate ندارن. تصمیم روی speedup number گرفته نشد؛ روی این گرفته شد که آیا change به quality gate نیاز داشت یا نه. speculative decoding نداشت. 2.67× bonus ـه.

این inverse ی property ی byte-identical-still-broken ـه. اون‌جا، یه transformation باید byte-identical به یه reference می‌بود و نبود؛ شکست under load کشف شد. این‌جا، byte-identity property ی load-bearing ـه، و تحت configuration ی خاص decoder ی که family هدف گرفته (greedy) exact ـه. هردو پست درباره‌ی فرق بین property ی که system ادعا می‌کنه و property ی که system داره هستن. DSpark اون سمتی زندگی می‌کنه که ادعا با property match می‌کنه. به‌خاطر همینه که می‌تونه تحت lfm1.0 با SGLang integration ی in-flight (PR #31041) و Metal kernels ی llama.cpp ship بشه.

کجا generalize می‌شه

خواننده باید با یه test ی قابل انتقال بره. وقتی یه optimization ی inference رو evaluate می‌کنی، یه سوال بپرس: آیا output ها رو تحت greedy decoding عوض می‌کنه؟

اگه نه، بدون eval suite ship کن. اگه آره، budget بذار.

این سوال به هر تصمیم serving ی دو سال آینده اعمال می‌شه: KV-cache compression، paged attention، continuous batching، prefix caching، quantization kernel، draft model، MoE expert pruning. هرکدوم یا output رو عوض می‌کنه یا نمی‌کنه، و همون یه property تعیین می‌کنه که آیا rollout به quality gate نیاز داره یا نه. speedup تا جواب سوال داده نشه irrelevant ـه. بیشتر وقت‌ها جواب “نه” ـه (optimization تحت greedy exact ـه)، و جواب چراغ سبزه. بعضی وقت‌ها جواب “آره” ـه، و سوال اینه که آیا speedup مالیات eval-suite رو می‌ارزه یا نه. هردو سوال downstream ی سوال اول زندگی می‌کنن.

اون trap

trap اینه که number های speedup رو result بخونی. side effect ان. result اینه که Liquid AI سه draft model تحت یه license ی permissive، target ی سه size ی متفاوت، day one، با SGLang integration ی in-flight و Metal kernels ی llama.cpp ship کرد. result اینه که bottleneck ی serving ی LFM2.5 روی Apple Silicon دیگه compute نیست؛ memory bandwidth ی draft path ـه. result اینه که یه confidence scheduler ساخته شد، evaluate شد، و dormant موند چون نسخه‌ی static call ی درستی بود.

continuity ی پست Omarchy. property های visible (exactness under greedy) ship شدن. property های hidden (dynamic adaptation) shelve شدن. کل release یه argument ی واحده: technique قابل ship ـه چون property ی که claim می‌کنه همون property ی ـیه که داره، و property ی که claim می‌کنه exactness under یه decoder ی خاصه. speculative decoding همیشه این property رو claim کرده. DSpark release ی ـیه که توش claim با benchmark match می‌کنه، benchmark با workload match می‌کنه، و workload با production stack match می‌کنه. 2.67× headline ـه. byte-identity result ـه.