DeepSeek V4-Flash-0731: thinking не отключается

Последнее обновление: 2 августа 2026 года. Версия модели, дата вывода старых идентификаторов и параметры thinking повторно сверены с официальными материалами DeepSeek.

Победитель в этой проверке — контроль конечного исходящего запроса, а не просмотр конфигурационного файла. Если в приложении указано disabled, но в сеть уходит запрос без объекта thinking или с другим значением, API использует режим по умолчанию. Для OpenAI SDK переключатель нужно передавать внутри extra_body; если прямой запрос уже отключает thinking, а в рабочей среде всё ещё появляется reasoning_content, проверяйте сериализацию SDK, общий шлюз и отдельные запросы AI Agent. (api-docs.deepseek.com)

Эта статья предназначена для трёх групп:

• разработчиков, которые после перехода на DeepSeek V4-Flash-0731 продолжают получать reasoning_content;
• инженеров платформы, обслуживающих прокси, шлюзы и единые SDK-обёртки;
• команд, где основной запрос работает без thinking, но скрытые шаги AI Agent продолжают увеличивать задержку и usage.

DeepSeek V4-Flash-0731: thinking не отключается из-за проверки не того слоя

Обычно сбой выглядит так: в YAML, переменных окружения или внутреннем объекте задачи записано thinking: disabled, но в ответе снова появляется reasoning_content. После этого команда меняет модель, удаляет историю сообщений или пытается отключить режим через пользовательский интерфейс. Такие действия не доказывают причину.

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

Проверка должна связывать между собой:

• идентификатор запроса на стороне приложения;
• идентификатор ответа API;
• фактически использованную модель в поле model;
• время отправки и время получения;
• поля ответа content, reasoning_content и usage;
• признак потоковой или непотоковой передачи.

Официальная документация указывает, что thinking по умолчанию включён. В режиме рассуждения содержимое возвращается в отдельном поле reasoning_content, на одном уровне с обычным content. Поэтому отсутствие явного thinking: {"type": "disabled"} нельзя считать подтверждением отключения. (api-docs.deepseek.com)

Здесь важно разделить три разных источника ложного сигнала:

1. Текущий ответ API.
   Поле reasoning_content действительно пришло в новом ответе.

2. Сохраненная история.
   Приложение показывает поле из старого сообщения, которое было создано до исправления.

3. Остаток потокового парсера.
   Клиентский обработчик не очищает буфер рассуждений между запросами и повторно отображает уже обработанный фрагмент.

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

Важно: для потоковой передачи проверяйте не только финальный объект ответа. Официальный формат содержит отдельные дельты для content и reasoning_content, а статистика usage может приходить в завершающем фрагменте при включённом stream_options.include_usage. (api-docs.deepseek.com)

OpenAI SDK: почему параметр должен быть внутри extra_body

Вызов через OpenAI SDK часто выглядит корректно на уровне исходного кода, но параметр исчезает при подготовке JSON. Причина в том, что thinking не является обычным универсальным аргументом OpenAI-совместимого метода.

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

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "user", "content": "Проверка режима ответа"}
    ],
    extra_body={
        "thinking": {
            "type": "disabled"
        }
    }
)

В этом фрагменте важно не само имя переменной внутри приложения. Важен JSON, который фактически отправлен на сетевом уровне:

{
  "model": "deepseek-v4-flash",
  "messages": [
    {
      "role": "user",
      "content": "Проверка режима ответа"
    }
  ],
  "thinking": {
    "type": "disabled"
  }
}

В OpenAI SDK объект из extra_body должен быть преобразован в часть конечного тела запроса. Если thinking остался только внутри локальной структуры настроек, сервер его не увидит. Если параметр был передан отдельным неподдерживаемым аргументом, SDK может отклонить вызов, проигнорировать поле или не включить его в сериализованный JSON — результат зависит от конкретной версии библиотеки и адаптера.

Проверять следует три представления одного вызова:

• вход приложения: что передал бизнес-код;
• выход SDK или адаптера: что получилось после нормализации аргументов;
• сетевой запрос: что реально ушло на конечный API-адрес.

Только третий уровень является доказательством. Лог вызова функции не заменяет перехват HTTPS-запроса, отладочный транспортный лог или контролируемую запись тела запроса после удаления ключа API.

Ошибки, которые выглядят как отключение

Одна из распространённых ошибок — использовать собственное поле вроде:

request_config = {
    "thinking": "disabled"
}

Затем эта структура передаётся в функцию, которая принимает только model, messages, stream и несколько стандартных параметров. Настройка существует в приложении, но не обязательно участвует в формировании запроса.

