מאחורי הקלעים של קלוד: תחקיר חושף שלוש תקלות תשתית שהשפיעו על המודל

בין אוגוסט לתחילת ספטמבר, שלוש תקלות תשתית פגעו לסירוגין באיכות התגובות של קלוד. כעת פתרנו תקלות אלו ואנו מבקשים להסביר מה קרה.

בתחילת אוגוסט, מספר משתמשים החלו לדווח על ירידה באיכות התגובות מקלוד. דיווחים ראשוניים אלו היו קשים להבדלה מתנודות רגילות במשוב המשתמשים. אך לקראת סוף אוגוסט, התדירות וההתמדה הגוברת של הדיווחים הניעו אותנו לפתוח בחקירה, שהובילה לחשיפת שלוש תקלות תשתית נפרדות.

חשוב להדגיש: אנו לעולם איננו מפחיתים את איכות המודל עקב ביקוש, שעת היום או עומס שרתים. הבעיות שדווחו על ידי המשתמשים נבעו אך ורק מתקלות תשתית.

אנו מבינים כי משתמשים מצפים לאיכות עקבית מקלוד, ואנו שומרים על סטנדרט גבוה במיוחד כדי להבטיח ששינויים בתשתית לא ישפיעו על הפלטים של המודל. במקרים האחרונים, לא עמדנו בסטנדרט זה. התחקיר שלפניכם מסביר מה השתבש, מדוע הזיהוי והפתרון ארכו יותר זמן מהמצופה, ומה אנו משנים כדי למנוע תקריות דומות בעתיד.

לרוב איננו משתפים רמה כזו של פירוט טכני אודות התשתית שלנו, אך היקף ומורכבות התקלות הצדיקו הסבר מקיף יותר.

כיצד אנו משרתים את קלוד בקנה מידה רחב

אנו משרתים את קלוד למיליוני משתמשים באמצעות ה-API הישיר שלנו, Amazon Bedrock ו-Vertex AI של Google Cloud. אנו פורסים את קלוד על פני פלטפורמות חומרה מרובות, ובפרט AWS Trainium, מעבדי NVIDIA GPU ומעבדי Google TPU. גישה זו מספקת את הקיבולת והפיזור הגיאוגרפי הדרושים כדי לשרת משתמשים ברחבי העולם.

לכל פלטפורמת חומרה מאפיינים שונים ודרישות אופטימיזציה ספציפיות. למרות שוני זה, יש לנו סטנדרטים מחמירים לשוויון ביישומי המודל. מטרתנו היא שהמשתמשים יקבלו תגובות באותה איכות, ללא קשר לפלטפורמה המשרתת את בקשתם. מורכבות זו פירושה שכל שינוי בתשתית דורש אימות קפדני בכל הפלטפורמות והתצורות.

ציר זמן של האירועים

אופיין החופף של תקלות אלו הפך את האבחון למאתגר במיוחד. התקלה הראשונה הוטמעה ב-5 באוגוסט, והשפיעה על כ-0.8% מהבקשות שיועדו למודל Sonnet 4. שתי תקלות נוספות נבעו מפריסות שבוצעו ב-25 וב-26 באוגוסט.

אף שההשפעות הראשוניות היו מוגבלות, שינוי באיזון עומסים ב-29 באוגוסט החל להגדיל את התעבורה המושפעת. הדבר גרם לכך שהרבה יותר משתמשים חוו בעיות, בעוד שאחרים המשיכו לראות ביצועים רגילים, מה שיצר דיווחים מבלבלים וסותרים.

שלוש תקלות חופפות

להלן תיאור של שלוש התקלות שגרמו לירידה באיכות, מתי אירעו וכיצד נפתרו:

1. שגיאת ניתוב חלון הקשר

ב-5 באוגוסט, חלק מבקשות מודל Sonnet 4 נותבו בטעות לשרתים שהוגדרו עבור חלון הקשר העתידי של 1M טוקנים. תקלה זו השפיעה תחילה על 0.8% מהבקשות. ב-29 באוגוסט, שינוי שגרתי באיזון עומסים הגדיל באופן לא מכוון את מספר הבקשות עם הקשר קצר שנותבו לשרתי חלון הקשר של 1M טוקנים. בשעה החמורה ביותר, ב-31 באוגוסט, 16% מהבקשות למודל Sonnet 4 הושפעו.

כ-30% ממשתמשי Claude Code שביצעו בקשות בתקופה זו חוו ניתוב של לפחות הודעה אחת לסוג שרת שגוי, מה שהוביל לתגובות באיכות ירודה. ב-Amazon Bedrock, תעבורה שנותבה באופן שגוי הגיעה לשיא של 0.18% מכלל בקשות Sonnet 4 החל מ-12 באוגוסט. ניתוב שגוי השפיע על פחות מ-0.0004% מהבקשות ב-Vertex AI של Google Cloud בין 27 באוגוסט ל-16 בספטמבר.

