פריסת LLM ב-AWS: SageMaker, Bedrock, EC2

פריסת LLM ב-AWS: היכן נשבר הפרודקשן

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

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

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

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

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

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

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

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

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

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

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

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

אירוח LLM ב-AWS: אפשרויות ומגבלות

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

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

איך מתבצעת ההטמעה: מביקורת עומס ועד מסירה

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

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

מה מועבר ללקוח: תרשימים, מדיניות, נהלים

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

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

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

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

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

מה נבנה מחדש

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

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

מה השתנה בנתונים

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

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

במה שירות מנוהל שונה מאינסטנסים משלכם?

השאלה היא לא מי מקים מודל מהר יותר, אלא מי אחראי לשכבה שמתחתיו. ב-AWS זה בחירה בין Bedrock, SageMaker לבין סביבה עצמאית על EC2. שירות מנוהל — אחריות שכורה על סביבת ההרצה ועמידות בתקלות; אינסטנסים משלכם — שליטה מלאה עם סט מלא של חובות.

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

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

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

ספקות טכניים נפוצים לפני ההרצה

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

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

מה עושים עם סביבה שכבר פרוסה — לכתוב הכול מחדש?

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

מי אחראי לגרסאות המודל ולעדכונים שלהן?

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

איך מוגבלת הגישה לנתונים?

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

איך מעבירים פתרון קיים בלי השבתה?

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

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

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

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

אחרי דיון במשימה נשלח:

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

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