DeepSeek V4 Pro (0813): Мислене на предаване и 3-API матрица

AIHubMix15 мин четене
DeepSeek V4 Pro (0813): Мислене на предаване и 3-API матрица

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

"Потвърдените" заключения и примерните отговори в секциите идват от реални извиквания, направени на 2026-08-13 чрез API на AIHubMix (Завършвания на чат / Отговори / Съобщения); спецификациите, които не са маркирани като "Потвърдени", идват от официалната документация на 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 за отговори (DeepSeek описва местна поддръжка за формата, с адаптации за Codex). Той предлага и FIM (попълване в средата) завършване като бета функция на отделна крайна точка, която не е част от трите AIHubMix API.
  • Разлика от ~120× между цените при кеш-хит и кеш-пропуск: Публикуваният механизъм за ценообразуване на DeepSeek е кеш-хит $0.003625/M срещу кеш-пропуск $0.435/M (изход $0.87/M), а кеширането е автоматично без параметър за настройка. За натоварвания, които повторно използват дълги префикси (системни подканвания, дълги документи), тази разлика доминира в сметката. Актуалната търговска цена е каквото показва страницата на модела.
Артикул Стойност
Име на модела в AIHubMix deepseek-v4-pro-0813
Контекстен прозорец 1M токена (1,000,000)
Максимален изход Официалната формулировка е MAX OUTPUT MAXIMUM: 384K (точният брой токени и по подразбиране не са публикувани)
Входни модалности Само текст. Страницата за съвместимост с отговори изрично заявява, че входовете с изображения и файлове не се поддържат; страницата за съобщения изрично маркира блоковете type="image" като Неподдържани; в Завършвания на чат съобщението на потребителя content приема само низ, без многомодални части на съдържанието
Режим на мислене Хибриден (мислене / немислене), мисленето е включено по подразбиране
Нива на мислене reasoning_effort приема low / high / max, по подразбиране high; medium и xhigh са картографирани на high за съвместимост
Налични API Завършвания на чат, Отговори, Съобщения (съвместими с Claude)
Потвърдено: надвишаването на max_tokens се отхвърля от валидиране, а не се прекратява безшумно — изпращането на max_tokens=9999999 връща HTTP 400, а тялото на грешката назовава полето и дава таван 393216.
# max_tokens=9999999 -> HTTP 400
"...max_tokens... 393216"
Изображенията не предизвикват грешка, но се отхвърлят: официалната формулировка за API за отговори е "Входовете с изображения и файлове не се поддържат (частите input_image не предизвикват грешка, но се заменят с текст за запълване)" — част от input_image не проваля заявката, а се заменя с текст за запълване. В Завършвания на чат съобщението на потребителя content приема само низ, а в Съобщения блоковете type="image" са маркирани като Неподдържани. При изграждане на многомодално маршрутизиране, никога не третирайте "няма грешка" като доказателство, че моделът наистина е видял изображението.

2. Как да изключите мисленето? Три API, три форми на полета

V4 Pro мисли по подразбиране: не изпращайте никакви параметри и отговорът се връща с мисловно съдържание. Изключването му използва различна форма на поле за всеки от трите API.

Завършвания на чат

Използвайте обекта 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 изчезват заедно, което потвърдва, че превключвателят е влязъл в сила.

Отговори

Няма отделен превключвател за отговори; изключването на мисленето означава задаване на нивото на 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] е елементът на съобщението директно (без елемент за разсъждение)
# effort не е зададен: output винаги започва с елемент за разсъждение
Потвърдено: reasoning.effort="none" се различава осезаемо от нивото по подразбиране (токените за разсъждение падат до нула, елементът reasoning изчезва), което потвърджа, че е влязло в сила.

Съобщения

Същото име и същата форма като Завършвания на чат: обектът 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 на Завършвания на чат в тестовете (high е по подразбиране и се прилага, когато полето е пропуснато), но броят на токените за мислене не показва монотонна разлика между нивата за един и същ въпрос (лесен въпрос: low=43 / max=27; труден въпрос: low=114 / max=92), и нищо не се повтаря в отговора — нивото се приема, но няма наблюдаваем сигнал от отговора. При Отговори, само нивото none (мисленето изключено) може да бъде потвърдено от страната на отговора.

3. Защо многопосочен разговор внезапно връща 400? Историята на мисленето трябва да бъде предадена обратно дословно

Това е най-честият проблем с този модел: в режим на мислене, многопосочен разговор трябва да предаде предишното съдържание на мисленето обратно дословно, или заявката се отхвърля. Не е понижено, не е с по-ниско качество — твърд HTTP 400.

