DeepSeek V3.2 prompt caching в ofox: 10 минут, до 80% экономии (2026)

Между каждым запросом DeepSeek с попаданием в кеш и каждым промахом стоит ценовой разрыв в 4.8× — и на типичном agent loop разница между hit и miss сводится к тому, не забыли ли вы поставить timestamp в конец промпта.

Ответ за 30 секунд

Если у вас есть время только на таблицу — вот она:

Итого: ~10 минут. После этого корректно структурированные вызовы попадают на cache read $0.06/M вместо ставки miss $0.29/M — скидка 79.3% на кешированные input-токены.

Три правила покрывают 90% экономии:

1. Стабильный префикс, динамический хвост. Всё, что меняется между запросами, идёт в конец промпта, а не внутрь system-сообщения или few-shot блока.
2. Тот же байт — то же попадание. Кеш сопоставляется как точное совпадение по токенам. Новый пробел, другой ISO timestamp, per-user salt — что угодно из этого ломает префикс.
3. Не измеряли — не было. Доставайте prompt_cache_hit_tokens из каждого ответа. Если коэффициент падает — что-то динамическое заползло в префикс.

Что вы можете и не можете после этой настройки

✅ Можете:

• Запускать DeepSeek V3.2 по deepseek/deepseek-v3.2 через один ofox API key, в той же форме кода, что и любой вызов OpenAI SDK.
• Получать cache reads по $0.06/M на повторяющихся префиксах — контекст 128K, max output 32K.
• Отслеживать попадания на каждый запрос через те же поля usage, что DeepSeek возвращает напрямую (prompt_cache_hit_tokens, prompt_cache_miss_tokens).
• Шарить один API key на команду и смотреть в dashboard usage logs, какие пути вызовов кешируются хорошо.

❌ Не можете:

• Принудительно попасть в кеш. Кеш DeepSeek работает best-effort — нет ни флага cache_control, как у Anthropic, ни cache_id, как в Gemini context cache.
• Кешировать между пользователями, когда у каждого свой per-call salt в system prompt. Перенесите user ID в хвост или в metadata-поля вне тела промпта.
• Держать кеш бесконечно. Время жизни — «от нескольких часов до нескольких дней», на холодных путях очищается.
• Кешировать между версиями модели. Переключение с deepseek/deepseek-v3.2 на deepseek/deepseek-r1 строит новый кеш.
• Совмещать экономию на кеше с алиасом V4 на стороне DeepSeek-direct после 24 июля 2026. Через ofox model ID V3.2 закреплён, и нагрузки на нём продолжают работать после миграции алиасов вверху, но в какой-то момент V4 появится в каталоге ofox, и тогда придётся пересмотреть.

Если вам нужны какие-либо из этих гарантий, ответ не «подкрутить эту настройку» — это другая модель или другой вендор.

Decision frame: когда применять эту настройку, а когда нет

Когда использовать DeepSeek V3.2 + prompt caching в ofox:

1. RAG-пайплайны со стабильным извлечённым контекстом на сессию. Извлечённые чанки плюс system prompt образуют длинный стабильный префикс, запрос пользователя — хвост. Cache hit ratio 70%+ — норма.
2. Многоходовые agent loops с тем же system prompt и tool schema. Каждая итерация видит одно и то же начало — кеш окупается со второго хода.
3. Batch-задачи, где много промптов делят длинную преамбулу (например, классификация 10k тикетов поддержки против одного и того же набора инструкций по разметке). Прогоняйте их последовательно через один префикс — кеш остаётся тёплым.

Когда НЕ использовать:

1. Одноразовые, полностью динамические промпты. Если у каждого запроса свой system message, вы платите $0.29/M каждый раз. Кеш не помогает — лучше взять модель поменьше.
2. Жёсткие latency SLO, завязанные на попадания в кеш. Кеш best-effort; стройте под miss.
3. Compliance-окружения, запрещающие cross-request кеширование пользовательских данных. Отключайте на уровне обработки данных; маршрутизируйте на модель с явной per-call ephemeral памятью.
4. Нагрузки, требующие image input. V3.2 только текстовый. Для мультимодальности переходите на модель с поддержкой зрения в ofox.

