Prompt Caching в LLM API: сравнение OpenAI, Anthropic, DashScope и DeepSeek

Все основные LLM API провайдеры теперь кэшируют повторяющиеся prompt prefix, но реализации принципиально различаются. OpenAI кэширует автоматически, а с GPT-5.6 добавил explicit breakpoints с платой за запись. Anthropic требует маркеры cache_control и взимает плату за запись. DashScope предлагает explicit cache (с платой за запись) и implicit cache (без платы за запись). DeepSeek автоматически записывает на диск без дополнительных расходов. Скидки на чтение кэша варьируются от 80% до 90%, TTL — от 5 минут до 24 часов, минимальный порог token — от 256 до 1 024.

При routing запросов между провайдерами эти различия напрямую влияют на стоимость: prompt, получающий 90% скидку на чтение у одного провайдера, может сначала заплатить 25% надбавку за запись у другого, а несовпадение TTL может превратить ожидаемые cache hit в полноценные cache miss.

В этой статье мы сравниваем четырёх провайдеров с примерами кода, расчётами стоимости и матрицей выбора стратегии кэширования.

OpenAI-совместимость означает, что провайдер предоставляет endpoint chat-completions, чей контракт запроса и ответа достаточно близок к API OpenAI, чтобы немодифицированный вызов OpenAI SDK работал после замены трёх значений: API key, base URL, название модели. Минимальная поверхность на практике —POST /v1/chat/completions с messages, model и потоковым ответом в форме OpenAI.

Источники: OpenAI Prompt Caching docs, получено 2026-08-05; DashScope Context Cache docs, получено 2026-08-05; DeepSeek Context Caching docs, получено 2026-08-05; Anthropic Prompt Caching docs, получено 2026-08-05 (поисковый фрагмент); DashScope Model Pricing, получено 2026-08-05.

---

Сводная таблица сравнения

---

OpenAI: автоматическое кэширование + explicit breakpoints в GPT-5.6

Prompt caching OpenAI работает автоматически для prompt длиной от 1 024 token. Система направляет запросы на серверы, недавно обрабатывавшие тот же prefix, используя hash первых ~256 token. Никаких изменений в коде не требуется.

С GPT-5.6 появились explicit cache breakpoints и плата за запись (1,25× базовой input цены). По умолчанию implicit breakpoint устанавливается на последнем сообщении user или tool. Если это сообщение содержит изменяемые данные (timestamps, tool-call history), prefix на breakpoint различается между запросами и cached_tokens может быть 0.

Для управления этим поведением добавьте prompt_cache_breakpoint в конце стабильного prefix и установите prompt_cache_options.mode в explicit:

from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-5.6-sol",
    prompt_cache_key="repo-review-v1",
    prompt_cache_options={"mode": "explicit"},
    messages=[
        {
            "role": "system",
            "content": [
                {
                    "type": "text",
                    "text": "You are a code reviewer. Repository contents:\n\n<repo>...</repo>",
                    "prompt_cache_breakpoint": {"mode": "explicit"},
                }
            ],
        },
        {"role": "user", "content": "Review the auth module for security issues."},
    ],
)

usage = response.usage
print(f"Cached: {usage.prompt_tokens_details.cached_tokens}")
print(f"Written: {usage.prompt_tokens_details.cache_write_tokens}")

Ключевые детали:

• prompt_cache_key в сочетании с hash prefix направляет запросы к одному кэшу. Трафик на один key — не более ~15 RPM.
• TTL для explicit breakpoints в GPT-5.6 по умолчанию 30 минут.
• Extended retention (до 24 часов) доступна для серий GPT-4.1, GPT-5, GPT-5.1, GPT-5.2, GPT-5.4, GPT-5.5 для организаций без ZDR.
• До 4 новых записей кэша на запрос; до 50 breakpoints для чтения.

Источник: OpenAI Prompt Caching docs, получено 2026-08-05.

---

Anthropic: explicit cache_control с платой за запись

Prompt caching у Anthropic полностью explicit. Вы отмечаете блоки контента маркерами cache_control, чтобы указать, какие prefix кэшировать. Первый вызов с данным prefix оплачивает запись по 1,25× стоимости; последующие вызовы при cache hit платят только 10% от базовой input цены (скидка 90%).

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a code reviewer. Full repo contents:\n\n<repo>...</repo>",
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[
        {"role": "user", "content": "Review auth module for vulnerabilities."}
    ],
)

usage = response.usage
print(f"Cache write: {usage.cache_creation_input_tokens}")
print(f"Cache read:  {usage.cache_read_input_tokens}")

Ключевые детали:

