Prompt Caching — הורדת latency ועלויות במערכות LLM

מאת צוות מדיה דיל · 09.08.2026 · AI · 9 דק׳

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

מערכת AI agent עם system prompt של שלושת אלפים טוקנים - הוראות מפורטות, הגדרת כלים, דוגמאות few-shot - שמופעל מחדש בכל קריאה בודדת, גם כשההוראות עצמן לא משתנות כלל בין בקשה לבקשה. בלי אופטימיזציה, המודל "קורא" מחדש את אותם שלושת אלפים טוקנים בכל פעם, מעבד אותם מהתחלה, ומשלם על כך גם בזמן וגם בעלות - שוב ושוב, על אותו תוכן בדיוק. Prompt Caching פותר את זה: הוא מאפשר למודל "לזכור" עיבוד קודם של חלקים קבועים בפרומפט, ולדלג על עיבודם מחדש בקריאות הבאות שמתחילות באותו תוכן בדיוק.

איך זה עובד ברמת המנגנון - KV Cache

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

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

עיצוב פרומפט למקסום שימוש ב-Cache

ההשלכה הארכיטקטונית המרכזית: הסדר של חלקי הפרומפט קריטי. חלקים שקבועים ביותר בין קריאות - system prompt, הגדרות כלים, דוגמאות few-shot סטטיות - צריכים להופיע בתחילת הפרומפט. חלקים שמשתנים בכל קריאה - השאלה הספציפית של המשתמש, הקשר דינמי שנשלף מ-RAG - צריכים להופיע בסוף. סדר הפוך - תוכן דינמי בהתחלה, קבוע בסוף - הורס לחלוטין את היעילות של Prompt Caching, כי השינוי המוקדם "מנטרל" את הקידומת הקבועה כולה מבחינת יכולת שימוש חוזר.

// מבנה שממקסם Prompt Caching
[System Prompt קבוע - הוראות, אישיות, כללים]
[הגדרות כלים (Tools) - קבועות]
[דוגמאות Few-shot - קבועות]
[--- נקודת השבירה של ה-cache ---]
[הקשר דינמי מ-RAG - משתנה בכל קריאה]
[שאלת המשתמש - משתנה בכל קריאה]

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

מבני שיחה ארוכה - Multi-turn Caching

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

TTL ומחיקת Cache - מתי המנגנון "שוכח"

ה-KV Cache לא נשמר לנצח - כל ספק מגדיר TTL (Time To Live) ל-cache שנוצר, לרוב בטווח של דקות בודדות. המשמעות המעשית: אם עובר יותר מדי זמן בין שתי קריאות שאמורות לשתף את אותה קידומת, ה-cache פג תוקף וצריך להיבנות מחדש מאפס. עבור מערכות עם עומס נמוך או פערי זמן ארוכים בין בקשות (למשל שיחה שמתקדמת לאט מאוד), היתרון של Prompt Caching עלול להתפוגג בפועל, גם אם התוכן זהה טכנית.

ההשלכה התכנונית: כדאי למדוד את דפוסי התעבורה בפועל - אם רוב הקריאות למערכת מגיעות בקצב שמאפשר לנצל את חלון ה-TTL, Prompt Caching שווה מאוד; אם הקריאות מפוזרות בפערי זמן ארוכים, כדאי לבדוק אם יש דרך לקבץ קריאות (batching) או להאריך את חלון ה-TTL אצל ספקים שמאפשרים זאת (לרוב בעלות נוספת), לפני שמניחים שהמנגנון פשוט לא רלוונטי למקרה השימוש.

חיסכון בפועל - עלות ו-Latency

ההשפעה הכפולה של Prompt Caching היא הן על עלות והן על מהירות, אבל בפרופורציות שונות. מבחינת עלות, ספקי LLM לרוב מציעים תמחור מוזל משמעותית לטוקנים שמגיעים מ-cache לעומת טוקנים שמעובדים מחדש - זה חיסכון ישיר וכמותי שגדל ליניארית עם גודל הקידומת הקבועה וקצב החזרתיות שלה בין קריאות. מבחינת latency, החיסכון נובע מכך שהמודל פשוט לא צריך לעבד מחדש את שלב ה-Prefill (עיבוד הפרומפט לפני תחילת ייצור התשובה) עבור החלק שכבר ב-cache - עבור פרומפטים ארוכים עם system prompt כבד, זה יכול להוריד משמעותית את הזמן עד לטוקן הראשון שמוחזר למשתמש (Time To First Token).

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

שילוב עם ניהול Context - קשר ל-Token Engineering

Prompt Caching לא פועל בוואקום - הוא חלק מתמונה רחבה יותר של ניהול נכון של תקציב הטוקנים במערכת, שמתואר במלואו במדריך Token Engineering. החלטות כמו מה נכנס ל-system prompt הקבוע ומה נשלף דינמית מRAG משפיעות ישירות על יעילות ה-caching - ככל שיותר תוכן "יציב" עובר לחלק הקבוע של הפרומפט (בתנאי שהוא באמת לא משתנה), כך יותר טוקנים נהנים מהחיסכון. יש כאן טרייד-אוף עדין: הכנסת תוכן דינמי לתוך הקידומת הקבועה "כדי לחסוך זמן פיתוח" הורסת בפועל את יעילות ה-cache על כל מה שאחריו.

