Цены на API DeepSeek в часы пик делают маршрутизацию модели проблемой планирования.

Цены на API DeepSeek V4 превратились из простого вопроса о выборе модели в вопрос о сроках.

На официальной странице цен на API компании теперь перечислены DeepSeek V4 Flash и DeepSeek V4 Pro с большими контекстными окнами на 1 миллион токенов, базовыми URL-адресами в формате OpenAI и Anthropic, а также отдельными категориями оплаты за входные и выходные токены с попаданием в кеш, промахом в кеш и выходными токенами. В отчетах, собранных Techmeme 13 августа, говорится, что DeepSeek поднимает цены на модели V4 и вводит динамическое выставление счетов в пиковую и внепиковую часы, при этом новые цены вступают в силу в 16:00 UTC 16 августа 2026 года.

Это нечто большее, чем обычное обновление таблицы цен. Для команд, использующих агенты с большим объемом поиска, помощников по кодированию с длинным контекстом, задания пакетного анализа или продукты искусственного интеллекта, ориентированные на клиентов, стоимость запроса DeepSeek теперь может зависеть не только от того, какая модель выбрана, но и от того, когда запрос отправлен и какая часть запроса может быть обработана из кэша.

Что изменилось в выставлении счетов DeepSeek V4

В текущей документации API DeepSeek представлены версии V4 Flash и V4 Pro, доступные через обе версии. Форматы API в стиле OpenAI и Anthropic. Это важно, поскольку многие разработчики уже направляют DeepSeek вместе с другими поставщиками через уровни совместимости, а не пишут код приложения для конкретного поставщика.

Примечательной структурой выставления счетов является разделение между входными данными при попадании в кеш, входными и выходными данными при промахе в кэше. На практике это означает, что повторяющиеся префиксы подсказок, системные инструкции, схемы инструментов или длинные повторно используемые блоки контекста могут иметь профиль затрат, отличный от вновь отправленного текста подсказки. Это уже было важной частью стоимости DeepSeek V4-Pro. Новый уровень пиковой/непиковой нагрузки добавляет еще одну переменную: стоимость одной и той же рабочей нагрузки может различаться в зависимости от времени ее выполнения.

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

Почему важны цены в пиковые и непиковые часы

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

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

Это меняет проблему маршрутизации. Шлюз, выбирающий между моделями на основе качества, задержки и цены токена, теперь должен учитывать время. Если DeepSeek V4 Pro экономически эффективен в часы пик, но дорог в часы пик, приложение может предпочесть другую модель в течение дня и вернуться к DeepSeek позже. Если V4 Flash остается привлекательным для быстрых задач, но экономичность кэша ухудшается для длинных общих префиксов, возможно, потребуется пересмотреть саму архитектуру запросов.

Для команд, использующих шлюз AI API, наиболее полезной функцией может быть не еще одно переключение модели. Это может быть политика: немедленно отправлять интерактивные запросы, ставить в очередь несрочные задания, предупреждать, когда запрос попадает в окно с более высокой стоимостью, или применять бюджеты на уровне команды до начала пакетного выполнения. Это имеет непосредственное отношение к инфраструктуре в стиле Model Gate, поскольку унифицированное выставление счетов, аналитика использования и контроль маршрутизации становятся более ценными, когда цены поставщиков являются динамическими, а не статичными.

Кто наиболее уязвим?

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

Команды, использующие DeepSeek через интерфейсы, совместимые с OpenAI, не должны полагать, что совместимость защищает их от изменений в выставлении счетов. Запрос может показаться знакомым, но счет по-прежнему соответствует правилам ценообразования DeepSeek для конкретной модели.Доступ в антропном формате создает ту же проблему с другой стороны: более простая интеграция не устраняет необходимости понимать категории счетов поставщиков.

Разработчикам, поддерживающим калькуляторы цен, информационные панели реселлеров или внутренние инструменты возврата платежей, следует быстро обновлять предположения. Если таблица цен на продукт по-прежнему рассматривает DeepSeek V4 как единую фиксированную стоимость за токен, это может занижать или завышать реальное использование. Это может исказить прибыль клиентов, бюджеты команд и решения по выбору модели.

Отделы закупок и финансов также должны обратить на это внимание. Динамические цены на API усложняют ежемесячное прогнозирование. Рабочая нагрузка, которая была доступной при тестировании, может вести себя по-другому в рабочей среде, если пользовательский трафик концентрируется в периоды пиковой нагрузки. Тот же риск применим к демонстрациям, оценкам и тестам агентов: сравнение моделей, проводимое в одно время дня, может не отражать экономику непрерывного выполнения одного и того же рабочего процесса.

Что команды должны делать сейчас

Следующий шаг — отделить техническую миграцию от финансовой проверки. Изменение кода может не потребоваться, если приложения уже вызывают DeepSeek V4 Flash или V4 Pro через поддерживаемые форматы API. Но предположения о выставлении счетов, оповещения и информационные панели нуждаются в пересмотре.

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

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

Что остается неопределенным, так это точное влияние цен в реальном времени для каждой рабочей нагрузки. Официальная документация DeepSeek подтверждает форматы моделей, контекстное окно и категории выставления счетов, видимые на странице цен, а вторичные отчеты описывают активацию 16 августа в часы пик/непиковое время и повышение цен. Точная разница в стоимости зависит от текущей активной таблицы, времени отправки запросов, поведения кэша и длины выходных данных.

Более широкий урок менее неопределенен. Цены на LLM становятся действующими. Выбор модели, время запроса, дизайн кэша и бюджетная политика теперь связаны между собой. Для разработчиков и предприятий контроль затрат на AI API больше не является просто работой с электронными таблицами после развертывания; это часть того, как необходимо маршрутизировать производственные системы искусственного интеллекта.