עם זאת, חלק מהמשתמשים הושפעו בחומרה רבה יותר, מכיוון שניתובי השרתים שלנו הם "דביקים" (sticky). משמעות הדבר היא שברגע שבקשה טופלה על ידי שרת שגוי, גם בקשות המשך סביר שיטופלו על ידי אותו שרת שגוי.

פתרון: תיקנו את לוגיקת הניתוב כדי להבטיח שבקשות עם חלון הקשר קצר וארוך יופנו למאגרי השרתים הנכונים. פרסנו את התיקון ב-4 בספטמבר. הפריסה לפלטפורמה הישירה שלנו ול-Vertex AI של Google Cloud הושלמה עד 16 בספטמבר, ול-AWS Bedrock עד 18 בספטמבר.

2. שחיתות פלט

ב-25 באוגוסט, פרסנו תצורה שגויה לשרתי ה-TPU של Claude API, שגרמה לשגיאה במהלך יצירת טוקנים. בעיה שנגרמה על ידי אופטימיזציית ביצועים בזמן ריצה הקצתה לעיתים הסתברות גבוהה לטוקנים שאמורים להיות מיוצרים לעיתים רחוקות בהינתן ההקשר – לדוגמה, יצירת תווים תאילנדיים או סיניים בתגובה לפרומפטים באנגלית, או יצירת שגיאות תחביר ברורות בקוד. תת-קבוצה קטנה של משתמשים ששאלו שאלה באנגלית ייתכן שראו, למשל, "สวัสดี" באמצע התגובה.

שחיתות זו השפיעה על בקשות שיועדו למודלים Opus 4.1 ו-Opus 4 בין 25 ל-28 באוגוסט, ועל בקשות למודל Sonnet 4 בין 25 באוגוסט ל-2 בספטמבר. פלטפורמות צד שלישי לא הושפעו מבעיה זו.

פתרון: זיהינו את הבעיה וביצענו החזרה לאחור (rollback) של השינוי ב-2 בספטמבר. הוספנו בדיקות זיהוי לפלטי תווים בלתי צפויים לתהליך הפריסה שלנו.

3. שגיאת קומפילציה ב-approximate top-k XLA:TPU

ב-25 באוגוסט, פרסנו קוד שנועד לשפר את אופן בחירת הטוקנים של קלוד במהלך יצירת טקסט. שינוי זה הפעיל בשוגג באג רדום בקומפיילר XLA:TPU[1], שאושר ככזה שהשפיע על בקשות למודל Claude Haiku 3.5.

אנו גם מאמינים כי ייתכן שזה השפיע על תת-קבוצה של Sonnet 4 ו-Opus 3 ב-Claude API. פלטפורמות צד שלישי לא הושפעו מבעיה זו.

פתרון: זיהינו לראשונה את הבאג משפיע על Haiku 3.5 וביצענו החזרה לאחור ב-4 בספטמבר. מאוחר יותר שמנו לב לדיווחים ממשתמשים על בעיות במודל Opus 3 שהיו תואמות לבאג זה, וביצענו החזרה לאחור גם שם ב-12 בספטמבר. לאחר חקירה מקיפה לא הצלחנו לשחזר באג זה במודל Sonnet 4 אך החלטנו לבצע החזרה לאחור גם עבורו מתוך זהירות יתרה.

במקביל, (א) עבדנו עם צוות XLA:TPU על תיקון לבאג הקומפיילר ו-(ב) פרסנו תיקון לשימוש ב-exact top-k עם דיוק משופר. לפרטים נוספים, ראו את הניתוח המעמיק להלן.

הצצה מקרוב לבאג הקומפיילר של XLA

כדי להמחיש את מורכבות התקלות הללו, כך התבטא באג הקומפיילר של XLA ומדוע אבחונו התגלה כמאתגר במיוחד.

כאשר קלוד מייצר טקסט, הוא מחשב הסתברויות עבור כל מילה אפשרית הבאה, ולאחר מכן בוחר באופן אקראי דגימה מהתפלגות הסתברות זו. אנו משתמשים ב"דגימת top-p" כדי למנוע פלטים חסרי היגיון – תוך התחשבות רק במילים שההסתברות המצטברת שלהן מגיעה לסף מסוים (בדרך כלל 0.99 או 0.999). ב-TPU, המודלים שלנו רצים על פני שבבים מרובים, כאשר חישובי ההסתברות מתבצעים במיקומים שונים. כדי למיין הסתברויות אלו, עלינו לתאם נתונים בין שבבים, מה שהופך את התהליך למורכב.[2]

