האצת LLM: הגדרת מטמון KV ומטמון סמנטי

מטמון אינפרנס LLM: היכן אובדת המהירות

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

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

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

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

מה נותן שימוש חוזר בתשובות ובהקשר

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

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

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

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

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

מצבי מטמון: מדויק, סמנטי, הקשרי

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

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

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

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

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

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

מה נשאר אצלכם: תצורות, תרשים, נהלים

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

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

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

מקרה בוחן: זמן תגובה ושיעור פגיעות לפני ואחרי

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

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

מה שינינו

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

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

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

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

במה שונה שימוש חוזר בהקשר מחזרה על תשובות?

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

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

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

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

מגבלות וטעויות נפוצות בכיול

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

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

היכן הגבול של התאמות שווא בחיפוש סמנטי?

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

מה בדיוק לא כדאי לשמור במטמון?

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

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

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

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

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