DeepSeek V4 Pro (0813): Връщане на мисленето и матрица с 3 API

Практическо ръководство за DeepSeek V4 Pro (0813): превключвател на мисленето и нива на reasoning_effort, задължително връщане на историята на мисленето, инструменти, кеширане и матрица с 3 API.

AIHubMix15 мин четене
DeepSeek V4 Pro (0813): Връщане на мисленето и матрица с 3 API

Тази статия разглежда бележките за употреба и капаните при deepseek-v4-pro-0813. В AIHubMix моделът е достъпен чрез Chat Completions, Responses и Claude-съвместимите Messages API. Вижте също: официалната документация на DeepSeek API.

Заключенията с етикет „Verified“ и примерните отговори в всеки раздел идват от реални заявки, направени на 2026-08-13 през API на AIHubMix (Chat Completions / Responses / Messages). Спецификациите без етикет „Verified“ са взети от официалната документация на DeepSeek.

1. Позициониране на модела и спецификации накратко

V4 Pro е висшият клас в поколение V4 на DeepSeek (леката deepseek-v4-flash е негов сибling). Линията от версии води началото си от 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* с този модел), и Responses API (DeepSeek описва нативна поддръжка на формата с адаптации за Codex). Предлага също FIM (fill-in-the-middle) допълване като функция в бета на отделна крайна точка, която не е част от трите 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" като Not Supported; при 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"
❗ Изображенията не предизвикват грешка, но се отхвърлят: официалната формулировка за Responses API е „Image and file inputs are not supported (input_image parts do not cause an error, but are replaced with a placeholder text)“ – част input_image не прекъсва заявката, а се заменя с текст-заместител. При Chat Completions полето content на потребителското съобщение приема само низ, а при Messages блоковете type="image" са маркирани като Not Supported. При изграждане на мултимодално маршрутизиране никога не приемайте липсата на грешка като доказателство, че моделът действително е видял изображението.

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": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): message.reasoning_content present, reasoning_tokens = 43
# Thinking off (disabled): reasoning_content absent, reasoning_tokens absent
Проверено: при 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="What is 2 + 2?",
    reasoning={"effort": "none"},
)

# effort="none": usage.output_tokens_details.reasoning_tokens = 0
#                output[0] is the message item directly (no reasoning item)
# effort unset : output always starts with a reasoning item
Проверено: 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": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): content = [thinking block, text block]
# Thinking off (disabled): content = [text block]
Проверено: след изключване блокът 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 в съобщението на асистента The `reasoning_content` in the thinking mode must be passed back to the API.
Responses Елементът на изхода с type="reasoning" в масива input The `reasoning_text` in the thinking mode must be passed back to the API.
Messages Блокът thinking в блоковете на съдържанието на асистента The `content[].thinking` in the thinking mode must be passed back to the API.
Проверено (условия за задействане): тази валидация се задейства последователно при многоходови заявки, които съдържат tools (моделът извиква инструмент, след което резултатът от инструмента се изпраща обратно). При обикновени многоходови заявки без инструменти, при които моделът отговаря директно, валидацията не се задейства в този кръг от тестове и заявката върна 200. С други думи, оркестрацията на инструменти (агентни / function-calling натоварвания) е мястото, където най-вероятно ще се натъкнете на проблема, затова третирайте съдържанието на мисленето като част от състоянието на разговора, което съхранявате и повторно изпращате.

Chat Completions

# Multi-turn: pass the previous assistant message back verbatim, including reasoning_content
messages = [
    {"role": "user", "content": "What is 1 + 1? Remember the result."},
    {
        "role": "assistant",
        "content": "2",
        "reasoning_content": "<reasoning_content from the previous response>",
    },
    {"role": "user", "content": "Add 1 to the result."},
]

# Dropping reasoning_content -> HTTP 400 invalid_request_error
Проверено: историческо съобщение на асистента без reasoning_content връща 400; когато полето се добави обратно, идентичната заявка връща 200 и продължава коректно.

Responses

# Multi-turn: input = previous input + response.output (reasoning item included) + new message
input = previous_input + response.output + [
    {"role": "user", "content": "Add 1 to the result."}
]

# Filtering out the type="reasoning" item -> HTTP 400
Проверено: достатъчно е да вмъкнете response.output обратно без промени. Филтрирането на елементите на изхода по type == "message" при сглобяване на историята премахва елемента reasoning и предизвиква 400 – това е най-честият начин да се подведете.

Messages

# Multi-turn: pass response.content back verbatim as the assistant message
messages = [
    {"role": "user", "content": "What's the weather in Paris?"},
    {"role": "assistant", "content": response.content},   # thinking + tool_use blocks
    {"role": "user", "content": [tool_result_block]},
]

# Stripping the thinking 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": "What's the weather in Paris?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather for a city",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
        },
    }],
    tool_choice={"type": "function", "function": {"name": "get_weather"}},
)

