DeepSeek V4 Pro (0813): Обратная связь по мышлению и матрица 3-API

AIHubMix15 мин чтения
DeepSeek V4 Pro (0813): Обратная связь по мышлению и матрица 3-API

В этой статье рассматриваются примечания по использованию и подводные камни для deepseek-v4-pro-0813. На AIHubMix модель доступна через API Chat Completions, Responses и Claude-compatible Messages. Также см.: официальная документация API DeepSeek.

«Проверенные» выводы и примеры ответов в каждом разделе получены из фактических вызовов, сделанных 2026-08-13 через API AIHubMix (Chat Completions / Responses / Messages); элементы спецификации, не отмеченные как «Проверенные», взяты из официальной документации DeepSeek.

1. Позиционирование модели и спецификации на первый взгляд

V4 Pro — это высококачественный уровень поколения V4 от DeepSeek (облегченная deepseek-v4-flash является его «сестрой»). Линия релиза восходит к DeepSeek-V4 Preview от 2026-04-24, а 0813 — это метка ВЕРСИИ МОДЕЛИ, которую DeepSeek присвоил текущей сборке. Кроме сырых спецификаций, четыре вещи выделяют его:

  • Разреженная модель на границе: 1.6T всего параметров / 49B активированных (архитектура MoE, или смесь экспертов — каждый проход вывода активирует только подмножество экспертных сетей: общее количество параметров определяет емкость знаний, активированные параметры определяют стоимость вычислений за вызов). В карточке модели указаны гибридное внимание CSA+HCA, mHC и оптимизатор Muon.
  • Открытые веса под MIT: deepseek-ai/DeepSeek-V4-Pro опубликован на HuggingFace под лицензией MIT (одна из самых разрешительных лицензий с открытым исходным кодом — коммерческое использование и закрытая перераспределение разрешены) и может быть размещен самостоятельно. MIT не является обычным для модели такого размера. Примечания по саморазмещению в карточке модели также предполагают контекстное окно ≥384K токенов при запуске в Think Max (самый высокий уровень мышления) — это руководство по развертыванию для саморазмещения, а не спецификация для размещенного API.
  • Поддержка нескольких протоколов является первичной, а не сторонним переводом: сам DeepSeek предлагает OpenAI Chat API, совместимую с Anthropic конечную точку (/anthropic, которая сопоставляет claude-opus* с этой моделью) и API Responses (DeepSeek описывает нативную поддержку формата с адаптациями для Codex). Он также предлагает завершение FIM (заполнение посередине) как бета-функцию на отдельной конечной точке, которая не является частью трех API AIHubMix.
  • Разница в цене между кэшированием и пропуском кэша ~120×: опубликованный механизм ценообразования DeepSeek — кэширование $0.003625/M против пропуска кэша $0.435/M (выход $0.87/M), и кэширование происходит автоматически без параметра для установки. Для рабочих нагрузок, которые повторно используют длинные префиксы (системные подсказки, длинные документы), эта разница доминирует в счете. Фактические розничные цены — это то, что показывает страница модели.
Элемент Значение
Название модели на AIHubMix deepseek-v4-pro-0813
Контекстное окно 1M токенов (1,000,000)
Максимальный вывод Официальная формулировка: MAX OUTPUT MAXIMUM: 384K (точное количество токенов и значение по умолчанию не опубликованы)
Входные модальности Только текст. Страница совместимости Responses явно указывает, что ввод изображений и файлов не поддерживается; страница Messages явно отмечает блоки type="image" как Не поддерживается; в Chat Completions сообщение пользователя content принимает только строку, без многомодальных частей контента
Режим мышления Гибридный (мышление / немышление), по умолчанию включено мышление
Уровни мышления reasoning_effort принимает low / high / max, по умолчанию high; medium и xhigh сопоставляются с high для совместимости
Доступные API Chat Completions, Responses, Messages (совместимые с Claude)
Проверено: превышение max_tokens отклоняется проверкой, а не молча обрезается — отправка max_tokens=9999999 возвращает HTTP 400, а тело ошибки указывает поле и дает потолок 393216.
# max_tokens=9999999 -> HTTP 400
"...max_tokens... 393216"
Изображения не вызывают ошибку, но они отбрасываются: официальная формулировка для API Responses гласит: «Ввод изображений и файлов не поддерживается (части input_image не вызывают ошибку, но заменяются текстом-заполнителем)» — часть input_image не приводит к сбою запроса, она заменяется текстом-заполнителем. В Chat Completions сообщение пользователя content принимает только строку, а в Messages блоки type="image" отмечены как Не поддерживается. При построении многомодальной маршрутизации никогда не рассматривайте «нет ошибки» как доказательство того, что модель действительно увидела изображение.

