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

במסמך הזה מפורטת סקירה כללית של שיטות מומלצות להפעלת עומסי עבודה של הסקת מסקנות ב-GKE.

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

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

הכנה להצגת מסקנות ב-GKE

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

ניתוח המאפיינים של תרחיש השימוש בהסקת מסקנות

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

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

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

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

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

• התאמה בין משימות לבין אופני פעולה: הערכת מודלים על סמך המשימות שהוקצו להם ואופני הפעולה הנתמכים. מודל שעבר אופטימיזציה למשימה ספציפית כמעט תמיד יניב ביצועים טובים יותר ממודל לשימוש כללי.
• מאפיינים טכניים: הארכיטקטורה של מודל ודיוק סוג הנתונים שלו – כמו FP16,‏ FP8 ו-FP4 – הם גורמים מרכזיים בקביעת דרישות המשאבים והביצועים שלו. ההערכה הזו עוזרת לכם להחליט אם אתם צריכים להשתמש בטכניקות קוונטיזציה. בודקים את הדיוק הנתמך של משקלי המודל, מוודאים שיש תמיכה ב-framework ומאמתים את אורך חלון ההקשר המקסימלי הנתמך של המודל.
• ביצועים ויעילות מבחינת עלות: כדי לקבל החלטה שמבוססת על נתונים, כדאי להשוות בין המודלים שנבחרו באמצעות מדדי השוואה שזמינים לציבור ובאמצעות בדיקות פנימיות משלכם. כדאי להשתמש בטבלאות השוואה כמו Chatbot Arena כדי להשוות בין מודלים, ולבדוק את העלות למיליון טוקנים של כל מודל בחומרה שלכם.

החלת קוונטיזציה על המודל

קוונטיזציה היא טכניקה לאופטימיזציה של עומסי עבודה של היקש על ידי הקטנת הזיכרון שבשימוש של המודל. היא ממירה את המשקלים, ההפעלות והמטמון של זוגות מפתח/ערך (KV) של המודל מפורמטים של נקודה צפה ברמת דיוק גבוהה (כמו FP16,‏ FP32 ו-FP64) לפורמטים ברמת דיוק נמוכה יותר (כמו FP8 ו-FP4). הפחתה בזיכרון יכולה להוביל לשיפורים משמעותיים בביצועים וביעילות העלויות.

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

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

• הערכת הפשרה בין דיוק לבין יעילות: כימוּת עלול לפעמים לגרום לירידה ברמת הדיוק של המודל. כשמעריכים את הפשרה בין דיוק לבין קוונטיזציה, חשוב לזכור שקוונטיזציה של 8 ביט יכולה להוביל לעיתים קרובות לאובדן מינימלי של דיוק. לעומת זאת, קוונטיזציה של 4 ביט יכולה להקטין עד פי ארבע את דרישות הזיכרון של המאיץ, אבל היא גם עלולה לגרום לאובדן דיוק גדול יותר בהשוואה לקוונטיזציה של 8 ביט. כדאי להעריך את הביצועים של המודל שעבר קוונטיזציה בתרחיש השימוש הספציפי שלכם, כדי לוודא שהדיוק עדיין נמצא בטווח קביל. כדי להעריך את אובדן הדיוק, אפשר להשתמש בכלים כמו OpenCompass ו-Language Model Evaluation Harness.
• הערכת התמיכה בהאצת חומרה: כדי להפיק את המרב מהכימות, כדאי להשתמש במאיצים שמספקים האצת חומרה לפורמטים של הנתונים שבהם נעשה שימוש במודל הכמותי. לדוגמה:
  • מעבדים גרפיים (GPU) מסוג NVIDIA H100 מספקים האצת חומרה לפעולות FP8 ו-FP16.
  • מעבדים גרפיים (GPU) מסוג NVIDIA B200 מספקים שיפור מהירות באמצעות חומרה לפעולות FP4,‏ FP8 ו-FP16.
  • ‫Cloud TPU v5p מספק האצת חומרה לפעולות FP8.
• בדיקה אם יש מודלים שעברו קוונטיזציה מראש: לפני שמבצעים קוונטיזציה של מודל בעצמכם, כדאי לבדוק מאגרי מודלים ציבוריים כמו Hugging Face. הכי טוב למצוא מודל שאומן באופן טבעי ברמת דיוק נמוכה יותר, כי זה יכול לשפר את הביצועים בלי לאבד את הדיוק בגלל קוונטיזציה אחרי האימון.
• שימוש בספריית קוונטיזציה: אם מודל שעבר קוונטיזציה מראש לא זמין, אפשר להשתמש בספרייה כדי לבצע את הקוונטיזציה בעצמכם. שרתי הסקה כמו vLLM תומכים בהרצת מודלים שעברו קוונטיזציה במגוון טכניקות. אתם יכולים להשתמש בכלים כמו llm-compressor כדי להחיל טכניקות קוונטיזציה על מודל שלא עבר קוונטיזציה.
• כדאי לשקול כימות של מטמון KV: בנוסף לכימות של המשקלים של המודל, אפשר גם לבצע כימות של מטמון KV. הטכניקה הזו מצמצמת עוד יותר את הזיכרון שנדרש למטמון KV בזמן הריצה, מה שיכול לשפר את הביצועים.

