نشت داده میان درخواست‌ها در GLM-5.3؛ باگ SGLang و پیکربندی ناسازگار

چه اتفاقی افتاد؟

به گفتهٔ شرکت، مدل GLM-5.3 از روز عرضه، یعنی ۲۷ اوت، با این مشکل در دسترس بود. یک پژوهشگر امنیتی شب ۸ سپتامبر مشکل را از مسیر برنامهٔ باگ‌بانتی گزارش کرد. صبح ۹ سپتامبر راستی‌آزمایی شروع شد، حدود ساعت ۱۳:۲۲ UTC حادثه رسماً اعلام شد و نشت داده ظرف ۲۵ دقیقه تأیید شد. مدل حدود ساعت ۱۴:۰۰ از دسترس خارج شد، ریشهٔ مشکل نیم ساعت بعد پیدا شد و سرویس همان روز، نزدیک ساعت ۱۹:۴۰، با اصلاحات دوباره برقرار شد.

دامنهٔ اثر محدود بود: ۱۵۵ پاسخ در حدود ۱۳ روز، همگی برای درخواست‌هایی با طول بیش از ۶۸۱٬۲۸۰ توکن. مدل‌های دیگر این سرویس تحت تأثیر نبودند. شرکت می‌گوید پس از کنار گذاشتن آزمایش‌ها و فعالیت پژوهشگر، الگوی درخواست‌های آسیب‌دیده با استفادهٔ عادی از زمینهٔ طولانی همخوان بوده و شواهدی از سوءاستفادهٔ عمدی پیدا نکرده است.

ریشهٔ فنی: پنجرهٔ زمینه بزرگ‌تر از حافظهٔ کش

مدل‌های زبانی برای تولید سریع‌تر، حالت میانی محاسبات (KV cache) را روی GPU نگه می‌دارند. در معماری «تفکیک‌شده»، یک دسته GPU مرحلهٔ prefill یعنی پردازش پرامپت را انجام می‌دهند و کش حاصل را به GPUهای مرحلهٔ decode تحویل می‌دهند.

در این استقرار، پنجرهٔ زمینه روی ۱٬۰۴۸٬۵۷۶ توکن تنظیم شده بود، اما استخر کش GPU فقط ۶۸۱٬۲۸۰ توکن جا داشت. شرکت می‌گوید از این اختلاف خبر داشته و فرض کرده بود موتور آن را به‌شکل امن مدیریت می‌کند.

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

اصلاحات و توصیه‌ها

برای رفع فوری، اندازهٔ استخر کش به حدود ۲٫۰۴ میلیون توکن افزایش یافت تا درخواست‌ها به مسیر ردشدن نرسند. موتور هم طوری وصله شد که درخواست‌های بیش‌ازحد طولانی پیش از انتقال کش کنار گذاشته شوند. چند وصله به نسخه‌های v0.5.21 و v0.5.22 از SGLang راه یافته است.

در سخت‌سازی بلندمدت، آزادسازی تأخیری کش در عملیات انتقال، اعتبارسنجی checksum در تحویل از prefill به decode، تغییر در توزیع بار برای جلوگیری از abortهای غیرضروری و گسترش کانَری‌های تشخیص خرابی کش اضافه شده است. شرکت همچنین از هدفی به نام «یکپارچگی ذاتی» با برچسب‌های رمزنگاشتی در سطح صفحه و راستی‌آزمایی صوری پروتکل‌ها خبر داده است.

چرا مهم است؟

این حادثه نشان می‌دهد در سرویس‌های استنتاج چندمستاجری، مرز امنیتی فقط در لایهٔ API یا احراز هویت نیست؛ حافظهٔ GPU و کش مشترک هم بخشی از سطح حمله‌اند. اگر تیم شما مدل متن‌باز را با SGLang یا موتورهای مشابه روی زیرساخت خودتان اجرا می‌کند، به‌ویژه در حالت prefill/decode جداگانه، مقایسهٔ حد زمینه با ظرفیت واقعی کش و بازبینی مسیرهای خطا ضروری است.

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