Stop rule: если ваш повторяющийся префикс короче ~1k токенов, экономия от кеша реальна, но невелика. Конфигурация всё равно имеет фиксированную стоимость. Ниже этого порога просто выкатывайте без оптимизации кеша и возвращайтесь, когда промпты вырастут.

Системные требования

DeepSeek-direct аккаунт не нужен. Одного ofox-ключа достаточно для всего каталога.

Пошаговая установка

Шаг 1: получить ofox API key

В dashboard ofox создайте ключ. Положите в env-переменную локально, чтобы он не оказался в репозитории:

export OFOX_API_KEY="sk-ofox-xxx"
export OPENAI_BASE_URL="https://api.ofox.ai/v1"

Ожидаемый результат: echo $OFOX_API_KEY возвращает ваш ключ. Никакой файл на диске его не содержит.

Шаг 2: установить OpenAI SDK

Python:

pip install "openai>=1.0.0"

Node:

npm install openai

Ожидаемый результат: pip show openai или npm list openai подтверждает установку. OpenAI SDK — правильный клиент, потому что API ofox OpenAI-совместим: та же форма, другой base_url.

Шаг 3: первый вызов DeepSeek V3.2

Минимальный smoke-тест в smoke.py:

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["OFOX_API_KEY"],
    base_url="https://api.ofox.ai/v1",
)

resp = client.chat.completions.create(
    model="deepseek/deepseek-v3.2",
    messages=[
        {"role": "system", "content": "You are a terse assistant. Answer in one sentence."},
        {"role": "user", "content": "What is the cache read price for V3.2 on ofox?"},
    ],
)
print(resp.choices[0].message.content)
print(resp.usage)

Ожидаемый результат: текст ответа плюс объект usage с prompt_tokens, completion_tokens, total_tokens и двумя cache-полями prompt_cache_hit_tokens и prompt_cache_miss_tokens. На самом первом вызове счётчик попаданий будет 0 (холодный кеш).

Шаг 4: структурируем под cache hits

Перестройте промпт так, чтобы стабильные части шли первыми, а переменные — последними. Рабочий шаблон:

SYSTEM_PROMPT = """You are a customer-support classifier for an e-commerce site.
Label each ticket with exactly one of: refund | shipping | account | bug | other.
Output JSON only: {"label": "...", "confidence": 0.0-1.0}"""

FEW_SHOT_EXAMPLES = """Ticket: "Where is my order #12345?" -> {"label": "shipping", "confidence": 0.95}
Ticket: "Reset my password please" -> {"label": "account", "confidence": 0.92}
Ticket: "The button on /checkout doesn't work" -> {"label": "bug", "confidence": 0.88}"""

def classify(ticket_text: str) -> str:
    resp = client.chat.completions.create(
        model="deepseek/deepseek-v3.2",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT + "\n\n" + FEW_SHOT_EXAMPLES},
            {"role": "user", "content": f"Ticket: {ticket_text}"},
        ],
    )
    return resp.choices[0].message.content

Ожидаемый результат: со второго по N-й вызов этой функции prompt_cache_hit_tokens должен покрывать блок system + few-shot. Меняется только строка user; всё, что до неё, остаётся побайтово идентичным.

Шаг 5: логируем коэффициент попаданий

Оборачиваем вызов, чтобы видеть, где кеш работает:

def classify(ticket_text: str) -> dict:
    resp = client.chat.completions.create(
        model="deepseek/deepseek-v3.2",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT + "\n\n" + FEW_SHOT_EXAMPLES},
            {"role": "user", "content": f"Ticket: {ticket_text}"},
        ],
    )
    u = resp.usage
    hit_ratio = u.prompt_cache_hit_tokens / max(u.prompt_tokens, 1)
    return {
        "label": resp.choices[0].message.content,
        "tokens_in": u.prompt_tokens,
        "tokens_cached": u.prompt_cache_hit_tokens,
        "hit_ratio": round(hit_ratio, 3),
    }