2. Как отключить мышление? Три API, три формы полей

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

Chat Completions

Используйте верхний уровень объекта thinking.

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Что такое 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Мышление включено (по умолчанию): message.reasoning_content присутствует, reasoning_tokens = 43
# Мышление отключено (выключено): reasoning_content отсутствует, reasoning_tokens отсутствуют
Проверено: с thinking.type="disabled" как message.reasoning_content, так и usage.completion_tokens_details.reasoning_tokens исчезают вместе, что подтверждает, что переключение сработало.

Responses

На Responses нет отдельного переключателя; отключение мышления означает установку уровня на none.

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Что такое 2 + 2?",
    reasoning={"effort": "none"},
)

# effort="none": usage.output_tokens_details.reasoning_tokens = 0
#                output[0] — это элемент сообщения напрямую (без элемента reasoning)
# effort не установлен: output всегда начинается с элемента reasoning
Проверено: reasoning.effort="none" заметно отличается от уровня по умолчанию (токены мышления падают до нуля, элемент reasoning исчезает), что подтверждает, что это сработало.

Messages

Та же форма и название, что и у Chat Completions: верхний уровень объекта thinking.

from anthropic import Anthropic

client = Anthropic(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com",
)

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Что такое 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Мышление включено (по умолчанию): content = [блок мышления, текстовый блок]
# Мышление отключено (выключено): content = [текстовый блок]
Проверено: после отключения блок thinking полностью исчезает, и остается только блок text.
О уровнях мышления: low и max оба возвращали 200 на Chat Completions в тестировании (high является уровнем по умолчанию и применяется, когда поле опущено), но количество токенов мышления не показывает монотонной разницы между уровнями для одного и того же вопроса (легкий вопрос: low=43 / max=27; сложный вопрос: low=114 / max=92), и ничего не возвращается в ответе — уровни принимаются, но из ответа не наблюдается различительного сигнала. На Responses только уровень none (мышление отключено) может быть подтвержден со стороны ответа.

3. Почему многоходовой разговор внезапно возвращает 400? Историю мышления необходимо передавать обратно дословно

Это самая распространенная проблема с этой моделью: в режиме мышления многоходовой разговор должен передавать содержимое мышления предыдущего хода обратно дословно, иначе запрос отклоняется. Не ухудшается, не снижает качество — жесткий HTTP 400.

Три API несут то же самое содержимое мышления под разными именами полей:

API Форма передачи Тело ошибки при отсутствии
Chat Completions Поле reasoning_content в сообщении помощника Содержимое `reasoning_content` в режиме мышления должно быть передано обратно в API.
Responses Элемент вывода с type="reasoning" в массиве input Содержимое `reasoning_text` в режиме мышления должно быть передано обратно в API.
Messages Блок thinking внутри блоков содержимого помощника Содержимое `content[].thinking` в режиме мышления должно быть передано обратно в API.
Проверено (условия срабатывания): эта проверка срабатывает последовательно на многоходовых запросах, которые содержат tools (модель вызывает инструмент, затем результат инструмента отправляется обратно). В простых многоходовых запросах без инструментов, где модель отвечает напрямую, проверка не сработала в этом раунде тестирования, и запрос вернул 200. Другими словами, оркестровка инструментов (агент / рабочие нагрузки вызова функций) — это то, где вы с наибольшей вероятностью столкнетесь с этой проблемой, поэтому рассматривайте содержимое мышления как часть состояния разговора, которое вы сохраняете и воспроизводите.