בדצמבר 2024, גילינו שיישום ה-TPU שלנו ישמיט לעיתים את הטוקן הסביר ביותר כאשר ה-טמפרטורה הייתה אפס. פרסנו פתרון עוקף (workaround) לטיפול במקרה זה.

שורש הבעיה היה קשור לחישובים בדיוק מעורב. המודלים שלנו מחשבים הסתברויות לטוקן הבא ב-bf16 (נקודה צפה של 16 סיביות). עם זאת, מעבד הוקטורים הוא fp32-native, כך שהקומפיילר של ה-TPU (XLA) יכול לבצע אופטימיזציה של זמן הריצה על ידי המרת פעולות מסוימות ל-fp32 (32 סיביות). מעבר אופטימיזציה זה נשלט על ידי הדגל xla_allow_excess_precision, שברירת המחדל שלו היא true.

הדבר גרם לחוסר התאמה: פעולות שאמורות היו להסכים על הטוקן בעל ההסתברות הגבוהה ביותר רצו ברמות דיוק שונות. חוסר התאמת הדיוק גרם לכך שהן לא הסכימו על איזה טוקן היה בעל ההסתברות הגבוהה ביותר. הדבר גרם לטוקן בעל ההסתברות הגבוהה ביותר להיעלם לעיתים לגמרי מטווח השיקולים.

ב-26 באוגוסט, פרסנו שכתוב של קוד הדגימה שלנו כדי לתקן את בעיות הדיוק ולשפר את אופן הטיפול בהסתברויות המגיעות לסף ה-top-p. אך בתיקון בעיות אלו, חשפנו בעיה מורכבת יותר.

התיקון שלנו הסיר את פתרון העוקף מדצמבר מכיוון שהאמנו שפתרנו את שורש הבעיה. הדבר הוביל לבאג עמוק יותר בפעולת ה-approximate top-k – אופטימיזציית ביצועים שמוצאת במהירות את הטוקנים בעלי ההסתברות הגבוהה ביותר.[3] קירוב זה החזיר לעיתים תוצאות שגויות לחלוטין, אך רק עבור גדלי אצווה (batch sizes) ותצורות מודל מסוימים. פתרון העוקף מדצמבר הסווה בטעות את הבעיה הזו.

התנהגות הבאג הייתה בלתי עקבית באופן מתסכל. היא השתנתה בהתאם לגורמים לא קשורים כמו אילו פעולות רצו לפניו או אחריו, והאם כלי איתור באגים הופעלו. אותו פרומפט יכול היה לעבוד בצורה מושלמת בבקשה אחת ולהיכשל בבקשה הבאה.

במהלך החקירה, גילינו גם שלפעולת ה-exact top-k כבר לא הייתה את פגיעת הביצועים המרתיעה שהייתה לה בעבר. עברנו מ-approximate ל-exact top-k ותקננו פעולות נוספות לדיוק fp32.[4] איכות המודל אינה נתונה למשא ומתן, ולכן קיבלנו את ההשפעה הקטנה על היעילות.

מדוע האיתור היה קשה

תהליך האימות שלנו מסתמך בדרך כלל על מדדי ביצועים, לצד הערכות בטיחות ומדדי ביצועים. צוותי ההנדסה מבצעים בדיקות מדגמיות ופורסים תחילה לקבוצות "קנריות" קטנות.

תקלות אלו חשפו פערים קריטיים שהיינו צריכים לזהות מוקדם יותר. ההערכות שביצענו פשוט לא קלטו את ירידת האיכות שדווחה על ידי המשתמשים, בין השאר מכיוון שקלוד לרוב מתאושש היטב מטעויות נקודתיות. נוהלי הפרטיות שלנו גם יצרו אתגרים בחקירת הדיווחים. בקרות הפרטיות והאבטחה הפנימיות שלנו מגבילות את האופן והזמן שבו מהנדסים יכולים לגשת לאינטראקציות של משתמשים עם קלוד, במיוחד כאשר אינטראקציות אלו אינן מדווחות לנו כמשוב. זה מגן על פרטיות המשתמשים אך מונע ממהנדסים לבחון את האינטראקציות הבעייתיות הנדרשות לזיהוי או שחזור באגים.

כל באג יצר תסמינים שונים בפלטפורמות שונות ובשיעורים שונים. הדבר יצר תערובת מבלבלת של דיווחים שלא הצביעה על גורם יחיד. זה נראה כמו ירידת איכות אקראית ובלתי עקבית.

