Кешування промптів LLM: Зменште витрати на API на 90% (Усі 3 постачальники)

Кешування промптів LLM: Зменште витрати на API на 90% (Усі 3 постачальники)

Кешування промптів LLM дозволяє повторно використовувати раніше оброблені токени між запитами API, знижуючи вхідні витрати до 90% і скорочуючи час до першого токена (TTFT) до 85%. Якщо ви надсилаєте один і той самий системний промпт, визначення інструментів або приклади few-shot у кожному запиті, ви платите повну ціну за роботу, яку GPU вже виконав.

Цей посібник охоплює OpenAI, Anthropic та Gemini з реалізацією одного й того самого чат-бота в усіх трьох SDK, чого не робить жоден інший посібник. Ми також розглянемо оновлення автоматичного кешування від Anthropic за лютий 2026 року, сценарії виробничих витрат із реальними сумами в доларах та антипатерни, які непомітно руйнують ваш показник влучень у кеш (cache hit rate).

Короткий підсумок: огляд усіх трьох постачальників

Перш ніж занурюватися в деталі реалізації, ось повне порівняння. Якщо ви вже знаєте, якого постачальника використовуєте, переходьте до відповідного розділу. Якщо ви проводите оцінку, ця таблиця дасть вам усю необхідну інформацію за 10 секунд.

Ключовий висновок: OpenAI є найпростішим (нульова конфігурація, знижка 50%). Anthropic надає найбільшу знижку (90%) з найбільшим контролем. Gemini пропонує налаштовуваний TTL і неявне кешування на моделях 2.5+ із знижками, порівнянними з Anthropic.

Як працює кешування промптів LLM?

Вам не потрібно розуміти внутрішню будову трансформерів, щоб ефективно використовувати кешування промптів. Але вам потрібно зрозуміти одну концепцію: зіставлення префіксів.

KV-кеш за 60 секунд

Коли LLM обробляє ваш промпт, вона обчислює стани уваги (пари ключ-значення) для кожного токена. Ці записи KV-кешу є дорогою частиною — саме вони споживають пам'ять GPU та обчислювальний час. Кешування промптів зберігає ці обчислені стани, тому наступний запит із тим самим префіксом повністю пропускає повторні обчислення.

Ключове слово — префікс. Кеш зіставляється від початку вашого промпту вперед. Якщо перші 2000 токенів збігаються з записом у кеші, але токен 2001 відрізняється, ці перші 2000 токенів будуть взяті з кешу. Все після точки розходження обчислюється заново.

Ось чому порядок промптів має значення. Структуруйте свої промпти так:

1. Визначення інструментів (найбільш статичні)
2. Системний промпт
3. Статичні приклади few-shot
4. Отриманий контекст (напівдинамічний)
5. Історія розмови (зростає з кожним ходом)
6. Запит користувача (завжди різний)

Статичний контент спереду, динамічний — в кінці. Чим більше токенів збігається з кешованим префіксом, тим більша ваша економія.

Кешування промптів проти семантичного кешування проти кешування відповідей

Ці три терміни постійно плутають. Кешування промптів (те, що охоплює цей посібник) повторно використовує обчислені стани KV на рівні GPU для ідентичних токенних префіксів, без втрати точності, видаючи той самий результат, що й без кешу. Семантичне кешування використовує схожість ембедінгів для повернення раніше згенерованих відповідей на «достаточно схожі» запити; це швидше, але може повертати неправильні відповіді. Кешування відповідей зберігає точні пари вхід-вихід і повертає кешовану відповідь дослівно, працюючи лише для дійсно ідентичних запитів.

Кешування промптів є єдиною «безкоштовною оптимізацією»: воно знижує вартість і затримку без будь-якого компромісу щодо точності. Для глибокого математичного пояснення KV-кешування технічне пояснення Hugging Face виміряло прискорення ~5.21x на GPU T4.

Як OpenAI обробляє кешування промптів?

Кешування промптів у OpenAI повністю автоматичне. З жовтня 2024 року кожен запит API з понад 1,024 вхідними токенами автоматично отримує вигоду від кешування. Вам не потрібно підключати цю функцію, додавати заголовки чи змінювати код.

Як працює автоматичне кешування OpenAI

Коли ви надсилаєте запит щонайменше з 1,024 токенами, OpenAI перевіряє, чи збігається префікс із недавнім запитом від вашої організації. Влучення в кеш коштують 50% від стандартної ціни вхідного токена. Після початкового порогу в 1,024 токена кеш зіставляється блоками по 128 токенів.

Кеш живе 5-10 хвилин під час звичайного використання і може зберігатися до 24 годин із розширеним зберіганням у періоди низького навантаження. Він обмежений рамками організації, тому різні проєкти в межах однієї організації отримують вигоду від спільних кешів.

Підтримувані моделі включають GPT-4o, GPT-4o-mini, GPT-4.1, o1, o3-mini та всі новіші моделі.

Приклад використання Python SDK OpenAI

from openai import OpenAI

client = OpenAI()

# This system prompt is ~2,000 tokens -- well above the 1,024 minimum
SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

def chat(user_message: str) -> str:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": user_message},
        ],
    )

    # Check if caching kicked in
    usage = response.usage
    cached = usage.prompt_tokens_details.cached_tokens
    total_input = usage.prompt_tokens
    print(f"Cached: {cached}/{total_input} tokens ({cached/total_input*100:.0f}%)")

    return response.choices[0].message.content

# First call: cache miss (full price)
chat("Review this async function for race conditions...")

# Second call within 5-10 min: cache hit (50% off on cached tokens)
chat("Now optimize the same function for throughput...")

Перший запит обробляє все за повною ціною і заповнює кеш. Другий запит повторно використовує кешовані токени системного промпту за пів ціни. У виводі ви побачите щось на зразок Cached: 1920/2048 tokens (94%).

Вердикт: OpenAI найпростіший для початку, нульова конфігурація, кешування просто відбувається. Знижка 50% є найнижчою серед трьох постачальників, але за простотою їм немає рівних.

Як Anthropic/Claude обробляє кешування промптів?

Anthropic пропонує два режими: автоматичне кешування (увімкнено за замовчуванням з лютого 2026 року) та явне кешування з точками контролю cache_control. Головна цифра важко ігнорувана: читання з кешу коштує лише 10% від стандартної ціни вхідних даних, тобто знижка 90%.

Автоматичне проти явного кешування (оновлення 2026)

Станом на 5 лютого 2026 року Anthropic увімкнула автоматичне кешування за замовчуванням для всіх придатних промптів. Вам більше не потрібен старий бета-заголовок. Система автоматично визначає оптимальні точки розриву кешу.

Явне кешування все ще доступне, коли вам потрібен детальний контроль. Ви розміщуєте cache_control: {"type": "ephemeral"} у конкретних блоках контенту, щоб точно позначити, де має бути межа кешу. Це корисно, коли ваш промпт має специфічну структуру, і ви хочете гарантувати кешування певних розділів.

Існують два варіанти TTL:

• 5-хвилинний кеш (за замовчуванням): запис коштує 1.25x базової ціни входу, читання коштує 0.1x. Окупається після 1 влучення в кеш.
• 1-годинний кеш: запис коштує 2x базової ціни входу, читання коштує 0.1x. Окупається після 2 влучень у кеш. Доступно на моделях Claude 4.5+.

Ізоляція кешу змінилася з рівня організації на рівень робочого простору (workspace) 5 лютого 2026 року. Це означає, що різні робочі простори в межах однієї організації підтримують окремі кеші.

При роботі з кешуванням Anthropic допомагає структурувати ваш промпт для оптимального кешування; розміщення статичного контенту перед динамічним тут ще важливіше, оскільки ви сплачуєте премію за запис.

Приклад використання Python SDK Anthropic

import anthropic

client = anthropic.Anthropic()

SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

def chat(user_message: str) -> str:
    response = client.messages.create(
        model="claude-sonnet-4-5-20250514",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": SYSTEM_PROMPT,
                "cache_control": {"type": "ephemeral"},  # Explicit breakpoint
            }
        ],
        messages=[
            {"role": "user", "content": user_message},
        ],
    )

    # Read cache metrics from the response
    usage = response.usage
    created = usage.cache_creation_input_tokens
    read = usage.cache_read_input_tokens
    standard = usage.input_tokens
    print(f"Cache write: {created}, Cache read: {read}, Standard: {standard}")

    return response.content[0].text

# First call: cache_creation_input_tokens = ~1920 (write at 1.25x)
chat("Review this async function for race conditions...")

# Second call: cache_read_input_tokens = ~1920 (read at 0.1x -- 90% off!)
chat("Now optimize the same function for throughput...")

Розуміння ціноутворення: запис у кеш проти читання з кешу

Саме тут ціноутворення Anthropic стає цікавим. Використовуючи Claude Sonnet 4.5 ($3/MTok базовий вхід) як приклад:

• Стандартний вхід: $3.00 за мільйон токенів
• Запис у кеш (5 хв): $3.75 за мільйон токенів (1.25x), ви платите більше першого разу
• Читання з кешу: $0.30 за мільйон токенів (0.1x) — на 90% дешевше при кожному наступному влученні

5-хвилинний кеш окупається всього після 1 читання. 1-годинний кеш ($6.00/MTok запис) окупається після 2 читань. Якщо ви робите більше кількох запитів на хвилину з тим самим префіксом, математика однозначно на вашому боці.

Вердикт: Anthropic надає найбільшу знижку (90%) і найбільший контроль. Найкращий вибір для високонавантажених завдань, чутливих до витрат.

Як Google Gemini обробляє кешування промптів?

Gemini використовує інший підхід з двома різними механізмами кешування: явне контекстне кешування (найменовані об'єкти кешу, які ви створюєте та на які посилаєтеся) і неявне кешування (автоматичне, без конфігурації, додане в 2026 році для моделей Gemini 2.5+).

Явне контекстне кешування (найменовані кеші)

На відміну від OpenAI та Anthropic, де кешування є прозорим, явне кешування Gemini вимагає спочатку створити найменований об'єкт кешу, а потім посилатися на нього в наступних запитах. Мінімальний поріг токенів становить 1,024 токени для моделей Gemini Flash і 4,096 токенів для моделей Pro. TTL налаштовується, за замовчуванням — 1 година, але ви можете встановити будь-яке необхідне значення.

Кешовані токени на Gemini 2.5 Pro коштують $0.125/MTok проти стандартної ціни входу $1.25/MTok, що становить знижку 90%. Також існує вартість зберігання $4.50 за мільйон токенів на годину для Pro і $1.00 для Flash.

Неявне кешування в Gemini 2.5 (2026)

Починаючи з Gemini 2.5 Pro та Flash, Google додав неявне кешування — автоматичне кешування, яке працює подібно до підходу OpenAI. Конфігурація не потрібна. Розмістіть великий, загальний контент на початку вашого промпту і надсилайте запити з подібними префіксами швидко один за одним. Система автоматично виявляє контент, придатний для кешування, і передає заощадження.

Приклад використання Python SDK Gemini

from google import genai
from google.genai import types

client = genai.Client()

SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

# Step 1: Create a named cache object
cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        display_name="python-review-guidelines",
        system_instruction=SYSTEM_PROMPT,
        ttl="3600s",  # 1 hour
    ),
)

print(f"Cache created: {cache.name}, expires: {cache.expire_time}")

# Step 2: Use the cache in requests
response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="Review this async function for race conditions...",
    config=types.GenerateContentConfig(
        cached_content=cache.name,
    ),
)