• Минимум для кэширования: 1 024 token для Claude Sonnet 5, 2 048 для Claude Opus.
• TTL по умолчанию: 5 минут (ephemeral). Параметр ttl позволяет продлить до 1 часа.
• До 4 маркеров cache_control на запрос.
• Запись: 1,25× базовой input цены. Чтение: 0,1× базовой input цены.
• Каждый cache hit сбрасывает TTL.

Источник: Anthropic Prompt Caching docs, получено 2026-08-05 (поисковый фрагмент).

---

DashScope: explicit и implicit режимы

DashScope (Alibaba Cloud Model Studio) предлагает два режима кэширования, взаимоисключающих в рамках одного запроса:

Explicit cache

Аналог подхода Anthropic: маркеры cache_control: {"type": "ephemeral"} в сообщениях. Запись — 1,25× базовой input цены. Чтение — 0,1× базовой input цены (скидка 90%). TTL — 5 минут, сбрасывается при hit. Минимум 1 024 token. До 4 маркеров на запрос.

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxx",
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)

response = client.chat.completions.create(
    model="qwen3.7-max",
    messages=[
        {
            "role": "system",
            "content": [
                {
                    "type": "text",
                    "text": "You are a financial analyst. Report:\n\n<report>...</report>",
                    "cache_control": {"type": "ephemeral"},
                }
            ],
        },
        {"role": "user", "content": "Summarize key revenue metrics."},
    ],
)

print(response.usage)

Implicit cache

Включается по умолчанию, когда explicit маркеры не используются. Система автоматически находит общие prefix между запросами и кэширует их. Плата за запись отсутствует — token кэша создаются по стандартной input цене. Чтение — 20% от базовой input цены (скидка 80%). Минимум 256 token. TTL неопределённый; система периодически очищает неиспользуемые данные.

Поддерживаемые модели (на август 2026): Qwen3.7-Max, Qwen3.7-Plus, Qwen3.6-Flash, Qwen3.5-Plus, Qwen3.5-Flash, Qwen3-Max, Qwen-Plus, Qwen-Flash, DeepSeek-V3.2 (через DashScope), Kimi-K2.7-Code, Kimi-K2.6, Kimi-K2.5, GLM-5.1 и варианты Qwen VL/Coder.

Источник: DashScope Context Cache docs, получено 2026-08-05.

---

DeepSeek: автоматическое дисковое кэширование

DeepSeek Context Caching on Disk включён по умолчанию для всех пользователей. Никаких изменений в коде не требуется. Каждый запрос инициирует создание кэша, последующие запросы с совпадающим prefix попадают в кэш автоматически.

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxx",
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": "You are a financial analyst. Report:\n\n<report>...</report>"},
        {"role": "user", "content": "Summarize key revenue metrics."},
    ],
)

usage = response.usage
print(f"Cache hit tokens:  {usage.prompt_cache_hit_tokens}")
print(f"Cache miss tokens: {usage.prompt_cache_miss_tokens}")

Ключевые детали:

• Cache prefix units создаются на границах запросов (конец user input + конец model output), через фиксированные интервалы token для длинных input и при обнаружении общего prefix между запросами.
• Для cache hit требуется полное совпадение с персистированным prefix unit. Частичное совпадение prefix не даёт hit.
• В многораундовых диалогах второй запрос может совпасть с cache unit первого. Для разных вопросов к одному документу система обнаруживает общий prefix после 2+ запросов и персистирует его; третий запрос попадает в кэш.
• TTL: best-effort, «от нескольких часов до нескольких дней». Явного управления TTL нет.
• Плата за запись отсутствует. Token при cache hit тарифицируются по сниженной ставке (~90% скидка).

Источник: DeepSeek Context Caching docs, получено 2026-08-05.

---

SiliconFlow: кэширование не документировано

По состоянию на август 2026 года в публичной документации SiliconFlow API не описан механизм prompt caching. Endpoint /v1/chat/completions следует OpenAI-compatible schema, но не предоставляет cached_tokens или аналогичных полей. Если SiliconFlow выполняет внутреннее кэширование, оно прозрачно и не отражается в биллинге или метаданных ответа.

---

Расчёт стоимости: когда кэширование экономит?

Кэширование экономит только тогда, когда экономия на чтении превышает затраты на запись за достаточное количество запросов.

OpenAI (GPT-5.6)

• Запись: 1,25× базовой input цены
• Чтение: до 90% скидка (0,1× базовой цены)
• Точка безубыточности: ~2 чтения на запись

Anthropic

• Запись: 1,25× базовой input цены
• Чтение: 0,1× базовой input цены
• Точка безубыточности: ~2 чтения на запись