מידע נוסף זמין במאמר בנושא אופטימיזציה של עומסי עבודה של הסקת מסקנות מ-LLM ביחידות GPU.

בחירת המאיצים הנכונים

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

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

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

   כדי להעריך את הזיכרון הנדרש, משתמשים במשוואה הבאה:

   \[ \begin{aligned} \text{Required accelerator memory} = {} & (\text{Model weights} + \text{Overhead} + \text{Activations}) \\ & + (\text{KV cache per batch} \times \text{Batch size}) \end{aligned} \]

   המונחים במשוואה הם:

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

   דוגמה: חישוב דרישות הזיכרון של המאיץ עבור Gemma 3

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

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

   • קלט:
     • משקלי המודלים: 54 GB
     • גודל אצווה (max_num_sequences): 1
     • אורך הקלט הממוצע: 1,500 טוקנים
     • אורך פלט ממוצע: 200 טוקנים
     • תקורה של מנוע ההסקה: 1 GB (משוער)
     • גודל סוג הנתונים של מטמון KV: ‏ 2 (עבור BF16)
     • ווקטורים של זוגות מפתח/ערך: 2 (אחד למפתח ואחד לערך)
   • הגדרת מודל עבור מודל Gemma 3 27B שעבר כוונון להוראות:
     • ‫hidden_size: 5376
     • intermediate_size: 21504
     • ‫num_attention_heads: 32
     • num_hidden_layers: 62
     • ‫num_key_value_heads: 16
   • חישוב הזיכרון:
     • ‫sequence_length = avg_input_length + avg_output_length = 1,500 + 200 = 1,700 טוקנים
     • pytorch_activation_peak_memory = (max_num_sequences * sequence_length * (18 * hidden_size + 4 * intermediate_size)) / (1000^3) = ‎~0.31 GB (משוער).
     • ‫head_dims = hidden_size / num_attention_heads = 5376 / 32 = 168
     • kv_cache_memory_per_batch = (kv_vectors * max_num_sequences * sequence_length * num_key_value_heads * head_dims * num_hidden_layers * kv_data_type_size) / (1000^3) = (2 * 1 * 1700 * 16 * 168 * 62 * 2) / (1000^3) = ~1.13 GB
     • זיכרון נדרש למאיץ = Model weights + Overhead + Activations + KV cache per batch = 54 + 1 + 0.31 + 1.13 = ‎~56.44 GB

   נפח הזיכרון הכולל המשוער במאיץ שנדרש לפריסת המודל הוא בערך 57 GB.

