הפעלת prompt caching לא חסכה לי דבר—למעשה, החשבונית שלי ב-OpenAI-API קפצה בכרבע בערך. האשם היה שורה אחת שהשתנתה בכל בקשה: חותמת זמן (timestamp) שהייתה מוטמעת בתוך ה-system prompt.
ספקי LLM מאפשרים למפתחים לבצע caching לשברי prompt כדי להפחית את עלויות עיבוד ה-tokens. קריאה מהמטמון (a “hit”) עולה רק עשירית מהתעריף הרגיל, בעוד שכתיבה למטמון (a “miss”) עולה בערך פי 1.25 מהמחיר הרגיל. אם מתבצעת כתיבה אך השבר המטמון לעולם לא נקרא, תשלום ה-25% הנוסף הולך לטמיון. זה בדיוק מה שקרה כשה-timestamp מנע מה-prompt להתאים לאף רשומה קיימת במטמון.
למה caching יכול להשתבש
Prompt caching עובד על ידי התאמה של רצף הבתים (byte sequence) המדויק של החלק המטמון. הספק מבצע hashing לקלט; אם ה-hash תואם לרשומה שמורה, המערכת משתמשת מחדש בחישוב הקודם ומחילה את תעריף הקריאה הזול. כל שינוי—אפילו תו בודד—שובר את ההתאמה ומאלץ חישוב חדש, שחייב בתעריף הכתיבה הגבוה יותר.
במקרה שלי, ה-system prompt התחיל ב:
Current session started: 2026-07-14T09:41:07Z
מכיוון שה-timestamp התעדכן בכל קריאת API, הבתים הראשונים של הבקשה מעולם לא היו זהים. הספק התייחס לכל קריאה כרשומה חדשה במטמון, חייב בפרמיית הכתיבה, ומעולם לא תיעד קריאה. התוצאה הייתה עלייה מתמדת ב-cache_creation_input_tokens בעוד ש-cache_read_input_tokens נשאר על אפס, סימן ברור לכך שהמטמון מעולם לא הופעל (hit).
איך לזהות מטמון תקול
יומני השימוש (usage logs) המסופקים על ידי ה-API מציגים שני מונים מרכזיים:
- cache_creation_input_tokens – tokens שהפעילו כתיבה.
- cache_read_input_tokens – tokens שנהנו מקריאה.
כאשר הראשון עולה והשני נשאר שטוח, המטמון אינו מנוצל מחדש. בדיקת תקינות (sanity check) מהירה היא לחזור על אותה בקשה בדיוק פעמיים; הקריאה השנייה צריכה להראות קפיצה ב-read tokens אם המטמון מתפקד כראוי.
פתרון הבעיה
הפתרון פשוט: ודאו שהאזור המטמון הוא סטטי לאורך הקריאות. פעלו לפי שני הכללים הללו:
- הציבו תוכן בלתי משתנה (immutable) ראשון. system prompts, הגדרות כלים (tool definitions), או כל הוראה שאינה משתנה לעולם צריכות לתפוס את הבתים הראשונים של הבקשה.
- הוסיפו תוכן משתנה (mutable) בסוף. חותמות זמן (timestamps), טקסט שנוצר על ידי משתמש, מזהי בקשה (request IDs), או כל נתון שמשתנה בין קריאה לקריאה חייבים להופיע אחרי הקטע המטמון.
אם אפילו תו אחד זז, ה-hash משתנה וה-cache miss נמשך. סידור מחדש של ה-prompt כך שחותמת הזמן תהיה בסוף מחזיר את שיעור ה-cache hit ומוריד את החשבונית חזרה לרמת העלות הנמוכה המצופה.
מתי caching באמת עוזר
Prompt caching באמת מנצח בתרחישים שבהם סט הוראות זהה מנוצל מחדש פעמים רבות:
- Agent loops שבהם AI קורא שוב ושוב למערך קבוע של כלים.
- Chat sessions המתייחסים למסמך ארוך וסטטי, בעוד שרק השאילתה האחרונה של המשתמש משתנה.
- Bulk data extraction שבו אותו prompt ניתוח (parsing) מוחל על רשומות רבות.
עבור קריאות חד-פעמיות (single-shot) הכוללות הקשר (context) חדש בכל פעם — כמו שאלה בודדת עם הקדמה ייחודית — ה-caching אינו מציע שום יתרון ואף עלול להוסיף עלות אם הבקשה מפעילה כתיבה בטעות.
מלכודות נסתרות
גם אם ה-prompt עצמו סטטי, הבקשה עלולה להשתנות בשלבים מאוחרים יותר (downstream):
- Proxies או אגרגטורים שמסדרים מחדש או מזריקים רווחים (whitespace) עלולים לשבור את ההתאמה של בית-אחר-בית.
- שירותי Gateway שמוסיפים כותרות אימות (authentication headers) בתחילת הבקשה או משנים את פורמט ה-JSON עלולים לשנות בטעות את הקטע המטמון.
בדיקה דרך ה-gateway על ידי שליחת אותה בקשה בדיוק פעמיים ובדיקת מוני הקריאה עוזרת לוודא שנתיב ה-caching נשאר תקין.
תמונת העלות הרחבה יותר
תוספת ה-25% על כתיבות אינה קנס על שימוש ב-caching; היא משקפת את כוח העיבוד הנוסף הדרוש לאחסון השבר לצורך שימוש עתידי. כאשר מתרחש cache hit, העלות צונחת דרמטית — לעיתים קרובות לשבריר מהתעריף הרגיל. המפתח הוא לאפשר למערכת באמת לפגוע במטמון (hit the cache). אחרת, אתם משלמים את הפרמיה ללא כל חיסכון.
טיעון נגד: caching לא מת
Some developers argue that the complexity of managing static versus dynamic prompt parts outweighs the savings. That view overlooks the fact that many production pipelines already separate configuration (static) from user data (dynamic). By structuring prompts accordingly, the same caching mechanism that saved the original developers of the API can be leveraged without extra effort. The trade-off is a modest discipline in prompt design, not a fundamental flaw in the technology.
What to watch next
- Monitor the two cache counters in your usage dashboard weekly.
- Audit prompt construction to confirm that any variable element sits after the cached block.
- Run A/B tests with and without caching on a representative workload to quantify actual savings.
- Validate the gateway by comparing raw request payloads before and after any proxy.
Takeaway
Prompt caching can slash LLM API costs, but only if the cached segment is truly identical across calls. A stray timestamp or any other dynamic token at the start of a prompt forces a costly write every time, inflating the bill. By front-loading static instructions and relegating changing data to the tail end, you let the cache do its job and keep your expenses in check.