विस्तृत विश्लेषण · लगभग 6 मिनट पढ़ना
Cloudflare ने GLM-5.3 कैश अलगाव घटना समझाई: सफल उत्तर सुरक्षा का प्रमाण क्यों नहीं था
26 अक्टूबर की रिपोर्ट अगस्त–सितंबर की घटना, लागू सुधारों और अभी अधूरे मेमोरी अखंडता कार्य को अलग रखती है।
- यहाँ प्रकाशित
- स्रोत की तारीख
- स्रोत जाँचा गया
Cloudflare ने 26 अक्टूबर को Workers AI पर अपने GLM-5.3 परिनियोजन में एक अनुरोध का डेटा दूसरे के उत्तर में आने की रिपोर्ट प्रकाशित की। कंपनी इसे कैश क्षमता के अंतर और SGLang के अस्वीकृति प्रबंधन दोष का संयुक्त परिणाम बताती है। सेवा 9 सितंबर को ठीक हुई थी; यह नई बाधा या हर GLM परिनियोजन में प्रमाणित दोष की खबर नहीं है।
समाचार सुनें
यह लेख सुनें या समाचार लगातार चलाएँ।
पढ़ने की तैयारी हो रही है…
डिवाइस की आवाज़
वाक् प्रक्रिया आपके ब्राउज़र या डिवाइस में होती है। AISubHub पाठ किसी ऑडियो API को नहीं भेजता। आवाज़ों और लॉक स्क्रीन पर चलने की सुविधा डिवाइस पर निर्भर है।
जारी करने पर छोटा वाक्यांश दोहराया जा सकता है।
मुख्य बातें
- कंपनी के अनुसार 27 अगस्त से 9 सितंबर के बीच 155 उत्तर प्रभावित हुए, सभी 681,280 tokens से लंबे prompts के थे। यह उत्तरों की संख्या है, ग्राहकों की नहीं।
- घोषित संदर्भ 1,048,576 tokens था, जबकि prefill पूल 681,280 समा सकता था। सुधार के बाद लगभग 2.04 मिलियन tokens हैं; इंजन का अस्वीकृति मार्ग भी ठीक किया गया।
- अलग prefill/decode चलाने वालों को SGLang v0.5.22 या बाद का संस्करण सुझाया गया है। पहचान क्षमता वास्तुकला पर निर्भर है और भविष्य के उपाय सार्वभौमिक गारंटी नहीं हैं।
प्रकाशन की तारीख और घटना की अवधि अलग हैं
Cloudflare ने प्रभाव की अवधि Workers AI पर 27 अगस्त के लॉन्च से 9 सितंबर तक बताई है। Knostic के शोधकर्ता Gadi Evron ने 8 सितंबर को सूचना दी। अगले दिन 13:22 UTC पर घटना घोषित हुई, 14:00 पर मॉडल का सार्वजनिक उपयोग रोका गया और बदलाव व सत्यापन के बाद 19:40 पर बहाल किया गया। 26 अक्टूबर समन्वित खुलासे की तारीख है।
कंपनी ने 155 ऐसे उत्तर पहचाने जिनमें उसी मॉडल के अन्य ग्राहकों के हालिया अनुरोधों की सामग्री थी। अपने और शोधकर्ता के परीक्षण हटाने के बाद समय व मात्रा सामान्य लंबे संदर्भ वाले उपयोग जैसी थी और जानबूझकर शोषण का प्रमाण नहीं मिला, ऐसा उसका कहना है। यह कभी दुरुपयोग न होने का प्रमाण नहीं है। अन्य Workers AI मॉडल अप्रभावित होने का दावा भी कंपनी का है।
घोषित संदर्भ भौतिक कैश पूल से बड़ा था
इस व्यवस्था में prefill GPU prompt संसाधित करके key/value कैश को Mooncake तथा RDMA के जरिये decode GPU तक भेजते थे। SGLang मॉडल weights लोड होने के बाद बची मेमोरी से पूल का आकार तय करता था। संदर्भ सीमा अलग कॉन्फ़िगर होती थी। इसलिए 1,048,576 tokens की विंडो के साथ केवल 681,280 tokens का पूल मौजूद था।
Cloudflare मानता है कि लॉन्च से पहले अंतर ज्ञात था, लेकिन लंबे संदर्भ के परीक्षण सफल लौटने पर उसने अधिक बड़े अनुरोध सुरक्षित ढंग से अस्वीकार होने की अपेक्षा की। रिपोर्ट में कमी मानी गई है कि HTTP स्थिति और प्रदर्शन जाँचे गए, आउटपुट पर्याप्त नहीं जाँचा गया। विवरण कॉन्फ़िगरेशन और इंजन की परस्पर क्रिया का है; मॉडल weights में backdoor का प्रमाण नहीं देता।
अस्वीकृत अनुरोध फिर भी सक्रिय माना गया
शेड्यूलर ने बहुत बड़े अनुरोध को अस्वीकार करने के लिए चिह्नित किया और prompt की जगह एक-token placeholder रखा। लेकिन अलग-अलग नोडों की admission जाँच यह देखती थी कि अनुरोध समाप्त हुआ है या नहीं, न कि अस्वीकार हुआ है या नहीं। लंबित त्रुटि समाप्ति की शर्त पूरी नहीं करती थी। दोनों पक्ष ऐसे अनुरोध को स्वीकार कर लेते थे जिसे त्रुटि के साथ रुकना चाहिए था।
मूल चित्र आठ आरक्षित पृष्ठों का उदाहरण देता है: नया अनुरोध एक पृष्ठ लिखता है, जबकि decode सात पुराने पृष्ठ भी पढ़ सकता है। ये समझाने की संख्याएँ हैं, घटना के मापे हुए कुल नहीं। ग्राहक को HTTP 200, उचित लगती token गणना और संगत पाठ मिल सकता था, जिसमें पुराने अनुरोधों की सामग्री हो। सफल उत्तर सही अलगाव का प्रमाण नहीं था।
तत्काल सुधार की दो परतें थीं
Cloudflare के अनुसार कॉन्फ़िगरेशन बदलने पर prefill पूल लगभग 2.04 मिलियन tokens का हुआ, जो 1,048,576-token संदर्भ से बड़ा है। इंजन में लंबित अस्वीकृति admission पर ही समाप्त की गई, allocation या कैश transfer से पहले। कंपनी कहती है कि बहाली से पहले दोनों बदलाव सत्यापित किए गए। केवल पूल बढ़ाना भविष्य की मेमोरी सेटिंग पर नाजुक निर्भरता छोड़ देता।
उपरि परियोजना की तालिका v0.5.20 के शुरुआती सुधार, v0.5.21 की पहले होने वाली अस्वीकृति और v0.5.22 तक के अतिरिक्त सुदृढ़ीकरण अलग करती है। कंपनी अलग prefill/decode ऑपरेटरों को v0.5.22 या बाद का संस्करण, अथवा उपयुक्त backports सुझाती है। यह उस सेवा विधि और patch समूह की सलाह है, प्रदर्शन तुलना या संस्करण स्थापित करते ही हर परिनियोजन सुरक्षित होने का प्रमाण नहीं।
चलती हुई लिखाइयाँ पृष्ठों का जीवनचक्र जटिल बनाती हैं
रिपोर्ट एक संबंधित त्रुटि वर्ग भी समझाती है: अनुरोध abort करने से पहले भेजी गई RDMA writes वापस नहीं आतीं। गंतव्य पृष्ठ बहुत जल्दी दोबारा देने पर देर से आने वाली write दूसरे अनुरोध को बिगाड़ सकती है। उस समय-निर्भर race के विपरीत, इस घटना का अस्वीकृत अनुरोध निश्चित रूप से गलत handoff मार्ग पर चलता था। दोनों में सभी भागीदार क्रियाएँ पूरी होने तक स्वामित्व का हिसाब चाहिए।
Cloudflare दोनों भूमिकाओं में deferred release, सीमित Mooncake batches, load balancer की disconnect प्रक्रिया में बदलाव और deployment checks बताता है। weights, quantization या parallelism बदलने पर दोनों वास्तविक pools मापने की सलाह है। Checksum और KV Canary हर architecture को समर्थन नहीं देते; विकल्प चालू होने भर से हर अनुरोध की जाँच मानना उचित नहीं।
दीर्घकालीन अखंडता कार्य अभी अधूरा है
पृष्ठ tags का prototype अगस्त में GLM-5.2 पर जाँचा गया था। Cloudflare अपने परीक्षणों में throughput और tail latency का खर्च 1% से कम बताता है, पर विश्वसनीयता समस्याओं के कारण उसे जल्द बंद भी किया। यह सीमित प्रयोग का आँकड़ा है, सक्रिय सुरक्षा या सामान्य overhead का माप नहीं। पृष्ठ छोड़ते समय zero करने की योजना अभी draft proposal है।
Transfer checksum handoff जाँचता है; पृष्ठ स्वामित्व की जाँच बाद के reads तक सत्यापन बढ़ाएगी। Cloudflare वितरित transfer protocol की formal modeling की भी योजना बनाता है, लेकिन प्रमाणों की सीमाएँ स्वीकार करता है। AISubHub विश्लेषण: अलगाव, अस्वीकृति और जीवनचक्र के नियम अलग सत्यापित होने चाहिए, तथा लागू सुरक्षा, prototypes और भविष्य की गारंटी स्पष्ट अलग रखनी चाहिए।
यह क्यों अहम है
AISubHub विश्लेषण: किरायेदारों के बीच अलगाव की अपनी स्वीकृति कसौटी होनी चाहिए। HTTP स्थिति, token गणना और गति सामान्य दिख सकती हैं, भले मेमोरी स्वामित्व गलत हो। कॉन्फ़िगरेशन और विफलता मार्गों की जाँच प्रदर्शन benchmark से अलग प्रश्नों का उत्तर देती है।
सीमाएँ और उपलब्धता
प्रभाव का दायरा, सुधार और जानबूझकर दुरुपयोग का प्रमाण न मिलने का कथन Cloudflare का है। AISubHub ने सेवा या patches का स्वतंत्र audit नहीं किया। इससे सभी GLM परिनियोजनों के प्रभावित होने या हर SGLang कॉन्फ़िगरेशन के कैश जीवनचक्र त्रुटियों से सुरक्षित होने का निष्कर्ष नहीं निकलता।
स्रोत और प्रमाण
स्रोत की तारीख: · स्रोत जाँचा गया:
AI की सहायता से लिखे लेखों को दिए गए प्राथमिक स्रोतों से जाँचा जाता है। प्रदाता के दावों का श्रेय स्पष्ट है; सूची में होना समर्थन नहीं है।