2. הערכת אפשרויות ההאצה: אחרי שמעריכים את דרישות הזיכרון, צריך להעריך את האפשרויות הזמינות של GPU ו-TPU ב-GKE.

   בנוסף לכמות הזיכרון של המאיץ, כדאי להביא בחשבון את הדרישות הבאות של המודל לצורך ההערכה:

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

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

   מאיצים מומלצים לפי תרחיש לדוגמה

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

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

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

   תרחיש לדוגמה	מאיצים מומלצים	סדרת מכונות	מאפיינים מרכזיים
   הסקת מסקנות במודל קטן	NVIDIA L4	G2	אפשרות משתלמת למודלים קטנים (זיכרון של 24 GB לכל GPU).
   	NVIDIA RTX Pro 6000	G4	משתלם למודלים עם פחות מ-30 מיליארד פרמטרים וליצירת תמונות (זיכרון של 96GB לכל GPU). תומך בתקשורת ישירה בין יחידות GPU, ולכן מתאים להסקת מסקנות במארח יחיד עם כמה יחידות GPU.
   	TPU v5e	-	אופטימיזציה של העלות-תועלת.
   	TPU v6e	-	האפשרות הזו מציעה את הערך הכי גבוה למודלים של טרנספורמרים ולמודלים של יצירת תמונות לפי טקסט.
   הסקת מסקנות במודל גדול במארח יחיד	NVIDIA A100	A2	מתאים לרוב המודלים שנכנסים לצומת יחיד (עד 640 GB זיכרון כולל).
   	NVIDIA H100	A3	אידיאלי לעומסי עבודה של הסקת מסקנות שמתאימים לצומת יחיד (עד 640 GB זיכרון כולל).
   	NVIDIA B200	A4	אפשרות עתידית למודלים תובעניים שמתאימים לצומת יחיד (עד 1,440 GB זיכרון כולל).
   	TPU v4	-	האפשרות הזו מציעה איזון טוב בין עלות לביצועים.
   	TPU v5p	-	אפשרות לביצועים גבוהים לעומסי עבודה תובעניים.
   הסקת מסקנות במודל גדול עם כמה מארחים	NVIDIA H200	A3 Ultra	מתאים למודלים גדולים שדורשים הרבה זיכרון (עד 1,128 GB זיכרון כולל).
   	NVIDIA B200 / GB200	A4 / A4X	לעומסי עבודה (workloads) הכי תובעניים, אינטנסיביים מבחינת מחשוב ומוגבלים על ידי הרשת. מכונות A4X משתמשות במעבדי CPU מבוססי-Arm, ולכן יכול להיות שיהיה צורך בשינוי מבנה עומס העבודה (שינויים בקוד מעבר לבנייה מחדש פשוטה של קונטיינר) אם עומס העבודה משתמש בתכונות או באופטימיזציות ספציפיות ל-x86.
   	TPU v5e	-	אופטימיזציה של העלות והביצועים להצגת מודלים גדולים של שפה (LLM) בגודל בינוני עד גדול.
   	TPU v5p	-	אפשרות לביצועים גבוהים להסקת מסקנות בכמה מארחים, שדורשת מקביליות בקנה מידה גדול.
   	TPU v6e	-	אופטימיזציה להצגת מודלים של טרנספורמר, מודלים של יצירת תמונות לפי טקסט ומודלים של CNN.

   דוגמה: בחירת מאיץ למודל של 260GB

   נניח שאתם צריכים לפרוס מודל שדורש 260GB של זיכרון כולל של מאיץ (200GB למודל, 50GB למטמון KV ו-10GB לתקורה).

   על סמך דרישות הזיכרון בלבד, אפשר להחריג מעבדים גרפיים מסוג NVIDIA L4, כי המכונה הגדולה ביותר מסוג G2 מציעה זיכרון מאיץ של עד 192GB. בנוסף, מכיוון שמעבדי L4 GPU לא תומכים בקישוריות מהירה עם זמן אחזור נמוך בין מאיצים, חלוקת עומס העבודה בין כמה צמתים היא לא אפשרות מעשית להשגת הביצועים הרצויים.

   אם אתם רוצים להימנע משינוי מבנה של עומסי העבודה שלכם ב-x86-64 (כלומר, לא לשנות את הקוד כדי שהוא יוכל לפעול על מעבד מסוג אחר), אתם צריכים גם להחריג את המאיצים NVIDIA GB200 ו-GB300, שמשתמשים במעבדי CPU מבוססי-Arm.

   לכן, יש לכם את האפשרויות הבאות:

   • NVIDIA A100
   • NVIDIA RTX Pro 6000
   • NVIDIA H100
   • NVIDIA H200
   • NVIDIA B200

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

   יחידות GPU עם כמה מופעים במקביל

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

   לדוגמה, אפשר לצרף NVIDIA RTX PRO 6000 ולבצע את הפעולות הבאות:

   • לחלק אותו לארבעה מופעים (כל מופע מספק 24 GB של זיכרון מאיץ), ולהריץ מודלים של דיפוזיה או עומסי עבודה של הסקת מסקנות ממודלים קטנים, כמו מודלים עם כ-8 מיליארד פרמטרים שמשתמשים בדיוק של פורמט נתונים FP16 למשקלי המודל. יכול להיות שלמחיצה הזו יש יחס טוב יותר בין מחיר לביצועים בהשוואה ל-NVIDIA L4.
   • אפשר לחלק אותו לשני מופעים (כל מופע מספק 48 GB של זיכרון מאיץ), ולהריץ עומסי עבודה קטנים של הסקת מודלים, כמו מודלים עם כ-15 מיליארד פרמטרים שמשתמשים בפורמט נתונים FP16 לדיוק של משקלי המודל. המחיצה הזו יכולה להיות חלופה להרצת עומסי עבודה של הסקה ב-GPU של NVIDIA A100 40 GB.

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

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

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

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

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

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

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

     דוגמה: מקביליות טנסור

     לדוגמה, נניח שאתם צריכים לפרוס מודל עם 109 מיליארד פרמטרים. ברמת הדיוק שמוגדרת כברירת מחדל, BF16‏ (16 ביט), טעינת המשקלים של המודל לזיכרון המאיץ דורשת כ-113GB. מעבד GPU יחיד מסוג NVIDIA H100 מספק זיכרון בנפח 80 GB. לכן, גם בלי להתחשב בדרישות זיכרון אחרות כמו מטמון KV, אתם צריכים לפחות שני כרטיסי GPU מסוג NVIDIA H100 כדי לטעון את המודל, עם גודל מקביליות טנסור של שניים.

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

     דוגמה: מקביליות היברידית (טנזור וצינור)

     למודל גדול מאוד עם יותר מ-600 מיליארד פרמטרים, דרישת הזיכרון יכולה להיות יותר מ-1.1 TB. בתרחיש עם שני צמתים של a3-megagpu-8g (כל אחד עם שמונה מעבדי GPU של NVIDIA H100), לכל האשכול יש 1.28 TB של זיכרון מאיץ. כדי להריץ את המודל, צריך להטמיע אסטרטגיה היברידית: מקביליות טנסור ב-8 כיוונים בכל צומת, ומקביליות צינור ב-2 כיוונים בשני הצמתים. המודל יפוצל לשני שלבים, כאשר המחצית הראשונה של השכבות תהיה בצומת הראשון והמחצית השנייה בצומת השני. כשבקשה מגיעה, הצומת הראשון מעבד אותה ושולח את נתוני הביניים ברשת לצומת השני, שמשלים את החישוב.

   הנחיות נוספות לבחירת אסטרטגיית הסקה מבוזרת לשכפול של מודל יחיד מופיעות במאמר Parallelism and Scaling (מקביליות ושינוי קנה מידה) במסמכי העזרה של vLLM.

