DeepSeek V4 и «серое» окно перед релизом: что известно о модели и почему спорят о routing

Что стало новостью

19 июля на Hugging Face вышла community-публикация DeepSeek V4 GA Is in Grayscale Testing: Architecture, Routing Controversy, and What We Actually Know. Автор утверждает, что часть пользователей API могла наблюдать поведение GA-candidate билда DeepSeek V4, а сильные ответы на сложных coding-задачах запустили спор о маршрутизации запросов.

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

Поводом стала не пресс-конференция и не официальный changelog, а community-статья на Hugging Face. Автор описал возможное «серое» тестирование DeepSeek V4 GA: по его версии, часть трафика могла попадать на кандидатный билд, который еще не объявлен стабильным релизом. В том же тексте обсуждается routing controversy, то есть гипотеза о том, что необычно сильные ответы могли быть связаны не только с нативными V4-весами, но и с маршрутизацией или особенностями backend.

Такой сигнал нельзя игнорировать. Hugging Face остается значимой площадкой для открытых моделей, model cards, технических обсуждений и независимой проверки. Но его нельзя приравнивать к позиции DeepSeek. По сравнению с официальной карточкой deepseek-ai/DeepSeek-V4-Pro, документацией API или релизной заметкой community-публикация имеет меньшую доказательную силу.

Корректная формула сейчас такая: появился публичный сигнал о возможном grayscale-тестировании DeepSeek V4, но официально подтверждены V4 Preview, API-модели, открытые веса, параметры и миграция со старых model ID. Это не делает дискуссию второстепенной. Она показывает, насколько трудно оценивать frontier-модель, когда один бренд существует сразу как открытый checkpoint, официальный API и, возможно, разные endpoints у интеграторов.

Официальная картина сдержаннее. DeepSeek еще 24 апреля объявила DeepSeek V4 Preview, открытые веса и API-доступ к двум моделям: V4-Pro и V4-Flash. В документации указаны контекстное окно, цены, лимиты и дата отключения старых alias-имен deepseek-chat и deepseek-reasoner. Отдельного официального объявления GA-релиза или публичной политики grayscale testing в предоставленном наборе источников нет.

Эта история важна не как очередной слух о релизе, а как повод разобрать устройство современных AI-сервисов. API-ответ не всегда равен работе «чистых весов»: на него влияют версия модели, режим рассуждения, inference-слой, кэш, fallback и маршрутизация. Для MoE-модели с контекстом до 1 млн токенов обслуживание становится частью продукта, а не нейтральной трубой между пользователем и checkpoint.

Что DeepSeek подтвердила официально

24 апреля 2026 года DeepSeek объявила DeepSeek V4 Preview как live & open-sourced. В официальной новости названы две версии: DeepSeek-V4-Pro и DeepSeek-V4-Flash. Обе доступны через API и связаны с режимами Thinking и Non-Thinking. Для пользователя это две разные продуктовые роли: более тяжелая версия для качества и рассуждения и более легкая версия для скорости, массовых запросов и контроля стоимости.

По данным DeepSeek, V4-Pro имеет 1,6 трлн total parameters и 49 млрд activated parameters. V4-Flash имеет 284 млрд total parameters и 13 млрд activated parameters. Разница между total и activated особенно существенна для MoE-моделей: сеть содержит много экспертных блоков, но при конкретной обработке активируется только часть. Total parameters показывает общий масштаб, а activated parameters ближе к вычислительной нагрузке одного прохода.

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

Для интеграторов особенно важен другой факт: отключение legacy-имен. В документации указано, что deepseek-chat и deepseek-reasoner должны быть deprecated 24 июля 2026 года в 15:59 UTC. До этого они соответствуют non-thinking и thinking режимам deepseek-v4-flash. Это уже не слух о релизе, а конкретная миграционная задача: старые alias лучше заменить на явные model ID.

Здесь нужно различать две линии. Первая линия продуктовая: DeepSeek дает Preview, API-доступ, цены, лимиты и модельные идентификаторы. Вторая линия рыночная: сообщество пытается понять, не идет ли уже подготовка GA и не меняется ли backend для части пользователей. Первая линия подтверждается официальными материалами. Вторая остается интерпретацией наблюдений.

Практический вывод для команд, которые уже используют DeepSeek API, довольно прямой. Если в коде, конфигурациях, low-code сценариях или агентных цепочках остались старые alias, их нужно искать заранее. После отключения legacy-имен проблема может выглядеть не как крупный релизный сбой, а как набор точечных отказов в разных сервисах: ботах поддержки, внутренних ассистентах, пайплайнах анализа документов и тестовых стендах.

Цитата в переводе

«Мы представляем preview-версию серии DeepSeek-V4, включающую две сильные языковые модели Mixture-of-Experts (MoE): DeepSeek-V4-Pro с 1,6 трлн параметров (49 млрд активируемых) и DeepSeek-V4-Flash с 284 млрд параметров (13 млрд активируемых). Обе поддерживают контекст длиной один миллион токенов.»

Архитектура V4: почему это не «модель побольше»

DeepSeek V4 относится к MoE-семейству. Mixture-of-Experts - архитектура, в которой модель содержит множество экспертных блоков, но для каждого токена использует не всю сеть, а выбранную часть. Такой подход позволяет увеличивать общий объем параметров без пропорционального роста вычислений на каждый запрос. В V4 эта логика сочетается с длинным контекстом и attention-механизмами, описанными в технических материалах и документации.

Поэтому параметры Pro и Flash нужно читать как описание компромисса. Pro с 1,6T total и 49B activated parameters рассчитана на более высокий потолок качества. Flash с 284B total и 13B activated parameters выглядит как слой для более дешевых и массовых сценариев. Поддержка контекста в 1 млн токенов у обеих моделей расширяет поле применения, но одновременно повышает требования к serving-инфраструктуре.

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

Здесь появляется связь с routing controversy. Если обслуживание устроено сложно, API-ответ может зависеть от маршрута запроса: версии backend, режима, кластера, fallback или оптимизаций serving-слоя. Это не доказывает стороннюю маршрутизацию в случае DeepSeek V4, но объясняет, почему сообщество смотрит не только на benchmark-таблицы, но и на поведение конкретного endpoint в конкретные даты.

Для пользователя MoE может выглядеть как обычная модель в API. Для инженера это набор решений о выборе экспертов, кэшировании, распределении нагрузки, задержках и цене. Поэтому фраза «V4 стала лучше отвечать на coding-задачи» без уточнения endpoint, даты, режима и параметров запроса мало что доказывает. Она описывает наблюдение, но не раскрывает, какой слой системы дал результат.

Именно поэтому DeepSeek V4 нельзя оценивать только как «модель побольше». Ее конкурентоспособность складывается из архитектуры, открытых весов, доступности в API, стоимости токенов, лимитов, режима thinking, качества serving и понятности миграции. Чем длиннее контекст и чем сложнее MoE-логика, тем важнее становится инфраструктурная часть продукта.

Grayscale testing: что означает термин и что не доказано

Grayscale testing, или «серое» тестирование, обычно означает постепенное включение новой версии продукта для ограниченной доли пользователей. Такой подход снижает риск массового сбоя: команда может отслеживать задержки, жалобы, стоимость, стабильность и качество до полного выката. Для языковых моделей это особенно чувствительно, потому что смена версии проявляется не только в uptime, но и в стиле ответа, безопасности, склонности к ошибкам и стоимости генерации.

В случае DeepSeek V4 граница проходит между наблюдением и подтверждением. Community article утверждает, что с 17 июля часть пользователей могла попадать на GA-candidate билд. Но это утверждение не равно официальному признанию DeepSeek. В доступных источниках подтверждены V4 Preview, API-модели и открытые веса, но не отдельный публичный запуск GA и не официальная политика grayscale testing.

Формулировка «DeepSeek V4 вышла в GA» сейчас была бы сильнее доказательств. Точнее говорить так: в сообществе появился сигнал, который интерпретируют как возможное предрелизное тестирование GA-кандидата. Пока финальная версия официально не обозначена, июльские API-ответы лучше фиксировать как наблюдения по конкретному endpoint, model ID, режиму и дате, а не как доказательство возможностей окончательного релиза.

Для публичной коммуникации это не формальность. Preview, GA-candidate, grayscale rollout и stable GA означают разные уровни ответственности. У каждого статуса свои ожидания по стабильности, совместимости, документации и повторяемости результатов. Если смешать эти слова, можно неправильно оценить риски внедрения: команда решит, что работает со стабильным релизом, хотя фактически тестирует сервис в переходном состоянии.

С другой стороны, само наличие community-сигнала полезно. Оно показывает, где пользователи видят изменения поведения, какие задачи становятся индикаторами возможного обновления и какие метаданные нужно сохранять при тестировании. Для рынка это способ быстрее заметить сдвиг, но не замена официального объявления.

Routing controversy: почему спор не сводится к обвинению

Самая чувствительная часть дискуссии - routing. В узком смысле это выбор маршрута обработки запроса: модель, режим, провайдер, кластер, fallback или комбинация этих элементов. В MoE есть внутренний routing, то есть выбор экспертов внутри самой модели. В API-инфраструктуре есть внешний routing: выбор backend, версии модели или поставщика. Эти уровни нельзя смешивать.

Публикация на Hugging Face описывает признаки, которые автор считает совместимыми с гипотезой маршрутизации: сильные ответы на сложных coding-задачах, изменения стиля рассуждения, отличия поведения на чувствительных примерах и динамику ответов в окне наблюдения. Но даже в такой постановке это не прямое доказательство сторонней модели. Возможны и другие объяснения: неанонсированный билд, внутренний routing, обновление serving-слоя, разные reasoning-режимы или изменение prompt-handling.

Для индустрии существенен не сам слух, а методологическая проблема. Если тестировать модель только через API, измеряется не чистый checkpoint, а весь сервисный путь. Для бизнеса это может быть приемлемо: заказчику важны итоговый ответ, цена и стабильность. Но для научного сравнения, закупки и compliance нужно понимать, что именно проверяется. Открытые веса deepseek-ai/DeepSeek-V4-Pro дают один уровень проверяемости, официальный API - другой, сторонние endpoints - третий.

На текущей базе нельзя утверждать, что DeepSeek тайно проксирует запросы к сторонней модели. Такой вывод был бы сильнее источников. Можно сказать иначе: июльская дискуссия показывает, что для V4 нужно разделять результаты на открытых весах, результаты официального API и результаты внешних провайдеров, если они участвуют в цепочке использования. Для coding-бенчмарков эта разница особенно заметна: небольшое изменение режима или backend может существенно повлиять на итог.

Routing controversy также показывает, почему современные AI-сервисы трудно проверять обычным пользовательским способом. Два человека могут отправить похожий prompt, получить разные ответы и сделать противоположные выводы о модели. Без фиксации версии, endpoint, режима и параметров это остается анекдотом, даже если ответ действительно впечатляет.

Профессиональная проверка должна быть скучнее и строже. Нужно сохранять исходный prompt, параметры генерации, дату, идентификатор модели, endpoint, latency, скорость вывода и повторные прогоны. Если используются открытые веса, нужно фиксировать checkpoint, inference engine, quantization и конфигурацию оборудования. Только так можно понять, сравниваются ли веса, API-сервис или конкретная интеграция.

Цены, лимиты и почему Flash может стать массовым слоем

В официальной таблице DeepSeek API Pricing для обеих моделей указаны 1M context length и 384K max output. Для deepseek-v4-flash цена cache hit input составляет $0.0028 за 1 млн токенов, cache miss input - $0.14, output - $0.28. Для deepseek-v4-pro: cache hit input - $0.003625 за 1 млн токенов, cache miss input - $0.435, output - $0.87. Также указаны concurrency limits: 2500 для Flash и 500 для Pro.

Эти параметры показывают продуктовую логику. Pro выглядит как вариант для задач, где оправдана более высокая стоимость: сложный код, аналитика, рассуждение, длинные документы. Flash - вероятный массовый слой для чат-ботов, ассистентов, RAG-систем, классификации, извлечения данных и внутренних корпоративных сценариев. Именно Flash временно наследует старые alias-имена deepseek-chat и deepseek-reasoner, что делает миграцию особенно актуальной.

Разница между cache hit и cache miss превращает архитектуру приложения в часть экономики. Cache hit означает, что повторяющийся входной контекст уже закэширован и обходится дешевле. Для продуктов с постоянными системными инструкциями, шаблонными агентными сценариями или повторяемыми документами это может снизить стоимость. Экономия, однако, не возникает сама: приложение должно повторно использовать контекст и не ломать кэш мелкими изменениями.

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

На практике это меняет разговор с финансовым директором и владельцем продукта. Уже недостаточно спросить, сколько стоит миллион токенов. Нужно понять долю cache hit, средний размер входа, длину ответа, частоту повторного использования контекста, долю задач для Pro и долю задач для Flash. Иначе тест на нескольких красивых prompts не покажет реальную стоимость production-сценария.

Для интеграторов важны и concurrency limits. Высокий лимит Flash лучше соответствует массовым нагрузкам, где тысячи параллельных запросов важнее максимального качества на одной задаче. Pro с более низким лимитом логично держать для ограниченного класса запросов, где нужен лучший reasoning или более сложная обработка. Если маршрутизация внутри приложения сделана грубо, экономическая модель быстро ломается.

Открытые веса и проверяемость

Карточка deepseek-ai/DeepSeek-V4-Pro на Hugging Face важна тем, что переводит разговор из плоскости «верим API или не верим» в более проверяемую область. В репозитории указаны открытые веса, лицензия MIT, model card, файлы и технические материалы. Это не означает, что любой пользователь легко поднимет V4-Pro у себя: масштаб модели остается огромным. Но возможность независимого развертывания отличает open-weight подход от полностью закрытого API.

Открытые веса не снимают всех вопросов. Производительность локального или стороннего deployment зависит от quantization, inference engine, GPU-конфигурации, версии библиотек и реализации attention. Модель такого класса нельзя оценивать по принципу «скачал веса, получил тот же сервис, что у разработчика». Но открытость дает исследователям и крупным интеграторам шанс проверить checkpoint отдельно от официального endpoint.

Документация Transformers по DeepSeek V4 важна для экосистемы: поддержка в распространенных инструментах снижает барьер для экспериментов, сравнений и production-пилотов. В результате V4 будут оценивать не только по API, но и через самостоятельные сборки, open-source serving и адаптации под конкретные задачи.

Спор о routing не обнуляет значение V4. Он подчеркивает необходимость разделения: если речь о capabilities весов, нужны воспроизводимые тесты на известном checkpoint. Если речь о покупке API-сервиса, нужны latency, стоимость, стабильность, лимиты и прозрачность model ID. Это разные проверки, и смешивать их рискованно.

Для исследователя открытые веса дают возможность задавать более точные вопросы. Например, отличается ли поведение официального API от поведения того же checkpoint в независимом окружении. Или насколько влияет выбранный inference engine на скорость и качество длинного контекста. Или как меняется результат после quantization. В закрытом API такие вопросы часто остаются недоступными.

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

Российский контекст: интерес есть, но V4 нельзя подменять историей R1

Для российской аудитории DeepSeek остается заметным именем из-за открытых весов, стоимости, темпа релизов и более сложной геополитической карты доступа к западным AI-сервисам. РБК в материале о китайском ИИ и США описывал DeepSeek как заметный фактор распространения ИИ в условиях ограниченного доступа к американским продуктам. Но этот фон нельзя автоматически переносить на V4.

Показатели распространения и обсуждения в российской прессе относятся к DeepSeek R1 и общему интересу к китайским моделям, а не к подтвержденному внедрению V4. Если компания тестировала R1 или использовала DeepSeek раньше, из этого не следует, что она уже внедрила V4-Pro или V4-Flash. Для такого вывода нужны отдельные данные.

Практическая связь все же есть. Если растет интерес к open-weight и недорогим моделям, DeepSeek V4 будет рассматриваться как кандидат для пилотов: корпоративные ассистенты, работа с длинными документами, анализ кода, агентные сценарии, внутренние RAG-системы. Но для чувствительных данных потребуются отдельные решения по хранению, локальному развертыванию, журналированию и юридической оценке.

Остается и вопрос доверия. Дискуссия вокруг китайских AI-моделей, ограничений и киберрисков делает DeepSeek не только технологическим, но и governance-объектом. Для российских компаний это не причина автоматически отказываться от V4, а повод задавать прикладные вопросы: где обрабатываются данные, какой endpoint используется, можно ли поднять веса локально, кто отвечает за обновления и как фиксируется версия модели в критичных процессах.

В этом смысле DeepSeek V4 для российского рынка будет оцениваться не только по качеству ответов. Значение имеют доступность API, предсказуемость цен, возможность работы с открытыми весами, прозрачность model ID и правила обработки данных. Один сильный benchmark или удачный coding-пример не закрывает эти вопросы.

Аккуратность особенно важна для медиа и аналитиков. Нельзя переносить выводы о DeepSeek R1 на V4 без отдельного подтверждения. Нельзя писать о внедрениях V4, если источник говорит только об интересе к китайским моделям. И нельзя делать из глобального геополитического фона прямой вывод о качестве конкретной модели.

Цитата в переводе

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

Как теперь читать бенчмарки V4

Бенчмарки DeepSeek V4 стоит делить на три категории. Первая категория - vendor-reported результаты из model card и технических материалов: они показывают, как разработчик позиционирует модель, но не заменяют независимую проверку. Вторая категория - тесты открытых весов, где фиксируются checkpoint, параметры запуска и окружение. Третья категория - API-тесты, которые отражают сервис в конкретный день и могут включать особенности backend и маршрутизации.

Routing controversy важна потому, что API-тесты часто становятся основой быстрых выводов: «модель стала лучше», «модель победила конкурента», «модель провалила задачу». В случае V4 такие выводы нужно сопровождать метаданными: дата, model ID, режим Thinking или Non-Thinking, endpoint, провайдер, latency, скорость генерации, параметры запроса и повторяемость результата. Без этого сильный ответ на coding-задачу остается интересным наблюдением, но слабым доказательством архитектурного преимущества.

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

Еще одна проблема бенчмарков - переносимость результата. Если тест сделан через официальный API, он может быть полезен для покупателя API, но не обязательно описывает открытый checkpoint в локальном deployment. Если тест сделан на открытых весах, он не обязательно отражает качество официального endpoint. Если тест сделан у внешнего провайдера, нужно дополнительно понимать, какая модель и какой backend реально использовались.

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

Для coding-задач эта дисциплина особенно важна. Ответ модели может резко меняться из-за reasoning-режима, hidden prompt-handling, лимитов контекста, fallback или обновления backend. Если такой результат сразу превращается в маркетинговый вывод, рынок получает шум. Если он фиксируется как наблюдение с метаданными, он становится полезной частью общей картины.

Что это означает на практике

Для команд, которые используют DeepSeek или только готовят пилот V4, главная задача сейчас не угадать дату GA. Гораздо полезнее привести в порядок техническую дисциплину: model ID, логи тестов, кэширование, маршрутизацию задач между Flash и Pro, правила работы с длинным контекстом и governance для чувствительных данных.

Особое внимание стоит уделить старым alias-именам. Они удобны на старте, но опасны при миграции: в коде может быть непонятно, какой режим и какая модель фактически используются. DeepSeek в документации указала дату deprecation для deepseek-chat и deepseek-reasoner, поэтому это не абстрактный риск, а конкретный пункт проверки.

Второй блок практики связан с измерениями. Если команда тестирует V4 на документах, коде или агентных сценариях, нужно сохранять не только красивый ответ, но и полный контекст эксперимента. Иначе после обновления backend или изменения режима будет невозможно понять, почему качество изменилось.

Третий блок - экономика. При контексте 1 млн токенов стоимость определяется не только ценой output. На нее влияют cache hit, cache miss, повторяемость контекста, длина системных инструкций и то, насколько аккуратно приложение разделяет задачи между Flash и Pro.

Четвертый блок - доверие и развертывание. Открытые веса дают дополнительный путь проверки, но не делают внедрение простым. Для локального deployment нужны ресурсы, компетенции и процедура контроля версии. Для API-сценария нужны договоренности по данным, endpoint, логированию и мониторингу.

И наконец, командам стоит осторожнее относиться к громким формулировкам. Июльский community-сигнал нельзя называть официальным GA-релизом. Его можно использовать как повод усилить тесты и мониторинг, но не как доказательство финального статуса DeepSeek V4.

• Проверьте, не используются ли в коде legacy-имена deepseek-chat и deepseek-reasoner: по документации DeepSeek они должны быть отключены 24 июля 2026 года в 15:59 UTC.
• При тестировании V4 фиксируйте prompt, ответ, model ID, endpoint, режим Thinking или Non-Thinking, дату, latency, output speed и параметры запроса.
• Не переносите результаты V4-Pro на V4-Flash без отдельной проверки. У моделей разный масштаб активируемых параметров, разные concurrency limits и разные экономические сценарии.
• Если продукт работает с длинными документами, заранее проектируйте кэширование. Разница между cache hit и cache miss в pricing-модели DeepSeek делает архитектуру приложения частью стоимости.
• Для чувствительных корпоративных данных оценивайте не только качество модели, но и юрисдикцию endpoint, условия обработки данных, возможность локального развертывания открытых весов и процедуру фиксации версии модели.
• Не называйте июльский community-сигнал официальным GA-релизом. В первичных материалах подтверждены V4 Preview, API и открытые веса, а не публичный запуск GA или официальная политика grayscale testing.

Вывод

История с DeepSeek V4 показывает, как изменилась журналистика об ИИ-релизах. Раньше новость о модели часто сводилась к дате, benchmark-таблице и нескольким примерам. Теперь этого мало: у frontier-модели есть веса, API, провайдеры, inference-движки, режимы рассуждения, кэш и staged rollout. Любой из этих слоев может повлиять на ответ, который пользователь видит в окне чата.

Главный подтвержденный факт: DeepSeek V4 существует как Preview с открытыми весами, двумя API-моделями, большим контекстом и конкретной ценовой сеткой. Главный неподтвержденный тезис: что DeepSeek официально вывела V4 в GA через grayscale testing или маршрутизирует часть запросов к сторонней модели. Между этими утверждениями есть дистанция, которую нельзя заполнять догадками.

Даже как неподтвержденная гипотеза routing controversy полезна рынку. Она заставляет точнее формулировать тесты, отделять capabilities checkpoint от качества endpoint и осторожнее использовать слова «релиз», «внедрение» и «производительность». Для DeepSeek V4 это может быть не менее значимо, чем очередное место в benchmark-таблице: доверие к инфраструктуре становится частью конкурентоспособности наряду с архитектурой и ценой.

Для DeepSeek это одновременно шанс и риск. Шанс в том, что V4 уже обсуждают не только как модель, но и как платформу для API, открытых весов и длинного контекста. Риск в том, что любая непрозрачность вокруг статуса релиза, routing или поведения endpoints будет усиливать недоверие, даже если технически модель сильна.

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

