אופטימיזציית עלויות: שמירה מהירה במטמון

רווחים:

• הסבירו את הלוגיקה של התאמת הקידומת של שמירה במטמון
• מגדיל את הפגיעה במטמון על ידי הצבת הקשר קבוע ראשון והקשר משתנה אחרי
• יכול לחשב כתיבה/קריאת מטמון כלכלה ונקודת איזון

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

איך המטמון עובד? הכלל האחד בלתי משתנה

שמירה במטמון היא התאמה לקידומת. הספק שומר באופן זמני את האסימונים שהוא עיבד מאז תחילת ההנחיה שלך. אם ההנחיה מתחילה עם אותה קידומת בבקשה הבאה, החלק המשותף הזה לא מחושב מחדש; זה הרבה יותר זול לקריאה מאשר מטמון.

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

סדר העיבוד הוא בדרך כלל: כלים → הנחיית מערכת → הודעות. אתה שם את נקודת המטמון (נקודת הפסקה) בסוף הקטע הקבוע.

כלכלת מטמון

למטמון שלוש רמות מחיר:

• כתיבת מטמון: אחסון בפעם הראשונה. ~1.25x מחיר קלט רגיל (עבור 5 דקות אחסון).
• קריאת מטמון: קריאה בבקשות עוקבות. פי 0.1 ממחיר התשומה הרגיל - כלומר עשירית.
• קלט רגיל: החלק שלא נכנס למטמון ומעובד בעלות מלאה בכל פעם.

נקודת איזון: בקשה ראשונה משלמת פרמיית כתיבה (×1.25). מהבקשה השנייה, הקריאה (0.1×) נכנסת לפעולה. בערך, אתה תהיה צוואר על צוואר על שתי בקשות; אחרי זה, זה חיסכון נטו. ככל שההקשר הקבוע גדול יותר וככל שיותר בקשות נעשה בו שימוש חוזר, כך הרווח גדל.

תַרחִישׁ

האם המטמון עובד?

הודעת מערכת קבועה גדולה, אלפי בקשות

כן - הרווחים הגבוהים ביותר

שאלות רבות על אותם מסמכי עזר

כן

טקסט קצר שונה לחלוטין לכל בקשה

לא - בונוס כתיבה מבוזבז

בקשה חד פעמית

לא - אין קריאה בכלל

תאריך/מזהה משתנים עם כל בקשה בהודעת המערכת

לא - הקידומת שבורה, הפגיעה היא אפס

שלב אחר שלב: כיצד להגדיר הודעת היט?

1. הפרד בין קבוע למשתנה. איזה תוכן לעולם לא משתנה (הנחיית מערכת, ספר חוקים, תיעוד)? מה משתנה עם כל בקשה (שאלת משתמש, תאריך, מזהה)?
2. שים את הקבוע בהתחלה. במהלך העיבוד, החלק שבא קודם (כלים, מערכת) חייב להיות יציב.
3. שים את המשתנה בסוף. השאלה הנוכחית של המשתמש, אחרונה.
4. מניחים את השלט בקצה הגבול. שים את נקודת המטמון בבלוק האחרון של החלק הקבוע.
5. אמת פגיעה. בדוק אם cache_read_input_tokens גדול מאפס בשדה השימוש בתגובה. אם אפס, קיים משבש נסתר בקידומת.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "{{}user_user_}}current

טיפ: אל תנחש כניסות מטמון, מדוד אותן. אם usage.cache_read_input_tokens עדיין אפס בבקשות עוקבות, פועל מפסק שקט (datetime.now() בהנחיית המערכת, JSON לא מסודר, רשימת הכלים המשתנים עם כל בקשה. השווה את ההנחיה הגולמית של שתי הבקשות בייט אחר בייט ומצא את ההבדל.

משבשים שקטים

דפוסים אופייניים המשחיתים את המטמון מבלי לדעת:

# BREAKER: הטמעת מידע בהנחיית המערכת שמשתנה עם כל בקשה "תאריך היום: {{עכשיו}}. אתה עוזר..." ← הקידומת משתנה עם כל בקשה, הפגיעה היא אפס# TRUE: העבר את המשתנה למערכת ההודעות: "אתה עוזר..." ← הקבוע נכנס ל-cachemessages: {{roleto:day: תוכן. ..."}] ← משתנה בסוף

מפרקים אחרים: JSON ממוין באופן שונה בכל בקשה (שמור את המפתחות בסדר קבוע), רשימת הכלים משתנה לפי משתמש (הכלים מעובדים תחילה; שום דבר לא נכנס למטמון אם הם משתנים), שינוי המודל באמצע השיחה (מטמונים הם ספציפיים לדגם).

הנחיה חלשה / הנחיה חזקה (מבנה ידידותי למטמון)

# מערכת חלשה (בניית מטמון): "תאריך: 18.07.2026 14:32. משתמש: Ahmet (id 8842). אתה בוט תמיכה. כללים: ...(2000 אסימונים)..."

# STRONG (מבנה ידידותי למטמון) system: "אתה בוט תמיכה. כללים: ...(2000 אסימונים, לעולם לא משתנה)..." [סימן מטמון]הודעות: [ { תפקיד: משתמש, תוכן: "תאריך: 18.07.2026 14:32. מזהה משתמש: 8842. שאלה: איך אני מפעיל את ההחזר שלי?" }]

בגרסה החלשה, בלוק הכלל של 2000 אסימונים מעובד בעלות מלאה בכל בקשה. בגרסה החזקה, אותו בלוק נכתב פעם אחת ונקרא על כל הבקשות הבאות תמורת עשירית מהמחיר.

שלושה מיני מארזים

מקרה 1 - שמירה במטמון של ספר החוקים. אוטומציה חשבונאית הוסיפה את ספר החוקים של 12,000 אסימונים לכל חשבונית; 5,000 בקשות ביום. קלט ללא מטמון עולה ~180$ ליום. הם שמרו על ספר החוקים קבוע ושמרו אותו במטמון: בקשות ראשונות שילמו פרמיית כתיבה, לאחר מכן קריאות 0.1×. עלות הקלט ירדה ~90% ל~$18 ליום.

מקרה 2 - עלות שורת תאריך נסתרת. צוות אחד הקים מטמון אך לא קיבל פגעים; cache_read_input_tokens היה תמיד אפס. סיבה: היה datetime.now() בשורה הראשונה של שורת המערכת, הקידומת השתנתה עם כל בקשה. כשהעברנו את התאריך להודעת המשתמש, שיעור הפגיעה עלה פתאום מ-0% ל-94%.

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

טעויות נפוצות

• ערבוב קבוע ומשתנה: כאשר תוכן המשתנה נמצא בקידומת, הפגיעה מתאפסת.
• הטמעת תאריך/מזהה בהנחיית מערכת: המשבש השקט הנפוץ ביותר.
• לא מודדים את הפגיעה: אם cache_read_input_tokens לא מסומן, לא יבחינו בבזבוז.
• הוספת מטמון כשאין קידומת ציבורית: אתה משלם רק את פרמיית הכתיבה, העלות עולה.
• שינוי רשימת הרכבים או הדגם: הקידומת שבורה מההתחלה; הכל נכתב מחדש.
• שכחת גודל המטמון המינימלי: מטמונים קצרים מאוד (מתחת ל-1-4k אסימונים בהתאם לדגם) לא ייכנסו למטמון בשקט.

עמוק יותר: עיצוב מטמון לפי סוג עומס עבודה

התמורה בפועל של שמירה במטמון משתנה בהתאם לאופי עומס העבודה שלך; אז תחילה להכיר את התנועה שלך. שלוש תבניות אופייניות והתקנה נכונה:

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

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

הקידומת המשותפת היא החלק האחרון לשינוי. בקשות מרובות חולקות קבוצה גדולה של קודמים קבועים (סט מדגם, הוראות) אך מופרדות בשאלה אחת בסוף. אתה שם את מצביע המטמון בסוף החלק המשותף; אחרת, כל בקשה תכתוב מטמון נפרד משלה ואף אחד ממנו לא ייקרא.

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

לסיכום

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

משימת יישום

בחר עומס עבודה. (1) חלקו את התוכן לשתי עמודות: "לעולם לא משתנה" ו"משתנה עם כל בקשה". (2) צייר מחדש את מבנה הפקודה, שים את החלק הקבוע בהתחלה ואת החלק המשתנה בסוף. (3) הערך את גודל האסימון של החלק הקבוע והשווה את העלות החודשית עם/בלי מטמון. (4) שימו לב מאיזה שדה (cache_read_input_tokens) תאמת את הפגיעה.

רשימת בדיקה

• [ ] אני יכול להסביר שהמטמון הוא התאמת קידומת והכלל היחיד הבלתי ניתן לשינוי.
• [ ] אני יכול להגביר את הדיוק על ידי הצבת התוכן הקבוע בהתחלה והמשתנה בסוף.
• [ ] אני יודע לכתוב/לקרוא כלכלה ואת נקודת האיזון של שתי בקשות.
• [ ] אני יכול לזהות משבשים שקטים (תאריך, JSON לא מסודר, רשימת רכבים משתנה).
• [ ] אני יכול לאמת את הפגיעה באמצעות usage.cache_read_input_tokens.