DeepSeek-V4-Flash-Vision-Exp: что мультимодальный API меняет для разработчиков

Что именно запустила DeepSeek

21 августа 2026 года DeepSeek сообщила о доступности deepseek-v4-flash-vision-exp на API Platform. Модель принимает изображения вместе с текстом: мультимодальный ввод стал доступной функцией API, а не анонсом будущей возможности.

Для разработки появляется новый прикладной контур. В запрос можно передавать скриншоты, изображения товаров или документы, получать текстовый либо структурированный результат, а при повторных обращениях к вложению использовать Files API. В названии модели остаётся маркер Exp: доступность API не равна подтверждённой зрелости для конкретного корпоративного процесса.

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

Экспериментальный статус не исключает пилот или ограниченное применение. Но он не позволяет считать неизменными имя модели, лимиты, формат интеграции и поведение на прикладных данных. Заменять действующий маршрут одной настройкой конфигурации рискованно. Безопаснее выделить отдельный маршрут с feature flag, лимитами и текстовым fallback.

Сам релиз не заменяет независимую проверку. В доступных первичных материалах нет подтверждённых показателей времени до первого токена, сквозной задержки или качества OCR именно для Vision-Exp. Метрики текстовой V4-Flash могут быть только фоном, но не обещанием для запроса с изображением.

• Подтверждённый факт: deepseek-v4-flash-vision-exp принимает изображения через API.
• Подтверждённый факт: модель выпущена как экспериментальная.
• Неподтверждённый вывод: любой совместимый SDK без изменений корректно передаст все мультимодальные блоки.
• Практическое решение: запускать Vision-Exp отдельным маршрутом и измерять его показатели отдельно от текстовой цепочки.

Цитата в переводе

«DeepSeek-V4-Flash-Vision-Exp теперь доступна на API-платформе DeepSeek!»

Payload: изображение становится частью контракта запроса

Главное изменение для приложения состоит в структуре пользовательского сообщения. Вместо одной строки content может содержать массив частей: текстовую инструкцию и объект изображения. Документация описывает передачу через image_url, включая URL и base64 data URL, а также через блок file со ссылкой на ранее загруженный объект по file_id. Поддерживаются JPEG, PNG, GIF и WebP.

Меняется не только сериализация JSON. Инструкция должна объяснять, что сделать с изображением и в каком виде вернуть ответ. Вопрос о том, что изображено, годится для демонстрации, но редко становится хорошим производственным контрактом. Для UI-скриншота полезнее запросить конкретный текст ошибки или список визуальных признаков. При извлечении полей стоит заранее задать структуру результата, а затем проверить значения в приложении.

У image_url есть параметр detail. Режим low уменьшает изображение до 512×512 и описан как вариант для более быстрых и дешёвых запросов. Режимы high, original и auto сохраняют больше визуальной информации. Выбор влияет на скорость, стоимость и вероятность прочитать мелкий текст, ячейку таблицы или элемент интерфейса.

Формат доставки полезно скрыть за внутренним attachment layer. Бизнес-сценарий передаёт изображение и цель обработки, а адаптер выбирает URL, data URL или file_id. Тогда смена способа доставки не потребует переписывать логику классификации, QA-проверки или извлечения полей.

• URL подходит, если файл уже находится в контролируемом и доступном хранилище; в материалах релиза для URL указан предел 8 192 символа.
• Base64 удобен для небольшого разового вложения, но увеличивает HTTP-payload.
• file_id подходит для повторных вопросов к одному изображению после загрузки в Files API.
• Для каждого сценария отдельно тестируйте low и более подробные режимы, не выбирая настройку по одному удачному примеру.

Files API: повторное использование файла и контроль жизненного цикла

DeepSeek описывает Files API для загрузки вложений. Изображение отправляется через POST /files как multipart/form-data с назначением user_data, после чего на него можно ссылаться по file_id в запросах chat completion. Указанный предел размера загружаемого файла составляет до 64 MiB.

Механизм полезен там, где к одному изображению обращаются несколько раз: оператор уточняет детали скриншота, агент последовательно извлекает поля или система запускает разные проверки. Вместо повторной передачи тяжёлого содержимого приложение использует идентификатор уже загруженного объекта. Однако сам объект и его жизненный цикл всё равно нужно контролировать.

В релизных материалах указано, что срок жизни файла можно задать в диапазоне от одного часа до 30 дней; без параметров expiration файл сохраняется бессрочно. Поэтому file_id нельзя считать безобидной краткоживущей ссылкой. Для upload-пути нужны явный TTL, учёт идентификатора, статус удаления и обработка повторных попыток загрузки.

