פריסת LLM ב-Azure: OpenAI או Machine Learning Endpoints

פריסת LLM ב-Azure: צווארי בקבוק וסיכונים

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

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

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

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

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

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

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

זמן ההעלאה של המודל לפעולה מתקצר משבועות של תיאומים תשתיתיים לשעות. פריסה ב-Azure Machine Learning היא רישום גרסת המודל, בחירת סוג צומת חישוב, הגדרת נקודת קצה והרצת סט בדיקה; רשת, מאגר סודות, לוגים ומטריקות מגיעים יחד עם הסביבה.

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

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

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

מצבי פריסה: שירות מנוהל ונקודות קצה משלכם

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

מה משווים

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

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

סדר היישום: מביקורת עומס ועד מסירת הסביבה

פריסת LLM ב-Azure מתחילה בביקורת עומס, ולא ביצירת משאבים: אנו מודדים את אורך הקשר הקלט, שיעור התשובות בזרימה, פניות שיא בשנייה. הנתונים האלה קובעים את הבחירה בין Azure OpenAI ל-Azure Machine Learning Endpoints ואת המרווח במכסות. בהמשך העבודה מתנהלת בשלבים.

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

ארטיפקטים הנדסיים: תרשימים, מדיניות גישה, נהלים

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

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

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

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

מה היה לפני השינויים

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

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

מה שינו ומה התקבל

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

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

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

במה שונה שירות מנוהל מסביבה ייעודית?

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

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

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

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

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

ספקות טכניים ומגבלות הפלטפורמה

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

מה קורה בעדכון המודל?

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

עד כמה השירות זמין ומה עם המגבלות?

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

איך מפרידים גישה למודל?

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

האם באמת אפשר להחליף פלטפורמה אחר כך?

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

נדון במשימה: מה דרוש להערכה ותוכנית עבודה

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

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

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