Chat Completions

# Многоходовой: передайте предыдущее сообщение помощника обратно дословно, включая reasoning_content
messages = [
    {"role": "user", "content": "Что такое 1 + 1? Запомните результат."},
    {
        "role": "assistant",
        "content": "2",
        "reasoning_content": "<reasoning_content from the previous response>",
    },
    {"role": "user", "content": "Добавьте 1 к результату."},
]

# Удаление reasoning_content -> HTTP 400 invalid_request_error
Проверено: историческое сообщение помощника, в котором отсутствует reasoning_content, возвращает 400; добавление его обратно делает идентичный запрос возвращающим 200 и продолжающим корректно.

Responses

# Многоходовой: input = предыдущий input + response.output (включая элемент reasoning) + новое сообщение
input = previous_input + response.output + [
    {"role": "user", "content": "Добавьте 1 к результату."}
]

# Фильтрация элемента type="reasoning" -> HTTP 400
Проверено: вставка response.output обратно как есть — это все, что нужно. Фильтрация выходных элементов по type == "message" при сборке истории удаляет элемент reasoning и вызывает 400 — это самый распространенный способ получить проблему.

Messages

# Многоходовой: передайте response.content обратно дословно как сообщение помощника
messages = [
    {"role": "user", "content": "Какова погода в Париже?"},
    {"role": "assistant", "content": response.content},   # блоки мышления + использования инструмента
    {"role": "user", "content": [tool_result_block]},
]

# Удаление блока мышления -> HTTP 400
Проверено: удаление блока thinking из массива содержимого возвращает 400 (с error.type, установленным на invalid_request_error).

4. Вызов инструментов

Каждый API объявляет инструменты в своей собственной форме протокола; формы не взаимозаменяемы.

Chat Completions

Вложенная форма (объект function, обертывающий name / parameters). Названный-функцией tool_choice принуждает вызов.

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Какова погода в Париже?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Получить погоду для города",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
        },
    }],
    tool_choice={"type": "function", "function": {"name": "get_weather"}},
)

# Наблюдаемое: finish_reason "tool_calls", tool_calls[0].function.arguments = {"city": "Paris"}
Проверено: tool_choice: "required" не может использоваться, пока мышление включено — это возвращает 400 Режим мышления не поддерживает этот tool_choice; отключение мышления (thinking.type="disabled") делает идентичный запрос возвращающим 200. Когда вам нужны семантика «должен вызвать инструмент», используйте названный-функцией tool_choice вместо этого (как выше, что работает с включенным мышлением), или сначала отключите мышление, а затем используйте required.

Responses

Плоская форма (type / name / parameters на одном уровне).

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Какова погода в Париже?",
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Получить погоду для города",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
)

# Наблюдаемые выходные элементы: ["reasoning", "function_call"]; arguments = {"city": "Paris"}
Проверено: копирование вложенной формы Chat Completions (function: {...}) в Responses возвращает 400 — используйте плоскую форму. tool_choice: "required" подлежит тому же ограничению режима мышления, что и на Chat.

Messages

Форма, родная для Anthropic (input_schema), с tool_choice: {"type": "any"}, чтобы принудить вызов.

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{
        "name": "get_weather",
        "description": "Получить погоду для города",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
    tool_choice={"type": "any"},
    messages=[{"role": "user", "content": "Какова погода в Париже?"}],
)

