Цифру «+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 миллион токенов.

Строка счета

Модель

Было, $/1M

Непик, $/1M

Пик, $/1M

Множитель в пик

Вход, попадание в кеш

flash

0,0028

0,007

0,014

5,00×

Вход, промах кеша

flash

0,14

0,22

0,44

3,14×

Выход

flash

0,28

0,66

1,32

4,71×

Вход, попадание в кеш

pro

0,003625

0,022

0,044

12,14×

Вход, промах кеша

pro

0,435

0,66

1,32

3,03×

Выход

pro

0,87

1,98

3,96

4,55×

Жирная строка и есть источник заголовков. Делим 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 по местному времени:

Часовой пояс

Города

Пиковых часов в рабочем дне

Когда именно

UTC+0

Лондон зимой

0 ч

—

UTC−4

Нью-Йорк летом

0 ч

—

UTC−7

Сан-Франциско летом

1 ч

18:00–19:00

UTC+1

Берлин зимой

1 ч

10:00–11:00

UTC+2

Калининград, Берлин летом

2 ч

10:00–12:00

UTC+3

Москва, Минск, Стамбул

3 ч

10:00–13:00

UTC+4

Тбилиси, Ереван, Баку, Самара

4 ч

10:00–14:00

UTC+5

Екатеринбург, Алматы, Ташкент

4 ч

11:00–15:00

UTC+6

Омск, Бишкек

4 ч

12:00–16:00

UTC+7

Новосибирск, Красноярск

5 ч

10:00–11:00 и 13:00–17:00

UTC+8

Иркутск, Пекин

6 ч

10:00–12:00 и 14:00–18:00

UTC+9

Якутск, Чита

7 ч

10:00–13:00 и 15:00–19:00

UTC+10

Владивосток

6 ч

11:00–14:00 и 16:00–19:00

UTC+11

Магадан, Сахалин

5 ч

12:00–15:00 и 17:00–19:00

UTC+12

Камчатка

4 ч

13:00–16:00 и 18: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"]) / 1e6


def 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:

Профиль нагрузки

Модель

Множитель счета при p=1/3

Он же при p=0

RAG, 50K вход при 80% попаданий, 800 ток выход

pro

2,33×

1,75×

Чат-ассистент, 10K вход при 50% попаданий, 1K выход

pro

2,35×

1,76×

Классификация, 8K вход при 90% попаданий, 50 ток выход

flash

2,37×

1,77×

Генерация текста, 2K вход без кеша, 4K выход

pro

2,83×

2,12×

Генерация текста, 2K вход без кеша, 4K выход

flash

2,93×

2,20×

Разброс получается 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, timezone

PEAK_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 0


def 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.

Источники