שיטות מומלצות להסקת מסקנות באצווה ב-GKE

במסמך הזה מוסברות שיטות מומלצות להרצה של עומסי עבודה של הסקת מסקנות באצווה ב-Google Kubernetes Engine ‏ (GKE). הסקת אצווה היא תהליך שבו משתמשים במודל למידת מכונה כדי ליצור חיזויים בקבוצות נתונים גדולות, תוך מתן עדיפות לתפוקה גבוהה ולחיסכון בעלויות על פני תגובות מיידיות עם זמן אחזור קצר.

במדריך הזה יש הבחנה בין הסקת אצווה לבין יצירת אצווה של בקשות (או יצירת אצווה דינמית) – שיטה בצד השרת במנועים כמו vLLM או SGLang, שמקבצת בקשות בו-זמניות בזמן אמת כדי לשפר את היעילות של המאיץ. אפשר להחיל אצווה של בקשות על עומסי עבודה של הסקת מסקנות באצווה.

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

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

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

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

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

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

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

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

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

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

• זמן אחזור: הזמן עד לקבלת הטוקן הראשון (TTFT) יכול לנוע בין עשרות שניות לדקות.
• מקורות נתונים: בדרך כלל מעבדים מערכי נתונים בגודל של מגה-בייט עד גיגה-בייט, כמו הודעות מ-Pub/Sub או קבצים מ-Cloud Storage שנצברו בחלון זמן קצר.
• דפוס המחשוב: התשתית צריכה לתמוך בשירות רציף שמטפל בעומסי עבודה תכופים.
• אופטימיזציה של העלויות: הדפוס הזה מציע איזון בין הסקת מסקנות בזמן אמת עם זמן אחזור נמוך לבין עיבוד ברצף (batch processing) עם תפוקה גבוהה.

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

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

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

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

כשמטמיעים הסקה באצווה, חשוב להתייחס למאפיינים הבאים:

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

אופטימיזציה של קצב העברת הנתונים ויעילות העלות

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

שימוש ב-VM במודל Spot כדי להפחית את עלויות המחשוב

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

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

שינוי גודל האצווה של עומס העבודה וגודל האצווה של הבקשה

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

כוונון גודל האצווה של עומס העבודה

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

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

• חישוב גודל האצווה המינימלי: ודאו שגודל האצווה של עומס העבודה הוא לפחות כמו גודל האצווה של הבקשה. לדוגמה, שליחת פריט אחד לשרת שיכול לעבד 256 פריטים בו-זמנית מובילה לניצול חלקי בלבד של השרת. כדי למצוא את הגודל המינימלי, בודקים את ההגדרות של שרת ההסקה, כמו הארגומנט max_num_seqs ב-vLLM. אתם יכולים להגדיר את הלוגיקה של הלקוח כך שתקבץ כמה פריטים לבקשה אחת, או לפצל את הנתונים כך שכל משימה תקבל כמות מינימלית של נתונים שעומדת בדרישות של גודל אצווה הבקשות או גדולה ממנו.
• חישוב גודל האצווה המקסימלי: ודאו שגודל האצווה של עומס העבודה מאפשר ל-Pod לסיים לפני שמגיעים לזמן הקצוב הקצוב לתפוגה של activeDeadlineSeconds שמוגדר ב-Kubernetes Job. כדאי להעריך את הזמן שנדרש לעיבוד של קבוצת בקשות אחת ולהגדיר את גודל עומס העבודה כך שה-Pod יסיים את העבודה הרבה לפני המועד האחרון. לדוגמה, אם הערך של activeDeadlineSeconds הוא 3,600 שניות והתקורה של ההפעלה היא 600 שניות, צריך לוודא שזמן הביצוע המקסימלי מאפשר ל-Pod לסיים תוך פחות מ-3,000 שניות.

אם גודל האצווה של עומס העבודה קטן מדי, המשימה תבזבז זמן על תקורה של הפעלת ה-Pod (הורדת משקלים, הקצאת משאבים, הפעלת המאיץ). אם גודל האצווה גדול מדי, קיים סיכון שהמשימה תופסק על ידי GKE בגלל פסק הזמן של activeDeadlineSeconds, מה שיגרום לכך שהמשימה תיכשל וההתקדמות שלה תאבד.