4. בחירת סוג מכונה שעבר אופטימיזציה לשימוש במאיץ: בהתאם לבחירת המאיץ ולמספר המאיצים שאתם צריכים, בוחרים סוג מכונה שמספק את המשאבים האלה. כל סוג מכונה מציע שילוב ספציפי של vCPU, זיכרון מערכת ורוחב פס ברשת, שיכולים גם להשפיע על הביצועים של עומס העבודה. לדוגמה, אם אתם צריכים 16 מעבדי NVIDIA H100 GPU, תצטרכו לבחור את סוג המכונה a3-megagpu-16g.

5. הפעלת מדדים משלכם: הביצועים של עומס העבודה של ההסקה תלויים מאוד בתרחיש השימוש הספציפי שלכם. כדאי להריץ השוואות ביצועים משלכם כדי לאמת את הבחירות ולשפר את ההגדרה.

אופטימיזציה של ההגדרה של שרת ההסקה

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

1. כדאי להתחיל עם מדריך למתחילים בנושא הסקת מסקנות ב-GKE כדי לקבל הגדרת בסיס אופטימלית של Kubernetes לתרחיש השימוש שלכם.
2. להריץ בדיקות השוואה כדי לתעד את מדדי התפוקה וזמן האחזור של קו הבסיס.
3. כדאי לשנות את ההגדרה של שרת ההסקה.
4. מריצים שוב את ההשוואה לשוק ומשווים את התוצאות כדי לאמת את השינויים.

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

• הגדרת מקביליות:
  • ‫Tensor Parallelism (tensor_parallel_size): מגדירים את הערך הזה למספר המאיצים בצומת יחיד כדי לפצל את עומס העבודה. לדוגמה, הגדרה של tensor_parallel_size=4 תחלק את עומס העבודה בין ארבעה מאיצים. חשוב לדעת שהגדלת הערך הזה עלולה להוביל לתקורה מוגזמת של סנכרון.
  • ‫Pipeline Parallelism (pipeline_parallel_size): מגדירים את הערך הזה למספר הצמתים שבהם מפיצים את המודל. לדוגמה, אם אתם פורסים בשני צמתים עם שמונה מאיצים בכל אחד מהם, צריך להגדיר את tensor_parallel_size=8 ואת pipeline_parallel_size=2. הגדלת הערך הזה עלולה להוביל לעיכובים.
• התאמה של מטמון KV ‏ (gpu_memory_utilization): הפרמטר הזה קובע את אחוז זיכרון ה-GPU ששמור למשקלים, להפעלות ולמטמון KV של המודל. ערך גבוה יותר מגדיל את גודל מטמון KV ויכול לשפר את התפוקה. מומלץ להגדיר ערך בין 0.9 ל-0.95. אם נתקלים בשגיאות של חוסר זיכרון (OOM), צריך להקטין את הערך הזה.
• הגדרת אורך מקסימלי של הקשר (max_model_len): כדי להקטין את הגודל של מטמון KV ואת דרישות הזיכרון, אפשר להגדיר אורך מקסימלי של הקשר שהוא קצר יותר מברירת המחדל של המודל. כך תוכלו להשתמש במעבדי GPU קטנים יותר וחסכוניים יותר. לדוגמה, אם תרחיש השימוש שלכם דורש רק הקשר של 40,000 טוקנים, אבל ברירת המחדל של המודל היא 256,000, הגדרה של max_model_len ל-40,000 תפנה זיכרון למטמון KV גדול יותר, מה שעשוי להוביל לתפוקה גבוהה יותר.
• הגדרת מספר הבקשות המקבילות (max_num_batched_tokens, max_num_seqs): כדאי לשנות את המספר המקסימלי של בקשות ש-vLLM מעבד במקביל כדי למנוע הפסקת פעולה לפני הזמן כשאין הרבה מקום במטמון KV. ערכים נמוכים יותר של max_num_batched_tokens ו-max_num_seqs מפחיתים את דרישות הזיכרון, בעוד שערכים גבוהים יותר יכולים לשפר את קצב העברת הנתונים, אבל עלולים לגרום לשגיאות OOM. כדי למצוא את הערכים האופטימליים, מומלץ להריץ ניסויים לבדיקת הביצועים ולעקוב אחרי מספר הבקשות להקדמת תורים במדדים של Prometheus שמערכת vLLM מייצאת.

