מטמון KV (KV Cache)

מודלים ושפה

הגדרה

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

מה נשמר, ולמה אפשר לשמור אותו

מודל-שפה מייצר תשובה טוקן אחר טוקן, וכל טוקן חדש נקבע בעזרת מנגנון הקשב (Attention), שמקשר אותו לכל הטוקנים שקדמו לו. לשם כך המודל מחשב לכל טוקן, בכל אחת משכבותיו, שלושה וקטורים: שאילתה (Query), מפתח (Key) וערך (Value). במודלים שמייצרים טקסט, טוקן אינו "רואה" את מה שבא אחריו, ולכן — כפי שמסביר תיעוד ספריית Transformers של Hugging Face — ברגע שטוקן עובד, המפתח והערך שלו כבר לא משתנים בהמשך. אפשר אפוא לשמור אותם בצד ולהשתמש בהם שוב: בכל צעד מחשבים מפתח וערך רק לטוקן האחרון, מוסיפים אותם למאגר, ומחשבים את הקשב מול כל מה שכבר שמור. המאגר הזה נקרא מטמון KV, על שם Key ו-Value, והוא נשמר בנפרד לכל שכבה של המודל. לפי אותו תיעוד, המטמון מיועד לשלב ההסקה בלבד, ולא לשלב האימון.

דוגמה פשוטה: חישוב מול זיכרון

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

למה הקשר ארוך מייקר זיכרון

מכיוון שהמטמון שומר נתונים לכל טוקן בכל שכבה, גודלו גדל עם אורך הרצף — השאלה, המסמכים שצורפו אליה והתשובה שנכתבת. מפתחי vLLM מאוניברסיטת ברקלי כתבו ב-2023 שהמטמון של רצף בודד במודל LLaMA-13B יכול להגיע ל-1.7GB, ושגודלו תלוי באורך הרצף, שקשה לחזות מראש. בהקשרים ארוכים במיוחד המספרים גדלים עוד: במאמר של AI21 Labs על מודל Jamba מ-2024 מופיעה טבלה שלפיה בהקשר של 256 אלף טוקנים, בדיוק של 16 ביט, המטמון של LLaMA-2 בגודל 6.7 מיליארד פרמטרים מגיע ל-128GB. לכן חלון-הקשר ארוך הוא לא רק שאלה של יכולת המודל, אלא גם של חומרה ועלות. לפי מאמר vLLM, כדי להפעיל שרת ביעילות צריך לאגד בקשות רבות יחד, והמטמון הגדול של כל בקשה מגביל את מספר הבקשות שנכנסות במקביל.

השפעה על מהירות ועל תפוקה

המטמון חוסך חישוב, אבל גם קריאתו אינה חינם. כבר ב-2019 כתב נועם שזיר (Noam Shazeer) שיצירת טקסט צעד אחר צעד איטית לעיתים קרובות בגלל עלות רוחב-הפס של טעינה חוזרת של טנזורי המפתחות והערכים הגדולים מהזיכרון. בשרתים יש בעיה נוספת, של ניהול הזיכרון: צוות vLLM מצא ב-2023 שמערכות קיימות בזבזו 60% עד 80% מהזיכרון בגלל פיצול והקצאת-יתר, והציע את PagedAttention — שיטה בהשראת הזיכרון הווירטואלי במערכות-הפעלה, שמחלקת את המטמון של כל רצף לבלוקים קטנים שאינם חייבים לשבת ברצף אחד בזיכרון. לפי הצוות, הבזבוז ירד אל מתחת ל-4%, ובמאמר דווח על שיפור של פי 2 עד 4 בתפוקה באותה רמת השהיה, לעומת FasterTransformer ו-Orca. אלה מדידות של מפתחי השיטה עצמם. השיטה גם מאפשרת לכמה פלטים שנוצרים מאותה בקשה לחלוק את המטמון של הבקשה המשותפת במקום לשכפל אותו.

איך מקטינים את המטמון

