Счёт за DeepSeek API — это не простое «число вызовов умножить на цену». Его определяют входные токены, выходные токены и попадания в кэш. Многие команды составляют бюджет по прайс-листу, а после запуска обнаруживают, что реальные затраты заметно выше. Причина обычно не в изменении цены, а в структуре входа, доле попаданий в кэш и количестве повторов, которые отличаются от расчётных.

Ниже тарификация DeepSeek API разложена на вычислимые части: какие токены оплачиваются, почему кэш иногда работает, а иногда нет, как оценивать стоимость по полю usage в ответе и в каком порядке снижать затраты. Конкретные цены смотрите на странице тарифов и в официальной документации DeepSeek.

Примечание: DeepSeek — товарный знак соответствующего правообладателя. Примеры отражают распространённые формы интерфейсов по состоянию на октябрь 2026 года; цены, имена моделей и правила биллинга могут меняться, поэтому перед закупкой сверьтесь с официальной страницей.

1. Разложим счёт на четыре статьи

Статья Когда возникает Основные факторы Направление оптимизации
Вход без попадания в кэш Новое содержимое впервые попадает в контекст Длина документа, история сообщений, определения инструментов Поиск, суммаризация, обрезка
Вход с попаданием в кэш Запрос повторно использует ранее закэшированный префикс Стабильность префикса, доля попаданий Фиксированный префикс, меньше случайного содержимого
Выход Модель генерирует текст и структурированный результат Длина выхода, ограничения формата max_tokens, ограничения JSON
Рассуждения Рассуждающая модель формирует цепочку мыслей Сложность задачи, уровень рассуждений Не использовать рассуждающую модель для простых задач

Кэш контекста DeepSeek обычно проявляется на стороне входа: попавший в кэш префикс тарифицируется по более низкой цене входа, а промах — по стандартной. Взимается ли плата за хранение кэша и сколько он живёт, смотрите в актуальной официальной документации, а не в старых статьях.

Стоимость одного запроса можно записать формулой:

Стоимость запроса =
  входные токены с попаданием × цена попадания
+ входные токены без попадания × цена входа
+ выходные токены × цена выхода

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

2. Почему кэш экономит и почему часто не срабатывает

Логика кэша контекста проста: если начало двух запросов полностью совпадает, сервер может переиспользовать предыдущий результат вычислений и заново считать только добавленную часть. Поэтому кэш наиболее эффективен для:

  1. Фиксированного system prompt и описания роли.
  2. Стабильных определений инструментов и схем функций.
  3. Повторно используемых фрагментов базы знаний, продуктовых руководств и шаблонов договоров.
  4. Неизменной первой части многораундового диалога.

Наоборот, кэш часто перестаёт работать из-за таких приёмов:

  • в начало system prompt вставляют текущее время, случайный ID или имя пользователя;
  • при каждом запросе меняется порядок инструментов или документов;
  • весь документ ставится в начало, а вопрос пользователя — в конец;
  • одно и то же направление бизнеса переключается между моделями и точками входа;
  • префикс слишком короткий и не достигает гранулярности, пригодной для переиспользования.

Самое простое и эффективное решение — перенести изменяемое содержимое в конец запроса, а стабильное оставить в начале. Кэш обычно работает по принципу best effort и не гарантирует попадание, поэтому бюджет нужно считать исходя из частичного попадания, а не предполагать, что кэшируется всё.

3. Оценка по полю usage на реальных данных

Не угадывайте токены по количеству символов. Записывайте usage из каждого ответа и наблюдайте неделю — так вы получите реальную структуру своего бизнеса.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

resp = client.chat.completions.create(
    model="deepseek-chat",  # имя модели уточняйте на странице тарифов
    messages=[
        {"role": "system", "content": "Ты помощник службы поддержки, отвечай не более чем тремя предложениями."},
        {"role": "user", "content": "Можно ли изменить адрес доставки после отправки заказа?"},
    ],
    max_tokens=256,
)

usage = resp.usage
hit = getattr(usage, "prompt_cache_hit_tokens", 0) or 0
miss = getattr(usage, "prompt_cache_miss_tokens", 0) or 0

print("Вход", usage.prompt_tokens)
print("Попадание в кэш", hit, "промах", miss)
print("Выход", usage.completion_tokens)

Если ответ не содержит разбивки по кэшу, фиксируйте общий вход и общий выход, а затем восстанавливайте структуру по счёту или странице расхода. Главное — придерживаться одной методики и не сравнивать данные разных дней и разных точек входа вперемешку.

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

4. Почему при одинаковом объёме вызовов счёт отличается в разы