Для российских команд это существенно в сценариях со скриншотами CRM, личных кабинетов, договоров и внутренних панелей. Такие вложения могут содержать персональные, коммерчески чувствительные или секретные сведения. Представленный набор источников не позволяет сделать выводы о географии обработки или юридическом режиме трансграничной передачи. Перед масштабированием необходимы внутренняя классификация данных и проверка применимых договорных документов, а не предположение по названию API.

• Не оставляйте срок хранения по умолчанию для чувствительных изображений.
• Храните связь file_id с бизнес-объектом, временем истечения и результатом удаления.
• Проверьте, что retries не создают неконтролируемые дубликаты файлов.
• Начинайте пилот с синтетических или обезличенных изображений и короткого TTL.

Цитата в переводе

«Загрузите файл изображения, на который затем можно ссылаться по его file_id в запросах chat completion.»

Стоимость: считать нужно успешный сценарий, а не картинку

В материалах релиза DeepSeek указывает, что изображения токенизируются для биллинга: до 384 токенов на картинку, по тарифам V4-Flash. Для некэшированного input названы 0,44 доллара за 1 млн токенов в peak и 0,22 доллара вне peak; для output: 1,32 и 0,66 доллара соответственно. Для cache hit действуют отдельные сниженные ставки. Peak-периоды указаны как 01:00–04:00 и 06:00–10:00 UTC.

Потолок в 384 image tokens помогает оценить порядок величины, но не даёт готового прогноза расходов. При максимуме 384 токена входная часть одной картинки составляет около 0,00016896 доллара в peak и 0,00008448 доллара вне peak. Это иллюстрация только для image input: итоговый счёт зависит также от текстового контекста, длины ответа, кэширования и числа шагов в цепочке.

Цена одного изображения остаётся слабой продуктовой метрикой. В классификации решение может быть получено одним коротким запросом. Разбор интерфейсной ошибки способен потребовать несколько скриншотов, уточняющий вопрос и проверку результата. В документообороте добавятся извлечение кандидатов на поля, валидация и ручная эскалация. Сравнивать стоит стоимость завершённой задачи при требуемом качестве, а не цену одного API-вызова.

В каталоге Artificial Analysis для текстового DeepSeek V4 Flash отмечена высокая многословность в используемой сервисом оценке. Это наблюдение относится к текстовой модели, не к Vision-Exp, и не оценивает мультимодальный расход. Но оно показывает, почему в пилоте нельзя игнорировать usage: длинный output или многошаговая агентная логика могут повлиять на бюджет сильнее visual input.

• Логируйте input, output, reasoning и cache-статусы, если они возвращаются в usage.
• Ограничьте максимальную длину ответа и число итераций агента до широкого запуска.
• Сверяйте peak и off-peak по UTC, а не по локальному времени команды.
• Отдельно считайте цену fast path и accuracy path: дешёвый запрос не оправдан, если он увеличивает долю ручных проверок.

Цитата в переводе

«Изображения токенизируются для биллинга: до 384 токенов за каждое, по тарифам V4-Flash.»

Latency: текстовые цифры нельзя выдавать за скорость vision-запросов

Для deepseek-v4-flash-vision-exp в рассмотренных первичных материалах не опубликованы конкретные значения времени до первого токена, сквозной задержки, скорости OCR или влияния разрешения на время обработки. Корректный вывод: latency нужно измерять на собственных файлах, в своём сценарии и при выбранной схеме доставки изображения.

Artificial Analysis приводит для текстового DeepSeek V4 Flash 0731 через API DeepSeek TTFT 1,22 секунды и 141 output tokens/s в режиме max effort. Сервис описывает эти данные как показатели за последние 72 часа. Это лишь контекст для текстовой модели. В мультимодальном запросе появляются получение или загрузка изображения, обработка visual input и зависимость от выбранного detail; переносить текстовый результат на Vision-Exp нельзя.

Минимальная телеметрия должна разделять этапы. upload_or_fetch_ms показывает подготовку файла, api_ttft_ms — время до первого SSE chunk, e2e_ms — задержку до готового результата. Рядом следует хранить формат, размер, разрешение, число вложений, detail, usage и исход проверки. Иначе средняя latency не покажет, какие документы или скриншоты создают проблему.

При потоковой выдаче документация позволяет запросить финальный usage chunk через stream_options.include_usage=true. Это помогает совместить streaming-интерфейс с финансовой наблюдаемостью: пользователь получает потоковый ответ, а система учёта — итоговые данные использования.

