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

למה ה-cache חשוב

ה-prompt cache של הספק חוסך לכם כסף על ידי דילוג על עיבוד מחדש של כל בקשה שמתחילה בקידומת (prefix) זהה בבייט-אח-בייט. אם הטוקנים (tokens) הראשונים תואמים לקריאה קודמת, הספק משתמש מחדש בייצוג שכבר חושב עבור אותם טוקנים ומחייב רק על הסיומת (suffix) החדשה. הכלל הוא קפדני: ההתאמה חייבת להיות מדויקת, לא רק דומה. טוקן אחד שונה בהתחלה הורס את כל ה-cache hit.

הטעות שהרגה את אחוז ההצלחה (hit rate)

בסוכן (agent) שלנו, הצבנו חותמת זמן (timestamp) נוכחית ממש בראש ה-system prompt כדי לתת למודל תחושה של "עכשיו". מכיוון שחותמת הזמן משתנה בכל שנייה, רצף הטוקנים הראשון היה ייחודי לכל בקשה. ה-cache מעולם לא מצא התאמה, ולכן כל קריאה גררה איתה את המחיר המלא עבור 18,000 הטוקנים הסטטיים שבאו לאחר מכן — סכמות של כלים (tool schemas), קטעי תיעוד, דוגמאות few-shot והוראות קבועות. התוצאה הייתה אחוז cache hit של 0% וחשבון שזינק פי שלושה.

ארגון מחדש לצורך יכולת caching

הפתרון פשוט: שמרו את כל מה שאינו משתנה בתחילת הפרומפט, ודחפו כל נתון משתנה (volatile) לסוף.

קידומת סטטית (ניתנת ל-cache)

  • הגדרות כלים (Tool definitions)
  • מסמכי שליפה (Retrieval documents)
  • דוגמאות few-shot
  • הוראות מערכת קבועות

סיומת משתנה (לא ניתנת ל-cache)

  • זמן נוכחי
  • מזהי סשן (Session identifiers)
  • הודעות משתמש
  • הקשר חי (Live context)

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

רוצחים נסתרים ב-stack

גם כשהתבנית נראית תקינה, middleware או SDKs יכולים להוסיף בשקט מטא-דאטה — מזהי בקשה (request IDs), חותמות זמן או כותרות (headers) אחרות — לפני שהתכולה (payload) מגיעה ל-API. גם כמה מ-deployment pipelines משנים את סדר הגדרות הכלים בכל rollout. השינויים הבלתי נראים הללו משנים את רצף הבייטים ומחבלים ב-cache מבלי שבוצע שום שינוי בקוד של בונה הפרומפטים שלכם.

עקבו אחר אחוז ה-cache hit

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

שורה תחתונה

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