פריסת LLM ב-Google Cloud Vertex AI

פריסת LLM Vertex AI: מה נשבר בפרודקשן

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

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

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

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

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

מה נותנת פריסה מנוהלת של המודל

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

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

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

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

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

אפשרויות פריסה של LLM: השוואת מצבים

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

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

סדר ההטמעה: מהאודיט ועד המסירה

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

1. אודיט של התשתית. מפרקים את מה שכבר קיים: פרויקטים, רשתות, הרשאות, כמויות ואיכות הנתונים לאימון ולכיול. בנפרד קובעים את דרישות העומס — כמה בקשות במקביל מחזיק השירות ואיזו שהות תגובה מקובלת. בפלט — מפת מגבלות וסיכונים עם סדרי עדיפויות.
2. תרשים הפריסה. מחליטים מה מוסרים לשירות מנוהל ומה מרימים על התשתית שלנו: מודלים עם נתונים רגישים דורשים בדרך כלל את האפשרות השנייה. התרשים מציג נקודות כשל, גבולות רשתות וסדר הוצאת גרסאות חדשות.
3. קונפיגורציה של הסביבה. סביבות נפרדות לפיתוח ולפרודקשן, חשבונות שירות עם ההרשאות המינימליות הנדרשות, גישה רשתית פרטית ללא כתובות פומביות, סודות — במאגר מאובטח. כל התיאור נשמר כקוד, ולכן הסביבה משוחזרת ולא נבנית ביד.
4. בנייה וחיבור של המודל. מכינים image עם המשקולות והתלויות, מגדירים סקיילינג אוטומטי לשיאים, הגבלת בקשות במקביל ותיעוד לוגים ללא נתונים אישיים. גרסה חדשה מוציאים תחילה לחלק קטן מהתעבורה.
5. בדיקת קבלה. מריצים פרופיל של בקשות אמיתיות: מודדים את זמן התגובה בקלטים ארוכים, בוחנים את ההתנהגות בכשל צומת ובמיצוי מכסה, בודקים את החזרה לגרסה הקודמת — היא צריכה לארוך דקות, לא שעות.
6. מסירה והכשרת הצוות. מוסרים גישות, תרשימים, את נוהל העדכונים ואת ניתוח האירועים הטיפוסיים, ומכשירים את המהנדסים שלכם. בשבועות הראשונים של פעילות השירות אנחנו הולכים לצדכם ומתקנים הגדרות לפי מדדים בפועל, ולא לפי הנחות.

מה נשאר אצלכם: קונפיגורציות ונוהלים

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

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

מקרה בוחן: הסרנו את ההידרדרות בתשובות בעומס שיא

עומס שיא הוא המצב היחיד שבאמת חשוב בפרודקשן. בשירות לפניות לתמיכה, הג'נרציה על Google Cloud Vertex AI החזיקה מעמד עד לזרימה מסוימת, ומעבר לכך החלה ההידרדרות: התשובה התארכה, חלק מהבקשות נקטעו בגלל זמן ההמתנה, התור הצטבר והאיץ את זמן התגובה עוד יותר. עסקנו לא במודל, אלא באופן שבו הוא נפרס.

מה שינינו

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

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

במה נבדלת פלטפורמה מנוהלת מסביבה עצמאית?

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

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

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

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

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

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

ספקות טכניים: עונים לפי נקודות

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

כיצד מתעדכן המודל בלי השבתה?

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

כמה יהיה צורך לשכתב ביישום הקיים?

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

מי יקבל גישה ללוגים וכיצד היא מופרדת?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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