שינוי גודל האצווה של הבקשות

גודל אצווה הבקשות הוא מספר הבקשות המקבילות ששרת ההסקה מעבד במקביל במאיץ. כדי לשפר את הפרמטר הזה, משנים את הדגלים הספציפיים לשרת בהגדרות של שרת ההסקה (לדוגמה, הדגל --max-num-seqs ב-vLLM).

המטרה היא למקסם את השימוש ב-GPU בלי לגרום לשגיאות של חוסר בזיכרון (OOM). אם גודל חבילת הבקשות לא מכויל, המערכת תנצל פחות את המאיץ או תגרום לקריסת שרת המודל. ב-vLLM, אפשר להשתמש בכלים כמו סקריפט auto_tune של vLLM כדי למצוא את הערכים הכי טובים להגדרות max_num_seqs ו-max_num_batched_tokens עבור החומרה הספציפית שלכם. מידע נוסף זמין במאמר אופטימיזציה של ההגדרה של שרת ההסקה במדריך 'סקירה כללית של שיטות מומלצות להסקה ב-GKE'.

הטמעת רכיבים אסינכרוניים להסקה אסינכרונית

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

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

בתרשים מוצג התהליך מ-Pub/Sub למנויים, לשער הסקה ולשרת הסקה, כשהתוצאות נשמרות ב-AlloyDB וההודעות שנכשלו נשלחות לנושא של הודעות שלא ניתן למסור.

הארכיטקטורה מורכבת מהרכיבים הבאים:

• נושא Pub/Sub: משמש כמאגר זמני מתמשך להודעות נכנסות מלקוחות, עם תקופת שמירה של 7 עד 31 ימים.
• מנוי: רכיב שקורא חבילות של הודעות, שולח בקשות לשרת ההסקה ומאשר את העיבוד.
• HPA של מנויים: משנה את גודל הפריסה של המנויים בהתאם למדד num_undelivered_messages (מספר ההודעות שלא אושרו).
• אחסון: שמירת תוצאות ההיקש באמצעות מסד נתונים (כמו AlloyDB) או מאגר אובייקטים (כמו Cloud Storage) .
• ‫Inference Gateway: חושף את עומסי העבודה של ההסקות למנוי.
• שרת הסקה: מעבד את בקשות ההסקה באצווה (לדוגמה, vLLM).
• ‫Server HPA: משנה את קנה המידה של מנוע ההסקה לפי מדדים ספציפיים למנוע, כמו vllm:num_requests_waiting.
• נושא להודעות ללא מוצא: מתעד הודעות שהעיבוד שלהן נכשל אחרי מספר מוגדר של ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).

מידע נוסף זמין ביישום לדוגמה ב-GitHub.

אגירת בקשות וצירוף שלהן

כדי לנהל את זרימת הבקשות:

• שימוש ב-Pub/Sub כמאגר נתונים זמני עמיד: הטמעה של Pub/Sub לאחסון עמיד של בקשות הסקה. ההגדרה הזו פועלת כמאגר FIFO שמכיל בקשות עד שלצרכן יש קיבולת לעבד אותן, וכך מונעת עומס יתר על השרת בזמן תנועה גבוהה.
• שימוש במינויי משיכה עם בקרת זרימה בצד הלקוח: מגדירים מודל מינוי משיכה. ההגדרה הזו מאפשרת לאפליקציית המנויים לבקש הודעות באופן מפורש רק כשיש לה יכולת לעבד אותן, וכך אתם מקבלים שליטה מלאה על קצב הצריכה.
• צריך לצבור הודעות כדי למלא את גודל האצווה של השרת: לא מומלץ לשלוח הודעת Pub/Sub אחת כבקשת הסקה אחת. במקום זאת, המנוי צריך לאגד כמה הודעות בבקשת Batch אחת שתואמת לגודל האצווה האופטימלי של שרת ההסקה (לדוגמה, תואם להגדרות max_num_seqs ב-vLLM). הגישה הזו עוזרת לוודא שההאצות מנוצלות במלואן וממקסמת את קצב העברת הנתונים. במיוחד, צריך להגדיר את הגדרת המשיכה של המנוי למספר שהוא כפולה של max_num_seqs כדי להבטיח שכל העברה קדימה של המודל תהיה רוויה לחלוטין.max_messages