• Сравнивайте low и original на одной размеченной выборке.
• Снимайте p50 и p95, а не только среднее время ответа.
• Отделяйте сетевое время загрузки от времени обработки API.
• Не включайте текстовые TTFT-цифры в SLA мультимодального процесса.

Качество и агенты: где нужны проверки вместо обещаний

DeepSeek публикует для Vision-Exp результаты на Terminal Bench 2.1, NL2Repo, DeepSWE, DSBench-Hard, AutomationBench, ApexBench, Agents’ Last Exam, Chartography и ZeroBench, а также заявляет близость мультимодальных агентных возможностей к Opus-4.8. Это показывает, какие классы задач поставщик считает целевыми, но не служит независимой валидацией для российского OCR, корпоративных таблиц или UI-регрессии.

Методика имеет значение. В описании DeepSeek использовала DeepSeek Harness в minimal mode, max effort, top_p=0,95 и temperature=1,0; DSBench-Hard назван внутренним набором. Для ApexBench и Agents’ Last Exam, согласно описанию, текстовый V4-Flash игнорировал мультимодальные элементы. Следовательно, результаты характеризуют одновременно модель, набор, конфигурацию и систему запуска.

Наиболее управляемый первый сценарий: помощник с ограниченной ответственностью: классификация изображения, поиск визуального признака, черновик описания, кандидаты на поля или помощь QA при разборе скриншота. Если ошибка ведёт к платежу, изменению данных или действию во внешней системе, ответ модели должен оставаться входом в проверяемый workflow, а не единственным источником истины.

Отдельный риск связан с tool calls. Документация предупреждает, что аргументы инструмента могут содержать невалидный JSON или неописанные параметры. Перед выполнением приложение должно проверить JSON Schema, допустимые значения, права пользователя и бизнес-инварианты. В vision-сценарии это критично: неверно прочитанный номер, статус или элемент интерфейса не должен автоматически запускать действие.

• Для OCR измеряйте exact match по каждому полю.
• Для QA фиксируйте верно найденные дефекты и ложные срабатывания.
• Для агентного сценария измеряйте success rate tool call после серверной валидации.
• Сохраняйте ручную проверку для критичных классов документов на ранних этапах.

Что командам сделать прямо сейчас

Сначала создайте feature flag и отдельный маршрут на deepseek-v4-flash-vision-exp. Ограничьте его тестовой группой, несколькими понятными сценариями и заранее разрешёнными классами файлов. Существующий текстовый маршрут сохраните как fallback: это изолирует эксперимент и создаёт контрольную точку для сравнения.

Затем подготовьте размеченный внутренний набор, отражающий реальную работу: простые и перегруженные скриншоты, мелкий текст, таблицы, изображения низкого качества, разные языки и типовые ошибки интерфейса. Для каждого примера заранее зафиксируйте ожидаемый результат и критерий приемлемости. Существенна не численность примеров, а повторяемость проверки при изменении prompt, SDK, адаптера или модели.

Запустите две ветки. В fast path используйте detail: low, когда достаточно грубой классификации или обнаружения признака. В accuracy path проверьте high либо original на мелком тексте, кодах ошибок и табличных данных. Маршрутизацию выбирайте по трём показателям: качеству, p95 latency и стоимости успешной задачи.

До расширения пилота задайте стоп-условия: критическая ошибка извлечения, превышение задержки, рост usage, отсутствие TTL у файла или tool call, не прошедший строгую валидацию. Это помогает быстро отделить полезный сценарий от впечатляющей, но непроверенной демонстрации.

• Вынесите URL, base64 и file_id в единый слой вложений.
• Включите usage и тайминги в лог каждого вызова; для streaming используйте финальный usage chunk.
• Задайте TTL всем загружаемым файлам и тестируйте удаление.
• Не исполняйте структурированный результат и tool calls без серверной проверки.
• До масштабирования определите допустимые классы изображений и внутренний порядок работы с чувствительными данными.

Что это означает на практике

DeepSeek-V4-Flash-Vision-Exp формирует рабочую мультимодальную поверхность API: приложение уже может объединить изображение, текст, Files API и streaming в одном процессе.

Экспериментальный статус требует инженерной дисциплины. Не стоит переносить на vision-запросы текстовые метрики, принимать бенчмарки поставщика за независимую проверку или оценивать экономику только по image tokens.

Следующий шаг: небольшой измеримый пилот с адаптером вложений, размеченной выборкой, контролем TTL, телеметрией и fallback. Такой подход даст команде воспроизводимые данные для решения о масштабировании, а не набор впечатлений от релиза.