מידע נוסף זמין במקורות המידע הבאים:

• כדי לקבל מידע מעמיק על אופטימיזציה של הפרמטרים האלה, אפשר לעיין במאמר vLLM Performance Tuning: The Ultimate Guide to xPU Inference Configuration (אופטימיזציה של הביצועים של vLLM: המדריך המלא להגדרת הסקת מסקנות ב-xPU).
• הנחיות נוספות לאופטימיזציה של זיכרון המודל זמינות במאמר שיטות מומלצות לאופטימיזציה של הסקת מסקנות של מודלים גדולים של שפה (LLM) באמצעות יחידות GPU ב-GKE.
• דוגמה מלאה שאפשר לפרוס מופיעה במאמר הטמעה לדוגמה של GKE Inference.

אופטימיזציה של זמן האחזור והזמינות

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

אופטימיזציה של זמן הטעינה של הפעלה מההתחלה (cold startup) של עומס עבודה של הסקת מסקנות

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

אופטימיזציה של זמן ההפעלה של ה-Pod

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

• האצת טעינת המודל באמצעות טוען נתונים שעבר אופטימיזציה: לשיטה שבה אתם משתמשים כדי לאחסן ולטעון את משקלי המודל יש השפעה משמעותית על זמן ההפעלה. בגרסאות vLLM 0.10.2 ואילך, הגישה המומלצת היא להשתמש בRun:ai Model Streamer כדי לטעון מודלים על ידי סטרימינג שלהם ישירות מקטגוריה של Cloud Storage.

  אם הסטרימר לא זמין לתרחיש השימוש שלכם, אתם יכולים לטעון קטגוריה של Cloud Storage באמצעות Cloud Storage FUSE ולשפר את הביצועים שלה על ידי הפעלת מרחבי שמות היררכיים ושימוש בטכניקות כמו הורדות מקבילות ואחזור מראש. מידע נוסף על הטכניקות האלה זמין במאמר בנושא אופטימיזציה של מנהל התקן ה-CSI של Cloud Storage FUSE לביצועים ב-GKE. בכל מקרה, מומלץ להשתמש בRapid Cache כדי ליצור מטמונים אזוריים לקריאה עם ביצועים גבוהים עבור הקטגוריות, ולהפעיל את הגישה האחידה ברמת הקטגוריה כדי לשלוט בגישה לקטגוריות באופן אחיד.

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

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

הפעלת צמתים עם הפעלה מהירה

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

גמישות התוכנית, יעילות וזמינות של קיבולת מאיץ

יכול להיות שהזמינות של מאיצים עם ביקוש גבוה כמו GPU ו-TPU תהיה מוגבלת, ולכן חשוב לתכנן את הקיבולת מראש.

תכנון ושריין קיבולת

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

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

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

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

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

אם עומסי העבודה שלכם יכולים לסבול עיכובים בהקצאת הקיבולת, כדאי להשתמש ב-Dynamic Workload Scheduler (מתזמן דינמי של עומסי עבודה) עם מצב הקצאה של הפעלה גמישה.

אם עומסי העבודה יכולים לסבול עיכוב מסוים בהקצאת הקיבולת, אפשר להשתמש בDynamic Workload Scheduler‏ (DWS) במצב הקצאת משאבים עם גמישות בהתחלה כדי לקבל מאיצים במחיר מוזל. בעזרת DWS אפשר להוסיף בקשות לקיבולת לתור למשך עד שבעה ימים.

כשמשתמשים ב-DWS במצב הקצאת הרשאות עם התחלה גמישה, מומלץ לפעול לפי ההנחיות הבאות:

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

שימוש ב-ComputeClasses

‫ComputeClasses הוא תכונה של GKE שמאפשרת להגדיר רשימה עם עדיפות של הגדרות תשתית לעומסי העבודה. ‫ComputeClasses מספקות יכולות מרכזיות שנועדו לשפר את הגמישות, היעילות והזמינות של קיבולת המאיצים:

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

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