התאמה אוטומטית לעומס של אפליקציות רשומות ושרתים

כדי להסיק מסקנות ביעילות באצווה, צריך לשנות את קנה המידה של המנויים (מוגבלים על ידי המעבד) באופן שונה משרתי ההסקה (מוגבלים על ידי ה-GPU או ה-TPU).

• התאמת מספר המנויים בהתאם לעומס העבודה: הגדרת HorizontalPodAutoscaler‏ (HPA) לפריסת המנויים על סמך מדד num_undelivered_messages מ-Pub/Sub. מידע נוסף זמין בדוגמה של HPA ב-Pub/Sub. מחשבים את מספר הרפליקות שרוצים להשתמש בהן באמצעות המשוואה הבאה:

  \[ desiredReplicas = \frac{num\_undelivered\_messages}{target\_latency\_seconds \times throughput\_per\_replica} \]

• הקפדה על מכסות התשתית: הגדירו את הערך maxReplicas ב-HPA כדי להגביל באופן מפורש את מספר הרפליקות המקסימלי של המנויים. אל תגדילו את מספר המנויים מעבר למכסת ה-GPU או ה-TPU של שרתי ההסקה. הקצאת יתר של מנויים תעביר את צוואר הבקבוק לשרת ההסקה, ותגדיל את התחרות על המשאבים בלי להגדיל את התפוקה.

• התאמת גודל השרתים של ההסקות על סמך מדדי המנוע: התאמת גודל הפריסה של שרת ההסקות על סמך מדדים שמיוצאים ישירות על ידי מנוע ההסקות (ולא רק דרך CPU/זיכרון). לדוגמה, אפשר להשתמש בvllm:num_requests_waitingהגדרה של vLLM, שמודדת ישירות את העומס של העיבוד ברמת שרת המודל. מידע נוסף מופיע במאמר בנושא התאמה אוטומטית לעומס של ה-Pods.

טיפול בשגיאות ובפסק זמן

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

• הארכה יזומה של מועדי האישור: מגדירים את המנוי כך שיאריך באופן יזום את מועד האישור (ack) של Pub/Sub להודעות שנמצאות בתהליך עיבוד, כדי למנוע לולאות של שליחה חוזרת ועיבוד כפול. הגישה הזו נדרשת כי משימות הסקה לרוב אורכות יותר מחלונות הזמן הקצובים שמוגדרים כברירת מחדל. ככלל, כדאי להגדיר את תקופת ההארכה כך שתהיה ארוכה יותר מזמן ההסקה של אצווה במקרה הגרוע ביותר.
• בידוד כשלים באמצעות נושא להודעות ללא מוצא: הפעלה של נושא להודעות ללא מוצא כדי לבודד באופן אוטומטי הודעות פגומות שלא נמסרו שוב ושוב. הגישה הזו מונעת מהודעות מסוג "poison pill" לחסום את התור ולהפסיק את כל הצינור.
• הטמעת אסטרטגיות השהיה לפני ניסיון חוזר (backoff): אם שרת ההסקה מחזיר את השגיאות 429 (יותר מדי בקשות) או 503 (השירות לא זמין), המנוי צריך לזהות אותן ולהטמיע אסטרטגיית השהיה מעריכית לפני ניסיון חוזר (exponential backoff), ולהשהות באופן זמני את הצריכה מ-Pub/Sub עד שהשרת יתאושש.

תזמור משימות באצווה בקנה מידה גדול

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

שימוש ב-JobSet להסקה מבוזרת בכמה צמתים