# Observed: finish_reason "tool_calls", tool_calls[0].function.arguments = {"city": "Paris"}
❗ Проверено: tool_choice: "required" не може да се използва, докато мисленето е включено – връща 400 Thinking mode does not support this tool_choice; изключването на мисленето (thinking.type="disabled") прави идентичната заявка успешна с 200. Когато е нужна семантика „трябва да се извика инструмент“, използвайте tool_choice с име на функция tool_choice (както е по-горе, работи и при включено мислене) или първо изключете мисленето и след това използвайте required.

Responses

Плоска форма (type / name / parameters на същото ниво).

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What's the weather in Paris?",
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get weather for a city",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
)

# Observed output items: ["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": "Get weather for a city",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
    tool_choice={"type": "any"},
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
)

# Observed: content contains a tool_use block, name = get_weather, input = {"city": "Paris"}
❗ Паралелното извикване на инструменти не може да се изключи по собствен дизайн на DeepSeek – официалната страница за съвместимост с Anthropic посочва в реда за tool_choice, че disable_parallel_tool_use is ignored, а страницата за Responses също посочва parallel_tool_calls | Ignored (parallel tool calling is always enabled). Тестовете потвърждават това: запитване за два града едновременно с disable_parallel_tool_use: true все пак връща два блока tool_use. Ако ви трябва последователно изпълнение, вземете първото извикване или организирайте опашката сами от страна на клиента.
Количество инструменти и цена на контекста: изпращането на 200 дефиниции на функции в една заявка все още върна 200 с нормален отговор и не задейства никаква проверка на броя (наблюдавано на този път; по-големи количества не са тествани). Но prompt_tokens за тази заявка достигна 6105 — дефинициите на инструментите влизат в контекста изцяло и се таксуват. Когато имате много инструменти, ограничавайте набора според сценария, вместо да декларирате всички безусловно.

5. Структуриран изход

Chat Completions

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

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Return {\"a\": 1} as JSON."}],
    response_format={"type": "json_object"},
)

# Observed response content: {"a":1}
Проверено: изходът е валиден JSON.

Responses

Декларирайте JSON Schema чрез text.format, като режимът strict се поддържа.

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Return the number 1 under key a.",
    text={
        "format": {
            "type": "json_schema",
            "name": "extract",
            "strict": True,
            "schema": {"type": "object", "properties": {"a": {"type": "integer"}}, "required": ["a"]},
        }
    },
)

# Observed output text: {"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

# usage of the second call with an identical long prefix
"prompt_tokens_details": {"cached_tokens": 640}   # first call: 0
Проверено: две последователни извиквания със същия дълъг префикс по същия канал промениха cached_tokens от 0 на 640.

Responses

# usage of the second call with identical long instructions
"input_tokens_details": {"cached_tokens": 896}    # first call: 0

Messages

# usage of a call whose long system prefix was already warmed
"cache_read_input_tokens": 896
Проверено: префиксът по-горе беше загрят от заявка Responses с идentично съдържание и първото извикване на Messages веднага отбеляза попадение от 896 — което е в съответствие с това, че кеширането се базира на префикса на съдържанието и се споделя между протоколните интерфейси.

7. logprobs: Chat връща два канала

logprobs (логаритмични вероятности — подробната информация за увереността на модела за всеки кандидат токен) се връща в различна структура при двата API и кодът за парсване трябва да ги обработва отделно.

Chat Completions

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Say hi."}],
    logprobs=True,
    top_logprobs=2,
)

# Observed: choices[0].logprobs contains TWO arrays
#   logprobs.content[]            -> tokens of the final answer
#   logprobs.reasoning_content[]  -> tokens of the thinking text
❗ Проверено: Chat връща log probabilities както за content, така и за reasoning_content. Код, който чете само logprobs.content според стандартната OpenAI структура на отговора, няма да даде грешка, но тихо ще пропусне канала за разсъждения; ако вашият код предполага един масив под logprobs, първо добавете проверка на структурата.

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Say hi.",
    top_logprobs=3,
)

# Observed: logprobs only on the final message item
#   output[-1].content[0].logprobs[] with logprob + top_logprobs details
Проверено: Responses прикрепя logprobs само към последния текстов елемент — без двуканалната структура, наблюдавана при Chat.

Messages

Протоколът Messages (Anthropic) няма еквивалентно поле. За детайлна информация за вероятностите на ниво токен използвайте Chat Completions или Responses.

8. Кои API могат да търсят в уеба?

Уеб търсенето тук е инструмент от страна на сървъра (извличането се изпълнява на сървъра; клиентът никога не изпраща самата заявка) и при тестване реално се изпълнява и при Responses, и при Messages API.

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is the latest stable version of Python?",
    tools=[{"type": "web_search"}],
)

# Observed output item sequence:
# ["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": "What is the latest stable version of Python?"}],
)

# Observed content block sequence:
# ["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. Официалната справка за Chat API на DeepSeek не съдържа никъде поле за инструмент за търсене в схемата на заявката (това е отсъствие, установено чрез преминаване през списъка с полета едно по едно; DeepSeek не е направила изрично изявление, че отрича поддръжка). API с ясно официално изявление за поддръжка на търсене от страна на сървъра е Responses (web_search), а официалната страница за съвместимост с Messages също изброява блоковете със съдържание, свързани с търсене.