# Check cache usage in the response
metadata = response.usage_metadata
print(f"Cached tokens: {metadata.cached_content_token_count}")
print(f"Total input tokens: {metadata.prompt_token_count}")

Явний підхід має одну велику перевагу: ви точно контролюєте TTL. Якщо ви знаєте, що ваше пакетне завдання виконується протягом 4 годин, встановіть 4-годинний TTL і уникайте закінчення терміну дії кешу посеред процесу.

Вердикт: Налаштовуваний TTL Gemini та подвійні режимы кешування (явний + неявний) роблять його універсальним. Мінімальний поріг тепер порівнянний з іншими постачальниками, а знижка 90% на читання з кешу відповідає Anthropic.

Порівняння коду пліч-о-пліч: той самий випадок використання, усі 3 постачальники

Ось той самий чат-бот із кешованим системним промптом, реалізований у всіх трьох SDK. Порівняйте досвід розробника безпосередньо.

# --- OpenAI: Zero config, just call the API ---
from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},  # Cached automatically
        {"role": "user", "content": user_message},
    ],
)
cached = response.usage.prompt_tokens_details.cached_tokens

# --- Anthropic: Explicit cache_control breakpoint ---
import anthropic
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},  # Mark cache boundary
    }],
    messages=[{"role": "user", "content": user_message}],
)
cached = response.usage.cache_read_input_tokens

# --- Gemini: Named cache object ---
from google import genai
from google.genai import types

client = genai.Client()
cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        system_instruction=SYSTEM_PROMPT,
        ttl="3600s",
    ),
)
response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=user_message,
    config=types.GenerateContentConfig(cached_content=cache.name),
)
cached = response.usage_metadata.cached_content_token_count

Якщо ви хочете економії без зусиль, обирайте OpenAI. Якщо вам потрібна найбільша знижка та детальний контроль, обирайте Anthropic. Якщо вам потрібні налаштовувані терміни життя кешу або ви вже використовуєте Google Cloud, обирайте Gemini.

Калькулятор виробничих витрат: реальна економія в масштабі

Абстрактні відсотки не керують рішеннями. Долари — так. Ось три виробничі сценарії з реальною оцінкою витрат, використовуючи Claude Sonnet 4.5 ($3/MTok вхід), GPT-4o ($2.50/MTok вхід) та Gemini 2.5 Pro ($1.25/MTok вхід).

Ціни перевірено в березні 2026 року. Перевірте ціни Anthropic, ціни OpenAI та ціни Gemini для актуальних тарифів.

Припущення: 80% влучень у кеш (реалістично для добре структурованих промптів), вихідні токени виключено, оскільки кешування впливає лише на вхідні витрати.

На рівні зростання кешування Anthropic економить $576/місяць, незважаючи на вищу базову ціну, ніж у OpenAI. На корпоративному рівні ви дивитесь на $7,200/місяць економії з Anthropic, або $86,400 на рік. Це зарплата старшого інженера, заощаджена завдяки зміні конфігурації.

Закономірність очевидна: чим більший обсяг ваших запитів і чим довший ваш статичний префікс, тим більше економить кешування. Знижка 90% від Anthropic домінує в масштабі, але нижча базова ціна Gemini робить її конкурентоспроможною, якщо враховувати загальну вартість.

Антипатерни кешування промптів: коли НЕ варто кешувати

Кешування здається простим, поки ваш показник влучень у кеш таємничим чином не опиниться на рівні 0%. Ось помилки, які непомітно ламають кешування промптів, і способи їх виправлення.

Помилки, що руйнують кеш (із виправленнями)

Мітки часу в системних промптах. Найпоширеніша помилка. Якщо ваш системний промпт містить datetime.now(), ключ кешу змінюється кожну секунду.

# BAD: Cache misses every single request
system_prompt = f"""You are a helpful assistant.
Current time: {datetime.now().isoformat()}
Always be helpful and accurate."""

