הרעיון הבסיסי: לא לחשב פעמיים את מה שכבר חושב
כל קריאה למודל-שפה גדול כרוכה בעיבוד הפרומפט השלם מההתחלה: הנחיית-המערכת, הגדרות-הכלים הזמינים, ולעיתים היסטוריית-שיחה ארוכה — כל זה עובר בכל פעם מחדש דרך שכבות-הרשת-העצבית של המודל כדי לחשב את מה שנקרא בעגה הטכנית מצב-תשומת-הלב (Attention State, או KV-Cache). כשחלק גדול מהפרומפט חוזר על עצמו בין קריאה לקריאה — למשל הנחיית-מערכת ארוכה שמוגדרת פעם אחת לכל הסוכן, או רשימת-כלים שלמה שחוזרת בכל צעד בלולאת-סוכן — עיבוד חוזר של אותו טקסט בכל פעם הוא בזבוז-חישוב מיותר. מטמון-הקשר (Prompt Caching, ולעיתים Context Caching) פותר את זה: הוא שומר את מצב-העיבוד של קידומת (Prefix) חוזרת בפרומפט, כך שקריאה הבאה שמתחילה באותה קידומת בדיוק לא צריכה לחשב אותה מחדש — רק את החלק החדש שמעבר לה. המצב הפנימי הזה הוא מטמון KV (KV Cache), שכל מודל-שפה מבוסס Transformer בונה ממילא תוך כדי יצירת תשובה אחת; מטמון-הקשר שומר אותו גם בין קריאה לקריאה.
Anthropic: נקודות-מטמון מפורשות ו-TTL כפול
Anthropic השיקה מטמון-הקשר באוגוסט 2024, כגישה מבוססת-סימון מפורש: המפתח מוסיף לפרומפט עד ארבע "נקודות-שבירה" (cache_control, מסוג ephemeral) שמסמנות איפה כדאי לחתוך את המטמון, והמערכת שומרת את הקידומת עד לנקודה האחרונה שסומנה — בסדר קבוע של כלים, הנחיית-מערכת, ואז הודעות. ברירת-המחדל היא זמן-חיים (TTL) של חמש דקות מרגע השימוש האחרון, עם אפשרות לשלם פרמיה ולקבל מטמון לשעה שלמה. מבחינת מחיר: כתיבה למטמון עולה פי 1.25 (חמש דקות) או פי 2 (שעה) ממחיר-קלט רגיל, אבל קריאה ממטמון עולה רק עשירית מהמחיר הרגיל — הנחה של 90 אחוז. לפי רשומת-ההשקה של Anthropic, בתרחיש של "שיחה עם ספר שלם" (כ-100 אלף טוקן) המטמון קיצץ 79 אחוז מזמן-התגובה ו-90 אחוז מהעלות; בשיחות רב-תוריות הקיצוץ עמד על 75 אחוז בזמן ו-53 אחוז בעלות.
ציר-זמן: שלושה ספקים תוך פחות משנה
שלושת המימושים הושקו בפער של חודשים בודדים זה מזה: Google הייתה הראשונה, עם הוספת מטמון-הקשר ל-Gemini API כבר ב-18 ביוני 2024; Anthropic עקבה כחודשיים לאחר מכן, באוגוסט 2024, עם מטמון-הקשר מבוסס-נקודות-שבירה מפורשות; ו-OpenAI השלימה את השלישייה בסוף אותה שנה עם גרסה אוטומטית שלא דרשה שינוי-קוד כלל. הרצף המהיר הזה — כמעט כל הספקים המובילים בתוך פחות משנה — משקף עד כמה מהר תבנית-השימוש בסוכני-AI, עם הפרומפטים הארוכים והחוזרים-על-עצמם שהם דורשים, הפכה מתרחיש-קצה לצורך-ליבה בתשתית ה-API של כל ספק מרכזי.
OpenAI: מטמון אוטומטי בלי שינוי-קוד
OpenAI בחרה בגישה שונה בתכלית: המטמון שלה פועל באופן אוטומטי, בלי צורך לסמן נקודות-שבירה במפורש בקוד. כל פרומפט שעובר 1,024 טוקן נבדק אוטומטית מול קריאות קודמות, וכשיש התאמה בקידומת המשותפת, הקריאה מקבלת הנחה של 90 אחוז על אותו חלק חוזר — בלי שהמפתח יצטרך לשנות כלום בקוד הקיים. זמן-החיים של המטמון במודלים החדשים הוא 30 דקות — גם כברירת-מחדל וגם כמקסימום; במודלים מוקדמים-יותר ברירת-המחדל הייתה ארוכה בהרבה, עד 24 שעות. במסמכי-התיעוד הרשמיים OpenAI מציגה דוגמאות-שימוש אמיתיות: משימת-שיפוט-איכות חד-פעמית שהגיעה לשיעור-פגיעה-במטמון (Cache Hit Rate) של כ-70 אחוז, וסוכן רב-שלבי שהגיע לשיעור-פגיעה של מעל 90 אחוז.
Gemini: מטמון סמוי מול מטמון מפורש, ותשלום נפרד על אחסון
Google מציעה אצל Gemini שני מסלולים שונים. מטמון סמוי (Implicit Caching) פועל אוטומטית כברירת-מחדל אצל דגמי Gemini 2.5 ומעלה, בלי הגדרה מצד המפתח — בדומה לגישה של OpenAI. מטמון מפורש (Explicit Caching) מאפשר למפתח ליצור ולנהל בעצמו "אובייקט-מטמון" נפרד, ודורש לפחות 2,048 עד 4,096 טוקן, תלוי בדגם. ההבדל המבני הבולט ביותר בין Gemini לשני המתחרות: מלבד ההנחה של כ-90 אחוז על קריאה מהמטמון — דומה לשתי החברות האחרות — Google גובה גם דמי-אחסון נפרדים לפי שעה, בסדר-גודל של חצי-דולר ועד 4.5 דולר לכל מיליון טוקן לשעה, תלוי בדגם. זו עלות שאין לה מקבילה אצל Anthropic או OpenAI, ששתיהן לא גובות תשלום נפרד על עצם ההחזקה של המטמון.
מטמון-הקשר וההתפתחות של חלונות-הקשר הענקיים
ההתפתחות של מטמון-הקשר קשורה קשר הדוק להתרחבות הדרמטית של חלונות-ההקשר אצל מודלים מובילים, שהגיעו למיליון טוקן ומעלה (ראו הערך אחזור-מוגבר-בייצור (RAG) לדיון מקביל לגבי RAG מול חלון-הקשר מורחב). ככל שמפתחים מזינים יותר ויותר מידע ישירות לפרומפט — קובצי-קוד שלמים, מסמכים ארוכים, היסטוריות-שיחה מתמשכות — עלות עיבוד-מחדש של אותו מידע שוב ושוב הופכת למכשול כלכלי ממשי, לא רק תיאורטי. מטמון-הקשר הוא בעצם התשובה המשלימה לבעיה הזו: הוא לא מקטין את חלון-ההקשר, אלא הופך שימוש חוזר בו לזול משמעותית, כך שהרחבת חלונות-ההקשר וההוזלה שמטמון-הקשר מספק מזינות זו את זו — חלון גדול יותר שימושי יותר כשהעלות של להשתמש בו שוב ושוב נמוכה.
סדר-קבוע כדי למקסם פגיעות-מטמון: כלים, הנחיה, ואז שיחה
Anthropic ממליצה במפורש לבנות את הפרומפט לפי סדר קבוע — תחילה הגדרות-הכלים, אחר-כך הנחיית-המערכת, ורק בסוף היסטוריית-השיחה המשתנה — כי זה הסדר שהמטמון עוקב אחריו: חלקים שמופיעים מוקדם ומשתנים לעיתים רחוקות (כלים, הנחיה) נשמרים כקידומת-מטמון יציבה, וחלקים שמופיעים מאוחר ומשתנים בכל צעד (השיחה עצמה) הם היחידים שבאמת מתעבדים מחדש בכל קריאה. עקרון-סידור דומה מנחה גם מפתחי-סוכנים שמשתמשים במטמון האוטומטי של OpenAI או Gemini: גם שם, ככל שהחלקים היציבים ביותר מופיעים מוקדם יותר בפרומפט, כך גדל הסיכוי שהם יזוהו כקידומת-חוזרת ויחסכו את עלות-העיבוד-מחדש.
כשמטמון לא עוזר: קלט קצר או ייחודי בכל פעם
מטמון-הקשר לא נותן שום יתרון כשאין בכלל קידומת חוזרת — למשל שירות שמקבל כל פעם שאלה קצרה ועצמאית לגמרי, בלי הנחיית-מערכת ארוכה ובלי היסטוריה משותפת. במקרים כאלה, מנגנון-המטמון פשוט לא מזהה שום דבר לחסוך, וההוצאה הנוספת על כתיבה-למטמון (אצל Anthropic, פרמיה של עד פי 2) אף עלולה להפוך פחות-משתלמת מקריאה רגילה חד-פעמית. זו הסיבה שהתועלת מרוכזת במיוחד בתרחישי-סוכן ובצ'אטבוטים-שיחתיים, ולא בכל שימוש ב-API של מודל-שפה.
מה זה תורם לסוכני-AI בפרט
מטמון-הקשר רלוונטי במיוחד לסוכן-AI (ראו הערך הייעודי) שמריץ לולאה ארוכה של צעדים: בכל צעד כזה, הנחיית-המערכת המלאה, רשימת-הגדרות-הכלים, וההיסטוריה שהצטברה עד כה נשלחות מחדש למודל — ובלי מטמון, המחיר והזמן גדלים ליניארית עם כל צעד נוסף בלולאה, גם כשרוב התוכן זהה לצעד הקודם. מכיוון שהמטמון "זז קדימה" עם כל תוספת חדשה (הקידומת הקודמת עדיין תקפה, רק מה שנוסף בסופה הוא חדש), עלות-הרצת-סוכן ארוכה יכולה לרדת משמעותית ברוב הצעדים, פרט לצעד הראשון שבו נבנה המטמון לראשונה. זו הסיבה שמטמון-הקשר נחשב כיום לתשתית סמויה אך קריטית מאחורי כל סוכן-קידוד או סוכן-מחקר שמריץ עשרות צעדים ברצף באותה שיחה.
סף מינימלי לפרומפט
לכל אחד משלושת הספקים יש גם סף-אורך מינימלי לפרומפט שמתחתיו המטמון פשוט לא מופעל: אצל Anthropic הסף נע בין 512 ל-4,096 טוקן, תלוי בדגם הספציפי; אצל OpenAI הסף האחיד הוא 1,024 טוקן; ואצל Gemini הסף נע בין 2,048 ל-4,096 טוקן, תלוי בדגם. המשמעות המעשית: עבור בקשות קצרות — הודעת-משתמש בודדת בלי הנחיית-מערכת ארוכה — המטמון פשוט לא רלוונטי, וכל התועלת שלו מתרכזת בדיוק בתרחישים שסוכני-AI נתקלים בהם הכי הרבה: פרומפטים ארוכים שחוזרים על עצמם שוב ושוב באותה לולאה.
שבירת המטמון: כל שינוי בקידומת מפיל הכול אחריו
לכל שלושת המימושים יש מכנה משותף שמגביל את התועלת בפועל: המטמון תקף רק לקידומת מדויקת וזהה. ברגע שמשהו משתנה בתחילת הפרומפט — אפילו תו בודד בהנחיית-המערכת, או רשימת-כלים ששונה סדר-ההופעה שלה — כל מה שמעבר לנקודת-השינוי מפסיק להיות ממוטמן, גם אם רוב הטקסט שאחריו זהה. המשמעות המעשית עבור מי שבונה סוכן: כדאי לשמור על סדר קבוע ויציב של רכיבי-הפרומפט — תמיד כלים, ואז הנחיית-מערכת, ואז היסטוריה — ולהימנע מהוספת חותמות-זמן דינמיות או ניסוחים משתנים בתחילת הפרומפט, כי אפילו שינוי קטן שם עלול לבטל את כל יתרון-המטמון עבור הבקשה כולה.
דוגמה: מטמון-הקשר בצינור RAG
תרחיש נפוץ נוסף שמטמון-הקשר משרת היטב: מערכת אחזור-מוגבר-בייצור (RAG) שמזינה מסמך-רקע ארוך וקבוע לכל שאילתה — למשל תקנון-מוצר שלם, או ספר-הדרכה פנימי — יחד עם שאלת-משתמש שמשתנה בכל פעם. בלי מטמון, כל שאלה חדשה גוררת עיבוד-מחדש מלא של המסמך כולו, גם אם הוא זהה לחלוטין לזה ששימש את השאלה הקודמת. עם מטמון-הקשר, המסמך עצמו נשמר כקידומת ממוטמנת, וכל שאלה חדשה משלמת רק על עיבוד השאלה הקצרה שמתווספת בסופו — בדיוק אותו עיקרון שמופעל בלולאת-סוכן, אבל בהקשר-שימוש שונה.
מטמון-הקשר מול מטמון סמנטי
חשוב להבחין בין מטמון-הקשר לבין מטמון סמנטי (Semantic Caching), מנגנון נפרד: מטמון-הקשר עובד ברמת ה-API של ספק-המודל עצמו, ומזהה התאמה מדויקת של קידומת-טוקנים חוזרת — מילה-במילה, לא לפי משמעות. מטמון סמנטי, לעומת זאת, פועל בשכבה שמעל למודל: הוא משווה שאלות שונות-בניסוחן-אך-דומות-במשמעות (למשל "מה מזג האוויר מחר?" מול "איך יהיה האוויר מחר?"), ומחזיר תשובה שמורה בלי לקרוא למודל כלל. אלה שני מנגנוני-חיסכון משלימים ולא מתחרים: מטמון-הקשר חוסך בתוך קריאה בודדת למודל שחוזרת על קידומת זהה, ומטמון סמנטי חוסך את הקריאה למודל כולה כשהשאלה כבר נענתה בעבר בניסוח שונה.