# Three control groups, same question requiring live information, all HTTP 200:
# A no search field       -> "cannot retrieve", annotations = null
# B web_search_options    -> "cannot retrieve", annotations = null, usage identical to A
# C enable_search         -> "cannot retrieve", annotations = null, usage identical to A
Проверено: изпращането на web_search_options или enable_search не предизвиква грешка, но и не извлича нищо — в отговора липсва annotations (списъкът с цитати, прикачен към отговор, когато се изпълнява уеб търсене), а използването съвпада с контролната група поле по поле. За достъп до уеб използвайте Responses или Messages API.

9. Бележки за употребата: дизайнът на DeepSeek срещу отклоненията по нашия път

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

9.1 По дизайн на DeepSeek

Поведение Официална формулировка Какво да правите
Responses не запазва състояние на сесията или метаданни Официалната страница за съвместимост с Responses посочва ред по ред store | Not supported. The response always carries store: false, metadata | Not supported и safety_identifier | Not supported (от тези четири полета само user е Supported). Тестовете потвърждават: заявката връща 200, но metadata е null, safety_identifier липсва, а store е винаги false Пазете данните за корелация на заявките при клиента; не разчитайте на съхранение от страна на сървъра
Параметрите за семплиране нямат ефект в режим на разсъждение DeepSeek изрично посочва, че temperature и top_p са тихо неактивни в режим на разсъждение. При тестване и двата връщат 200, без нищо върнато обратно и без промяна във формата на отговора Не разчитайте на параметрите за семплиране за стабилност на изхода в режим на разсъждение; използвайте структуриран изход, когато ви трябва детерминизъм
Продължение на префикс / FIM е само в официалната бета крайна точка Официалното описание на prefix е „(Beta) … Трябва да зададете base_url="https://api.deepseek.com/beta", за да използвате тази функция“, а FIM completion също е бета функция. Проверено в производствената среда на 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 с нормален отговор, без грешка и без видим ефект. Фактът е достатъчно ясен — този път в момента не валидира enum-а на reasoning_effort. Неясно е дали трябва да го прави: DeepSeek публикува допустимия enum, но никога не посочва дали недопустимо ниво трябва да бъде отхвърляно, така че няма база за сравнение, което означава, че това не се брои нито за официално поведение, нито за дефект на нашия път. Безопасният клиентски подход: валидирайте нивото сами и не разчитайте API да го улови.

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

Клетките по-долу показват написанието на параметъра / полето за всеки API. Освен където е маркирано като изрична формулировка на DeepSeek, всяко заключение идва от реални извиквания, направени на 2026-08-13 към производствените API на AIHubMix.

Възможност Chat Completions Responses Messages
Основен чат / системни инструкции ✅ messages ✅ input + instructions ✅ messages + най-горно ниво system
Стрийминг ✅ stream + stream_options ✅ stream (response.created … response.completed) ✅ stream (message_start … message_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"}
Паралелно извикване на инструменти (не може да се изключи) ➖ няма такова поле в официалния Chat API ❗ DeepSeek посочва, че parallel_tool_calls се игнорира и паралелното извикване е винаги включено ❗ DeepSeek посочва, че disable_parallel_tool_use се игнорира; при тестване все още се връщат два блока tool_use
Структуриран изход ✅ response_format (json_object) ✅ text.format (json_schema + strict) ➖ нямаш протоколно поле; schema се предава в tool
Автоматично отчитане на cache hit ✅ usage.prompt_tokens_details.cached_tokens ✅ usage.input_tokens_details.cached_tokens ✅ usage.cache_read_input_tokens
logprobs ❗ двоен канал: content + reasoning_content ✅ top_logprobs само при последния текстов елемент ➖
Уеб търсене ➖ няма поле за търсене в официалния Chat API; изпращането на такова поле също не извлича резултати ✅ tools: [{"type": "web_search"}] ✅ web_search_20250305
Stop sequences ✅ stop ➖ няма поле за stop sequences в протокола (дължината се ограничава само с 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-съвместимия Messages API (/v1/messages).

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

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

Различават ли се трите нива на reasoning_effort?
low / high / max се приемат всички (по подразбиране high; medium и xhigh се преобразуват към high за съвместимост). При тестване броят на токените за разсъждения за един и същ въпрос не показва монотонна разлика между нивата и нищо не се връща обратно, така че разликата не може да бъде потвърдена от страна на извикващия. Само нивото none при Responses (изключени разсъждения) дава ясно наблюдаема разлика.

Защо tool_choice: "required" връща 400?
Тази стойност не се приема, докато разсъжденията са включени (тялото на грешката гласи Thinking mode does not support this tool_choice). Използвайте tool_choice с име на функция ({"type": "function", "function": {"name": "..."}}), за да принудите извикване на конкретна функция при включени разсъждения, или първо изключете разсъжденията и след това използвайте required.

Как се включва кеширането на контекста?
Не се включва ръчно – работи автоматично. Поставете стабилното, непроменящо се съдържание (системни промпти, фрагменти от знания, дефиниции на инструменти) в началото на заявката, а броят на попаденията се отчита в usage: 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.

Един шлюз към множество AI доставчици. Създаден за продукционна среда.

Посетете AIHubMix