# GOOD: Move the timestamp to the user message
system_prompt = """You are a helpful assistant.
Always be helpful and accurate."""

user_message = f"[Current time: {datetime.now().isoformat()}]\n{user_query}"

Контент, специфічний для користувача, перед статичним контентом. Якщо ви розміщуєте session_id або уподобання користувача на початку, кожен користувач отримує унікальний префікс.

# BAD: Unique prefix per user = zero cache reuse
messages = [
    {"role": "system", "content": f"User ID: {user_id}\nPreferences: {prefs}\n{GUIDELINES}"},
    {"role": "user", "content": query},
]

# GOOD: Static content first, user context at the end
messages = [
    {"role": "system", "content": GUIDELINES},  # Same for all users -> cached
    {"role": "user", "content": f"Context: User {user_id}, prefs: {prefs}\n{query}"},
]

Коли кешування промптів дійсно не допомагає

Деякі сценарії не отримають вигоди від кешування, навіть якщо ви ідеально структуруєте свої промпти:

• Промпти одноразового використання: Якщо кожен запит має абсолютно унікальний контекст і немає спільного префіксу, кешувати нічого.
• Дуже короткі промпти: Менше 1,024 токенів (OpenAI/Anthropic) або 4,096 токенів (Gemini Pro), кешування не активується.
• Рідкісні запити: Якщо запити надходять з інтервалом у години, кеш застаріває до надходження другого запиту. Вікно 5-10 хвилин у OpenAI та TTL 5 хвилин за замовчуванням у Anthropic означають, що вам потрібен стабільний трафік.

Чи працює кешування промптів із потоковою передачею?

Так. Кешування промптів і потокова передача є незалежними: кешування працює з вхідними токенами, потокова передача впливає на доставку виходу. Вони вирішують різні проблеми на різних етапах життєвого циклу запиту.

Кеш обробляє фазу заповнення (prefill) (обробка вашого вхідного промпту). Потокова передача обробляє фазу декодування (генерація та поступова відправка вихідних токенів). Ви отримуєте обидві переваги одночасно: швидше заповнення завдяки влученню в кеш плюс прогресивна доставка виходу завдяки потоковій передачі.

Ось приклад потокової передачі з увімкненим кешуванням:

import anthropic

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": "Explain Python's GIL..."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

    # After streaming completes, check cache metrics
    usage = stream.get_final_message().usage
    print(f"\nCache read: {usage.cache_read_input_tokens} tokens")

Покращення TTFT від кешування насправді найбільш помітне саме з потоковою передачею. Без кешування ви чекаєте повного заповнення, перш ніж перший токен повернеться потоком. З кешуванням заповнення майже миттєве, тому токени починають надходити майже відразу.

Як моніторити показники влучень у кеш у виробництві

Налаштування кешування — це половина битви. Знання того, чи він дійсно працює, — інша половина. Якщо ваш показник влучень у кеш падає нижче 50%, щось змінилося у структурі вашого промпту, і ви втрачаєте гроші.

Специфічні метрики кешу для постачальників

Простий логер показників влучень у кеш

Ось службова функція, яку ви можете додати в будь-який проєкт, щоб відстежувати показники влучень у кеш через поля відповіді API:

import logging

logger = logging.getLogger("cache_monitor")

def log_cache_metrics(provider: str, usage: dict) -> float:
    """Extract and log cache metrics from any provider's response. Returns hit rate."""

    if provider == "openai":
        cached = getattr(usage.prompt_tokens_details, "cached_tokens", 0)
        total = usage.prompt_tokens
    elif provider == "anthropic":
        cached = usage.cache_read_input_tokens
        created = usage.cache_creation_input_tokens
        total = cached + created + usage.input_tokens
    elif provider == "gemini":
        cached = getattr(usage, "cached_content_token_count", 0)
        total = usage.prompt_token_count
    else:
        raise ValueError(f"Unknown provider: {provider}")

    hit_rate = (cached / total * 100) if total > 0 else 0
    logger.info(f"[{provider}] Cache hit rate: {hit_rate:.1f}% ({cached}/{total} tokens)")

    if hit_rate < 50:
        logger.warning(f"[{provider}] Low cache hit rate! Check prompt structure.")

    return hit_rate

