המודל נחנק? כך תרוויחו בחזרה 76% מהזיכרון

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

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

מאת יובל לוריא

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

ואז הגעתם לפרודקשן. חיברתם את המודל ל-30 או 50 משתמשים במקביל בארגון, או שהזרקתם לו מסמכי RAG ארוכים – ופתאום הכל נשבר: זמני התגובה מזנקים, המשתמשים מחכים שניות ארוכות רק כדי לראות את המילה הראשונה נכתבת (Time To First Token), והקלאסטר זורק שגיאות CUDA Out of Memory סדרתיות.

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

האינסטינקט הראשוני של רוב הצוותים הוא לרוץ להנהלה ולבקש תקציב לכרטיסי מסך נוספים. אבל האמת היא שלא חסר כוח חישוב – המודל נחנק בגלל משהו אחר לגמרי שמתרחש מתחת למכסה המנוע: ניהול לא יעיל של ה-KV Cache.

מה זה בכלל KV Cache?

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

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

כדי למנוע את החישוב החוזר הזה, מנועי אינפרנס שומרים בזיכרון המהיר של ה-GPU (ה-HBM) את טבלאות ה-Key וה-Value של כל הטוקנים הקודמים. זהו ה-KV Cache.

על פניו הרעיון מעולה – אנחנו מחליפים כוח חישוב (FLOPs) בצריכת זיכרון. אבל יש כאן מלכוד 22 אכזרי: משקלי המודל עצמם תופסים נפח קבוע וידוע מראש בזיכרון, בעוד שה-KV Cache גדל ומתנפח דינמית עם כל מילה שנוצרת ועם כל משתמש שמצטרף למערכת.

במודלים פופולריים כמו Llama 3 או Qwen, תחת חלון קונטקסט של 32,000 טוקנים, שאילתה פעילה בודדת עשויה לדרוש עשרות גיגה-בייט של זיכרון אך ורק עבור ה-KV Cache שלה. כשמכפילים את זה בכמה עשרות משתמשים במקביל, כרטיס המסך פשוט קורס עוד לפני שהמאווררים שלו בכלל התחילו להסתובב ברצינות.

איפה הזיכרון שלכם באמת נשרף?

אם תסתכלו על שרתי אינפרנס מסורתיים (כמו שרתי PyTorch רגילים או ספריות מוקדמות), תגלו בעיה מבנית עמוקה שנקראת פרגמנטציה של זיכרון. כשמשתמש שולח שאילתה למערכת, שרת האינפרנס אינו יודע מראש כמה מילים המשתמש יקליד וכמה מילים המודל יענה לו. לכן, הגישה הנאיבית הייתה לשריין לכל משתמש מראש בלוק זיכרון רציף וענק ב-GPU, לפי חלון ההקשר המקסימלי האפשרי (לדוגמה 4,096 או 8,192 טוקנים).

אך בפועל, רוב השאילתות של המשתמשים קצרות בהרבה. יש לכך שתי תוצאות:

1. זיכרון שנעול לחינם: שריינתם מקום ל-4,000 טוקנים, המשתמש קיבל תשובה של 100 טוקנים – ו-3,900 מקומות עומדים ריקים ואסורים לשימוש עד שהחיבור יסתיים.
2. חורים בין ההקצאות: כשאנשים מתחברים ומתנתקים, הזיכרון של ה-GPU נשבר לעשרות חתיכות קטנות. כעת, כשמגיע משתמש חדש, השרת לא מוצא רצף זיכרון אחד גדול מספיק – והבקשה נתקעת בתור או קורסת, למרות שבפועל יש עשרות גיגה-בייטים פנויים של זיכרון.

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

הגיים צ'יינג'ר: לנהל את ה-GPU כמו מערכת הפעלה

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

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

זה בדיוק מה שעושה אלגוריתם PagedAttention:

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

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

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

איך לשבור את מחסום ה-RAG?

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