Сценарий Типичная структура токенов Источник роста затрат На что обратить внимание
Чат-бот поддержки Много входа, короткий выход История сообщений передаётся снова и снова Суммаризация, кэш, только последние раунды
Извлечение из документов Средний вход, структурированный выход Один и тот же документ читается многократно Кэширование префикса, пакетная обработка
Помощник по коду Большой вход и большой выход Результаты инструментов и длинные файлы Поиск, разбиение на блоки, ограничение выхода
Генерация длинных текстов Короткий вход, длинный выход Накопление выходных токенов Генерация по частям, max_tokens
Задачи рассуждения Средний вход, выход с размышлениями Цепочка мыслей учитывается в выходе Для простых задач брать нерассуждающую модель

Различия обычно возникают в пяти местах:

  1. Разное соотношение входа и выхода. У поддержки и генерации длинных текстов противоположная структура затрат; нельзя оценивать их одним средним значением.
  2. Разная доля попаданий в кэш. Фиксированный префикс переиспользуется, динамическое содержимое ломает кэш.
  3. Разная длина контекста. Если каждый раунд заново передавать весь документ, стоимость входа накапливается с числом раундов.
  4. Разное число повторов. Повторные отправки после 429 и таймаутов увеличивают объём запросов; оплачиваются ли неудачные запросы, смотрите в счёте.
  5. Разный уровень модели. У рассуждающих и нерассуждающих моделей отличаются цена и длина выхода; неверный выбор раздувает бюджет.

5. Порядок снижения затрат не должен быть обратным

  1. Сначала измерьте. По usage и логам рассчитайте реальную структуру токенов каждой функции, а не полагайтесь на ощущения.
  2. Затем повышайте попадания в кэш. Зафиксируйте system prompt, определения инструментов и префикс знаний, уберите динамическое содержимое из начала.
  3. Затем сокращайте вход. RAG должен возвращать только релевантные фрагменты, историю сообщений — суммаризировать, из вывода инструментов оставлять необходимые поля.
  4. Ограничивайте выход. Задайте разумный max_tokens, требуйте JSON или фиксированные поля, уменьшайте повторные объяснения.
  5. Распределяйте модели. Классификация, извлечение и переписывание — на лёгкую модель, сложные рассуждения — на более сильную.
  6. Используйте асинхронность и пакетную обработку. Разметку, суммаризацию и офлайн-анализ, где не нужен немедленный ответ, отправляйте в очередь.
  7. Мониторьте и настраивайте оповещения. Смотрите расход по проектам, моделям и сценариям, задавайте лимиты бюджета.

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

6. Как управлять бюджетом и счётом

  • Один проект — один ключ; тест и производство раздельно, чтобы не занимать общий лимит.
  • Задайте ключам лимит расхода и оповещения, чтобы автоматически останавливать аномальные вызовы.
  • Еженедельно сверяйте расход по «проекту, модели и сценарию» и находите самые быстрорастущие вызовы.
  • Отдельно фиксируйте экономию от кэша и распределения моделей, иначе эффективность оптимизации не доказать.
  • Командам, которым нужны оплата в юанях и счёт, подходит единый биллинг через локальный AI-шлюз; конкретные цены, курс и правила выставления счетов смотрите на странице тарифов.

Частые вопросы

Нужно ли вручную включать кэш DeepSeek?

Обычно явно размечать кэшируемые сегменты не требуется: сервер сам определяет по префиксу, можно ли переиспользовать вычисления; конкретный механизм и срок хранения смотрите в официальной документации. Ваша задача — сделать префикс стабильным, а не добавлять больше настроек.

Почему доля попаданий в кэш то растёт, то падает?

Частая причина — метка времени, случайный ID или данные пользователя в префиксе, либо переключение запросов между моделями и точками входа. Сначала перенесите изменяемое содержимое в конец, затем наблюдайте неделю.

Оплачиваются ли размышления рассуждающей модели?

Токены рассуждений обычно учитываются в выходе; точную методику смотрите в официальной документации и счёте. Для простой классификации и извлечения не стоит по умолчанию использовать рассуждающую модель.

Что дороже: вход или выход?

У большинства моделей выход дороже входа, но вход после попадания в кэш обычно дешевле. Не сравнивайте две цены по отдельности — считайте стоимость одного запроса по своему соотношению входа и выхода.

Почему оценка не совпадает со счётом?

Часто не учитывают историю сообщений, определения инструментов, повторные запросы, промахи кэша и длинный выход. Сопоставьте request ID с журналом расхода, чтобы найти расхождение.

Что дальше

Создайте тестовый ключ в ZSQH AI Gateway, прогоните реальные задачи в течение недели, записывайте вход, выход и попадания в кэш, а затем пересчитайте бюджет по странице тарифов. Доступность моделей и цены определяются страницей тарифов.

Читайте также: