Влияние на Prompt Caching: баланс между попаданиями в кэш и экономией токенов

Чему вы научитесь

• Понимать механизм работы Prompt Caching у LLM-провайдеров
• Знать, почему обрезка DCP влияет на попадания в кэш
• Уметь находить баланс между потерей кэша и экономией токенов
• Выбирать оптимальную стратегию в зависимости от провайдера и модели тарификации

Ваша текущая проблема

После включения DCP вы заметили, что показатель попаданий в кэш упал с 85% до 65%, и теперь беспокоитесь — не увеличит ли это затраты? Или вы хотите понять, как использование DCP повлияет на разных LLM-провайдеров (Anthropic, OpenAI, GitHub Copilot)?

Операция обрезки DCP изменяет содержимое сообщений, что влияет на Prompt Caching. Но стоит ли этот компромисс? Давайте разберёмся детально.

Когда применять этот подход

• В длинных сессиях, когда контекст значительно разрастается
• При использовании провайдеров с оплатой за запрос (GitHub Copilot, Google Antigravity)
• Когда нужно уменьшить загрязнение контекста и повысить качество ответов модели
• Когда экономия токенов превышает потери от снижения попаданий в кэш

Основная концепция

Что такое Prompt Caching

Prompt Caching — это технология оптимизации производительности и затрат, предоставляемая LLM-провайдерами (Anthropic, OpenAI и др.). Она основана на точном совпадении префикса для кэширования уже обработанных промптов — одинаковые префиксы не пересчитываются повторно.

Пример механизма кэширования

Допустим, у вас есть следующая история диалога:

[Системный промпт]
[Сообщение пользователя 1]
[Ответ AI 1 + вызов инструмента A]
[Сообщение пользователя 2]
[Ответ AI 2 + вызов инструмента A]  ← тот же вызов инструмента
[Сообщение пользователя 3]

Без кэширования каждая отправка в LLM требует пересчёта всех токенов. С кэшированием при второй отправке провайдер может переиспользовать ранее вычисленные результаты и рассчитать только новую часть — «Сообщение пользователя 3».

Как DCP влияет на кэширование

Когда DCP обрезает вывод инструмента, он заменяет исходное содержимое на текст-заглушку: "[Output removed to save context - information superseded or no longer needed]"

Эта операция изменяет точное содержимое сообщения (вместо полного вывода инструмента теперь заглушка), что приводит к инвалидации кэша — кэшированный префикс с этой точки больше не может быть переиспользован.

Анализ компромиссов

Метрика	Без DCP	С DCP	Влияние
Попадания в кэш	~85%	~65%	⬇️ Снижение на 20%
Размер контекста	Постоянно растёт	Контролируемая обрезка	⬇️ Значительное уменьшение
Экономия токенов	0	10-40%	⬆️ Значительное увеличение
Качество ответов	Может снижаться	Более стабильное	⬆️ Улучшение (меньше загрязнения контекста)

Почему снижение попаданий в кэш может означать меньшие затраты?

Снижение показателя попаданий в кэш не равно увеличению затрат. Причины:

1. Экономия токенов обычно превышает потери от кэша: в длинных сессиях количество токенов, сэкономленных обрезкой DCP (10-40%), часто превышает дополнительные вычисления из-за инвалидации кэша
2. Уменьшение загрязнения контекста: после удаления избыточного содержимого модель может лучше сфокусироваться на текущей задаче, качество ответов повышается
3. Абсолютное значение попаданий в кэш остаётся высоким: даже при 65% почти 2/3 содержимого всё ещё кэшируется

Тестовые данные показывают, что в большинстве случаев эффект экономии токенов от DCP более заметен.

Влияние разных моделей тарификации

Оплата за запрос (GitHub Copilot, Google Antigravity)

Идеальный сценарий — никаких негативных последствий.

Эти провайдеры взимают плату за количество запросов, а не за количество токенов. Поэтому:

• ✅ Экономия токенов от обрезки DCP не влияет напрямую на стоимость
• ✅ Уменьшение размера контекста повышает скорость ответа
• ✅ Инвалидация кэша не увеличивает затраты

GitHub Copilot и Google Antigravity

Эти платформы тарифицируются по запросам, поэтому DCP — это оптимизация с нулевой стоимостью: даже при снижении попаданий в кэш затраты не увеличиваются, а производительность улучшается.

