چطور DSpark سرعت پاسخ‌دهی عامل‌های هوشمند را در سخت‌افزارهای محلی بالا برد؟

اگر امروز برای اجرای مدل‌های محلی روی سخت‌افزار خودتان هزینه می‌کنید، احتمالاً با گلوگاه حافظه دست‌وپنجه نرم می‌کنید. خبر خوب این است که سرعت استنتاج در مدل LFM2.5-8B-A1B حالا به لطف یک مسیر جدید در رمزگشایی گمانه‌زن (Speculative Decoding)، تا ۳.۱۸ برابر سریع‌تر شده است.

شرکت Liquid AI در ۲۰ اوت ۲۰۲۶ نقاط بازرسی (Checkpoints) مدل‌های پیش‌نویس DSpark را برای خانواده LFM2.5 منتشر کرد. هدف این به‌روزرسانی، کاهش شدید گلوگاه‌های حافظه‌محور (Memory-bound) در مرحله رمزگشایی مدل‌های زبانی بزرگ (LLM) است. این انتشار شامل نقاط بازرسی برای سه مدل از خانواده LFM2.5 می‌شود: LFM2.5-1.2B-Instruct، LFM2.5-2.6B و LFM2.5-8B-A1B. این مدل‌ها در واقع تکامل یافته‌ی معماری LFM2.5 هستند که پیش‌تر توانایی پردازش متون طولانی را بدون نیاز به GPUهای حجیم به نمایش گذاشته بود.

بسیاری از تأخیرهای فعلی در هوش مصنوعی ناشی از محاسبات خام نیست، بلکه به دلیل فرآیند کند استریم کردن وزن‌ها از حافظه DRAM به SRAM است. این موضوع اصلی‌ترین مانع برای عامل‌های هوش مصنوعی (AI Agents) روی دستگاه است که باید در لحظه بخوانند، برنامه‌ریزی کنند و ابزارها را فراخوانی کنند. با تکیه بر منطق تکنیک‌های پیش‌نویس موازی قبلی مانند DFlash، هدف DSpark این است که فاز «رمزگشایی» (Decode) را به‌طور قابل‌توجهی کارآمدتر کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی استنتاج اشاره کردیم، کاهش این تأخیر کلید تبدیل مدل‌های آزمایشگاهی به ابزارهای کاربردی است. این چالش با بحران حافظه در معماری‌های پیشرو سال ۲۰۲۶ که اولویت جدید توسعه‌دهندگان شده است، کاملاً هم‌سو است. استنتاج (Inference) — همان لحظه‌ای که مدل واقعاً جواب تولید می‌کند، مثل خودِ آشپزی و نه دوره‌ی آموزش آشپز — اکنون با مکانیزم DSpark بسیار بهینه‌تر شده است.

سازوکار DSpark

طبق مستندات Liquid AI، این سامانه از یک سیستم سه بخشی برای شتاب‌دهی به تولید توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — استفاده می‌کند.

اول، سیستم از یک ستون فقرات موازی به سبک DFlash استفاده می‌کند که حالت‌های پنهان (Hidden States) چندین توکن پیش‌نویس را تنها در یک گذر پیشرو (Forward Pass) تولید می‌کند. این ستون فقرات بر اساس ویژگی‌های زمینه‌ای (Context Features) مدل هدف شرطی شده است.

در مرحله دوم، یک سرِ متوالی سبک‌وزن (Lightweight Sequential Head) مانند یک زنجیره مارکوف عمل می‌کند تا وابستگی‌های بین توکن‌ها را مدیریت کند. با مدل‌سازی رابطه بین توکن‌های همسایه، این بخش نرخ پذیرش توکن‌ها را در جایگاه‌های انتهایی توالی افزایش می‌دهد.

در نهایت، سیستم از یک تأییدکننده با زمان‌بندی اعتماد (Confidence-scheduled Verifier) بهره می‌برد. این مؤلفه احتمال بقای هر توکن را پیش‌بینی کرده و پسوندهای کم‌اعتماد را هرس می‌کند. این سازوکار تضمین می‌کند که سیستم بیش از مقدار صرفه‌جویی حاصل از گمانه‌زنی، روی عملیات تأیید (Verification) هزینه محاسباتی نکند.

معماری و آموزش مدل

