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

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

המסמך הזה מיועד לאדמינים של נתונים, למפעילים ולמפתחים שרוצים להשתמש בשיטות מומלצות לעומסי עבודה של הסקה באמצעות מאיצים, כמו GPU ו-TPU, עם Kubernetes ו-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 צריך המודל שלי? קובץ notebook של 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 אידיאלי לעומסי עבודה של הסקת מסקנות שמתאימים לצומת יחיד (עד 640 GB זיכרון כולל).
    NVIDIA B200 A4 אפשרות עתידית למודלים תובעניים שמתאימים לצומת יחיד (עד 1,440 GB זיכרון כולל).
    TPU גרסה 4 - האפשרות הזו מציעה איזון טוב בין עלות לביצועים.
    TPU v5p - אפשרות עם ביצועים גבוהים לעומסי עבודה תובעניים.
    הסקת מסקנות במודל גדול עם כמה מארחים NVIDIA H200 A3 Ultra מתאים למודלים גדולים שדורשים הרבה זיכרון (עד 1,128 GB זיכרון כולל).
    NVIDIA B200 / GB200 A4 / A4X לעומסי עבודה (workloads) הכי תובעניים, אינטנסיביים מבחינת מחשוב ומוגבלים מבחינת רשת. מכונות A4X משתמשות במעבדי CPU מבוססי-Arm, ולכן יכול להיות שיהיה צורך בארגון הקוד מחדש (Refactoring) של עומס העבודה (שינויים בקוד מעבר לבנייה מחדש פשוטה של קונטיינר) אם עומס העבודה משתמש בתכונות או באופטימיזציות ספציפיות ל-x86.
    TPU v5e - אופטימיזציה של העלות והביצועים להצגת מודלים גדולים של שפה (LLM) בגודל בינוני עד גדול.
    TPU v5p - אפשרות לביצועים גבוהים להסקת מסקנות בכמה מארחים, שדורשת מקביליות בקנה מידה גדול.
    TPU v6e - אופטימיזציה להצגת תוצאות של מודלים מסוג Transformer, מודלים ליצירת תמונות לפי טקסט ומודלים של רשתות עצביות קונבולוציוניות (CNN).

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

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

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

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

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

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

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

    הנחיות נוספות לבחירת אסטרטגיית היקש מבוזרת עבור רפליקה של מודל יחיד זמינות במאמר 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 Parallelism (pipeline_parallel_size): מגדירים את הערך הזה למספר הצמתים שביניהם מחלקים את המודל. לדוגמה, אם אתם פורסים בשני צמתים עם שמונה מאיצים בכל אחד, תגדירו את tensor_parallel_size=8 ואת pipeline_parallel_size=2. הגדלת הערך הזה עלולה להוביל לעיכובים.
  • התאמת המטמון של זוגות מפתח/ערך (gpu_memory_utilization): הפרמטר הזה קובע את אחוז זיכרון ה-GPU ששמור למשקלים, להפעלות ולמטמון של זוגות מפתח/ערך של המודל. ערך גבוה יותר מגדיל את גודל מטמון KV ויכול לשפר את התפוקה. מומלץ להגדיר ערך בין 0.9 ל-0.95. אם נתקלים בשגיאות שקשורות לחוסר זיכרון (OOM), כדאי להקטין את הערך הזה.
  • הגדרת אורך מקסימלי של הקשר (max_model_len): כדי להקטין את גודל המטמון של זוגות מפתח/ערך ואת דרישות הזיכרון, אפשר להגדיר אורך מקסימלי של הקשר שהוא קצר יותר מברירת המחדל של המודל. כך תוכלו להשתמש במעבדי 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 מייצאת.

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

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

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

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

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

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

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

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

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

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

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

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

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

תכנון הקיבולת ומקסום הזמינות של המאיצים

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

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

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

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

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

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

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

אם עומסי העבודה שלכם יכולים לסבול עיכובים בהקצאת הקיבולת, כדאי להשתמש ב-Dynamic Workload Scheduler עם מצב הקצאה של התחלה גמישה

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

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

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

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

Custom Compute Classes (CCCs) הם תכונה של 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 עבור מעבדים גרפיים של NVIDIA: כדי לעקוב אחרי תקינות וביצועים של מעבדים גרפיים של NVIDIA, צריך להגדיר את GKE כך שישלח מדדים של NVIDIA Data Center GPU Manager‏ (DCGM) אל Cloud Monitoring.
  • הפעלת מעקב אוטומטי אחרי אפליקציות: כדי לפשט את תהליך המעקב אחרי שרתי ההסקה, מפעילים מעקב אוטומטי אחרי אפליקציות ב-GKE.
  • הוספת כלי מדידה לעומסי העבודה באמצעות OpenTelemetry: לעומסי עבודה שלא נתמכים על ידי מעקב אוטומטי אחרי אפליקציות, אפשר להשתמש ב-OpenTelemetry כדי לאסוף מדדים ועקבות בהתאמה אישית.

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

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

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

  • הגדרת 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.

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

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

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

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

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

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

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

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

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

    למידע נוסף:

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

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

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

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

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

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

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

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

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

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

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