• הזמנות: מספקות את רמת הוודאות הגבוהה ביותר לגבי קבלת קיבולת. כשמשתמשים ב-ComputeClasses כדי לצרוך הזמנות, חשוב להביא בחשבון את ההגבלות שלהן. לדוגמה, בסוגים מסוימים של הזמנות יש הגבלה על סוגי המכונות שאפשר להזמין או על המספר המקסימלי של מכונות שאפשר לבקש.
• על פי דרישה: מודל ההקצאה הרגיל, שמציע גמישות אבל עשוי להיות כפוף למגבלות קיבולת אזוריות עבור משאבים שיש להם ביקוש גבוה.
• מכונות וירטואליות מסוג Spot: שימוש בקיבולת פנויה במחיר נמוך יותר, אבל יכול להיות שהמכונות יופסקו. כשמתרחש אירוע של קדימות, GKE מספק תקופת סיום הדרגתית של עד 30 שניות ל-Pods מושפעים, על בסיס המאמץ המרבי. כדי לנצל את היתרון הזה, צריך להטמיע מנגנונים של נקודות ביקורת וניסיונות חוזרים כדי שהעומסים שלכם יהיו עמידים לאירועי קדימות.
• ‫Dynamic Workload Scheduler (DWS): מאפשר לכם להוסיף בקשות לתור של משאבים נדירים במחירים מוזלים. התכונה הזו מתאימה לעומסי עבודה שיכולים לסבול עיכובים ברכישת קיבולת.

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

עדיפות	עומסי עבודה עם זמן אחזור נמוך	עומסי עבודה (workloads) עם אופטימיזציה של עלויות (סובלים זמן אחזור)
1	הזמנות (ספציפיות, ואז כלליות)	הזמנות (ספציפיות, ואז כלליות)
2	על פי דרישה	מכונות וירטואליות של Spot
3	מכונות וירטואליות של Spot	Dynamic Workload Scheduler
4	Dynamic Workload Scheduler	על פי דרישה

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

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

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

מדיניות המיקום של Cluster Autoscaler קובעת איך GKE מחלק צמתים בין אזורים במהלך אירוע של הגדלת קיבולת. ההגדרה הזו חשובה במיוחד כשמשתמשים ב-ComputeClasses, כי היא קובעת באילו אזורים יתבצע המידרוג האוטומטי של האשכול לפני החלת רשימת העדיפויות של ComputeClass.

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

• ‫location-policy=ANY: נותן עדיפות להשגת קיבולת על פני איזון הצמתים באופן שווה בין האזורים. ההגדרה הזו רלוונטית במיוחד אם ComputeClass כולל מכונות וירטואליות מסוג Spot או סוגי מכונות עם זמינות משתנה, כי ANY מאפשר ל-Cluster Autoscaler לבחור את האזור עם הסיכוי הכי גבוה למילוי סוגי הצמתים לפי סדר העדיפויות של ComputeClass. אפשר להשתמש בהגדרה הזו גם כדי לתת עדיפות לשימוש בהזמנות שלא נעשה בהן שימוש. כשמשתמשים במדיניות הזו, מומלץ להתחיל עם num-nodes=0 כדי לתת ל-Cluster Autoscaler גמישות מקסימלית במציאת קיבולת.

• ‫location-policy=BALANCED: ניסיונות לחלק את הצמתים באופן שווה בין כל האזורים הזמינים. משתמשים במדיניות הזו כשעומסי העבודה משתמשים במשאבים שקל להשיג ורוצים לשמור על יתירות אזורית כדי להבטיח זמינות גבוהה.

אפשר להגדיר את ההגדרה הזו כשיוצרים או מעדכנים מאגר צמתים.

אופטימיזציה של היעילות והעלות

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

מעקב אחרי שרתי ההסקה וההאצה

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

• מעקב אחרי מדדי DCGM של מעבדים גרפיים של NVIDIA: כדי לעקוב אחרי תקינות וביצועים של מעבדים גרפיים של NVIDIA, צריך להגדיר את GKE כך שישלח מדדים של NVIDIA Data Center GPU Manager‏ (DCGM) אל Cloud Monitoring.
• הפעלת מעקב אוטומטי אחרי אפליקציות: כדי לפשט את תהליך המעקב אחרי שרתי ההסקה, מפעילים מעקב אוטומטי אחרי אפליקציות ב-GKE.
• לבצע אינסטרומנטציה לעומסי העבודה באמצעות OpenTelemetry: לעומסי עבודה שלא נתמכים על ידי מעקב אוטומטי אחרי אפליקציות, אפשר להשתמש ב-OpenTelemetry כדי לאסוף מדדים מותאמים אישית ונתוני מעקב.