Вторая ошибка — передать неверную форму объекта:

{
  "thinking": "disabled"
}

Для текущего формата требуется объект с полем type, а допустимые значения — enabled и disabled. Это описано в справочнике Chat Completions API. (api-docs.deepseek.com)

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

SDK-обёртка против прямого вызова: где исчезает поле

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

Типичный путь выглядит так:

конфигурация задачи
    ↓
вызов приложения
    ↓
единый SDK-адаптер
    ↓
модельный шлюз
    ↓
конечный HTTP-запрос
    ↓
ответ API

На каждом переходе нужно записать только безопасные диагностические признаки:

• название модели;
• наличие объекта thinking;
• значение thinking.type;
• режим stream;
• идентификатор трассировки;
• адрес логического маршрута без токена;
• model и usage из ответа;
• наличие reasoning_content.

Секреты, содержимое пользовательских сообщений и персональные данные из таких логов следует удалять.

Белый список параметров

Многие внутренние адаптеры формируют запрос не из всех входных полей, а из заранее разрешённого списка. Например, адаптер может сохранять messages, model, temperature и stream, но отбрасывать всё неизвестное. В таком случае extra_body будет потерян целиком.

Другой вариант — адаптер сохраняет сам extra_body, но фильтрует вложенные ключи. Вход приложения показывает:

{
  "extra_body": {
    "thinking": {
      "type": "disabled"
    }
  }
}

А после нормализации остаётся:

{
  "extra_body": {}
}

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

Удобно начать с прямого запроса к официальному endpoint, а затем повторить тот же тест через SDK и через рабочий шлюз. В официальном руководстве для OpenAI SDK прямо показана передача thinking через extra_body. (api-docs.deepseek.com)

Шлюз против локальной настройки: как найти повторное включение

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

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

Проверка должна сравнить минимум три маршрута:

Маршрут	Что фиксировать	Какой вывод допустим
Прямое обращение к API	model, thinking.type, ответ и usage	Проверяется базовое поведение endpoint
Тестовый шлюз	исходный и изменённый JSON, маршрут	Видно, добавляет ли шлюз значение
Производственный шлюз	итоговый JSON и trace ID	Подтверждается реальная конфигурация

Не следует менять имя модели наугад. Сначала нужно определить фактически использованный model. В документации для текущего Chat Completions API указаны идентификаторы deepseek-v4-flash и deepseek-v4-pro; поле model также возвращается в ответе. (api-docs.deepseek.com)

Если прямой вызов с disabled не содержит reasoning_content, а производственный маршрут его возвращает, точка сбоя находится между этими двумя уровнями. Далее сравниваются:

1. JSON до шлюза;
2. JSON после правил нормализации;
3. запрос после выбора маршрута;
4. ответ с тем же trace ID.

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

Главный запрос против AI Agent: почему скрытая ветка остаётся с thinking

В многошаговом AI Agent один пользовательский запрос редко равен одному API-вызову. Помимо видимого ответа могут выполняться:

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

Отключение thinking в точке входа не гарантирует, что внутренние методы унаследуют это значение. Некоторые фреймворки создают новый объект запроса для каждого шага. Если объект собирается заново, extra_body нужно передавать в каждом типе вызова.

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

• trace ID и parent span;
• роль запроса: основной, планировщик, инструмент, повтор;
• модель;
• thinking.type в исходящем JSON;
• наличие reasoning_content;
• prompt_tokens, completion_tokens и total_tokens;
• длительность;
• причина завершения.

Официальное руководство отдельно отмечает, что при tool calls содержимое reasoning_content должно передаваться обратно в последующих запросах такого цикла. Поэтому наличие этого поля в истории не всегда означает, что текущий запрос снова включил thinking. Нужно различать сохранённый промежуточный результат и новый ответ модели. (api-docs.deepseek.com)

Почему стоимость может оставаться высокой

Если основной ответ уже работает в non-thinking режиме, но общий usage остаётся высоким, возможны четыре объяснения:

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

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

Текущие тарифные условия и модельные обозначения следует сверять по официальной странице цен. На момент проверки DeepSeek отдельно публикует таблицу моделей и описывает политику тарифов, поэтому старые значения для выведенных идентификаторов нельзя автоматически переносить на новый endpoint. (api-docs.deepseek.com)

Как провести изолированный прогон и принять исправление

Для воспроизводимой проверки нужен один обезличенный запрос. Его следует запускать в одинаковом виде по трём маршрутам:

1. прямой официальный endpoint;
2. существующий OpenAI SDK;
3. производственный SDK и шлюз.

Каждый прогон должен сохранять конечный JSON и ответ. Нельзя сравнивать только исходные Python-словари или настройки панели.

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

