Не в 12,1 раз, а 2,3–2,9: сколько стоит новый тариф DeepSeek V4 и почему все решают 3 часа с 10:00 до 13:00 МСК

Цифру «+1100%» я увидел в чужом пересказе, и это ровно тот жанр новости, после которого приходят спрашивать, что будет со сметой. Часть нашей нагрузки на DeepSeek пакетная, ее можно двигать по времени суток, так что вопрос был прикладной: насколько сильно двигать и куда.

Я открыл прайс, взял профиль своей нагрузки, перемножил. Получилось 2,3. Перепроверил на других профилях, получилось от 2,3 до 2,9. Роста в 11 раз не вышло нигде.

Дальше выяснилось, что 12,1 существует, живет ровно в одной клетке прайса из шести и весит в счете меньше 10%. А по дороге я наткнулся на вещь поинтереснее: пиковые окна DeepSeek объявил в UTC, и в московском времени они ложатся так, что из рабочего дня дорогим оказывается ровно промежуток с 10:00 до 13:00, после чего до 04:00 следующих суток все идет по дешевому тарифу.

Ниже разбор прайса, реверс-инжиниринг пиковых окон, таблица «найдите свой часовой пояс», калькулятор на 40 строк и фрагмент crontab, который сдвигает батч за 13:05.

Куда делись 12,1 раза

16 августа в 16:00 UTC DeepSeek заменил плоский прайс на двухуровневый. Одни и те же токены теперь стоят по-разному в зависимости от часа: пиковый тариф ровно в 2 раза дороже непикового, никаких промежуточных ступеней. Вот вся таблица целиком, в долларах за 1 миллион токенов.

Жирная строка и есть источник заголовков. Делим 0,044 на 0,003625, получаем 12,14, округляем до «+1100%». Все остальные 5 строк подорожали в 3,0–5,0 раза в пик и в 1,5–2,4 раза вне его, и именно эти 5 строк формируют счет.

История цифры 0,003625 объясняет остальное. Она держалась с 26 апреля 2026 года, когда DeepSeek срезал стоимость попаданий в кеш в 10 раз от стартовой. До апреля кешированный вход на Pro стоил 0,03625, так что новый пиковый тариф 0,044 это плюс 21% к цене, которая действовала 4 месяца назад, а на Flash кеш и сейчас в 2 раза дешевле стартового. Рост в 12 раз меряет откат весенней акции на самой дешевой строке прайса, и меряет от ее нижней точки.

В счете эта строка почти ничего не весит, потому что кешированный вход изначально стоил копейки. У чат-ассистента с половиной попаданий в кеш он занимал 0,59% старого счета и занимает 2,04% нового. В RAG, где кеш забирает 80% входа, доля растет с 2,79 до 9,71%, и это потолок для живых нагрузок. Чтобы 12,14× дошли до итоговой суммы, запросы должны состоять почти целиком из попаданий в кеш и почти не производить выходных токенов: я прогнал предельный случай со 100 тысячами токенов контекста, ответом в 1 токен и промахом кеша раз на 1000 запросов, и даже там множитель упирается в 11,15. В продакшене такого профиля не бывает.

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

Дырка в расписании на 2 часа

В документации про время сказано одной строкой: Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC (all other hours are off-peak). 7 часов дорогих, 17 дешевых.

Первая реакция у меня была ленивая и неправильная: глянул на «01:00» и «06:00», решил, что это глубокая ночь, и мысленно закрыл вопрос. Потом дошло, что UTC это не мое время, и прибавил к ним 3.

Но раньше денег меня зацепила форма расписания. Пиковых окон 2, и между ними дыра ровно на 2 часа: 04:00–06:00 UTC, когда тариф внезапно падает и через 2 часа снова поднимается. Для нагрузки это бессмыслица, спрос не проваливается на 2 часа посреди пика и не возвращается по будильнику. Если только это не чей-то обеденный перерыв.

Пекин живет в UTC+8. Сдвигаем оба окна на 8 часов вперед:

• 01:00–04:00 UTC превращается в 09:00–12:00 по Пекину

• 06:00–10:00 UTC превращается в 14:00–18:00 по Пекину

Утро в офисе, обед с 12 до 14, вторая половина дня до 18:00. Дыра в расписании это китайский обед.

Никакого абстрактного «пика» здесь нет, DeepSeek снял собственную кривую нагрузки и выставил тариф по ней, а кривая у него домашняя. Все остальные часовые пояса получили китайский рабочий день в наследство, и повезло им очень по-разному. Иначе и быть не могло: тариф проектировали под Пекин, а не под глобальную карту.

Что это в московском времени

Москва это UTC+3 круглый год, перевод стрелок отменили в 2014-м, поэтому арифметика разовая и навсегда. Прибавляем 3 и получаем пик с 04:00 до 07:00 и с 09:00 до 13:00 МСК.

