טעויות בזיכרון קאש של פקודות יכולות לעלות לארגון שלך כמעט 6x בכל סיבוב AI

מאז הבנתי חלק מהסיבה. אדם יכול לחזור לשיחה ביום הבא, וכל הזמן שהשיחה ניתנה בתחילת התהליך התיישן. משהו צריך לספק אותו שוב. harness, התוכנית סביב מודל שמרכיב כל בקשה ומריץ את הלולאה, יכול לעשות זאת על ידי כתיבת הזמן הנוכחי בהוראות המודל לפני כל בקשה. הרץ הסוכן שאנו משתמשים בו בייצור עשה בדיוק את זה.

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

התשובה היא יקרה. ב-GPT-6 Luna, הזמן שנכתב במקום הלא נכון גרם לכל סיבוב של שיחה לעלות 5.7× מה שהיה צריך, וללא שגיאה כלשהי. ברחבי ארגוני התנועה שולחים את הדגמים האלה, הקלט הוא 96–99% של התויקים ו-66–87% של הדולרים ששולמו בפועל, כך שהמטמון מחליט את רוב החשבון. עבור ארגון שמבנה את החיבורים שלו, מריץ פלטפורמת AI פנימית או שולח מוצרים מבוססי AI, טעות כזו מכפילה את עלות כל סיבוב, בשקט, כל עוד היא רצה.

כל מספר לפי סיבוב כאן נמדד ב-23 בספטמבר 2026, דרך OpenRouter. הנתונים השוקיים הם של OpenRouter עצמו, קראו אותם באותו יום.

כל קריאה למודל שולחת את כל השיחה שוב: הגדרות הכלים, הבקשה של המערכת (ההוראות הקבועות שהחבל כותב), כל סיבוב קודם, וההודעה החדשה.

ספקים שומרים את תחילת הבקשות המעובדות האחרונות. כאשר הבקשה הבאה מתחילה עם אותו הטקסט, הספק קורא את הפריפיקס המאוחסן במקום לעבד אותו שוב. ב-GPT-6 Luna, OpenRouter חשב קריאה ב-0.10× מחיר הקלט הרשום והכתיבה הראשונה ב-1.25×. בקשה שנכתבת שוב בכל סיבוב לכן עולה יותר מהבקשה ללא מטמון בכלל.

רק תחילת הבקשה ניתן לשימוש חוזר. שינוי בכל נקודה מבטל הכל אחרי זה:

graph LR
    A[הגדרות כלים] --> B[בקשה של המערכת]
    B --> C[סיבובים קודמים]
    C --> D[הודעת משתמש חדשה]
    B -. a changed line here voids B, C and D .-> D

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

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

המפעיל איתו עבדתי מצא תחילה שהרישום עצמו היה שגוי. על פני 33 קריאות הוא העריך $0.064; הספק חשב $0.023, 2.7× פחות. קביעת מחיר לכל קריאה לפי ספירת טוקנים מחיקה כל הנחה שהספק החל. קריאת העלות המדווחת על ידי הספק במקום הראתה קאשינג עובד בתוך כל סיבוב ונכשל בתחילת כל חדש.

ההסבר הראשון שלו היה מפתח סשן חסר שיחזיק בקשות באותו שרת. החקירה שלו שלחה את זה: פקודות זהות כבר נקראו מהקאש בין סיבובים ב‑GPT‑6 Luna, והוספת מפתח סשן, מפתח קאש או סימן קאש מפורש לא שינתה דבר. הסיבה הייתה בפקודה המערכת עצמה. כ־95% מהדרך פנימה, הרץ כתב שתי שורות ששינו בכל סיבוב: ספריית עבודה לכל סיבוב ושעון לדקה. כל קריאה ראשונה של סיבוב כתבה את כל הפקודה מחדש ב‑1.25×.

העברת שתי השורות לסוף ההודעה של המשתמש תיקנה את זה בייצור. סיבובים 2 ו‑3 כעת נפתחים ב‑0.47–0.51× במקום ב‑1.25×. השאר הוא בלוק של הקשר לכל סיבוב שהרץ עדיין שולח בהודעת המשתמש.

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

כדי לבדוק זאת ישירות, בנינו חוקר שמריץ את אותו שיחה עם השעון במקומות שונים, מחלק את 65 שניות כך שהדקה משתנה בין כל זוג. GPT-6 Luna, מערכת פקודה של 8.5K אסימונים, 3 משכפלת:

ההודעה המפרדת שלי שמרה את המטמון בשתי הצורות, בכל סיבוב ורק כאשר יש עומס. התנאי הוא היכן שההודעה נמצאת. לאחר ההוראות הקבועות, הספק קורא הכל לפניו. כמשהו שני של הודעת מערכת הוא נמצא בין ההוראות, ו‑GPT‑6 Luna כתב את כל ההצעה מחדש על 12 של 12 סיבובים.

הכלל שאחריו הוא קצר. כל דבר שמשנה בין סיבובים מגיע אחרי הכל שלא משתנה.

המטמון משווה טקסט, לכן שעון אינו מזיק כל עוד הטקסט שלו נשאר זהה. באותו חוקר עם החלפות 4 שניות, שעון דקה במערכת הקלט נקרא מהמטמון בכל פעם. עם החלפות 65 שניות, הוא נאלץ לכתוב מחדש מלא בכל סיבוב.

רזולוציה קובעת כמה לעיתים זה קורה. שעון שעה וְשְׁרִי תאריך בְּקְרִי הַסִּסְטֶם שניהם קוראים מהמטמון בְּכָל פתיחת סיבוב של 12 של הריצות של 65 שניות, כי אף אחד לא עבר. הם נשברים גם כן, פעם בשעה ופעם ביום. שעון דקה נשבר בכל סיבוב שמתחיל בדקה מאוחרת יותר מהדקה הקודמת.

המטמון עצמו גם פג תוקף. בהריצות חד-זמן, GPT-6 Luna עדיין קרא את הפקדים שלו אחרי 30 דקות של עצירה וכתב את כל הפקודה מחדש ב-1.25× אחרי 60. DeepSeek V4.1 Flash קרא אחרי 10 דקות והחמיץ אחרי 60. Claude Opus 5.5 כבר חצית אחרי 10, מכיוון שמטמון ברירת המחדל של Anthropic נמשך 5 דקות והמטמון של 1 שעות עולה 2× לכתיבה. האדם שמחזור לשיחה ביום הבא, המקרה שהמאמר התחיל בו, מוצא גם זמן ישן וגם מטמון קר בכל שלוש המקרים. הסיבוב הראשון שמחזור משלם עבור כל הפקודה, לא משנה מה המכשיר עושה. הצבה קובעת אם הסיבובים אחרי זה גם כן.

GPT-6 Luna היא תשובת ספק אחת. כדי לראות עד כמה השיעור כללי, הרצתנו את המיקומים האלו על מודל נוכחי אחד מכל אחת מ4 מעבדות, עם קודקוד זהה של 2.5K-token, כל אחד מקובע לספק אחד:

GPT-6 Luna מאחסנת הודעות שלמות. שורה ששונתה מבטלת את ההודעה שמחזיקה אותה ואת הכול אחרי.

Claude Opus 5.5 מאחסנת איפה שהקורא מסמן. מודלי Anthropic מאחסנים רק עד לסימן cache_control שהמערכת מציבה. ללא סימן, אותו קודקוד נרשם במחיר מלא בכל קריאה. עם הסימן במסר המערכת, שעון בתוך אותו בלוק עלה 1.24×, בעוד שעון במסר מערכת שני אחרי זה קרא ב0.08×. המיקום שה-GPT-6 Luna עונשית הוא בטוח ב-Opus. ב-Opus המחיר ההבדל לכל פתיחת סיבוב היה $0.0214 נגד $0.0023. Opus גם ספירה את הקודקוד זהה כ-4,056 tokens כאשר GPT-6 Luna ספירה 2,395, כך שהטקסט זה עולה 1.69× יותר tokens לפני כל מחיר נוחם.