Трите API носят същото съдържание на мислене под различни имена на полета:

API Форма на предаване Тяло на грешката при липса
Завършвания на чат Полето reasoning_content в съобщението на асистента Полето `reasoning_content` в режим на мислене трябва да бъде предадено обратно на API.
Отговори Изходният елемент с type="reasoning" в масива input Полето `reasoning_text` в режим на мислене трябва да бъде предадено обратно на API.
Съобщения Блокът thinking вътре в блоковете на съдържанието на асистента Полето `content[].thinking` в режим на мислене трябва да бъде предадено обратно на API.
Потвърдено (условия на задействане): тази валидация се задейства последователно при многопосочни заявки, които носят tools (моделът извършва извикване на инструмент, след което резултатът от инструмента се изпраща обратно). При обикновени многопосочни заявки без инструменти, където моделът отговаря директно, валидацията не се задейства в този кръг на тестване и заявката връща 200. С други думи, оркестрацията на инструменти (агент / натоварвания с извикване на функции) е мястото, където най-вероятно ще се сблъскате с него, така че третирайте съдържанието на мисленето като част от състоянието на разговора, което запазвате и възпроизвеждате.

Завършвания на чат

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

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

Отговори

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

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

Съобщения

# Многопосочен: предайте 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 декларира инструменти в своя собствена протоколна форма; формите не са взаимозаменяеми.

Завършвания на чат

Вложена форма (обект 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": "Париж"}
Потвърдено: tool_choice: "required" не може да се използва, докато мисленето е включено — то връща 400 Режимът на мислене не поддържа този tool_choice; деактивирането на мисленето (thinking.type="disabled") прави идентичната заявка да върне 200. Когато имате нужда от семантика "задължително извикване на инструмент", използвайте именувана функция tool_choice вместо (както по-горе, което работи с включено мислене), или първо изключете мисленето и след това използвайте required.

Отговори

Плоска форма (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"]; аргументи = {"city": "Париж"}
Потвърдено: копирането на вложената форма на Завършвания на чат (function: {...}) в Отговори връща 400 — използвайте плоската форма. tool_choice: "required" подлежи на същото ограничение на режима на мислене, както и на Чат.

Съобщения

Форма, специфична за 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": "Какво е времето в Париж?"}],
)

# Наблюдавано: съдържанието съдържа блок за използване на инструмент, име = get_weather, вход = {"city": "Париж"}
Паралелното извикване на инструменти не може да бъде изключено, по собствен дизайн на DeepSeek — официалната страница за съвместимост с Anthropic заявява, на реда tool_choice, че disable_parallel_tool_use се игнорира, а страницата за Отговори също заявява паралелни_tool_calls | Игнорирано (паралелното извикване на инструменти е винаги включено). Тестването съвпада: питането за две града наведнъж с disable_parallel_tool_use: true все още връща два блока tool_use. Ако имате нужда от серийно изпълнение, вземете първото извикване или ги опашвайте сами от страната на клиента.
Брой инструменти и разходи за контекст: изпращането на 200 определения на функции в една заявка все пак върна 200 с нормален отговор и не задейства никаква валидация на броя (наблюдавано по този път; по-високи количества не бяха тествани). Но prompt_tokens за тази заявка достигна 6,105 — определенията на инструменти влизат в контекста изцяло и се таксуват. Когато имате много инструменти, намалете набора от инструменти за всеки сценарий, вместо да декларирате всичко безусловно.

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

Завършвания на чат

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.

Отговори

Декларирайте 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}
Потвърдено: изходът строго отговаря на зададената схема.

Съобщения

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

6. Как да активирате кеширане на контекста? Не можете, то е автоматично

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

Завършвания на чат

# употреба на второто извикване с идентичен дълъг префикс
"prompt_tokens_details": {"cached_tokens": 640}   # първо извикване: 0
Потвърдено: две последователни извиквания с един и същ дълъг префикс на същия канал преместиха cached_tokens от 0 на 640.

Отговори

# употреба на второто извикване с идентични дълги инструкции
"input_tokens_details": {"cached_tokens": 896}    # първо извикване: 0

Съобщения

# употреба на извикване, чийто дълъг системен префикс вече е загрят
"cache_read_input_tokens": 896
Потвърдено: префиксът по-горе е бил загрят от заявка за Отговори с идентично съдържание, и първото извикване на Съобщения е ударило 896 веднага — в съответствие с кеширането, което е ключирано на префикса на съдържанието и споделено между протоколни повърхности.

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

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

