סקירה כללית של שיטות מומלצות להסקת מסקנות ב-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.
   • ‫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 שעבר כוונון להוראות:
     • ‫5376: hidden_size
     • 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 לתקורה).

   על סמך דרישות הזיכרון בלבד, אפשר להחריג GPUs מסוג 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 עם כמה מופעים. בעזרת ההגדרה הזו, אתם מחלקים מעבד גרפי נתמך כדי לשתף מעבד גרפי יחיד בין כמה קונטיינרים ב-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, צריך לפחות שני כרטיסי 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. כדי לקבל הגדרת בסיס אופטימלית של 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. הגדלת הערך הזה עלולה להוביל לעיכובים.
• התאמת המטמון של זוגות מפתח/ערך (gpu_memory_utilization): הפרמטר הזה קובע את אחוז זיכרון ה-GPU ששמור למשקלים, להפעלות ולמטמון של זוגות מפתח/ערך של המודל. ערך גבוה יותר מגדיל את גודל מטמון 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 משתנה ל-Ready תלוי בעיקר בזמן שנדרש למשיכת קובץ אימג' של קונטיינר ולהורדת משקלי המודל. כדי לבצע אופטימיזציה לשניהם, כדאי לנסות את השיטות הבאות:

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

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

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

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

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

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

שימוש במחלקות מחשוב בהתאמה אישית

מחלוקות מחשוב בהתאמה אישית (CCC) הן תכונה של GKE שמאפשרת לכם להגדיר רשימה עם עדיפות של הגדרות תשתית לעומסי העבודה. התכונות העיקריות של CCC נועדו לשפר את היכולת להשיג תוכניות האצה:

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

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

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

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

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

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

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

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

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

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

• ‫location-policy=ANY: מתן עדיפות להשגת קיבולת על פני איזון הצמתים באופן שווה בין האזורים. ההגדרה הזו רלוונטית במיוחד אם ה-CCC כולל מכונות וירטואליות זמניות או סוגי מכונות עם זמינות משתנה, כי ANY מאפשרת ל-Cluster Autoscaler לבחור את האזור עם הסיכוי הכי גבוה למילוי סוגי הצמתים שקיבלו עדיפות ב-CCC. אפשר להשתמש בהגדרה הזו גם כדי לתת עדיפות לשימוש בהזמנות שלא נעשה בהן שימוש. כשמשתמשים במדיניות הזו, מומלץ להתחיל עם 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 מקומי: לעומסי עבודה שדורשים גישה עם זמן אחזור נמוך במיוחד לנתונים זמניים, אפשר להשתמש ב-SSD מקומי כמטמון עם ביצועים גבוהים. שימוש בכונני SSD מקומיים כאמצעי אחסון זמני עם זמן אחזור נמוך לאחסון נתונים שנמצאים בשימוש תדיר עוזר לצמצם את זמן ההמתנה של משאבים יקרים, כמו מאיצים, על ידי קיצור משמעותי של הזמן שבו המאיצים ממתינים לסיום פעולות קלט/פלט. שימו לב שלא כל סדרות המכונות תומכות בכונני SSD מקומיים, מה שיכול להשפיע על הבחירה שלכם במאיצים.
• ניהול מטמונים באמצעות GKE Data Cache: כדי שעומסי עבודה יקראו נתונים לעיתים קרובות מ-Persistent Disks, צריך להפעיל את 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 מנתב את תעבורת הנתונים בצורה חכמה על ידי מעקב אחרי מדדים מרכזיים משרתי ההסקה ב-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 הפעלת צמתים עם הפעלה מהירה
תכנון קיבולת וזמינות של מאיצים	תכנון ושריין קיבולת שימוש בכלי לתזמון עומסי עבודה דינמיים שימוש במחלקות מחשוב בהתאמה אישית הגדרת מדיניות המיקום של אשכולות GKE ומאגרי הצמתים
יעילות המשאבים והמאיצים	מעקב אחרי מאיצים ושרתי הסקה שינוי אוטומטי של גודל ה-Pods העברת נתונים קרוב יותר לעומסי העבודה
איזון עומסים	שימוש ב-GKE Inference Gateway לפריסות באשכול יחיד
פריסות מרובות-צמתים	הגדלת רוחב הפס והתפוקה של רשת המאיצים שימוש ב-LeaderWorkerSet לקיבוץ של Pods מיקום צמתים בקרבה פיזית באמצעות מיקום קומפקטי
פריסות במספר אזורים	הקצאת אשכולות GKE במספר אזורים איזון עומסים של תנועה בין אזורים אחסון משקלי המודל בקטגוריות של Cloud Storage שמירת נתונים במטמון באמצעות Rapid Cache

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

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