deepseek v4 api: как не пустить неподтверждённую версию в backlog

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

Механизм всегда один. Задача получает оценку раньше, чем зависимость получает источник. Дальше оценку складывают в спринт, спринт кладут в roadmap, а roadmap показывают заказчику. К этому моменту никто уже не помнит, что число «мы успеем за две недели» опиралось на скриншот бенчмарка, а не на страницу документации. Технический долг здесь рождается не из плохого кода, а из задачи, которой назначили срок раньше, чем проверили её основание.

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

Платите в рублях за DeepSeek API без наценки на токены через provod.ai

Факты о deepseek v4 api, которые подтверждены источниками

Начнём с того, что можно привязать к первоисточнику, потому что именно это отделяет проверяемую зависимость от слуха. По официальному блогу API-документации DeepSeek от 24 апреля 2026 года анонсирован открытый «V4 Preview» с двумя вариантами, и API стал доступен в тот же день. Это первое первоисточное подтверждение, что версия вообще существует и вызывается по сети.

Официальный справочник «List Models» и страница «Models & Pricing» на дату проверки 18 июля 2026 года перечисляют ровно два идентификатора, которые можно указывать как проверяемую зависимость: deepseek-v4-pro (1.6T всего, 49B активных параметров) и deepseek-v4-flash (284B всего, 13B активных). У обоих окно контекста 1M токенов и максимум вывода 384K токенов. Всё, что выходит за пределы этих двух строк каталога, на дату проверки источника не имеет.

Важная тонкость статуса. Домашняя страница DeepSeek по-прежнему называет текущий релиз «DeepSeek-V4 Preview» и не использует в своём маркетинге слова «V4 Pro» или «V4 Flash». То есть «версия существует и доступна через API» и «версия официально вышла из preview» - это два разных события. Независимое издание TechNode 30 июня 2026 года сообщило, что не-preview релиз запланирован на середину июля вместе с новой пиковой тарификацией, но это анонс в пересказе издания, а не первоисточная страница документации.

Есть и жёсткий срок, который делает часть старых задач просроченными автоматически. По той же официальной странице устаревшие имена deepseek-chat и deepseek-reasoner полностью отключаются после 24 июля 2026 года, 15:59 UTC, после чего живут только как алиасы к deepseek-v4-flash. Любая карточка, завязанная на старые имена, требует переуказания зависимости до этой даты - и, поскольку 24 июля наступает через несколько дней после проверки, статус стоит перепроверить прямо перед планированием.

Когда зависимость подтверждена таким образом, её можно заводить в работу через агрегатор вроде provod.ai (российский OpenRouter), где модель выбирается из фактического списка каталога, а не по скриншоту из соцсетей. Ключевое слово - «когда подтверждена»: сам по себе доступ к агрегатору не доказывает существование конкретной версии.

Ниже эти два подтверждённых идентификатора и набор неподтверждённых свойств сведены в одну таблицу для быстрой сверки при планировании.

Как слух превращается в плановую зависимость?

Слух редко приходит один. За три месяца до апрельского подтверждения, 21 января 2026 года, разработчики заметили в официальном репозитории DeepSeek FlashMLA неразъяснённый идентификатор «MODEL1». Открытый issue с просьбой объяснить его остался без ответа мейнтейнеров. Это показательный случай: даже первоисточный код-артефакт сам по себе не был подтверждением модели. Строчка в коде - это зацепка для расследования, а не спецификация для оценки.

Ещё нагляднее история с числами. 1 апреля 2026 года по соцсетям разошёлся скриншот «утёкших» бенчмарков V4 - 83.7% на SWE-Bench Verified, 99.4% на AIME 2026 и другие. Сообщество фактчекеров показало, что показатель AIME математически невозможен по официальной системе оценивания, а DeepSeek эти цифры никогда не подтверждал. И всё же именно такое число легко просачивается в задачу как приёмочный критерий: «должно давать не хуже, чем в утечке». Спецификация, у которой нет источника, заражает оценку так же, как и код.

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

Разделение факта и гипотезы прямо в backlog

Спорная позиция по умолчанию звучит так: достаточно пометить слух в реестре фактов, а backlog оставить прежним. Она не выдерживает нагрузки, потому что оценивают и планируют не по реестру фактов, а по карточкам. Если карточка с неподтверждённой зависимостью лежит в общем спринте, её оценят как обычную работу - и статус «слух» в другом документе на это не повлияет. Отсюда нормативная позиция статьи: неподтверждённая версия не должна быть плановой зависимостью. Это оценочное суждение автора. Проверяемым фактом о DeepSeek оно не является.

Рабочий инструмент - доска на четыре колонки: задача, заявленная зависимость от версии, первичный источник, статус. Ниже она прогнана по типовым формулировкам, в которых зависимость от версии приходит в задачу. Смысл в нормализации входа: разные написания одной и той же просьбы должны сходиться к одной ветке, иначе один и тот же слух заведут в backlog дважды под разными именами.

Логика колонки «статус» простая. Есть первичный источник и однозначный ID - карточка идёт в рабочий backlog и получает оценку. Источника нет - карточка уходит в ветку гипотез без срока. Написание без буквы «v», как в deepseek 4 api, или разговорная форма deepseek v4 pro апи не меняют статус: важна зависимость под запросом, а не орфография. Отдельно стоит deepseek coder api - в текущем списке из двух идентификаторов такой модели нет, поэтому по умолчанию это гипотеза, пока не появится строка в каталоге.

Сколько стоит deepseek v4 pro и что с «бесплатным» доступом?

Экономика - место, где слух наносит самый дорогой урон, потому что смету защитить сложнее, чем код. Запросы вроде deepseek v4 pro стоимость упираются в двойной статус. Существование платного доступа к deepseek-v4-pro подтверждено официальной страницей цен. А вот пиковая/непиковая тарификация (двойная цена в 9:00-12:00 и 14:00-18:00), о которой писал TechNode со ссылкой на анонс DeepSeek, на момент проверки официальной страницы pricing там ещё не отражена. Это прямое расхождение между анонсом и документацией, и закладывать его в смету без повторной проверки нельзя.

Отдельная ловушка - «бесплатно». Запросы deepseek v4 api free и deepseek v4 api бесплатно приходят постоянно, но в первоисточниках на дату проверки нет подтверждённого бесплатного тарифа для V4. Значит, любая задача, чья экономика построена на «возьмём бесплатный доступ», опирается на предположение. Её место - в ветке гипотез, а не в финансовой модели квартала. То же касается deepseek v4 flash free api: пока строки о бесплатном лимите нет в каталоге, назначать такой задаче срок попросту не на чем.

Для российской команды к этому добавляется вопрос доступа: прямой путь к API DeepSeek упирается в оплату и сеть, поэтому маршрут часто идёт через агрегатор. Для сметы здесь важно ровно одно свойство: у provod.ai в этом сценарии модели идут по ценам провайдера без наценки сверху, с оплатой в рублях, - значит официальная страница pricing остаётся той же базой расчёта, что и при прямом доступе, и сверять смету можно с ней. На проблему статуса версии это не влияет: агрегатор не подтверждает, что «V4 вышел из preview», он лишь даёт способ оплатить и вызвать те модели, которые уже есть в каталоге.

Оба случая - конец длинной цепочки. Ниже она развёрнута по датам: видно, в какой момент появилось первое подтверждение и в какой - число, которого никто не проверял.

Перевод backlog на две скорости

Альтернатив у двухскоростного подхода две, и обе хуже. Первая - оценивать V4-задачи как обычные; тогда слух получает срок и становится долгом. Вторая - заморозить весь backlog до подтверждения версии; тогда подтверждённые задачи простаивают из-за слухов. Принятая цена компромисса - вести две ветки параллельно. Это менее эффектно, чем один чистый roadmap, зато проверенная работа не блокируется ожиданием непроверенного.

Порядок действий такой.

1. Протрассировать backlog. По каждой карточке выписать заявленную зависимость от версии, первичный источник и статус - три колонки доски, заполненные до всякой оценки.
2. Применить критерии отклонения. Карточка не идёт в рабочий backlog как подтверждённая, если под заявленной зависимостью нет первичного источника или если статус версии нельзя проверить на дату планирования. Отдельный случай - карточка, у которой зависимости от версии нет вовсе: её нужно переформулировать, а не оценивать.
3. Развести ветки. Подтверждённые задачи остаются в спринте с оценкой. Гипотезы уходят в отдельную ветку без срока и без стори-поинтов - они вернутся, когда появится первичный источник.
4. Переуказать зависимости под срок отключения. Всё, что завязано на deepseek-chat и deepseek-reasoner, перевести на актуальные ID до 24 июля 2026 года, перепроверив страницу перед этой датой.
5. Сверять зависимость с фактическим каталогом, а не с тредом. Один вызов List Models показывает, какие ID реально существуют.

Пятый шаг стоит зашить в CI, чтобы человек не сверял руками. Проверка тривиальна и работает через любой OpenAI-совместимый эндпоинт:

from openai import OpenAI

client = OpenAI(api\_key="ВАШ\_КЛЮЧ", base\_url="https://api.provod.ai/v1")

# ID, заявленные как зависимости в карточках backlog expected = {"deepseek-v4-pro", "deepseek-v4-flash"} available = {m.id for m in client.models.list().data}

missing = expected - available assert not missing, f"Зависимость без строки в каталоге: {missing}"

Смысл теста в простом правиле: если задача ссылается на ID, которого нет в живом списке моделей, она не проходит как подтверждённая. Такой assert ловит и опечатку в имени, и попытку завести гипотезу под видом факта. Запросы вроде deepseek v4 agent app api тоже проходят эту проверку: агентный сценарий допустим ровно настолько, насколько подтверждён ID под ним.

Чего эта доска не решает

Доска - не факт-проверка существования версии. Она не отвечает на вопрос, реален ли конкретный релиз; она отвечает на вопрос, можно ли по нему назначать срок. Если завтра появится третий идентификатор, доска не узнает об этом сама - её питают трассировка и ручная сверка с первоисточником.

Она не заменяет перепроверку статуса. «V4 существует и вызывается по API» подтверждено с 24 апреля 2026 года, но «V4 официально вышел из preview» - отдельное событие, заявленное независимым изданием на середину июля; на 18 июля 2026 года завершённость этого перехода без повторного визита на официальную страницу утверждать нельзя.

И она не защищает от честных ошибок в самих источниках. Расхождение между анонсом пиковых цен и текущей документацией - ровно такой случай: доска покажет, что источники расходятся, но выбор между ними остаётся за человеком.

CTA

FAQ

Существует ли deepseek v4 api вообще?

Да: официальный анонс V4 Preview и доступность API датированы 24 апреля 2026 года. Не подтверждено другое - что релиз уже официально вышел из статуса preview.

Какие имена моделей можно указывать как зависимость?

Ровно два: deepseek-v4-pro и deepseek-v4-flash. Остальные написания из запросов - варианты формулировки, а не новые модели.

Что делать со старыми deepseek-chat и deepseek-reasoner?

Переуказать зависимость на актуальные ID до 24 июля 2026 года, 15:59 UTC, и перепроверить официальную страницу прямо перед этой датой.

Можно ли верить утёкшим бенчмаркам?

Нет: у апрельского скриншота нет первоисточника, а заявленные 99.4% на AIME математически невозможны по официальной системе оценивания. Как приёмочный критерий такие цифры не годятся.

provod.ai — от идеи и текста до изображения, видео и звука

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

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Каждый формат оплачивается по базовой цене поставщика 1:1: provod.ai объединяет расчёты, но не добавляет свою наценку.

Соберите медиапроизводство на provod.ai: форма регистрации · цены на модели · защита данных по 152-ФЗ · главная provod.ai

Источники

• DeepSeek API Docs, анонс V4 Preview, дата проверки 2026-07-18: https://api-docs.deepseek.com/news/news260424/
• DeepSeek API Docs, Models & Pricing, 2026-07-18: https://api-docs.deepseek.com/quick_start/pricing/
• DeepSeek API Docs, List Models, 2026-07-18: https://api-docs.deepseek.com/api/list-models/
• GitHub, deepseek-ai/FlashMLA, issue про MODEL1, 2026-07-18: https://github.com/deepseek-ai/FlashMLA/issues/155
• TechNode, анонс не-preview релиза и пиковых цен, 2026-07-18: https://technode.com/2026/06/30/deepseek-to-launch-v4-in-mid-july-with-new-peak-time-api-pricing/
• Overchat AI Hub, разбор недостоверного бенчмарк-скриншота, 2026-07-18: https://overchat.ai/ai-hub/deepseek-v4
• DeepSeek, домашняя страница со статусом Preview, 2026-07-18: https://www.deepseek.com/en/