Здорова виробнича система повинна підтримувати 70-90% влучень у кеш. Якщо ви нижче 50%, перегляньте розділ антипатернів. Ви також можете інтегрувати це з автоматизованими метриками оцінки, щоб виявляти регресії у вашому пайплайні промптів.

Кешування промптів у реальних випадках використання

Приклади чат-ботів вище ілюструють механіку, але кешування промптів дійсно сяє в конкретних архітектурних патернах.

Пайплайни RAG

У налаштуванні RAG ваш системний промпт та приклади few-shot є статичними для всіх запитів. Отримані документи змінюються щоразу. Структуруйте свій промпт, щоб максимізувати кешований префікс:

1. Системний промпт (кешований)
2. Приклади few-shot (кешовані)
3. Отримані документи (динамічні, йдуть останніми)
4. Запит користувача (завжди унікальний)

З системним промптом на 5,000 токенів і 3,000 токенів прикладів few-shot, це 8,000 токенів кешуються в кожному запиті. При 1,000 запитів/день на Anthropic ви заощадите приблизно $6.50/день лише на кешованому префіксі. Коли ви отримуєте та кешуєте блоки контексту, переконайтеся, що результат отримання йде після статичного префіксу.

Багатоходові чат-боти

Багатоходові розмови є ідеальним місцем для кешування промптів. Кожен хід додається до історії розмови, але вся попередня розмова вже кешована з попередніх ходів. Вигода від кешу накопичується: до 10-го ходу у вас може бути 15,000 токенів кешованої історії з лише 200 новими токенами з останнього повідомлення користувача.

Агентні системи та визначення інструментів MCP

Якщо ви будуєте агентів із використанням інструментів, ваші визначення інструментів є статичними JSON-схемами, що повторюються в кожному окремому запиті API. Типовий агент може мати 20+ інструментів, що сумарно дають 3,000-5,000 токенів визначень. Це ідеальний матеріал для кешування.

Це особливо актуально для архітектур на основі MCP, де визначення інструментів сервера надсилаються в кожному запиті. З явним cache_control від Anthropic ви можете позначити масив tools для кешування та гарантувати повторне використання цих токенів.

Якого постачальника обрати?

Якщо ви вже використовуєте одного постачальника, почніть з нього — кешування промптів не вимагає перемикання. LiteLLM діє як проксі-шар, який нормалізує параметри кешування між постачальниками, що корисно, якщо ви маршрутизуєте запити до кількох моделей.

FAQ: Кешування промптів LLM

Що таке кешування промптів у LLM?

Кешування промптів зберігає обчислені стани уваги (KV-кеш) з раніше оброблених префіксів промптів. Коли наступний запит починається з тієї ж послідовності токенів, постачальник повторно використовує ці збережені стани замість їх повторного обчислення, знижуючи як вартість, так і затримку без впливу на якість виходу.

Скільки економить кешування промптів на витратах API?

Економія становить від 50% до 90% залежно від постачальника. OpenAI пропонує знижку 50% на кешовані вхідні токени. Anthropic пропонує до 90% знижки (читання з кешу за 0.1x базової ціни). Gemini пропонує приблизно 90% знижки на читання з кешу. Реальна економія залежить від вашого показника влучень у кеш, довжини промпту та частоти запитів.

Чи відбувається кешування промптів OpenAI автоматично?

Так, з жовтня 2024 року. Будь-який запит API з понад 1,024 вхідними токенами автоматично отримує вигоду від кешування. Не потрібно підключати, немає заголовків, зміни коду не потрібні. Кеш зіставляє токенні префікси від початку промпту.

