הסקת LLM עם TGI: מפחיתים השהיה וחוסכים VRAM

מדוע אינפרנס TGI נתקל בעיכובים ובזיכרון וידאו

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

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

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

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

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

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

מה נותן צינור שירות מנוהל למודלי שפה

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

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

ב-Hugging Face TGI אלו מצבים מובנים — המהנדסים שלנו מכווננים אותם לפרופיל העומס, ולא משאירים ערכי ברירת מחדל.

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

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

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

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

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

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

השוואת אפשרויות

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

כיצד אנו פורסים אינפרנס TGI: שלבי העבודה

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

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

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

ארטיפקטים של ההטמעה: תצורות, תרשימים ונוהלים

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

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

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

מקרה בוחן: האיצנו את התגובה והפחתנו את צריכת זיכרון הווידאו

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

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

מה שינינו

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

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

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

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

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

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

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

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

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

ספקות טכניים: עונים על שאלות נפוצות

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

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

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

אצלנו כבר פועל מודל אחר — המעבר יהיה כואב?

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

מי אחראי לתפעול לאחר ההטמעה?

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

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

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

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

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

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