כאשר LLM מעבד prompt, הוא בונה ייצוג פנימי שנקרא KV cache (Key-Value cache) — מטריצות נומריות שמייצגות את ה-attention state של המודל אחרי עיבוד הטוקנים. עד 2024, המידע הזה נזרק אחרי כל בקשה. די בזבזני, אם תחשבו על זה.
ב-2026, ספקי ה-API משאירים את ה-KV cache בזיכרון (או על GPU-local storage) ומאפשרים לבקשה הבאה להתחיל מהמצב הזה במקום מאפס.
התוצאה? זמן השהיה (latency) נמוך ב-עד 80% ועלות נמוכה ב-עד 90% עבור החלק החוזר של ה-prompt. בארכיטקטורות סוכן (agent), RAG, או chatbots עם system prompt ארוך — הרווח פשוט עצום.
מתי Prompt Caching באמת רלוונטי
- System prompts ארוכים — instructions של 2,000-50,000 טוקנים שחוזרים על עצמם בכל בקשה
- Few-shot examples — בלוק דוגמאות סטטי שמוזרק לכל קריאה
- RAG עם הקשר קבוע — מסמכי policy או תיעוד שמופיעים בכל query
- סוכנים עם conversation history — ה-history גדל, אבל הראש שלו זהה לכל הקריאות
- ניתוח מסמכים ארוכים — שאלות מרובות על אותו מסמך של 100K+ טוקנים
הכלל המרכזי בכל שלושת הספקים זהה: Caching מבוסס על prefix matching בלבד. במילים אחרות — התוכן הקבוע חייב להיות בתחילת ה-prompt, והתוכן המשתנה (שאלת המשתמש) בסוף. נשמע פשוט, אבל ראיתי לא מעט צוותים שמפספסים את זה ותוהים למה ה-hit rate שלהם תקוע על 3%.
Anthropic Claude: Prompt Caching עם בקרה מפורשת
Anthropic הייתה הראשונה שהציגה caching מובהק (explicit) ב-2024, וב-2026 המנגנון כבר בשל ובוגר. אתם מציינים במפורש אילו בלוקים לקאש באמצעות cache_control — בלי קסמים, בלי ניחושים.
מבנה התמחור (נכון למאי 2026)
| סוג טוקן | מכפיל המחיר הבסיסי |
|---|
| קלט רגיל (base input) | 1.0× |
| Cache write — 5 דקות TTL | 1.25× |
| Cache write — 1 שעה TTL (Extended) | 2.0× |
| Cache read (כל TTL) | 0.1× (הנחה של 90%) |
המשמעות המעשית: הקריאה הראשונה תעלה לכם יותר מקריאה רגילה (בגלל ה-write premium), אבל כל קריאה חוזרת בתוך ה-TTL תעלה רק 10% מהמחיר הבסיסי. כן, אני יודע, זה מרגיש קצת מוזר בהתחלה — אבל המתמטיקה עובדת, ועוד איך.
דוגמת קוד: Claude Sonnet 4.6 עם Prompt Caching
from anthropic import Anthropic
client = Anthropic()
LONG_SYSTEM_PROMPT = open("legal_policy.txt").read() # 20,000 tokens
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=[
{
"type": "text",
"text": "You are a legal compliance assistant."
},
{
"type": "text",
"text": LONG_SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral", "ttl": "5m"}
}
],
messages=[
{"role": "user", "content": "Is GDPR Article 17 applicable here?"}
]
)
usage = response.usage
print(f"Cache creation tokens: {usage.cache_creation_input_tokens}")
print(f"Cache read tokens: {usage.cache_read_input_tokens}")
print(f"Regular input tokens: {usage.input_tokens}")
Extended Cache של שעה — מתי באמת משתלם
החל מ-2026, Anthropic מציעה TTL של שעה במחיר write של 2.0× במקום 1.25×. וכאן יש מלכודת אמיתית: בין סוף פברואר לתחילת מרץ 2026, ברירת המחדל של ה-TTL ירדה בשקט מ-1h ל-5m. השינוי הזה גרם לעלייה של 20-32% בעלויות cache creation עבור משתמשים שלא ציינו TTL מפורש (כן, גם אצלי בחשבון, ולקח לי שבוע להבין למה).
הכלל הברזל: אם אתם משתמשים ב-Extended Cache, ציינו תמיד "ttl": "1h" במפורש. אל תסמכו על ברירות מחדל בנושאים שעולים כסף.
קצת מתמטיקה — נוסחת break-even ל-Extended Cache: השעה משתלמת אם מספר הקריאות החוזרות בתוך שעה גדול מ-(2.0 − 1.25) / (1.0 − 0.1) = כ-0.83. במילים פשוטות, אם תקבלו קריאה חוזרת אחת בנוסף לזו שכתבה את ה-cache, ה-1h כבר משתלם — בתנאי כמובן ש-5m לא יספיק.
Workspace Isolation (פברואר 2026)
מאז 5 בפברואר 2026, ה-cache מבודד ברמת ה-workspace ולא ברמת הארגון. אם יש לכם מספר workspaces ב-Console, כל אחד מהם מקבל cache נפרד. זה משפיע במיוחד על ארגונים שמשתפים system prompts בין צוותים — שווה לשקול לאחד workspaces כדי למקסם hit rate. (זה לא נושא סקסי, אבל זה החלק שמשפיע על החשבון בסוף החודש.)
OpenAI: Caching אוטומטי וחינמי
הגישה של OpenAI שונה לחלוטין: אין קוד שצריך להוסיף, ואין עלות נוספת על ה-write. כל בקשה בת 1,024 טוקנים או יותר נכנסת לקאש אוטומטית, וההנחה ניתנת לקריאות עוקבות באופן שקוף. די מגניב, האמת.
מבנה התמחור
- Cache write: 1.0× (אותה עלות כמו קלט רגיל — אין פרמיה)
- Cache read: 0.1× (90% הנחה) על מודלים מודרניים כמו GPT-5.4 ו-GPT-5.5
- סף מינימלי: 1,024 טוקנים. cache נשמר ב-increments של 128 טוקנים מעבר לכך
- TTL ברירת מחדל: כ-5-10 דקות in-memory, אך GPT-5.5 ו-GPT-5.5-pro תומכים ב-Extended Cache של עד 24 שעות דרך offload ל-GPU-local storage
דוגמת קוד: GPT-5.5 עם caching אוטומטי
from openai import OpenAI
client = OpenAI()
SYSTEM = (
"You are a senior Python code reviewer.\n"
+ open("style_guide.md").read() # 8,000 tokens of stable content
)
response = client.chat.completions.create(
model="gpt-5.5",
messages=[
{"role": "system", "content": SYSTEM},
{"role": "user", "content": "Review this function:\n" + user_code}
]
)
# Inspect cache usage
usage = response.usage
cached = usage.prompt_tokens_details.cached_tokens
print(f"Total prompt tokens: {usage.prompt_tokens}")
print(f"Cached tokens: {cached}")
print(f"Cache hit ratio: {cached / usage.prompt_tokens:.1%}")
אופטימיזציה ל-Cache Hit Rate
מאחר ש-OpenAI לא נותנת לכם בקרה מפורשת, כל ה-leverage שלכם נמצא במבנה ה-prompt:
- Static-first: הציבו system prompt, few-shot examples, ו-tools definitions בתחילת הבקשה
- הימנעו מ-timestamps ב-system prompt — אפילו תאריך משתנה הורס לכם את ה-prefix match לחלוטין
- נרמלו whitespace ו-newlines — שינוי של רווח בודד יכול לשבור את ההתאמה (כן, באמת)
- גודל בלוק: חבילות של 1,024+ טוקנים יציבות נותנות הכי הרבה ערך
Google Gemini: Implicit + Explicit Caching
Gemini בחרה בגישה ההיברידית, ולדעתי האישית זה אחד הדברים החכמים שהם עשו: Implicit Caching אוטומטי (כמו OpenAI) ובמקביל Explicit Caching מפורש (כמו Anthropic) — אתם בוחרים.
Implicit Caching (אוטומטי)
פעיל כברירת מחדל בכל מודלי Gemini 2.5 ומעלה. אם בקשה חולקת prefix עם בקשה קודמת — אתם מקבלים הנחה אוטומטית של 90% על הטוקנים החוזרים, ללא שום עלות אחסון. ממש בחינם.
Explicit Caching (מפורש)
נותן ערובה לחיסכון תמורת תשלום אחסון נפרד. אתם מעלים את ה-context פעם אחת, מקבלים cached_content_id, ומפנים אליו בבקשות עוקבות.
דוגמת קוד: Explicit Caching ב-Gemini 2.5 Pro
from google import genai
from google.genai.types import CreateCachedContentConfig
import datetime
client = genai.Client()
# Step 1 — create the cache (one-time, paid per token + storage TTL)
cache = client.caches.create(
model="gemini-2.5-pro",
config=CreateCachedContentConfig(
system_instruction="You are a financial analyst.",
contents=[long_10k_report], # ~100,000 tokens
ttl=datetime.timedelta(hours=2)
)
)
# Step 2 — reuse across many queries
for question in user_questions:
response = client.models.generate_content(
model="gemini-2.5-pro",
contents=question,
config={"cached_content": cache.name}
)
print(response.text)
# Inspect usage
print(response.usage_metadata.cached_content_token_count)
חישוב Break-Even ל-Explicit Caching
ל-Gemini 2.5 Flash, נדרשות בערך 4 שאילתות בשעה לכל מיליון טוקנים בקאש כדי שה-explicit cache ישתלם מעל ה-implicit. מתחת לסף הזה — היצמדו ל-implicit (אין עלות אחסון) או פשוט דלגו על caching לגמרי אם ה-context שלכם קטן מ-32K טוקנים. אין סיבה להסתבך.
השוואה ישירה: Claude vs OpenAI vs Gemini
| קריטריון |
Anthropic Claude |
OpenAI GPT |
Google Gemini |
| סוג ברירת מחדל | Explicit | Implicit (אוטומטי) | Implicit + Explicit |
| Cache write premium | 1.25× / 2.0× | 1.0× (ללא פרמיה) | 1.0× implicit / מחיר אחסון explicit |
| Cache read discount | 90% | 90% (במודלים חדשים) | 90% (2.5+) / 75% (2.0) |
| מינימום טוקנים | 1,024 (sonnet/opus) | 1,024 | אין מינימום נוקשה (implicit), 4,096 explicit |
| TTL סטנדרטי | 5 דקות | ~5-10 דקות | משתנה (implicit), מוגדר משתמש (explicit) |
| TTL מורחב | 1 שעה (2.0× write) | 24 שעות (GPT-5.5+) | עד ימים (explicit, חיוב אחסון) |
| בידוד | Workspace (פברואר 2026) | ארגון | פרויקט |
| שליטת מפתח | גבוהה | נמוכה | גבוהה (explicit) |
הנדסת prompt לאופטימיזציית cache hits
בלי קשר לספק, הכלל הקובע הוא prefix stability. ארגון ה-prompt צריך להיראות כך:
- System instructions (קבוע)
- Tools / Function definitions (קבוע)
- Few-shot examples (קבוע)
- Reference documents / RAG context (סטטי-מקובץ)
- Conversation history (גדל, אך הראש שלו יציב)
- User input הנוכחי (משתנה — בסוף בלבד)
טעויות נפוצות שמייקרות את החשבון
- טבעת timestamp בכל קריאה ב-system prompt — שובר את ה-prefix lock לחלוטין (זו הטעות מספר 1 שאני רואה)
- שינוי סדר tools dynamically — קריאה מבוססת JSON שמסדרת keys באקראיות
- חוסר ציון TTL מפורש ב-Anthropic אחרי שינוי ברירת המחדל של מרץ 2026
- בלוקי cache קטנים מ-1,024 טוקנים — פשוט לא נכנסים לקאש בכלל
- פיצול ה-context בין tools ו-system prompt במקום ריכוז ברצף אחד
- הפעלת Extended Cache (1h) לעומסים שמתחדשים בתוך 5 דקות — תשלום פרמיה ללא תועלת
מדידה ו-Observability של Cache Performance
בלי מדידה, אין אופטימיזציה. נקודה. כל ספק חושף שדות שונים ב-response:
# Anthropic
usage.cache_creation_input_tokens # tokens written
usage.cache_read_input_tokens # tokens hit
# OpenAI
usage.prompt_tokens_details.cached_tokens
# Gemini
response.usage_metadata.cached_content_token_count
המדד היחיד שבאמת משנה הוא cache hit ratio — אחוז הטוקנים שנקראו מהקאש מתוך סך טוקני הקלט. יעד ייצור סביר: ≥ 70% עבור chatbots ו-RAG, ו-≥ 90% עבור סוכנים ארוכי-טווח.
אינטגרציה עם OpenTelemetry GenAI semantic conventions (יציבה ב-2026) מאפשרת לעקוב אחרי המדד הזה ב-Langfuse, Arize Phoenix, או Datadog ולקבל התראות כשהיחס יורד — סימן ברור שמישהו שבר את ה-prefix stability. ולא, זה כמעט אף פעם לא קסם — תמיד יש סיבה.
אסטרטגיית בחירת ספק לפי דפוס שימוש
| דפוס שימוש | בחירה מומלצת | סיבה |
|---|
| תעבורה לא צפויה / hit rate לא יציב | OpenAI | ללא פרמיה על write → אין סיכון |
| סוכן עם system prompt גדול וקבוע | Anthropic + 1h cache | שליטה גבוהה, ROI ברור |
| ניתוח מסמך 1M+ טוקנים מספר פעמים | Gemini Explicit | תמיכה ב-context ענק + הנחה מובטחת |
| צ'אט עם conversation arc ארוך | OpenAI GPT-5.5+ (24h) | TTL ארוך מכסה משתמשים גם אחרי הפסקות |
| חיוב הוצאה מקסימלית לחיזוי | Anthropic או Gemini Explicit | תמחור explicit ניתן לחיזוי מראש |
שאלות נפוצות (FAQ)
האם Prompt Caching שומר את ה-prompts שלי?
לא במובן של אחסון טקסט. כל שלושת הספקים שומרים רק את ה-KV cache הפנימי של המודל — מטריצות נומריות שאינן שחזירות לטקסט המקורי. Anthropic מציינת במפורש שה-caching עומד בתקני ZDR, ו-OpenAI מבודדת ברמת ארגון. אין שיתוף בין ארגונים.
למה הקריאה הראשונה שלי יקרה יותר עם caching ב-Claude?
הסיבה היא ה-write premium של 1.25× (TTL של 5 דקות) או 2.0× (1 שעה). הקריאה הראשונה משלמת את הפרמיה כדי לכתוב ל-cache. החל מהקריאה השנייה תוך ה-TTL, העלות יורדת ל-10%. ב-OpenAI אין פרמיה כזו, ולכן הקריאה הראשונה זהה בעלותה לקריאה ללא caching.
האם Prompt Caching עובד עם streaming responses?
כן, בכל שלושת הספקים. Caching משפיע רק על עיבוד הקלט (prefill phase), בעוד streaming מתייחס לטוקני הפלט. תקבלו hit על ה-prefix גם בבקשות streaming, וזמן הטוקן הראשון (TTFT) ישתפר משמעותית.
מה ההבדל בין Implicit ל-Explicit Caching ב-Gemini?
Implicit פעיל אוטומטית, ללא עלות אחסון, אך גם ללא ערובה — אם השרת לא מצא prefix match אחרון, אין הנחה. Explicit מבטיח הנחה תמורת תשלום אחסון לפי TTL. השתמשו ב-implicit לפרוטוטיפים ובתעבורה משתנה; ב-explicit לעומסי ייצור צפויים מעל 32K טוקנים עם 4+ קריאות בשעה למיליון טוקנים בקאש.
איך אני יודע אם ה-cache באמת hit?
בדקו את שדות ה-usage בתגובה: cache_read_input_tokens ב-Anthropic, prompt_tokens_details.cached_tokens ב-OpenAI, ו-usage_metadata.cached_content_token_count ב-Gemini. אם הערך 0 על אף ש-prompt דומה נשלח לפני רגע — הפרק קצר מ-1,024 טוקנים, ה-TTL פג, או ה-prefix נשבר על ידי שינוי קטן (whitespace, timestamp, סדר tools).
סיכום
Prompt Caching אינו אופטימיזציה מיקרו — זו הקפיצה הגדולה ביותר ביחס עלות/ביצוע באפליקציות LLM בשנתיים האחרונות. נקודה. ההבדלים בין הספקים אמיתיים: Anthropic נותנת שליטה מקסימלית עם פרמיה על write; OpenAI מציעה automation ללא סיכון אך עם פחות שקיפות; Gemini משלבת את שתי הגישות עם תמיכה ב-context ענק.
הכלל המעשי, אחרי שראיתי המון אפליקציות LLM בייצור: מדדו hit ratio, ארגנו prompts לפי הסדר static-first, ובחרו TTL לפי דפוס השימוש האמיתי שלכם — לא לפי תחושת בטן. צוותים שעושים את זה נכון מורידים חשבוני LLM ב-60-85% תוך שבועות, לא חודשים.