Первое окно приходится на глухую ночь и цепляет только кроны. Второе цепляет утро, и вот тут вся суть: при рабочем дне с 10:00 до 19:00 под дорогой тариф попадает промежуток с 10:00 до 13:00, ровно 3 часа из 9. Дальше идет самый длинный дешевый интервал в сутках, с 13:00 до 04:00 следующего дня, 15 часов подряд, и в него укладывается весь остаток рабочего дня, весь вечер и вся ночь. Плюс есть утренняя форточка 07:00–09:00.

Москве повезло почти максимально среди тех, кто вообще платит пиковый тариф. Я посчитал по 15 поясам, сколько пиковых часов попадает в рабочий день с 10:00 до 19:00 по местному времени:

Якутская команда съедает все 7 пиковых часов внутри рабочего дня и не имеет ни одной дешевой минуты с 10:00 до 19:00. Лондонская и нью-йоркская не платят пиковый тариф вообще: оба окна лежат у них в ночи, когда офис пустой. Разница в счете за одинаковую работу получается двукратной и зависит только от географии.

Тем, кто держит команду или инстансы в Европе, стоит добавить в календарь еще и переводы стрелок: в конце марта и в конце октября пиковые окна в местном времени уезжают на час, и расписание, привязанное к локальному времени, начинает промахиваться. В России и Казахстане этой проблемы нет.

Сколько это в деньгах

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

new_bill = offpeak_bill × (1 + p)

где p это доля токенов, обработанных в пиковые окна. Весь трафик вне пика дает p = 0 и счет по непиковому прайсу, весь трафик в пике дает p = 1 и удвоение. Московская команда с ровной нагрузкой внутри рабочего дня получает p ≈ 1/3, круглосуточный сервис с ровным трафиком получает p = 7/24 ≈ 0,29. Итоговый множитель к старому счету раскладывается на M_off × (1 + p), где первый сомножитель зависит только от профиля токенов, а второй только от расписания. Первое чинится кешем и выбором модели, второе чинится кроном, и это 2 независимых рычага.

Калькулятор без зависимостей, запускается и печатает разбор:

"""Пересчет счета DeepSeek V4 со старого плоского прайса на пик/непик.Все цены в USD за 1M токенов, по состоянию на 16.08.2026."""OLD = {    "flash": {"hit": 0.0028,   "miss": 0.14,  "out": 0.28},    "pro":   {"hit": 0.003625, "miss": 0.435, "out": 0.87},}OFFPEAK = {    "flash": {"hit": 0.007, "miss": 0.22, "out": 0.66},    "pro":   {"hit": 0.022, "miss": 0.66, "out": 1.98},}# пиковый тариф ровно в 2 раза дороже непикового по всем строкамPEAK = {m: {k: v * 2 for k, v in r.items()} for m, r in OFFPEAK.items()}def bill(rate, miss, hit, out):    """Стоимость одного запроса, USD."""    return (miss * rate["miss"] + hit * rate["hit"] + out * rate["out"]) / 1e6def report(model, in_tokens, cache_hit_rate, out_tokens, peak_share, req_per_day=1):    hit = in_tokens * cache_hit_rate    miss = in_tokens - hit    old = bill(OLD[model], miss, hit, out_tokens) * req_per_day    off = bill(OFFPEAK[model], miss, hit, out_tokens) * req_per_day    new = off * (1 + peak_share)    print(f"модель            {model}")    print(f"вход              {in_tokens:,} ток, попаданий в кеш {cache_hit_rate:.0%}")    print(f"выход             {out_tokens:,} ток")    print(f"доля в пике       {peak_share:.0%}")    print(f"было              ${old:.2f}/сут")    print(f"стало             ${new:.2f}/сут   ({new / old:.2f}x)")    print(f"если убрать пик   ${off:.2f}/сут   ({off / old:.2f}x), экономия "          f"{(1 - off / new) * 100:.1f}%")if __name__ == "__main__":    # московская команда 10:00-19:00: под пик попадает 3 часа из 9    report("pro", in_tokens=50_000, cache_hit_rate=0.80,           out_tokens=800, peak_share=1 / 3, req_per_day=20_000)

Долю p берите не из статьи, а из своих логов: гистограмма запросов по часам UTC за неделю, сумма токенов в интервалах 01:00–04:00 и 06:00–10:00, поделить на общую сумму. Одна SQL-строчка.

Вот что выдает калькулятор на типовых профилях при p = 1/3, то есть для московской команды с рабочим днем 10:00–19:00:

Разброс получается 2,33–2,93, для круглосуточного сервиса с ровным трафиком он сдвигается вниз до 2,26–2,84. Хуже всех досталось генеративным задачам, потому что выход подорожал в 2,28–2,36 раза против 1,52–1,57 у промаха кеша, и чем длиннее ответы модели, тем выше итоговый множитель. Поисковым и классификационным нагрузкам повезло больше.

