DeepSeek V4 Reasoning Effort в трёх API-форматах: почему ваш прокси, скорее всего, передаёт параметры неверно

Когда 13 августа вышел GA-релиз DeepSeek V4-Pro, публика сосредоточилась на пиковом и внепиковом ценообразовании. Операционно значимое изменение было задокументировано тише: управление глубиной рассуждений перешло из экспериментального режима в полноценный трёхуровневый API-параметр — low, high и max, с дефолтом high. При этом каждый из трёх поддерживаемых API-форматов использует разные поля, что критично для команд, работающих через прокси или gateway.

Что изменилось в GA-релизе V4-Pro

V4-Pro и V4-Flash теперь поддерживают три явных уровня глубины рассуждений. Синтаксис запроса различается в зависимости от формата.

Формат OpenAI Chat Completions:

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[...],
    reasoning_effort="high",
    extra_body={"thinking": {"type": "enabled"}}
)

Здесь нужны оба поля: reasoning_effort на верхнем уровне задаёт интенсивность, а thinking внутри extra_body включает режим рассуждений. Если убрать extra_body, режим не активируется, и значение reasoning_effort не имеет эффекта.

Формат Anthropic Messages:

{
  "model": "deepseek-v4-pro",
  "thinking": {"type": "enabled"},
  "output_config": {"effort": "high"}
}

Формат Responses API:

{
  "model": "deepseek-v4-pro",
  "reasoning": {"effort": "high"}
}

Три формата — три разных пути к одной функции.

Почему прокси молча передаёт параметры неверно

Большинство OpenAI-совместимых прокси прозрачно форвардируют стандартные поля Chat Completions — model, messages, temperature, max_tokens — и отбрасывают неизвестные расширения. extra_body — это конструкция Python SDK, а не wire-level поле: SDK объединяет его с телом запроса при вызове, и по сети уходит обычный JSON с thinking на верхнем уровне рядом с messages.

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

Сообщество воспроизвело этот эффект при работе через OpenCode: когда фреймворк не передавал блок thinking, DeepSeek в ряде случаев молча применял серверный дефолт, который не совпадал с явно заданным reasoning_effort.

Правило работы с reasoning_content в цепочках tool call

В мультиходовых agent-пайплайнах есть ещё один нюанс: обработка reasoning_content при вызовах инструментов.

Когда модель делает tool call, reasoning_content промежуточного assistant-сообщения обязан передаваться в контекст следующего хода. Если tool call не было — reasoning_content предыдущего хода можно опустить (передача допустима, но добавит лишние токены).

Многие agent-фреймворки при конкатенации контекста сохраняют только поле content, молча отбрасывая reasoning_content. Потеря этого поля в tool call-последовательности приводит к непредсказуемому поведению модели в последующих ходах. Это правило не зависит от выбранного уровня усилия — оно одинаково для low, high и max.

Что раскрывает конфигурация интеграции Codex

DeepSeek опубликовал JSON-спецификацию интеграции с Codex, которая показывает внутреннюю логику маршрутизации. Для deepseek-v4-flash спецификация содержит:

{
  "default_reasoning_level": "high",
  "supported_reasoning_levels": [
    {"effort": "low", "description": "Fast responses with lighter reasoning"},
    {"effort": "high", "description": "Extra high reasoning depth for complex problems"},
    {"effort": "max", "description": "Maximum reasoning depth for the hardest problems"}
  ]
}

Это означает: при маршрутизации V4-Flash через Codex-совместимый клиент без явного указания уровня усилия по умолчанию применяется high. Если gateway пытается принудительно задать reasoning_effort=low на уровне маршрута, а клиент Codex переопределяет это своим default_reasoning_level ниже по стеку — возникает конфликт, который не вызывает никаких ошибок.

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

Трёхуровневая система усилий (low, high, max) перекликается с управлением бюджетом extended thinking в Anthropic Claude. Fast mode и service tiers OpenAI (standard, priority, fast) — ортогональный механизм: он управляет пропускной способностью и задержкой, а не глубиной рассуждений, и прямого аналога здесь нет.

Главное отличие DeepSeek — дефолтное значение high, а не low. Это означает, что базовая стоимость agent-нагрузки через V4-Pro изначально находится на среднем уровне вычислительных затрат. Для задач с высоким объёмом и низкой сложностью — классификация, извлечение данных, простая генерация — явное указание reasoning_effort=low способно ощутимо снизить стоимость и задержку. Но только при условии, что прокси действительно передаёт этот параметр на сторону DeepSeek.

Три вопроса перед запуском в продакшн

1. Форвардирует ли ваш прокси поле thinking как есть? Проверьте фактическое тело запроса, которое прокси отправляет на DeepSeek — через tcpdump или логирование на стороне gateway, а не по SDK-вызову.

2. Задаётся ли усилие на уровне запроса или маршрута? Для смешанной нагрузки — agent-задачи требуют high или max, batch-обработка может работать на low — нужен per-request контроль усилия, а не глобальный дефолт, применяемый к всему трафику.

3. Сохраняет ли ваш agent-фреймворк reasoning_content в tool call-последовательностях? Изучите логику сборки assistant-сообщений в фреймворке: если он реконструирует их из подмножества полей ответа, reasoning_content в tool call-ходах, скорее всего, теряется.

Для пользователей TheRouter

При маршрутизации к DeepSeek через TheRouter: прокси-слой пересылает тела запросов дословно. Поля thinking и reasoning_effort дойдут до DeepSeek, если клиент их отправит корректно. Риск — на стороне клиента: убедитесь, что SDK правильно объединяет extra_body, если вы используете путь с форматом OpenAI.

Для смешанной нагрузки разумная стратегия — маршрутизировать простые задачи на deepseek-v4-flash с явным reasoning_effort=low. Бенчмарки V4-Flash на рутинных задачах достаточно сильны, чтобы уровень low практически не уступал high в большинстве production-сценариев.