באופן בסיסי יותר, הסתמכנו יתר על המידה על הערכות רועשות. אף שהיינו מודעים לעלייה בדיווחים ברשת, לא הייתה לנו דרך ברורה לחבר אותם לכל אחד מהשינויים האחרונים שלנו. כאשר דיווחים שליליים זינקו ב-29 באוגוסט, לא קישרנו זאת מיד לשינוי איזון עומסים סטנדרטי לכאורה.

מה אנו משנים

ככל שאנו ממשיכים לשפר את התשתית שלנו, אנו משפרים גם את הדרך שבה אנו מעריכים ומונעים באגים מסוג אלו שנדונו לעיל, בכל הפלטפורמות שבהן אנו משרתים את קלוד. הנה השינויים שאנו מבצעים:

• הערכות רגישות יותר: כדי לסייע באיתור שורש הבעיה של כל תקלה נתונה, פיתחנו הערכות שיכולות להבחין בצורה מהימנה יותר בין יישומים תקינים ליישומים תקולים. נמשיך לשפר הערכות אלו כדי לפקוח עין קרובה יותר על איכות המודל.
• הערכות איכות במקומות נוספים: אף שאנו מריצים הערכות קבועות על המערכות שלנו, נריץ אותן ברציפות על מערכות ייצור אמיתיות כדי לתפוס בעיות כגון שגיאת איזון העומסים של חלון ההקשר.
• כלי איתור באגים מהירים יותר: נפתח תשתית וכלים לטובת איתור באגים יעיל יותר על בסיס משוב מהקהילה, מבלי לוותר על פרטיות המשתמשים. בנוסף, כלים מותאמים אישית שפותחו כאן ישמשו להפחתת זמן התיקון בתקריות דומות עתידיות, אם וכאשר יתרחשו.

הערכות וניטור חשובים. אך תקריות אלו הראו שאנו זקוקים גם לאות רציף מהמשתמשים כאשר התגובות מקלוד אינן עומדות בסטנדרט הרגיל. דיווחים על שינויים ספציפיים שנצפו, דוגמאות להתנהגות בלתי צפויה שנתקלה, ותבניות על פני מקרי שימוש שונים – כל אלו סייעו לנו לבודד את הבעיות.

המשך קבלת משוב ישיר מהמשתמשים שלנו נותר חשוב במיוחד. ניתן להשתמש בפקודה /bug ב-Claude Code או בכפתור ה'אגודל למטה' (thumbs down) באפליקציות של קלוד לשם כך. מפתחים וחוקרים לעיתים קרובות יוצרים דרכים חדשות ומעניינות להעריך את איכות המודל, המשלימות את הבדיקות הפנימיות שלנו. אם תרצו לשתף את דרכי ההערכה שלכם, פנו אלינו בכתובת feedback@anthropic.com.

אנו נותרים אסירי תודה לקהילה שלנו על תרומות אלו.

תודות

נכתב על ידי סם מקאליסטר (Sam McAllister), עם תודות לסטוארט ריצ'י (Stuart Ritchie), ג'ונתן גריי (Jonathan Gray), קאשיאפ מוראלי (Kashyap Murali), ברנאן סאטה (Brennan Saeta), אוליבר ראוש (Oliver Rausch), אלכס פלקואי (Alex Palcuie), ורבים אחרים.

[1] XLA:TPU הוא הקומפיילר המייעל המתרגם את שפת האופטימיזציה ברמה גבוהה של XLA – הנכתבת לעיתים קרובות באמצעות JAX – להוראות מכונה של TPU.

[2] המודלים שלנו גדולים מדי עבור שבבים יחידים ומחולקים על פני עשרות שבבים או יותר, מה שהופך את פעולת המיון שלנו למיון מבוזר. ל-TPU (בדיוק כמו ל-GPU ול-Trainium) יש גם מאפייני ביצועים שונים מאלה של מעבדי CPU, הדורשים טכניקות יישום שונות המשתמשות בפעולות וקטוריות במקום באלגוריתמים סדרתיים.

[3] השתמשנו בפעולה מקורבת זו מכיוון שהיא הניבה שיפורי ביצועים משמעותיים. הקירוב פועל על ידי קבלת אי-דיוקים פוטנציאליים בטוקנים בעלי ההסתברות הנמוכה ביותר, מה שאמור לא להשפיע על האיכות – אלא כאשר הבאג גרם לו להשמיט במקום זאת את הטוקן בעל ההסתברות הגבוהה ביותר.

[4] יש לציין כי יישום ה-top-k המתוקן כעת עשוי לגרום להבדלים קלים בהכללת טוקנים הקרובים לסף ה-top-p, ובמקרים נדירים משתמשים עשויים להפיק תועלת מכוונון עדין מחודש של בחירת ה-top-p שלהם.