Skip to main content
POST
Responses: DeepSeek V4 Flash text generation (with chained explicit cache)
Используйте playground справа, чтобы протестировать напрямую: вставьте Bearer sk-your-api-key в Authorization. В примере по умолчанию уже указаны caching: {"type": "enabled"} и store: true — схема записи первого вызова для цепочечного явного кэширования.
Responses добавляет слой явного кэша поверх Chat Completions. Сведения о возможностях, тарификации и управлении рассуждением см. в обзоре DeepSeek V4 Flash.
  • text.format json_schema не действует: возвращает 200, игнорируя схему; 3/3 ответа были заключены в блоки кода и не поддались парсингу
  • web_search backend непригоден к использованию: инструмент подключён (элементы web_search_call отображаются с status: completed), но 6/6 поисков завершились ошибкой и не вернули ни одного results
  • mcp возвращает AccessDenied: право на встроенный инструмент на уровне аккаунта/канала — корректный URL сервера даёт тот же результат
  • Только текстовая модель — при передаче изображений возвращает Model do not support image input

Краткая справка по параметрам

Явный кэш: требуется цепочка

Распространённая ошибка: повторная отправка одного и того же длинного префикса дважды с установленным caching приводит к тому, что cached_tokens остаётся на 0. Явный кэш не сопоставляется по префиксу — вам нужно связать сессию с previous_response_id.
Правильная схема: сначала отправьте весь документ в первом вызове, чтобы записать кэш, затем отправляйте только новый вопрос, при этом связывая предыдущий id. Каждый раунд задействует весь предыдущий контекст. Для последующих вопросов по длинному документу это гораздо дешевле, чем отправлять полный текст заново на каждом шаге.

Пример цепочки вызовов

Неявный кэш

Без caching неявный кэш по-прежнему применяется: повторение идентичного длинного префикса дало 99,9% попадания в кэш (15,633 → 15,616). Выбирайте в зависимости от сценария — один префикс, повторно используемый во многих независимых запросах лучше подходит для неявного кэша, тогда как одна сессия с последовательными уточнениями лучше подходит для цепочечного явного кэширования.

Типы элементов вывода

Ответ output — это массив, который может содержать следующие элементы:

Авторизации

Authorization
string
header
обязательно

API Key obtained from the APIYI console

Тело

application/json
model
enum<string>
по умолчанию:deepseek-v4-flash-ga-260731
обязательно

Model ID, fixed to deepseek-v4-flash-ga-260731

Доступные опции:
deepseek-v4-flash-ga-260731
input
обязательно

Input content. Either a string or a standard OpenAI Responses message array. Text only — no images

max_output_tokens
integer
по умолчанию:500

Max output tokens, hard ceiling 393,216. Reasoning counts toward this

Требуемый диапазон: x <= 393216
store
boolean
по умолчанию:true

Whether to store this response. Must be true to chain with previous_response_id

previous_response_id
string

The id of the previous response. Combined with caching, this hits the explicit cache in full

caching
object

Explicit cache switch. Pass {"type": "enabled"} on the first call to write, then chain with previous_response_id to hit

reasoning
object

Reasoning control. Measured: effort=minimal always yields 0 reasoning tokens; the other tiers do not form a monotonic ladder

stream
boolean
по умолчанию:false

Stream the response over SSE. Measured TTFB around 2.3 seconds

tools
object[]

Tool list. The function type works; web_search is wired but its backend errors, and mcp returns AccessDenied

Ответ

Generation succeeded

id
string

Response ID, used as the next call's previous_response_id

model
string
output
object[]

Output item array. May contain reasoning / message / function_call / web_search_call items

caching
object

Explicit cache status echo

usage
object

Usage. input_tokens_details.cached_tokens is the cache hit; output_tokens_details.reasoning_tokens is reasoning spend