یک پژوهش تازه درباره بازتولیدپذیری سامانه‌های زبانی نشان می‌دهد که استفاده دوباره از محاسبات پیشوندِ ورودی می‌تواند مسیر اجرای یک عامل را تغییر دهد، حتی وقتی مدل، تنظیمات تولید، بذر تصادفی و ترتیب درخواست‌ها ثابت مانده‌اند. در آزمایش‌های این پژوهش، هرچه وزن‌های مدل با دقت پایین‌تری ذخیره شدند، این تفاوت رفتاری نیز بیشتر شد.

این مقاله ۴ سپتامبر در arXiv منتشر شده و برای IEEE Access ارسال شده است؛ بنابراین هنوز نباید نتایج آن را یافته‌ای قطعی و تعمیم‌پذیر به همه زیرساخت‌ها دانست. پژوهش نیز ادعا نمی‌کند که استفاده از حافظه نهان به‌طور متوسط دقت مدل را کاهش می‌دهد. مسئله اصلی چیز دیگری است: وضعیت داخلی سرویس‌دهنده می‌تواند اجرای ظاهراً یکسان را به مسیر دیگری ببرد.

یک بهینه‌سازی زیرساختی، مسیر عامل را عوض کرد

پژوهشگران یک مجموعه ۸۰‌مرحله‌ای از اجرای چندمرحله‌ای ابزارها را روی دو موتور سرویس‌دهی و چهار قالب متفاوت برای دقت وزن‌ها آزمایش کردند. همه درخواست‌ها به‌صورت ترتیبی و با اندازه دسته یک اجرا شدند، تولید متن حریصانه بود، دما روی صفر قرار داشت و همه درخواست‌ها از بذر ۴۲ استفاده می‌کردند. خود حافظه کلید و مقدار نیز در تمام آزمایش‌ها ۱۶‌بیتی باقی ماند؛ پس متغیر اصلی، دقت وزن‌های مدل بود نه فشرده‌سازی همان حافظه.

وقتی استفاده دوباره از محاسبات ذخیره‌شده غیرفعال بود، اجرای تکراری در همه پیکربندی‌های بررسی‌شده کاملاً یکسان ماند و در ۸۰۰ اپیزود هیچ تفاوتی دیده نشد. اما در مقایسه مسیر محاسبه مجدد با مسیر استفاده از داده‌های ذخیره‌شده، در حالت ۱۶‌بیتی ۳۶٫۲ درصد اپیزودها مسیر متفاوتی پیدا کردند و در حالت چهاربیتی این رقم به ۷۵ درصد رسید.

در یک آزمایش کنترل‌شده‌تر نیز هر یک از دو مسیر، اگر با وضعیت یکسان آغاز می‌شد، در ۴۰ مورد از ۴۰ مورد قابل بازتولید بود؛ با این حال خروجی دو مسیر در ۱۴ مورد با هم تفاوت داشت. بنابراین مسئله را نباید صرفاً «بی‌ثباتی تصادفی» نامید. رفتار سامانه می‌تواند قطعی باشد، اما به وضعیتی وابسته باشد که در خود درخواست ثبت نشده است.

بازپخش یک درخواست بدون ثبت وضعیت سرویس‌دهنده کافی نیست

مقاله در یکی از موتورهای آزمایش‌شده به لایه دیگری از نگهداری پیشوند در سطح سرور برخورد کرد که روی اجرای تکراری اثر زیادی داشت. وقتی این لایه فعال بود، قرار دادن یک اجرای بدون حافظه میان دو اجرای دارای حافظه، نرخ تفاوت را از ۳۸٫۸ به ۷۷٫۵ درصد رساند. با غیرفعال شدن همان لایه، تغییر ترتیب فقط ۱٫۲ درصد تفاوت ایجاد کرد.

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

این شفافیت امکان ممیزی را بهتر می‌کند، اما جای بازتولید مستقل را نمی‌گیرد. یک گزارش جداگانه در پروژه vLLM نیز در ژانویه تفاوت خروجی میان نخستین درخواست بدون داده ذخیره‌شده و درخواست‌های بعدی دارای وجود داده در حافظه نهان را روی سخت‌افزار AMD MI355X ثبت کرده است. آن گزارش از مدل، سخت‌افزار و نسخه دیگری استفاده می‌کند و بازتولید مستقیم مقاله محسوب نمی‌شود، اما نشان می‌دهد تفاوت مسیرهای محاسباتی قبلاً هم در یک موتور واقعی سرویس‌دهی مشاهده شده است.

