Тази статия разглежда бележките за употреба и капаните при 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"не може да се използва, докато мисленето е включено – връща 400Thinking 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.



