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

טייס אוטומטי רגילה

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

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

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

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

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

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

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

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

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

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

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

• התאמה בין משימות לבין אופני פעולה: הערכת מודלים על סמך המשימות שהוקצו להם ואופני הפעולה הנתמכים. מודל שעבר אופטימיזציה למשימה ספציפית כמעט תמיד יניב ביצועים טובים יותר ממודל לשימוש כללי.
• מאפיינים טכניים: הארכיטקטורה של מודל ודיוק סוג הנתונים שלו – כמו FP16,‏ FP8 ו-FP4 – הם גורמים מרכזיים בקביעת דרישות המשאבים והביצועים שלו. ההערכה הזו עוזרת לכם להחליט אם צריך להשתמש בטכניקות קוונטיזציה. בודקים את הדיוק הנתמך של משקלי המודל, מוודאים שיש תמיכה במסגרת ומוודאים שאורך חלון ההקשר המקסימלי של המודל נתמך.
• ביצועים ויעילות מבחינת עלות: כדי לקבל החלטה שמבוססת על נתונים, כדאי להשוות בין המודלים שנבחרו באמצעות מדדי השוואה שזמינים לציבור ובאמצעות בדיקות פנימיות משלכם. אפשר להשתמש בטבלאות השוואה כמו 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.

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

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

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

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

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.
   • ‫Activation: הזיכרון שנדרש להפעלות ביניים במהלך ההרצה של מודל.
   • מטמון 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.

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

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

   תרחיש לדוגמה	מאיצים מומלצים	Machine Series	מאפיינים מרכזיים
   הסקת מסקנות במודל קטן	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	אידיאלי לעומסי עבודה של הסקת מסקנות שמתאימים לצומת יחיד (עד 640GB של זיכרון כולל).
   	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	-	אופטימיזציה להצגת מודלים של Transformer, מודלים של יצירת תמונות לפי טקסט ומודלים של 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

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

   יחידות 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 ביט), טעינת המשקלים של המודל לזיכרון המאיץ דורשת כ-113 GB. מעבד GPU יחיד של NVIDIA H100 מספק זיכרון בנפח 80 GB. לכן, גם בלי להתחשב בדרישות זיכרון אחרות כמו מטמון KV, צריך לפחות שני מעבדי NVIDIA H100 GPU כדי לטעון את המודל, באמצעות גודל מקביליות טנסור של שניים.

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

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

     במודל גדול מאוד עם יותר מ-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. כדי לקבל הגדרת בסיס אופטימלית של Kubernetes לתרחיש השימוש שלכם, כדאי להתחיל עם מדריך ההתחלה המהירה בנושא הסקת מסקנות ב-GKE.
2. מריצים בדיקות השוואה כדי לתעד את מדדי התפוקה וזמן האחזור של קו הבסיס.
3. כדאי לשנות את ההגדרות של שרת ההסקה.
4. מריצים שוב את ההשוואה לשוק ומשווים את התוצאות כדי לאמת את השינויים.

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

• הגדרת מקביליות:
  • ‫Tensor Parallelism (tensor_parallel_size): מגדירים את הערך הזה למספר המאיצים בצומת יחיד כדי לפצל את עומס העבודה. לדוגמה, הגדרה של tensor_parallel_size=4 תחלק את עומס העבודה בין ארבעה מאיצים. חשוב לדעת: הגדלת הערך הזה עלולה להוביל לתקורה מוגזמת של סנכרון.
  • מקביליות של צינור עיבוד נתונים (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.
• לקבלת הנחיות נוספות בנושא אופטימיזציה של זיכרון המודל, אפשר לעיין במאמר שיטות מומלצות לאופטימיזציה של הסקת מודלים גדולים של שפה (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 או Dynamic Workload Scheduler (DWS). אפשר להפוך את אסטרטגיית הגיבוי הזו לאוטומטית באמצעות ComputeClasses מותאמים אישית כדי להגדיר סדר עדיפויות לאספקת סוגים שונים של קיבולת.

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

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

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

כשמשתמשים ב-DWS עם מצב הקצאת הרשאות של flex-start, מומלץ:

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

שימוש ב-ComputeClasses

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • ניצול מטמון של זוגות מפתח/ערך (לדוגמה, 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 מקומי: לעומסי עבודה (workloads) שדורשים גישה עם זמן אחזור נמוך במיוחד לנתונים זמניים, אפשר להשתמש ב-SSD מקומי כמטמון עם ביצועים גבוהים. שימוש בכונני SSD מקומיים כאמצעי אחסון זמני עם זמן אחזור נמוך לאחסון נתונים שנמצאים בשימוש תדיר עוזר לצמצם את זמן ההמתנה של משאבים יקרים, כמו מאיצים, על ידי קיצור משמעותי של הזמן שבו המאיצים ממתינים לסיום פעולות קלט/פלט. שימו לב שלא כל סדרות המכונות תומכות בכונני SSD מקומיים, מה שיכול להשפיע על הבחירה שלכם במאיצים.
• ניהול מטמונים באמצעות GKE Data Cache: כדי שעומסי עבודה יקראו נתונים מדיסקים מתמידים בתדירות גבוהה, מומלץ להפעיל את GKE Data Cache. מטמון הנתונים של GKE משתמש בכונני SSD מקומיים כדי ליצור מטמון מנוהל עם ביצועים גבוהים עבור כוננים קשיחים קבועים. לרוב עומסי העבודה בסביבת הייצור, מומלץ להשתמש במצב Writethrough כדי למנוע אובדן נתונים על ידי כתיבת נתונים באופן סינכרוני גם למטמון וגם לדיסק הבסיסי הקבוע.

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

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

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

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

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

• קיבוץ של Pods להצגת מודעות ל-InferencePool: מגדירים InferencePool לכל קבוצה של Pods שמציגים את עומסי העבודה של ההסקות. מידע נוסף זמין במאמר בנושא התאמה אישית של ההגדרה של GKE Inference Gateway.
• ריבוב עומסי עבודה שרגישים לזמן האחזור: מגדירים את InferenceObjectives כדי לציין את מאפייני ההצגה של המודל, כמו השם והעדיפות שלו. ב-GKE Inference Gateway, עומסי עבודה עם עדיפות גבוהה מקבלים עדיפות, כך שאפשר לבצע מולטיפלקס של עומסי עבודה שרגישים לזמן האחזור ועומסי עבודה שלא רגישים לזמן האחזור, וליישם מדיניות של הפחתת עומס בזמן עומס תנועה כבד.
• שימוש בניתוב מודע למודל: כדי לנתב בקשות על סמך שם המודל בגוף הבקשה, משתמשים בניתוב מבוסס-גוף. כשמשתמשים בניתוב שמבוסס על גוף הבקשה, חשוב לוודא שהשרתים העורפיים זמינים מאוד. אם התוסף לא זמין, השער יחזיר שגיאה כדי למנוע ניתוב שגוי של הבקשות.
• מתן הרשאה ל-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 באשכולות במצב Autopilot.

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

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

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

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

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

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

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

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

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

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

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

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