- अगस्त से सितंबर की शुरुआत तक Claude के response quality में गिरावट की घटना तीन infrastructure bugs की वजह से हुई
- समस्या के मुख्य कारण क्रमशः context window routing error, output corruption, और XLA:TPU approximate top-k miscompile त्रुटि थे
- हर bug अलग-अलग hardware और deployment paths पर एक-दूसरे के साथ ओवरलैप हुआ, जिससे diagnosis और कठिन हो गया
- Detection और resolution में देरी के कारणों में validation process की कमियां और privacy policy के कारण access restrictions शामिल थे
- Anthropic ने evaluation और monitoring को मजबूत करने, और तेज debugging tools विकसित करने जैसे उपायों से ऐसी घटनाओं की पुनरावृत्ति रोकने की दिशा में कदम उठाए हैं
अवलोकन और पृष्ठभूमि
- अगस्त से सितंबर की शुरुआत तक Claude के response quality में बीच-बीच में गिरावट की रिपोर्ट मिली
- शुरुआत में इसे user feedback के भीतर सामान्य उतार-चढ़ाव माना गया, लेकिन रिपोर्ट लगातार बढ़ने पर जांच शुरू की गई
- Anthropic ने स्पष्ट किया कि इसका कारण demand या server load नहीं, बल्कि केवल infrastructure bugs थे
- Claude को लाखों users तक APIs, Amazon Bedrock, Google Vertex AI जैसे कई platforms के जरिए उपलब्ध कराया जाता है, और AWS Trainium, NVIDIA GPU, Google TPU जैसे अलग-अलग hardware पर समान परिणाम सुनिश्चित करने के लिए कड़े validation standards लागू हैं
- इस पोस्टमॉर्टम में bug के कारण, diagnosis और resolution में देरी के कारण, और recurrence रोकने के उपाय बताए गए हैं
Claude को बड़े पैमाने पर सेवा देने का तरीका
- Claude service कई hardware platforms (Trainium, GPU, TPU) के जरिए global deployment बनाए रखती है
- हर platform पर समान quality सुनिश्चित करने के लिए implementation equivalence standards सख्त हैं
- infrastructure में बदलाव होने पर सभी platforms और settings में सटीक validation process की आवश्यकता होती है
प्रमुख घटनाक्रम की समयरेखा
- 5 अगस्त: पहला bug, Sonnet 4 requests के लगभग 0.8% पर असर
- 25 और 26 अगस्त: दूसरा और तीसरा bug क्रमशः deploy हुए
- 29 अगस्त: load balancing बदलाव के कारण प्रभावित traffic तेजी से बढ़ा, और अधिक users प्रभावित हुए
- हर bug के symptoms एक-दूसरे पर चढ़े हुए थे, इसलिए diagnosis बहुत कठिन था
तीन ओवरलैपिंग bugs और समाधान प्रक्रिया
1. Context window routing error
- 5 अगस्त को Sonnet 4 की कुछ requests को 1M token context window के लिए बने servers पर गलत तरीके से route कर दिया गया
- load balancing बदलाव के बाद Sonnet 4 requests के अधिकतम 16% तक असर पड़ा, और Amazon Bedrock व Google Vertex AI पर भी मामूली असर देखा गया
- routing तरीका "sticky" था, इसलिए एक बार गलत server से जुड़ने पर आगे भी वही server बार-बार इस्तेमाल होता रहा
- समाधान: routing logic में सुधार, 4 सितंबर को Anthropic के अपने platform पर patch लागू, Google Cloud पर 16 सितंबर तक deploy, और Bedrock पर चरणबद्ध rollout जारी है
2. Output corruption (bug)
- 25 अगस्त को Claude API के TPU servers पर गलत setting लागू हो गई, जिससे token generation के दौरान errors होने लगे
- अंग्रेजी सवालों के जवाब में थाई या चीनी जैसे असंगत अक्षर मिल जाने, या code में साफ़ grammar errors जुड़ जाने जैसी समस्याएँ सामने आईं
- असर केवल Opus 4.1, Opus 4 और Sonnet 4 पर पड़ा; third-party platforms प्रभावित नहीं हुए
- समाधान: 2 सितंबर को बदलाव rollback किया गया, और abnormal character output detect करने वाले tests को deployment process में जोड़ा गया
3. Approximate top-k XLA:TPU miscompile error
- 25 अगस्त को token selection method को बेहतर बनाने के दौरान XLA:TPU compiler में एक latent bug सामने आया
- इसका असर Claude Haiku 3.5, कुछ Sonnet 4, और Opus 3 पर पड़ा
- third-party platforms प्रभावित नहीं हुए
- समाधान: Haiku 3.5 को 4 सितंबर और Opus 3 को 12 सितंबर को rollback किया गया; Sonnet 4 पर यह सीधे reproduce नहीं हुआ था, फिर भी एहतियातन rollback किया गया
- साथ ही XLA:TPU टीम के साथ मिलकर compiler bug को ठीक किया जा रहा है, और exact top-k method पर switch किया गया है
XLA compiler bug का विस्तृत विश्लेषण
- Claude token generation के दौरान हर candidate के लिए probability calculation और sampling करता है
- TPUs distributed environment में काम करते हैं, इसलिए token probabilities को synchronize करना पड़ता है, जो जटिल होता है
- 2024 के दिसंबर में bf16-32-bit mixed precision के कारण error से highest-probability token छूट जाने की समस्या मिली, जिसके लिए एक temporary fix deploy किया गया
- 26 अगस्त को root cause को हल करने के लिए sampling code में बदलाव के दौरान approximate top-k operation में एक और गहरा bug सामने आया, जिसमें कुछ मामलों में पूरी तरह गलत output आने लगा
- पहले का temporary fix इस समस्या को छिपा रहा था
- साथ ही approximate top-k bug के symptoms production environment और batch size के अनुसार अनियमित रूप से बदलते थे
- approximate top-k की जगह अब performance cost काफी कम हो जाने के कारण exact top-k अपनाया गया है, और प्रमुख operations को fp32 standardization के जरिए सुधारा गया है
Detection में देरी के कारण
- periodic automated evaluation और pre-group deployment जैसी प्रक्रियाएँ पहले से इस्तेमाल हो रही थीं
- इस घटना ने evaluation process की कमियों को उजागर किया। उदाहरण के लिए, कुछ evaluation items समस्या की स्थितियों को ठीक से detect नहीं कर पाए, और internal privacy policy (engineers को specific user requests तक पहुंच नहीं) की वजह से तेज analysis मुश्किल हुआ
- platform और version के हिसाब से symptoms अलग-अलग दिखे, इसलिए एक single root cause पहचानना कठिन था
- online reports बढ़ने के बावजूद, standard load balancing change से इसके संबंध को तुरंत पहचाना नहीं जा सका
आगे के सुधार और प्रतिक्रिया उपाय
- उच्च संवेदनशीलता वाले evaluation items विकसित करना, ताकि corrupted state और normal implementation के बीच automated evaluation अधिक स्पष्ट अंतर कर सके
- पूरे production environment में evaluation और monitoring systems का विस्तार, जैसे context window routing error जैसी runtime परिस्थितियों पर केंद्रित evaluation
- तेज और अधिक सटीक debugging tools तैयार करना, ताकि privacy बनाए रखते हुए community feedback का जल्दी analysis किया जा सके, इसके लिए infrastructure और custom tools विकसित किए जा रहे हैं
- internal evaluation के साथ-साथ user feedback के निरंतर संग्रह पर भरोसे पर जोर: जिन errors या bugs की भविष्यवाणी करना कठिन है, उनके लिए वास्तविक user reports अहम signal का काम करती हैं
"/bug"command या 'thumbs down' फीचर का उपयोग, और email के जरिए model quality evaluation methods साझा करने को सक्रिय रूप से प्रोत्साहित किया गया है
संदर्भ विवरण
- XLA:TPU, XLA के high-level optimized language code को TPU instructions में बदलने वाला compiler है
- model size बड़ा होने के कारण इसे एक chip पर नहीं, बल्कि कई chips पर विभाजित करके रखा जाता है, और sorting operations जैसी चीज़ों को vectorized form में implement करना पड़ता है
- approximate top-k operation performance बढ़ाने के लिए उपयोगी है, लेकिन इसमें highest-probability token छूट जाने जैसी गंभीर समस्याएँ हो सकती हैं
- फिलहाल exact top-k method अपनाया गया है, और top-p threshold के करीब आने वाले tokens के शामिल होने के पैटर्न में हल्के बदलाव हो सकते हैं। कुछ मामलों में users को top-p value adjust करनी पड़ सकती है
अभी कोई टिप्पणी नहीं है.