שינוי גודל אוטומטי של ה-Pods

כדי לוודא שעומסי העבודה של ההסקה יכולים להסתגל באופן דינמי לשינויים בביקוש, כדאי להשתמש ב-Horizontal Pod Autoscaler (HPA) כדי לשנות את מספר ה-Pods באופן אוטומטי. בעומסי עבודה של הסקת מסקנות, חשוב לבסס את ההחלטות לגבי שינוי קנה המידה על מדדים שמשקפים ישירות את העומס על שרת הסקת המסקנות, ולא על מדדי CPU או זיכרון רגילים.

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

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

  • לעומסי עבודה שרגישים לזמן האחזור, יש שתי אפשרויות עיקריות:

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

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

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

• הפעלת פרופיל הביצועים של HPA: ב-GKE בגרסה 1.33 ואילך, פרופיל הביצועים של HPA מופעל כברירת מחדל באשכולות שעומדים בדרישות, כדי לשפר את זמן התגובה של HPA.

למידע נוסף, אפשר לעיין במאמרים הגדרת HPA לעומסי עבודה של מודלים גדולים של שפה (LLM) במעבדי GPU ושינוי אוטומטי של קנה המידה של עומסי עבודה של הסקת מסקנות של מודלים גדולים של שפה (LLM) ב-TPU.

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

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

• יצירת מטמוני קריאה אזוריים באמצעות Rapid Cache: אם אתם משתמשים ב-Cloud Storage לאחסון נתונים עבור עומסי העבודה של AI/ML, כדאי להפעיל את Rapid Cache. ‫Rapid Cache יוצר מטמוני קריאה אזוריים עם ביצועים גבוהים לקטגוריות של Cloud Storage.
• שמירת נתונים במטמון לגישה מהירה באמצעות SSD מקומי: לעומסי עבודה שדורשים גישה עם זמן אחזור נמוך במיוחד לנתונים זמניים, אפשר להשתמש ב-SSD מקומי כמטמון עם ביצועים גבוהים. שימוש בכונני SSD מקומיים כאמצעי אחסון זמני עם זמן אחזור נמוך לאחסון נתונים שנמצאים בשימוש תדיר עוזר לצמצם את זמן ההמתנה של משאבים יקרים, כמו מאיצים, על ידי קיצור משמעותי של הזמן שבו המאיצים מחכים לסיום פעולות קלט/פלט. שימו לב שלא כל סדרות המכונות תומכות בכונני SSD מקומיים, ולכן זה יכול להשפיע על הבחירה שלכם במאיצים.
• ניהול מטמונים באמצעות GKE Data Cache: לעומסי עבודה שקוראים נתונים לעיתים קרובות מדיסקים קבועים, מומלץ להפעיל את GKE Data Cache. מטמון הנתונים של GKE משתמש בכונני SSD מקומיים כדי ליצור מטמון מנוהל עם ביצועים גבוהים עבור כוננים קשיחים קבועים. ברוב עומסי העבודה בסביבת הייצור, מומלץ להשתמש במצב Writethrough כדי למנוע אובדן נתונים על ידי כתיבת נתונים באופן סינכרוני גם למטמון וגם לדיסק הקשיח הבסיסי.

אופטימיזציה לארכיטקטורות מתקדמות של התאמה להיקף השימוש

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

איזון עומסים של תנועה באמצעות GKE Inference Gateway

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

כשמשתמשים ב-GKE Inference Gateway, מומלץ לפעול לפי השיטות המומלצות הבאות:

• קיבוץ של Pods להצגת מודעות ל-InferencePool: מגדירים InferencePool לכל קבוצה של Pods שמציגים את עומסי העבודה של ההסקות. מידע נוסף זמין במאמר בנושא התאמה אישית של ההגדרה של GKE Inference Gateway.
• ריבוב של עומסי עבודה שרגישים לזמן האחזור: מגדירים את InferenceObjectives כדי לציין את מאפייני ההצגה של המודל, כמו השם והעדיפות שלו. ‫GKE Inference Gateway נותן עדיפות לעומסי עבודה עם עדיפות גבוהה יותר, ומאפשר לכם לבצע מולטיפלקס של עומסי עבודה שרגישים לזמן תגובה ועומסי עבודה שלא רגישים לזמן תגובה, וליישם מדיניות של הפחתת עומס בזמן עומס תנועה כבד.
• שימוש בניתוב מודע-מודל: כדי לנתב בקשות על סמך שם המודל בגוף הבקשה, משתמשים בניתוב מבוסס-גוף. כשמשתמשים בניתוב שמבוסס על גוף הבקשה, חשוב לוודא שהשרתים העורפיים זמינים מאוד. אם התוסף לא זמין, השער יחזיר שגיאה כדי למנוע ניתוב שגוי של בקשות.
• התרת שער להפצת תנועה באופן אוטומטי: ‏GKE Inference Gateway מנתב תנועה בצורה חכמה על ידי מעקב אחרי מדדים מרכזיים משרתי ההסקה ב-InferencePool, כמו ניצול מטמון KV, אורך התור ומדדי מטמון של קידומות. האיזון הזה של עומס בזמן אמת משפר את ניצול המאיץ, מקצר את זמן הטעינה של הזנב ומגדיל את התפוקה הכוללת בהשוואה לשיטות מסורתיות.
• שילוב עם Apigee ו-Model Armor: כדי לשפר את האבטחה והניהול, אפשר לשלב עם Apigee לניהול ממשקי API ועם Model Armor לבדיקות בטיחות.

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

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