Чек-лист запуска Vision-Exp

Сохраните и используйте этот список перед расширением пилота. PDF-версия предусмотрена в составе пакета для скачивания.

Маршрутизация и контракты

Отделите экспериментальный мультимодальный маршрут от существующей текстовой цепочки. Это позволит безопасно сопоставить качество, задержку и стоимость сценария.

• Включён feature flag для Vision-Exp.
• Есть текстовый fallback.
• Классы допустимых изображений определены.
• URL, base64 и file_id скрыты за единым attachment layer.
• Для ответа задана проверяемая структура.

Данные, файлы и безопасность

Работа с Files API должна быть частью управляемого жизненного цикла вложения, а не технической деталью интеграции.

• Для загруженных файлов задан явный TTL.
• file_id связан с бизнес-объектом и временем истечения.
• Проверяется удаление и результат повторных попыток.
• Пилот начинается с синтетических или обезличенных материалов.
• Чувствительные изображения не отправляются до внутренней проверки допустимых данных и договорных условий.

Качество, latency и экономика

Проверяйте сценарий на размеченной выборке, а не на единичных удачных примерах. Учитывайте стоимость завершённой задачи и долю ручной проверки.

• Сравнены detail: low и более подробные режимы.
• Собираются p50, p95, TTFT и сквозная задержка.
• Разделены время загрузки файла и обработка API.
• Логируются usage и cache-статусы, если они доступны.
• Есть лимиты на длину ответа и число итераций.
• Tool calls проходят серверную валидацию до исполнения.

Источники

• DeepSeek-V4-Flash-Vision-Exp Release: Multimodal API Now Live | DeepSeek API Docs
• DeepSeek-V4-Flash-Vision-Exp Release: Multimodal API Now Live | DeepSeek
• Документация DeepSeek API
• Artificial Analysis: провайдеры DeepSeek V4 Flash 0420
• Artificial Analysis: DeepSeek V4 Flash
• Пользовательское соглашение DeepSeek
• Политика конфиденциальности DeepSeek
• Пользовательское соглашение DeepSeek на платформе
• Официальный источник: DeepSeek V4 Flash Vision Exp

Частые вопросы

Что умеет DeepSeek-V4-Flash-Vision-Exp?

Экспериментальная модель DeepSeek принимает изображения вместе с текстом через API. В документации описаны передача через URL, base64 data URL и ранее загруженный файл по file_id.

Когда использовать Files API вместо base64?

Files API уместен при повторных обращениях к одному изображению. После загрузки приложение передаёт file_id, но должно контролировать TTL, удаление и дубли при повторных попытках.

Можно ли считать текстовые метрики DeepSeek V4 Flash скоростью Vision-Exp?

Нет. Для мультимодальной модели в рассмотренных первичных материалах не приведены подтверждённые значения TTFT, сквозной задержки или OCR-качества. Их нужно измерять на собственных файлах и выбранной схеме доставки.

Как оценивать стоимость мультимодального сценария?

Считать нужно не цену одной картинки, а стоимость завершённой задачи при требуемом качестве: с учётом текстового контекста, output, кэширования, повторных шагов и ручной проверки.

Как безопасно начать пилот Vision-Exp?

Выделите отдельный маршрут с feature flag и текстовым fallback, используйте размеченную выборку, задайте TTL файлам, собирайте latency и usage, а структурированные ответы и tool calls проверяйте на сервере.

Практический чек-лист

Чек-лист запуска DeepSeek Vision-Exp

PDF для команды, которая готовит контролируемый пилот DeepSeek-V4-Flash-Vision-Exp: маршрутизация, файлы, качество, задержка и валидация действий.

Маршрутизация и контракты

• Включён feature flag для Vision-Exp.
• Сохранён текстовый fallback.
• Определены допустимые классы изображений.
• Форматы URL, base64 и file_id вынесены в единый слой вложений.
• Для результата задана проверяемая структура.

Данные и Files API

• Для файлов задан явный TTL.
• file_id связан с бизнес-объектом и временем истечения.
• Проверяются удаление и повторные попытки загрузки.
• Пилот использует синтетические или обезличенные изображения.
• Чувствительные данные не передаются до внутренней проверки.

Метрики и контроль качества

• На размеченной выборке сопоставлены low и подробные режимы detail.
• Собираются p50, p95, TTFT и сквозная задержка.
• Разделены время загрузки и время обработки API.
• Логируются usage и cache-статусы, если они доступны.
• Tool calls и структурированные ответы валидируются сервером.