פריסת LLM ב-Yandex Cloud עם GPU ו-vLLM

פריסת LLM: היכן התשתית נשברת תחת עומס

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

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

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

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

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

מה נותן מעגל הסקה ייעודי בסביבת עבודה

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

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

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

פריסת LLM במעגל סגור: אפשרויות מיקום

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

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

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

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

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

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

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

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

תיעוד, תרשימים ותקנונים בתוצרי הפרויקט

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

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

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

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

שיעור התגובות השגויות עמד על כ-10%, וחלקן יוחס לאיכות המודל, בעוד שבלוגים אלה היו חריגות זמן וניתוקי חיבור.

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

האוטוסקיילינג נקשר לאורך התור, ולא לעומס הממוצע של המאיץ: התור הוא הראשון שמראה שהמערכת יוצאת משליטה.

מדדים לפני ואחרי

• חציון זמן תגובה: מ-4 ל-1.2 שניות.
• p95: מ-12 ל-3.2 שניות.
• שיעור תגובות שגויות: מ-10% ל-3.5%.
• שיא תעבורה עד פי 2.5 מהרגיל: עובר ללא תור וללא כשלים.

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

במה שונה הסקת מודלים בענן ממעגל מקומי?

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

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

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

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

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

ספקות טכניים לפני תחילת העבודות

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

הנתונים לא יצאו מחוץ למעגל?

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

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

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

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

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

מה עם תמיכה לאחר המסירה?

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

מה לדון בפגישה הראשונה לגבי המעגל שלכם

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

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

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