مدل‌های پیش‌نویس نسبتاً کوچک هستند و هر کدام تقریباً ۳۰۰ میلیون پارامتر دارند. این مدل‌ها از یک معماری ساده‌شده‌ی «فقط-توجه» (Attention-only) با ۵ لایه و اندازه بلوک (Block Size) ۹ استفاده می‌کنند. Liquid AI این مدل‌ها را طی ۱۵ دوره (Epoch) با استفاده از ترکیبی متنوع از داده‌های SFT، گفتگو (Chat)، کدنویسی و داده‌های فراخوانی تابع (Function-calling) آموزش داده است.

تفکیک دقیق پارامترها برای مدل‌های پیش‌نویس به شرح زیر است:

• پشته رمزگشا (۵ لایه): ۲۴۱.۲ میلیون پارامتر در هر سه مدل.
• پروجکشن حالت پنهان: ۲۱ میلیون پارامتر در هر سه مدل.
• سر مارکوف: ۳۳.۶ میلیون پارامتر برای LFM2.5-1.2B-Instruct و ۶۵.۵ میلیون پارامتر برای LFM2.5-2.6B و LFM2.5-8B-A1B.
• نرمال‌سازها و سر اعتماد: ۲۷.۵ هزار پارامتر.

تعداد کل پارامترها از ۲۹۵.۷ میلیون (برای پیش‌نویس 1.2B-Instruct) تا ۳۲۷.۷ میلیون (برای پیش‌نویس‌های 2.6B و 8B-A1B) متغیر است. نکته کلیدی این است که تیم توسعه، نقاط بازرسی را بر اساس «بالاترین نرخ پذیرش توکن» انتخاب کرده است، نه کمترین میزان زیان (Loss). این بهینه‌سازی تضمین می‌کند که پیش‌بینی‌های مدل پیش‌نویس به‌طور نزدیکی با توزیع مدل هدف هم‌راستا باشد.

بنچمارک‌های عملکرد

به گزارش وبلاگ Liquid AI، میزان شتاب بسته به سخت‌افزار و اندازه مدل متفاوت است. تست‌ها روی یک GPU H100 80GB در حالت BF16 با استفاده از SGLang، و یک مک‌بوک پرو M4 Max با استفاده از وزن‌های FP16 GGUF از طریق llama.cpp و Metal انجام شده است. در هر دو حالت، اندازه دسته (Batch Size) برابر ۱، دما (Temperature) برابر ۰ و حداکثر تعداد توکن‌های خروجی ۲۵۶ در نظر گرفته شده بود.

برای مدل LFM2.5-2.6B روی مک‌بوک M4 Max، توان عملیاتی به‌طور میانگین از ۶۱ به ۱۳۹ توکن در ثانیه جهش کرد. این سرعت، تعامل محلی را به سطحی می‌برد که معمولاً توسط مدل‌های تجاری ابری (حدود ۱۴۰ توکن در ثانیه) ارائه می‌شود.

نتایج روی یک GPU H100 80GB با استفاده از SGLang حتی چشمگیرتر بود:

• LFM2.5-8B-A1B: در بنچمارک MATH500 به شتاب ۳.۱۸ برابری رسید و به سرعت ۱,۳۶۲ توکن در ثانیه دست یافت. میانگین شتاب GPU برای این مدل ۲.۵۴ برابر (از ۴۱۸ به ۱,۰۷۴ توکن در ثانیه) بود.
• LFM2.5-2.6B: به‌طور میانگین در پنج بنچمارک مختلف شتاب ۲.۶۷ برابری داشت و روی H100 از ۳۲۳ به ۸۶۴ توکن در ثانیه رسید.
• LFM2.5-1.2B-Instruct: شتاب میانگین ۲.۱۰ برابری روی GPU (از ۶۵۶ به ۱,۳۸۴ توکن در ثانیه) و ۲.۵۴ برابری روی M4 Max (از ۱۳۸ به ۳۵۰ توکن در ثانیه) را تجربه کرد.

تحلیل توزیع داده‌ها و جزئیات عملکرد