כדאי לפעול לפי השיטות המומלצות הבאות:

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

  • ‫GPUDirect-TCPX: יעיל למגוון עומסי עבודה של הסקת מסקנות מרובת צמתים שפועלים ב-A3 High.
  • GPUDirect-TCPXO: מציע ביצועים משופרים עם הפחתת עומס גדולה יותר ורוחב פס גבוה יותר, מה שמייצר יתרונות לאשכולות גדולים יותר בהשוואה ל-TCPX רגיל, ופועל במכונות A3 Mega.
  • ‫GPUDirect RDMA: מספק את רוחב הפס הגבוה ביותר בין צמתים ואת זמן האחזור הנמוך ביותר על ידי מתן גישה ישירה לזיכרון בין מעבדי GPU בצמתים שונים, תוך עקיפת המעבד. הוא מתאים במיוחד לתרחישי הסקה תובנות תובעניים ביותר בקנה מידה גדול במכונות A3 Ultra ו-A4.

  למידע נוסף:

  • מיקסום רוחב הפס של רשת ה-GPU באשכולות במצב רגיל.
  • הגדלת רוחב הפס של רשת ה-GPU באשכולות במצב אוטומטי.

  כדי לוודא שהגדרת הרשת מרובת הצמתים פועלת כמצופה, מומלץ להריץ בדיקות באמצעות כלים כמו NVIDIA Collective Communications Library (NCCL).

• שימוש ב-LeaderWorkerSet לניהול עומסי עבודה מבוזרים: כשפורסים עומס עבודה מבוזר עם שמירת מצב, כמו שירות הסקה מרובה צמתים, חשוב לנהל את כל הרכיבים שלו כיחידה אחת. כדי לעשות את זה, משתמשים ב-LeaderWorkerSet, שהוא API מקורי של Kubernetes שמאפשר לנהל קבוצה של קובצי Pod קשורים כישות אחת. ה-LeaderWorkerSet מוודא שכל ה-Pods בסט נוצרים ונמחקים יחד, וזה קריטי לשמירה על השלמות של עומס עבודה מבוזר.

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

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

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

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

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

סיכום השיטות המומלצות

בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במסמך הזה:

נושא	משימה
פריסה והגדרה	ניתוח המאפיינים של תרחיש השימוש בהסקת מסקנות בחירת המודלים המתאימים לתרחישי השימוש שלכם בהסקת מסקנות החלת קוונטיזציה על המודל בחירת המאיצים הנכונים בחירה של אסטרטגיית הפצה של מסקנות אופטימיזציה של ההגדרה של שרת ההסקה
זמן הטעינה של הפעלה מההתחלה (cold start)	אופטימיזציה של זמן ההפעלה של ה-Pod הפעלת צמתים עם הפעלה מהירה
תכנון קיבולת, גמישות, יעילות וזמינות	תכנון ושריין קיבולת שימוש בכלי לתזמון עומסי עבודה דינמיים שימוש ב-ComputeClasses הגדרת מדיניות המיקום של אשכולות GKE ומאגרי הצמתים
יעילות המשאבים והמאיצים	מעקב אחרי השרתים להסקת מסקנות והמאיצים שינוי אוטומטי של גודל ה-Pods העברת נתונים קרוב יותר לעומסי העבודה
איזון עומסים	שימוש ב-GKE Inference Gateway לפריסות באשכול יחיד
פריסות מרובות-צמתים	הגדלת רוחב הפס והתפוקה של רשת המאיצים שימוש ב-LeaderWorkerSet כדי לקבץ Pods מיקום צמתים במרחק פיזי קרוב באמצעות מיקום קומפקטי
פריסות במספר אזורים	הקצאת אשכולות GKE במספר אזורים איזון עומסים של תנועה בין אזורים אחסון משקלי מודלים בקטגוריות של Cloud Storage שמירת נתונים במטמון באמצעות Rapid Cache

המאמרים הבאים

• אפשר לעיין בארכיטקטורת העזר של GKE Inference.