# Наблюдаемое: содержимое содержит блок использования инструмента, name = get_weather, input = {"city": "Paris"}
Параллельный вызов инструментов не может быть отключен, по дизайну DeepSeek — официальная страница совместимости с Anthropic утверждает, что disable_parallel_tool_use игнорируется, и страница Responses также утверждает parallel_tool_calls | Игнорируется (параллельный вызов инструментов всегда включен). Тестирование подтверждает: запрос о двух городах одновременно с disable_parallel_tool_use: true все равно возвращает два tool_use блока. Если вам нужна последовательная обработка, выполните первый вызов или поставьте их в очередь самостоятельно на стороне клиента.
Количество инструментов и стоимость контекста: отправка 200 определений функций в одном запросе все равно возвращала 200 с нормальным ответом и не вызвала никаких проверок количества (наблюдалось на этом пути; более высокие количества не тестировались). Но prompt_tokens для этого запроса достигло 6,105 — определения инструментов полностью входят в контекст и тарифицируются. Когда у вас много инструментов, сокращайте набор инструментов для каждого сценария, а не объявляйте все без условий.

5. Структурированный вывод

Chat Completions

response_format поддерживает режим JSON.

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Вернуть {\"a\": 1} в формате JSON."}],
    response_format={"type": "json_object"},
)

# Наблюдаемое содержимое ответа: {"a":1}
Проверено: вывод является допустимым JSON.

Responses

Объявите JSON-схему через text.format, с поддержкой режима strict.

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Вернуть число 1 под ключом a.",
    text={
        "format": {
            "type": "json_schema",
            "name": "extract",
            "strict": True,
            "schema": {"type": "object", "properties": {"a": {"type": "integer"}}, "required": ["a"]},
        }
    },
)

# Наблюдаемый выходной текст: {"a":1}
Проверено: вывод строго соответствует заданной схеме.

Messages

Протокол Messages (Anthropic) не имеет эквивалента response_format / text.format. Обычное решение — передать схему в инструмент — объявить инструмент, чья input_schema является вашей целевой схемой, установить tool_choice: {"type": "any"} и прочитать структурированный результат из input блока tool_use. Этот раунд тестирования не проверял конкретно этот шаблон; когда вам нужны жесткие гарантии схемы, предпочтите Chat Completions или Responses.

6. Как включить кэширование контекста? Вы не можете, это автоматическое

Кэширование контекста (идентичные префиксы повторно используются, и кэшированная часть тарифицируется по более низкой ставке) включено по умолчанию и не требует параметров. Второй запрос с тем же длинным префиксом сообщает о попадании в usage, под полем, название которого варьируется в зависимости от API. Для деталей кэширования и текущего ценообразования смотрите страницу модели; для стратегии кэширования между моделями и техник попадания смотрите практики кэширования подсказок.

Chat Completions

# использование второго вызова с идентичным длинным префиксом
"prompt_tokens_details": {"cached_tokens": 640}   # первый вызов: 0
Проверено: два последовательных вызова с тем же длинным префиксом на одном канале переместили cached_tokens с 0 до 640.

Responses

# использование второго вызова с идентичными длинными инструкциями
"input_tokens_details": {"cached_tokens": 896}    # первый вызов: 0

Messages

# использование вызова, чей длинный системный префикс уже был прогрет
"cache_read_input_tokens": 896
Проверено: указанный выше префикс был прогрет запросом Responses с идентичным содержимым, и первый вызов Messages сразу же достиг 896 — что соответствует тому, что кэширование основывается на префиксе содержимого и делится между протокольными поверхностями.

7. logprobs: Chat возвращает два канала

logprobs (логарифмические вероятности — детали уверенности модели по каждому кандидату-токену) возвращаются в разных формах на двух API, и код парсинга должен обрабатывать их отдельно.

Chat Completions

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Скажи привет."}],
    logprobs=True,
    top_logprobs=2,
)

# Наблюдаемое: choices[0].logprobs содержит ДВА массива
#   logprobs.content[]            -> токены окончательного ответа
#   logprobs.reasoning_content[]  -> токены текста мышления
Проверено: Chat возвращает логарифмические вероятности как для content, так и для reasoning_content. Код, который читает только logprobs.content, согласно стандартной форме ответа OpenAI, не вызовет ошибку, но молча пропустит канал мышления; если ваш код предполагает единственный массив под logprobs, сначала добавьте проверку формы.

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Скажи привет.",
    top_logprobs=3,
)