عملکرد مدل‌ها بسته به توزیع‌های مختلف متنی متفاوت بود. برای مدل LFM2.5-2.6B، شتاب روی H100 در MT-Bench بیشترین مقدار (۲.۸۷ برابر) و در GSM8K کمترین مقدار (۲.۲۲ برابر) بود. در مک‌بوک M4 Max، بنچمارک HumanEval بیشترین جهش را داشت (۲.۶۳ برابر، از ۶۱ به ۱۶۱ توکن در ثانیه).

در مورد LFM2.5-1.2B-Instruct، تیم توسعه متوجه واریانس بالاتری در نرخ پذیرش شد. شتاب بسته به مجموعه داده تا ۵۲٪ تغییر می‌کرد؛ برای مثال، MATH500 شتاب ۲.۵۶ برابری روی H100 را نشان داد، در حالی که MT-Bench تنها ۱.۶۶ برابر بود.

برای LFM2.5-8B-A1B، نرخ پذیرش به‌طور کلی بالاتر بود (میانگین ۶.۹۵) در مقایسه با مدل‌های متراکم (Dense). با این حال، بهبود روی دستگاه‌های محلی به‌طور میانگین تنها ۱۸٪ بود. این موضوع به دلیل محدودیت‌های فعلی بک‌اند Metal در llama.cpp و این واقعیت است که تأیید چندین توکن باعث فعال شدن اکسپرت‌های (Experts) بیشتری می‌شود که در نتیجه ترافیک انتقال وزن‌ها را افزایش می‌دهد.

کارایی عامل‌محور و کیفیت

برای توسعه‌دهندگانی که عامل (Agent) می‌سازند، حیاتی‌ترین معیار، تأخیر در فراخوانی تابع (Function Calling) است. Liquid AI گزارش می‌دهد که DSpark این تأخیر را برای مدل LFM2.5-2.6B به‌طور میانگین ۵۷٪ کاهش داده است. این امر مدل را در سناریوهای چند-ابزاری (Multi-tool) به‌طور قابل‌توجهی پاسخگوتر می‌کند.

از آنجا که مدل هدف هر توکن پیشنهادی را تأیید می‌کند، خروجی نهایی دقیقاً مشابه رمزگشایی حریصانه (Greedy Decoding) باقی می‌ماند. اگر یک توکن پیش‌نویس رد شود، توکن تولید شده توسط خودِ مدل هدف جایگزین آن می‌شود. این بدان معناست که دقت بنچمارک‌ها، مانند pass@1 یا تطبیق دقیق (Exact Match)، بدون تغییر باقی می‌ماند در حالی که سرعت به‌شدت افزایش می‌یابد.

استقرار و یکپارچه‌سازی

این قابلیت از روز اول برای دو فریم‌ورک اصلی استنتاج پشتیبانی می‌شود: llama.cpp (با استفاده از کرنل‌های تجربی Metal برای مک) و SGLang. نقاط بازرسی مدل‌های پیش‌نویس در Hugging Face با هر دو فرمت Safetensors و GGUF در دسترس هستند.

برای اجرا با SGLang، کاربران به نسخه‌ای نیاز دارند که از DSpark برای اهداف LFM2 پشتیبانی کند (PR #31041). دستور اجرا نیازمند تعیین --speculative-algorithm DSPARK و --speculative-draft-model-path است. برای llama.cpp، کاربران به بیلد مربوطه (PR#27383) نیاز دارند و می‌توانند از پرچم -md برای متصل کردن مدل پیش‌نویس استفاده کنند.

این تغییر در کارایی استنتاج، این فرض را که گردش‌کارهای سریع عامل‌محور نیازمند خوشه‌های عظیم ابری هستند، تغییر می‌دهد. با بهینه‌سازی ماهیت حافظه‌محور رمزگشایی، Liquid AI در حال نزدیک کردن ما به عصر هوش مصنوعی محلی و سیال است.

گام بعدی شما

• اگر از تراشه‌های سری M اپل استفاده می‌کنید، نقاط بازرسی GGUF را تست کنید تا ببینید سرعت ۱۴۰ توکن در ثانیه چگونه تجربه کاربری (UX) اپلیکیشن شما را تغییر می‌دهد.
• برای کاهش تأخیر در ابزارهای Agentic، مدل LFM2.5-2.6B را با DSpark جایگزین مدل‌های فعلی کنید.
• مستندات SGLang را برای فعال‌سازی الگوریتم DSPARK در محیط‌های تولیدی بررسی کنید.

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