‏شتاب‌دادن Gemini Nano روی پیکسل با پیش‌بینی چندتوکنی

داشتن یه مدل زبانی توی جیب دیگه واقعیته — Gemini Nano و Gemma کارهایی مثل خلاصه‌کردن نوتیفیکیشن‌ها یا بازخوانی پیام رو بدون فرستادن داده به سرور انجام می‌دن. ولی نویسنده‌های این پست پژوهشی گوگل می‌گن مشکل اصلی روی موبایل سرعته: بودجهٔ انرژی سفت‌وسخته، رم محدوده، و مدل‌ها هم متن رو autoregressive تولید می‌کنن، یعنی توکن‌به‌توکن — که هم گلوگاه می‌سازه هم باتری می‌خوره.

راه‌حل اعلام‌شده، سوارکردن Multi-Token Prediction (MTP) روی مدل‌های موجود و فریزشدهٔ Gemini Nano v3 ست. این کار روی پیکسل ۹ و ۱۰ عرضه شده و به گفتهٔ گوگل یه شتابِ آماده و بدون تنظیم اضافه‌ست: قابلیت‌هایی مثل AI Notification Summaries و Proofread محسوس‌تر سریع‌تر و کم‌مصرف‌تر شدن.

پایهٔ ایده speculative decoding ه: یه مدل کوچک و سریع (drafter) چند توکن حدس می‌زنه و مدل بزرگ (verifier) اون‌ها رو موازی تأیید می‌کنه؛ اگه حدس‌ها با پیش‌بینی مدل بزرگ یکی بودن قبول می‌شن، وگرنه از اولین اختلاف عقب‌گرد می‌شه. مشکل نسخهٔ کلاسیک اینه که drafter مستقل (مثلاً ۱۲۸ میلیون پارامتر) هم رم می‌خوره، هم نسبت به حالت درونی مدل اصلی کوره.

MTP به‌جای مدل جدا، یه هد ترنسفورمری سبک به لایه‌های آخر مدل اصلی می‌چسبونه که از فعال‌سازی‌های نهایی همون مدل استفاده می‌کنه. وزن‌های مدل پایه فریز می‌مونن و فقط پارامترهای هد آموزش می‌بینن — یعنی MTP صرفاً یه بهینه‌سازی کاراییه و نه به توانایی‌های مدل دست می‌زنه نه به هم‌ترازی ایمنیش. چون حدس‌های غلط موقع تأیید دور ریخته می‌شن، خروجی نهایی بیت‌به‌بیت با مدل اصلی یکیه.

قطعهٔ مهندسی جالب ماجرا معماری zero-copy ه. یه drafter معمولی حتی با وزن مشترک، KV cache خودش رو می‌سازه و نگه می‌داره — که روی موبایل مالیات مضاعف رمه. این‌جا هد MTP مستقیماً به KV cache فریزشدهٔ مدل اصلی cross-attend می‌کنه. نتیجه: تأخیر prefill درفتر صفر می‌شه و ۱۳۰ مگابایت رم به‌ازای هر instance صرفه‌جویی می‌شه.

طبق آزمایش‌ها، هد MTP نسبت به drafterهای مستقلِ هم‌اندازه، حدس‌های دقیق‌تری می‌زنه و روی پیکسل ۹ بسته به وظیفه ۵۰٪ یا بیشتر شتاب می‌ده. توی کارهای دستوری مثل خلاصه‌سازی و بازنویسی با محدودیت، اختلافش با drafter مستقل زیاده و در متن‌های ساختارمند مثل smart reply تا ۵۵٪ بهبود در نرخ پذیرش توکن دیده شده. در بار کاری واقعی هم به‌طور میانگین نزدیک دو توکن اضافی در هر pass درست پیش‌بینی می‌شه.

گوگل می‌گه قدم‌های بعدی شامل decode موازی، معماری‌های بدون هد کمکی، بررسی مسیرهای شاخه‌شاخه به‌جای فرض یه آیندهٔ قطعی، و «سهل‌گیری در تأیید» — یعنی شل‌کردن شرط تطابق دقیق توکن‌ها در بعضی کاربردها — ست.

نکات کلیدی:

• MTP روی مدل فریزشدهٔ Gemini Nano v3 سوار می‌شه، پس نه بازآموزی لازمه نه توانایی و ایمنی مدل تغییر می‌کنه
• هد سبک ترنسفورمری جای drafter مستقل رو می‌گیره و از فعال‌سازی‌های نهایی مدل اصلی استفاده می‌کنه
• معماری zero-copy: هد به KV cache مدل اصلی cross-attend می‌کنه، پس prefill اضافه نداره و ۱۳۰MB رم کمتر می‌خوره
• خروجی نهایی بیت‌به‌بیت با مدل پایه یکیه، چون حدس‌های غلط در مرحلهٔ تأیید حذف می‌شن
• روی پیکسل ۹ و ۱۰ تا ۵۰٪ شتاب و تا ۵۵٪ بهبود نرخ پذیرش توکن در کارهای ساختارمند گزارش شده