במערכות RAG ארגוניות, כל שאילתה מתחילה בהזרקה של מסמכים ארוכים (חוזי עבודה, תקנונים בנקאיים, קבצי לוגים). שלב קריאת המסמך נקרא Prefill – זהו שלב שדורש כוח חישוב כבד מאוד של ה-GPU ומייצר את ה-KV Cache הראשוני של המסמך.

הבעיה היא שבמערכות ענן רגילות, ה-KV Cache חי רק בתוך הפוד הבודד שמשרת את הבקשה. כך, ברגע שהפוד עושה ריסטארט או שסביבת הקוברנטיס מבצעת Scale-down – כל ה-KV Cache נמחק. בנוסף, אם משתמש א' שלח שאלה על מסמך וקיבל תשובה מפוד 1, ומשתמש ב' שאל שאלה על אותו מסמך בדיוק ונותב לפוד 2 – פוד 2 יבצע שוב את כל פעולת ה-Prefill היקרה מההתחלה. התוצאה היא שהמשתמש מחכה 10 שניות לתשובה ראשונה, וה-GPU טוחן חישובים זהים שוב ושוב.

כאן נכנסת לתמונה ארכיטקטורת LMCache – קוד פתוח המשתלב עם מנועים כמו vLLM: במקום להתייחס ל-KV Cache כמצב זיכרון זמני שמתנדף, שומרים בלוקים של טוקנים בשכבות אחסון היררכיות ב-RAM של ה-CPU, בכונני NVMe מהירים, או ב-Redis/Object Storage משותף.

כאשר משתמש חדש ניגש למסמך שכבר נותח בעבר במערכת, המנוע מדלג לחלוטין על שלב ה-Prefill, מושך את ה-KV Cache המוכן ישירות ל-GPU ומתחיל לפלוט תשובה מיד.

בנצ'מרקים בעולם האמיתי מראים ירידה של עד פי 8 בזמן התגובה הראשוני ושיפור של פי 2-14 בתפוקת הקלאסטר כולו.

אוקיי, ומה עושים מחר בבוקר בקלאסטר?

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

1. עברו ממערכות הרצה גנריות למנועי אינפרנס ייעודיים: אם אתם עדיין מריצים מודלים דרך שרתי Flask פשוטים או wrappers בסיסיים של Transformers, עברו למנועים מבוססי PagedAttention כמו vLLM או SGLang. המעבר הזה לבדו ישחרר לכם עשרות אחוזי זיכרון.
2. הסתכלו על המדדים הנכונים – TTFT מול ITL: הפסיקו למדוד רק Latency כללי. פצלו את המדידה לזמן עד לטוקן הראשון (TTFT – שמצביע על צווארי בקבוק ב-Prefill ובקונטקסט ארוך) מול הזמן בין טוקן לטוקן (ITL – שמצביע על רוחב פס של זיכרון ה-GPU).
3. הפעילו Prefix Caching מובנה: במנועי אינפרנס מודרניים קיימת הגדרה פשוטה (כמו –enable-prefix-caching ב-vLLM). הפעלתה תאפשר למנוע לזהות פרומפטים מערכתיים קבועים ולעשות שימוש חוזר ב-KV Cache שלהם בין משתמשים שונים.
4. תכננו קיבולת על בסיס דאטה ולא ניחושים: בעבודה שלנו ברד האט על פרויקטים כמו llm-d-planner, ראינו שכאשר ממפים במדויק את יחס ה-Input/Output של המשתמשים ואת ה-Concurrency הצפוי, ניתן לבחור חומרה מדויקת (לדוגמה, כרטיסי L4 או A10G במקום לקפוץ אוטומטית ל-H100) ולחסוך עד 60% מעלויות הענן.

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

הכותב הוא SMLE ב-Red Hat ומוביל בתחום AI & MLOps. בנוסף, לוקח חלק פעיל בתרומה לקוד הפתוח של קהילת vLLM שעוסקת בניהול ואפטום המתמקדת באופטימיזציה, דטרמיניזם וניהול זיכרון עבור מנועי LLM Serving בקנה מידה רחב