DashScope explicit

• Запись: 1,25× базовой input цены
• Чтение: 0,1× базовой input цены
• Точка безубыточности: ~2 чтения на запись

DashScope implicit

• Запись: бесплатно (1,0× стандартной цены)
• Чтение: 0,2× базовой input цены
• Точка безубыточности: экономия с первого cache hit

DeepSeek

• Запись: бесплатно
• Чтение: ~0,1× базовой input цены
• Точка безубыточности: экономия с первого cache hit

Выводы для routing: DashScope implicit и DeepSeek дисковый кэш не имеют порога безубыточности — каждый cache hit экономит. OpenAI (GPT-5.6+), Anthropic и DashScope explicit требуют минимум 2 чтения кэша, чтобы окупить запись. Для разовых или редких prompt плата за запись может сделать кэширование дороже, чем его отсутствие.

---

Различия поведения кэша, влияющие на routing

TTL и cache affinity

При routing запросов между провайдерами кэш не мигрирует. Prefix, закэшированный на OpenAI, не существует на Anthropic. Round-robin routing одного и того же повторяющегося prefix по разным провайдерам означает, что ни один провайдер не накапливает кэш, и вы платите полную цену везде.

Для кэш-интенсивных нагрузок привязка провайдера (routing одного диалога или prompt template к одному провайдеру) экономичнее round-robin. Это компромисс: привязка повышает cache hit rate, но снижает гибкость failover.

Структура prefix

Все провайдеры матчат по точному prefix. Если изменяемый контент идёт до статического, кэширование не сработает ни у одного провайдера:

✅ system prompt (статический, длинный) → user message (переменный, короткий)
❌ user context (переменный) → system prompt (статический)

У DeepSeek матчинг строже: cache unit должен совпасть полностью. Запрос 1: A + B, запрос 2: A + C — запрос 2 не попадает в кэш. DeepSeek обнаруживает общий prefix A после обоих запросов и персистирует его; третий запрос A + D попадает в кэш. Это означает задержку холодного старта в 2+ запроса для нагрузок с варьирующимся суффиксом.

Имена полей в ответе

Каждый провайдер сообщает о состоянии кэша по-своему. Если ваша система логирования или отслеживания расходов зависит от конкретных полей, необходим парсинг по провайдерам:

---

Матрица выбора: какая стратегия для какой нагрузки

---

Примечание TheRouter

Когда TheRouter направляет запросы между OpenAI, Anthropic, DashScope и DeepSeek, кэширование обрабатывается каждым провайдером независимо. Запрос, отправленный на OpenAI, создаёт кэш на OpenAI; если следующий запрос с тем же prompt направлен на Anthropic — кэш начинается с нуля.

Для нагрузок, где кэширование — значимый рычаг снижения затрат, рассмотрите настройку model fallbacks с предпочтением одного провайдера для конкретных prompt template, с fallback на альтернативы только при rate limit или ошибках. Это сохраняет cache affinity при поддержании надёжности.

Prompt caching не меняет саму логику routing — router не проверяет и не управляет состоянием кэша провайдера. Оптимизация на стороне prompt и конфигурации routing: структурируйте prompt для кэширования, привязывайте кэш-чувствительный трафик и мониторьте cache hit rate в метаданных ответов провайдеров.

---

FAQ

Можно ли использовать prompt caching через OpenAI-compatible gateway? Да. Автоматическое кэширование OpenAI работает прозрачно. Для explicit кэширования Anthropic и DashScope параметр cache_control должен быть пропущен gateway. Кэширование DeepSeek полностью прозрачно.

Влияет ли кэширование на качество ответов? Нет. Все провайдеры заявляют, что кэширование влияет только на обработку input (повторное использование KV cache). Модель по-прежнему генерирует output через полное вычисление, и случайность output (управляемая temperature) не затрагивается.

Что происходит при истечении кэша? Следующий запрос с тем же prefix оплачивается по полной цене (или по цене записи). У Anthropic и DashScope explicit каждый cache hit сбрасывает TTL, поэтому активно используемые кэши остаются актуальными. У OpenAI (GPT-5.6) explicit breakpoint кэши имеют TTL 30 минут; для старых серий моделей доступно extended retention.

Можно ли кэшировать определения tool и изображения? OpenAI: да (tool и изображения входят в prefix matching). Anthropic: да (определения tool и блоки изображений могут нести cache_control). DashScope: да (в explicit режиме мультимодальные блоки поддерживают cache_control). DeepSeek: определения tool являются частью prompt prefix и кэшируются автоматически.