DeepSeek V4.1 Flash מאחסנת בבלוקים של 256-token ומחייבת כלום נוסף לכתיבה. קריאות חזרו במכפילים מדויקים של 256: 2,560 tokens עבור הקודקוד ללא שינוי, 2,304 עם השעון בסוף המסר המערכת. שורה ששונתה עולה רק את הבלוק שמחזיק אותה. קריאות ראשונות נרשמות במחיר קלט פשוט, וקריאות ב0.03–0.04×. על פני 8 ריצות לכל מיקום, 2 קריאות בודדות פספסו את המטמון בסיבוב שהריצה אותה קראה, מה שמראה שהבקשה נופלת על שרת שונה במקום להיות תוצאה של מיקום. נקודת הקצה של DeepSeek היא היחידה OpenRouter מסמן כמאחסן אוטומטית, וההגדרה הפרטית של החשבון שלי סותרת אותה מכיוון שהנקודה הזו מאומנת על תנועה בתשלום. הריצות עברו DeepInfra, שהאחסנה, כמו Fireworks ו-Morph ב-2‑קריאות בדיקה.

Muse Spark 1.3 קוראת את המטמון שלה בתוך לולאת כלי ומפסיקה בתחילת כל סיבוב חדש. החקירות הראשונות שלנו, שמבקשות שאלה חדשה נגד אותו המסר המערכת, סיפקו עד 113 tokens מהמטמון ב-10 קריאות, ב-2.9K , 8.9K ו-19.4K tokens. כאשר שיחה המשך הרחיבה את הבקשה הקודמת, כפי שהלולאת כלי של הסוכן עושה, Muse קרא 2,801 של 2,966 טוקנים וספירה 0.17×. הסיבוב הבא של המשתמש, עם כל ההיסטוריה לפניו, לא קרא כלום. OpenRouter מדווח על שיעור הצלחה של 86.1% עבור Muse בתעבורה חיונית, שמתאים לעומס עבודה שמופעל על ידי לולאות כלים. בתחילת סיבוב השעון אינו משנה עבור Muse, מכיוון שהקריאה מתעלמת בכל מקרה.

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

ציפינו שהפניות המטומנות יענו מהר יותר. על 10 זוגות רציפים של קריאות GPT-6 Luna ב8.5K טוקנים, הקריאה הראשונה הבינונית לקחה 437 ms מהמטמון ו490 ms ללאו. הפער הזה נמצא בתוך התפוצה של הדגימות. בגודל זה, המטמון משנה את עלות הפנייה ומשאיר את משך הזמן כ- אותו דבר.

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

שעון במבקש המערכת נמצא לפני כל השיחה, כך שכל שכתוב מכסה את ההיסטוריה המתפתחת מאחוריו וכן את ההוראות. הנה העלות המדודת של שיחה אחת של 12-פניות GPT-6 Luna, עם החשבונית המלאה של הספק, כולל הפלט והקריאות בתוך כל פנייה:

שתי השורות חולקות את הפנייה הראשונה שלהן, כאשר שניהם כותבים את הזיכרון. מכאן ואילך, כל פנייה עם השעון במבקש המערכת עולה 5.7× מהעלות של אותה פנייה עם השעון בסוף הודעת המשתמש. עד פנייה 12 השיחה סבבה 4.1× כמות, והפער מתרחב עם כל פנייה.

חלקי סנט הופכים לפריט שורה בקנה מידה. פרזוזיה זו מחזירה את הקריאה הראשונה של כל פנייה עבור מוצר שמשרת 10,000 שיחות ביום, כל אחת עם מבקש מערכת של 8.5K טוקנים, 20 פניות, והיסטוריה שמתרחבת ב1,500 טוקנים לכל פנייה. כל מודל משתמש במחירו המופיע ובהתנהגות הקאשינג שהצג למעלה:

הבלוקים של DeepSeek שומרים את פקודת המערכת כאשר השעון משתנה, והמודל עדיין יוצא 13× יקר יותר, מכיוון שההיסטוריה מאחורי השעון עולה על ההוראות בתוך כמה סיבובים. Muse Spark מציג את הצד השני: הוא חסר בתחילת כל סיבוב בהרצאות שלנו, כך שהמיקום לא חסך כלום שם וכל פתיחת סיבוב שילמה את המחיר המלא, $2.1M שנה עבור אותו תעבורה.

המדידות שלנו משתמשות במקדם מבוקר. OpenRouter מפרסם את העלות של אותם מודלים על תנועת כולם, וההסדנה המופיעה שם בקנה מידה. כמעט כל מה שנשלח למודלים אלה הוא קלט: 96.3% של טוקנים של GPT-6 Luna ביום הראשון שלו, 98.5% של Claude Opus 5.5 וה-DeepSeek של V4.1 Flash, ו-98.9% של Muse Spark 1.3. קלט הוא המקום שבו המטמון מתבצע, כך ששיעור ההצלחה קובע את רוב מה שהעסק משלם.

לקוחות שילמו $0.87 למיליון טוקנים קלט עבור Claude Opus 5.5 נגד $4.00 רשום, $0.30 נגד $1.25 עבור Muse Spark 1.3, ו-$0.036 נגד $0.10 עבור GPT-6 Luna. בכל נקודות קצה שמספקות את אותו מודל באותו יום, המחיר ששולם עוקב אחרי שיעור ההצלחה:

קביעת מחיר לכל כשל ככתיבה למטמון וכל הצלחה כקריאה תחזית את מחירי המפורסמים של הנקודות הראשיות של 5 בין 2–13%. רמת ההצלחה בלבד מסבירה את הפיזור. על GPT-6 Luna הדגם זה פועל מ$0.025 בשיעור הצלחה של 88.1% ל$0.075 ב49.4%, גורם של 3.

החלטת המיקום המשותפת נופלת בצורה שונה על כל סוג של ארגון שמבנה על API אלה.

בונים של Harness קובעים את שיעור ההצלחה לכל משתמש בבת אחת. האפליקציות 5 ששולחו Claude Opus 5.5 את התנועה המקסימלית ביום הראשון שלהן היו כל סוכנים, בין 2.9B ל-16.3B טוקנים כל אחד. עבור Harness ב-10B טוקני קלט ביום על המודל הזה, כל נקודת שיעור הצלחה של המטמון שווה $175K בשנה. הפער בין נקודות הקצה 92.2% ל-77.4% לעיל מגיע ל-$2.07M בשנה בנפח זה. שעון בקידוד המערכת שמעדכן כל סיבוב פתיחה עולה בין $1.75M ל-$8.76M בשנה, בהתאם אם פתיחת הסיבובים היא 1 קריאה ב-10 או 1 ב-2. ההחלטה גם מתפשטת: כל מוצר שנבנה על Harness יורש את המיקום שלו. בזמן כתיבת זה מצאנו את אותו שעון בקידוד המערכת ב-harness השני שלנו, שמריץ גרסה ישנה יותר של אותו ראנר.

חברות שמריצות פלטפורמת AI פנימית קובעות זאת לכל צוות מאחוריהן. שער שמחיל את קידוד המערכת של כל בקשה עם תאריך ושעה או מזהה בקשה לאודיט הופך את פתיחת הסיבובים של כל אפליקציה לכתיבה, לא משנה מה הצוותים בונים מעליה. חשבונאות היא החשיפה השנייה. מחויבת בחזרה במחיר הרשימה, עלויות הקלט נראות 2.8× גדולות יותר מהחשבון ב-GPT-6 Luna, 4.1× ב-Muse Spark 1.3 ו-4.6× ב-Claude Opus 5.5. הרישום שלנו חיזרף את קריאות 33 ב-2.7×, ואני התקרבתי לשנות מודלים על סמך זה.

