DeepSeek V4: замена модели без роста счёта

По состоянию на 31 июля 2026 года для обычных диалогов и пакетной обработки выбирайте deepseek-v4-flash и явно отключайте thinking; для задач, где важны рассуждения, сначала сравните Flash и Pro в одинаковом режиме, а не переводите весь трафик на Pro. Это и есть безопасная стратегия замены модели DeepSeek V4 после отключения старых имён.

Эта статья предназначена разработчикам, которые ещё мигрируют с deepseek-chat, платформенным инженерам, поддерживающим общий шлюз или SDK, а также командам AI Agent и техническим руководителям, которым нужно одновременно удержать качество, задержку и расходы под контролем.

Последнее обновление: 31 июля 2026 года. Данные проверены по официальным материалам DeepSeek: объявлению V4, документации Thinking Mode, странице моделей и тарифов, а также описанию API-кэша.

Календарь отключения и действие на эту неделю

DeepSeek официально объявил, что deepseek-chat и deepseek-reasoner перестанут быть доступными именами моделей после 24 июля 2026 года, 15:59 UTC. До отключения эти имена временно маршрутизировались соответственно в режим без рассуждений и режим с рассуждениями на базе V4 Flash. После указанного времени приложение должно использовать новые идентификаторы напрямую: deepseek-v4-flash или deepseek-v4-pro. (официальное объявление DeepSeek V4)

На этой неделе действуйте в таком порядке:

1. Найдите все места, где встречаются deepseek-chat, deepseek-reasoner и внутренние псевдонимы вроде default-model.
2. Для обычных запросов задайте model: "deepseek-v4-flash".
3. В тех же запросах передайте thinking: {"type": "disabled"}.
4. Для прежних задач на рассуждение создайте отдельные маршруты Flash Thinking и Pro Thinking.
5. Проверьте не файл конфигурации, а фактическое тело исходящего запроса и поля model и usage в ответе.
6. До расширения трафика сравните качество, количество токенов, кэширование, повторные запросы и полную цепочку вызовов.

Главная ошибка после миграции — изменить только значение model. В документации DeepSeek указано, что переключатель thinking по умолчанию имеет состояние enabled. Поэтому новый идентификатор без явного параметра может изменить не только название модели, но и фактическое поведение запроса. (документация DeepSeek по Thinking Mode)

Обычные диалоги: базовая замена модели

Почему для чата подходит Flash без рассуждений

Если ваше приложение отвечает на типовые вопросы, формирует короткие объяснения, классифицирует обращения или поддерживает справочный диалог, начните с такой связки:

{
  "model": "deepseek-v4-flash",
  "messages": [
    {
      "role": "user",
      "content": "Составьте краткий ответ клиенту по этому обращению"
    }
  ],
  "extra_body": {
    "thinking": {
      "type": "disabled"
    }
  }
}

В формате OpenAI-подобного API параметр thinking передаётся внутри extra_body. Это важная деталь: если ваш SDK не знает параметр напрямую, он может молча отбросить его или шлюз может заменить его собственным значением. Официальная документация показывает именно такой способ передачи переключателя. (формат параметра Thinking Mode)

Обычная замена deepseek-chat на deepseek-v4-flash без thinking даёт наиболее близкую инженерную базу для миграции:

• меньше переменных в сравнительном тесте;
• проще сопоставить прежний ответ с новым;
• не возникает скрытого вывода рассуждений;
• легче объяснить изменение расходов по полям usage;
• можно отдельно включить рассуждение только для сложных запросов.

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

{
  "model": "deepseek-v4-flash",
  "usage": {
    "prompt_tokens": 0,
    "completion_tokens": 0,
    "prompt_cache_hit_tokens": 0,
    "prompt_cache_miss_tokens": 0
  }
}

Нулевые значения здесь показаны как шаблон структуры, а не как ожидаемый результат. В реальном ответе должны присутствовать фактические значения. DeepSeek отдельно документирует поля prompt_cache_hit_tokens и prompt_cache_miss_tokens, по которым можно отличить повторно использованный префикс от токенов без попадания в кэш. (документация по кэшированию префикса)

Проверка конечного запроса

Проверяйте три уровня, потому что каждый из них может изменить настройки:

1. Конфигурация приложения. Убедитесь, что новый идентификатор записан во все окружения, включая фоновые задания и тестовые воркеры.
2. SDK или внутренний клиент. Проверьте, не преобразует ли он thinking в другой формат и не добавляет ли собственное значение по умолчанию.
3. Общий шлюз. Посмотрите, не заменяет ли прокси модель или extra_body после получения запроса от приложения.