# Наблюдаемое: logprobs только на последнем элементе сообщения
#   output[-1].content[0].logprobs[] с логарифмическими вероятностями + деталями top_logprobs
Проверено: Responses прикрепляет logprobs только к последнему текстовому элементу — ни одного из двухканальных форматов, наблюдаемых на Chat.

Messages

Протокол Messages (Anthropic) не имеет эквивалентного поля. Для детализации вероятностей на уровне токенов используйте Chat Completions или Responses.

8. Какие API могут искать в Интернете?

Поиск в Интернете здесь является серверным инструментом (извлечение выполняется на сервере; клиент никогда не отправляет запрос сам), и он действительно выполняется как на API Responses, так и на API Messages в тестировании.

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Какова последняя стабильная версия Python?",
    tools=[{"type": "web_search"}],
)

# Наблюдаемая последовательность выходных элементов:
# ["reasoning", "web_search_call", "reasoning", "message"]
Проверено: элемент web_search_call появляется в последовательности выходных данных, что означает, что сервер действительно выполнил извлечение.

Messages

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{"type": "web_search_20250305", "name": "web_search"}],
    messages=[{"role": "user", "content": "Какова последняя стабильная версия Python?"}],
)

# Наблюдаемая последовательность блоков содержимого:
# ["thinking", "server_tool_use", "web_search_tool_result", "thinking", "text"]
# usage.server_tool_use.web_search_requests = 1
Проверено: usage.server_tool_use.web_search_requests считает 1 — запрос на извлечение действительно произошел и был учтен.

Chat Completions

Поиск в Интернете не может быть инициирован на Chat. Официальная справка API Chat от DeepSeek не содержит поля поиска нигде в схеме запроса (это отсутствие установлено путем проверки списка полей по одному; DeepSeek не сделала никаких явных заявлений о запрете поддержки). API с явным официальным заявлением о поддержке серверного поиска — это Responses (web_search), и официальная страница совместимости Messages также перечисляет связанные с поиском блоки содержимого.

# Три контрольные группы, один и тот же вопрос, требующий актуальной информации, все HTTP 200:
# A без поля поиска       -> "не может извлечь", аннотации = null
# B web_search_options    -> "не может извлечь", аннотации = null, использование идентично A
# C enable_search         -> "не может извлечь", аннотации = null, использование идентично A
Проверено: отправка web_search_options или enable_search не вызывает ошибку, но также ничего не извлекает — ответ не содержит annotations (список цитирования, прикрепленный к ответу, когда выполняется поиск в Интернете), и использование совпадает с контрольной группой поле за полем. Для доступа к вебу используйте API Responses или Messages вместо этого.

9. Примечания по использованию: Дизайн DeepSeek против отклонений на нашем пути

Все ниже возвращает HTTP 200, действуя интуитивно неправильно. Причины различаются, и то, что вы должны с этим делать, также различается, поэтому они перечислены отдельно: первая группа — это то, как DeepSeek спроектировала модель, и изменение поставщиков не изменит это; вторая группа — это текущее поведение на пути AIHubMix, над которым мы работаем.

9.1 По дизайну DeepSeek