Оплата за токены (Anthropic, OpenAI)

Необходимо взвешивать потери кэша и экономию токенов.

Пример расчёта:

Допустим, длинная сессия содержит 100 сообщений с общим количеством токенов 100K:

Сценарий	Попадания в кэш	Экономия от кэша	Экономия от обрезки DCP	Общая экономия
Без DCP	85%	85K × (1-0.85) = 12.75K	0	12.75K
С DCP	65%	100K × (1-0.65) = 35K	20K (оценка)	35K + 20K - 12.75K = 42.25K

После обрезки DCP, несмотря на снижение попаданий в кэш, благодаря уменьшению контекста на 20K токенов общая экономия оказывается больше.

Преимущество в длинных сессиях очевидно

В длинных сессиях преимущество DCP более заметно:

• Короткие сессии (< 10 сообщений): инвалидация кэша может доминировать, выгода ограничена
• Длинные сессии (> 30 сообщений): контекст сильно разрастается, экономия токенов от обрезки DCP значительно превышает потери кэша

Рекомендация: в длинных сессиях приоритетно включайте DCP, в коротких можно отключить.

Наблюдение и проверка

Шаг 1: Наблюдение за использованием кэшированных токенов

Зачем Понять долю кэшированных токенов в общем количестве и оценить важность кэширования

# Выполните в OpenCode
/dcp context

Что вы должны увидеть: анализ токенов примерно такого вида

╭───────────────────────────────────────────────────────────╮
│                  DCP Context Analysis                     │
╰───────────────────────────────────────────────────────────╯

Session Context Breakdown:
──────────────────────────────────────────────────────────

System         15.2% │████████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│  25.1K tokens
User            5.1% │████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│   8.4K tokens
Assistant       35.8% │██████████████████████████████████████▒▒▒▒▒▒▒│  59.2K tokens
Tools (45)      43.9% │████████████████████████████████████████████████│  72.6K tokens

──────────────────────────────────────────────────────────

Summary:
  Pruned:          12 tools (~15.2K tokens)
  Current context: ~165.3K tokens
  Without DCP:     ~180.5K tokens

Интерпретация ключевых метрик:

Метрика	Значение	Как оценивать
Pruned	Количество обрезанных инструментов и токенов	Чем выше, тем больше экономит DCP
Current context	Общее количество токенов текущего контекста сессии	Должно быть значительно меньше Without DCP
Without DCP	Каким был бы размер контекста без DCP	Для сравнения эффекта экономии

Шаг 2: Сравнение с включённым/выключенным DCP

Зачем Наглядно увидеть разницу в кэшировании и экономии токенов

# 1. Отключите DCP (установите enabled: false в конфигурации)
# Или временно отключите:
/dcp sweep 999  # Обрезать все инструменты, наблюдать эффект кэширования

# 2. Проведите несколько диалогов

# 3. Посмотрите статистику
/dcp stats

# 4. Снова включите DCP
# (измените конфигурацию или восстановите значения по умолчанию)

# 5. Продолжите диалог, сравните статистику
/dcp stats

Что вы должны увидеть:

Используйте /dcp context для наблюдения за изменением ключевых метрик:

Метрика	DCP выключен	DCP включён	Пояснение
Pruned	0 tools	5-20 tools	Количество инструментов, обрезанных DCP
Current context	Больше	Меньше	Контекст значительно уменьшается с DCP
Without DCP	Равен Current	Больше Current	Показывает потенциал экономии DCP

Рекомендации по практическому тестированию

Тестируйте в разных типах сессий:

1. Короткие сессии (5-10 сообщений): наблюдайте, важнее ли кэширование
2. Длинные сессии (30+ сообщений): наблюдайте, заметнее ли экономия от DCP
3. Повторное чтение: сценарии с частым чтением одних и тех же файлов

Это поможет сделать оптимальный выбор на основе ваших реальных паттернов использования.

Шаг 3: Понимание влияния загрязнения контекста

Зачем Обрезка DCP не только экономит токены, но и уменьшает загрязнение контекста, повышая качество ответов

Что такое загрязнение контекста?

Загрязнение контекста — это когда избыточная, нерелевантная или устаревшая информация накапливается в истории диалога, что приводит к:

• Рассеиванию внимания модели, затруднению фокусировки на текущей задаче
• Возможным ссылкам на старые данные (например, уже изменённое содержимое файлов)
• Снижению качества ответов, необходимости большего количества токенов для «понимания» контекста

DCP уменьшает это загрязнение, удаляя выводы завершённых инструментов, повторные операции чтения и т.д.

Сравнение практического эффекта:

Сценарий	Без DCP	С DCP
Чтение одного файла 3 раза	Сохраняется 3 полных вывода (избыточность)	Сохраняется только последний
Повторное чтение после записи файла	Старая операция записи + новое чтение	Сохраняется только новое чтение
Ошибочный вывод инструмента	Сохраняется полный ошибочный ввод	Сохраняется только сообщение об ошибке

После уменьшения загрязнения контекста модель может точнее понимать текущее состояние, уменьшая случаи «галлюцинаций» или ссылок на устаревшие данные.

Рекомендации по лучшим практикам

Выбор стратегии в зависимости от провайдера

Провайдер	Модель тарификации	Рекомендация	Причина
GitHub Copilot	За запрос	✅ Всегда включать	Оптимизация с нулевой стоимостью, только улучшение производительности
Google Antigravity	За запрос	✅ Всегда включать	То же самое
Anthropic	За токены	✅ Включать в длинных сессиях ⚠️ Опционально в коротких	Баланс кэша и экономии
OpenAI	За токены	✅ Включать в длинных сессиях ⚠️ Опционально в коротких	То же самое

Настройка конфигурации в зависимости от типа сессии

// ~/.config/opencode/dcp.jsonc или конфигурация проекта

{
  // Длинные сессии (> 30 сообщений): включить все стратегии
  "strategies": {
    "deduplication": { "enabled": true },
    "supersedeWrites": { "enabled": true },  // Рекомендуется включить
    "purgeErrors": { "enabled": true }
  },

  // Короткие сессии (< 10 сообщений): включить только дедупликацию
  "strategies": {
    "deduplication": { "enabled": true },
    "supersedeWrites": { "enabled": false },
    "purgeErrors": { "enabled": false }
  }
}

Описание стратегий:

• deduplication (дедупликация): минимальное влияние, рекомендуется всегда включать
• supersedeWrites (замена записей): среднее влияние, рекомендуется для длинных сессий
• purgeErrors (очистка ошибок): минимальное влияние, рекомендуется включать

Динамическая настройка стратегий

Используйте /dcp context для наблюдения за составом токенов и эффектом обрезки:

# Если значение Pruned высокое, DCP активно экономит токены
# Сравните Current context и Without DCP для оценки эффекта экономии

/dcp context

Контрольные точки ✅

Убедитесь, что вы понимаете следующие ключевые моменты:

• [ ] Prompt Caching основан на точном совпадении префикса, изменение содержимого сообщения инвалидирует кэш
• [ ] Обрезка DCP изменяет содержимое сообщений, что приводит к снижению попаданий в кэш (примерно на 20%)
• [ ] В длинных сессиях экономия токенов обычно превышает потери кэша
• [ ] GitHub Copilot и Google Antigravity тарифицируются за запрос, DCP — оптимизация с нулевой стоимостью
• [ ] Anthropic и OpenAI тарифицируются за токены, необходим баланс кэша и экономии
• [ ] Используйте /dcp context для наблюдения за составом токенов и эффектом обрезки
• [ ] Динамически настраивайте конфигурацию стратегий в зависимости от длины сессии

Типичные ошибки

❌ Ошибочное мнение, что снижение попаданий в кэш равно увеличению затрат

Проблема: Увидев снижение попаданий в кэш с 85% до 65%, думать, что затраты увеличатся

Причина: Фокус только на попаданиях в кэш, игнорирование экономии токенов и уменьшения контекста

Решение: Используйте /dcp context для просмотра реальных данных, обращая внимание на:

1. Токены, сэкономленные обрезкой DCP (Pruned)
2. Текущий размер контекста (Current context)
3. Теоретический размер без обрезки (Without DCP)

Сравнивая Without DCP и Current context, вы увидите реальное количество токенов, сэкономленных DCP.

❌ Слишком агрессивная обрезка в коротких сессиях

Проблема: В коротких сессиях из 5-10 сообщений включены все стратегии, инвалидация кэша заметна