Источники

• DeepSeek V4 technical report на Hugging Face
• Вашингтон против, бизнес - за: как китайский ИИ покоряет США, РБК
• DeepSeek V4 GA Is in Grayscale Testing: Architecture, Routing Controversy, and What We Actually Know
• DeepSeek API updates
• DeepSeek API pricing
• DeepSeek V4 Preview official news
• DeepSeek-V4-Pro model card на Hugging Face
• DeepSeek V4 documentation in Hugging Face Transformers

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

DeepSeek V4 уже вышла в GA?

В предоставленных источниках нет официального объявления DeepSeek о GA-релизе V4. Подтверждены V4 Preview, API-доступ, открытые веса, цены, параметры и миграция со старых model ID. Сигнал о GA-candidate связан с community-публикацией на Hugging Face и остается интерпретацией наблюдений.

Что означает grayscale testing в контексте DeepSeek V4?

Grayscale testing обычно означает постепенное включение новой версии для части пользователей перед полным релизом. В случае DeepSeek V4 community-автор описывает возможное такое тестирование, но официальной политики grayscale testing в доступных материалах DeepSeek нет.

Почему спор о routing важен?

Он показывает, что API-тест может измерять не только свойства весов, но и весь сервисный путь: backend, режим, кэш, fallback, endpoint и возможную маршрутизацию. Поэтому результаты V4 нужно разделять на тесты открытых весов, официального API и внешних endpoints.

Чем отличаются DeepSeek-V4-Pro и DeepSeek-V4-Flash?

По данным DeepSeek, V4-Pro имеет 1,6 трлн total parameters и 49 млрд activated parameters, а V4-Flash - 284 млрд total parameters и 13 млрд activated parameters. Pro выглядит как слой для более сложных задач, Flash - как более массовая и дешевая модель для API-сценариев.

Что нужно проверить интеграторам DeepSeek API?

Нужно найти legacy-имена deepseek-chat и deepseek-reasoner, заменить их на явные model ID, фиксировать endpoint, режим Thinking или Non-Thinking, дату, параметры запроса, latency, output speed и отдельно считать экономику cache hit и cache miss.

Практический чек-лист

Памятка для тестирования DeepSeek V4 перед внедрением

PDF-файл для downloads/checklist.pdf: короткая рабочая памятка, которую можно приложить к внутреннему тесту DeepSeek V4, чтобы не смешивать свойства открытых весов, официального API и поведения конкретного endpoint.

Model ID и миграция

• Проверить, используются ли deepseek-chat и deepseek-reasoner в коде, конфигурациях, low-code сценариях и документации.
• Заменить legacy-имена на явные model ID для V4-Flash или V4-Pro.
• Отдельно зафиксировать режим Thinking или Non-Thinking для каждого теста.
• Проверить дату deprecation legacy-имен: 24 июля 2026 года, 15:59 UTC, по документации DeepSeek.

Паспорт API-теста

• Сохранять prompt, полный ответ и параметры запроса.
• Фиксировать endpoint, model ID, режим, дату и время теста.
• Записывать latency, output speed и повторяемость результата.
• Не делать вывод о GA-релизе только по изменению поведения API.

Экономика контекста

• Разделить сценарии, где нужен V4-Pro, и сценарии, где достаточно V4-Flash.
• Оценить долю cache hit и cache miss в реальном приложении.
• Проверить, не ломаются ли кэши из-за мелких изменений системных инструкций.
• Считать стоимость на типовой рабочей нагрузке, а не на одном демонстрационном prompt.

Проверяемость и governance

• Разделять тесты открытых весов, официального API и внешних endpoints.
• Для открытых весов фиксировать checkpoint, inference engine, quantization и конфигурацию оборудования.
• Для чувствительных данных проверить endpoint, правила обработки, журналирование и возможность локального deployment.
• Не переносить выводы о DeepSeek R1 или общих китайских моделях на V4 без отдельного источника.