Поведение Официальная формулировка Что делать
Responses не сохраняет состояние сессии или метаданные Официальная страница совместимости Responses утверждает, строка за строкой, store | Не поддерживается. Ответ всегда содержит store: false, metadata | Не поддерживается, и safety_identifier | Не поддерживается (из этих четырех полей только user поддерживается). Тестирование соответствует: запрос возвращает 200, но metadata равно null, safety_identifier отсутствует, а store всегда false Сохраняйте данные корреляции запросов на клиенте; не полагайтесь на серверное хранение
Параметры выборки не влияют в режиме мышления DeepSeek явно утверждает, что temperature и top_p молча неактивны в режиме мышления. В тестировании оба возвращают 200 без ничего, возвращаемого обратно, и без изменения формы ответа Не полагайтесь на параметры выборки для стабильности вывода в режиме мышления; используйте структурированный вывод, когда вам нужна детерминированность
Продолжение префикса / FIM доступно только на официальной бета- конечной точке Официальное описание prefix гласит: «(Бета) … Вы должны установить base_url="https://api.deepseek.com/beta", чтобы использовать эту функцию», и завершение FIM также является бета-функцией. Проверено на производстве AIHubMix: отправка prefix: true против стандартной конечной точки возвращает 200, но префикс молча отбрасывается, что соответствует официальной формулировке Для контролируемого формата вывода используйте структурированный вывод (раздел 5) или обрезание stop
Параллельный вызов инструментов не может быть отключен См. раздел 4: DeepSeek утверждает на страницах Responses и Anthropic, что переключатель игнорируется и параллельный вызов всегда включен Ставьте вызовы в очередь на клиенте, когда вам нужна последовательная обработка

9.2 Текущее поведение на пути AIHubMix

Поведение Что показывает тестирование Что делать
Нестандартный type на объектах ошибок Responses error.type на ответах 4xx — это Aihubmix_api_error, в то время как тот же класс ошибки на Messages возвращает каноническую invalid_request_error Разветвляйте по коду состояния HTTP, а не по строке error.type
Токены мышления учитываются как 0 на Messages Ответ действительно содержит блок thinking, но usage.output_tokens_details.thinking_tokens всегда равно 0, что противоречит фактически произведенному содержимому мышления; согласно контракту с Anthropic, с которым мы интегрируемся, это поле обязательно и должно быть ≤ output_tokens Для учета стоимости мышления используйте completion_tokens_details.reasoning_tokens на Chat или output_tokens_details.reasoning_tokens на Responses
Messages повторяет model как deepseek-v4-pro Запрос отправляет deepseek-v4-pro-0813, а ответ повторяет deepseek-v4-pro. Причина в названии: единственное официальное название модели API DeepSeek — это deepseek-v4-pro, а 0813 — это его метка версии Не делайте поле model ответа единственным основанием для проверок маршрутизации модели или атрибуции использования

9.3 Неопределено DeepSeek, поэтому нет вердикта ни в ту, ни в другую сторону

Отправка значения вне перечисления для reasoning_effort (например, bogus_xyz) возвращает 200 с нормальным ответом, без ошибки и без наблюдаемого эффекта. Факт достаточно ясен — этот путь в настоящее время не проверяет перечисление reasoning_effort. Что неясно, так это должно ли это быть: DeepSeek публикует законное перечисление, но никогда не указывает, должно ли незаконное значение быть отклонено, поэтому нет базового уровня для оценки, что означает, что это не считается ни официальным поведением, ни дефектом на нашем пути. Безопасный подход на стороне клиента: проверьте уровень самостоятельно и не полагайтесь на API, чтобы поймать его.

10. Матрица возможностей × поддержки API

Ячейки ниже дают написание параметров / полей для каждого API. За исключением случаев, когда указано иное, все выводы основаны на фактических вызовах, сделанных 2026-08-13 против производственных API AIHubMix.