Кеш при этом стал относительно менее выгодным, хотя бросать его никто не предлагает: на старом прайсе попадание стоило 1/120 от промаха, теперь 1/30, то есть экономия на входе упала с 99,2 до 96,7%. В абсолютных деньгах он все еще режет входную часть счета в 30 раз, просто больше из него не выжать.

Крон, который двигает батч

Второй рычаг работает только на том трафике, который может подождать. Интерактивные запросы двигать некуда, пользователь не согласится вернуться в 13:05. А вот переиндексация, разметка, генерация описаний и пересчет эмбеддингов ждут прекрасно, и для них перенос из окна 06:00–10:00 UTC означает минус 50% от их собственного счета. Если батч дает треть суточного трафика, общий счет падает на 25%.

Надежнее всего держать сервер в UTC и не связываться с переменными окружения:

# Пик DeepSeek: 01:00-04:00 и 06:00-10:00 UTC.# Старт в 10:05 UTC = 13:05 МСК, сразу после закрытия дневного окна.5 10 * * * /opt/batch/run.sh >> /var/log/llm-batch.log 2>&1# Тяжелый прогон в длинное дешевое окно, 22:05 UTC = 01:05 МСК.5 22 * * * /opt/batch/run-heavy.sh >> /var/log/llm-batch.log 2>&1

Если крон должен жить в московском времени, у vixie cron и cronie есть CRON_TZ=Europe/Moscow перед строкой расписания, а в Kubernetes с версии 1.27 стабильно поле .spec.timeZone у CronJob. С CRON_TZ я бы советовал сначала проверить, что он вообще работает на вашей системе: в busybox crond, который стоит в контейнерах на Alpine, этой переменной нет, присваивание молча проигнорируется, и джоба уедет на время контейнера. Проверяется не чтением документации, а строчкой date -u в крон и взглядом в лог на следующий день.

Дороже всего обходится другая мелочь. Батч, стартовавший в 13:05 МСК, имеет впереди 15 часов дешевого тарифа, но если он идет дольше, то в 04:00 МСК въезжает в ночное пиковое окно и продолжает жечь бюджет по двойной цене, никак об этом не сообщая. Долгую очередь надо гейтить по часам, а не надеяться, что успеет:

from datetime import datetime, timedelta, timezonePEAK_UTC = ((1, 4), (6, 10))  # часы UTC, [начало, конец)def is_peak(ts: datetime | None = None) -> bool:    h = (ts or datetime.now(timezone.utc)).hour    return any(lo <= h < hi for lo, hi in PEAK_UTC)def seconds_to_offpeak(ts: datetime | None = None) -> int:    """0, если сейчас непик. Иначе секунды до открытия дешевого тарифа."""    now = ts or datetime.now(timezone.utc)    for lo, hi in PEAK_UTC:        if lo <= now.hour < hi:            end = now.replace(hour=hi % 24, minute=0, second=0, microsecond=0)            if hi >= 24 or end <= now:                end += timedelta(days=1)            return int((end - now).total_seconds())    return 0def submit_all(tasks, client):    """Останавливаем подачу на входе в пик, а не в середине очереди."""    for i, task in enumerate(tasks):        if is_peak():            wait = seconds_to_offpeak()            log.warning("вошли в пик на задаче %d/%d, пауза %d c", i, len(tasks), wait)            time.sleep(wait)        client.complete(task)

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

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

Заодно стоит заглянуть в конфиг: в текущей табличке моделей у DeepSeek есть только deepseek-v4-flash и deepseek-v4-pro, а алиасов deepseek-chat и deepseek-reasoner, на которых до сих пор висят многие старые интеграции, там нет. По какому прайсу тарифицируются они, надо смотреть в биллинге, а не угадывать.

Посчитать свою p по логам, прогнать калькулятор, передвинуть 2 строчки в кроне и поставить гейт занимает рабочий день. Множитель, который придет в счет московской команде, лежит между 2,3 и 2,9, и кроном из него двигается 25%, те самые 3 часа с 10:00 до 13:00.

Источники

• DeepSeek API Docs, Models & Pricing — действующий прайс и формулировка пиковых окон

• DeepSeek API Docs, релиз DeepSeek-V4-Pro, 13.08.2026 — анонс перехода на пик/непик с 16:00 UTC 16 августа

• DeepSeek API Docs, релиз V4 Preview, 24.04.2026 — стартовый прайс V4 (таблица на картинке /img/v4-price-en.png)

• InfoWorld: DeepSeek raises some V4 prices by more than 10x — диапазон «52% to 1,100%» и июльские цены

• TLDL: DeepSeek API Pricing, июль 2026 — прайс, действовавший до 16 августа, включая цены попаданий в кеш

• Quartz: DeepSeek raising API prices by up to 1,100% — тот самый заголовок