В журнале исходящего HTTP-запроса зафиксируйте model и переданный объект thinking. В журнале ответа сопоставьте их с фактическим полем model и разделом usage. Только такая связка подтверждает, что миграция реально дошла до API, а не осталась изменением в YAML-файле.

Пакетная обработка: экономичный маршрут

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

Начальная конфигурация для batch-задач:

• deepseek-v4-flash;
• thinking отключён;
• фиксированный формат ответа, например JSON Schema, если он поддерживается вашим клиентом;
• повторная отправка только для сетевых ошибок и временных отказов;
• отдельный учёт успешных, повторных и частично завершённых заданий.

Не смешивайте три причины роста счёта:

• режим thinking может увеличить объём генерируемых токенов;
• неудачные повторы повторно оплачивают вход и выход;
• промахи кэша увеличивают стоимость входного контекста по сравнению с попаданием в кэш.

Официальная страница тарифов указывает, что расчёт зависит от общего числа входных и выходных токенов, а для V4 Flash и V4 Pro отдельно показываются ставки для cache hit, cache miss и output. На этой же странице сейчас указаны разные лимиты одновременных запросов: 2 500 для Flash и 500 для Pro. Перед публикацией собственной таблицы расходов перепроверьте страницу тарифов, поскольку DeepSeek оставляет за собой право менять цены. (официальные тарифы и лимиты моделей)

Для длинных документов важна структура префикса. Если системная инструкция и исходный текст документа повторяются в одинаковом порядке, следующий запрос может получить cache hit. Если между запросами вы меняете начало сообщения, добавляете случайный идентификатор или переставляете блоки, кэш может не сработать. Документация DeepSeek описывает кэширование как best effort и не обещает стопроцентное попадание. (правила кэширования входного префикса)

Условия перехода на thinking

Не повышайте режим только потому, что новый ответ выглядит непривычно. Сначала задайте измеримые условия выхода из дешёвого маршрута:

• на контрольной выборке Flash без thinking не проходит заранее установленный порог точности;
• ошибка приводит к ручной переработке, возврату средств или нарушению бизнес-процесса;
• формат ответа формально корректен, но содержательная проверка показывает систематические пропуски;
• повторный запрос без изменения режима не устраняет проблему;
• команда готова считать не только стоимость одного вызова, но и цену исправления результата.

Если хотя бы один критерий выполнен, протестируйте deepseek-v4-flash с thinking. Только после этого сравнивайте Pro. Не меняйте одновременно модель, режим, шаблон запроса и параметры повторов — иначе вы не поймёте, что именно улучшило качество или увеличило расходы.

AI Agent: граница между Flash и Pro

У Agent другой профиль риска. Один пользовательский запрос может породить несколько обращений к модели, вызовы инструментов и повторные раунды рассуждения. В официальном примере Thinking Mode DeepSeek показывает цикл, в котором модель сначала создаёт рассуждение, затем вызывает инструмент, получает его результат и продолжает работу. При использовании tool call поле reasoning_content нужно передавать в последующих запросах; неправильная сборка истории может привести к ошибке API. (официальный пример Thinking Mode с инструментами)

Поэтому не сравнивайте Agent по одному главному запросу. Считайте полную задачу:

• число обращений к модели;
• число вызовов инструментов;
• входные и выходные токены каждого шага;
• cache hit и cache miss;
• долю повторных попыток;
• полную задержку от запроса пользователя до результата;
• процент задач, завершённых без ручного вмешательства.

Используйте Flash, если:

• инструменты простые и их результаты легко проверить;
• ошибка приводит к повторному запуску, а не к серьёзному ущербу;
• Agent решает типовые задачи поиска, классификации или преобразования данных;
• важнее пропускная способность и предсказуемая стоимость.

Тестируйте Pro, если:

• цепочка инструментов длинная и требует планирования;
• неверное действие имеет высокую стоимость;
• Agent должен анализировать противоречивые данные;
• качество ответа важнее максимальной скорости;
• контрольная выборка показывает устойчивое преимущество Pro, а не единичные удачные ответы.

Не переносите старое имя deepseek-reasoner в новую архитектуру как безусловное правило. Историческое назначение старого маршрута объясняет, зачем он использовался, но не доказывает, что теперь весь его трафик должен идти в V4 Pro. Официальное объявление подтверждает наличие Flash и Pro, поддержку двух режимов и временное направление старых имён в V4 Flash, но не устанавливает обязательное соответствие deepseek-reasoner → Pro после отключения. (условия перехода со старых имён моделей)

Сложное рассуждение: контролируемое повышение качества