Яка різниця між кешуванням промптів і семантичним кешуванням?

Кешування промптів зіставляє точні токенні префікси на рівні GPU, немає втрати точності, а виходи ідентичні запитам без кешу. Семантичне кешування використовує схожість ембедінгів для пошуку «достаточно близьких» попередніх запитів і повертає кешовані відповіді; це швидше, але може повертати неправильні або застарілі відповіді. Вони вирішують фундаментально різні проблеми.

Як довго живе кеш промптів?

Це залежить від постачальника. OpenAI: 5-10 хвилин (до 24 годин із розширеним зберіганням). Anthropic: 5 хвилин (за замовчуванням) або 1 година (доступно на моделях Claude 4.5+, коштує 2x запис). Gemini: налаштовується, за замовчуванням 1 година для явних кешів. TTL неявного кешування автоматично керується Google.

Яка мінімальна довжина токенів для кешування промптів?

OpenAI: 1,024 токени. Anthropic: 1,024 токени для більшості поточних моделей. Gemini: 1,024 токени для моделей Flash, 4,096 для моделей Pro. Промпти нижче цих порогів не активують кешування — це найпоширеніша причина «це не працює».

Чи працює кешування промптів із потоковими відповідями?

Так. Кешування та потокова передача працюють на різних фазах запиту. Кешування прискорює фазу заповнення входу; потокова передача доставляє вихідні токени поступово. Обидва працюють одночасно, і ви навіть помітите покращення TTFT більше з увімкненою потоковою передачею.

Коли НЕ слід використовувати кешування промптів?

Уникайте покладання на кешування, коли ваші промпти нижче мінімального порогу токенів, коли ви включаєте мітки часу або ID сесій у системний промпт, коли ви ротуєте приклади few-shot між викликами або коли запити надходять занадто рідко, щоб влучити в кеш до його закінчення терміну дії (вікно 5-10 хвилин для OpenAI/Anthropic).

Чи можна використовувати кешування промптів з LangChain або LiteLLM?

Так. LangChain передає специфічні для постачальника параметри кешування через свої API-обгортки. LiteLLM надає уніфікований синтаксис кешування, який нормалізує cache_control між Anthropic, OpenAI, Gemini, Vertex AI та Bedrock, що особливо корисно для налаштувань з кількома постачальниками.

Що таке влучення в кеш проти промаху кешу?

Влучення в кеш означає, що постачальник знайшов відповідний префікс у пам'яті та повторно використав збережені стани KV, ви платите за зниженою ставкою кешованих токенів і отримуєте швидший TTFT. Промах кешу означає, що збігу не знайдено, тому весь промпт обробляється з нуля за стандартними цінами. Перевірте поля cached_tokens (OpenAI), cache_read_input_tokens (Anthropic) або cachedContentTokenCount (Gemini) у відповіді API, щоб побачити, що сталося.

Остаточний вердикт

Кешування промптів — це оптимізація з найменшими зусиллями та найвищою віддачею в стеку API LLM. Ви не змінюєте свою модель, не жертвуєте якістю, а реалізація варіюється від «нічого не робити» (OpenAI) до «додати одне поле» (Anthropic) або «створити об'єкт кешу» (Gemini).

Почніть з автоматичного кешування вашого поточного постачальника. Виміряйте свій показник влучень у кеш за допомогою наведеної вище утиліти логування. Якщо ви нижче 70%, реструктуруйте свої промпти (спочатку статичні, в кінці динамічні) та усуньте антипатерни. Більшість команд бачать зниження витрат на 50-80% протягом дня після впровадження цих змін.

Джерела

• Документація Anthropic щодо кешування промптів
• Посібник OpenAI з кешування промптів
• Документація Gemini щодо контекстного кешування
• Ціни на моделі Anthropic
• Ціни API Gemini
• Пояснення KV-кешування, блог Hugging Face
• Документація LiteLLM щодо кешування промптів