אופטימיזציה של הסקת LLM באמצעות TensorRT-LLM

TensorRT-LLM: היכן נתקע האינפרנס של LLM

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

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

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

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

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

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

האפקט של האופטימיזציה: השהיה, תפוקה, כשלים

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

השהיית תגובה

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

תפוקה

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

כשלים תחת עומס שיא

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

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

מצבי האצה: קוונטיזציה, קיבוץ בקשות, מטמון

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

מה בודקים לפני ההפעלה

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

TensorRT-LLM מספק את כל המצבים האלה, אבל השילוב שלהם עבור פרופיל עומס מסוים נבחר לפי מדידות, ולא לפי preset ברירת מחדל.

הטמעת TensorRT-LLM: שלבי עבודה הנדסית

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

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

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

מה מוסרים: בילדים, סכמות, מדיניות, נוהלים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ספקות: דיוק, הידרדרות, תאימות מודלים

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

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

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

האם המודל שלנו יעבוד — מותאם אישית או לא סטנדרטי?

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

האם נצטרך לבנות הכול מחדש בכל עדכון מודל?

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

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

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

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