Завършвания на чат

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[]  -> токени на текста на мисленето
Потвърдено: Чатът връща логаритмични вероятности и за content, и за reasoning_content. Код, който чете само logprobs.content, според стандартната форма на отговор на OpenAI, няма да предизвика грешка, но ще пропусне канала за мислене безшумно; ако вашият код предполага един единствен масив под logprobs, добавете проверка на формата първо.

Отговори

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Кажи здравей.",
    top_logprobs=3,
)

# Наблюдавано: logprobs само на окончателния елемент на съобщението
#   output[-1].content[0].logprobs[] с логаритмична вероятност + детайли за top_logprobs
Потвърдено: Отговори прикрепят logprobs само към последния текстов елемент — нито един от двойния канал, наблюдаван на Чат.

Съобщения

Протоколът на Съобщенията (Anthropic) няма еквивалентно поле. За детайли на вероятността на ниво токен, използвайте Завършвания на чат или Отговори.

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

Търсенето в мрежата тук е инструмент на сървъра (извличането се извършва на сървъра; клиентът никога не извършва самата заявка), и наистина се изпълнява и на API за Отговори, и на API за Съобщения в тестовете.

Отговори

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

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

Съобщения

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 — заявката за извличане наистина се е случила и е била измерена.

Завършвания на чат

Търсенето в мрежата не може да бъде задействано на Чат. Официалната справка на DeepSeek за Chat API не съдържа поле за инструмент за търсене никъде в схемата на заявката (това е отсъствие, установено чрез преглед на списъка с полета едно по едно; DeepSeek не е направил изрично изявление, отричащо поддръжка). API с изрично официално заявление за поддръжка на търсене на сървъра е Отговори (web_search), а официалната страница за съвместимост на Съобщенията също изброява свързаните с търсенето блокове съдържание.

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

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

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

9.1 Според дизайна на DeepSeek

Поведение Официална формулировка Какво да направите
Отговори не запазват състояние на сесията или метаданни Официалната страница за съвместимост с отговори заявява, ред по ред, 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 заявява на страниците за Отговори и Anthropic, че превключвателят се игнорира и паралелното извикване винаги е включено Опашвайте извиквания на клиента, когато имате нужда от серийно изпълнение

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

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

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

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

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

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

Възможност Завършвания на чат Отговори Съобщения
Основен чат / системни инструкции 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"}
Паралелно извикване на инструменти (не може да бъде деактивирано) ➖ няма такова поле в официалния Chat API ❗ DeepSeek заявява, че parallel_tool_calls се игнорира и паралелното извикване винаги е включено ❗ DeepSeek заявява, че disable_parallel_tool_use се игнорира; тестването все още връща два блока tool_use
Структуриран изход response_format (json_object) text.format (json_schema + strict) ➖ няма такова понятие в този API; носете схемата в инструмент
Автоматично измерване на кеш-хит 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 ➖ няма поле за спиране в протокола (само max_output_tokens ограничава дължината) stop_sequences (stop_reason: "stop_sequence")

Легенда: ✅ потвърдено работещо · 🟡 прието, но не може да бъде потвърдено като ефективно · ❗ изисква внимание (вижте бележките по-горе) · ➖ няма такова понятие в този API

ЧЗВ

Кои API поддържа deepseek-v4-pro-0813 в AIHubMix?
Завършвания на чат (/v1/chat/completions), Отговори (/v1/responses) и съвместимия с Claude API за Съобщения (/v1/messages).

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

Може ли мисленето да бъде изключено?
Да. Изпратете thinking: {"type": "disabled"} на Чат или Съобщения, и reasoning: {"effort": "none"} на Отговори. След като е изключено, както съдържанието на мисленето, така и токените за мислене изчезват.

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

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

Как да активирате кеширането на контекста?
Не можете — то е автоматично. Поставете стабилното, непроменящо се съдържание (системни подканвания, фрагменти от знания, определения на инструменти) в началото на заявката, а броят на ударите се отчита в употребата: prompt_tokens_details.cached_tokens на Чат, input_tokens_details.cached_tokens на Отговори и cache_read_input_tokens на Съобщения.


За ценообразуване и статус в реално време, вижте страницата на модела deepseek-v4-pro-0813; за повече модели, посетете галерията на модели.

Свързани ръководства: Ръководство за Kimi K3 (нови параметри и матрица за поддръжка на три API) и промени в кеширането на подканвания и таксуването на GPT-5.6.