חברות שמפיצות מוצרים AI משלמות זאת בכל שיחה. בתוך שיחה אחת, עלות השעון הלא נכונה היא 5.7× לכל סיבוב. בשוק, הסיכונים גדלים. ב-21 בספטמבר, Muse Spark 1.3 לקחה 88.5B טוקני קלט דרך OpenRouter. במחיר הרשימה זה $110.6K; הלקוחות שילמו $26.9K, וכל נקודת שיעור הצלחה על התנועה הזו שווה $355K בשנה. DeepSeek V4.1 Flash לקחה 2.68T טוקני קלט באותו יום, ובמחירי DeepInfra כל נקודה שווה $1.33M בשנה. המספרים האלה מכסים רוטר אחד. הטראפיק שנשלח לספקים ישירות אינו מופיע בהם.

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

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

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

סף על המספרים הללו פופס את הירידה המפתיעה. שמות הסיבה על פני שבועות של נתונים הוא בעיית סיווג, וקטגוריה חדשה של מודל מתאימה לכך. Jev, מ-TypeSafe, הוא מה שמייצר שלו מכנה מודל System One. הוא אינו יוצר טקסט. הוא מקבל מצב ושאלות מסוג טקסט ומחזיר תשובות מסוג טקסט עם חלוקת הסתברות ואמון: בחירה מבין אפשרויות, הסתברות של כן, או מיקום בסולם מסודר. בהתבסס על פרופיל המטמון היומי של נתיב, הוא יכול לזהות את התבנית שהיום תואם (בריא, פתיחת פניות מחודשת, פג תוקף המטמון בין פניות, תנועה שמגיעה לנקודת קצה שאינה מטמנת) ולומר כמה בטוח, כך ששינוי קטגוריה הופך להתרעה. אנו משתמשים בו בייצור כדי לסווג מסמכים ובצפייה, כדי לדרג פרקים של סוכן שהושלמו. OpenRouter מציין את זה ב$0.042 למיליון טוקנים קלט ללא תשלום עבור פלט. במחיר זה, סיווג פרופיל יומי של 2K טוקנים לכל אחד מ1,000 נתיבים עולה כ-$31 בשנה, לעומת $175K בשנה עבור נקודת שיעור הצלחה אחת בקנה מידה של harness מעל.

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

כל מספר מדוד לעיל מגיע משדות הקריאה של OpenRouter (טוקנים מאוחסנים, טוקנים לכתיבה במטמון והוצאה מחושבת) ב-23 בספטמבר 2026. המספרים השוקיים מגיעים מדפי המודל הציבוריים של OpenRouter שנקראו באותו יום: מחיר קלט משוקלל ששולם בפועל, מחיר אפקטיבי של כל נקודת קצה ושיעור הצלחה במטמון, ויום של פעילות טוקנים לכל מודל. Claude Opus 5.5 ו-GPT-6 Luna נחשפו ב-22 בספטמבר, כך שמספרי הפעילות שלהם מכסים יום ראשון חלקי, והמאמר משתמש בהם רק כיחסי חלקים. ניסיונות הוצאו $0.63 בסך הכל, והחוקר סירב להתחיל ברגע שהשימוש בחשבון הגיע ל$1 קפא. מחירים הם OpenRouter's מחירי רשימה שנקראו באותו יום. מדריך המטמון של OpenRouter מציין OpenAI קריאות מטמון ב-0.25–0.50×; GPT-6 Luna גבשה את קריאותיה ב-0.10×, והמאמר מדווח על מה שנגבה.

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

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

בידי Claude Opus 5.5. הוא מצא שהספר החשבונות שלנו חבוי את המטמון, 2.7× על קריאות 33, והסיק את הסיבה ל2 שורות במבנה המערכת שהשתנו בכל סיבוב. הוא בנה את תיקון הרץ שכעת במוצר, החוקר, האנליזה, ומודל העלות מאחורי כל מספר כאן, והסתגל את המנגנון למספרים השוקיים של OpenRouter. ברחבי מודל 4 זיהה 3 התנהגויות מטמון שונות, כולל התנהגות של GPT-6 Luna של כל ההודעה, ומודל רביעי ללא מטמון שימושי.