מומלץ להשתמש במשאב JobSet של Kubernetes כדי לתזמן עומסי עבודה של הסקת מסקנות מבוזרת שדורשים שיתוף פעולה בין כמה צמתים, כמו מודלים גדולים שפועלים ב-TPU Pods או באשכולות GPU מרובי-צמתים. משימות רגילות של Kubernetes לא יכולות להבטיח שכל ה-Pods הנדרשים יתחילו בו-זמנית, מה שעלול להוביל למבוי סתום בעומסי עבודה מבוזרים.

‫JobSet הוא API מקורי של Kubernetes שמנהל קבוצות של משימות כיחידה אחת, ומספק את היתרונות הבאים להסקת מסקנות באצווה:

• תזמון קבוצתי: עוזר לוודא שכל המשאבים הנדרשים, כמו חלקי TPU או צמתי GPU, זמינים לפני הפעלת עומס העבודה כדי למנוע מצבי קיפאון.
• מיקום בלעדי: עוזר להבטיח של-JobSet יחיד תהיה גישה בלעדית לטופולוגיית הרשת (לדוגמה, חלוקת TPU) כדי למקסם את הביצועים של הקישוריות.
• התאוששות מכשל: מאפשרת להפעיל מחדש משימות משוכפלות ספציפיות או את כל קבוצת המשימות אם ה-worker נכשל, בהתאם להגדרות האישיות.

שימוש במשימות עם אינדקס לצורך חלוקת נתונים

כשמשתמשים ב-JobSet, מגדירים את ReplicatedJob כך שישתמש בהגדרה completionMode: Indexed. ההגדרה הזו מוסיפה באופן אוטומטי משתנה סביבה של JOB_COMPLETION_INDEX לכל Pod. קוד ההסקה יכול להשתמש באינדקס הזה כדי לבחור באופן דטרמיניסטי קטע נתונים ייחודי לעיבוד.

לדוגמה, אם יש לכם קטגוריה של Cloud Storage עם 100,000 תמונות ואתם פורסים JobSet עם מקביליות של 10, כל אחד מ-10 ה-Pods קורא את האינדקס שלו (0-9) בזמן ההפעלה. לאחר מכן, Pod 0 יכול לחשב שהוא צריך לעבד את התמונות 0 עד 9,999, בעוד ש-Pod 1 מעבד את התמונות 10,000 עד 19,999. הגישה הזו מצמצמת את הצורך בשירות נפרד של תור משימות.

שימוש בתבנית Sidecar לרוויית שרתים

כדי למקסם את השימוש במאיץ, מגדירים את ה-Pods של JobSet עם שני קונטיינרים באמצעות תבנית ה-sidecar:

• שרת הסקה: שרת שעבר אופטימיזציה (כמו vLLM) ומתמקד רק בחישובים של GPU או TPU.
• Client driver: מאגר לוגיקה ששולח באופן אסינכרוני נפח גדול של בקשות לשרת ב-localhost.

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

סיכום רשימת המשימות

קטגוריה	שיטה מומלצת
תבניות ארכיטקטורה	בוחרים בין דפוסי פעולה אסינכרוניים או דפוסי פעולה של אצווה בהתאם לדרישות שלכם לגבי זמן האחזור והנפח.
עלות וקצב העברת נתונים	שימוש ב-VM במודל Spot עם נקודות ביקורת כדי להפחית את עלויות המחשוב. כדאי לכוונן את עומס העבודה ואת גודל האצווה של הבקשות כדי למקסם את השימוש במאיץ.
העברת הודעות והתאמה לעומס	מאגרים ומצברים בקשות באמצעות Pub/Sub כדי למלא אצוות שרת. התאמה אוטומטית לעומס של אפליקציות רשומות על סמך העומס ושל שרתים על סמך מדדי המנוע. טיפול בשגיאות על ידי הארכת המועדים, שימוש בנושא להודעות ללא מוצא והטמעה של השהיה מעריכית לפני ניסיון חוזר (backoff).
Orchestration	שימוש ב-JobSet לתזמון של קבוצות של כמה צמתים להסקת מסקנות מבוזרת. שימוש במשימות עם אינדקסים לפיצול נתונים דטרמיניסטי. הטמעת תבנית sidecar כדי להבטיח שהשרת להסקת מסקנות יהיה רווי.