Cloudflare گزارش حادثه مفصلی را منتشر کرده است که توضیح می‌دهد چگونه یک باگ مدیریت حافظه پنهان در پلتفرم هوش مصنوعی بدون سرور خود باعث شد حداقل 155 کاربر از استقرار مدل GLM-5.3 پاسخ‌هایی حاوی بخش‌هایی از اعلان‌ها و خروجی‌های دیگر مشتریان را دریافت کنند. این گزارش که در 26 اکتبر به عنوان یک افشای هماهنگ در کنار پروژه موتور استنتاج منبع باز SGLang منتشر شد، یک نگاه عمومی نادر به لوله‌کشی سرویس LLM چند مستاجر ارائه می‌کند - و هشداری در مورد مفروضات امنیتی حافظه GPU.

چگونه نشت پیدا شد For more context on this story, see our ongoing breaking AI news.

با توجه به Cloudflare، محقق امنیتی Gadi Evron از Knostic در 8 سپتامبر 2026، از طریق برنامه جایزه باگ HackerOne به شرکت هشدار داد. Evron گزارش داد که درخواست‌های بسیار طولانی که به مدل GLM-5.3 در پلتفرم هوش مصنوعی Cloudflare's Workers ارسال می‌شد، گاهی اوقات متنی را که متعلق به جلسات دیگر کاربران بود، برمی‌گرداند. Cloudflare صبح روز بعد این مشکل را بازتولید کرد و همان روز مدل را غیرفعال کرد و در 9 سپتامبر پس از اجرای اصلاحات آن را بازیابی کرد.

مدل آسیب‌دیده @cf/zai-org/glm-5.3 بود - مدل کدگذاری عاملی از Z.ai که Cloudflare از طریق Workers AI، پلت‌فرم استنتاج بدون سرور این شرکت ارائه می‌کند. Cloudflare تأیید کرد که هیچ مدل دیگری که روی پلتفرم میزبانی شده بود تحت تأثیر قرار نگرفت.

واقعا چه اتفاقی افتاد

این حادثه به دو مشکل همپوشانی برمی‌گردد، یکی عملیاتی و دیگری در خود موتور.

اول، پیکربندی نادرست. Cloudflare GLM-5.3 را با یک پنجره زمینه 1,048,576 توکن مستقر کرد، اما حافظه پنهان کلید-مقدار (KV) روی پردازنده‌های گرافیکی پیش‌پرش تنها برای 681280 توکن جا داشت. این شرکت اذعان کرد که قبل از راه اندازی از این عدم تطابق آگاه بود و انتظار داشت که موتور استنتاج درخواست های بیش از حد را با خیال راحت رد کند.

دوم، اشکال موتور. در حالت prefill/decode تفکیک‌شده – معماری Workers AI استفاده می‌کند، که در آن یک مجموعه از GPU‌ها درخواست را پردازش می‌کنند و حافظه پنهان KV حاصل را به یک مجموعه جداگانه از GPU‌هایی که پاسخ را تولید می‌کنند تحویل می‌دهد – SGLang درخواست بیش از حد طول را به اشتباه مدیریت کرد. درخواستی که با استخر مطابقت نداشت، به‌عنوان رد شده در داخل علامت‌گذاری شد و با یک مکان‌نمای تک نشانه جایگزین شد. اما به جای لغو درخواست و برگرداندن یک خطای مشتری، مرحله prefill حافظه پنهان KV را برای درخواست مکان‌دار ایجاد کرد و آن را به گره رمزگشایی منتقل کرد، که سپس پاسخی را تولید کرد که با داده‌های باقی‌مانده از درخواست‌های قبلی که همان صفحات حافظه را به اشتراک می‌گذاشتند مخلوط شد.