Причина: В коротких сессиях разрастание контекста не критично, выгода от агрессивной обрезки мала

Решение:

• В коротких сессиях включайте только deduplication и purgeErrors
• Отключите стратегию supersedeWrites
• Или полностью отключите DCP (enabled: false)

❌ Игнорирование различий в тарификации разных провайдеров

Проблема: Беспокойство об увеличении затрат из-за инвалидации кэша при использовании GitHub Copilot

Причина: Не учтено, что Copilot тарифицируется за запрос, инвалидация кэша не увеличивает затраты

Решение:

• Copilot и Antigravity: всегда включайте DCP
• Anthropic и OpenAI: настраивайте стратегии в зависимости от длины сессии

❌ Принятие решений без анализа реальных данных

Проблема: Решение о включении DCP на основе интуиции

Причина: Не использованы /dcp context и /dcp stats для наблюдения за реальным эффектом

Решение:

• Собирайте данные в разных сессиях
• Сравнивайте разницу с включённым/выключенным DCP
• Делайте выбор на основе своих паттернов использования

Итоги урока

Основной механизм Prompt Caching:

• LLM-провайдеры кэшируют промпты на основе точного совпадения префикса
• Обрезка DCP изменяет содержимое сообщений, вызывая инвалидацию кэша
• Попадания в кэш снижаются (примерно на 20%), но экономия токенов более значительна

Матрица принятия решений:

Сценарий	Рекомендуемая конфигурация	Причина
GitHub Copilot/Google Antigravity	✅ Всегда включать	Оплата за запрос, оптимизация с нулевой стоимостью
Anthropic/OpenAI длинные сессии	✅ Включить все стратегии	Экономия токенов > потери кэша
Anthropic/OpenAI короткие сессии	⚠️ Только дедупликация + очистка ошибок	Кэширование важнее

Ключевые выводы:

1. Снижение попаданий в кэш не равно увеличению затрат: нужно смотреть на общую экономию токенов
2. Модель тарификации провайдера влияет на стратегию: оплата за запрос vs за токены
3. Динамическая настройка в зависимости от длины сессии: длинные сессии выигрывают больше
4. Используйте инструменты для анализа данных: /dcp context и /dcp stats

Сводка лучших практик:

1. Определите вашего провайдера и модель тарификации
2. Настройте стратегии в зависимости от длины сессии
3. Регулярно используйте /dcp context для наблюдения за эффектом
4. В длинных сессиях приоритет — экономия токенов
5. В коротких сессиях приоритет — попадания в кэш

Анонс следующего урока

В следующем уроке мы изучим Обработка субагентов.

Вы узнаете:

• Как DCP обнаруживает сессии субагентов
• Почему субагенты не участвуют в обрезке
• Как результаты обрезки в субагентах передаются главному агенту

---

Приложение: Справочник по исходному коду

Нажмите, чтобы развернуть расположение исходного кода

Дата обновления: 2026-01-23

Функция	Путь к файлу	Строки
Описание Prompt Caching	README.md	46-52
Расчёт токенов (с кэшем)	lib/messages/utils.ts	66-78
Команда анализа контекста	lib/commands/context.ts	68-174
Расчёт кэшированных токенов	lib/commands/context.ts	106-107
Логирование кэшированных токенов	lib/logger.ts	141
Определение заглушки обрезки	lib/messages/prune.ts	6-7
Обрезка вывода инструментов	lib/messages/prune.ts	22-46

Ключевые константы:

• Нет

Ключевые функции:

• calculateTokens(messages, tokenizer): расчёт количества токенов сообщений, включая cache.read и cache.write
• buildSessionContext(messages): построение анализа контекста сессии, разделение на System/User/Assistant/Tools
• formatContextAnalysis(analysis): форматирование вывода анализа контекста

Ключевые типы:

• TokenCounts: структура подсчёта токенов, включает input/output/reasoning/cache

Описание механизма кэширования (из README):

• Anthropic и OpenAI кэшируют промпты на основе точного совпадения префикса
• Обрезка DCP изменяет содержимое сообщений, вызывая инвалидацию кэша
• С включённым DCP попадания в кэш ~65%, без DCP ~85%
• Идеальный сценарий: провайдеры с оплатой за запрос (GitHub Copilot, Google Antigravity) — никаких негативных последствий