Для кода, многошагового анализа и решений с высокой ценой ошибки создайте минимум два тестовых маршрута:

{
  "model": "deepseek-v4-flash",
  "extra_body": {
    "thinking": {
      "type": "enabled"
    }
  }
}

{
  "model": "deepseek-v4-pro",
  "extra_body": {
    "thinking": {
      "type": "enabled"
    }
  }
}

Одинаковыми должны оставаться:

• набор задач;
• системная инструкция;
• формат ожидаемого ответа;
• правила вызова инструментов;
• лимиты повторов;
• критерии оценки.

Сначала сравните Flash Thinking и Pro Thinking. После этого сопоставьте лучший thinking-маршрут с Flash без thinking. Такая последовательность разделяет два разных эффекта: преимущество модели и преимущество самого режима рассуждения.

У V4 Flash и V4 Pro заявлены оба режима, поддержка вызовов инструментов и контекст до 1M токенов; на странице тарифов также указан максимальный размер вывода до 384K токенов. Это технические возможности API, а не гарантия одинакового качества, задержки или стоимости в вашей задаче. (официальные технические параметры V4)

Шлюз и SDK: единые правила маршрутизации

Платформенной команде следует убрать неоднозначные псевдонимы из внутренних контрактов. Вместо поля reasoning-model записывайте отдельно:

• конечный model;
• состояние thinking;
• тип рабочей нагрузки;
• резервную модель;
• версию правила маршрутизации;
• идентификатор тестового набора.

Пример правила:

chat_default:
  model: deepseek-v4-flash
  thinking: disabled
  fallback: deepseek-v4-flash-thinking

agent_standard:
  model: deepseek-v4-flash
  thinking: enabled
  fallback: deepseek-v4-pro-thinking

analysis_high_risk:
  model: deepseek-v4-pro
  thinking: enabled
  fallback: deepseek-v4-flash-thinking

Это не универсальная готовая конфигурация, а схема, которую нужно подтвердить вашим тестом. Важен сам принцип: fallback должен быть явным, а не зависеть от старого имени.

Проверьте также права на изменение параметров. Если приложение передаёт thinking: disabled, шлюз не должен принудительно включать его для всех запросов. Если платформа пока не готова полностью удалить старый псевдоним, оставьте временное правило с владельцем, датой удаления и счётчиком обращений. Правило без метрики быстро превращается в постоянный обходной путь.

Сигнатура миграции для технического руководителя

Перед расширением трафика соберите одну таблицу по всем командам. В ней должны быть не только «старое имя» и «новое имя», но и доказательства поведения.

Для фиксации можно использовать раздел помощи VpsGona, если вам нужно отдельно организовать тестовый доступ, сетевую конфигурацию или изолированное окружение для проверки шлюза. Общую информацию об инфраструктурных сценариях можно посмотреть на русской странице VpsGona.

Контрольный список перед переводом трафика

• [ ] Все вызовы deepseek-chat и deepseek-reasoner найдены в коде, конфигурации и фоновых заданиях.
• [ ] Для обычного трафика выбран deepseek-v4-flash.
• [ ] Для обычного трафика thinking отключён явно через поддерживаемый формат API.
• [ ] В исходящем запросе проверяется конечный model.
• [ ] В ответе сохраняются model и поля usage.
• [ ] Для batch-задач отдельно видны cache hit, cache miss и повторы.
• [ ] Для Agent считается вся цепочка, а не только первый запрос.
• [ ] Flash Thinking и Pro Thinking сравниваются на одном наборе задач.
• [ ] У каждого маршрута есть резервный вариант.
• [ ] Для временных псевдонимов назначены владелец и условие удаления.
• [ ] Установлено окно наблюдения без несанкционированных маршрутов.
• [ ] Качество подтверждено до увеличения доли трафика.

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

Если проблема проявляется только в macOS- или iOS-клиенте, Xcode-сборке либо конкретном SDK, не смешивайте проверку клиента с изменением production-маршрута. Текущая инфраструктура — например, локальный Mac, Windows-система или обычный Linux-сервер — может быть неудобна для воспроизведения именно Apple-цепочки: другой SDK, другая прокси-конфигурация, отличающиеся сертификаты и переменные окружения создают отдельные источники ошибки. Для краткого изолированного теста можно рассмотреть облачный Mac через VpsGona, но сначала проверьте доступную конфигурацию, способ выдачи, срок аренды и соответствие вашей версии macOS. Это разумнее, чем покупать постоянное оборудование ради одной миграционной проверки; при длительной стабильной нагрузке или необходимости физических интерфейсов собственный Mac всё же может оказаться практичнее.