نتیجه: بین 27 اوت و 9 سپتامبر، تعداد کمی از مشتریانی که از این مدل استفاده می‌کردند، پاسخ‌هایی را دریافت کردند که حاوی داده‌هایی از درخواست‌های دیگر مشتریان کمی قبل از درخواست‌های آنها بود. در مجموع، 155 پاسخ تحت تأثیر قرار گرفتند - همه، طبق یافته های Cloudflare، بیش از 681280 توکن را درخواست کردند.

شواهدی مبنی بر بهره برداری عمدی وجود ندارد

Cloudflare اظهار داشت که پس از حذف آزمایش‌های خود و درخواست‌های اعتبارسنجی محقق، درخواست‌های تحت‌تأثیر از نظر زمان و حجم با استفاده از زمینه معمولی سازگار بودند و این شرکت هیچ مدرکی مبنی بر سوء استفاده عمدی از این باگ پیدا نکرد. از آنجایی که هر درخواست آسیب‌دیده از ظرفیت استخر کوچک‌تر فراتر می‌رفت، پنجره نوردهی کاملاً محدود بود - یک پوشش نقره‌ای که از پیکربندی نادرست ناشی از این مشکل ناشی می‌شود.

راه حل: استخرهای بزرگتر و یک مسیر شکست ایمن تر

اصلاح روی هر دو لایه شکست کار کرد. Cloudflare استقرار GLM-5.3 خود را برای مطابقت با پیکربندی GLM-5.2 خود مجدداً پیکربندی کرد و به اندازه کافی حافظه GPU را آزاد کرد که در استخر KV پیش‌پر اکنون حدود 2.04 میلیون توکن در خود جای می‌دهد - تقریباً دو برابر طول زمینه 1,048,576 توکن مدل. اعلانی که با پنجره زمینه مطابقت دارد، اکنون همیشه با استخر مطابقت دارد.

اما این شرکت همچنین تاکید کرد که تکیه بر اندازه استخر به تنهایی شکننده است: تغییرات در کوانتیزاسیون، موازی سازی تانسور، اندازه‌های نمودار CUDA یا یک نسخه مدل آینده می‌تواند به‌طور بی‌صدا اندازه استخر را تغییر دهد. بنابراین، مسیر رد SGLang را نیز وصله کرد، و اطمینان حاصل کرد که درخواست رد شده به‌جای تولید و انتقال حافظه پنهان برای نگه‌دارنده، به‌طور تمیز سقط می‌شود. هر دو تغییر در برابر اسکریپت بازتولید محقق و آزمایش‌های نشانگر قناری خود Cloudflare قبل از بازیابی مدل تأیید شدند، و اصلاحات در بالادست به نگهدارنده‌های SGLang ارائه شده‌اند.

چرا حافظه GPU مشترک یک سوال امنیتی است

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

این افشاگری به جامعه توسعه دهندگان رسید: این داستان در عرض چند ساعت به 123 نقطه در Hacker News رسید، با بحث بر روی چگونگی حالت شکست - درخواستی که باید با صدای بلند شکست می خورد و در حالت خراب بی سر و صدا پیش می رفت - منعکس کننده درس های کلاسیک از مهندسی سیستم های توزیع شده است.

درس گسترده تر برای زیرساخت هوش مصنوعی

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

برای شرکت‌هایی که بر روی پلت‌فرم‌های هوش مصنوعی بدون سرور کار می‌کنند، نتیجه گزارش Cloudflare دو جنبه دارد: اشکال‌های جداسازی مستاجر در سرویس LLM واقعی هستند و قبلاً در تولید رخ داده‌اند، و زمان پاسخ‌دهی فروشندگان - کمتر از 24 ساعت از گزارش تا غیرفعال کردن، یک روز برای تعمیر و بازیابی - استاندارد سخت‌کوشی برای درخواست از هر ارائه‌دهنده حساسی است که رسیدگی می‌کند.

---

Stay Ahead of AI

Get the latest AI news, analysis, and breakthroughs — all in one place.

Read more AI news →