• [ ] Зафиксировать обезличенный текст запроса и список сообщений.
• [ ] Указать точное имя модели в каждом маршруте.
• [ ] Передать thinking как объект с type: "disabled" внутри extra_body.
• [ ] Сохранить финальное тело HTTP-запроса без ключа API.
• [ ] Проверить, что в каждом запросе присутствует thinking.type.
• [ ] Сопоставить model в запросе и в ответе.
• [ ] Проверить отсутствие нового reasoning_content в непотоковом ответе.
• [ ] Для потокового ответа отдельно проверить дельты reasoning_content.
• [ ] Включить usage и сохранить токены по каждому дочернему запросу.
• [ ] Повторить проверку для планировщика, tool call и retry.
• [ ] Сравнить trace ID родительского и дочерних запросов.
• [ ] Зафиксировать слой, на котором значение впервые исчезло или изменилось.

Критерий исправления состоит не в том, что пользовательский интерфейс показывает «выключено». Исправление принято, если прямой прогон, SDK и рабочий шлюз отправляют одинаковое значение, а все дочерние запросы AI Agent проходят ту же проверку. Изменение стоимости или задержки нельзя заранее объявлять в процентах: оно зависит от длины контекста, числа шагов, инструментов и повторов.

Для команд, которым нужно регулярно повторять такие тесты, полезно заранее разделить окружения. На отдельном облачном Mac для тестирования совместимости SDK проще закрепить версии библиотек, переменных окружения и перехватчиков трафика. Это снижает риск, что локальный тест проходит на одной версии адаптера, а production использует другую.

Что выбрать для повторной диагностики

Ниже — не сравнение тарифов, а выбор среды для доказательства причины. Он помогает понять, где проводить следующий прогон.

Среда	Сильная сторона	Ограничение	Когда использовать
Локальная машина	Быстрый запуск минимального SDK-теста	Сложно воспроизвести production-шлюз и Agent-цепочку	Для первичной проверки extra_body
Тестовый Mac	Изолированные версии SDK, прокси и переменных	Нужно подготовить отдельный стенд	Для сравнения прямого вызова и адаптера
Производственный маршрут	Показывает реальное поведение и usage	Логи могут быть ограничены политикой безопасности	Для окончательной проверки перед выпуском
Общий стенд команды	Удобен для повторных прогонов	Конфигурация может меняться параллельно	Для регрессионных тестов после обновлений

Если локальный тест успешен, а production снова выдаёт reasoning, исправление нужно искать не в модели. Приоритет получают адаптер, шлюз и скрытые ветки Agent. Если же прямой запрос уже возвращает неожиданный режим, сначала повторно сверяются официальные параметры endpoint и текущие правила API.

Старые deepseek-chat и deepseek-reasoner нельзя использовать как контрольные точки после 24 июля 2026 года, 15:59 UTC: официальный материал DeepSeek указывает, что после этого времени они должны быть выведены из эксплуатации. В качестве контрольной модели нужно фиксировать актуальный идентификатор и проверять его в ответе. (api-docs.deepseek.com)

Для удобства дальнейших прогонов можно использовать консоль ProxyMac, если тестовый Mac применяется как отдельная среда наблюдения. Доступ к ресурсам и периодичность проверок стоит планировать отдельно: частые регрессионные прогоны требуют стабильной среды, а не случайного рабочего ноутбука.

Почему отдельная среда лучше постоянного исправления production

Оставлять такую проверку только внутри production неудобно по нескольким причинам. Во-первых, сетевой лог часто сокращается или маскируется, и команда видит только входные параметры. Во-вторых, единый шлюз может менять правила без изменения приложения. В-третьих, Agent создаёт дочерние запросы, которые не попадают в обычный экран мониторинга. Наконец, повторная попытка после ошибки способна использовать другой путь сериализации.

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

Перед запуском тестов условия доступа и рабочий цикл можно сверить через справочный раздел ProxyMac. Это имеет смысл именно для временной диагностики, миграционной проверки и воспроизводимого прогона SDK — не как универсальная замена постоянной инфраструктуре.

Главный практический вывод остаётся простым: если конфигурация говорит disabled, а итоговый запрос этого не подтверждает, конфигурация не является доказательством. Сначала фиксируется конечный JSON, затем сравниваются SDK, шлюз и дочерние вызовы Agent. Только после этого можно связывать reasoning_content, задержку или необычный usage с реальным режимом модели.

Читать далее

• API или локальное развёртывание: как проверить полный путь параметров модели
• AI-агенты и API: скрытые запросы, MCP и потребление ресурсов