خبر تأییدشده
Cloudflare در گزارش ۲۶ اکتبر ۲۰۲۶ توضیح داد که مدل GLM-5.3 در Workers AI بین ۲۷ اوت و ۹ سپتامبر با نقص جداسازی درخواست‌ها روبه‌رو بوده است. طبق گزارش، ۱۵۵ پاسخ به ورودی‌های بسیار بلند متأثر شدند و ممکن بود داده درخواست قبلی را نشان دهند. شرکت می‌گوید سایر مدل‌ها آسیب ندیده‌اند و شواهدی از بهره‌برداری عمدی پیدا نکرده است. علت، ترکیب ناسازگاری ظرفیت کش با طول context و خطایی در SGLang بود. مدل در ۹ سپتامبر پس از اصلاح پیکربندی و موتور دوباره فعال شد. تاریخ خبر، زمان انتشار گزارش است؛ زمان وقوع و رفع رخداد به سپتامبر برمی‌گردد.
تحلیل مستقل IROSG
درس عملی این رخداد برای بهره‌برداران مدل، اهمیت آزمون مرز منابع است. یک سامانه ممکن است در ورودی عادی پاسخ درست بدهد، اما هنگام عبور از ظرفیت حافظه رفتار متفاوتی نشان دهد. از نگاه تحریریه، آزمون کارکرد باید علاوه بر کیفیت پاسخ، بررسی کند درخواست نامعتبر چگونه متوقف می‌شود و چه وضعیتی از اجرای قبلی باقی می‌ماند. موفقیت یک تست طولانی نیز به‌تنهایی همه مسیرهای رد درخواست را پوشش نمی‌دهد.
در سامانه چندمستاجری، پاک‌سازی و مالکیت حافظه جزئیات صرفاً عملکردی نیستند. اگر یک بخش فرایند تصور کند داده جدید آماده است و بخش دیگر تنها بخشی از آن را نوشته باشد، مسئله می‌تواند از خطای پاسخ به نقض محرمانگی تبدیل شود. بنابراین پیشنهاد ما ثبت قرارداد روشن میان اجزای سرویس است: چه کسی تکمیل انتقال را تأیید می‌کند، شکست چگونه منتقل می‌شود و آیا مصرف‌کننده اجازه دارد از وضعیت ناقص استفاده کند.
برای سازمانی که مصرف‌کننده سرویس مدیریت‌شده است، اقدام مناسب با نقش ارائه‌دهنده متفاوت خواهد بود. تیم مشتری باید بازه زمانی و مدل مورد استفاده خود را با دامنه گزارش مقایسه کند، نوع اطلاعات ارسال‌شده را مشخص کند و اطلاعیه‌های مستقیم ارائه‌دهنده را بررسی کند. از این گزارش نباید نتیجه گرفت همه درخواست‌ها یا همه مدل‌های سرویس در معرض همان مشکل بوده‌اند. محدود نگه‌داشتن ادعا به دامنه تأییدشده، بخشی از پاسخ دقیق به رخداد است.
از منظر طراحی ارزیابی، داده آزمایشی قابل تشخیص می‌تواند در بررسی جداسازی مفید باشد. پیشنهاد تحریریه برای آزمایشگاه مجاز این است که درخواست‌های مستقل با داده ساختگی مشخص اجرا شوند و خروجی‌ها از نظر اختلاط بررسی شوند. این آزمایش باید در محیط کنترل‌شده و بدون داده واقعی مشتری انجام شود. هدف، کشف نقص در سامانه تحت اختیار تیم است، نه بررسی داده سایر کاربران یک سرویس عمومی.
انتشار گزارش پس از رفع مشکل نیز یک فرصت آموزشی ایجاد می‌کند. مسئولان فنی می‌توانند ببینند کدام فرض نادرست بوده و چگونه آن فرض در آزمون و پایش آینده حذف می‌شود. معیار بلوغ فقط سرعت بازگرداندن سرویس نیست؛ توان تبدیل تجربه رخداد به کنترل قابل تکرار نیز اهمیت دارد. این برداشت تحلیلی IROSG است و جایگزین ارزیابی مستقل امنیت سرویس یا نتیجه تحقیقات ارائه‌دهنده نیست.
مرور فرض‌های ظرفیت باید پس از تغییر مدل یا پیکربندی تکرار شود، زیرا آزمونی که برای یک ترکیب موفق بوده لزوماً رفتار ترکیب بعدی را تضمین نمی‌کند.