Возможность Chat Completions Responses Messages
Основные инструкции чата / системы messages input + instructions messages + верхний уровень system
Потоковая передача stream + stream_options stream (response.createdresponse.completed) stream (message_startmessage_stop)
Потолок вывода max_tokens (400 при превышении, потолок 393216) max_output_tokens max_tokens
Отключение мышления thinking: {"type": "disabled"} reasoning: {"effort": "none"} thinking: {"type": "disabled"}
Уровень мышления 🟡 reasoning_effort принимается, нет различительного сигнала reasoning.effort (только none подтверждается) 🟡 output_config.effort принимается, ничего не возвращается
Возвращаемое содержимое мышления reasoning_content поле reasoning элемент вывода thinking блок содержимого
Обязательная обратная связь по истории мышления ✅ отсутствие reasoning_content → 400 ✅ отсутствие элемента reasoning → 400 ✅ отсутствие блока thinking → 400
Вызов инструментов ✅ вложенные tools + названный tool_choice ✅ плоские tools input_schema + tool_choice: {"type":"any"}
Принуждение вызова с required ❗ 400, пока мышление включено; сначала отключите мышление ❗ то же самое, что и слева {"type": "any"}
Параллельный вызов инструментов (не отключаемый) ➖ нет такого поля в официальном API Chat ❗ DeepSeek утверждает, что parallel_tool_calls игнорируется, и параллельный вызов всегда включен ❗ DeepSeek утверждает, что disable_parallel_tool_use игнорируется; тестирование все равно возвращает два tool_use блока
Структурированный вывод response_format (json_object) text.format (json_schema + strict) ➖ нет протокольного поля; передайте схему в инструмент
Автоматическое измерение попаданий в кэш usage.prompt_tokens_details.cached_tokens usage.input_tokens_details.cached_tokens usage.cache_read_input_tokens
logprobs ❗ двойной канал: content + reasoning_content top_logprobs только на последнем текстовом элементе
Поиск в Интернете ➖ нет поля поиска в официальном API Chat; отправка не извлекает ничего tools: [{"type": "web_search"}] web_search_20250305
Секвенции остановки stop ➖ нет поля последовательности остановки в протоколе (только max_output_tokens ограничивает длину) stop_sequences (stop_reason: "stop_sequence")

Легенда: ✅ проверено, работает · 🟡 принято, но не может быть подтверждено как эффективное · ❗ требует внимания (см. примечания выше) · ➖ такого понятия в этом API нет

Часто задаваемые вопросы

Какие API поддерживает deepseek-v4-pro-0813 на AIHubMix?
Chat Completions (/v1/chat/completions), Responses (/v1/responses) и совместимый с Claude API Messages (/v1/messages).

Почему многоходовой разговор внезапно возвращает 400?
Наиболее распространенной причиной является история мышления, которая не была передана обратно. В режиме мышления содержимое мышления предыдущего хода должно воспроизводиться дословно: reasoning_content в сообщении помощника для Chat, элемент type="reasoning" для Responses и блок thinking для Messages. Многоходовые запросы с инструментами — это то, где это особенно актуально — многие фреймворки фильтруют выходные элементы по type == "message" при сборке истории, что удаляет элемент reasoning.

Можно ли отключить мышление?
Да. Отправьте thinking: {"type": "disabled"} на Chat или Messages и reasoning: {"effort": "none"} на Responses. После отключения как содержимое мышления, так и токены мышления исчезают.

Отличаются ли три уровня reasoning_effort?
low / high / max все принимаются (по умолчанию high; medium и xhigh сопоставляются с high для совместимости). В тестировании количество токенов мышления для одного и того же вопроса не показывает монотонной разницы между уровнями и ничего не возвращается, поэтому разницу нельзя подтвердить со стороны вызывающего. Только уровень none на Responses (мышление отключено) производит четкую наблюдаемую разницу.

Почему tool_choice: "required" возвращает 400?
Это значение не принимается, пока мышление включено (тело ошибки гласит Режим мышления не поддерживает этот tool_choice). Используйте названный-функцией tool_choice ({"type": "function", "function": {"name": "..."}}), чтобы принудить конкретный вызов с включенным мышлением, или сначала отключите мышление, а затем используйте required.

Как включить кэширование контекста?
Вы не можете — это автоматическое. Поместите стабильный, неизменный контент (системные подсказки, фрагменты знаний, определения инструментов) в начало запроса, и количество попаданий будет отражено в использовании: prompt_tokens_details.cached_tokens на Chat, input_tokens_details.cached_tokens на Responses и cache_read_input_tokens на Messages.


Для получения информации о ценах и текущем статусе смотрите страницу модели deepseek-v4-pro-0813; для получения дополнительных моделей посетите галерею моделей.

Связанные практические руководства: Практическое руководство Kimi K3 (новые параметры и матрица поддержки трех API) и Изменения в кэшировании подсказок и выставлении счетов GPT-5.6.