Ожидаемый результат: примерно через 10 вызовов выводимый hit_ratio должен устаканиться в диапазоне 0.6–0.85 для этого шаблона. Если он держится около 0, что-то в префиксе меняется между вызовами — найдите это до того, как масштабировать трафик.

Шаг 6: посчитайте реальный счёт

С цифрами V3.2 посчитайте перед запуском большой задачи. На 1M prompt-токенов с долями 70% cache hits / 30% misses плюс 200k output-токенов:

Та же нагрузка при 0% попаданий (всё miss): $0.29 input + $0.086 output = $0.376. Кеш срезает 43% с реалистичной задачи со смешанным hit rate. Поднимите hit ratio выше — экономия увеличится: при 90% попаданий получится $0.169, снижение ~55%.

Типичные ошибки при настройке (и как их чинить)

Team / multi-developer конфигурация

Для одиночной работы хватит одного API key и одного base URL. Для 3+ разработчиков и общих нагрузок структура важнее, чем хитрость отдельного промпта.

Свой ключ на разработчика, общий контракт модели.

Выдайте по одному ключу ofox на разработчика; не коммитьте ключи в git. Закрепите model ID и base URL в общем конфиг-файле, чтобы все били ровно по одной модели — если один разработчик идёт в deepseek/deepseek-v3.2, а другой — в опечатку, их кеши разойдутся, и вы будете жечь деньги без возможности отследить.

Общий ai.config.ts (или ai_config.py) — самое дешёвое решение:

export const AI_CONFIG = {
  baseURL: "https://api.ofox.ai/v1",
  model: "deepseek/deepseek-v3.2",
  systemPrompt: SYSTEM_PROMPT,
  fewShot: FEW_SHOT_EXAMPLES,
} as const;

Cache hit ratio как метрика дашборда.

Пробросьте hit_ratio из шага 5 в свою существующую observability (Datadog, Honeycomb, обычный Postgres — неважно). Поставьте алерт на hit_ratio < 0.4 за 1 час. Это лучший единичный сигнал того, что кто-то выкатил изменение промпта, сломавшее префикс.

Зачем общий prompt registry на масштабе: как только два сервиса независимо переписывают system prompt, каждый строит свой кеш. Счёт удваивается за ту же работу. Реестр + ревью промптов через PR удерживают префикс консистентным между сервисами, и кеш остаётся горячим.

Advanced: толкаем hit ratio за 80%

Несколько паттернов позволяют выжать ещё, когда основы стоят:

Сортируйте определения инструментов детерминированно. Если сериализуете tool/function schema в system-сообщение, сортируйте ключи. Порядок ключей у JSON-сериализаторов в Python и Node может отличаться — одного смещения пробела достаточно, чтобы сломать префикс.

Фиксируйте порядок few-shot. Не рандомизируйте примеры «для разнообразия». Случайный порядок = случайный префикс = нулевой кеш. Нужно разнообразие — заведите два отдельных зарегистрированных промпта (два префикса, оба тёплые), а не один с перемешиваемым внутри.

Предпочитайте system + assistant ходы вместо вставки контекста в user. Длинный блок извлечённого контекста в начале user-сообщения кешируется, но он лучше работает в system или в ведущем assistant-ходе — детекция префикса чище. (См. документацию ofox по структуре chat-сообщений для поддерживаемых форм.)

Batch warm-up при деплое. Когда выкатываете новую версию промпта, прогрейте кеш 3–5 пустыми запросами на низкой температуре до прихода живого трафика. Первый пользователь больше не платит премию за cache-miss.

Для глубокого погружения в то, что именно отчитывает поле usage.prompt_cache_hit_tokens, есть официальный гайд DeepSeek по кешированию с wire-level подробностями, а анонс цен на disk cache от DeepSeek 2024 объясняет, почему cache-hit на прямом API примерно в 10× дешевле miss.