חלק גדול מהמחקר על יעילות מודלי-שפה עוסק בהקטנת המטמון. במאמר מ-2019 הציע שזיר קשב רב-שאילתות (Multi-Query Attention), שבו כל "ראשי" הקשב חולקים סט אחד של מפתחות וערכים, במחיר ירידה קלה באיכות. ב-2023 הוצעה GQA (Grouped-Query Attention), דרך-ביניים שבה קבוצות של ראשים חולקות מפתחות וערכים; לפי המאמר, היא מגיעה לאיכות קרובה לזו של קשב רגיל במהירות דומה לזו של השיטה של שזיר. דרך אחרת היא לתחום את המטמון: לפי תיעוד Hugging Face, במודלים עם קשב בחלון מחליק (Sliding Window), כמו Mistral ו-Gemma 2, המטמון בשכבות האלה מפסיק לגדול כשהוא מגיע לגודל החלון. אפשר גם לכמת (Quantize) את המטמון לדיוק נמוך יותר, או להעביר אותו לזיכרון המעבד הראשי; התיעוד מציין ששתי הפשרות חוסכות זיכרון ועלולות, בתנאים מסוימים, להאט את היצירה. הדרך המבנית ביותר היא ארכיטקטורה היברידית: במודל Jamba של AI21 חלק גדול מהשכבות הן שכבות Mamba במקום שכבות-קשב, ולפי מאמר המודל המטמון שלו קטן פי 8 מזה של Transformer רגיל.

מהמטמון בתוך בקשה אל מטמון-ההקשר ואל החומרה

המטמון נועד לחסוך חישוב בתוך תשובה אחת, אבל אותו רעיון הורחב אל מעבר לה. כשהרבה בקשות מתחילות באותו טקסט — הנחיית-מערכת ארוכה, מסמך משותף — אפשר לשמור את המטמון של הקידומת ולהשתמש בו שוב: תיעוד Hugging Face מציג דוגמה של מילוי מטמון מראש עבור קידומת ויצירת כמה המשכים שונים ממנה, ומנוע-ההרצה vLLM כולל מנגנון של מטמון-קידומת אוטומטי (Automatic Prefix Caching). ברמת המוצר, זה הבסיס למטמון-הקשר (Prompt Caching) שספקי ה-API מציעים בהנחה על קלט חוזר — ראו הערך הייעודי. גם יצרני החומרה מתייחסים למטמון כמשאב בפני עצמו: בינואר 2026 הציגה NVIDIA בפלטפורמת Vera Rubin שכבת-אחסון ייעודית בשם Inference Context Memory Storage, מבוססת זיכרון-הבזק (Flash), שנועדה להחזיק את מטמון ה-KV של עבודות ארוכות, רב-שלביות ורב-סוכניות מחוץ לזיכרון המעבד הגרפי. NVIDIA מדווחת על עד פי 5 יותר טוקנים לשנייה ועד פי 5 יעילות-חשמל לעומת פתרונות-אחסון מסורתיים; זו טענת-יצרן, לא מדידה עצמאית.

גודל מטמון ה-KV בהקשר של 256 אלף טוקנים, בדיוק של 16 ביט (לפי טבלה במאמר Jamba של AI21, 2024)
פרמטרים בסך הכולפרמטרים פעיליםמטמון KV
LLaMA-26.7 מיליארד6.7 מיליארד128GB
Mistral7.2 מיליארד7.2 מיליארד32GB
Mixtral46.7 מיליארד12.9 מיליארד32GB
Jamba52 מיליארד12 מיליארד4GB

שאלות נפוצות ❓

מה בדיוק שומר מטמון KV?

את וקטורי המפתח (Key) והערך (Value) שהמודל חישב לכל טוקן שכבר עובד, בכל אחת משכבותיו, כדי שבכל צעד חדש יצטרך לחשב אותם רק לטוקן האחרון.

האם המטמון משנה את התשובה של המודל?

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

למה שיחה ארוכה דורשת יותר זיכרון?

כי המטמון שומר נתונים לכל טוקן בהקשר, ולכן גדל עם אורכו. לפי מפתחי vLLM, המטמון של רצף בודד במודל LLaMA-13B יכול להגיע ל-1.7GB.

מה ההבדל בין מטמון KV למטמון-הקשר (Prompt Caching)?

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

איך מקטינים את המטמון?

בין הדרכים: שיתוף מפתחות וערכים בין ראשי-קשב (MQA ו-GQA), תחימה לחלון מחליק, כימות המטמון או העברתו לזיכרון המעבד, וארכיטקטורות היברידיות כמו Jamba שמחליפות חלק משכבות-הקשב בשכבות Mamba.