Cache Warming - מניעת "קור" בתחילת עומס

בעיה מעשית שמופיעה בעיקר במערכות עם עומס משתנה: כשמערכת "שקטה" למשך זמן ואז מקבלת גל בקשות, הבקשה הראשונה בכל גל כזה לא נהנית מ-cache כלל, כי אין קידומת קיימת מזמן קודם - היא צריכה "לחמם" את ה-cache מחדש. לכך יש חשיבות מעשית בעיקר במערכות שבהן זמן התגובה של הבקשה הראשונה קריטי (למשל אחרי deploy חדש, או אחרי חלון שקט ארוך בלילה). פתרון נפוץ הוא Cache Warming יזום - שליחת בקשת "חימום" מלאכותית עם הקידומת הקבועה מיד עם עליית המערכת או בתדירות קבועה, כדי לוודא שה-cache תמיד "חם" כשמשתמש אמיתי מגיע, גם אם המשמעות היא עלות שולית קבועה תמורת latency יציב יותר.

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

Caching רב-שכבתי - שילוב עם ספקי מודל מרובים

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

טעויות נפוצות בעבודה עם Prompt Caching

• סדר לא נכון של חלקי הפרומפט - הצבת תוכן דינמי (שאלת המשתמש) לפני תוכן קבוע (system prompt), מה שמנטרל את יכולת ה-caching כמעט לחלוטין.
• שינויים "קטנים" בתוכן הקבוע - עדכון timestamp או מזהה סשן בתוך מה שאמור להיות קידומת קבועה, מה שמזהם את כל ה-cache ומכריח עיבוד מחדש.
• הזנחת TTL בעומסי עבודה מפוזרים - הנחה שה-cache תמיד פעיל בלי לבדוק שקצב הבקשות בפועל תואם את חלון התוקף.
• אי-מדידת חיסכון בפועל - הטמעת caching בלי לעקוב אחרי מדדי cache hit rate בפועל, ולגלות רק מאוחר יותר שהמבנה לא ממנף את המנגנון כמצופה.

דוגמה מהשטח - כשמזהה סשן שבר את כל ה-Cache

בפרויקט AI agent פנימי, הצוות בנה system prompt מפורט הכולל תיאור כלים והוראות אישיות, ובתחילת הפרומפט הוסיף שורת מטא-דאטה עם מזהה סשן ייחודי לצרכי logging - נראה כמו תוספת קטנה ותמימה. בפועל, הוספת המזהה הייחודי בתחילת הפרומפט הרסה את יכולת ה-caching לחלוטין: כל קריאה קיבלה מזהה סשן שונה, ולכן כל הפרומפט - כולל אלפי הטוקנים הקבועים שבאו אחרי המזהה - נחשב "חדש" מבחינת מנגנון ה-cache בכל פעם. הצוות גילה את הבעיה רק כשמדדי latency ועלות לא השתפרו כלל אחרי הטמעת Prompt Caching, שאמורה הייתה לתת חיסכון ניכר. הפתרון היה פשוט אך לא טריוויאלי לגלות: העברת מזהה הסשן לסוף הפרומפט, אחרי הקידומת הקבועה, כך שהוא לא "מזהם" את יכולת השימוש החוזר בחלק הקבוע. הלקח: כל שדה דינמי, גם הקטן ביותר, חייב להיבדק במפורש מבחינת מיקומו בפרומפט - הנחות אינטואיטיביות לגבי "זה רק שדה קטן" לא תמיד נכונות.

שאלות נפוצות

מה זה KV Cache ולמה הוא הבסיס ל-Prompt Caching?

KV Cache הוא הייצוג הפנימי שהמודל מחשב לכל טוקן בזמן עיבוד הפרומפט. Prompt Caching מנצל את זה כדי לדלג על חישוב מחדש עבור קידומת שכבר עובדה בקריאה קודמת.

למה הסדר של חלקי הפרומפט כל כך משמעותי?

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

כמה זמן ה-Cache נשמר?

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

האם Prompt Caching מחליף Semantic Cache?

לא - הן פותרות בעיות שונות. Semantic Cache מונע קריאה למודל כלל עבור שאלות דומות; Prompt Caching מייעל קריאות שכן מתבצעות.

איך יודעים אם המערכת שלי מנצלת Prompt Caching נכון?

מדידת cache hit rate מפורשת דרך מטריקות שהספק חושף, יחד עם השוואת latency ועלות לפני ואחרי מבנה פרומפט מותאם.

האם Prompt Caching מתאים גם למערכות עם עומס נמוך?

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

מבנה פרומפט נכון שממקסם Prompt Caching יכול להוריד עלויות ו-latency משמעותית בלי לוותר על איכות. מדיה דיל בונה מערכות AI יעילות מהיסוד - דברו איתנו בוואטסאפ.

תגיות: Prompt Caching · LLM · Latency · Cost Optimization · Context Window · System Prompt · Token

← חזרה לבלוג · צור קשר