Если нужно сравнить ценообразование кеша DeepSeek V3.2 с другими моделями в ofox со своими стратегиями кеширования — Qwen 3.7, семейства Claude, Gemini 3.x — перейдите в кластер сравнения моделей:

• Детали модели DeepSeek V3.2 в ofox
• Каталог моделей ofox
• Документация API ofox
• Блог ofox: OpenAI-совместимый доступ к API

FAQ

Кеширует ли DeepSeek V3.2 промпты автоматически? Да. Кеширование включено по умолчанию — никакого блока cache_control, как у Anthropic. Модель сопоставляет префикс запроса с дисковым кешом и тарифицирует совпавшие токены по ставке cache-read.

Какая цена попадания в кеш для DeepSeek V3.2 в ofox? $0.06 за миллион токенов для cache reads, против $0.29/M за cache misses на некешированном вводе и $0.43/M за вывод. Cache hits примерно в 4.8× дешевле miss.

Сколько живёт prompt cache DeepSeek? Документация описывает время жизни как «обычно от нескольких часов до нескольких дней» — best-effort, без SLA. Это оппортунистический кеш, не гарантированный.

Можно ли принудительно попасть в кеш на DeepSeek V3.2? Нет. Единственный рычаг — структура запроса: стабильный префикс, динамический хвост, побайтово идентичные system + few-shot блоки между вызовами.

Будет ли DeepSeek V3.2 удалён в 2026? Алиасы deepseek-chat и deepseek-reasoner на DeepSeek-direct маршрутизируются на deepseek-v4-flash с 24 апреля 2026 (grace period), и имена алиасов будут полностью deprecated 24 июля 2026. ofox отдаёт V3.2 под явным ID deepseek/deepseek-v3.2, независимо от миграции алиасов вверху.

Как проверить cache hit rate на DeepSeek? Каждый ответ chat completion включает usage.prompt_cache_hit_tokens и usage.prompt_cache_miss_tokens. Сложите их и поделите попадания на общее число prompt-токенов.

Работает ли prompt caching при вызове DeepSeek через ofox? Да. Поля hit/miss пробрасываются без изменений, биллинг применяет ставку кеша. Base URL — https://api.ofox.ai/v1, model ID — deepseek/deepseek-v3.2.

Стоит ли в середине 2026 использовать DeepSeek V3.2 в проде, а не V4 Flash? Для кеш-тяжёлых нагрузок — RAG, повторяющиеся system prompts, agent loops со стабильными инструкциями — V3.2 по $0.06/M cache read остаётся одним из самых дешёвых путей к контексту 128K. Пересмотрите после того, как V4 появится в ofox.

Самая дешёвая модель в вашем счёте — та, которую вы настроили попадать в свой собственный кеш, и DeepSeek V3.2 по $0.06 за миллион кешированных токенов — это то, как оно выглядит, когда сделано правильно.

Источники, проверенные для этого обновления

• DeepSeek API docs, KV cache guide (проверено 2026-06-15): https://api-docs.deepseek.com/guides/kv_cache
• DeepSeek API news, анонс context caching (проверено 2026-06-15): https://api-docs.deepseek.com/news/news0802
• Snapshot каталога ofox (https://ofox.io/llms-full.txt), подтверждено, что DeepSeek-V3.2 присутствует и deepseek/deepseek-v3.2 — канонический model ID (проверено 2026-06-15)
• Страница модели V3.2 в ofox (проверено 2026-06-15): https://ofox.io/models/deepseek/deepseek-v3.2 — Input $0.29/M, Output $0.43/M, Cache Read $0.06/M, контекст 128K, max output 32K
• Справка OpenRouter по DeepSeek V3.2 (проверено 2026-06-15): https://openrouter.ai/deepseek/deepseek-v3.2
• Уведомление о миграции алиасов deepseek-chat / deepseek-reasoner с выводом 2026-07-24 (перекрёстно сверено с несколькими вторичными источниками)