یافته اصلی درباره بازتولیدپذیری است، نه میانگین دقت

در بخش تک‌مرحله‌ای آزمایش، برخی پاسخ‌ها از درست به غلط و برخی از غلط به درست تغییر کردند، در حالی که میانگین دقت تقریباً ثابت ماند. بنابراین نتیجه درست این نیست که «حافظه نهان دقت را خراب می‌کند».

برای ارزیابی عامل‌ها، ثابت ماندن میانگین امتیاز کافی نیست. تغییر یک توکن می‌تواند انتخاب ابزار، وضعیت میانی، فراخوانی سرویس بیرونی یا زمان وقوع خطا را عوض کند و در عین حال امتیاز نهایی معیار ارزیابی تقریباً همان بماند. در چنین شرایطی دو اجرای ظاهراً هم‌ارز ممکن است مسیرهای عملیاتی متفاوتی را طی کرده باشند.

محدودیت‌های پژوهش نیز جدی‌اند. آزمایش‌ها روی مدل‌های متن‌باز ۷ تا ۱۴ میلیارد پارامتری، یک RTX 4090، محیط تک‌کاربره و داده‌های انگلیسی انجام شده‌اند. مقاله هیچ نرخ مشابهی برای مدل‌های مرزی، رابط‌های برنامه‌نویسی میزبانی‌شده، محیط چندکاربره یا شتاب‌دهنده‌های دیگر اثبات نمی‌کند. همچنین معیار ارزیابی عاملی برای مدل‌های آزمایش‌شده دشوار بوده و نویسنده از آن برای ادعای تغییر در موفقیت نهایی وظایف استفاده نکرده است.

برای بازتولید یک آزمایش باید وضعیت زیرساخت هم ثبت شود

برداشت عملی Aipolix این است که شناسنامه یک آزمایش مدل زبانی بزرگ نباید در نام مدل، دستور ورودی، دما و بذر متوقف شود. وقتی لایه سرویس‌دهی میان درخواست‌ها وضعیت نگه می‌دارد، همان وضعیت نیز بخشی از شرایط آزمایش است.

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

برای مدل‌های کم‌دقت نکته دیگری هم وجود دارد. کاهش دقت وزن‌ها معمولاً برای صرفه‌جویی در حافظه و هزینه انجام می‌شود، اما فرایند ارزیابی اغلب فرض می‌کند ورودی یکسان به معنی آزمایش قابل مقایسه است. این پژوهش نشان می‌دهد این دو تصمیم می‌توانند به هم وابسته باشند. اگر دقت کمتر باعث شود اختلاف عددی کوچک ناشی از مسیر حافظه نهان آسان‌تر مرز انتخاب توکن را جابه‌جا کند، نسخه کم‌دقت باید دقیقاً با همان تنظیمات سرویس‌دهیِ محیط واقعی ارزیابی شود.

داده‌ها برای بررسی دوباره در دسترس‌اند

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

این سطح از انتشار بسته پژوهشی باعث می‌شود نتیجه، حتی پیش از داوری نهایی، برای تیم‌های فنی قابل بررسی باشد. پرسش باز همچنان میزان تعمیم‌پذیری است: آیا همین اندازه اثر روی مدل‌های دیگر، شتاب‌دهنده‌های متفاوت، دسته‌های هم‌زمان و سرویس‌های چندکاربره نیز دیده می‌شود؟

فعلاً نتیجه قابل دفاع روشن است: در سامانه‌هایی که قابلیت بازتولید اجرای مدل زبانی بزرگ اهمیت دارد، استفاده از پیشوندهای ذخیره‌شده را نباید یک جزئیات کاملاً نامرئی زیرساخت دانست؛ و کاهش دقت وزن‌ها ممکن است اثر رفتاری آن را بسیار پررنگ‌تر کند.

منابع
- https://arxiv.org/abs/2609.04748
- https://github.com/aditi-p31/cache-divergence-study
- https://github.com/vllm-project/vllm/issues/33123