אופטימיזציה של עלות הסקת AI: אסטרטגיות וכלים

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

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

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

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

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

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

מה משתנה בעבודת האינפרנס לאחר הכיוונון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ערכת אספקה: קונפיגורציות, סכמות, תיעוד

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

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

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

מקרה בוחן: צמצום בזבוז משאבי מחשוב

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

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

האינפרנס הועבר ל-NVIDIA Triton: הפעלנו באצ'ינג דינמי עם חלון המתנה, הוצאנו את מטמון ה-KV לשכבה משותפת, הוספנו כימות משקלים 8-ביט והפרדנו בין מאגר אינטראקטיבי למאגר באצ'ים — יש להם מטרות שונות בהשהיה, והם כבר לא התחרו על אותם מאיצים. סקיילינג אוטומטי הועבר מעומס המעבד לעומ�ק התור.

מטריקות לפני ואחרי על אותו פרופיל תעבורה:

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

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

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

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

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

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

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

ספקות ומגבלות: עונים על שאלות נפוצות

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

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

האם המטמון ישתלם בתעבורה שלנו?

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

איך למצוא את צוואר הבקבוק האמיתי?

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

מה יקרה אם הסכמה תסתבך?

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

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

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

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

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